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 RCE, Remarks, and Amendments filed 12/30/2025.
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
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 23-24, 27-30, 33-36, and 39-40 are rejected under 35 U.S.C. 112(b) or (for pre-AIA ) 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention.
Independent claims 23, 29, 35 have been amended to recite features directed towards the following: “…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 an order of recommending, by the machine learning model, the subset of the project elements comprises one or more order of acts selected from the group consisting of: rearranged, performed in parallel, omitted, included, divided and combined.” - underlines added for emphasis.
Respectfully, there are multiple issues with the aforementioned claim features, each of which leads to a finding of indefiniteness.
First, the claim appears to include a colloquial expression regarding the term “with” as underlined above. On its face, the claim requires “a recommendation” to be display “with” (i.e. in addition to) “the subset of the project elements…”. However, then the claims proceed to recite something which introduces significant confusion in the proper interpretation of the claims; i.e. the claims then state: “wherein an order of recommending,…the subset…” However, the subset has not previously been recited as being “recommended”. Instead, the subset is previously recited as already being determined and being displayed “with” a “recommendation”. it is not clear whether applicant is attempting to state that the displaying of the subset is distinct from a recommendation or, the display of the subset is according to a particular order or scheme or, something else entirely.
Second, the following phrase “wherein an order of recommending, by the machine learning model, the subset of the project elements comprises one or more order of acts selected from the group consisting of: rearranged, performed in parallel, omitted, included, divided and combined.” on its face is not clear. For example, assuming applicant is trying to convey the idea that a subset of project elements has been determined and the system is making a recommendation regarding this subset, it remains completely unclear what “an order of recommending… comprises one or more order of acts selected from the group consisting of: rearranged, performed in parallel, omitted, included, divided and combined.” is supposed to mean. Does this mean an order in which the subset of the project elements is recommended is “rearranged”? This is perhaps a colloquialism known to the draftsman but it is not a limitation which conveys any definite scope of subject matter to a person of ordinary skill in the art.
Therefore, for each of these reasons, the claims are held to be indefinite. For the purpose of compact prosecution, the aforementioned features in question are interpreted as follows:
displaying a recommendation, by the machine learning model, 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.
Additionally, independent claims 23, 29, 35 have been amended to recite features directed towards the following: “…creating to a project model data store a model for the project comprising the specified project name on a first dynamic display area”.
Respectfully, the claim is not clear. The Examiner understands the following: the portion of the claim reciting, “creating to a project model data store…” appears to mean creating a model and saving (or otherwise recording) said model into a “project model data store” (e.g. a database); Furthermore, Examiner understands the claim feature, “…a model for the project comprising the specified project name” to mean the model, which is created and saved, includes or otherwise comprises “the specified project name”. However, it is not clear what the final phrase “on a first dynamic display area” is meant to convey. It is not clear whether the “project name” is intended to be modified by this phrase – e.g. the name is somehow on a “first dynamic display” or, whether this phrase is intended to modify something else – e.g. the “creating” is “on [sic] a first dynamic display area”. In the latter regard, Examiner notes that claims 29 and 35 appear to require a computing system to perform the “creating” but claim 23 does not explicitly set forth who or what performs this creating; therefore, this later interpretation, e.g. the “creating” is “on [sic] a first dynamic display area”, causes confusion about whether applicant intends a computer system to actually perform the creating or whether applicant intends a human actor to perform the creating using some generic graphical user interface and/or GUI tools (i.e. the now recited “first dynamic display area”). Respectfully, it is not at all clear what this phrase is intended to modify. The feature is completely unclear and thus the claim is indefinite.
For the purpose of compact prosecution, the phrase is considered to be an error by the draftsman and is not given further consideration nor afforded patentable weight; i.e. the feature in question is interpreted as though the phrase “on a first dynamic display area” is not included in the claim feature. Nonetheless, amendment, correction, and clarification is required.
Dependent claims 24, 27-28, 30, 33-34, 36, and 39-40 inherit the deficiencies of their parent claim and are also rejected under 35 U.S.C. 112(b) or (for pre-AIA ) 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor, a joint inventor, or (for pre-AIA ) the applicant regards as the invention.
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[,] to a project model data store[,] 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 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; …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 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;… 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 an order of recommending, by the machine learning model, the subset of the project elements comprises one or more order of acts selected from the group consisting of: rearranged, performed in parallel, omitted, included, divided and combined”
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 is purely 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]. 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 Official Notice 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, by a machine learning model, 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….”
The difference between the claim feature and the teachings of Fernandez is only that Fernandez, although teaching “each team may specify [initialize] a preferred order in which any task/phase [types of project elements] should be processed…”, he may not explicitly teach his teams use a “machine learning model” to make their specification [initialization]. However, per [0025] Fernandez also teaches “automation of certain task phases” which implies some type of machine logic may be used by a team in specifying a preferred order. Furthermore, Examiner takes Official Notice that 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. 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 and the Examiner finds that using a machine learning model to perform the specifying [initializing] of a preferred order in which any task/phase [types of project elements] should be processed 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.);
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; creating[,] to a project model data store[,] a model for the project comprising the specified project name on a first dynamic display area (Fernandez, see citations noted supra and also at least Fig. 35 [a first dynamic display area] 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…”; project model is created and saved, e.g. via a “Add Project” interface depicted per 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 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 the machine learning model, 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].
The difference between the claim feature and the teachings of Fernandez is that Fernandez may not explicitly teach “machine learning model” performs his “recommend[ing]” even though his system somehow learns, i.e. takes into account, “task priorities specific to the project, team attributes, settings, etc… However, because, as already noted supra, generic “machine learning models” are well-known to a person of ordinary skill in the art before the effective filing date of the claimed invention, and Fernandez provides motivation to use some type of automation to perform his “taking into account” functionality [a type of learning functionality], 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 have used a generic “machine learning model” to accomplish the functionality which Fernandez discloses his system/method accomplishes 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.).
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 an order of recommending, by the machine learning model, the subset of the project elements comprises one or more order of acts selected from the group consisting of: rearranged, performed in parallel, omitted, included, divided and combined (Note 112(b) rejection guiding claim interpretation. 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…”)
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 12/30/2025. Claims 1-22, 25-26, 31-32, and 37-38 remain canceled. Applicant's arguments (hereinafter “Remarks”) also filed 12/30/2025, 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 112, 101, and 35 USC 103 rejections in view of Fernandez, Official Notice, and DeWind.
Conclusion
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