DETAILED ACTION
This action is responsive to the Applicant’s response filed 8/12/26.
As indicated in Applicant’s response, claims 1, 6, 9, 14, 16, 22 have been amended, claims 5, 13, 19-20 cancelled and claims 23-24 added. Claims 1-4, 6-12, 14-18, 21-24 are resubmitted and pending prosecution by the following office action.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to a
judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without
significantly more. Claim(s) 1 s/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because of the following 2-step analysis.
Step 1:
The claim is directed to a process category
Step 2A
Prong One:
The elements recited as "identifying an electronic document each comprising elements to configure settings pertaining application feature", “determining at least one or more operation mapped to at least one element” (for inclusion in a file) and "generating configuration file based on configuration data and an operation mapped to at least one element" are mostly viewed as activities that can be performed by a human mind or via use of pen/paper; as a human can identify a document on a computer screen and jot down data pertinent to user interaction observed from the computer interface into a paper file format. The claim falls into the Mental Process/Organizing human activity subgroup of a Judicial Exception. MPEP 2106.04(a) (II) and (III)
Prong Two:
The elements recited as "receiving a request for configuring a feature for an
application", "providing the electronic document for presentation", "obtaining configuration data with
settings pertaining to the feature based on user interaction with a document" and "providing user access to the application feature" (based on generated configuration file and in accordance with the request) amount to extra-solution activities that either pre-activities that precede the Abstract Idea or post-activities that follow the Abstract Idea. That is, step of receiving a request", "providing document for presentation" and "obtaining configuration data" are construed as part of gathering or collecting information in support for either a "identifying" step and a "generating" (a configuration file) step and the step of "providing access" to the feature clearly amounts to an extra-solution activity relaying on result of the Abstract Idea similar to sending, distributing or displaying result from an Abstract Idea. As a whole, the claim describe a scenario starting from receiving a request (for a feature), then "identifying" a document (associated with a feature), providing a document (from user selection) and obtaining configuration data or settings (from interaction with the document) and "generating a configuration file", which enable providing access of the feature to the user, in the sense that the scenario is about obtaining or acquiring information for an identification step, and for pen/paper generation step, followed by post- activity step to enable access to result of the "generating" step. In a whole, the claim describes typical steps or well- understood routines that fall under the ambit of a mental process sequence that acquires information, performs identification and generates pen/paper data for distributing/providing information access to other recipients.
The element recited as “each of the plurality elements mapped to one or more operations that when executed enable at least a portion of application feature” is construed as an element included in a document and at best represents but a piece of information contained in a document. This document-included “element” cannot upconvert the abstract Idea into a practical application
The claim fails to integrate the Abstract idea (of step IIA) into a Practical Application as no part of the acquiring step or providing step clearly expresses a significant computer-based improvement or transformation to this identification scenario. See MPEP 2106.05 (a), (b), (c),(g).
Step 2B
The additional elements recited as "receiving" (request, feature), "application provided by
the platform", "document comprises elements enable user to configure settings" and
"providing" (document for presentation) and "providing" (the user with access to the application
feature) are construed either as mere pre-activity actions to acquire data (feature, element, settings,
document) the Abstract Idea (of identifying or generating or determining) or mere post-activity actions that make use of result from the Abstract Idea in terms of "providing access" of the generated file. Hence, as these extra-solution activities are well-understood routines, these additional elements fail to add significantly more to the abstract idea itself; nor do they convert the Abstract Idea into an inventive improvement to the field of computer application in processing documents. MPEP 2106.05 (a), (b), (c), (g)
Claim 1 is deemed ineligible under the 35 USC § 101 statute
Claims 9 and 16 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claim(s) 9 and 16 is/are directed to Abstract Idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial
exception because of the following 2-step analysis.
Eligibility of claim 9
Step 1:
this claim is directed to an apparatus/system category.
Step 2A
Prong One:
The elements recited as "identifying an electronic document each comprising elements to configure settings pertaining application feature", “determining at least one or more operation mapped to at least one element” (for inclusion in a file) and "generating configuration file based on configuration data and an operation mapped to at least one element" are mostly viewed as activities that can be performed by a human mind or via use of pen/paper. The activities are thus viewed as belonging to a mental process or use of pen/paper pertinent to an Abstract Idea group per MPEP 2106.04(a)(2) (II) or (III)
Prong Two:
The elements recited as "receiving a request for configuring a feature for an application", "providing the electronic document for presentation", "obtaining configuration data with settings pertaining to the feature based on user interaction with a document" and "providing user access to the application feature" (based on generated configuration file and in accordance with the request) amount to either as pre-activities that precede the Abstract Idea or post-activities that follow the Abstract Idea. That is, step of receiving a request", "providing document for presentation" and "obtaining configuration data" are construed as an extra-solution acts of gathering or collecting information in support for either a "identifying" step whereas the "generating" (a configuration file) step and the step of "providing access" to the feature clearly amount to a post-solution activity relaying on result of the Abstract Idea similar to sending, distributing or displaying result from an Abstract Idea. In all, the claim describes typical steps or well- understood routines that fall under the ambit of a mental process sequence that acquires information, performs identification and generates pen/paper data for distributing/providing information access to other recipients
The element recited as “each of the plurality elements mapped to one or more operations that when executed enable at least a portion of application feature” is construed as an element included in a document and at best represents but a piece of information contained in a document. This document-included “element” cannot upconvert the abstract Idea into a practical application
The claim fails to integrate the Abstract idea (of step IIA) into a Practical Application as no part of the acquiring step or providing step clearly expresses a significant computer-based improvement or transformation to this identification scenario. See MPEP 2106.05 (a), (b), (c),(g)
Step 2B
Claim 9 recites the same additional elements of claim 1, those being "receiving a request
for configuring a feature for an application" "providing document for presentation", "obtaining configuration data with settings pertaining to the feature based on user interaction"
and "providing user access to the feature" (based on generated configuration file) and as set forth above in step IIB of claim 1, these elements are viewed as well-understood routines that usually
comprise the acquisition of information prior to performing activities of a mental process and
divulging or transmitting result of the mental process into a format, and as such, these additional
elements cannot be construed as transforming a technical aspect in the computer-based application to
process document; that is, the "system" claim per effect of the additional elements from above
cannot significantly add more to the Abstract Idea itself. MPEP 2106.05 (a), (b), (c), (g)
Eligibility of claim 16.
Step 1:
Claim 16 is directed to a product/medium category.
Step 2A
Prong One:
This claim also recites "identifying an electronic document each comprising elements to configure settings pertaining application feature", “determining at least one or more operation mapped to at least one element” (for inclusion in a file) and "generating configuration file based on configuration data and an operation mapped to at least one element", and as set forth above, these activities are viewed as activities that can be performed in the human mind or via use of pen/paper.
The claim falls into the Mental Process/Organizing human activity subgroup of a Judicial Exception. MPEP 2106.04(a) (II) and (III)
Prong Two:
The elements recited as "receiving a request for configuring a feature for an application", "providing the electronic document for presentation", "obtaining configuration data with settings pertaining to the feature based on user interaction with a document" and "providing user access to the application feature" (based on generated configuration file and in accordance with the request) amount to either as pre-activities that precede the Abstract Idea or post-activities that follow the Abstract Idea. That is, step of receiving a request", "providing document for presentation" and "obtaining configuration data" are construed as an extra-solution acts of gathering or collecting information in support for either a "identifying" step whereas the "generating" (a configuration file) step and the step of "providing access" to the feature clearly amount to a post-solution activity relaying on result of the Abstract Idea similar to sending, distributing or displaying result from an Abstract Idea. In a whole, the claim describes typical steps or well- understood routines that fall under the ambit of a mental process sequence that acquires information, performs identification and generates pen/paper data for distributing/providing information access to other recipients
The element recited as “each of the plurality elements mapped to one or more operations that when executed enable at least a portion of application feature” is construed as an element included in a document and at best represents but a piece of information contained in a document. This document-included “element” cannot upconvert the abstract Idea into a practical application
The claim fails to integrate the Abstract idea (of step IIA) into a Practical Application as no part of the acquiring step or providing step clearly expresses a significant computer-based improvement or transformation to this identification scenario. See MPEP 2106.05 (a), (b), (c),(g)
Step 2B
Claim 16 recites the same additional elements of claim 1, those being "receiving a request
for configuring a feature for an application" "providing document for presentation", "obtaining configuration data with settings pertaining to the feature based on user interaction"
and "providing user access to the feature" (based on generated configuration file) and as set forth above in step IIB of claim 1, these elements are viewed as well-understood routines that usually
comprise the acquisition of information prior to performing activities of a mental process and
divulging or transmitting result of the mental process into a format, and as such, these additional
elements cannot be construed as particularly transforming a technical aspect in the computer-based application to process document; that is, claim 16 in terms of the additional elements from above cannot significantly add more to the Abstract Idea itself. MPEP 2106.05 (a), (b), (c), (g)
Step 2B Analysis of dependent claims
Claims 2, 10, 17 repeat the scenario of receiving an additional request, obtaining additional
configuration data, generating an additional file and providing access to the generated file, and as
mentioned from the base claim, these steps cannot add significantly more to the abstract idea of the
base claim.
Claims 3, 11, 18 recite "detecting" update to a feature, which amounts to a mental process by
a human mind, "updating" the configuration file which amounts to activity done via pen/paper, and
"providing" access to the "updated configuration file", which in all, amount to insignificant extra-solution activity that makes use of result from an abstract Idea; hence the above elements fail to add
significantly more to the Abstract Idea of the base claim.
Claims 4 and 12 describe settings that pertain to feature associated with a resource provided
by a platform; but this static descriptive matter cannot add significantly more to the Abstract Idea
itself.
Claims 5 and 13 recite that when a document is mapped to one or more operations for
execution, a portion of the feature will be enabled. Merely describing a intended use or result from a
execution that relies on a condition ("when executed") without showing the "how to" details fail to
render the Abstract Idea in the base claim significantly more than itself.
Claims 6 and 14 recite source code comprising one or more placeholder values that reference configuration data; obtaining and modifying a copy of such source code to replace the placeholder content. The operation of obtaining a file having values therein replaced basically depicts an extra-solution step of altering content of a file used into the abstract step of processing, instead of a significant computer-based transformation that improves upon a document-based feature mapping identified from step2A, notably when replacing placeholder value can be performed via use of pen/paper
Claims 7 and 15 depict client device or additional client in a organizational state of using
application so to be provided with the feature in the configuration file; but description of this extra-
solution functionality cannot add significantly more to the Abstract Idea itself.
Claim 8 gives exemplary instances of a feature and this static descriptive matter cannot add
significantly more to the Abstract Idea itself.
Claim 21 recites "detecting" update to a source code, which amounts to a mere mental
process; "updating" the configuration file, which amounts to a well-understood post-activity that
makes use of the Abstract Idea; "providing access to the user feature of the updated file, which
amount to an extra-solution typical of sending, distributing, printing and displaying result of a
mental process; and these additional elements cannot render the Abstract Idea (of claim 1)
significantly more than itself.
Claim 22 recites "detecting" user interaction, which amounts to a mere mental process, and
in response, "initiating" commands for a state checking and "updating" the electronic document
based on the state. As such, the checking of state and updating a document based on the checking
can be viewed as updating a file using pen/paper responsive to a "state" check being performed by a
mental process. Hence, claim 22 cannot add significantly more to the abstract idea of claim 1.
Claim 23 recites obtaining configuration data in terms of a enabled field value indicative of a resource associated with an element of the application feature, the value of the field being basis for inclusion of an operation in the configuration file. Describing a element of a configuration as basis for building a configuration file fails to describe functional execution of an operation or a file that improves the computer field in which the Abstract Idea operates.
Claim 24 recites source code update in terms of modifying one operation mapped to an element, thereby retrieving configuration data and regenerating the configuration file based on the modified operation and the retrieved configuration without user interaction. Updating a configuration file and retrieving configuration based on a modification to the file falls under the collecting and reorganizing gathered data (via modifying, processing information) as part of activities typical to the abstract idea of step 2A.
In all, claims 1-4, 6-12, 14-18, 21-24 are deemed ineligible under the 35 USC § 101 statute.
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.
Claims 1-4, 7-12, 15-18, 21-24 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Dinh et al, USPubN: 2021/0132935 (herein Dinh) in view of Li, Peng-Fei, CN 110704099 (translation) 04-22-2021, 14 pgs (herein LPengFei)
As per claim 1, Dinh discloses a method comprising:
receiving a request from a client device of a user (para 0037; requests 107 – para 0038) of a platform (Fig. 5) for configuring an application feature, of a plurality of application features (e.g. enterprise logic, endpoints, data sources, messaging, web services, templates – para 0041; blue-green deployment – para 0049; deployment component – para 0062; GitLab – para 0066; one-click deployment – para 0095; CLI 508 – para 0063), for an instance of an application (microservices – para 0033; para 0040; deploying microservice code – para 0063;) provided by the platform;
identifying, from a plurality of electronic documents (see below) each associated with a respective application feature of the plurality of application features (an endpoint may include a URL – para 0041; Templates my refer to … java code and dynamic web pages – para 0042 - Note1: URL, codebase, reference objects, java code and web page content referred to by application features like enterprise logic, endpoint, templates reads on electronic document – see Templates, JSON, XML specifications or properties - associated with a respective feature of the application – see para 0042; configuration properties … servlet containers … virtual machines – para 0043; blue-green deployment – para 0049; GitLab – para 0066; one-click deployment – para 0095), an electronic document (codebase sources 103 – para 0033; see templates, Java code, web page, server page specifications, XML configuration from below) associated with the application feature of the request, wherein the electronic document comprises at least one of a spreadsheet document, an electronic form document(e.g. Templates may refer to … object defined in Java code – para 0042; codebase from the specified location – para 0037; JSON schema – para 0066, 0068), a word processing document, a web page document (incorporating dynamic content in web pages – para 0042; server page specifications, XML configuration files – para 0043), or a slide presentation document;
providing the electronic document for presentation to the user, wherein the electronic document (see Templates, Java code, web page, server page specifications, XML configuration, JSON properties from above) comprises a plurality of elements (configuration properties – para 0043; URL or service or other locations from which APIs can access resources for performing their functions – para 0041; referencing objects defined in Java – para 0042; Fig. 7; para 0068; deployment descriptors – para 0049) each associated with at least one of a function (configuration level functionalities, application level logic, deployment … into a web container or a computing resource – para 0043; APIs … for performing their functions – para 0041) associated with the application feature (enterprise logic, endpoints, data sources, messaging, web services, templates – para 0041), each of the plurality of elements (see properties, URL, locations, objects defined in Java from above) being mapped to one or more operations (enterprise logic, endpoints, web services, microservice code – para 0085-0086) that, when executed, enable at least a portion of the application feature (see application logic, endpoint or web service from above; logic to generate microservice code – para 0065) according to one or more settings (e.g. servlet container - para 0043; snippet, placeholders, accelerators – para 0089; DevOps tool – para 0067);
obtaining configuration data (configuration properties, XML configuration files – para 0043) associated with one or more settings (see servlet container - para 0043; snippet, placeholders, accelerators – para 0089; DevOps tool – para 0067) pertaining to the application feature based on a user interaction (servlet container … can be configured by editing XML configuration files – para 0043; interface 506, CLI 508 … specifies and clicks on a codebase location … codebase can be retrieved – para 0063; ) with at least one element of the plurality of elements (see properties, URL, locations, objects defined in Java from above; JSON properties – para 0068);
determining, based on the user interaction(CLI 508, user interface 506 – para 0037-0038) and from a source code file(codebase from the specified location – para 0037; existing code, legacy code – para 0033; existing code, legacy code – para 0040) associated with the application feature(logic to generate microservice code – para 0065; enterprise logic, endpoints – para 0041; application level logic and/or enterprise logic … in connection with … deployment of application server or web server - para 0043 ), at least one operation (see servlet and HTTP server, web server from below) mapped to the at least one element (extract … properties related to web server and … containers for implementing servlet and providing HTTP server … in which code can be executed – para 0043; log checking, infrastructure services and task) for inclusion (generates one or more configuration files … based on outputs from the code analyzer 121 … configuration 125 include settings for … executing computer programs, applications, server processes – para 0045) in a configuration file (code snippets to illustrate the configuration files – para 0068 - Note2: user interaction via a UI and CLI to determine legacy code to provide an analyzer/extractor engine by which properties are mapped to a servlet application to execute logic of a web/application server – para 0043 – or code snippets, so that the code/settings for that logic implementation are inputted (ingested) into content that forms a configuration file – para 0045 - formed by assembling results/outputs from the code analyzer module reads on determining via UI and source code, at least one operation mapped to one or more properties for inclusion into a configuration file used in deploying a web service, web server or microservice application – see para 0046) for the application instance;
generating a configuration file (para 0045) for the application instance (para 0046) based on the configuration data (see user interaction and source code, extracted configuration properties and edited XML – para 0043 from above) and an operation mapped to the at least one element ( configuration properties related to web server and containers for implementing servlet and providing HTTP web server … in which code can be executed – para 0043 – Note3: container code or servlet code to be executed on a HTTP server – para 0043 - reads on operation mapped to at least one extracted property by a analyzer/extractor module using user interactions, edits to XML and source/legacy code retrieved by user specifications)
A) Dinh does not explicitly disclose
providing, based on an execution of the generated configuration file, the user with access to the application feature for the application instance via the client device, in accordance with the request.
Dinh discloses user request for a microservice code generation via interactive process to retrieve a selected legacy code (para 0037-0038) from storage using a combined analyzer/extractor module under an orchestration environment by a DevOps/GitLab framework (para 0066) that uses the input code to derive templates as well as other features of the microservice code generator framework, including enterprise logic, endpoints and web services (para 0041), where the analyzer/extractor provides the templates (para 0042) provide referenced objects in Java for incorporating to web pages, as well as configuration properties – e.g. XML data (para 0043) to configure container for in generating enterprise logic or application servers (e.g. HTTP/web server functionality or servlet), where output from the analyzer form one or more configuration files (para 0045) containing settings to build applications/server processes, according to which, the microservice code generator reads the configuration files (para 0046) and adapts API to retrieve snippets from repository and REST template via SOAP (Fig. 2), both the snippets and templates for further modification and configuration as part of microservice generator in support of developers (para 0047), the DevOps/GitLab framework enabling the developers to access Git Repository for codebase under the orchestration module (para 0064), to make use of a validation engine (para 0071,0074) integrated with the microservice code generator (MCG). Hence, user having access to a variety of application features in association with request (requests 107 – para 0038) for a microservice code generation via execution by an analyzer/extractor layer (Fig. 5) by which setting and extracted data therefrom form one or more configuration files (para 0045) destined to provide configuration and setting for the MCG to generate microservice code requested by the user entails providing the user with access to the application feature (e.g. enterprise logic, web services, templates) for the application instance via the client device, in accordance with the request – referred herein as (*)
Similar to Dinh use of DevOps and implementing of logic into a container, LPengFei discloses Kubernetes API construction method for a alliance chain in generating a cluster service (pg. 8) comprising receiving configuration parameters input by the user according to preset configuration of a template, number of development frames, distribution subscription information (claim 1, pg. 13) and name of the application (see Abstract) to generate a corresponding configuration file (pg. 2), the configuration file in YAML or JSON format (pg. 2) and including configuration data and parameter obtained from the user input, the configuration file submitted to a container arrangement engine (pg. 8, 10) where the inputted configuration file serve to preset the container engine to initiate a new service (pg. 4); wherein a API is invoked to develop the cluster service of the frame defined with the configuration data (pg. 3). Hence, generating a configuration file including configuration parameters obtained via user interactions and preset configuration from a template for the configuration to be executed by a container arrangement engine whereby a clustered service of the developed frame part of the alliance chain can be set for distribution (claim 4 pg. 13). Hence, using settings and parametric guidance from a configuration file set to provide an user (or client device) with access to a feature of an Kubernetes development instance, the feature being a new clustered service and/or a container arrangement API is recognized
Therefore, as the microservice code generation in Dinh is geared to provide the user with access to the application feature (e.g. enterprise logic, web services, templates) for the application instance via the client device, in accordance with the request – as set forth in (*), it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement Dinh’s container-based code generating framework with capture/extraction of insights from repository legacy code and codebase so to form settings and parametric configuration into a file, so that the this configuration file is deployed as a means to provide users with access of one or more feature of the application development instance – as in LPengFei configuration file where the feature being given access to is a clustered service and/or a container arrangement API; because
cloud infrastructure customers or other users as part of the FaaS, CaaS and/or PaaS
offerings in Dinh (see para 0082-0083) are predestined to access provision of the infrastructure such as via development environment equipped with repositories by which the users can request a code build in accordance to the user specifications; and codebase source or legacy code specified by a requesting user when extracted and translated by an analyzer of a container environment – as set forth in Dinh DevOps - into parametric requirements and configuration insights in form of a configuration file which when made accessible to the user – as in LPengFei - can serve as feature or parameterization tool for the user to coordinate with the DevOps framework in parameterizing a container-based functionalities and implementing of the (server/service) logic that underly operations of the microservice instance, in the sense that insights on declared functions and parameterization required of operations or logic thereof intrinsically reflect or match with logic functionalities, programming types and code component contexts in the very codebase or legacy code selected by the user (from a repository) per his/her initial request for a microservice code to be generated by Dinh’s container-based DevOps framework
As per claim 2, Dinh does not explicitly disclose method of claim 1, further comprising:
receiving an additional request from an additional client device associated with an additional user of the platform for configuring the application feature for an additional application instance associated with the additional user;
obtaining additional configuration data associated with one or more settings pertaining to the additional application feature based on an additional interaction with the one or more elements of the electronic document by an additional user of the additional client device;
generating an additional configuration file for the additional application instance based on the additional configuration data provided by the additional user; and
providing, based on an execution of the generated/additional configuration file, the additional user with access to the application feature for the additional application instance via the additional client device.
The framework in Dinh belongs to PaaS, CaaS, FaaS aspect of the cloud-based infrastructure
that is founded and operates with one or more APIs as source framework(s) from which a given
microservice can be built from selectively imported code base, in the sense that development
instance of microservices can be made available to users (para 0027; infrastructure customers or
other users as part of the FaaS, CaaS or PaaS offerings - para 0083) per the same infrastructure
arrangement described for one tenant or client in requesting creation of microservices provided via
the PaaS, CaaS, FaaS aspect of the cloud-based infrastructure (see user device 102-1, 102-2, 102-3
102-M - in the microservices development platform 110 of Fig. 1), where one or more users can
access to the framework, provide configuration data interactively and retrieve resources mapped to or corresponding the elements of a source file and assemble them into a configuration file as set forth above in rationale A of claim 1.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective
filing date of the invention to implement network settings and external code base sources in Dinh's
infrastructure SO that the development framework thereof is designed to fulfill request for services or microservices build coming from the tenants or users of the PaaS, CaaS, FaaS aspect of the cloud-
based infrastructure, the framework capable of configuring the application feature for the additional application instance based on the electronic document and additional configuration data provided by the additional user; updating the corresponding configuration file associated with the application feature as well as additional configuration file for additional application instance per additional users, and providing the additional user with access to the configured application feature for the additional application instance based on execution of the updated configuration file - as set forth in rationale A from above - or execution of updated additional configuration file for access by the additional client device, and so, in response to an additional request from an additional client device associated with an additional user of the platform; because
provision of a development platform by which a common build model of framework is provided for distributed use by tenants or client users of a cloud architecture as in Dinh expressed as PaaS,CaaS, and FaaS coupled with arrangement of code base or pre-stored source code files in repositories forming available electronic documents maintained and accessible for the purpose of the development aspect by the architecture would fulfill the distributive aspect of said development platform model or paradigm, according to which more than one tenants or client devices would be able to request instance of a development based on which, the one or more users can import from the infrastructure or networked repositories codebase, access to the configured and generated application feature for a given additional application instance in accordance to the user intents of building a cloud application or a microservice code.
As per claim 3, Dinh does not explicitly disclose method of claim 2, further comprising;
detecting an update to the application feature;
in response to the detection, updating the configuration file associated with the application feature for the application instance at the client device and the additional configuration file associated with the application feature for the additional application instance at the additional client device; and
providing the user with access to the application feature for the application instance based on an execution of the updated configuration file and the additional user with access to the application feature based on an execution of the updated additional configuration file.
Dinh discloses injector engine implementing use of accelerator in conjunction with addition of reusable microservice components to auto scale continuous and delivery of the framework engine, the auto-scaler accelerator functionality adjusting resources or policies responsive to real-time change to resource utilization (para 0050) where externalized proprieties underlying the deployment processes or a running configurator accelerator may be subjected to runtime refreshing so that no downtime is discerned as part of configuration property change in real-time (para 0049); hence instant detecting an update to the application feature; and updating the configured application feature for the application instance at the client device or additional client devices (as per rationale of claim 2) is recognized - the detecting and auto-scale and continuous functionality update - referred to herein as (**).
The adaptive approach by Dinh framework to continually respond to additional requests and configuration data from various users in generating additional configuration, settings per additional users’ interaction with elements of source document, as well as generating update configuration files to each additional user request for a corresponding application instance, so that each additional user
can be provided access to corresponding application feature has been rendered obvious per the rationale in claim 2. Thus updating a configuration file in response to detected update to an application feature - as per (**) - would have been obvious.
Therefore, based on rationale of claim 2 in regard to responding to configuration request from additional users by Dinh framework infrastructure, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to implement the configuration framework of users using the microservice development platform with capability for instant detection of change and real-time update, in the sense that each framework would be capable to detect a real-time update to the application feature as set forth above in (**); and update the corresponding configuration file - per obviousness rationale from above - for feature of a given application instance requested per an additional client device, and/or for additional application instance(s) at the additional client devices in response to the detection; because
having runtime changes to configuration of a runtime development process on user devices being immediately reflected with update or refresh per a specific observation and designer context
would have for effect of synchronizing the latest view or rendering of configured data from the visualization prospect of the developer with the underlying programmatic, interactive inputs or parametric setting of the application model under build, enabling thereby full assessment of the latest changes by the developer in a real-time basis SO that additional actions or update to a underlying configuration file would enable updated configuration format to be passed to subsequent stages in accordance to continuous integration/delivery (CI/CD) approach of a PaaS, CaaS, FaaS of Dinh's infrastructure, the latter in form of a framework particularly designed to generate a CI/CD aspect of service application (e.g. microservice feature), provide distribution thereof to its requesting users by dynamically responding to requests or latest changes to the application feature by the users, implementing reconfiguration/update to the existing configuration of the intended application - e.g. updated configuration file generated in accordance thereto - and granting the one of more additional users with access- for execution as set forth in LPengFei - to their corresponding updated application (reconfiguration of a requested feature) so that a targeted service feature can be deployed/distributed (on basis of CI/CD) at the device of each additional user in accordance to this very PaaS, CaaS, FaaS paradigm of Dinh's infrastructure.
As per claim 4, Dinh discloses method of claim 1, wherein at least one setting of the one or more settings pertaining to the application feature is associated with an application resource
provided by another application (e.g. microservice accelerators provide single point of dependency
management to microservices dependency versions errors handling based on generator patterns,
standardization of error responses structures for web services, control over latency and failure
between distributed systems, monitoring application development frameworks at runtime, validating
health of third-party connections used in an application - para 0052) of the platform or another platform.
As per claim 7, Dinh discloses method of claim 1, wherein the client device is associated with an organization (user devices associated with a particular company, organization or other enterprise para 0026) and the application instance is running using one or more additional client devices (refer to rationale of claim 2) associated with the organization, and
wherein the method further comprises:
providing one or more additional users associated with the one or more additional client
devices (refer to rationale of claim 2 or claim 3) with access to the configured application feature
(see user device 102-1, 102-2, 102-3 102-M in the microservices development platform 110 of Fig.
1; para 0027) for the application instance via the one or more additional client devices (see rationale
in claim 2).
As per claim 8, Dinh discloses method of claim 1, wherein the application feature comprises at least one of
a notification-based feature (code related to alert/notification generation para 0047),
a messaging-based feature,
a storage-based feature (para 0022, 0037),
a data sharing-based feature,
a data collection-based feature (collection, distribution, - para 0055; logging component - para 0057),
a data visualization-based feature,
a user workflow-based feature (validation, deployment can be parts of a CD/CI pipeline where final version … is reviewed, stage and produced – para 0062),
a customer relationship management (CRM)-based feature (CRM, information management, - para 0053),
an accounting-based feature or
an auditing-based feature (e.g. compliance, para 0053).
As per claim 9, Dinh discloses a system comprising: a memory device; and a processing device coupled to the memory device to perform operations comprising:
receiving a request from a client device of a user of a platform for configuring an application feature, of a plurality of application features, for an instance of an application provided by the platform;
identifying, from a plurality of electronic documents each associated with a respective application feature of the plurality of application features, an electronic document associated with the application feature of the request,
wherein the electronic document comprises at least one of a spreadsheet document, an electronic form document, a word processing document, a web page document, or a slide presentation document;
providing the electronic document for presentation to the user, wherein the electronic document comprises a plurality of elements each associated with at least one of a function or a computing resource associated with the application feature,
each of the plurality of elements being mapped to one or more operations that, when executed, enable at least a portion of the application feature according to one or more settings;
obtaining configuration data associated with one or more settings pertaining to the application feature based on a user interaction with at least one element of the plurality of elements;
determining, based on the user interaction and from a source code file associated with the application feature, at least one operation mapped to the at least one element for inclusion in a configuration file for the application instance;
generating a configuration file for the application instance based on the configuration data and an operation mapped to the at least one element; and
providing, based on an execution of the generated configuration file, the user with access to the application feature for the application instance via the client device, in accordance with the request.
( All of which having been addressed in claim 1)
As per claim 10, refer to rationale of claim 2.
As per claim 11, refer to rejection of claim 3.
As per claim 12, refer to rejection of claim 4.
As per claim 15, refer to rejection of claim 7.
As per claim 16, Dinh discloses a non-transitory computer readable storage medium
comprising instructions for a server that, when executed by a processing device, cause the
processing device to perform operations comprising:
receiving a request from a client device of a user of a platform for configuring an
application feature, of a plurality of application features, for an instance of an application
provided by the platform;
identifying, from a plurality of electronic documents each associated with a respective application feature of the plurality of application features, an electronic document associated with the application feature of the request,
wherein the electronic document comprises at least one of a spreadsheet document, an electronic form document, a word processing document, a web page document, or a slide presentation document;
providing the electronic document for presentation to the user, wherein the electronic document comprises a plurality of elements each associated with at least one of a function or a computing resource associated with the application feature, each of the plurality of elements being mapped to one or more operations that, when executed, enable at least a portion of the application feature according to one or more settings;
obtaining configuration data associated with one or more settings pertaining to the application feature based on a user interaction with at least one element of the plurality of elements;
determining, based on the user interaction and from a source code file associated with the application feature, at least one operation mapped to the at least one element for inclusion in a configuration file for the application instance;
generating a configuration file for the application instance based on the configuration data and an operation mapped to the at least one element; and
providing the user with access to the application feature for the application instance via the client device based on an execution of the generated configuration file, in accordance with the request.
( All of which having been addressed in claim 1)
As per claim 17, refer to rationale of claim 2.
As per claim 18, refer to rationale of claim 3.
As per claim 21, Dinh does not explicitly disclose method of claim 1, further comprising:
detecting an update to a source code file associated with the application feature;
updating the configuration file associated with the application feature based on the
updated source code and the obtained configuration data; and
providing the user with continuous access to the application feature based on execution of the updated configuration file, without providing one or more re-configuration prompts to the client device associated with the user.
However, resources such as document source (configuration files, property files, source code
repositories, source code for maintaining application - para 0022) associated with the application feature (e.g. microservice code) intended by Dinh's framework responsive to user requests are based
on recognition of elements provided from templates by an adapter engine(e.g. codebase can be retrieved and converted to microservice code so that the microservice code can be retrieved and processed to be enhanced by the development platform - para 0037), where the template values are subjected to change (para 0046) which triggers continuous readaptation (CI/CD) by effect
of identifying other reusable microservice code retrieved remotely by way of injector and CI/CD
accelerator engine (injector 141, accelerator 142 - para 0048); hence state of configuration files
provided as electronic source document reflecting in different template values which in turn dictates
change in retrieval of microservice feature (microservice codebase, enterprise logic, legacy code) from a remote repository by an injector engine providing continuous integration/deployment is recognized.
Therefore, as change in application feature reflected in variability of template content can
trigger change in retrieval of microservice code or snippets, it entails that configuration of a target
application in CI/CD approach in Dinh is to be readapted by virtue of obviousness, responsive to
detecting an update to a source code file associated with the application feature - referred herein as
(***).
Thus, based obviousness of generating a configuration file from update to application data,
variation in source files, or user changes made to configuration of target application feature, it would
have been obvious for one of ordinary skill in the art before the effective filing date of the invention
to implement injector and CI/CD accelerator engine in Dinh system, SO that these engines would be
configured with capabilities for
detecting an update to a source code file associated with the application feature;
updating the configuration file - per rationale in claim 3 associated with the application
feature based on the updated source code as per (***) from above - and the obtained configuration
data; and
providing the user with continuous access - as per the obviousness set in rationale B in claim
1 - to the application feature based on execution of the updated configuration file - see rationale of
claim 3 -, without providing one or more re-configuration prompts to the client device associated
with the user, using the automated provision of injector and CI/CD accelerator engine; because
of the same reasons set forth with rationale B in claim 1, and those set with obviousness
rationale of claim 3.
As per claim 22, Dinh discloses method of claim 1, wherein the electronic document further comprises a check resources function element (see below), and wherein the method further comprises:
responsive to detecting a user interaction (CLI 508 specify a click - para 0063; click of a mouse - para 0095; tool URL user to select and downloading the microservice code – para 0067) with the check resources function element (see validating from below, auto-scaler accelerator 144 para 0050; validating config properties in a user interface dashboard para 0052; accelerator
145 functionality for security protocol user authentication para 0050; validating - para 0087- 0088; validation engine 560 - para 0066),
initiating execution of one or more commands (e.g. para 0087, 0088; input code can be analyzed and validated - para 0066; validating - para 0052) associated with checking a state of one or more underlying resources (e.g. number of codebases, dependencies, location of one or more configurations, backing services; log are produced load testing, a quality of the generated microservice code - para 0087-0088; microservice code – para 0066 ) of the application feature; and
updating the electronic document (property refreshing so that there is little or no downtime
for configuration property changes - para 0049; templates may be used as is or modified during
code development process to change values in the templates - para 0046; options for committing;
generating a commit into a software development adding microservice components via the injector engine 141 - para 0068-0069) to include an indication of the state of the one or more underlying resources (e.g. para 0046-0048 – Note4: use of CI/CD accelerator coupled with
microcode validator, injector engine - para 0069 - in association with auto-scaler actions and
retrieval of snippets from microservice repository based on values adjust made to template during
the process of building the code or associated commit/review processes in the context of accepting or finalizing microservice code reads on updating source document elements, using validating commands as part of resources adjusting to include state indication of one or more underlying resources in accordance to an overall CI/CD accelerator process that validates, updates and commits ingestion of accepted code into a microservice codebase).
As per claim 23, Dinh discloses method of claim 1, wherein the at least one element (screenshot/options - Fig. 6) comprises an enabled field (field to enter a software development tool URL, service name – para 0067), wherein obtaining the configuration data comprises obtaining, based on the user interaction (user to select options to commit into … DevOps – para 0067), a value of the enabled field (e.g. URL, ESB name) indicating whether a computing resource (downloading … the microservice code as zip file – para 0067; retrieving input code … to deployment of the microservice code – para 0066) associated with the at least one element (screenshot/options - Fig. 6) is enabled for the application feature (user to select – par 0067), and wherein the determining of the at least one operation for inclusion (refer to Note2 in claim 1) in the configuration file is based on the value of the enabled field (refer to field enabled per user select … to download – para 0067).
As per claim 24, Dinh discloses method of claim 21, wherein the update to the source code file modifies the at least one operation (refer to claim 1) mapped to the at least one element (refer to claim 1), wherein updating the configuration file (refer to rationale of claim 3; editing XML configuration files – para 0043) comprises
retrieving the configuration data (accelerator 142 automates building and deployment … accelerator 142 implements functionality … use of deployment descriptors – para 0049) stored at the platform and regenerating the configuration file (configuration accelerator externalizes properties and provides for automatic refreshing – para 0049) based on (editing – para 0043) the modified at least one operation (components, modules – para 0049) and the retrieved configuration data(deployment descriptors – para 0049), and wherein the configuration file (files 125 – para 0045-0046) is regenerated (see refreshing from above) without an additional user interaction (automatic refreshing – para 0049) with the at least one element (deployment descriptors, properties – para 0049) of the electronic document (refer to claim 1).
Claims 6, 14 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Dinh et al, USPubN: 2021/0132935 (herein Dinh) in view of Li, Peng-Fei, CN 110704099 (translation) 04-22-2021, 14 pgs (herein LPengFei)further in view of Zhao et al, USPubN: 2021/0141637 (herein Zhao) and Cardenas, USPubN: 2022/0300340 (herein Cardenas)
As per claim 6, Dinh does not explicitly disclose method of claim 1, wherein
the source code file comprises one or more placeholder values that reference configuration data items, and wherein generating the configuration file for the application instance comprises:
obtaining a copy of the source code file including the operation and the one or more placeholder values; modifying the copy of the source code file to replace at least one of the one or more placeholder values with a configuration data item of the obtained configuration data.
Dinh discloses generation of microservice code from configuration files as including provision of placeholders inside the microservice code for inserting accelerator code (para 0089; claim 10, pg. 10) from external service support for the microservice code, the placeholder mechanism to add a measure of security to implementation of the accelerators SW.
Provision of external code template in support for runtime configuration of a webpage of online application is shown in Zhao; where a template language provided as one form of descriptive or text resource for configuring a user requested (target) webpage includes static elements redacted with placeholders at their respective locations inside the language, so that the placeholder values are replaced by data from online store when a theme is installed at compilation time of the requested webpage for the customer device (para 0035) to minimize exposure of the online commerce to infringement over privacy and security of the online e-commerce participants (para 0064)
Cardenas discloses a variable-based deployment of cloud-based environments according to a
infrastructure-as-code configuration approach based on variable-loaded templates (Fig. 5) for continuous integration/deployment (see Abstract; para 0016-0020) with provision of the cloud computing environment (data store 112, repository 114 - Fig. 1) to provision for the laC configuration file or execution thereof from the cloud provisioning SW(Fig. 1, 5) using security policies and protocols associated the IaC provisioning (para 0018-0019, para 0034), where one or more non-variable-loaded templates initially retrieved from a data store of IaC configuration data (para 0021-0022) comprise each placeholders therein so that variable-loaded the template(s) replaces the placeholder variables (hashtag value) in each template with a corresponding variable data from the environment configuration (para 0023) or from a repository; hence retrieval of template code having placeholder values therein into a config environment so that the placeholders can be replaced with either current environment configuration data or data from previously stored in repository of production environment (para 0024) is recognized.
Therefore, based on a framework configuration instance in which instances of source file or
code base can be retrieved from external source in Dinh and use of accelerator code placeholders to
impart an additional measure of security, it would have been obvious for one of ordinary skill in the
art before the effective filing date of the invention to implement instances of configuring operations
or functions derived - see Li's interaction method and Tob's cloud-service function from rationale A
in claim I - from the imported source file(s) and creating configuration data as part of generating the
targeted microservice code or application feature in Dinh,
so that the obtained source files
(1) would comprise each one or more placeholder values that are configured to reference external configuration data items - as per Zhao and Cardenas - in that the process of generating the configuration file for executing the application feature (based on one or more operations and obtained configuration data) would include
(2) obtaining a copy of the source code file including the one or more operations and the one
or more placeholder values - as per Zhao and Cardenas;
(3) modifying the copy of source code file to replace at least one of the one or more placeholder values with a configuration data item of the obtained configuration data - as shown in Zhao or Cardenas substituting of template placeholder value with corresponding data from a
repository thereof from above; because
the instrumental effect of transferring of source file maintained by and stored in the architectural storage services into a microservice code or application feature framework of Dinh, constitutes possibility of communicated data being corrupted (or tampered with) in the course of the transfer and to overcome this vulnerability exposure, provision of placeholder values in the very content (source file or code base or template) being transferred as set forth above would provide an added layer of security which requires a deferred runtime substitution mechanism only after transfer is completed, thereby hiding actual information intended for the framework use from external or undesirable malicious entities, ensuring thereby that configuration data and operations formed from the acquired source file, template, code base entities are protected from any incursion of vulnerability attacks, that state of their being imported and configured would remain compliant with integrity/vulnerability check requirements in course of the code integration and generation by Dinh's framework.
As per claim 14, refer to rationale of claim 6.
Response to Arguments
Applicant's arguments filed 8/12/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) The Applicant has submitted that by dissecting the claim per isolated verbs by the Office Action for the 101 rejection and not considering a SW implementation in claim 1 regarding a feature recited as determination from user interaction and source code, from elements of maintained electronic document, one operation mapped to at least one element for inclusion into a configuration file, the Abstract Idea rejection fails to establish eligibility evaluation under the Alice steps, notably when the claim requires relationships with a computer to operate on an electronic document, mapped operations and executed configuration files to configure a application feature of a application instance. (Applicant's Remarks, pg. 14, top pg. 15). The execution of a configuration file exactly as claimed only provides user with access to a feature of the application instance, and the mapped operations as claimed does not evidence use of a programmatic engine to perform a mapping via a computer, nor does the claim describe identifying one electronic document for elements and application features with HW support of a computer device, when in fact most of the description of “identifying”, “determining” limitations is expressed in a very high level of generality. For instance, determining an operation mapped to a element (of a document and associated feature) can be construed as visualization-based analysis combined with mental mapping by a human being.
(B) The Applicant has submitted that the current Specifications has explained how overall efficiency in computing resources has been achieved, via customizing features for the users with minimized latency in maintaining application; and that nothing in the step 2B analysis by the Office action clearly establishes via factual demonstration that determining from a source code the operations mapped to elements of a electronic document is prevalent, well-understood routine (Applicant's Remarks pg. 15 to pg. 16). The language depicting the “operations mapped to elements” of document has been construed as a mere observation and mental mapping, absent sufficient details in the claim to tie this operation with memory setting, and CPU circuitry of a computer. The allegation that step 2B analysis is deficient is deemed largely non-persuasive.
( C ) The Applicant has submitted that Dinh is silent regarding “obtaining configuration data associated with … settings … application feature based on …user interaction …”, “determining based on user interaction and source code … one operation mapped to at least one element for intrusion in a configuration file …”, and “generating a configuration file … based on configuration data and an operation mapped to the at least one element” (Applicant's Remarks pg. 18). Reliance on a newly added limitation to proffer patentability merits of a claim cannot be deemed a compliant case of rebut as no prima facie case rejection has been presented regarding the state of the added limitations.
( D) The Applicant has submitted that neither Tob, Li-Feng nor LPengFei is seen as remedying to the deficiencies by Ding in regard to the above limitations now included with claim 1 (Applicant's Remarks pg. 18 bottom to pg. 21). The grounds of rejection have been altered to meet the newly introduced limitations and any allegation of Tob, Li-Feng and LPengFei would be deemed largely moot in view of the changes in the rejection that have been necessitated by the Amendment.
In all, the claims submitted in the latest amendment will stand rejected.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 Tuan A Vu whose telephone number is (571) 272-3735. The examiner can normally be reached on 8AM-4:30PM/Mon-Fri.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Chat Do can be reached on (571)272-3721.
The fax phone number for the organization where this application or proceeding is assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before using) or 571-273-8300 ( for official correspondence) or redirected to customer service at 571-272-3609.
Any inquiry of a general nature or relating to the status of this application should be directed to the TC 2100 Group receptionist: 571-272-2100.
/Tuan A Vu/
Primary Examiner, Art Unit 2193
Octobre 8, 2026
