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 .
Status of Claims
This action is in reply to the application filed on 27 September 2024
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 24 February 2024 was filed after the mailing date of the initial disclosure but prior to any action on the merits. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Independent Claim 1 recites limitations for identifying a contract data requirements list deliverable associated with a program, determining whether the CDRL deliverable is associated with a milestone and whether there is a recurrence, and determining a delivery date. These limitations, as drafted, illustrate a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind. Identifying a deliverable and making determinations r illustrate high level observation and evaluation type functions that could be done the same way mentally or manually with a pen and paper. But for “with a controller” language, the claims encompass a user simply observing and making determinations in their mind. The mere nominal recitation of a generic computer component or computer system environment does not take the claim limitations out of the mental processes grouping. Thus, the claims recite a mental process, which is an abstract idea.
This judicial exception is not integrated into a practical application. The claims recite additional elements including displaying with the controller via a display, as well as the controller with which the identifying and determining functions are performed. The displaying is recited at a high level of generality and amount to mere data transmission outputting, which is a form of insignificant extra solution activity. The controller that performs the identifying and determining is also recited at a high level of generality and merely automates those steps. Each of the additional components is no more than mere instructions to apply the exception using a generic computer component in a particular computerize based environment. The combination of these additional elements is no more than mere instructions to apply the exception in a generic computer environment with generic computer components. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to step 2A Prong 2, the additional elements in the claims amount to no more than mere instructions to apply the exception using a generic computer component or linking the steps to a generic computer environment. The same analysis applies here in 2B and does not provide an inventive concept.
For the displaying step that was considered extra solution activity in step 2A above, this has been re-evaluated in step 2B and determined to be well-understood, routine and conventional activity in the field. The specification does not provide any indication that the controller is anything other than a generic, off the shelf computer component, and the Symantec, TLI and OIP Techs. court decisions in MPEP 2106.05 indicate that the mere collection, receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here.
Dependent claims 2-20 include all of the limitations of claim 1 and therefore recite the same abstract idea. The claims merely narrow the recited abstract idea by describing additional observation and evaluation steps including determining, identifying, describing what the list indicates and elements of the display and interface. The claims include additional elements for detecting, with the controller, updating, with the controller, querying, with the controller, displaying with the controller via a user interface, automatically updating, with the controller, accessing with the controller, describing the database entry, and switching between views. The additional elements recited fail to transform the claims into a patent eligible invention but instead describe additional extra solution activity including displaying (e.g. outputting/transmission, detecting (e.g. gathering), updating, querying, accessing and switching views (e.g. storing/gathering). When re-evaluated in step 2B these steps are determined to be well-understood, routine and conventional activity in the field. The specification does not provide any indication that the controller is anything other than a generic, off the shelf computer component, and the Symantec, TLI and OIP Techs. court decisions in MPEP 2106.05 indicate that the mere collection, receipt or transmission of data over a network is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here. Describing the database, elements in the display, interface checkboxes, and content links merely depicts the computer and interface environment but does not meaningfully limit the implementation of the recited abstract idea nor does it transform the claims into a patent eligible invention by amounting to significantly more.
Accordingly, claims 1-20 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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 and 8-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mantravadi et al. (US 2013/0246113) in view of Frank et al. (US 2006/0080136).
As per Claim 1 Mantravadi teaches:
A method comprising:
identifying, with a controller, a contract data requirements list (CDRL) deliverable associated with a program (Mantravadi in at least [0004, 0006, 0023, 0026, 0031, 0033-0034, 0038, 0040, 0045, 0052-0054, 0057, 0066] describe defining deliverables associated with a project or program including a plurality of commitments and requirements needed to fulfill the contract);
determining, with the controller, whether the CDRL deliverable is associated with a milestone of a plurality of milestones associated with the program (Mantravadi in at least [0009, 0023, 0027, 0036-0040, 0050, 0052, 0054-0055, 0059] describe determining that a deliverable is associated with a particular progress point, for example the system evaluates whether a user can invoice 20% of the contract amount when a particular deliverable is completed and another 20% when a different deliverable is completed and the last 60% when a 3rd deliverable is completed, see Figs 2-2E) and;
determining, with the controller, a delivery date for the CDRL deliverable based on whether the CDRL is associated with the milestone (Mantravadi in at least [0026, 0031, 0052-0054, 0057] describe determining a delivery date based on deliverable information including progress points for the project); and
displaying, with the controller via a display, a CDRL deliverable name of the CDRL deliverable and at least one of: the delivery date, a delivery status corresponding to the delivery date, and a delivery evaluation corresponding to the delivery date (Mantravadi in at least [0026, 0053, 0057] describe displaying a defined deliverable, specifics to the deliverable, the delivery date and price commitments, etc.).
Mantravadi does not explicitly recite determining whether the CDRL and deliverable are associated with a recurrence. However, Frank teaches a system and method for managing intellectual property. Frank describes managing an inventory of assets, products and marketing management for marketing projects associated with the products and assets. Frank further teaches:
whether the deliverable list is associated with a recurrence and whether the deliverable is associated with the recurrence (Frank in at least [0452-0453 and 0463] describe files of deliverables for tasks for projects, [0352] describes a GUI components for adding contacts and agreements including an add action button link as illustrated in at least Fig. 20 where an action can include designating whether an action is a recurring action and designating a time period for the recurrence and comments)
Therefore, it would be obvious to one of ordinary skill in the art to modify the deliverable definition and management functions to include techniques for designating and associating a recurrence because each of the elements were known, but not necessarily combined as claimed. The technical ability existed to combine the elements as claimed and the result of the combination is predictable because each of the elements performs the same function as it did individually. By enabling recurrence to be associated with deliverables, the combination enables a more customizable project definition that can perform continuous and ongoing analytics and management.
As per Claim 8 Mantravadi further teaches:
querying, with the controller, a milestone database with a milestone identification (ID) of the milestone, the milestone database associating at least one milestone ID with at least one milestone date; and in response to the querying, determining, with the controller, a milestone date associated with the milestone ID, wherein determining the delivery date comprises determining the delivery date according to the milestone date (Mantravadi in at least [0023, 0027, 0036-0037, 0039-0040, 0050, 0054-0055, 0059] describe the progress reporting component as well as the performance engine and datastore which interact in order to evaluate the progress and performance of the company against the defined deliverables and a variety other performance indicators including delivery dates, subtasks, tasks, and specific dates for each point as well as invoicing and cost metrics used to evaluate the progress against a timeline and other metrics).
As per Claim 9 Mantravadi further teaches:
displaying, with the controller via a user interface, a CDRL deliverable list indicating a plurality of CDRL deliverable names and at least one of: a plurality of delivery dates each associated with a respective one of the plurality of CDRL deliverables, a plurality of delivery statuses each associated with the respective one of the plurality of CDRLs, and a plurality of delivery evaluations each associated with the respective one of the plurality of CDRL deliverables (Mantravadi in at least [0023, 0026-0027, 0036-0037, 0039-0040, 0050, 0053-0055, 0057, 0059]] describe displaying defined deliverables, specifics to the deliverables, the delivery dates and price commitments, as well as progress reporting components and the performance engine that can compare and output actual vs. estimated performance by deliverable based on inputs including dates, cost, and other metrics).
As per Claim 10 Mantravadi further teaches:
wherein the CDRL deliverable list further indicates one or more CDRL group identifications (IDs) with which each of the plurality of CDRL deliverables is associated (Mantravadi in at least [0027] describes the plan generator as being able to divide the work required to deliver the deliverable into tasks and subtasks such that all the deliverables for a project can be evaluated during the progress of the plan or after completion by the reporting and performance engines, see also [0035-0036, 0043-0045, 0050, 0052]).
As per Claim 11 Mantravadi further teaches:
wherein the CDRL deliverable list further indicates one or more owners with which each of the plurality of CDRL deliverables is associated (Mantravadi in at least [0026-0027] and Fig. 1 illustrate and describe how the defined deliverable indicates assigned resources for projects, tasks, subtasks, and deliverables, the resources can include workers, e.g. associated owners, see also [0030, 0035]).
As per Claim 12 Mantravadi further teaches:
displaying, with the controller via the user interface, at least one add CDRL user interface (UI) element adjacent to the CDRL deliverable list, the at least one add CDRL UI element, upon being triggered, configured to cause display of at least one add CDRL interface for addition of a new CDRL deliverable or a new CDRL recurrence to the CDRL deliverable list (Mantravadi in at least Figs. 1 and [0026] illustrates and describes a display including an component to control deliverable definitions in response to clicking on the + or other interactive elements, [0028-0042] describes Figs. 2-2E which includes interface elements for adding and editing deliverables).
As per Claim 13 Mantravadi further teaches:
wherein the at least one add CDRL UI element comprises an add CDRL deliverable UI element, and wherein the at least one add CDRL interface comprises an add CDRL deliverable interface, and wherein the method further comprises: displaying the add CDRL deliverable interface in response to triggering the add CDRL deliverable UI element; (Mantravadi in at least Figs. 1 and [0026] illustrates and describes a display including an component to control deliverable definitions in response to clicking on the + or other interactive elements, [0028-0042] describes Figs. 2-2E which includes interface elements for adding and editing deliverables).
Mantravadi does not explicitly recite adding a recurrence UI element or in response to triggering the element displaying the recurrence interface. However, Frank teaches a system and method for managing intellectual property. Frank describes managing an inventory of assets, products and marketing management for marketing projects associated with the products and assets. Frank further teaches:
and an add CDRL recurrence UI element, and an add CDRL recurrence interface, and displaying the add CDRL recurrence interface in response to triggering the add CDRL recurrence UI element (Frank in at least [0452-0453 and 0463] describe files of deliverables for tasks for projects, [0352] describes a GUI components for adding contacts and agreements including an add action button link as illustrated in at least Fig. 20 where an action can include designating whether an action is a recurring action and designating a time period for the recurrence and comments)
Frank is combined based on the reasons and rationale set forth in the rejection of Claim 1 above.
As per Claim 14 Mantravadi further teaches:
automatically updating, with the controller, the CDRL deliverable list with the new CDRL deliverable or the new CDRL recurrence in response to submission of information corresponding to the new CDRL deliverable or the new CDRL recurrence using the at least one add CDRL interface (Mantravadi in at least Figs. 1 and 2-2E and [0026-0029] describe defining deliverables, [0036-0042] describes updating progress and status of deliverables including changing dates and information in the deliverable in the display when new information is added in the interface, see also [0045-0046, 0050, 0052-0053, 0059]).
As per Claim 15 Mantravadi further teaches:
wherein the at least one add CDRL interface comprises a checkbox to link the new CDRL deliverable or the new CDRL recurrence to the milestone (Mantravadi in at least [0030-0031, 0033, 0074-0075, 0076, 0083-0084] describe interface buttons and controls to link data).
As per Claim 16 Mantravadi further teaches:
accessing, with the controller, a CDRL database comprising a database entry for the CDRL deliverable, wherein the database entry comprises CDRL deliverable identification (ID) field, a milestone ID field, and a recurrence ID field (Mantravadi in at least [0004, 0006, 0023, 0026, 0031, 0033-0034, 0038, 0040, 0045, 0052-0054, 0057, 0066] describe defining deliverables associated with a project or program including a plurality of commitments and requirements needed to fulfill the contract).
As per Claim 17 Mantravadi further teaches:
wherein the database entry further comprises at least one of a deliverable content link field and a comments field (Mantravadi in at least [0030-0031, 0033, 0074-0075, 0076, 0083-0084] describe interface buttons and controls to link, enter and define data for deliverables, tasks, subtasks, etc. in a project, [0023, 0027, 0036-0037, 0039-0040, 0050, 0054-0055, 0059] describe the progress reporting component as well as the performance engine and datastore which interact in order to evaluate the progress and performance of the company against the defined deliverables and a variety other performance indicators including delivery dates, subtasks, tasks, and specific dates for each point as well as invoicing and cost metrics used to evaluate the progress against a timeline and other metrics)).
As per Claim 18 Mantravadi further teaches:
displaying, with the controller via a user interface, a near term view comprising a plurality of areas each associated with a respective one of a plurality of date ranges; and displaying, with the controller via the user interface, a plurality of CDRL deliverable names of a plurality of CDRL deliverables and a plurality of associated delivery statuses or a plurality of delivery evaluations in the plurality of areas according to respective delivery dates of the plurality of CDRL deliverables and the plurality of date ranges of the plurality of areas (Mantravadi in at least [0005, 0027, 0030-0031, 0033, 0035-0037, 0045, 0047, 0050-0057, 0064, 0077] describes displaying different views with different areas with different dates and times including estimated time for delivery and displaying a plurality of deliverables and progress information).
Distinguishable over Prior Art
Claims 2-7 and 19-20 are considered distinguishable over prior art. None of the prior art of record taken individually or in combination teach the limitations set forth in the claimed invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Housseini (US 20230401541) Intelligent Task Scheduling
Goodman et al. (US 20060059253) Architectures for Netcentric Computing Systems
McCormick (US 20130018802) Commercialization of a Pharmaceutical Product
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHANIE Z DELICH whose telephone number is (571)270-1288. The examiner can normally be reached on Monday - Friday 7-3:30.
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, Rutao Wu can be reached on 571-272-6045. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/STEPHANIE Z DELICH/Primary Examiner, Art Unit 3623