DETAILED ACTION
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 .
Disposition of Claims
Claims 1-20 are pending in the instant application. No claims have been added. Claims 2, 4-7, and 14-15 have been cancelled. Claims 1, 13, 16, and 20 have been amended. The rejection of the pending claims is hereby made final.
Response to Remarks
101
Regarding Applicant's assertions pertaining to the eligibility of the pending claims under 35 USC 101, the examiner has considered Applicant’s arguments and amendments pertaining to the rejection of claims 1, 3, and 8-12, and finds said arguments and amendments to be persuasive. The rejection of the aforementioned claims under 35 USC 101 is hereby withdrawn. Applicant’s arguments pertaining to the rejection of claims 13, and 16-20 have been considered by the examiner, but are not found to be persuasive. As stated in the previous Office Action, the examiner again submits that the Federal Circuit has found (see at least EPG v Alstom) that the collection, analysis, and display of certain results of collection and analysis to be a patent ineligible concept. The Court found that the process of gathering and analyzing information of a specified content, then displaying the results, devoid of any particular assertedly inventive technology for performing said functions to be directed to an abstract idea. The Federal Circuit has found that the when the focus of the claims is not on an improvement in computers as tools, but on certain independently abstract ideas that use computers as tools, that the claims fail to do more than merely selecting information, by content or source, for collection, analysis, and display does nothing significant to differentiate a process from ordinary mental processes, whose implicit exclusion from 101 undergirds the information based category of abstract ideas. The pending claims do not require an inventive set of components or methods that would generate new data and further do not invoke any inventive programming. The Courts have found that merely requiring the selection and manipulation of information to provide a humanly comprehensible amount of information useful for users, by itself does not transform the otherwise abstract processes of information collection and analysis. The two part analysis has to take into account how the desired result is achieved. The examiner submits that the computers, networks, and displays as recited in the pending claims does not transform the claimed subject matter into patent-eligible applications. The pending claims do not require any nonconventional computer, network, or display components or even a non-conventional and non-generic arrangement of known conventional pieces, but merely call for performance of the claimed information collection, analysis, and display functions on a set of generic computer components and display devices. Nothing in the claims, given their broadest reasonable interpretation in light of the specification, requires anything other than off the shelf, conventional computer, network, and display technology for gathering, sending, and presenting the desired information. The pending claims further fail to include any requirement for performing the claimed functions of gathering, analyzing, and displaying in real time by use of anything other than generic technology. The examiner submits that the limitation “task” as recited in the pending claims is described in at least paragraphs [0047]-[0055] of Applicant’s specification, wherein the creation and generation of tasks is reliant upon user interaction. The claims therefore do not state an arguable inventive concept in the realm of application of the information based abstract idea. The examiner further submits that the language of the claim is silent regarding the limitation “execution”, and as currently recited, and given its broadest reasonable interpretation consistent with the state of the art at the time of filing, does not positively recite being performed by or linked to a hardware device. Appropriate correction and/or clarification is required.
For at least the reasoning provided above, the examiner submits that the rejection of claims 13 and 16-20 under 35 USC 101 is hereby maintained and made final.
103
Due to Applicant’s arguments and amendments the previous office action is now moot and the claims have been given further searching and consideration. Consequently, please find a new rejection below addressing the amended claims.
Claim Rejections - 35 USC § 101
5. 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.
6. Claims 13, and 16–20 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.
In sum, claims 13, and 16–20 are rejected under 35 U.S.C. §101 because the claimed invention is directed to a judicial exception to patentability (i.e., a law of nature, a natural phenomenon, or an abstract idea) and do not include an inventive concept that is something “significantly more” than the judicial exception under the 2106 MPEP patentable subject matter eligibility guidance analysis which follows.
Under the 2106 MPEP step 1 analysis, it must first be determined whether the claims are directed to one of the four statutory categories of invention (i.e., process, machine, manufacture, or composition of matter). Applying step 1 of the analysis for patentable subject matter to the claims, it is determined that the claims are directed to the statutory category of a method and a computer readable storage medium(claims 13 and 15-20), where the computer readable storage medium is substantially directed to the subject matter of the method. (See, e.g., MPEP §2106.03). Therefore, we proceed to step 2A, Prong 1.
Under the 2106 MPEP step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more designated categories of patent ineligible subject matter (i.e., organizing human activity, mathematical concepts, and mental processes) that amount to a judicial exception to patentability. Here, the claims recite the abstract idea of generating and conveying tasks by:
generating, for display at a client device, a user interface for creating and configuring a custom task associated with one or more enterprise software applications, the user interface displaying a plurality of components, and the custom task being configurable by adding one or more components to the custom task, reordering the one or more components, configuring a property of the one or more components, and/or deleting the one or more components from the custom task; updating the user interface to support creating and configuring a form for soliciting one or more users inputs specifying the value of the variable during the execution of the custom task; receiving, through the user interface, one or more user inputs configuring the custom task; and generating, based on the one or more user inputs, the custom task for subsequent execution;
updating the user interface to support creating and configuring an automation;
receiving, through the updated user interface, a first user input creating the automation;
receiving, through the updated user interface, a second user input adding the custom task to the automation; and
generating, based at least on the first user input and the second user input, the automation including the custom task.
Here, the recited abstract idea falls within one or more of the three enumerated 2106 MPEP categories of patent ineligible subject matter, to wit: the category of certain methods of organizing human activity, which includes fundamental economic practices or principles and commercial or legal interactions (e.g., creating and disseminating tasks using a display, which constitutes following rules or instructions).
Under the 2106 MPEP step 2A, Prong 2 analysis, the identified abstract idea to which the claim is directed does not include limitations that integrate the abstract idea into a practical application, since the recited features of the abstract idea are being applied on a computer or computing device or via software programming that is simply being used as a tool (“apply it”) to implement the abstract idea. (See, e.g., MPEP §2106.05(f)). Therefore, the claim is directed to an abstract idea.
Under the 2106 MPEP step 2B analysis, the additional elements are evaluated to determine whether they amount to something “significantly more” than the recited abstract idea. (i.e., an innovative concept). Here, the additional elements, such as: a “processor,” and “memory” do not amount to an innovative concept since, as stated above in the step 2A, Prong 2 analysis, the claims are simply using the additional elements as a tool to carry out the abstract idea (i.e., “apply it”) on a computer or computing device and/or via software programming. (See, e.g., MPEP §2106.05(f)). The additional elements are specified at a high level of generality to simply implement the abstract idea and are not themselves being technologically improved. (See, e.g., MPEP §2106.05 I.A.). Independent claim 20 is nearly identical to independent claim 13 and so the analysis for claim 13 also applies to claim 20.
Dependent claims 16–19 have all been considered and do not integrate the abstract idea into a practical application.
The additional elements of the dependent claims merely refine and further limit the abstract idea of the independent claims and do not add any feature that is an “inventive concept” which cures the deficiencies of their respective parent claim under the 2019 PEG analysis. None of the dependent claims considered individually, including their respective limitations, include an “inventive concept” of some additional element or combination of elements sufficient to ensure that the claims in practice amount to something “significantly more” than patent-ineligible subject matter to which the claims are directed.
The elements of the instant process steps when taken in combination do not offer substantially more than the sum of the functions of the elements when each is taken alone. The claims as a whole, do not amount to significantly more than the abstract idea itself because the claims do not effect an improvement to another technology or technical field (e.g., the field of computer coding technology is not being improved); the claims do not amount to an improvement to the functioning of an electronic device itself which implements the abstract idea (e.g., the general purpose computer and/or the computer system which implements the process are not made more efficient or technologically improved); the claims do not perform a transformation or reduction of a particular article to a different state or thing (i.e., the claims do not use the abstract idea in the claimed process to bring about a physical change. See, e.g., Diamond v. Diehr, 450 U.S. 175 (1981), where a physical change, and thus patentability, was imparted by the claimed process; contrast, Parker v. Flook, 437 U.S. 584 (1978), where a physical change, and thus patentability, was not imparted by the claimed process); and the claims do not move beyond a general link of the use of the abstract idea to a particular technological environment (e.g., simply claiming the use of a computer and/or computer system to implement the abstract idea). Appropriate correction and/or clarification is required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 8-13, and 16–20 are rejected under 35 U.S.C. 103 as being unpatentable over Tattrie et al (US 2005/0066304) in view of Singh et al (US 2015/0378716).
Regarding claim 1, the prior art discloses a system, comprising: at least one data processor (see at least paragraph [0032] to Tattrie et al); and at least one memory storing instructions which, when executed by the at least one data processor (see at least paragraph [0032] to Tattrie et al), result in operations comprising: generating, a user interface for creating and configuring a custom task associated with one or more enterprise software applications, the user interface displaying a plurality of components (see at least paragraph [0038] to Tattrie et al “The screens of FIGS. 2 through 8 may be implemented in C# as web pages under XML (Extensible Markup Language), HTML (HyperText Markup Language) or any other scripts or methods of creating displayable data, such as the Wireless Access Protocol ("WAP"). The screens or web pages provide facilities to receive input data, such as a form with fields to be filled in, pull-down menus or entries allowing one or more of several options to be selected, buttons, sliders, hypertext links, or other known user interface tools for receiving user input”), and the custom task being configurable by adding one or more components to the custom task (see at least paragraph [0051] to Tattrie et al “defining a name for a model and associating an image with the model; defining tasks for the model (e.g., number of tasks, type of each task, responsible user(s) for the task, email notifications for the tasks, etc.); defining links and rework links used to connect tasks in the model; creating or importing forms or web forms for the tasks in the model; creating business rules or workflow logic for the links and rework links connecting the tasks; and defining directory and server names for deploying forms”), reordering the one or more components, configuring a property of the one or more components, and/or deleting the one or more components from the custom task (see at least paragraphs [0052] and [0053] to Tattrie et al “he user of the workflow application may use various built-in components and custom components to create workflow models, such as the built-in and custom components of FIG. 1 (104 and 114, respectively). From the perspective of the end user, such components may be introduced into a model design canvas, such as the design view 202 of FIG. 2, using "drag-and-drop" and/or "snap-on" functionality”);
Displaying, at a client device, the user interface;
receiving, through the user interface, one or more user inputs configuring the custom task (see at least paragraph [0053] to Tattrie et al “. A task 402 is the basic workflow object used to model one step of a workflow. A web form 404 is a form generally used when the user knows that the primary user interface for gathering and viewing data is a web browser”); generating, based on the one or more user inputs, the custom task for subsequent execution (see at least paragraph [0053] to Tattrie et al “ A system workflow object 406 is a special task that is automatically executed by the workflow application without the need for any user interaction or initiation”).
Tattrie et al does not appear to explicitly disclose wherein the custom task comprises a sequence of actions corresponding to the one or more components added to the custom task, and wherein each action in the sequence of actions is associated with one or more inputs and/or outputs; in response to at least one input or output of the one or more inputs and/or outputs being defined as a variable associated with a value that is provided during an execution of the custom task, updating the user interface to support creating and configuring a form for soliciting one or more user inputs specifying the value of the variable during the execution of the custom task; updating the user interface to support creating and configuring an automation; receiving, through the updated user interface, a first user input creating the automation; receiving, through the updated user interface, a second user input adding the custom task to the automation; and generating, based at least on the first user input and the second user input, the automation including the custom task.
However, Singh et al discloses methods and apparatus to update application deployments in cloud computing environments, wherein the custom task comprises a sequence of actions corresponding to the one or more components added to the custom task, and wherein each action in the sequence of actions is associated with one or more inputs and/or outputs (see at least paragraph [0033] to Singh et al); in response to at least one input or output of the one or more inputs and/or outputs being defined as a variable associated with a value that is provided during an execution of the custom task, updating the user interface to support creating and configuring a form for soliciting one or more user inputs specifying the value of the variable during the execution of the custom task (see at least paragraph [0047] to Singh et al); updating the user interface to support creating and configuring an automation (see at least paragraph [0054] to Singh et al); receiving, through the updated user interface, a first user input creating the automation; receiving, through the updated user interface(see at least paragraph [0055] to Singh et al), a second user input adding the custom task to the automation (see at least paragraph [0057] to Singh et al); and generating, based at least on the first user input and the second user input, the automation including the custom task(see at least paragraph [0059] to Singh et al).
Tattrie et al and Singh et al, in combination, do not appear to explicitly disclose wherein the user interface includes a plurality of panels comprising a first panel displaying a list of the one or more components added to the custom task, a second panel displaying elements that enable the reordering of the one or more components, and a third panel displaying the one or more inputs and/or outputs associated with the custom task and a list of properties for customizing the one or more components.
However, Choi et al discloses a system and method for component based software development, wherein the user interface includes a plurality of panels comprising a first panel displaying a list of the one or more components added to the custom task, a second panel displaying elements that enable the reordering of the one or more components, and a third panel displaying the one or more inputs and/or outputs associated with the custom task and a list of properties for customizing the one or more components (see at least paragraph [0054] and Figure 2, to Choi et al, wherein A graphical user interface (GUI) 200 provided by the graphical user interface (GUI) providing unit 110, as illustrated in FIG. 2, includes a first region 210 displaying information on a project presently working, a second region 220 displaying elements stored in a global component storage unit 142, a third region 230 generating and assembling the function-level component, a fourth region 240 displaying an attribute of an element selected in the graphical user interface 220, and a fifth region 250 displaying various kinds of messages, such as an error message and so on, generated in a build process. The regions may be located in any part of the graphical user interface 200. For example, although the first region 210 is shown in FIG. 2 on the right, the first region 210 may also be located at the top of the screen, the bottom of the screen, or on the left. Similarly, the regions may be included in one window, as shown in FIG. 2, or may be located in separate windows).
The examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). The examiner submits that the combination of the teaching of the system and method for custom and customizable components, such as for workflow applications, as disclosed by Tattrie et al and the methods and apparatus to update application deployment in cloud computing environments, as taught by Singh et al, further in view of the system and method for component based software development, in order to customize a user interface to streamline the user inputs necessary to implement task completion could have been readily and easily implemented, with a reasonable expectation of success. As such, the aforementioned combination is found to be obvious to try, given the state of the art at the time of filing.
Regarding claim 3, the prior art discloses the system of claim 1, wherein at least one input or output of the one or more inputs and/or outputs is defined as a fixed value (see at least paragraph [0059] to Tattrie et al “With the GenerateDocument action 524, the merge fields of the templates are bound to the corresponding elements or notes in an XML data object”)the term “fixed value” was interpreted in view of paragraph [0052] of Applicant’s specification wherein “To customize the content of a particular component within the custom task, one or more properties of the component may be directly modified in the Extensible Markup Language (XML) view of the custom task if the selected value is a constant or fixed value”.
Regarding claim 8, the prior art discloses the system of claim 1, wherein the operations further comprise: receiving, through the updated user interface, a third user input adding one or more activities to the automation or process including the custom task; and generating, based at least on the third user input, the automation or process to include the custom task as well as the one or more activities (see at least paragraph [0061] to Tattrie et al “ the workflow application may be configured for enhancement via the use custom components, such as the custom components and/or actions 114 of FIG. 1. A developer or other user with general programming skills may create such custom components in an integrated development environment, such as the integrated development environment 118 of FIG. 1. In this way, the developer can create one or more custom components that provide additional functionality that an end user can use to develop workflow models. As with the built-in components of FIGS. 4 and 5, the custom components may also provide "drag-and-drop" and/or "snap-on" functionality to make things easy for the end user”).
Regarding claim 9, the prior art discloses the system of claim 8, wherein the one or more activities include a log message activity for displaying an output of the custom task (see at least paragraph [0060] to Tattrie et al, wherein “ A SendEmail action 528 allows the user to construct an email message and associate it to a task workflow object”).
Regarding claim 10, the prior art discloses the system of claim 1, wherein the generating of the custom task includes generating a corresponding custom task object having an Extensible Markup Language (XML) view and one or more bindings (see at least paragraph [0082] to Tattrie et al “user friendly data binding, such as drag and drop data binding, in a workflow application”).
Regarding claim 11, the prior art discloses the system of claim 10, wherein the custom task is configured by at least modifying the Extensible Markup Language (XML) view of the custom task (see at least paragraph [0038] to Tattrie et al “XML”).
Regarding claim 12, the prior art discloses the system of claim 10, wherein the one or more bindings are created in response to a component in the custom task being linked to a variable input or a variable output (see at least paragraph [0038] to Tattrie et al, wherein “The screens or web pages provide facilities to receive input data, such as a form with fields to be filled in, pull-down menus or entries allowing one or more of several options to be selected, buttons, sliders, hypertext links, or other known user interface tools for receiving user input.”).
Claims 13 and 16-20 each contain recitations substantially similar to those addressed above and, therefore, are likewise rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
The examiner has considered all references listed on the Notice of References Cited, PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TALIA F CRAWLEY whose telephone number is (571)270-5397. The examiner can normally be reached on Monday thru Thursday; 8:30 AM-4:30 PM EST.
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, Fahd A Obeid can be reached on 571-270-3324. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TALIA F CRAWLEY/Primary Examiner, Art Unit 3627