Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1, 4-5, 7-8, 11-12, 14-15, 18, and 20-21 are presented for examination.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4-5, 7-8, 11-12, 14-15, 18, and 20-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Smit (US 20140351684 A1) in view of McMahon (US 20140289702 A1) further in view of Laskey (US 9,841,953).
Regarding Claim 1, Smit (US 20140351684 A1) teaches
A method for generating an application configuration for a native development environment, the method comprising:
i. receiving a non-native configuration file in a non-native application development environment, wherein the non-native configuration file includes information for configuring program code to be compiled into a native computer application; (Para 0047, "A user at a client device 102 views and/or modifies data from a plurality of different data sources 108 via an interactive electronic form. An example block diagram showing connections between a plurality of data sources 108 and an electronic form 302 via an object broker process 304 is illustrated in FIG. 3. The object broker process 304 (described in detail below with reference to FIG. 6) compiles data in a variety of different native formats from the different data sources 108 (e.g., different legacy database systems) into standardized business objects 306, 308 (e.g., in a declarative format such as XML)") Examiner Comments: This passage teaches receiving a non-native configuration file (data compiled into XML business objects from legacy sources) in a non-native application development environment (object broker process and form-based tooling), where the file includes information for configuring program code to be compiled into a native computer application (business objects/forms used to generate and configure native mobile apps). The object broker receives and compiles non-native data into configurations usable for native app generation.
ii. generating, [within the non-native application development environment], a native configuration file for a native application development environment based on the non-native configuration file, [wherein the native configuration file is generated from a template native configuration file which is sequentially modified by chaining together the modifier objects of the non-native plugin]; (Para 0014, "The disclosed system also generates native mobile applications that can be executed on mobile operating systems. The mobile applications contain the full feature set of a form that may be run, for example, on a desktop computer.") Examiner Comments: This passage teaches generating a native configuration file (native mobile app configuration with full form features) within the non-native environment (form process and object broker) based on the non-native configuration file (standardized business objects and forms). The system generates native configurations directly from non-native forms within the same environment.
v. performing a compilation process, using the native configuration file, to produce the native computer application to be run in a native environment. (Para 0014, "The disclosed system also generates native mobile applications that can be executed on mobile operating systems. The mobile applications contain the full feature set of a form that may be run, for example, on a desktop computer.") Examiner Comments: This passage teaches performing a compilation process (generating executable native mobile applications implies compilation from source/configs to binaries) using the native configuration file (form features in native configs) to produce the native computer application to be run in a native environment (executable mobile apps running on mobile operating systems). Producing executable native apps from configurations inherently involves compilation to make them runnable on OS.
Smit did not specifically teach
generating, within the non-native development environment,
iii. updating at least one of the non-native configuration files;
iv. dynamically repeating the generating on the fly in response to the updating
wherein the non-native configuration file includes a non-native plugin that contains modifier objects corresponding to the native development environment; and
wherein the native configuration file is generated from a template native configuration file which is sequentially modified by chaining together the modifier objects of the non-native plugin.
However, McMahon teaches
generating, within the non-native development environment (claim 1, based on the received data, updating the specification data; and triggering an automated build to update some or all components of the data service using the specification data as updated) Examiner Comments: This passage teaches generating/updating application components (native configs via automated build) within a non-native environment based on received/edited configurations (specification data), directly mapping to the generation step by automating the creation of service components from non-native specs.
iii. updating at least one of the non-native configuration files; (Claim 1, "receiving data representing an edited version of the portion of specification data in the second structured markup file format; based on the received data, updating the specification data;") Examiner Comments: This passage teaches updating at least one of the non-native configuration files (editing and updating specification data files); McMahon directly describes modifying non-native specs as part of an iterative development process.
iv. dynamically repeating the generating on the fly in response to the updating; (Claim 1, "and triggering an automated build to update some or all components of the data service using the specification data as updated.") Examiner Comments: This passage teaches dynamically repeating the generating on the fly in response to the updating (triggering automated build to regenerate components immediately upon spec update); The build is an on-the-fly automated response to configuration changes.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Smit’s teaching to McMahon’s in order to enhance development workflows by allowing users to directly edit and regenerate components in a user-friendly manner, reducing the need for manual reconfiguration, which this editing ability may lead to improved workflows whereby development personnel may have more direct access to portions of the API specification and may readily see the results of their efforts (McMahon, [abstract], [summary]).
Smit and McMahon did not specifically teach
wherein the non-native configuration file includes a non-native plugin that contains modifier objects corresponding to the native development environment; and
wherein the native configuration file is generated from a template native configuration file which is sequentially modified by chaining together the modifier objects of the non-native plugin.
However, Laskey (US 9,841,953 B2) teaches
wherein the non-native configuration file includes a non-native plugin that contains modifier objects corresponding to the native development environment (Claim 1, "applying a plurality of pluggable transforms to a plurality of states of the set of files to produce a particular subsequent state of the set of files … selecting an image builder from a set of pluggable image builders based on at least a target software environment on which the runtime-image will execute"; Col. 1, Lines 48-67 [summary], " The system then applies a plurality of pluggable transforms to a plurality of states of the set of files to produce a particular subsequent state of the set of files. In some embodiments, applying the plurality of pluggable transforms to the plurality of states of the set of files includes:(i) applying a particular pluggable transform to modify the intermediate code file into a particular transitional state of the intermediate code file; and (ii) applying one or more subsequent pluggable transforms to modify the particular transitional state of the intermediate code file into one or more other transitional states of the intermediate code file. The system then produces a runtime-image of the software program from at least the particular subsequent state of the set of files, the runtime-image including one or more files for execution by a virtual machine and one or more output resources to be accessed by the one or more executed files.") Examiner Comments: This passage teaches non-native configuration data that includes pluggable transforms (“modifier objects”) that are specific/targeted to a target software environment (“corresponding to the native development environment”), where the pluggable transforms are bundled within plug-in components (“a non-native plugin that contains modifier objects”) and are selected based on the target environment to which the resulting image will be deployed, directly mapping to a non-native plugin containing modifier objects that correspond to the native development environment.
wherein the native configuration file is generated from a template native configuration file which is sequentially modified by chaining together the modifier objects of the non-native plugin (Claim 1, "applying a particular pluggable transform to modify the intermediate code file into a particular transitional state of the intermediate code file; and applying one or more subsequent pluggable transforms to modify the particular transitional state of the intermediate code file into one or more other transitional states of the intermediate code file; and producing a runtime-image of the software program from at least the particular subsequent state of the set of files"; Col. 2, Lines 1-18 [summary], " the set of files further includes an input resource and applying the plurality of pluggable transforms further includes applying one or more other pluggable transforms to modify the input resource into one or more transitional states of the input resource, wherein at least one of the particular pluggable transform and the one or more subsequent pluggable transforms are applied exclusively to intermediate code files and at least one of the one or more other pluggable transforms are applied exclusively to input resources") Examiner Comments: This passage teaches that the final/native configuration file (“run-time image”) is generated from a starting template/intermediate code file by applying a first modifier object (“particular pluggable transform”) to produce a transitional state, and then applying subsequent modifier objects (“subsequent pluggable transforms”) to that transitional state, i.e., chaining the modifier objects together to sequentially modify the template until the final native configuration file is produced, directly mapping to a template native configuration file being sequentially modified by chaining together the modifier objects of the non-native plugin.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Smit’s and McMahon’s teachings with Laskey’s teaching in order to allow third-party developers and tool providers to extend and customize the native-configuration generation process by supplying pluggable, ordered transform modules, which Laskey teaches provides “flexibility and extensibility” to the build pipeline, enables build steps to be developed and updated independently of the core toolchain, and allows the generation process to be tuned to specific target environments without requiring modification of the underlying generator (Laskey, [abstract], Col. 1–Col. 3 [Background/Summary]).
Regarding Claim 4, Smit and McMahon teach
The method of claim 2, wherein the non-native configuration file includes at least one non-native library (Smit [Para 0055, the object broker process 304 uses a plurality of broker services to communicate with the data sources 108 … the object broker process 304 includes an ERP broker service 328, a CRM broker service 330, a custom broker service 332, an add-on broker service 334, and a function broker service 336]) Examiner Comments: This passage teaches non-native configuration files including plugins/libraries (broker services like ERP/CRM/add-on brokers acting as plugins for data integration), mapping to non-native plugins.
Regarding Claim 5, Smit and McMahon teach
The method of claim 4, wherein the application configuration defines life cycle events, and wherein at least one non-native library is registered with one or more life cycle events, wherein the non-native library is configured to be triggered at run time upon an occurrence of the one or more life cycle events (Smit [Para 0057, The form process 326 calls business object methods 340 in response to form events and populates the forms 302, 310, 312 with data from the business object properties 340; Para 0012, the information worker is empowered to change the layout of these pages on demand (e.g., add or remove forms on a page and define new relationships), which then in turn uses a personalization engine to store user specific changes and defined relationships between forms]) Examiner Comments: This passage teaches application configurations defining lifecycle events (from events like load/update triggering methods at runtime) with non-native libraries (broker services registered to events) triggered upon occurrence, mapping to lifecycle event registration and triggering.
Regarding Claim 7, Smit and McMahon teach
The method of claim 1, wherein generating includes generating a plurality of the application configurations for a plurality of native development environments based on the non-native configuration (Smit [Para 0014, The disclosed system also generates native mobile applications that can be executed on mobile operating systems]) Examiner Comments: This passage teaches generating multiple native configs (native apps for various mobile OS environments) based on non-native configs (forms/business objects), mapping to plural native environments.
Regarding Claim 8, is a computer readable media claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 11, is a computer readable media claim corresponding to the method claim above (Claim 4) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 4.
Regarding Claim 12, is a computer readable media claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 5.
Regarding Claim 14, is a computer readable media claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 7.
Regarding Claim 15, is a system claim corresponding to the method claim above (Claim 1) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 1.
Regarding Claim 18, is a system claim corresponding to the method claim above (Claim 4-5) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 4-5.
Regarding Claim 20, is a system claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 7.
Regarding Claim 21, is a system claim corresponding to the method claim above (Claim 5) and, therefore, is rejected for the same reasons set forth in the rejection of Claim 5.
Response to Arguments
Applicant’s arguments with respect to claims 1, 4-5, 7-8, 11-12, 14-15, 18, and 20-21 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights