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
1. This Office Action is in response to the application filed on 04/09/2026. Claims 1, 3-14 and 16-26 are pending in this application. Claims 1 and 14 are independent claims. Claims 2 and 15 are canceled.
Claim Rejections - 35 USC § 103
2. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
3. The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
4. Claims 1, 3, 4, 12, 14, 16, 17 and 25 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), and further in view of Rainisto (US PGPub 20130024808).
As per Claim 1, Burman teaches of a computer-implemented method when executed by data processing hardware causes the data processing hardware to perform operations comprising: receiving a trigger interaction indication indicating a first graphical user interaction by a user within a no-code environment; (Par 5, These GUIs allow an action of a workflow to be defined with dynamic output, so that the workflow can adapt to these changes. Advantageously, this allows workflows to be defined in a flexible, no-code fashion. In particular, actions incorporated into a workflow during workflow design are not hard-coded to a specific version of the schema. Figs 6B-D, Par 113, Notably, the workflow design tool can be a so-called “low-code/no-code” solution, with which designers either write very little program code, or no code at all, to implement the workflow. Par 117, The workflow design tool may present the designer with a series of GUI pages that allow the designer to specify the workflow.)
in response to receiving the trigger interaction indication, establishing a trigger condition for an application generated by the no-code environment; (Par 114, While the embodiments herein provide support for general workflow design, an example workflow design tool may be implemented based around specific definitions of triggers, actions, and workflow logic. Triggers may be used to specify conditions that start a workflow, such as a change to an entry in a database (e.g., the addition or updating of a configuration item in a CMDB) or according to a schedule (e.g., once per day or once per week). A trigger causes one or more actions to be performed, and each action may be controlled by workflow logic that specifies the conditions that must be true for the action to be performed. The action may involve changing the state of information in a database, sending a notification (e.g., an email) to a user, and so on)
receiving an action interaction indication indicating a second graphical user interaction by the user within the no-code environment; (Par 135, In FIG. 6D, the user has selected the “Core” context. Based on this selection, sub-menu 638 [second graphical user interaction] is displayed. This sub-menu provides the user the ability to select from a number of specific actions, such as “Ask for approval”, “Create record”, “Create task”, “Delete record”, “Log”, “Look up records”, “Send email”, “Update record”, and “Wait for condition”. From these, the user has selected “Look up records”. Accordingly, information box 640, that describes the selected action, may be displayed.)
Burman does not specifically teach, however Mimlitch teaches of in response to receiving the action interaction indication, defining an action response for the application when the trigger condition is satisfied, the action response comprising a function call calling a function of a script, the script generated within a low-code environment; and executing the application. (Fig. 7 and Par 29 and 38, In an aspect of this system, the program instructions being configured to create the graphical coding environment, further define a set of instructions, stored on the memory, to define a peek mode, wherein the peek mode is defined for a user to select a graphical programming block. The set of instructions for the peek mode is configured to convert the selected graphical programming block into a standard textual programming language [script], and display within the graphical coding environment the standard textual programming language in a display window adjacent to the graphical programming block. Par 194, Toolbar Change: FIGS. 14A and 14B illustrate in one embodiment of the invention the ability to change the left Toolbar Area 420 from Blocks to Text snippets depending on what the user is editing on the right Working Area 422. FIG. 14A shows the user dragging a Graphical Block 424 from the Toolbar Area 420 to the Working Area 422. FIG. 14B shows the left Toolbar transformed to code snippets. The user can now drag code snippets from the left Toolbar Area 420 into the Code Block 426. Several methods can be used to change the left Toolbar from blocks to text. One option is a user controlled switch. Another option is to automatically switch to text snippets in the toolbar when the user clicks within a Code Block, and automatically switch to blocks in the toolbar when the user clicks anywhere outside of a Code Block. Par 30, In another aspect of this system, the set of instructions for the peek mode is further configured to create a coding programming block equivalent to the selected graphical programming block, and wherein the coding programming block being accessible to edit with standard textual coding language. Par 147, The application now can parse block to code and mix in the textual code into a single program output for the intended target that executes the program.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add in response to receiving the action interaction indication, defining an action response for the application when the trigger condition is satisfied, the action response comprising a function call calling a function of a script, the script generated within a low-code environment; and executing the application, as conceptually seen from the teaching of Mimlitch, into that of Burman because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Neither Burman nor Mimlitch specifically teaches however, MacMillan teaches of in response to receiving the action interaction indication, requesting, from the user, a script selection indication receiving the script selection indication indicating selection of a script in response to receiving the script selection indication, (Col 18, lines 16-20, In one example, the user may use a web-based user interface presented on a display of a client computing device to select a script that performs a function that is pre-written and drag and drop the script into an area of the user interface. Col 17, line 56-col 18, line 4, Additionally, the client computing device 108 may receive a selection by the user of a script from the list of at least one pre-written scripts, the script performing a particular function, and receive a drop of the script into a particular step in the workflow of the application. Alternatively, the client computing device 108 may receive a selection by the user of a first script written in a first programming language that performs a first function and receive a selection by the user of a second script written in a second programming language that is different from the first programming language. Further, the client computing device 108 may receive a selection by the user of a first script that performs a first function and receive a selection by the user of a second script that performs a second function, and receive a drop of the first script and the second script into a step in the workflow of the application to execute both the first script and the second script in parallel. Col 6, lines 16-20, In one example, the user may use a web-based user interface presented on a display of a client computing device to select a script that performs a function that is pre-written and drag and drop the script into an area of the user interface. Col 12, lines 30-31, The button may show a name of the script and/or functionality associated with the script. Col 21, lines 4-6, As an example, the user may embed a standardized exit code into the script to have the system 100 perform particular functions.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add in response to receiving the action interaction indication, defining an action response for the application when the trigger condition is satisfied, the action response comprising a function call calling a function of a script, the script generated within a low-code environment; and executing the application, as conceptually seen from the teaching of MacMillan, into that of Burman and Mimlitch because this modification can help design and develop the application by selecting script text coding and function accordingly in order to further customize the application with a particular script and a function of a choice.
None of Burman, Mimlitch and MacMillan specifically teaches, however Muller teaches of the script comprising a plurality of functions; requesting, from the user, a function selection indication …receiving the function selection indication selection selecting a function of the script from the plurality of functions; in response to receiving the function selection indication … (Fig. 3 and Par 26, At block 304, the script authoring tool receives user selection of desired functions. At block 306, the script authoring tool adds the selected functions to the script. In addition, the script authoring tool adds corresponding conditions to the script. Alternatively, the script authoring tool allows the author to add some or all of the desired functions and/or conditions to the script. Par 27, At block 308, the script authoring tool receives a user request to save the script and stores the script in a script store for future use by a tester. Par 20, The script authoring tool 202 may provide functions by displaying a list of available functions to a test author and allowing the test author to select desired functions [in the script]. In addition, the script authoring tool 202 may specify conditions (also referred to as assertions) that need to be satisfied after corresponding functions are performed. Par 21, When a script is run, the test engine 204 invokes functions and conditions identified in the script, detects a condition failure, and identifies the phase in which the failure has occurred.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the script comprising a plurality of functions; requesting, from the user, a function selection indication …receiving the function selection indication selection selecting a function of the script from the plurality of functions; in response to receiving the function selection indication, as conceptually seen from the teaching of Muller, into that of Burman, Mimlitch and MacMillan because this modification can help select and execute a particular function from a list of functions from the selected script of a choice of the user based on the utility of the script execution such as predicted functional behaviors and requirements (i.e. low cost of execution).
None of Burman, Mimlitch, MacMillan and Muller specifically teaches, however Rainisto teaches of the function selection indication comprising a third graphical user interaction. (Par 4, 11 and 19-20 and Fig. 5 controlling display of a plurality of functions in response to a user input, the plurality of functions being associated with the program and being displayed in the graphical user interface with the portion; and determining if the user input selects a function of the plurality of functions for execution. … perform executing the selected function of the displayed plurality of functions in response to the user input.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the function selection indication comprises a third graphical user interaction, as conceptually seen from the teaching of Rainisto, into that of Burman, Mimlitch, MacMillan and Muller because this modification can help the user select and execute a particular function from a list of functions from the selected script of a choice of the user via graphical user interface.
As per Claim 3, Burman further teaches of the method of claim 2, wherein each function of the plurality of functions is generated within the low-code environment. (Fig. 8C and 9C and par 178, FIG. 8C depicts GUI 800 with the parsing step selected in action outline pane 802. Thus, specification pane 804 includes graphical elements that define how to parse results of the REST query defined in FIG. 8B. In particular, input variables 830 define input to a user-defined script that parses the results, and script specifier 836 includes a text box in which the script can be entered and/or edited. FIG. 9C depicts GUI 900 with the parsing step selected in action outline pane 902. Thus, specification pane 904 includes graphical elements that define how to parse results of the REST query defined in FIG. 9B. In particular, input variables 930 define input to a user-defined script that parses the results, and script specifier 936 includes a text box in which the script can be entered and/or edited. Each of input variables 930 is defined by a name and a value. For example, the input variable shown in FIG. 9C is named “payload” and the value is defined by pill 932. Notably, pill 932 refers to the ResponseBody parameter returned by the REST step. Pill 932 has been dragged and dropped into the value field, which indicates that the body of the response to the REST query (typically a JSON object) is to be parsed by the script. Script specifier 936 includes an example script that parses the expected JSON returned by the REST query into one or more records. While only one input variable is shown in FIG. 9C, additional input variables can be created by activating button 934.)
As per Claim 4, Burman teaches of the method of claim 1, wherein the operations further comprise, after receiving the function selection indication: receiving, from the low-code environment, one or more parameters associated with the function of the script; (Fig. 8C and Fig 8C, Each of input variables 830 is defined by a name and a value. For example, the input variable shown in FIG. 8C is named “payload” and the value is defined by pill 832. Notably, pill 832 refers to the ResponseBody parameter returned by the REST step. Pill 832 has been dragged and dropped into the value field, which indicates that the body of the response to the REST query (typically a JSON object) is to be parsed by the script. Script specifier 836 includes an example script that parses the expected JSON returned by the REST query into a normalized format or schema (not to be confused with the schema provided by the metadata API of the remote service). This format may be a data structure used by the computational instance to store arbitrary complex objects or structured data. While only one input variable is shown in FIG. 8C, additional input variables can be created by activating button 834.)
receiving, from the low-code environment, data type information for at least one of the one or more parameters; and (Par 44, As an example of the aPaaS development process, a software developer may be tasked to create a new application using the aPaaS system. First, the developer may define the data model, which specifies the types of data that the application uses and the relationships therebetween. Then, via a GUI of the aPaaS system, the developer enters (e.g., uploads) the data model. The aPaaS system automatically creates all of the corresponding database tables, fields, and relationships, which can then be accessed via an object-oriented services layer. Par 187, Query parameters 927 defines further parameters that can be appended to the resource path. In FIG. 9B, this includes a parameter named “sysparam_limit”, with is used to determine the maximum number of results to obtain from the REST query. Headers 928 specifies values of headers in the GET request.)
for each respective parameter of the one or more parameters, querying the user for an expression that, when evaluated, satisfies the respective parameter. (Par 9, wherein the metadata action defines a metadata query to the metadata API, rules for parsing the schema of the structured data, and a normalized format for the structured data. Claim 1, wherein the integration action defines a structured data query to a remote service application programming interface (API) of a remote service that provides access to structured data, and wherein the integration action defines an indication that a metadata action is to be performed to query a metadata API for a schema of a result of the structured data query to present the result of the structured data query in a normalized format based on the schema)
As per Claim 12, Burman teaches of the method of claim 1, wherein the application calls the function via an application programming interface (API). (Par 156, In fact, the amount of time that a workflow designer needs to spend designing a workflow also decreases because the designer can simply drag and drop representations of outputs from calls to the remote service API into other actions.)
Re Claim 14, it is the system claim, having similar limitations of claim 1. Thus, claim 14 is also rejected under the similar rationale as cited in the rejection of claim 1.
Re Claim 16, it is the system claim, having similar limitations of claim 3. Thus, claim 16 is also rejected under the similar rationale as cited in the rejection of claim 3.
Re Claim 17, it is the system claim, having similar limitations of claim 4. Thus, claim 17 is also rejected under the similar rationale as cited in the rejection of claim 4.
Re Claim 25, it is the system claim, having similar limitations of claim 12. Thus, claim 25 is also rejected under the similar rationale as cited in the rejection of claim 12.
5. Claims 5 and 18 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), and further in view of Ouali (US PGPub 20180024814).
As per Claim 5, none of Burman, Mimlitch, MacMillan, Muller and Rainisto specifically teaches, however Ouali teaches of the method of claim 4, wherein the function call calls the function of the script using an evaluation of the expression for each respective parameter. (Par 1397-1398, The syntax of a function expression is alias. functLoriName(p arameter 1, parameter2 . . . ) The parameter can be either variable or complex expressions The parameters are evaluated separately, and then the function is invoked with the evaluation results. The evaluation result of the function expression is the function invocation result i. Service)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the function call calls the function of the script using an evaluation of the expression for each respective parameter, as conceptually seen from the teaching of Ouali, into that of Burman, Mimlitch, MacMillan, Muller and Rainisto because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Re Claim 18, it is the system claim, having similar limitations of claim 5. Thus, claim 18 is also rejected under the similar rationale as cited in the rejection of claim 5.
6. Claims 6 and 19 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), and further in view of Wong (US PGPub 20050102534).
As per Claim 6, Burman teaches of the method of claim 1, wherein: the application is associated with a first set of permissions, (Par 3, For example, a workflow applying a particular information technology (IT) policy to an enterprise user's computing device or account may consider the capabilities of the computing device as well as the user's profile and access permissions. Par 4, In order to obtain the user's profile and access permissions, the remote network management platform may be configured with appropriate credentials to access the remote service, as well as a schema thereof that defines tables, fields, forms, application programming interfaces, and so on that contain the sought-after information.)
None of Burman, Mimlitch, MacMillan, Muller and Rainisto specifically teaches, however Wong teaches that the script is associated with a second set of permissions; and the second set of permissions is different than the first set of permissions. (Par 133, Briefly summarized, the permissions associated with any file are three--read permission (permission to read from a file), write permission (permission to write to a file), and execute permission (permission to execute a file containing an executable program or shell script). (Slightly different permissions are associated with files that are directories of other files.) Par 135, The left-most digit defines the file access permissions which the user of an account grants to himself or herself--normally "7", meaning all permissions are granted. The middle digit defines the file access permissions which the user of the account grants to members of the group of which the user is a member, typically "3", meaning only "read" and "execute" permissions are granted. The right-most digit defines the access permissions the user of the account grants to all other users, typically "0", meaning no file access permissions are granted. Thus, a typical response to a call to the function "umask" might return the three digits "730," meaning that the user of this account has granted himself or herself all three permissions, has granted the members of that user's group read and execute permissions, and has granted all other users no permissions.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the script is associated with a second set of permissions; and the second set of permissions is different than the first set of permissions, as conceptually seen from the teaching of Wong, into that of Burman, Mimlitch, MacMillan, Muller and Rainisto because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Re Claim 19, it is the system claim, having similar limitations of claim 6. Thus, claim 19 is also rejected under the similar rationale as cited in the rejection of claim 6.
7. Claims 7 and 20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), in view of Wong (US PGPub 20050102534), and further in view of Brickell (US PGPub 20030115142).
As per Claim 7, none of Burman, Mimlitch, MacMillan, Muller, Rainisto and Wong specifically teaches, however Brickell teaches of the method of claim 6, wherein the operations further comprise: determining the second set of permissions; requesting, from the user, approval for the second set of permissions; and receiving, from the user, permissions approval approving the second set of permissions. (Par 19, The authentication server 106 provides authentication service by performing registration methods, such as the ones shown in FIGS. 8 and 9 and by performing authentication and authorization methods, such as the ones shown in FIGS. 5-7 and 10. Registration is the process of associating authentication verification information with an individual identity. Authentication is the process of authenticating a user 102 and associating a level of assurance with the authentication of the user 102. Authorization is the process of deciding whether to grant a request to a user 102 based on the request of the user 102, the permissions of the user 102, and the level of assurance provided by the authentication. Registration, authentication, and authorization may all be performed by one server, as shown in FIG. 1, or divided among a number of servers. For example, FIG. 4 shows a registration server, an authentication server, and an authorization server. Par 67, In another embodiment of the method, the dynamic authorization decision is based on a requested access level, authentication mechanisms used, and an account status)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add determining the second set of permissions; requesting, from the user, approval for the second set of permissions; and receiving, from the user, permissions approval approving the second set of permissions, as conceptually seen from the teaching of Brickell, into that of Burman, Mimlitch, MacMillan, Muller, Rainisto and Wong because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Re Claim 20, it is the system claim, having similar limitations of claim 7. Thus, claim 20 is also rejected under the similar rationale as cited in the rejection of claim 7.
8. Claims 8, 9, 11, 21, 22 and 24 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), and further in view of Weizman (US PGPub 20210064685)
As per Claim 8, Burman teaches of the method of claim 1, wherein, while the application is executing, the application: determines whether the trigger condition has been satisfied; when the trigger condition has been satisfied, calls; and receives, from the function, a result comprising an execution status and a data response. (Par 114, While the embodiments herein provide support for general workflow design, an example workflow design tool may be implemented based around specific definitions of triggers, actions, and workflow logic. Triggers may be used to specify conditions that start a workflow, such as a change to an entry in a database (e.g., the addition or updating of a configuration item in a CMDB) or according to a schedule (e.g., once per day or once per week). A trigger causes one or more actions to be performed, and each action may be controlled by workflow logic that specifies the conditions that must be true for the action to be performed. The action may involve changing the state of information in a database, sending a notification (e.g., an email) to a user, and so on.)
None of Burman, Mimlitch, MacMillan, Muller and Rainisto specifically teaches, however Weizman teaches of when the trigger condition has been satisfied, calls, using the function call, the function of the script; (Par 17, Asynchronous or “async” APIs, as used herein, are APIs in the browser 110 that, when called, ask the browser 110 to execute a callback function when the async API detects that a trigger condition is met. As used herein, a callback function (or “callback”) is code executed based on a trigger condition of an async API call and can be provided to the async API as an argument. In some implementations, the choice of async API (and some provided arguments) can set the trigger condition(s) defining the timing of a desired action, while the callback function (also provided as an argument) defines the desired action. A callback can include code, calls to other functions or APIs, or other actions. Therefore, after the initial API call, the execution of an async API is independent of (and executed asynchronously with) the execution of the script 160 calling the async API. Async APIs can trigger a callback for any reason (depending on the async API), for example, based on a certain event being observed or after a preset period of time. The callback associated with an async API call executes at the time the correct trigger conditions are met, and can trigger after the script 160 which originally called the async API has finished executing or is no longer active. In some embodiments, an API can exhibit a mixture of synchronous and asynchronous behavior depending, for example, on provided arguments or the specific situation when the API is called.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add when the trigger condition has been satisfied, calls, using the function call, the function of the script, as conceptually seen from the teaching of Weizman, into that of Burman, Mimlitch, MacMillan, Muller and Rainisto because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
As per Claim 9, Burman teaches of the method of claim 8, wherein the data response comprises a structured data response comprising: one or more fields: and type information for at least one field of the one or more fields. (Par 154, Doing so allows that API definition to be used to design the workflow to process and consume output from the remote service (e.g., values of data structure fields returned by the remote service). Common data formats, such as complex objects (JSON and/or XML), may be inherently supported. Par 218, In some embodiments, the result of the structured data query is represented on the set of workflow design GUIs as a hierarchy of selectable data items in accordance with the normalized format, and the set of workflow design GUIs allows dragging of one or more of the selectable data items into an input field of the further action. Par 44, First, the developer may define the data model, which specifies the types of data that the application uses and the relationships therebetween. Par 174, Specification pane 804 of FIG. 8A contains definitions of the inputs for the input step. Each input may be defined by label 806, type 808, mandatory indicator 810, and possibly other options not shown. Label 806 is a name for the input with which it can be referred. Type 808 is a data type of the input.)
As per Claim 11, Burman teaches of the method of claim 8, wherein, while the application is executing, the application further uses the received data response as an input to a process. (Par 169, At block 718, the workflow executes. When the workflow reaches the integration action, computational instance 322 transmits query 718A to remote service 710. This query requests specific content from remote service 710, such as a number of records in a particular table, or the values of a particular column in a particular table. Remote service 710 provides the results of the query as structured data in response 718B. The metadata action is used to parse the structured data.)
Re Claim 21, it is the system claim, having similar limitations of claim 8. Thus, claim 21 is also rejected under the similar rationale as cited in the rejection of claim 8.
Re Claim 22, it is the system claim, having similar limitations of claim 9. Thus, claim 22 is also rejected under the similar rationale as cited in the rejection of claim 9.
Re Claim 24, it is the system claim, having similar limitations of claim 11. Thus, claim 24 is also rejected under the similar rationale as cited in the rejection of claim 11.
9. Claims 10 and 23 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), in view of Weizman (US PGPub 20210064685), and further in view of Qing (US PGPub 20060248406).
As per Claim 10, none of Burman, Mimlitch, MacMillan, Muller, Rainisto and Weizman specifically teaches, however Qing teaches of the method of claim 8, wherein the application, based on the result, calls a second function of a second script. (Par 20-21, According to another aspect of the present application, there is provided a method for handling errors comprising: provisioning a runtime environment which executes applications comprising component definitions with computer-executable code for: accepting as input at least one component definition describing user-defined errors and a script function for error-handling to provide customized handling of such errors; and detecting user-defined errors and invoking the script function for error-handling in response to user-defined errors detected. Claim 3. The method as claimed in claim 2, detecting an error in said script-based application, wherein said handling said identified collected error comprises providing an indication indicative of said error detected and invoking an error-handling script function.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add the application, based on the result, calls a second function of a second script, as conceptually seen from the teaching of Qing, into that of Burman, Mimlitch, MacMillan, Muller, Rainisto and Weizman because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Re Claim 23, it is the system claim, having similar limitations of claim 10. Thus, claim 23 is also rejected under the similar rationale as cited in the rejection of claim 10.
10. Claims 13 and 26 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Burman (US PGPub 20210141617), in view of Mimlitch (US PGPub 20180285084), in view of MacMillan (US Patent 10466981), in view of Muller (US PGPub 20110197181), in view of Rainisto (US PGPub 20130024808), and further in view of Jouhier (US PGPub 20190391823).
As per Claim 13, none of Burman, Mimlitch, MacMillan, Muller and Rainisto specifically teaches, however Jouhier teaches of the method of claim 1, wherein executing the application comprises deploying the application for a second user, the second user different than the user. (Par 3, Increasingly, it is desirable to develop modern enterprise class software applications so that they are “extensible”. This means that they are created in such a way that they can be modified/extended to meet the particular needs of different end users. This modification is usually achieved by incorporating into the “base code” of the application (the software defining the core functionality of the application) “add-on” code which modifies or extends the core functionality of the application. Extensible development means that different instances of the application can be readily customised and deployed for different users. Par 42, FIG. 1 provides a schematic diagram depicting in simplified form the way in which instances of a modern enterprise class software application are developed and deployed for multiple different users.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective filing date of the claimed invention to add executing the application comprises deploying the application for a second user, the second user different than the user, as conceptually seen from the teaching of Jouhier, into that of Burman, Mimlitch, MacMillan, Muller and Rainisto because this modification can help design and develop the application using script text coding from graphical programming in order to further customize the application more than what graphical programming can provide.
Re Claim 26, it is the system claim, having similar limitations of claim 13. Thus, claim 26 is also rejected under the similar rationale as cited in the rejection of claim 13.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 9am-6pm. 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, 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-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.
/JAE U JEON/Primary Examiner, Art Unit 2193
Prosecution Insights