DETAILED ACTION
In a communication received on 2 January 2026, the applicants amended claims 1, 2, 12, 13, and 19.
Claims 1-17 and 19-23 are pending.
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 Arguments
Applicant’s arguments with respect to claim(s) 1, 2, 12, 13, and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 4, 10, 12, 14, 15 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wittern et al. (US 2019/0370370 A1) in view of Thompson (US 2016/0301739), and further in view of Burli et al. (US 2018/0278471 A1).
With respect to claim 1, Wittern discloses: a representational state transfer (ReST) framework (i.e., server with interface component and resolve function for translating a request corresponding to a target REST API in Wittern, fig. 2, ¶0044), wherein the endpoint configuration comprises:
a plurality of supported operations (i.e., open api specification describes an API into operations identified by URI path and/or HTTP method in Wittern, ¶0024);
a plurality of header definitions, wherein each header definition is associated with at least one of the plurality of supported operations (i.e., the specification defining required parameters in headers corresponding with identified operations; for REST APIs resource identifiers and data are defined as parameters in headers in Wittern, ¶0024, ¶0044);
receiving, by the ReST framework, a request to perform an operation and ReST resource details associated with the request to perform the operation, the ReST resource details comprising an endpoint URL for a target resource and an indication that a first endpoint configuration applies to servicing the request to perform the operation (i.e., translate queries into a request using open API specifications to process methods corresponding to an endpoint, the endpoint addressable by a URL and HTTP methods with other data in the request in Wittern, ¶0018, ¶0023-0024, ¶0030); and
generating a ReST request, the ReST request including the endpoint URL for the target resource, a Hypertext Transfer Protocol (HTTP) method, and a header (i.e., generate request based on the submitted queries using the OAS definition where the request includes the URI of the endpoint, HTTP method, and other supporting information in Wittern, ¶0044),
wherein generating the ReST request comprises: accessing the first endpoint configuration (i.e., using the OAS definition to retrieve data types and other information to formulate the request, the OAS breaks down the API into parameters including those needed for the header in Wittern, ¶0024, ¶0030)
determining if the requested operation is one of the plurality of supported operations (i.e., determining a bound mapping of operation defined in OAS for an API and headers and a parameters corresponding to REST APIs in Wittern, ¶0044);
responsive to determining that the requested operation is one of the plurality of supported operations, selecting at least one header definition from the plurality of header definitions based on the requested operation (i.e., identify operations defined in an OAS file, determining instructions for sending arguments parameters in the queries as parameters in the headers in Wittern, ¶0044);
generating the header based on the selected at least one header definition (i.e., passing the resource identifiers, and parameters in a header corresponding to a mapping of original request using the defined specifications in Wittern, ¶0044); and
mapping the operation to the HTTP method (i.e., resolver function to bind mapping of arguments and functions to HTTP methods in Wittern, ¶0044); and
transmitting the ReST request to a ReST server (i.e., using the OAS to generate and send requests to the target API's in Wittern, ¶0044).
Wittern discloses translate queries into a request using open API specifications to process methods corresponding to an endpoint, the endpoint addressable by a URL and HTTP methods with other data in the request (¶0018, ¶0023-0024, ¶0030). Wittern do(es) not explicitly disclose the following. Thompson, in order to facilitate efficient exposure to endpoint APIs by providing configurable settings to implement one or more of caching, throttling, load balancing and scalability (¶0013), discloses: method comprising:
storing a plurality of endpoint configurations (i.e., endpoint management system accesses endpoint/API mapping definitions from a data source to implement proxy API which maps parameters and transforms request to input parameters of the backend API; "The response handler 108 may be in communication with and access an endpoint/API mapping definitions data source 128 to look up API mapping definition for a received request. The response handler 108 can, based at least in part on the API mapping definition, determine a backend API ( or APIs) and backend system( s) to be used to service the request." in Thompson, ¶0021)
for heterogeneous ReST interfaces as configurable files consumable by a ReST framework (i.e., endpoint management system provides proxy API definitions to map to logic and one or more heterogenous endpoints corresponding to REST; "The endpoints can be heterogeneous (e.g., web services, Internet of Things ("IoT") devices, other cloud-based service provider functions, datacenter functionality, and so on), and can also include other APIs. For example, a Representational State Transfer ("REST") API may be exposed which maps to a legacy SOAP-based APL" in Thompson, ¶0013).
Based on Wittern in view of Thompson, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Thompson to improve upon those of Wittern in order to facilitate efficient exposure to endpoint APIs by providing configurable settings to implement one or more of caching, throttling, load balancing and scalability.
Wittern discloses resolve functions corresponding to definitions in an open API specification to bind identifiers and parameters for request to REST-like APIs (¶0044). Wittern and Thompson do(es) not explicitly disclose the following. Burli, in order to improve interoperability and providing disparate endpoint user applications with a single platform (¶0002), discloses:
dynamically updating, during execution of the ReST framework and without stopping execution of the ReST framework, the ReST framework dynamically consuming a configurable file (i.e., configuration file corresponding to adding new endpoint application and its corresponding API without incurring platform downtime to rebuild and redeploy in Burli, ¶0047, ¶0097)
corresponding to the new type of data store to add to the plurality of endpoint configurations (i.e., a database management system endpoint corresponding to configuration file for its API; API of endpoint application may be ReST in Burli, ¶0040, ¶0076);
mapping an endpoint configuration from the plurality of endpoint configurations to at least one of a plurality of supported operations (i.e., selecting a configuration file from a plurality for the identified application; generate API calls from the request operations mapped to their analogues in Burli, ¶0009; ¶0098-0099).
Based on Wittern in view of Thompson, and further in view of Burli, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Burli to improve upon those of Wittern in order to improve interoperability and providing disparate endpoint user applications with a single platform.
With respect to claim 3, Wittern discloses: the method of claim 1, further comprising:
storing an object representing a ReST-based store (i.e., receiving an OPEN API Specification that describes how to interact with a given API in Wittern, ¶0030),
the object representing the ReST-based store comprising a data store type (i.e., schemas indicate the data types expected in Wittern, ¶0030)
and an endpoint URL for the ReST-based store (i.e., open API specification describes an API of a URI path and HTTP method in Wittern, ¶0024),
wherein the first endpoint configuration is stored in association with the data store type (i.e., open API specification describes an API of a URI path and HTTP method along with data schemas and parameters in Wittern, ¶0024).
With respect to claim 4, Wittern discloses: the method of claim 3, wherein the target resource is the ReST-based store and the endpoint URL for the target resource is the endpoint URL for the ReST-based store (i.e., resources are identified by a URI allowing clients to perform operations described in an open API specification in Wittern, ¶0018, ¶0024).
With respect to claim 10, Wittern discloses: the method of claim 1, further comprising:
storing an authentication module that is dynamically executable by the ReST framework, wherein generating the ReST request comprises: (i.e., authentication mechanisms allowing to pass authentication information from clients in Wittern, ¶0049, ¶0050)
determining that the first endpoint configuration references the authentication module (i.e., authentication mechanisms allowing user to pass authentication information such as keys, username, and password in Wittern, ¶0049, ¶0050); and
based on the determination that the first endpoint configuration references the authentication module, executing the authentication module to return authentication information, wherein the ReST request includes the authentication information. (i.e., authentication mechanisms allowing user to pass authentication information such as keys, username, and password in Wittern, ¶0049, ¶0050).
With respect to claim 12, the limitation(s) of claim 12 are similar to those of claim(s) 1. Therefore, claim 12 is rejected with the same reasoning as claim(s) 1.
With respect to claim 14, the limitation(s) of claim 14 are similar to those of claim(s) 3. Therefore, claim 14 is rejected with the same reasoning as claim(s) 3.
With respect to claim 15, the limitation(s) of claim 15 are similar to those of claim(s) 4. Therefore, claim 15 is rejected with the same reasoning as claim(s) 4.
With respect to claim 21, the limitation(s) of claim 21 are similar to those of claim(s) 10. Therefore, claim 21 is rejected with the same reasoning as claim(s) 10.
Claim(s) 2 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wittern et al. (US 2019/0370370 A1) in view of Thompson (US 2016/0301739) and Burli et al. (US 2018/0278471 A1), and further in view of Prahlad et al. (US 2010/0332456 A1).
With respect to claim 2, Wittern discloses translate queries into a request using open API specifications to process methods corresponding to an endpoint, the endpoint addressable by a URL and HTTP methods with other data in the request (¶0018, ¶0023-0024, ¶0030). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Prahlad, in order to implement REST-based protocols for interoperable cloud storage management (¶0120), discloses: the method of claim 1, further comprising: receiving, by a server of a content management system that manages a repository (i.e., REST interface to read, write, retrieve, data in an object server node corresponding to cloud storage in Prahlad, ¶0319)
comprising content objects (i.e., file/object in Prahlad, ¶0320),
container objects (i.e., sub-clients are containers in Prahlad, ¶0320)
and ReST store objects (i.e., cloud storage site corresponding to a URL serving a customer or company in Prahlad, ¶0320),
a client request with respect to a managed object from the repository (i.e., application running on client requests data object in Prahlad, ¶0338),
wherein the repository comprises: a metadata store comprising: content object metadata (i.e., information about data object in Prahlad, ¶0323),
container object metadata (i.e., identifying sub-client in Prahlad, ¶0323), and
ReST store object metadata (i.e., storage locations at cloud storage sites in Prahlad, ¶0323); and
a storage area comprising content containers and content files of the content objects (i.e., archive files in data store comprising volume folders, metadata files, container files in Prahlad, ¶0360), and
wherein the metadata store comprises, and wherein the managed object is a content object or a container object (i.e., sub-clients are containers with file/objects in Prahlad, ¶0320); and
based on the client request, retrieving object metadata of the managed object from the metadata store (i.e., security settings for the object retrieved in Prahlad, ¶0338),
the object metadata of the managed object referencing a first ReST store object (reference URL or web directory of cloud storage site in Prahlad, ¶0320),
the first ReST store object representing a ReST-based store and comprising the ReST resource details, wherein the server of the content management system provides the ReST resource details to the ReST framework (i.e., object server expose REST interface for accessing file system via REST in Prahlad, ¶0322).
Based on Wittern in view of Thompson and Burli, and further in view of Prahlad, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Prahlad to improve upon those of Wittern in order to implement REST-based protocols for interoperable cloud storage management.
With respect to claim 13, the limitation(s) of claim 13 are similar to those of claim(s) 2. Therefore, claim 13 is rejected with the same reasoning as claim(s) 2.
Claim(s) 5-9, 11, 16, 17, 20, 22, and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wittern et al. (US 2019/0370370 A1) in view of Thompson (US 2016/0301739) and Burli et al. (US 2018/0278471 A1), and further in view of Sharma et al. (US 2022/0326929 A1).
With respect to claim 5, Wittern discloses: the method of claim 3, further comprising a container object representing a container in the ReST-based store (i.e., a schema object further including nested object types suggesting a container in Wittern, ¶0035),
the container object comprising an endpoint URL for the container (i.e., open API specification describes an API of a URI path and HTTP method in Wittern, ¶0024)
Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: and a storage location indicating that the container is in the ReST-based store (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 6, Wittern discloses: the method of claim 5
wherein the method further comprises: accessing the container object to retrieve details of the container (i.e., open API specification describes an API of a URI path and HTTP method in Wittern, ¶0024)
and the endpoint URL for the container (i.e., open API specification describes an API of a URI path in Wittern, ¶0024);
including the data store type in the ReST resource details associated with the request as the indication that the first endpoint configuration applies (i.e., the OAS details information necessary to communicate with the target API including the types of data and values to expect] in Wittern, ¶0044).
Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses:
based on the storage location from the container object, accessing the object representing the ReST-based store to retrieve the data store type (i.e., manifest file indicates to the user the files to download suggesting indicating a storage location in Sharma, ¶0041, ¶0043); and
including the storage location (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042),
wherein the target resource is the container in the ReST-based store (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 7, Wittern discloses: the method of claim 3, further comprising storing a content object representing a file stored in the ReST-based store (i.e., generating schemas for API's suggesting the ability to store representations of objects in Wittern, ¶0030),
the content object (i.e., defines types based on schema objects suggesting representation and storage of content objects in Wittern, ¶0033)
comprising an endpoint URL for the file (i.e., open API specification describes an API of a URI path and HTTP method along with data schemas and parameters in Wittern, ¶0024)
indicating that the file is stored in the ReST-based store (i.e., storage of various types or schema objects located in a server in Wittern, ¶0035).
Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: and a storage location (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 8, Wittern discloses: the method of claim 7
and wherein the method further comprises: accessing the content object to retrieve details of the file including the storage location and the endpoint URL for the file (i.e., using the open API specification to generate a corresponding request to an endpoint API including the data types and parameters expected for the returning of the data in Wittern, ¶0030); and
including the data store type in the ReST resource details associated with the request as the indication that the first endpoint configuration applies (i.e., translate the request to the appropriate target API based on the schema defining the data included in the request in Wittern, ¶0024, ¶0030).
Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: wherein the target resource is the file stored in the ReST-based store (i.e., a REST api to present to end user in retrieving update package and the API is described in a declarative format like YAML and for a corresponding specific environment in Sharma, ¶0062);
based on the storage location from the content object, accessing the object representing the ReST-based store to retrieve the data store type (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 9, Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: the method of claim 1, further comprising:
determining that the first endpoint configuration is not cached (i.e., container images can benefit from determined caching mechanisms suggesting that if the container is cached, a download would not be necessary, and/or caching the image for future use in Sharma, ¶0053); and
based on the determination that the first endpoint configuration is not cached, reading the first endpoint configuration from a first location into a cache, wherein the first endpoint configuration is accessed from the cache (i.e., caching the container image such that future download not be necessary in Sharma, ¶0053).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 11, Wittern discloses REST APIs are achrictural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: the method of claim 10, further comprising:
after determining that the first endpoint configuration references the authentication module and prior to executing the authentication module, determining that the authentication module is not cached; and (i.e., retrieving the container image would be improved by determining if any of the container image dependencies were cached thus reducing the need to download the dependencies in a future update in Sharma, ¶0053);
based on the determination that the authentication module is not cached, reading the authentication module from a first location into a cache (i.e., specific dependencies may be cached to avoid future download during update in Sharma, ¶0053).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
With respect to claim 16, the limitation(s) of claim 16 are similar to those of claim(s) 5. Therefore, claim 16 is rejected with the same reasoning as claim(s) 5.
With respect to claim 17, the limitation(s) of claim 17 are similar to those of claim(s) 6. Therefore, claim 17 is rejected with the same reasoning as claim(s) 6.
With respect to claim 20, the limitation(s) of claim 20 are similar to those of claim(s) 9. Therefore, claim 20 is rejected with the same reasoning as claim(s) 9.
With respect to claim 22, the limitation(s) of claim 22 are similar to those of claim(s) 11. Therefore, claim 22 is rejected with the same reasoning as claim(s) 11.
With respect to claim 23, Wittern discloses: the method of claim 1, includes
authentication modules (i.e., an authentication component allowing users to pass authentication information into the resolve functions of one or more wrapped types supporting authentication in Wittern, ¶0049).
Wittern discloses REST APIs are architectural style of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, and Burli do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses: the ReST server includes a store plugin ReST to support multiple ReST-based stores (i.e., user-connection gateway to proxy pull commands and configured to cache container images locally; supports use of multiple containers and corresponding images with files within in Sharma, ¶0053).
Based on Wittern in view of Thompson and Burli, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wittern et al. (US 2019/0370370 A1) in view of Thompson (US 2016/0301739), Burli et al. (US 2018/0278471 A1) and Prahlad et al. (US 2010/0332456 A1), and further in view of Sharma et al. (US 2022/0326929 A1).
With respect to claim 19, Wittern discloses: the non-transitory, computer-readable medium of claim 13, wherein the managed object is a content object representing a file stored in the ReST-based store (i.e., generating schemas for API's suggesting the ability to store representations of objects in Wittern, ¶0030),
the content object comprising an endpoint URL for the file (i.e., open API specification describes an API of a URI path and HTTP method along with data schemas and parameters in Wittern, ¶0024), and
wherein the first ReST store object comprises a data store type (i.e., schemas indicate the data types expected in Wittern, ¶0030)
and an endpoint URL for the ReST-based store (i.e., open API specification describes an API of a URI path and HTTP method in Wittern, ¶0024),
wherein the first endpoint configuration is stored in association with the data store type (i.e., open API specification describes an API of a URI path and HTTP method along with data schemas and parameters in Wittern, ¶0024)
wherein the non-transitory, computer-readable medium further comprises instructions executable by the computer for:
accessing the content object to retrieve details of the file including the storage location and the endpoint URL for the file (i.e., using the open API specification to generate a corresponding request to an endpoint API including the data types and parameters expected for the returning of the data in Wittern, ¶0030); and
including the data store type in the ReST resource details associated with the request as the indication that the first endpoint configuration applies, wherein the file is the target resource. (i.e., translate the request to the appropriate target API based on the schema defining the data included in the request in Wittern, ¶0024, ¶0030).
Wittern discloses REST APIs are achrictural type of APIs identifying resources by URI's and allow clients to perform predetermined operations, clients need to adhere to APIs to perform methods with desired results, instead, clients can change their queries to meet requirements of APIs without adding endpoints (¶0018-0019). Wittern, Thompson, Burli, and Prahlad do(es) not explicitly disclose the following. Sharma, in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client (¶0004), discloses:
and storage location indicating the file is stored in the ReST-based store (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042);
based on the storage location from the content object, accessing the ReST store object to retrieve the data store type (i.e., manifest file enables user to download files of the packages/containers suggesting a storage location in Sharma, ¶0042).
Based on Wittern in view of Thompson and Burli and Prahlad, and further in view of Sharma, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings of Sharma to improve upon those of Wittern in order to improve automated implementation of deployments of cloud functionality to the client via delivery of updates to the client.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHERMAN L LIN whose telephone number is (571)270-7446. The examiner can normally be reached Monday through Friday 9:00 AM - 5:00 PM (Eastern).
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, Joon Hwang can be reached on 571-272-4036. 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.
Sherman Lin
1/10/2026
/S. L./Examiner, Art Unit 2447
/JOON H HWANG/Supervisory Patent Examiner, Art Unit 2447