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 .
DETAILED ACTION
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims (1, 11) of U.S. Patent No. 11,709,693 and in view of prior art.
Although the claims at issue are not identical, they are not patentably distinct from each other because: Claims (1, 11) of U.S. Patent Application No. 11,709,693 in view of prior art as shown in the corresponding table below contains every element of Claims 21-40 of the instant application and therefore anticipates the claims.
Present Application No. 18/524/919
Claims 21, 35, 40 A computer-implemented system for developing a digital experience application, comprising: a memory storing instructions; and a processor configured to execute the stored instructions to execute:
a developer utility framework configured to enable development of the digital experience application, wherein the developer utility framework comprises:
a command line interface configured to manage development of the digital experience application, wherein the command line interface is further configured to:
send a plurality of commands to create a driver application, a page component of the driver application, and a first micro- application; and
a build tool configured to receive the plurality of commands from the command line interface, wherein the build tool is further configured to:
create the driver application; create the page component of the driver application; create the first micro-application; and append the first micro-application to the page component of the driver application;
wherein the driver application is configured to host and manage a plurality of micro-applications, and wherein the page component comprises layout configuration information to lay out a plurality of micro-applications (See claim 1 and 11 of 11,709,693. Claims 35, 40 “storing, at a micro-application portal of the developer utility framework, the first micro-application” See Lucovsky mapping.
22. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises:
a developer tool comprising a mock driver for testing the first micro-application in a test container; and a micro-application portal configured to catalog the first micro-application after testing the first micro-application in the test container (See claim 1 of 11,709,693).
23. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises a core library configured to create a component of the driver application (See mapping of claim 23 below as taught by Lucovsky).
24. (New) The computer-implemented system of claim 23, wherein the component of the driver application includes at least one of an event hub, a state store, an event listener, and an error handler (See mapping of claim 24 below as taught by Lucovsky).
25. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises a support library configured to control a life cycle of the first micro-application (See mapping of claim 25 below as taught by Hu).
26. (New) The computer-implemented system of claim 25, wherein the support library is configured to perform at least one of the following operations: load the first micro-application for use by a user; destroy the first micro-application after the user operates the first micro-application; generate an error template in the first micro-application in response to an error in the first micro-application; and generate a load cursor in the first micro-application (See mapping of claim 26 below as taught by Hu).
27. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises: a user interface configured to display the first micro-application in one or more display fields, wherein the first micro-application is configured to display an action configured to trigger an application event when a user interacts with the action (See mapping of claim 27 below as taught by Lucovsky).
28. (New) The computer-implemented system of claim 27, wherein the first micro- application is further configured to display data based on the application event (See mapping of claim 27 below as taught by Lucovsky).
29. (New) The computer-implemented system of claim 27, wherein the one or more display fields comprise: an error field configured to display an error in the first micro-application;
an event field configured to display the application event: a state field configured to display a state information associated with the first micro-application; and an event change field configured to display a change in the state information associated with the first micro-application (See mapping of claim 29 below as taught by Bucuvalas).
30. (New) The computer-implemented system of claim 21, wherein the developer utility framework is further configured to enable visualization of an interaction between the driver application and the first micro-application (See mapping of claim 30 below as taught by Bucuvalas).
31. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises a debugger configured to display a visual representation of an application event transmitted from the first micro-application to a second micro-application (See mapping of claim 31 below as taught by Lemon).
32. (New) The computer-implemented system of claim 31, wherein the driver application further comprises an event hub configured to receive the application event from the first micro-application (See mapping of claim 32 below as taught by Lemon).
33. (New) The computer-implemented system of claim 32, wherein the debugger provides a visual representation of the application event transmitted from the first micro-application to the event hub (See mapping of claim 33 below as taught by Lemon).
34. (New) The computer-implemented system of claim 21, wherein the developer utility framework further comprises a lint tool configured to automatically integrate a standard rule for programming into the developer utility framework (See mapping of claim 33 below as taught by Noens).
36. (New) The computer-implemented method of claim 35, further comprising at least one of the following operations performed by at least one processor: loading, at a developer tool of the developer utility framework, a mock driver for testing the first micro-application; testing, in a test container of the mock driver, the first micro-application to detect an error condition in the first micro-application; and debugging the first micro-application to remove the error condition (See mapping of claim 33 below as taught by Doddappa).
37. (New) The computer-implemented method of claim 35, further comprising at least one of the following operations performed by at least one processor: presenting, at a support library of the developer utility framework, an error template based on the detected error condition; and destroying, via the support library of the developer utility framework, the first micro-application after a user operates the first micro-application (See mapping of claim 37 below as taught by Strong).
38. (New) The computer-implemented method of claim 35, further comprising the following operations performed by at least one processor: creating, at a core library of the developer utility framework, an event hub of the driver application; transmitting, from the first micro-application, an application event: receiving, at the event hub, the application event from the first micro- application; and presenting, via a debugger, a visual representation of an interaction between the first micro-application and the event hub, wherein the interaction is the transmission of the application event from the first micro-application to the event hub (See mapping of claim 38 below as taught by Kikuchi). .
39. (New) The computer-implemented method of claim 35, further comprising the following operations performed by at least one processor: creating, with the build tool of the developer utility framework, a second micro- application;
transmitting, from the first micro-application, an application event: receiving, at the second micro-application, the application event from the first micro-application; and presenting, via a debugger, a visual representation of an interaction between the first micro-application and the second micro-application, wherein the interaction is the transmission of the application event from the first micro-application to the second micro-application (See mapping of claim 38 below as taught by Lemon). .
U.S. Patent No. 11,709,693 in view of prior art
1. A computer-implemented system for developing a digital experience application, executed by a processor, comprising:
a developer utility framework configured to enable development of the digital experience application, wherein the developer utility framework comprises:
a command line interface configured to manage development of the digital experience application, wherein the command line interface is further configured to:
send a plurality of commands to create a driver application, a page component of the driver application, and a first micro-application;
a build tool configured to receive the plurality of commands from the command line interface, wherein the build tool is further configured to: create the driver application; create the page component of the driver application; create the first micro-application; and append the first micro-application to the page component of the driver application;
a developer tool comprising a mock driver for testing the first micro-application in a test container; and a micro-application portal configured to catalog the first micro-application after testing the first micro-application in the test container,
wherein the driver application is configured to host and manage a plurality of micro-applications, and wherein the page component comprises layout configuration information to lay out a plurality of micro-applications.
11. The computer-implemented system of claim 1, wherein the plurality of commands sent by the command line interface comprise: generate a feature of the digital experience application; install the feature onto the digital experience application; and update the feature on the digital experience application.
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.
Claims 21-40 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.
Regarding independent claims the limitations creates a driver application, page component, a micro-application, appending the micro-application to the component, and a layout configuration, as drafted, recites functions that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations as cited above as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. Thus, these limitation falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Under Prong 2, this judicial exception is not integrated into a practical application. The claim recites the following additional limitations: memory, processor, framework, command line interface, and a build tool. The additional elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using generic computer, and/or mere computer components, MPEP 2106.05(f), and steps of sending commands and storing do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering data. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2106.05(g).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of memory, processor, framework, command line interface, build tool, driver application configured to host and manage, amount to no more than mere instructions, or generic computer/computer components to carry out the exception. Furthermore, the limitations directed to sending commands and storing the courts have identified mere data gathering is well-understood, routine and conventional activity. See MPEP 2106.05(d) (Ex. iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;).
The recitation of generic computer instruction and computer components to apply the judicial exception, and mere data gathering do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding claim 23, 24 the limitations of creating a component, what a component comprises are functions that can be reasonably performed in the human mind, thus, additional mental process defined in the claims. The claim does not include any additional element, thus, no limitation that needs to be analyzed under prong 2 for practical application, or under step 2B for significantly more.
Regarding claim 27, 29, 32 the limitation of interface to display, an error field to display an error, an event hub to receive information, is considered mere instructions, or generic computer/computer components to carry out the exception Accordingly, the additional element recited in claim 3 fails to provide a practical application under prong 2, or amount to significantly more under step 2B.
Regarding claim 22, 25, 26, 28, 30, 31, 33, 34, 36, 37 limitations of a mock driver for testing and cataloging after testing, control a lifecycle, generate a template, display data based upon an event, enable a visualization, a debugger to display a visual representation, a lint tool to integrate a rule, testing to detect an error, presenting an error template, are nothing more than insignificant extra solution activity which is not a practical application under prong 2. Under step 2B, the courts of identified the generic function of gathering/storing data, the results of the judicial exception, is well-understood, routine and conventional activity. See MPEP 2106.05(d) - i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
Regarding claim 38, 39 the limitations of creating an event hub are functions that can be reasonably performed in the human mind, thus, additional mental process defined in the claims. The limitation transmitting and receiving are considered mere instructions, or generic computer/computer components to carry out the exception. The limitation of presenting a visual representation is nothing more than insignificant extra solution activity which is not a practical application under prong 2.
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 21, 23, 24, 27, 28, 35, 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky (Pat. No. US 10,817,273) in view of Brodsky (Pub. No. US 2015/0304182) in further view of Fong (Pub. No. US 2006/0123028).
Claim 21, Lucovsky teaches “a computer-implemented system for developing a digital experience application, comprising: a memory storing instructions; and a processor ([Fig. 4] memory, processor) configured to execute the stored instructions to execute: a developer utility framework configured to enable development of the digital experience application, wherein the developer utility framework (i.e. IDE) comprises: a command line interface configured to manage development of the digital experience application, wherein the command line interface is further configured to ([Col. 6, Line 6-16] In the embodiment depicted in FIG. 1A, web applications, such as web application 125, received by cloud controller 1344 may be developed by an application developer 140 in enterprise 100 using an integrated development environment (IDE) 142 installed on the developer's laptop or terminal IDE 142 includes an installed plug-in provided by service provider 102 that facilitates the development and submission of web application 125 to cloud computing environment 112. [Col. 10, Line 16-33] For example, developer 140 may interact with cloud controller 134 through a command line interface (“CLI”), other applications, or any other similar process or tool capable of initiating a network request (e.g., HTTP request) to communicate with cloud controller 134. Furthermore, it should be recognized that embodiments may include a policy engine 144 that intercepts communication between IDE plug-in (or CLI or other similar tool) and cloud controller 134, altering communications in order to adhere to set policies and/or performing steps on behalf of the IDE plug-in (e.g., selecting services in step 320 according to pre-defined policies, etc.). It should also be recognized that functionalities described herein as provided in a plug-in IDE (or CLI or other application or tool) may be alternatively provided inside the cloud computing environment 112, for example, in cloud controller 134, in alternative embodiments.): send a plurality of commands to create a driver application, a page component of the driver application, and a first micro-application ([Col. 9, Lines 45-54] In step 328, cloud controller 134 then creates a web application deployment package that can be unpacked by any available container VM. In one embodiment, such a web application deployment package is a “tar” file (also referred to as a tarball) that includes the start script file, an instance of the runtime environment (e.g., Apache Tomcat, etc.(i.e. driver application)) to be installed and started in a container VM, and the WAR file for web application 125 (e.g., embedded in an appropriate directory within the directory structure of the instance of the runtime environment). [Col. 8, Lines 11-16] In one embodiment, the submitted web application takes the form of a Java “WAR” (Web Application aRchive) file comprising dynamic (e.g., JavaServer Pages™, etc.) web pages, static web pages, Java servlets (i.e. page components and servlets as micro-application), Java classes, and other property, configuration and resources files that make up a Java web application. [Col. 8, Lines 21-23] For example, in an alternative embodiment, the submitted web application comprises a plurality of files, similar to those in a WAR file, organized into a tape archive file or a “tar” file (also referred to as a tarball). [Col. 15, Lines 4-5] Plural instances may be provided for components, operations or structures described herein as a single instance. Examiner notes: Brodsky teaches as evidence an IDE with command line interface for receiving commands from a user to deploy an application. [0014] “Client system 110 includes an integrated development environment (IDE) 112. The IDE may be implemented across plural computing systems. Alternatively, the IDE may reside on a processing node 130, manager system 140, or other computer system in communication with a distributed server. The IDE may present any graphical user (e.g., GUI, etc.) or other interface (e.g., command line prompts, menu screens, etc.) to receive commands from and display information to users, build one or more programs 114 and configurations 116, and submit programs 114 to manager system 140 and/or processing nodes 130 of distributed server 120.” Therefore, it would be obvious to one of ordinarily skilled in the art, the IDE CLI of Lucovsky teaches a plurality of commands for creating the web application.); and a build tool configured to receive the plurality of commands from the command line interface, wherein the build tool is further configured to: create the driver application; create the page component of the driver application; create the first micro-application; and wherein the driver application is configured to host and manage a plurality of micro-applications ([Col. 11, Line 64 – Col. 12, Line 32] (24) FIG. 5 depicts a flow diagram for deploying a web application in a container virtual machine. The steps set forth in FIG. 5 take place, for example, after cloud controller 134 has received and prepared web application 125 for deployment in accordance with the steps set forth in FIG. 3. In step 500, cloud controller 134 receives a request from enterprise 100 (e.g., from developer 140) to launch web application 125. In step 502, cloud controller 134 broadcasts a request (via addressing and discovery layer 132) for an available container VM. In one embodiment, such a broadcast request may “flavored” by cloud controller 134 to request specific characteristics desired in a container VM, such as guest operating system type (e.g., Windows, Linux, MacOS, etc.), computing resource requirements (e.g., memory requirements, etc.) and the like. In step 504, deployment agent 428 of container VM 126.sub.1 responds (via addressing and discovery layer 132) indicating the availability of container VM 126.sub.1 to host web application 125. In step 506, cloud controller 134 (via addressing and discovery layer 132) provides deployment agent 428 a link (e.g., URL) or otherwise establishes a connection with container VM 126.sub.1 to download a web application deployment package for web application 125 (e.g., as created in step 328 of FIG. 3), and in step 508, deployment agent 428 fetches or otherwise receives the web application deployment package. In step 510, deployment agent 428 unpacks the web application deployment package and installs runtime environment 430 (e.g., Apache Tomcat application server, etc.), including loading the WAR file (or other package) associated web application 125 into the appropriate directory of the runtime environment. In step 512, deployment agent 428 executes the start script file of the web application deployment package thereby spawning a new process in container VM 126.sub.1 that launches the runtime environment (e.g., Apache Tomcat) and starts web application 125 within the runtime environment. [Col. 8, Lines 24-30] storage of application)”.
However, may not explicitly teach the remaining limitations.
Fong teaches “append the first micro-application to the page component of the driver application; wherein the page component comprises layout configuration information to lay out a plurality of micro-applications ([Fig. 10, 1010] regular_template.jsp as page component with plurality of JSP files appended as layout [0075] In addition, other required Web assets are also deployed to the appropriate location (step 1120). These Web assets include the layout JSP files and cascade style sheet files that describe the page layout. If necessary, extension points are also provided to support additional processing for customization (step 1122). Once the stores are generated, the process terminates thereafter.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Fong with the teachings of Lucovsky, Brodsky in order to provide a system that teaches appending of page components. The motivation for applying Fong teaching with Lucovsky, Brodsky teaching is to provide a system that allows for ease of layout interfaces. Lucovsky, Brodsky, Fong are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Fong with the teachings of Lucovsky, Brodsky by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 23, the combination teaches the claim, wherein Lucovsky teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises a core library configured to create a component of the driver application ([Col. 11, Lines 19-26] For example, in one embodiment, runtime environment 430 may be a Java application server (e.g., Apache Tomcat, etc.) that includes a Java virtual machine and various API libraries that support the deployment of Java-based web applications. As described in the context of FIG. 3, such a runtime environment 430 may be received by a container VM as part of a web application deployment package created by cloud controller 134.)”.
Claim 24, the combination teaches the claim, wherein Lucovsky teaches “the computer-implemented system of claim 23, wherein the component of the driver application includes at least one of an event hub, a state store, an event listener ([Col. 12, Line 27-32] In step 512, deployment agent 428 executes the start script file of the web application deployment package thereby spawning a new process in container VM 126.sub.1 that launches the runtime environment (e.g., Apache Tomcat) and starts web application 125 within the runtime environment.), and an error handler”.
Claim 27, the combination teaches the claim, wherein Lucovsky teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises: a user interface configured to display the first micro-application in one or more display fields, wherein the first micro-application is configured to display an action configured to trigger an application event when a user interacts with the action ([0049] In a first scenario, Java developers instrumented JSP code snippets 404 in store page 405. Store page 405 may be one of the Web pages designed by the page designer. At run time, since JSP code snippet 404 is included in skeleton store page 405, the displayed store page is composed of both the skeleton and the snippet. In this case, JSP code snippets 404 include application logic developed by Java developers that are used for testing purposes or provide a specific feature. After a shopper clicks a button or a link in store page 405, the system displays another skeleton store page 406, which in turn may include another set of JSP code snippets.)”.
Claim 28, the combination teaches the claim, wherein Lucovsky teaches “the computer-implemented system of claim 27, wherein the first micro-application is further configured to display data based on the application event ([0049] In a first scenario, Java developers instrumented JSP code snippets 404 in store page 405. Store page 405 may be one of the Web pages designed by the page designer. At run time, since JSP code snippet 404 is included in skeleton store page 405, the displayed store page is composed of both the skeleton and the snippet. In this case, JSP code snippets 404 include application logic developed by Java developers that are used for testing purposes or provide a specific feature. After a shopper clicks a button or a link in store page 405, the system displays another skeleton store page 406, which in turn may include another set of JSP code snippets.)”.
Claim 35, “a computer-implemented method for developing a digital experience application using a developer utility framework, the method comprising the following operations performed by at least one processor: sending, from a command line interface of the developer utility framework, a plurality of commands to create a driver application, a page component of the driver application, and a first micro-application; receiving, at a build tool of the developer utility framework, the plurality of commands; creating, using the build tool of the developer utility framework, the driver application; creating, using the build tool of the developer utility framework, the page component of the driver application; creating, using the build tool of the developer utility framework, the first micro-application; appending, using the build tool of the developer utility framework, the first micro-application to the page component of the driver application; and storing, at a micro-application portal of the developer utility framework, the first micro-application (Lucovsky [Col. 8, Lines 24-33] Furthermore, it should be recognized that, rather than submitting the web application itself, alternative embodiments may submit web application in step 306 by providing a reference to download or otherwise access the web application, for example, by providing a uniform resource locator (“URL”), Git repository or other similar reference to web application. In such embodiments, the step of receiving the web application in step 308 would thus utilize the provided reference to fetch the web application.), wherein the driver application is configured to host and manage a plurality of micro-applications, and wherein the page component comprises layout configuration information to lay out a plurality of micro-applications” is similar to claim 21 and therefore rejected with the same references and citations.
Claim 40, “a tangible, non-transitory computer-readable memory device that stores a set of instructions that, when executed by at least one processor, cause the at least one processor to perform operations comprising: sending, from a command line interface of the developer utility framework, a plurality of commands to create a driver application, a page component of the driver application, and a first micro-application; receiving, at a build tool of the developer utility framework, the plurality of commands; creating, using the build tool of the developer utility framework, the driver application; creating, using the build tool of the developer utility framework, the page component of the driver application; creating, using the build tool of the developer utility framework, the first micro- application; appending, using the build tool of the developer utility framework, the first micro-application to the page component of the driver application; and storing, at a micro-application portal of the developer utility framework, the first micro-application (Lucovsky [Col. 8, Lines 24-33] Furthermore, it should be recognized that, rather than submitting the web application itself, alternative embodiments may submit web application in step 306 by providing a reference to download or otherwise access the web application, for example, by providing a uniform resource locator (“URL”), Git repository or other similar reference to web application. In such embodiments, the step of receiving the web application in step 308 would thus utilize the provided reference to fetch the web application.), wherein the driver application is configured to host and manage a plurality of micro-applications, and wherein the page component comprises layout configuration information to lay out a plurality of micro-applications” is similar to claim 21 and therefore rejected with the same references and citations.
Claim/s 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Arguelles (Pat. No. US 10,289,539).
Claim 22, the combination may not explicitly teach the claim.
Arguelles teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises: a developer tool comprising a mock driver for testing the first micro-application in a test container ([Col. 2, Lines 61 – Col. 3, Line 28] (14) After the software product is built, the deployment pipeline 100 may proceed to a step 130 to deploy the build of the software product to a test environment 135. Upon deployment to the test environment 135, the build of the software product may be executed, e.g., using one or more test hosts (i.e. container). In the test environment 135, the build of the software product may be insulated from real-time interaction with real-world clients, e.g., by processing only synthetic requests (i.e. mock driver) or prerecorded client requests that were previously captured in a production environment. For example, if the software product implements a service that is associated with an electronic commerce (e-commerce) merchant, then the service may be configured to perform one or more suitable operations such as generating a web page (e.g., a product description page for a product offered for sale by the merchant), completing a sale or other transaction between the merchant and a customer, verifying a payment presented by the customer, etc. The test environment 135 is discussed further with respect to FIG. 2B. (15) In the test environment 135, the build of the software product may be subjected to one or more performance tests to assess the performance impact of the build. As shown in the example of FIG. 1, three different categories of tests may be performed in three different steps: a step 140 to perform one or more sanity tests, a step 150 to perform one or more latency tests, and a step 160 to perform one or more load tests. However, it is contemplated that the performance tests may include fewer tests than shown, additional tests not shown, or tests performed in a different order than shown. As shown in the example of FIG. 1, each of the three testing steps 140, 150, and 160 may be performed in series. However, it is contemplated that any of the three testing steps 140, 150, and 160 may be performed in parallel with respect to others of the testing steps, when appropriate. In various embodiments, at least a portion of the tests within any of the testing steps 140, 150, or 160 may be performed in parallel and/or in series.); and a micro-application portal configured to catalog the first micro-application after testing the first micro-application in the test container ([Col. 10, Lines 45-48] (42) As previously discussed with respect to FIG. 1, if the current build passes all of the tests, the deployment pipeline 400 may proceed to a step 170 to deploy the build to a production environment.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Arguelles with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches testing of applications. The motivation for applying Arguelles teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving reliability of applications. Lucovsky, Brodsky, Fong, Arguelles are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Arguelles teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Arguelles with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 25, 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Hui (Pub. No. US 2011/0087672).
Claim 25, the combination may not explicitly teach the claim.
Hui teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises a support library configured to control a life cycle of the first micro-application ([0073] As previously described, embodiments of the present invention may enable a developer to make a rapid and efficient identification of deployed objects that are available for re-use in a J2EE application. It is well known in the art that J2EE application development commonly is performed by using a Java interactive development environment (IDE), such as JDeveloper from Oracle International Corporation of Redwood Shores, Calif. An IDE contains an integrated set of development tools such as a code editor and graphical object management tools. A developer using an IDE can create, delete, or edit an application source code object by accessing development tool user interfaces (UIs) provided by the IDE.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Hui with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of IDE functionality. The motivation for applying Hui teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Hui are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Hui teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Hui with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 26, the combination teaches the claim, wherein Hui teaches “the computer-implemented system of claim 25, wherein the support library is configured to perform at least one of the following operations: load the first micro-application for use by a user ([0073] As previously described, embodiments of the present invention may enable a developer to make a rapid and efficient identification of deployed objects that are available for re-use in a J2EE application. It is well known in the art that J2EE application development commonly is performed by using a Java interactive development environment (IDE), such as JDeveloper from Oracle International Corporation of Redwood Shores, Calif. An IDE contains an integrated set of development tools such as a code editor and graphical object management tools. A developer using an IDE can create, delete, or edit an application source code object by accessing development tool user interfaces (UIs) provided by the IDE.); destroy the first micro-application after the user operates the first micro-application; generate an error template in the first micro-application in response to an error in the first micro -application; and generate a load cursor in the first micro-application”.
Rationale to claim 25 is applied here.
Claim/s 29 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Bucuvalas (Pub. No. US 2011/0283260).
Claim 29, the combination may not explicitly teach the claim.
Bucuvalas “the computer-implemented system of claim 27, wherein the one or more display fields comprise: an error field configured to display an error in the first micro-application ([Fig. 12, 1210] error); an event field configured to display the application event ([Fig. 12, 1210] results): a state field configured to display a state information associated with the first micro-application ([Fig. 12, 1220] input information); and an event change field configured to display a change in the state information associated with the first micro-application ([Fig. 11, 1140] output of test [0207] Once the validation has completed, the results for each regression set is clearly indicated as either a success or failure. In the example in FIG. 11, there is a suite of regression sets, one for each product subset of the system. The validation has been executed on all regression sets and all regression sets passed validation except the C15 regression set as illustrated in FIG. 12 and denoted by the red "X" and "Failed" 1210. For the C15 failure, the reason 1220 for the failure is displayed: the Loan Amount constraint on one of the C15 patterns is unsupported in the master semantic model. Additional information on the failed regression set is available on the Regression Trace interface 1300, which is displayed when a failed regression set and Trace button 1230 (as shown in FIG. 12) are selected with the result being displayed as illustrated in interface 1300 shown in FIG. 13. Interface 1300 can include such information as the regression set name 1310, non-matching patterns information 1320, matching patterns information 1330, non-matching patterns trace information 1340 and matching patterns trace information 1350.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Bucuvalas with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of interfaces. The motivation for applying Bucuvalas teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Bucuvalas are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Bucuvalas teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Bucuvalas with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 30, 31, 32, 33, 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Lemon (Pub. No. US 2002/0156881).
Claim 30, the combination may not explicitly teach the claim.
Lemon teaches “the computer-implemented system of claim 21, wherein the developer utility framework is further configured to enable visualization of an interaction between the driver application and the first micro-application ([0085] For the developer, the process of developing a web application involves, among other tasks, testing each dynamic web component (in the case of a Java.TM. application, each JSP.TM. and servlet) to see that it performs the correct processing and generates the appropriate output. This involves executing individual web components, and also sequences of components as they would be traversed by a user who browses the web site. In the discussion which follows, the web application to be tested has been developed in an IDE, for example, the IDE 6 (shown in FIG. 3). The developer is using the IDE to test-run and debug the web application. The developer can execute the JSP.TM. pages or servlets from the IDE. The HTTP transaction monitor GUI (22 in FIG. 3) is displayed by either one of the two previously described mechanisms. As shown in FIG. 3, the contents of a web application is displayed in a GUI 50 that is included in the IDE 6. The developer selects a resource in the web application and then asks the IDE 6 to execute the resource For example, in FIG. 3, a JSP.TM. page called "input" has been selected. To display the page, the IDE 6 sends an HTTP request to the execution server (10 in FIG. 1). The output of the execution server (10 in FIG. 1), i.e., the HTTP response, is displayed in the browser 52 which is included in the IDE 6.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Lemon with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of interfaces. The motivation for applying Lemon teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Lemon are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Lemon teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Lemon with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claims 31, 39, the combination may not explicitly teach the claim.
Lemon teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises a debugger configured to display a visual representation of an application event transmitted from the first micro-application to a second micro-application ([0067] The server-side component 16 also includes a request player 17 that detects a special type of HTTP request ("replay request") sent by the client-side component 18. The replay request indicates that a prior HTTP request should be replayed and contains sufficient information to recreate the prior HTTP request. The request player 17 modifies the replay request to be identical to the original request before passing it on. The modified request is then processed by the data collector 15 before control is yielded to the execution server 10. The request player 17 runs on the execution server 10. In one implementation, the request player 17 relies on hooks in the execution server 10 or hooks in a server plug-in (e.g., a servlet engine) to intercept replay requests coming into the execution server 10. The request player 17 replaces all the request data, i.e., the IP address of the client from which the HTTP request originated, the HTTP method, the request URI, the protocol version, any query string and parameters, and all the HTTP headers, in the replay request with the corresponding data from the HTTP request that is to be replayed. The data needed to modify the replay request may be loaded directly from the directory 20 or may be passed in as parameters with the replay request (i.e., if the data is managed by the client-side component 18).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Lemon with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of interfaces. The motivation for applying Lemon teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Lemon are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Lemon teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Lemon with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim 32, the combination teaches the claim, wherein Lemon teaches “the computer-implemented system of claim 31, wherein the driver application further comprises an event hub configured to receive the application event from the first micro-application ([0067] The server-side component 16 also includes a request player 17 that detects a special type of HTTP request ("replay request") sent by the client-side component 18. The replay request indicates that a prior HTTP request should be replayed and contains sufficient information to recreate the prior HTTP request. The request player 17 modifies the replay request to be identical to the original request before passing it on. The modified request is then processed by the data collector 15 before control is yielded to the execution server 10. The request player 17 runs on the execution server 10. In one implementation, the request player 17 relies on hooks in the execution server 10 or hooks in a server plug-in (e.g., a servlet engine) to intercept replay requests coming into the execution server 10. The request player 17 replaces all the request data, i.e., the IP address of the client from which the HTTP request originated, the HTTP method, the request URI, the protocol version, any query string and parameters, and all the HTTP headers, in the replay request with the corresponding data from the HTTP request that is to be replayed. The data needed to modify the replay request may be loaded directly from the directory 20 or may be passed in as parameters with the replay request (i.e., if the data is managed by the client-side component 18).)”.
Rationale to claim 31 is applied here.
Claim 33, the combination teaches the claim, wherein Lemon teaches “Lemon teaches “the computer-implemented system of claim 32, wherein the debugger provides a visual representation of the application event transmitted from the first micro-application to the event hub ([0068] In one implementation, the client-side component 18 is accessible from the IDE 6. The client-side component 18 includes a GUI 22 which displays the transactions for which the server-side component 16 has collected data. The GUI 22 also allows the user to send a request to the execution server 10 to replay a prior HTTP transaction. The client-side component 18 further includes a mechanism for receiving notification of new HTTP transactions, which are subsequently listed on the GUI 22. In one embodiment, this functionality is handled by a servlet 23 which runs on the internal HTTP server 12 and is called whenever the server-side component 16 records a new transaction.)”.
Rationale to claim 31 is applied here.
Claim/s 34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Noens (Pub. No. US 2016/0154629).
Claim 34, the combination may not explicitly teach the claim.
Noens teaches “the computer-implemented system of claim 21, wherein the developer utility framework further comprises a lint tool configured to automatically integrate a standard rule for programming into the developer utility framework ([0041] In general, a tools engineer 402 may configure or specify build rules 364 for different targets, sets or application models. For example, different sets of build rules may be provided for different targets, sets or application models. The build rules may be specified, for example, using a GUI of the IDE. For example, a rules editor may be used to specify the build rules. The rules editor, for example, may be similar to the App metadata editor. In some implementations, the rules and App metadata editor may be the same editor. Other techniques for providing the build rules may also be useful. The build rules, for example, specify when to perform what actions on which resources. The build rules, for example, specify when to perform what actions on which resources during packaging. The build rules, for example, are in the form of metadata. For example, the build rules are provided as a build rules metadata file. The build rules may be modified or tweaked by a developer or end-user 403. The modification, for example, may be accomplished using the GUI of the IDE. Other techniques for modifying the build rules may also be useful.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Noens with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches testing of applications. The motivation for applying Noens teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving reliability of applications. Lucovsky, Brodsky, Fong, Noens are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Noens teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Noens with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, Noens in further view of Doddappa (Pub. No. US 2010/0235807).
Claim 36, “the computer-implemented method of claim 35, further comprising at least one of the following operations performed by at least one processor: loading, at a developer tool of the developer utility framework, a mock driver for testing the first micro-application; testing, in a test container of the mock driver, the first micro-application to detect an error condition in the first micro-application” is similar to claim 22 and therefore rejected with the same references and citations.
However, the combination may not explicitly teach removing the error.
Doddappa teaches “debugging the first micro-application to remove the error condition ([0030] The triage automation issues phase 408 begins at step 454. At this stage, any automation issues (i.e., bugs) that are related to the feature are identified and a determination is made regarding the source of the issue. At step 456, the team involves the QA team and then, if necessary, the development team to attempt to determine whether the test failure is due to a product issue and how it might be addressed. This completes triage automation issues phase 408. Finally, the debug automation tests phase 410 then involves step 460, during which the team investigates any failures and provides appropriate fixes until all tests pass. This completes the development/debug phase 400.)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Doddappa with the teachings of Lucovsky, Brodsky, Fong, Noens in order to provide a system that teaches testing of applications. The motivation for applying Doddappa teaching with Lucovsky, Brodsky, Fong, Noens teaching is to provide a system that allows for improving reliability of applications. Lucovsky, Brodsky, Fong, Noens, Doddappa are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Noens, Doddappa teach every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Doddappa with the teachings of Lucovsky, Brodsky, Fong, Noens by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 37 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Strong (Pub. No. US 2014/0258842).
Claim 37, the combination may not explicitly teach the claim.
Strong teaches “the computer-implemented method of claim 35, further comprising at least one of the following operations performed by at least one processor: presenting, at a support library of the developer utility framework, an error template based on the detected error condition ([0034] FIG. 4A illustrates a custom design application with exemplary templates and their interrelation to one another according to certain embodiments. The custom design application 400 generally comprises a plurality of templates 412, such as a site master template 402, a homepage template 404, one or more sub-templates 406, and a 404 error template 408. The custom design application 400 and plurality of templates 412 are provided by the website design server 112 through the communications network 102 to the user computer system 104 as previously described. The custom design application 400 and plurality of templates 412 are displayed via an I/O device through the browser which allows the user to interact with the custom design application 400 and plurality of templates 412 to create a customizable website design. It should be noted that a website created by a user utilizing the custom design application 400 may have a single web page or multiple web pages within the website.); and destroying, via the support library of the developer utility framework, the first micro-application after a user operates the first micro-application).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Strong with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of IDE functionality. The motivation for applying Strong teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Strong are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Strong teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Strong with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Claim/s 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lucovsky, Brodsky, Fong, in further view of Kikuchi (Pat. No. US 9,870,279).
Claim 38, the combination may not explicitly teach the claim.
Kikuchi teaches “the computer-implemented method of claim 35, further comprising the following operations performed by at least one processor: creating, at a core library of the developer utility framework, an event hub of the driver application ([Col. 3, Lines 55 – Col 4, Line 2] (33) The processor 31 controls the terminal 3. The memory 32 serves as a working area of the processor 31. The memory 32 is a volatile storage medium for storing a web browser 321 and a script engine program 322. The web browser 321 and the script engine program 322 are loaded from the local disk to the memory 32. The web browser 321 is a program for making the processor 31 control displaying web pages received from the web server 2 and sending and receiving web pages. The script engine program 322 is a program for making the processor 31 execute script codes included in responses from the web server 2. The script code is a program to obtain various logs concerning the web browser 321 running on the terminal 3.); transmitting, from the first micro-application, an application event: receiving, at the event hub, the application event from the first micro-application; and presenting, via a debugger, a visual representation of an interaction between the first micro-application and the event hub, wherein the interaction is the transmission of the application event from the first micro-application to the event hub ([Col. 7, Line 40-52] (61) FIG. 9 is an explanatory diagram for illustrating an example of registered information of DOM event handlers referred to at Step S813. Returning to FIG. 8, the terminal 3 acquires environmental information and information on the screen display from the web browser 321 with the log acquisition program 700 and stores the environmental information and the information on the screen display to an environmental log array and display log arrays as an environmental information log and a display log (Step S814). The terminal 3 further creates an operation log of the operations on the web browser 321 and stores information on the operations to operation log arrays with the log acquisition program 700 (Step S815).)”.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kikuchi with the teachings of Lucovsky, Brodsky, Fong in order to provide a system that teaches details of IDE functionality. The motivation for applying Kikuchi teaching with Lucovsky, Brodsky, Fong teaching is to provide a system that allows for improving development of applications. Lucovsky, Brodsky, Fong, Kikuchi are analogous art directed towards application deployment. Together Lucovsky, Brodsky, Fong, Kikuchi teaches every limitation of the claimed invention. Since the teachings were analogous art known at the filing time of invention, one of ordinary skill could have applied the teachings of Kikuchi with the teachings of Lucovsky, Brodsky, Fong by known methods before the effective filing date of the claimed invention and gained expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WYNUEL S AQUINO whose telephone number is (571)272-7478. The examiner can normally be reached 9AM-5PM EST M-F.
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, Lewis Bullock can be reached at 571-272-3759. 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.
/WYNUEL S AQUINO/Primary Examiner, Art Unit 2199