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 response to election filed on 19 November 2025.
Claims 1-14 are currently pending and Claims 10-14 have been examined.
Election/Restrictions
Applicant’s election without traverse of Group II Claims 10-14 in the reply filed on 19 November 2025 is acknowledged.
Claims 1-9 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim.
Claim Objections
Claim 10 is objected to for minor informalities. The claim contains multiple grammatical and idiomatic errors. For example “receiving parameters to define with a project”, “any of the at least fixtures” which should read “at least one fixtures”. Examiner requests that the claims be thoroughly reviewed to address all issues.
Claim 11 is objected to because of the following informalities: The claim is in improper form because it does not end in a period. Appropriate correction is required.
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 10, 13 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 10 recites the limitations “the at least one fixture associated with the unit”, “the user”, “the vendor”, and “the response”. There is insufficient antecedent basis for these limitations in the claim.
The claim recites “the at least one fixture associated with the unit”. At least one fixture associated with a unit has not been introduced in the claim. It is unclear if the at least one fixture associated with the unit is the at least on fixture received as a parameter or some other fixture.
The claim introduces an administrative user as well as a vendor user then in lines 14 and 29 references “the user”. It is unclear which user is being referenced as providing the acceptance and receiving the transmitting status update. For examination purposes it is interpreted that the vendor user has a credential and accepts a task and receives a transmitted status update.
The claim in line 15 introduces “the vendor”. It is unclear if “the vendor” is referring back to “the vendor user” that was previously introduced or if the vendor is referring to another entity, like the vendor as a whole, to which the task can be assigned.
The claim in line 25 recites transmitting “the response”. A response has not been previously introduced. It is unclear if the response is only an acceptance or if a response could comprise other options or types of responses such as a decline or denial.
Clarification and correction are required for all antecedent basis issues rejected above.
Claim 13 recites the limitation “the system associated with the unit…”. There is insufficient antecedent basis for this limitation in the claim. A system has not been previously introduced in the claims and therefore it is unclear what system is associated with the unit, skill availability or property parameter. Clarification and correction is required.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite because the claim presents a list of parameters in the alternative “the parameters comprises any of a property, a unit, a start date, a desired end date and at least one fixture”. This listing does not require that all these parameters are received to define a project, only that any one of the 5 could be received. Therefore, it is unclear when or how an initial status of the at least one fixture can be received when at least one fixture is not necessarily a received parameter in the method. For examination purposes the limitation is interpreted as “the parameters comprises any of a property, a unit, a start date or a desired end date and at least one fixture” so that a fixture is always part of the defined project. Clarification or correction is required..
Additionally, no association has been identified between a unit and a fixture. Neither a unit nor a fixture are necessarily received parameters. If only a property or desired end date are received with a fixture to define a project then the receiving an initial status of a fixture associated with the unit does not limit the scope of the claimed invention.
Clarification and correction are required.
Claim 14 is rejected for being indefinite because the claim recites wherein accepting the at least one task may generate a vendor calendar. It is unclear if or when a vendor calendar is generated. The metes and bounds of the claim are unclear. Clarification and correction are required.
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 10-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 10 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 10 recites–
“A method of managing projects, comprising: on a first electronic computing device associated with an administrative user: receiving parameters to define with a project, wherein the parameters comprises any of a property, a unit, a start date, a desired end date, and at least one fixture; receiving an initial status of the at least one fixture associated with the unit; generating a task list comprising at least one task associated with the project wherein each of the at least one tasks is associated with any of the at least fixtures being at or below a predetermined threshold; generating a timeline to the project based on any of the parameters and the task list, wherein the timeline comprises a due date for each of the at least one tasks; transmitting a request associated with at least one task to at least one secondary electronic computing device associated with a vendor user having at least one desired credential; responsive to receiving an acceptance from the user having at least one desired credential, assigning the at least one task to the vendor associated with the secondary electronic computing device; responsive to receiving a status update from the vendor user associated with the secondary electronic device updating the timeline; and responsive to receiving a completed status for the task assigned to the vendor user, removing the task from the task list;
on at least one second electronic device associated with the vendor user comprising at least one credential: receiving the request associated with at least one task from the first electronic computing device; transmitting the response to the request to the first electronic device; responsive to the request being acceptance, retrieving any of the parameters associated with the request from the first electronic computing device; receiving the status update; and
transmitting the status update to the user.”
As drafted, this is, under its broadest reasonable interpretation, within the Abstract idea grouping of “certain methods of organizing human activity” (managing relationships or interactions between people – including… teaching, and following rules or instructions). Here, the claim has a description of a series of instructions relating to project and timeline management where multiple users and tasks are monitored, associated with or assigned to a project. Accordingly, claim 10 is directed to an abstract idea.
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. Claim 10 recites Additional elements that including a first electronic computing device and a second electronic computing device for receiving, generating, transmitting, assigning, updating, removing, and retrieving inputs and results for managing projects.
The computing device elements are considered generic recitations of computer elements that merely apply or execute merely instructions to implement the abstract idea on a computer. (See MPEP 2106.05f; see also MPEP 2106.05h field of use for the generating, assigning, updating, and removing).
Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The receiving, transmitting, and retrieving are also generically recited and can be considered insignificant extra solution activity since they demonstrate merely data gathering and transmission. The claim also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of computing devices performing steps of receiving, generating, transmitting, assigning, updating, removing, and retrieving are treated as MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235); and MPEP 2106.05h (field of use). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. For the receiving, transmitting, and retrieving that can be considered extra solution activity, these have 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 devices are anything other than generic, off the shelf computer components, 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 11-14 include all of the limitations of claim 10 and therefore recite the same abstract idea. The claims merely narrow the recited abstract idea by describing additional data relating to the requesting comprising status data, the timeline comprising an ordered itinerary, the credential and that a task may generate a vendor calendar. No additional elements are recited that transform the claims into a patent eligible invention, integrate the abstract idea into a practical application, or amount to significantly more.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
The factual inquiries 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 nonobviousness.
Claims 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Lereya et al (US 2021/0166196) in view of Parikh (US 2023/0342723).
As per Claim 10 Lereya teaches:
A method of managing projects, comprising: on a first electronic computing device associated with an administrative user:
receiving parameters to define with a project, wherein the parameters comprises any of a property, a unit, a start date, a desired end date, and at least one fixture (Lereya in at least [0181] describes devices, systems and methods for collaborative work systems, the platform allows a user to structure the system in many ways with the same building blocks to represent what the user wants to manage and how they want to manage it, this is done through boards, boards may be a table of items defining objects or entities that are managed in the platform, such as a project, [0205-0209] describe defining rows and columns with different projects and characteristics of such items);
receiving an initial status of the at least one fixture associated with the unit (Lereya in at least [0023, 0026] describes receiving an associated first status for items associated with a project, see also [0205-0207, 0256, 0287-0288, 0300, 0318, 0346, 0351, 0436]);
generating a task list comprising at least one task associated with the project wherein each of the at least one tasks is associated with any of the at least fixtures being at or below a predetermined threshold (Lereya [0018, 0287, 0559, 0569, 0623, 0635-0638, 0696-0698] describe generating a list of tasks including project tasks that have associated thresholds that can be assigned to different columns or rows defining the project including time, budgetary, etc. types of thresholds for the defined project tasks and resources);
generating a timeline to the project based on any of the parameters and the task list, wherein the timeline comprises a due date for each of the at least one tasks (Lereya in at least [0256, 0258, 0264, 0380, 0386, 0389] describe generating a timeline for a project based parameters and the task list, the timeline including due dates for tasks);
responsive to receiving a status update from the vendor user associated with the secondary electronic device updating the timeline (Lereya in at least [0006-0008, 0334, 0402, 0438-0441, 0450, 0537, 0576-0581] describe receiving status updates from vendors and updating timelines accordingly, a change in status can cause an automatic update); and
responsive to receiving a completed status for the task assigned to the vendor user, removing the task from the task list (Lereya in at least [0647] describes that when a task status is updated to “done” the processor may delete the task row from the aggregate table of tasks);
on at least one second electronic device associated with the vendor user comprising at least one credential:
receiving the status update (Lereya in at least [0006-0008, 0334, 0402, 0438-0441, 0450, 0537, 0576-0581] describe receiving status updates from vendors and updating timelines accordingly, a change in status can cause an automatic update); and
transmitting the status update to the user (Lereya in at least [0006-0008, 0334, 0402, 0438-0441, 0450, 0537, 0576-0581] describe receiving status updates from vendors and updating timelines accordingly, a change in status can cause an automatic update or other visual indicators that are transmitted to a user).
Lereya does not explicitly recite transmitting/receiving a request associated with a task between two devices, receiving and transmitting a response to accept and assign the task and retrieving the task details after acceptance. Lereya also teaches analyzing vendors with for qualifications However, Parikh teaches project management automation. Parikh further teaches:
transmitting a request associated with at least one task to at least one secondary electronic computing device associated with a vendor user having at least one desired credential (Parikh in at least [0187, 0252, 0262] describes filtering the vendors based on one or more criteria and transmitting requests to a marketplace connecting business owners and/or vendors, owners can solicit vendors to perform a job or task and vendors can bid on jobs and/or otherwise accept jobs);
responsive to receiving an acceptance from the user having at least one desired credential, assigning the at least one task to the vendor associated with the secondary electronic computing device (Parikh in at least [0187, 0252, 0262] describes the ability of vendors to accept jobs in a marketplace such that the jobs are assigned to the filtered/qualified vendors, team members or users as is described further in at least [0065, 0095-0097, 0106, 0117, 0136, 0184-0185, 0202-0208, 0249]);
on at least one second electronic device associated with the vendor user comprising at least one credential:
receiving the request associated with at least one task from the first electronic computing device (Parikh in at least [0187, 0252, 0262] and Fig. 1 requests associated with tasks are received by the marketplace platform);
transmitting the response to the request to the first electronic device (Parikh in at least [0187, 0252, 0262] and Fig. 1 requests associated with tasks are received by the marketplace platform where vendors or business owners can respond and that information is transmitted between participants);
responsive to the request being acceptance, retrieving any of the parameters associated with the request from the first electronic computing device (Parikh in at least [0187, 0252, 0262] describes the ability of vendors to accept jobs in a marketplace such that the jobs are assigned to the filtered/qualified vendors, team members or users as is described further in at least [0065, 0095-0097, 0106, 0117, 0136, 0184-0185, 0202-0208, 0249, 0257] where the details and information associated with the tasks are accessible by the assigned user);
It would be obvious to one of ordinary skill in the art to modify the project management elements of Lereya to include the techniques for requesting and accepting task assignments 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 perform the same function as they did individually. By enabling requests that require acceptance, the combination enables business users and vendors to find other business users and vendors that satisfy their respective needs and meet their designated criteria, thus improving user satisfaction and overall fulfillment.
As per Claim 11 Lereya further teaches:
wherein the request comprises a status of any of the at least one fixtures, the property, the initial status of the at least one fixture, and the due date associated with the at least one task (Lereya in at least [0654] describes the ability to request that the associated entities provide status values for tasks).
Parikh further teaches in at least [0090 and 0249] sending and submitting requests that periodically acquire status information.
As per Claim 12 Lereya further teaches:
wherein the timeline comprises an ordered itinerary of each of the at least one tasks (Lereya in at least [0256, 0258, 0264, 0380, 0386, 0389] describe generating a timeline for a project based parameters and the task list, the timeline including due dates for tasks).
As per Claim 13 Lereya in at least [0880, 0960] describes using credentials but does not explicitly recite vendor credentials. Parikh further teaches:
wherein the at least one credential is any of an invitation to the system associated with the unit, a skill, an availability correlating with the timeline, and a proximity to the property (Parikh in at least [0187, 0252, 0262] describes the ability of vendors to accept jobs in a marketplace such that the jobs are assigned to the filtered/qualified vendors, team members or users as is described further in at least [0065, 0095-0097, 0106, 0117, 0136, 0184-0185, 0202-0208, 0249] where the details and information associated with the tasks are accessible by the assigned user);
Parikh is combined based on the reasons and rationale set forth in the rejection of Claim 10 above.
As per Claim 14 Lereya describes updating time based graphics such as calendars in at least [0438]. Lereya does not explicitly recite but Parikh further teaches:
wherein accepting the at least one task may generate a vendor calendar comprising the at least one task on the at least one second computing device (Parikh in at least [0187, 0252, 0262] describes the ability of vendors to accept jobs in a marketplace such that the jobs are assigned to the filtered/qualified vendors, team members or users as is described further in at least [0270] where the application may interface with one or more calendaring or scheduling applications to push information or pull information related to tasks, appointments, etc.).
Parikh is combined based on the reasons and rationale set forth in the rejection of Claim 10 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Jafari et al. (US 11288608) Systems and methods for project management portal.
Steinglass et al. (US 20090234699) User interface for scheduling resource assignments.
Cantor et al. (US 20140222485) Exploring the impact of changing project parameters on the likely delivery date of a project.
Haramati et al. (US 20210157806) Digital processing systems and methods for automatic user time zone updates in collaborative work systems.
Macatangay (US 20160364674) Project management with critical path scheduling and releasing of resources.
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