DETAILED ACTION
This action is responsive to the Applicant’s response filed 3/20/26.
As indicated in Applicant’s response, claims 1-3, 5-6, 9-11, 13-14, 16-18 have been amended, claims 19-20 cancelled and claims 21-22 added. Claims 1-18, 21-22 are pending a next office action.
Claim Objections
Claim 22 is objected to because of the following informalities: the phrase recited as “the electronic document comprises is a check resources function element” includes a double verb grouping impropriety. Appropriate correction to what appears to be a typo error is recommended.
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 I:
The claim is directed to a process category.
Step IIA:
Prong One:
The elements recited as “identifying … an electronic document … each comprising elements … to configure settings pertaining … application feature” and “generating … configuration file comprising … data obtained based on user interaction” 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 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 … document for presentation”, “obtaining configuration data … with settings pertaining to the … feature based on user interaction … user interaction with a document” and “providing … user access … to the feature” (based on generated configuration file) amount to extra-solution activities that precede the Abstract Idea of Step IIA or post-activities that rely of result of 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 using 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 all, these typical steps or well-understood routines fall under the ambit of a mental process sequence that acquires information, performs identification and generates pen/paper data for distributing/providing its access to other recipients. As such, 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 express a significant computer-based improvement or transformation to this identification scenario. See MPEP 2106.05 (a), (b), (c), (g)
Step IIB:
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 as mere pre-activity actions to acquire data (feature, element, settings, document) for step IIA Abstract Idea of identifying or generating (a file) or post-activity actions that use 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 therefore deemed non-eligible 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.
A. Eligibility of claim 9
Step I: this claim is directed to an apparatus/system category.
Step IIA:
Prong One:
Claim 9 recites elements recited as “identifying … an electronic document … each comprising elements … to configure settings pertaining … application feature” and “generating … configuration file comprising … data obtained based on user interaction”; and these activities are construed, absent any specific details to teach otherwise, as mere activities that can be carried out by a human mind or use of pen/paper (to generate a written file) - MPEP 2106.04(a)(2) (II) or (III). The claim is directed to the mental process under the Abstract Idea grouping by the courts.
Prong Two:
The elements recited as “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” are construed either as a extra-solution pre-activity or post-activity to the Abstract Idea, and as these elements are same to claim 1 as set forth above, these extra-solution activities The elements recited as “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” are construed either as a extra-solution pre-activity or post-activity to the Abstract Idea, and as these elements are same to claim 1 as set forth above, these extra-solution activities constitute well-understood routines (receiving, providing) and cannot integrate the Abstract Idea into a Practical Application. MPEP 2106.05 (a), (b), (c), (g)
Step IIB:
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 being 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 viewed 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)
B. Eligibility of claim 16.
Step I:
Claim 16 is directed to a product/medium category
Step IIA:
Prong One:
Claim 16 includes “identifying … an electronic document … each comprising elements … to configure settings pertaining … application feature” and “generating … configuration file comprising … data obtained based on user interaction”; and these activities are construed, absent any specific details to teach otherwise, as mere activities that can be carried out by a human mind or use of pen/paper. Claim 16 is directed to mental process pertinent to an Abstract Idea grouping by the courts. MPEP 2106.04(a) (II) and (III)
Prong Two:
The elements in claim 16 recited as “receiving a request … for configuring a … feature” , “providing … document for presentation”, “obtaining configuration data … with settings pertaining to the … feature based on user interaction” and “providing … user access … to the feature” are construed either as an extra-solution pre-activity or post-activity to the Abstract Idea, and as these elements are same as those in claim 1 as set forth above, these extra-solution activities constitute well-understood routines (receiving, providing) and cannot integrate the Abstract Idea into a Practical Application. MPEP 2106.05 (a), (b), (c), (g)
Step IIB:
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, the elements are well-understood activities that precede or follow a mental process typical to a scenario of obtaining information via a computer, making mental derivation and dispatching result from the mental process, and as such, the additional elements fail to add significantly more to the Abstract Idea. MPEP 2106.05 (a), (b), (c), (g)
Step IIB 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 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 describe operations of claims 5 or 13 as including source code comprising placeholder and obtaining and modifying a copy of such source code to replace the placeholder content; but these operations are not tied to the “configuration file” associated with Abstract Idea of the base claim, but rather depict an extra-solution step otherwise viewed as insignificant toward transforming the Abstract idea into a more inventive computer technique within a document processing field.
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.
In all, claims 1-18, 21-22 are deemed all non-eligible 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-5, 7-13, 15-18, 21-22 is/are rejected under § 35 U.S.C. 103 as being unpatentable over Dinh et al, USPubN: 2021/0132935 (herein Dinh) in view of Tob SH, CN 105144088, 09-04-2018, 22 pgs. (herein Tob) and Li, Ze-feng, CN 114840321, (translation) 08-22-2022, 16 pgs. (herein Li-Feng) further 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 of a platform for configuring an application feature (microservice code requests may be entered through a user interface of the user device connected to the network - para 0038; collection of services which execute different features of an application - para 0023), of a plurality of application features (microservices - para 0093; microservice code for deployment on one or more cloud computing platforms - para 00067- 0007; para 0009-0011; plurality of microservices - para 0057), for an instance of an application provided by the platform;
identifying, from a plurality of electronic documents(codebase repositories, codebase sources 103 - para 0033), an electronic document (e.g. source code in connection with building application, configuration files, property files, source code repositories, source code for maintaining application - para 0022; clicks on a codebase SO that a codebase from the specified location can be converted to microservice for deployment on a cloud platform - para 0063; select the codebase location for the desired codebase to be converted - para 0095; UI 502, code base location orchestration service 580 Parsing service 590, microservice generator 530 - Fig. 5; number of codebases for a plurality of microservices - para 0057; "CONFIG" files - para 0045; JSON schema, ESB parsing service, ESB code base - para 0065) associated with the application feature of the request (see above);
wherein a document of the plurality of electronic documents is associated with a respective application feature (e.g. codebase component for determining whether there is one codebase for each deployed service - para 0057) of the plurality of application features (e.g. error handling, control over latency, monitoring, validating the health, validating config, error analytics, backend services, CRM, information management, compliance, B2B integration, enterprise integration patterns, collection, distribution, pattern recognition - para 0052-0055; generating, testing and deploying - para 0056; logging component - para 0057; CI/CD, configuration accelerator, testing framework, logging framework accelerator - para 0048), and
wherein each of the plurality of electronic documents (("CONFIG" files - para 0045; JSON schema, ESB parsing service, ESB code base - para 0065; source code in connection with building application, configuration files, property files, source code repositories, source code for maintaining application - para 0022) comprises elements (configuration properties - para 0043; source code, configuration files, property files - para 0022; plurality of configuration properties 1104, generate configuration files from the extracted properties 1106 - Fig. 11; configuration generated from the extracted configuration properties - para 0007) that enable users to configure settings (parsing service decodes the ESB codebase generates a configuration file which includes logic to generate microservice code - para 0065; step 1106 Fig. 11) pertaining to a respective application feature (see above; para 0052-0055, 0048, 0057),
wherein the electronic document comprises at least one of a spreadsheet document, an electronic form document (JSON schema - para 0065-0067; pseudocode 700 for providing JSON properties - para 0068; XML configuration files, extractor to extract configuration properties – para 0043), a word processing document, a web page document (XML configuration files – para 0043; JSON, XML configuration files YAML, markup language – para 0045), or a slide presentation document;
providing the electronic document for presentation to the user (e.g. para 0095; Fig. 5 and related text; user interface or CLI can specify or click code from a source code can be retrieved and processed - para 0063; interface for selecting code for conversion user to select options – para 0067; Fig. 6; para 0014);
obtaining configuration data (para 0045; see templates, placeholders, snippets, objects refined in Java code from below) associated with one or more settings (e.g. include parameters that define settings for building programs, applications - para 0045; templates, code snippets, placeholder, accelerators - para 0089; endpoints may include a URL of service or locations from which APIs can access resources - para 0041; replacement assign values to variables, modify the structure of a payload, combinations of transformations and assignments para 0047; code templates used as is, or modified during the development process para 0046; templates used for referencing objects refined in Java code - para 0042; para 0068-0069) pertaining to the application feature (e.g. a microservice) based on a user interaction with one or more elements (e.g. modify the structure of a payload, combinations of transformations and assignments - para 0047; e.g. click on a codebase location - para 0037; user CLI - para 0038; para 0063; development tool URL, user to select options … downloading … generated microservice code – para 0067) of the electronic document (see above);
configuring the application feature (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) based on the user interaction with the one or more elements (e.g. click on a codebase location - para 0037; user CLI - para 0038; CLI … click on a location – para 0063; Fig. 6, para 0014; development tool URL, user to select options … downloading … generated microservice code – para 0067) of the electronic document (see above); and
providing, the user with access to the configured application feature (configured to generate vendor independent microservice code for deployment on multiple cloud platforms - para 0070; distributed components implemented on respective ones of a plurality of compute nodes - para 0079; offered to cloud infrastructure customers or other users as part of the FaaS, CaaS and/or PaaS offerings – para 0082-0083) for the application instance via the client device, in accordance with the request (para 0038).
A) Dinh does not explicitly disclose
wherein each of the plurality of electronic documents is associated with a respective application feature of the plurality of features.
Dinh discloses extracting configuration properties from the input code or codebase files (para
0022), determining granularity of the service in the code and determining at least one logic, endpoints, data source, messaging queues, webservice and templates in the code, the configuration data for a given feature (microservice code … can be retrieved and processed to be enhanced by the … development platform – para 0037) derived from user interaction (click on a codebase location - para 0037; user CLI - para 0038; CLI … click on a location – para 0063; Fig. 6, para 0014; development tool URL, user to select options– para 0067) with a electronic document feature. Hence, user interactions and extracted properties in code base based thereon, when granularly analyzed in correspondence with a service or application feature enable identification of an service aspect or application feature such as messaging, data sourcing, logging, service endpoints feature; that is, each of the plurality of codebase file in terms of electronic document being associated for use with one application feature or a targeted microservice is recognized.
Tob discloses metadata and corresponding source code being stored in respective repositories serving a code base to provide SW developers with information to develop code in the granularity desired for developing tasks or services (pg. 2, 6), where via parsing one or more non-structured or structured metadata entities, source code entities linked thereto can be identified and retrieved from repository or database (pg. 7) into a IDE such as for source code editing, debugging or testing (pg. 4, 8), where granular elements of a given source code entity can be integrated (pasted) into an existing source code of a development (pg. 9) via interaction between the developers and backend servers as part of SW development in providing basis structure of the service or replacing a function provided under the cloud-service (pg. 10); e.g. including a scene of developer interaction in which source code is being subjected to creation, deletion, modification triggering update of a corresponding source code or metadata in the repository (pg. 11); hence identification of metadata corresponding source code to extract granular guidance therefrom to retrieve one or more associated source code entities from storage to implement or edit action code in developing or replacing a cloud-service as in Tob entails source code entities being available to correspond to an application feature such as developing or replacing a cloud-service.
Li-Feng discloses obtaining relationship between plurality of code files stored in library and data tables identified per a target application for establishing call relationships with which to implement method calling of a target application (see Abstract), so to improve accuracy of code calling for the target application (pg. 2), using a process including determining the target application, preprocessing initial field information and linking it to the database by which to retrieve one or more corresponding data tables for a given interaction name (interaction method) and call relation information thereof, selecting an interaction name and retrieving from a library the proper code files that also match name on the identified data table (pg. 3), the retrieval including code indicating the interaction method, and code indicating the calling relation between any two interaction methods found in the same table or different tables (pg. 4); hence retrieval of code files that each corresponds to a particular interaction method or relationship between two methods of a target application as in Li-Feng entails code files being available each to correspond to a feature such as interaction method of a target application.
Therefore, based on possibility that an application feature can encompass a variety of types
of implementation varying from actions, tasks or interaction method, single or group functionalities
for a target application or service, it would have been obvious for one of ordinary skill in the art
before the effective filing date of the invention to implement use of prestored source code or base
code as plurality of electronic documents so that each of such electronic document is or can be
associated with a respective application feature as set forth above in Li-Feng and Tob; so that using code base associated metadata, developers of a application development environment would be able to identify one or more pertinent electronic documents or code files from repository and integrating the retrieved file(s) into a certain aspect of the development such as specific feature of a network PaaS or SaaS as set forth in Dinh; because
associating metadata with prestored base document or code files provided from external
storage in electronic format for easy transfer, retrieval or import into a development environment
such as in Dinh's system, would facilitate preliminary filtering of source code files for use into the
development context, per effect of coupling setting information, granular definition identified from
parsing the metadata as set forth above with a given code base or code file, in accordance to which,
the most appropriate code base entities or code files befitting a implementation aspect can be
retrieved from remote, as file or source document imported into a early development stage as raw
code instance which (a) not only best suit granular code calling and functional interaction required
for a particular type of feature or network service targeted in Dinh microservices generating
infrastructure, but (b) would also enable developers to impart additional modification, re-adaptation,
parametric augmentation thereto in the course of the interactive steps of the development process,
thereby (c) optimizing a given development of a cloud or application feature in that less deployment
and research effort by developer for source code is being spent, and activities scope of a developer is
being significantly reduced or compacted to a mere interactive mode typical of a very efficient low-
code form of development.
Dinh does not explicitly disclose configuring the application feature and providing user access to the application feature in terms of
generating a configuration file for the application instance, the configuration file comprising the configuration data obtained based on the user interaction with the one or more elements of the electronic document; 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.
Dinh discloses configuration data being driven in part from user interaction (click on a codebase location - para 0037; user CLI - para 0038; para 0063; development tool URL, user to select options … downloading … generated microservice code – para 0067) with the elements (templates, code snippets, placeholder, accelerators - para 0089; endpoints may include a URL of service or locations from which APIs can access resources - para 0041; development tool URL, user to select options … downloading … generated microservice code – para 0067) pertaining to a document source (configuration files, property files, source code repositories, source code for maintaining application - para 0022) associated with the application feature (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) recognized per the user request (e.g. microservice code requests may be entered through a user interface of the user device connected to the network - para 0038; collection of services which execute different features of an application - para 0023).
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) 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) to subscribers is recognized.
Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to use user interactions and templates and configuration data based thereon in Dinh’s approach so that the configuration data thus obtained can be formatted in a file form -such as a configuration file per LPengFei – the configuration file comprising the configuration data obtained based on the user interaction with the one or more elements of the electronic document, which upon being executed, enable the user with access to the configured application feature for the application instance – as per the service cluster distribution in LPengFei - via the client device in accordance with the request; because
configuration consolidated as a file – as set forth above - can be made portable and editable as needed, notably when the configuration collected therein basically contains input from user interaction, distribution settings and template data which are susceptible to further changes, whereas in such format, a configuration file can be passed to a subsequent processing stage – a container arrangement engine as in LPengFei - by which the feature according the configuration data, or service intended by a user/subscriber request can be generated into a distributable application for access and use by subscribers of the service.
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 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 more than one users can access to the framework, provide configuration data interactively and retrieve resources corresponding the elements of a source file and assemble them into a configuration file as set forth above in rationale B 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 B 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 herein as (**).
The adaptive approach by Dinh framework to continually respond to additional request 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 5, Dinh discloses method of claim 1, wherein each element of the electronic document is mapped to one or more operations (refer to rationale A of claim 1 in conjunction with a imported source file per Tob, for mapping file element with provision of a structure of the service or replacing a function provided under the cloud-service; per Li-Feng in mapping file element with given interaction name - interaction method - and call relation information thereof) that, when executed, enable at least a portion of the application feature according to at least one setting pertaining to the application feature.
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, (repository code related to alert/notification generation
para 0047),
a messaging-based feature,
a storage-based feature,
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,
a customer relationship management-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, an electronic document associated with the application feature of the request,
wherein each of the plurality of electronic documents is associated with a respective application feature of the plurality of application features, and
wherein each of the plurality of electronic documents comprises elements that enable users to configure settings pertaining to a respective application feature,
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;
obtaining configuration data associated with one or more settings pertaining to the application feature based on a user interaction with one or more elements of the electronic document;
generating a configuration file for the application instance, the configuration file comprising the configuration data obtained based on the user interaction with the one or more elements of the electronic document; 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.
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 13, refer to rejection of claim 5.
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, an electronic document associated with the application feature of the request,
wherein each of the plurality of electronic documents is associated with a respective application feature of the plurality of application features, and
wherein each of the plurality of electronic documents comprises elements that enable users to configure settings pertaining to a respective application feature,
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;
obtaining configuration data associated with one or more settings pertaining to the application feature based on a user interaction with one or more elements of the electronic document;
generating a configuration file for the application instance, the configuration file comprising the configuration data obtained based on the user interaction with the one or more elements of the electronic document configuring the application feature for the application instance based on the electronic document and the obtained configuration data; and
providing the user with access to the configured 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.
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(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 code) from a remote repository by an injector engine providing CI/CD adaptation 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 is [sic] 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 - Note1: 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 processes in regard to accepting retrieved 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).
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 Tob SH, CN 105144088, 09-04-2018, 22 pgs. (herein Tob) and Li, Ze-feng, CN 114840321, (translation) 08-22-2022, 16 pgs. (herein Li-Feng) further 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 discloses method of claim 5, wherein the one or more operations are included in a source code file (refer to claim 1) associated with the application feature,
Dinh does not explicitly disclose
the source code file comprising 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 one or more operations 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 "variabilized" 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 IaC
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-variabilized templates initially retrieved from a data store of IaC configuration data (para
0021-0022) comprise each placeholders therein so that variabilizing 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 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 perform
(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
provision of placeholder values in the very content (source file or code base or template)
being transferred as set forth above would provide a 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 3/20/26 have been fully considered but they are not persuasive. Following are the Examiner’s observations in regard thereto.
(A) Applicants have submitted that the newly added limitations associated with generating configuration files, and providing access thereto to the user is not disclosed in Dinh use of codebase, notably when the “configuration file” comprise data obtained from “user interaction with one or more elements of the electronic document” as claimed; nor is there teaching by Dinh in regard to “proving the user with access to the application feature”, based on “execution of the generated configuration file” (Applicants Remarks pg. 12)
The added limitation has been addressed with one or more adjusted grounds of rejection, rendering the allegation by the Applicant largely misplaced.
(B) Applicants have submitted that Li as far as processing a “calling relation” does no remedy to the deficiency by Dinh concerning the generating of configuration file and providing access thereof to user from above (Applicants Remarks pg. 12, bottom); nor does Tob use of metadata associated source code, which is considered silent with respect to generating of configuration file and providing access thereof to user from above (Applicants Remarks pg. 13)
The added limitation or limitations have been addressed with one or more adjusted grounds of rejection, rendering the allegation by the Applicant largely misplaced.
( C ) Applicants have submitted that in view of the deficiency by Dinh, Li, and Tob, claim 6 and 14 in view of Zhao, and Cardenas are patentable as these claims depend from claim 1, 9 from above.
The Applicants’ allegation on merits of claims 6, 14 on basis of Dinh, Li, Tob not meeting claim 1 appears to rely heavily on state of a prior prosecution rendered to address Applicant’s claims provided prior to the current Amendment; hence cannot be construed as a valid prima facie case of rebut.
In all, the submitted claims amendment stand rejected as set forth above.
Conclusion
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
May 10, 2026
Prosecution Insights