DETAILED ACTION
Status of Claims
The present application, filed on or after 3/16/2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the Remarks and Amendments filed 06/10/2026.
Claims 1-22, 25-26, 31-32, 37-38 remain canceled.
Claims 23, 29, 35 have been amended.
Claims 23-24, 27-30, 33-36, and 39-40 have been examined and are pending.
(AIA ) Examiner Note
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned at the time any inventions covered therein were effectively filed absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned at the time a later invention was effectively filed in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Official Notice / Admitted Prior Art
With regard to claims 23-24, 27-30, 33-36, and 39-40, the common knowledge (i.e. generic “machine learning models” were old and well-known to a person of ordinary skill in the art before the effective filing date of the claimed invention and were useful to automate tasks) declared to be well-known in the art is hereby taken to be Applicant admitted prior art because the Applicant failed to traverse the Examiner’s assertion of Official Notice. To adequately traverse such a finding, an applicant must specifically point out the supposed errors in the Examiner’s action, which would include stating why the noticed fact is not considered to be common knowledge or well-known in the art. See 37 CFR 1.111(b). See also Chevenard, 139 F.2d at 713, 60 USPQ at 241 (“[I]n the absence of any demand by Applicant for the examiner to produce authority for his statement, we will not consider this contention.”). A general allegation that the claims define a patentable invention without any reference to the Examiner’s assertion of Official Notice is inadequate. Support for the Applicant’s assertion should be included. Because Applicant failed to traverse Examiner’s Official Notice, the common knowledge or well-known in the art statement is taken to be admitted prior art. See MPEP 2144.03(C).
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 23-24, 27-30, 33-36, and 39-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (i.e. a judicial exception) without significantly more.
Per step 1 of the 2019 Revised Patent Subject Matter Eligibility Guidance, the claims are directed towards a process, machine, or manufacture.
Per step 2A Prong One, the claims recite specific limitations which fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG, as follows:
Per Independent claims 23, 39, and 35:
“[A / the] method…, comprising:
Initializing,…, an inventory of project elements…;
Creating, a model for the project comprising the specified project name…;
adding to the created project model an instance of the selected project element and the specified attribute value.
determine a schedule and a budget for the instance added to the project;
…determine a subset of the project elements among the inventory of project elements;
As noted supra, these limitations fall within at least one of the groupings of abstract ideas enumerated in the 2019 PEG. Specifically, these limitations fall within the group Certain Methods Of Organizing Human Activity (e.g. fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
That is, the steps as drafted are not technical in nature and are not a technical solution to a technical problem but instead are a business decision to create a model of a business project (as is done by project managers and/or business owners), such as naming a project and adding pre-specified project elements to a model with a specific attribute value for the project element, and recommending a subset of elements which may be related to or necessary to implement a specified project attribute – all of which are business activities thus falling into Certain Methods of Organizing Human Activity. Note that there is no particular technique or method of “creating… a model for the project”; instead, such creation is left to the creativity of the practitioner of the claims reinforcing the finding that the claims contain an abstract idea. Furthermore, the mere nominal recitation of a generic computing environment and/or generic computing hardware intended to implement the idea (e.g. performing this method “in a computing system”, “one or more processors”, a “memory”, etc…) does not take the claim limitations out of the enumerated grouping. Thus, the claims recite an abstract idea.
Per step 2A Prong 2, the Examiner finds that the judicial exception is not integrated into a practical application. Although there are additional elements, other than those noted supra, recited in the claims, none of these additional element(s) or a combination of elements as recited in the claims apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that it is more than a drafting effort designed to monopolize the exception. As drafted, the claims as a whole merely describe how to generally “apply” the aforementioned concepts and link them to a field of use (i.e. in this case project modeling, e.g. as is done by project managers, project owners, etc…) or serve as insignificant extra-solution activity (such as data-gathering). The claimed computer components are recited at a high level of generality and are merely invoked as tools to implement the idea but are not technical in nature. Simply implementing the abstract idea on or with generic computer components is not a practical application of the abstract idea.
These additional limitations are as follows:
“A method of integrating a computing system into a healthcare system, comprising:... by a machine learning model,… [an inventory of project elements] that identifies project elements usable to assemble a plurality of projects within the healthcare system; for each of a plurality of project element types: for each of one or more project elements of the project element type:
receiving user input naming the project element; receiving user input specifying an attribute of the project element; and adding to the inventory of project elements a project element reflecting the received user input; and for each of a plurality of projects: receiving user input specifying a name for the project;… saving, by the machine learning model, the model in the project model data store, and displaying, by the machine learning model, the model in the project model data store on a first dynamic display area; and for each of a plurality of the project elements among the inventory of project elements: receiving user input selecting the project element for the project; and receiving user input specifying a value for the attribute specified for the project element;… and; wherein, upon addition of the instance of the selected project element and the specified attribute value, the machine learning model…; receiving user input specifying a project attribute value; storing the specified project attribute value in the project model created for the project;… displaying a recommendation, by the machine learning model, on a second dynamic display area with the subset of the project elements among the inventory of project elements, wherein the recommendation regarding the subset of the project elements comprises one or more of: rearranging, omitting, including, dividing, and combining the subset of the project elements.”
However, these elements do not present a technical solution to a technical problem; i.e. the description that applicant’s method/system is for the intended purpose of being integrated within “a healthcare system” is merely the field of choice in which the abstract idea is intended to be practiced but this descriptive context is not more than the abstract idea. Instead, it provides context but does not further illuminate how the core steps of the abstract idea are to be performed nor does it serve to integrate the abstract idea into a practical application thereof. Furthermore, Applicant’s invention is not a technique nor technical solution for “receiving” user input for a model, regardless of the intended use of such input (e.g. specifying a project name, or value, or project attribute value, etc…), nor is it a technique of “storing” or “adding” input to a model inventory [database]. Applicant also has not invented a technical solution for “displaying” a recommendation regardless of the subject of the recommendation. Note that applicant’s claims are so generic and high-level that it appears the invention, as claimed, does not actually require any automated mechanism or technical means by which a “recommendation” is created but only to display such recommendation; the actual means by which generation of such recommendation is accomplished may be a human’s own idea or creativity or mental decision. Therefore, the displaying a recommendation and the description of the recommendation are nothing but insignificant extra-solution activity as relates to the aforementioned abstract ideas.
The additional elements do not recite a specific manner of performing any of the steps core to the already identified abstract idea. Instead, these features merely serve to generally “apply” the aforementioned concepts using generic computer components, or link them to a field of use (e.g. project management within the health care industry) or, are insignificant pre-solution activity or insignificant extra-solution activity in regards to the already identified abstract idea and do not integrate the abstract idea into a practical application thereof.
Per Step 2B, the Examiner does not find that the claims provide an inventive concept, i.e., the claims do not recite additional element(s) or a combination of elements that amount to significantly more than the judicial exception recited in the claim. As discussed with respect to Step 2A Prong Two, the additional elements in the independent claims were considered as merely serving to generally “apply” the aforementioned concepts via generically described computer components (e.g. in a “computing environment” or by one or more “processors”, etc…) and “link” them to a field of use (i.e. project management via project modeling within health care), or as insignificant extra-solution activity (data-gathering and storage of data in a generic inventory). For the same reason these elements are not sufficient to provide an inventive concept; i.e. the same analysis applies here in 2B. Mere instructions to apply an exception using a generic computer component and conventional data gathering cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. So, upon revaluating here in step 2B, these elements are determined to amount to no more than mere instructions to apply the exception using generic computer components (i.e. a server) and/or gather and transmit data which is well-understood, routine, conventional activity in the field; i.e. note the Symantec, TLI, and OIP Techs Court decisions cited in MPEP 2106.05(d)(ll) indicate that mere 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).
Accordingly, alone and in combination, these elements do not integrate the abstract idea into a practical application, as found supra, nor provide an inventive concept, and thus the claims are not patent eligible.
As for the dependent claims, the dependent claims do recite a combination of additional elements. However, these claims as a whole, considered either independently or in combination with the parent claims, do not integrate the identified abstract idea into a practical application thereof nor do they provide an inventive concept.
For example, dependent claims 24, 30, and 36 recite the following: “…wherein the plurality of project element types comprise project phase, project activity, project key event, and project checklist item.” However, descriptions of the intended use of input data is merely a part of the already identified abstract idea and not significantly more than the abstract idea itself. Note this is not technical in nature and is a choice by the project manager/owner regarding their business decision pertaining how to organize and model their project.
Therefore, the Examiner does not find that these additional claim limitations integrate the abstract idea into a practical application nor provide an inventive concept. Instead, these limitations, as a whole and in combination with the already recited claim elements of the parent claims, are not significantly more than the already identified abstract idea. A similar finding is found for the remaining dependent claims.
For these reasons, the claims are not found to include additional elements that are sufficient to amount to significantly more than the judicial exception and are therefore patent ineligible.
Please see the 2019 Revised Patent Subject Matter Eligibility Guidance published in the Federal Register (84 FR 50) on January 7, 2019 (found at http://www.uspto.gov/patent/laws-and-regulations/examination-policy/examination-guidance-and-training-materials).
Claim Rejections - 35 USC § 103 (AIA )
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claims 23-24, 27-30, 33-36, and 39-40 are rejected under 35 U.S.C. 103 as obvious over Fernandez (US 2015/0088569 A1; hereinafter, “Fernandez”) in view of Applicant Admitted Prior Art and De Wind et al. (US 2019/0303825 A1; hereinafter, “DeWind”)
Claims 23, 29, 35: (Currently amended)
Pertaining to claims 23, 29, and 35 exemplified in the method steps of claim 23, Fernandez as shown teaches the following:
A method […], comprising:
Initializing, […], an inventory of project elements that identifies project elements usable to assemble a plurality of projects […] (Fernandez, see at least [0025], e.g.: “…The disclosed systems and methods support each team in determining how best to respond to a particular task [a task/activity is a type of project element], group of tasks, or project phase within its own environment. Each team may specify [initialize] a preferred order in which any task/phase [types of project elements] should be processed compared to others. Thus, when a deliverable [project attribute] to be created is entered into the system, for example as part of an asset list, its component tasks behave as a workflow comprising data objects. The data objects are then treated in accordance with team attributes specific to that team. Tasks [project elements] are scheduled automatically or recommended by the system, taking into account task priorities specific to the project, and taking into account team attributes, settings for approvals, and automation of certain task phases…”; see also at least [0042], e.g.: “…Server 340 comprises a project management application 350, and project content 360 such as project information that may be stored in a database [inventory], for example. In one aspect, project information [e.g. including project elements] may be obtained from internal users and abstracted for presentation to external users, as will be described…”; Fernandez’s “task/phase” [types of project elements] are useable to assemble projects, e.g. see at least [0092], e.g.: “…Exemplary interactions include, but are not limited to, (1) reference to files on a cloud storage service, (2) creating, modification and synchronization of equivalent objects on other project/production tracking services [usable to assemble projects], such as comments, tasks [project element], projects, etc….”);
for each of a plurality of project element types: for each of one or more project elements of the project element type:
receiving user input naming the project element; receiving user input specifying an attribute of the project element; and adding to the inventory of project elements a project element reflecting the received user input, (Fernandez, see at least [0048]-[0055], e.g.: “…For example, … activities [an activity is a type of project element] may be defined [named] in a central list [added to an inventory of project elements] that determines where tasks [project elements] and conversations associated with these tasks will be viewable. In an embodiment, tasks [project element] may be tagged [specifying an attribute of a project element] with predetermined tags or sets of tags, and filters may operate on the tags to provide views of information having a scope determined by the tags and by user roles.…”; also note at least [0009] noting “Teams may specify a priority [another attribute] of any task [project element]…”) such that the project element is usable to assemble the plurality of projects (Fernandez, see at least [0092], e.g.: “…Exemplary interactions include, but are not limited to, (1) reference to files on a cloud storage service, (2) creating, modification and synchronization of equivalent objects on other project/production tracking services [usable to assemble projects], such as comments, tasks [project element], projects, etc….”)
; and
for each of the plurality of projects:
receiving user input specifying a name for the project (Fernandez, see citations noted supra including again Fig. 35 and [0093]-[0094], e.g.: “….In the example of FIG. 35, a project is added [input] into the system [data store], where project specification data, such as name ("Zombies 3") [receiving user input specifying a name for the project], description, project revenue, and contractual start and end date may be specified…”
PNG
media_image1.png
700
1184
media_image1.png
Greyscale
);
creating, […] a model for the project comprising the specified project name,] saving […] the model in the project model data store, and displaying […] the model in the project data store on a first dynamic display area (Fernandez, see citations noted supra and also at least Fig. 35 [a first dynamic display area] where the model is displayed from storage; and per at least [0093]-[0094], e.g.: “….In the example of FIG. 35, a project is added [input and saved] into the system [data store], where project specification data, such as name ("Zombies 3") [receiving user input specifying a name for the project], description, project revenue, and contractual start and end date may be specified…”; project model is created and saved, e.g. via a “Add Project” interface depicted per Fig. 35 and then displayed as depicted per at least Fig. 35); and
for each of a plurality of the project elements among the inventory of project elements:
receiving user input selecting the project element for the project; and receiving user input specifying a value for the attribute specified for the project element; and adding to the created project model an instance of the selected project element and the specified attribute value (Fernandez, see citations already noted supra, and also at least [0011] in view of [0076] and [0099]-[0102] teaching a list of “tasks” and “assets” [types of project elements] for a project may be displayed, a task/asset [the project element for the project] may be selected [receiving user input selecting the project element] and task data may be updated, such as updating expected hours [attribute values] estimated to be required to complete a task, or updating specific comments [attribute values] or, inputting a “priority setting” for the task [specifying an attribute value for the project element], etc… For example, per [0100]: “…FIG. 46 illustrates an exemplary screenshot of a task update for a project, where, in this example, the rigging (i.e., binding digital skeleton to a 3D mesh) of a deliverable is indicated, together with a comment update…”); and
wherein, upon addition of the instance of the selected project element and the specified attribute value, […] automatically determine a schedule (Fernandez, see citations noted supra in view of at least Fig. 4 and [0072], e.g. #430-#440 “Generate a schedule for completing the tasks”; note Fernandez teaches: “….FIG. 4 shows a method of an illustrative implementation. As shown, the method starts by the system obtaining information ofa project to be completed, assets of the project, and tasks to complete the assets, 410. The system also obtains an estimate of the resources to complete each task, and calculates internal resource estimates for the tasks, 420. The system obtains a measure of the resources consumed toward the completion of each task, and calculates actual totals of resources consumed on project assets and the project as a whole, 430. A schedule for completing the tasks is obtained or generated automatically, 440…”) and a budget for the instance added to the project (Fernandez, see citations noted supra, including again at least [0029], e.g.: “…[0029] Cost reporting may be tracked, forecasted, and viewed based on individual tasks. Profitability analysis may be based on inputs that account for all resources already used and estimated to be required to complete the project. Project tasks may be ordered based on their respective priority, such as for scheduling and resource management. Efficiency may be determined by comparing the estimated time and resources needed to complete tasks to what has been logged and expended against those tasks. Updates can be provided periodically, such as at the end of every day, or in real time and updated with each new input of relevant information. In an exemplary aspect, assets may be assigned to a group of project participants, and the group's tasks may take on attributes of the group…”; applicant’s generically referenced “budget” reads on Fernandez’s teachings herein.);
for a project in the plurality of projects:
receiving user input specifying a project attribute value; storing the specified project attribute value in the project model created for the project (Fernandez, see at least a [0055], e.g. “…the system provides an interface with which a user enters information of a project, which is defined as having deliverables [project attribute values], and a deliverable list may be generated therefrom. Further, each deliverable is defined as comprising one or more tasks [project elements], and information of the tasks may be entered via the user interface. Tasks are thereby easily associated with a specific deliverable of a specific project…”; see also at least [0065]-[0070], teaching e.g.: “…a deliverable [a project attribute value] is entered [therefore received and stored] into the system, for example as part of an asset list…”); and causing […], for inclusion in the project and based on the specified project attribute value, to determine a subset of the project elements among the inventory of project elements (Fernandez, see citations noted supra and also at least [0065]-[0070] “….Tasks [project elements] are… recommended [e.g. determined for inclusion in the project], taking into account [implies learning] task priorities specific to the project [i.e. a proper subset related to the deliverable of the project] and taking into account team attributes, settings for approvals, and automation of task phases followed through accordingly…”; see also [0046], e.g.: a proper number of meetings, which is a task [subset of project elements], may be recommended based on project task attributes related to the particular project deliverable(s) [project attribute values]).
displaying a recommendation, […], on a second dynamic display area regarding the subset of the project elements among the inventory of project elements, wherein the recommendation regarding the subset of the project elements comprises one or more of rearranging, omitting, including, dividing, and combining the subset of the project elements (Fernandez, see citations noted supra, e.g. per at least [0046] and [0065]-[0070], e.g.: “…The auto-scheduling by the system can readjust timelines as needed, automatically filling gaps arising from changes in timelines with subsequent tasks, for example, in priority order. …other tasks will be reordered and moved around it accordingly. In an embodiment, the system may reassign tasks to levelize workloads of staff members working on a project or may recommend to a manager to reassign tasks. Such automatic reassignment or recommendation may be based on an analysis of staff member efficiencies, known skill sets, and the like… reassignments may be made or recommended based on known or unexpected interruptions in a staff member's schedule, such as due to a looming vacation, or an unexpected health issue from an accident or disease, for example…”)
The difference between the claim feature and the teachings of Fernandez is that Fernandez may not explicitly teach a “machine learning model” is the mechanism by which his system automates or otherwise performs various tasks which his system does perform as claimed, e.g. “initializing”, “saving”, “creating”, “displaying”, “determining”, “recommending”, etc… even though Fernandez’ system somehow learns, i.e. takes into account, task priorities specific to his project, team attributes, settings, etc… to perform the tasks as shown supra. However, again per [0025] Fernandez has been shown to teach “automation of certain task phases” which implies some type of machine logic is used to automate such tasks. Furthermore, Applicant Admitted Prior Art has noted: generic “machine learning models” were old and well-known to a person of ordinary skill in the art before the effective filing date of the claimed invention and were useful to automate tasks. Therefore, in view of these findings, the Examiner understands Fernandez provides motivation to use old and well-known automated methods such as machine learning models to automate his tasks and the Examiner finds that using a machine learning model to perform the “initializing”, “saving”, “creating”, “displaying”, “determining”, “recommending”, etc… which Fernandez teaches is performed, would be obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.
Although Fernandez teaches the above limitations, and Fernandez’s “Flexible Project Management” system and method are applicable to “managing projects” regardless of which industry the project is related, Fernandez may not explicitly teach his flexible project management system and method is to be integrated into a “healthcare system” for projects “within the healthcare system”. Nonetheless, regarding this intended use feature, although not patentably distinct from Fernandez, for the sake of compact prosecution, the Examiner notes that such features are obvious over Fernandez and DeWind as shown below:
[A method] of integrating a computing system into a healthcare system,…; [projects] within the healthcare system (DeWind, see at least [0006]-[0011], teaching, e.g.: “…an opportunity to create a fresh take on project management applied specifically in the health care environment… Placing care in the center of projects. Creating simple tools to track project progress. Shifting the culture from "doing all things" to "doing vetted projects well". Prior to this program, intake of project work was haphazard and created conflicts when scarce resources were double, or even triple booked. Delivery dates were hard to set and disappointment with project performance was prevalent. The tools created for this invention helped to streamline the intake process, developed stage gates for each project phase and increased end user satisfaction by setting realistic expectations and delivery quality results. Building upon previous construction project management patent, US 2013/0132440 May 2013, this submission seeks to provide a concise, relevant project management process within healthcare settings…”)
Therefore, the Examiner understands DeWind provides motivation to integrate the flexible project management computer system and method of Fernandez specifically into a healthcare environment “to provide a concise, relevant project management process within healthcare settings” and therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have integrated Fernandez’ computing system into a healthcare system to support projects within the healthcare system because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference or to combine prior art reference teachings to arrive at the claimed invention is obvious. The motivation to combine may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.
Claims 24, 30, 36: (Original)
Fernandez/DeWind teaches the limitations upon which these claims depend. Furthermore, Fernandez as shown teaches the following:
…wherein the plurality of project element types comprise project phase, project activity, project key event, and project checklist item (Fernandez, see again citations already noted supra, including at least [0025], e.g.: “…The disclosed systems and methods support each team in determining how best to respond to a particular task [a task/activity is a type of project element], group of tasks, or project phase [another project element type] within its own environment. Each team may specify a preferred order in which any task/phase [types of project elements] should be processed compared to others. Thus, when a deliverable [key event] to be created is entered [initialized] into the system, for example as part of an asset list [inventory of project elements], its component tasks [checklist items] behave as a workflow comprising data objects….”; see also at least [0055]: “…the system provides an interface with which a user enters information of a project, which is defined as having deliverables, and a deliverable list [project checklist] may be generated therefrom. Further, each deliverable is defined as comprising one or more tasks, and information of the tasks may be entered via the user interface. Tasks are thereby easily associated with a specific deliverable of a specific project. A new task may be added to a deliverable by searching for the name of the deliverable and using the interface to add the new task. The system may then automatically associate the task to the correct project, and ensure it shows up in the correct production stream…”)
Claims 27, 33, 39: (previously presented)
Fernandez/DeWind teaches the limitations upon which these claims depend. Furthermore, Fernandez as shown teaches the following:
…wherein the user input specifying an attribute of a project element (1) specifies that the attribute is a cost estimate for the project element, […] the method further comprising applying the specified formula to the project attribute value specified for the project to obtain a cost estimate for the project element in the project (Fernandez, see at least Fig. 16 [0028]-[0029], [0076], and [0095], teaching “cost reporting may be tracked… Efficiency may be determined by comparing the estimated time and resources needed to complete tasks to what has been logged and expended against those tasks…” and teaches a user/manager may specify estimated hours to complete a task as well as the “hourly cost” for an employee who may be assigned to a task, and teaches at the passages noted supra: e.g.: “…As shown, colors may be used to highlight certain aspects of tasks and assets. For example, as shown, where the hours estimated internally to be required to complete a task are less than a bid amount of an approved bid, the hours are highlighted in green, etc…”)
The difference between the claims and the teachings of the prior art is only that Fernandez may not explicitly teach and (2) specifies a formula for calculating a value for cost estimate attribute that is based on the project attribute for which a value specified for the project. However, because Fernandez as shown supra does teach cost estimate tracking and teaches the basis for such an estimate may be specified, e.g. hourly cost of employee and the hours necessary for completing a task may both be specified, the Examiner finds that it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also have provided Fernandez’s user/manager a mechanism by which to specify a “formula for calculating a value for a cost estimate” based on the information which he already teaches his users may specify, e.g. cost estimate = hours estimated for task completion * cost/hour of employee assigned to complete such task because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.
Claims 28, 34, 40: (Previously presented)
Fernandez/DeWind teaches the limitations upon which these claims depend. Furthermore, Fernandez as shown teaches the following:
…wherein the user input specifying an attribute of a project element (1) specifies that the attribute is a time estimate for the project element, […], the method further comprising applying the specified formula to the project attribute value specified for the project to obtain a time estimate for the project element in the project (Fernandez, see at least Fig. 4, [0028]-[0029], [0076], and [0095], teaching “… Efficiency may be determined by comparing the estimated time and resources needed to complete tasks to what has been logged and expended against those tasks. Updates can be provided periodically, such as at the end of every day, or in real time and updated with each new input of relevant information. …” and teaches a user/manager may specify the number of persons assigned to a task, as well as “…bid hours (that is, an estimate of the person-hours required for a project, that may be used to bid on the project); actual hours (that is, person-hours actually expended on the project); and a forecast of the time remaining by the calendar to complete the project…”, and also teaches at the passages noted supra: e.g.: “…As shown, colors may be used to highlight certain aspects of tasks and assets. For example, as shown, where the hours estimated internally to be required to complete a task are less than a bid amount of an approved bid, the hours are highlighted in green, etc…”)
The difference between the claims and the teachings of the prior art is only that Fernandez may not explicitly teach and (2) specifies a formula for calculating a value for time estimate attribute that is based on the project attribute for which a value specified for the project. However, because Fernandez as shown supra does teach “Efficiency may be determined by comparing the estimated time and resources needed to complete tasks to what has been logged and expended against those tasks” and teaches the basis for such an estimate may be specified, e.g. “person-hours” necessary for completing a task and the number of persons assigned to a task, the Examiner finds that it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to also have provided Fernandez’s user/manager a mechanism by which to specify a “a formula for calculating a value for time estimate attribute” based on the information which he already teaches his users may specify, e.g. time estimate = person-hours estimated to be required for task completion divided by number of persons / employee assigned to complete such task because per MPEP 2143(I) (G) Some teaching, suggestion, or motivation in the prior art that would have led one of ordinary skill to modify the prior art reference teachings to arrive at the claimed invention is obvious. The motivation may be implicit and may be found in the knowledge of one of ordinary skill in the art, or, in some cases, from the nature of the problem to be solved. Id. at 1366, 80 USPQ2d at 1649.
Response to Arguments
Applicant amended claims 23, 29, 35 on 06/10/2026. Claims 1-22, 25-26, 31-32, and 37-38 remain canceled. Applicant's arguments (hereinafter “Remarks”) also filed 06/10/2026, have been fully considered but are moot in view of the new grounds of rejection necessitated by applicant’s amendments. Note the new 35 USC 101, and 35 USC 103 rejections in view of Fernandez, Applicant Admitted Prior Art, and DeWind.
The previous 35 USC 112 rejections are respectfully withdrawn in view of applicant’s amendments.
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).
The following prior art is made of record although not relied upon as it is considered pertinent to applicant's disclosure:
US Publication 2018/0109574 A1, Vigoda discusses a machine learning project collaboration system and method which teaches applicant’s main features and the applicant’s invention does not appear to be inventive in view of this reference and the knowledge of a person of ordinary skill in the art before the effective filing date of the claimed invention; i.e. this reference would appear to be an alternative reference which may be used as the basis of forming a 35 USC 103 rejection similar to that as provided supra. For example, note at least the teachings of Vigoda at [0047]: In some implementations, the machine learning procedure may infer one or more of the at least one action variable the at least one latent variable about at least one of what task users of the one or more users are working on, what users of the one or more users are working on the task together, when the task is being worked on, why the task is being worked on, and how the one or more users participate in the collaboration. For example, consider a group of office workers preparing a budget estimate for a company. The machine learning procedure of OP 10 may infer that the list of users are working on the budget estimation project. Furthermore, the machine learning procedure of OP 10 may infer that the name of the project is ‘budget proposal’. Furthermore, the machine learning procedure of OP 10 may infer when the project is being worked on in the form of start and end dates as well as milestones within the project. Furthermore, the machine learning procedure of OP 10 may infer why the task is being worked on in the form of the relationship between this project and other projects, such as the ‘budget proposal’ is a sub project of the larger project ‘presentation to advisory board’. Furthermore, the machine learning procedure of OP 10 may infer how the team members communicate with one another in the form of a list of the types of communications used by the team, such as email, SMS text, or other messaging methods, etc…
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J SITTNER whose telephone number is (571)270-3984. The examiner can normally be reached M-F; ~9:30-6: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, Waseem Ashraf can be reached on (571) 270-3948. 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.
/Michael J Sittner/
Primary Examiner, Art Unit 3621
Prosecution Insights