DETAILED ACTION
Status of Claims
This communication is in response to applicant’s response filed on 1/28/2026.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1, 8 and 15 are amendment. Claims 1-21 are currently pending and have been examined.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-7 are drawn to a system which is within the four statutory categories (i.e. a machine). Claims 8-14 are drawn to an non-transitory computer readable medium which is within the four statutory categories (i.e., a manufacture). Claims 15-21 are drawn to a method which is within the four statutory categories (i.e., a process).
Since the claims are directed toward statutory categories, it must be determined if the claims are directed towards a judicial exception (i.e. a law of nature, a natural phenomenon, or an abstract idea). Based upon consideration of all of the relevant factors with respect to the claim as a whole, Claims 1-21 are determined to be directed to an abstract idea. The rationale for this determination is explained below:
Independent claims 1, 8 and 15 as a whole directed toward an abstract idea of processing and tracking jobs (i.e manage a tenant user job, the managing comprising: generating one or more customizable dynamically alterable user interfaces; assigning a first secure user login credential and a second user login credential; authenticating the first secure user login credential; assigning user roles to one or more users, the one or more user roles comprising an administrative user, a customer user, a crew manager user and a crew member user; applying a first job attribute to a first of the at least one of the one or more user interfaces of a first user; in response to the applying of the first job attribute, updating a job listing status table associated with the first user; adding a job order associated with the first user, comprising a service date, a service type, and a service recipient; automatically updating the job listing status table associated with the first user in response to the adding of the job order; revising the job listing status table according to a job progress update entered by the user; and creating a customer invoice upon completion of the tenant user job, wherein a first user access is allowed following authentication of the first secure user login credential.) since BRI of claimed limitation can be performed manually and hence falls under abstract idea bucket of Certain Methods of Organizing Human Activities.
Because the claim recites abstract ideas, the analysis proceeds to determine whether the claim recites additional elements that recite a practical application of the abstract ideas. According to MPEP 2106.04(d), additional elements that recite an instruction to apply the abstract ideas using computing systems and electronic device and using machine learning algorithm, that recite that generally link the use of the abstract ideas to a particular technological environment or field of use are not indicative of a practical application. Here, the additional elements such as a processer, a computer-readable medium and interface (BRI of which is general purpose computer) fail to recite a practical application because they are instructions to apply the abstract ideas using computers. The steps are implemented using generic computer hardware (processors, memory) and software modules, without a transformation or improvement to the underlying technology. Therefore, the claim as a whole fails to recite a practical application of the abstract ideas.
The dependent claims 2-10 and 12-20 further define the abstract idea (i.e. verifying an address of the job listing, storing and retrieval of user branding information by the user for customization of the defined one or more of the customizable user interfaces, storing and retrieval of visual information for display on the defined one or more of the customizable user interfaces, providing notifications regarding an updated job status and the notification is a short messaging service (SMS) message and an e-mail message.) Modules (i.e. location services module, an assets data store, a multimedia data store, notification generating module) performing above functionality is implemented by general purpose computer merely automate the task that can be performed manually and does integrate an abstract idea into a practical application. Therefore, the claims 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.
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 as of the effective filing date of the claimed invention(s) 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 as of the effective filing date of the later invention 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.
Claims 1-6, 8-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kalscheuer (US 2010/0191556 A1) in view Kulkarni (US 2024/0137383 A1) further in view of Houle (US 2003/0204421 A1).
Regarding Claims 1, 8 and 15:
Kalscheuer teaches a system built on a multi-tenant architecture platform (examiner consider architecture platform as in fig. 1 as multi-tenant, considering each city with sperate tenant). for processing and tracking jobs, comprising: a processer, and a computer-readable medium storing instructions that, when executed by the processor, cause the processor to manage a tenant user job in a multi-tenant cloud-based workflow management system, the managing comprising: (A non-transitory computer readable medium having instructions stored thereon that, when executed by a processor associated with a multi-tenant architecture platform, cause the processor to generate customizable user interfaces and job tracking and invoicing information for a plurality of tenants, comprising:)(A method for processing and tracking jobs according to multi-tenant architecture techniques, comprising the steps of:)
Kalscheuer teaches generating one or more customizable dynamically alterable user interfaces; (By disclosing, The above job posting step process allows city government users to post job announcements using form fill fields to make the job announcement posting, and to upload documents which would contain additional information about the job announcement. Each job announcement posting uses one of over fifty city government standardized job categories and city government standardized job types. The system allows user to edit each job announcement posting at any time, re-post ended job announcements, save job announcements to an archive and post saved job announcements from the archived job announcements table. If a job announcement is an prospective job announcement, the posting results in the prospective employees who submitted their interest or electronic resume being notified over the invention and by e-mail if settings are selected to make e-mail notification to the prospective employee. See at least paragraph [0090] as well as screen of fig. 1-19g as user interface)(examiner interprets generating interfaces for customized job announcement as dynamically alterable user interfaces)
assigning via a user authentication module a first secure user login credential and a second user login credential; authenticating via a source code control module the first secure user login credential; wherein a first user access to the one or more application programs via the source code control module is allowed following authentication of the first secure user login credential. (By disclosing, [0049] If city government is not registered to use invention, city government attempting to register may fill out contact information and proceed to next step in registration process which requires entry of main city hall address, telephone number, and URL of city's home page if available. The invention then allows registering user to enter a passcode as an option. The passcode may be provided by the invention administrators to the city government by e-mail or direct mail. The passcode is an alphanumeric code that is randomly generated and preloaded to into database for each city government. If entered by a city government user during registration, passcode matches preloaded city name, county name, and state name, to validate the city government user. If valid, the invention automatically approves user applicant as full registered user of invention for the respective city name. If a passcode does not match the criteria for approval, the user is notified and cannot use the passcode to register. Registration without a passcode causes the registration application to be forwarded to an application pending queue in the Administrative Module where applicant-provided information is displayed to administrative users of the invention side-by-side with other preloaded information on the city government. See at least paragraphs [0045] fig. 3 describes passcode as well as “username/password” which are interpreted as a first secure user login credential and a second user login credential respectively)
creating one or more applications for one or more tenants of the multi-tenant cloud-based workflow management system using the one or more user interfaces: (By disclosing, job announcements are accomplished on invention by using a step process. The first step involves entering the job title or selecting a job title that has been entered as a prospective job announcement. If the entered job title duplicates one that is already scheduled, active, ended, or is archived, invention alerts user of this and directs user to consider reposting the ended job, for example. If user enters prospective job announcement as a new job title without selecting the prospective job announcement, the user will be directed to select the prospective job announcement or delete the prospective job announcement before making the job posting. The second step involves inputting monthly or hourly salary information or checking off a "Depends on Qualifications" option. On this step the city government must also assign the job announcement a city government standardized job category, such as "City Managers Office" or "Public Safety-Police", and select a city government standardized job type such as "Police Captain." See at least paragraph [0087]-[0091] and fig. 1-19g))
applying a first job attribute to a first of the at least one of the one or more user interfaces of a first user; in response to the applying of the first job attribute, updating a job listing status table associated with the first user; (By disclosing, the city government user is required to add job announcement information details using a third party property rich text editor plugin. In subsequent steps, the invention includes options for the city government user to upload graphic file documents, such as job flyer or job application, and then add or edit city profile hyperlinks to the job announcement. Hyperlinks that were entered by the city government as part of the create profile process are made as presented to city government during job posting steps so that the city government user can test them and update if necessary and make them part of the job announcement. See at least paragraph [0087]-[0091] and fig. 1-19g)
adding a job order associated with the first user, comprising a service date, a service type, and a service recipient; automatically updating the job listing status table associated with the first user in response to the adding of the job order; revising the job listing status table according to a job progress update entered by the user; (See at least fig. 17G where job tile is revised according fig. 17H. See at least paragraph [0087]-[0091] and fig. 1-19g)
Kalscheuer does not specifically disclose assigning user roles to one or more users, the one or more user roles comprising an administrative user, a customer user, a crew manager user and a crew member user; However Kulkarni teaches assigning various roles to user such as an admin role, employee, super admin, network administrator, security administrator, or others to mange security related access to system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Kalscheuer with the technique of assigning roles as disclosed by Kulkarni so access privilege can be restricted or granted based on roles. Further specific type of roles can be design choice of one based on project or system requirement hence it would be obvious to assign user roles comprising an administrative user, a customer user, a crew manager user and a crew member user as type of user interacting with the system. Furthermore, merely combining well known elements in the prior art with predictable results does not render an invention patentably distinct over such combination.
Kalscheuer in view of Kulkarni does not specifically disclose invoking an invoicing module for creating a customer invoice upon completion of the tenant user job. However Houle teaches invoking an invoicing module for creating a customer invoice upon completion of the tenant user job. (See at least fig. 12 as well as associated text). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Kalscheuer with the technique of invoking an invoicing module for creating a customer invoice upon completion of the tenant user job as disclosed by Houle to perform billing function to complete project management.
Regarding Claims 2, 9 and 16:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above. Kalscheuer further teaches a location services module for verifying an address of the job listing. See at least paragraph [0048]).
Regarding Claims 3, 10 and 17:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above. Kalscheuer further teaches an assets data store for storing and retrieval of user branding information by the user for customization of the defined one or more of the customizable user interfaces. See at least paragraph [0048], [0087]-[0091] & [0209])
Regarding Claims 4, 11 and 18:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above. Kalscheuer further teaches a multimedia data store for storing and retrieval of visual information for display on the defined one or more of the customizable user interfaces. See at least paragraph [0048], [0087]-[0091] & [0209] fig. 9 as well as associated text)
Regarding Claims 5, 12 and 19:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above. Kalscheuer further teaches a notification generating module for providing notifications via a user dashboard regarding an updated job status. (See at least paragraph [0047])
Regarding Claims 6, 13 and 20:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above. Kalscheuer further teaches the notification is a short messaging service (SMS) message. See at least paragraph [0048], [0087]-[0091] & [0209] fig. 9 as well as associated text)
Claims 7, 14 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Kalscheuer (US 2010/0191556 A1) in view Kulkarni (US 2024/0137383 A1) further in view of Houle (US 2003/0204421 A1) and Wohlstadter et al. (US 2020/0026397 A1)
Regarding Claims 7, 14 and 21:
Kalscheuer in view Kulkarni and Houle teaches limitations shown above but does not specifically disclose wherein the notification is an e-mail message. (See at least paragraph [0047]). However Wohlstadter the notification is an e-mail message. (See at least paragraph [0136]) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Kalscheuer with the technique providing notification via SMA as disclosed by Wohlstadter because to draw prompt attention to use and hance effective way to notify about job update.
Response to Arguments
As to the remark, Applicant asserted that
Claims 1 , 8 and 15 integrate the judicial exception into a practical application similar to that in the recent Federal Circuit case of CosmoKey Solutions, GMBH & Co., KG. v. Duo Security, LLC, 15 F.4* 10910 (Fed. Cir. Oct. 4, 2021)
The Examiner posits that there are no limitations that recite to a practical application of the abstract idea. [Office Action, p. 4]. Applicant respectfully disagrees. Applicant points to a specific set of ordered steps that provide a technical improvement such as that discussed in CosmoKey. The claimed set of ordered steps include: generating one or more customizable dynamically alterable user interfaces; assigning via a user authentication module a first secure user login credential and a second user login credential; authenticating via a source code control module the first secure user login credential; creating one or more application programs for one or more tenants of the multi- tenant cloud-based workflow management system using the one or more user interfaces; wherein a first user access to the one or more application programs via the source code control module is allowed following authentication of the first secure user login credential. In the Office Action, these ordered elements of claims 1, 8 and 15 are not considered by the Examiner. Applicant submits that the claims are similar in substance to Example 37 of the USPTO's Subject Matter Eligibility Guidance, found to be a "yes" at Step 2A, Prong 2. The claims as amended do more than "recite that generally link the use of the abstract idea to a particular technological environment of field of use". Office Action, p. 4. To the contrary, claims 1, 8 and 15 as amended recite a series of ordered steps that address security and access concerns of a multi-tenant platform and providing specific tenants with limited access only to content of that tenant's concern. This integrates the claims into practical application.
Applicant submits that independent claims 1, 8 and 15, as currently amended, are not rendered obvious by the three-way combination Kalscheuer in view Kulkarni further in view of Houle. The claims recite: generating one or more customizable dynamically alterable user interfaces; assigning via a user authentication module a first secure user login credential and a second user login credential; authenticating via a source code control module the first secure user login credential; creating one or more application programs for one or more tenants of the multi- tenant cloud-based workflow management system using the one or more user interfaces; wherein a first user access to the one or more application programs via the source code control module is allowed following authentication of the first secure user login credential. Applicant submits that the cited prior art neither teaches nor suggests the claimed combination. Specifically, generation of customizable dynamically alterable user interfaces and authentication of a login credential via a source code control module, which limits the user among that user's among many multi tenant user's to the source code, is not taught or suggested by these prior art references.
Examiner respectfully traverses Applicant’s remark for the following reasons:
With respect to (a) Examiner would like to point out to applicant that applicant argues the claims are integrated into a practical application, citing CosmoKey. However, in CosmoKey, the Federal Circuit found eligibility because the claims recited a specific improvement to authentication that increased security and was not conventional or routine. In contrast, the present claims do not recite a particular technical improvement to authentication protocols, user interface generation, or multi-tenant architecture itself. The steps of authenticating users and limiting access are generic implementations of known security and access control functions in cloud-based systems. There is no indication that the claimed steps solve a technical problem in a technical way, as required by relevant case law and USPTO guidance. The claims, individually and as an ordered combination, do not amount to significantly more than the abstract idea itself. The system components and steps—user authentication, dynamic UI, access control, job tracking, and invoicing—are routine and conventional in the context of workflow management platforms. The claims do not recite a specific, non-conventional technical solution or improvement to computer technology.
With respect to (b) Examiner would like to point out to applicant that the claim recites a system for managing tenant user jobs in a multi-tenant cloud-based workflow management system, including steps such as generating customizable user interfaces, authenticating users, creating application programs, assigning user roles, updating job status tables, and generating invoices. These steps are directed to organizing human activity, managing business relationships, and manipulating or displaying information—abstract ideas under relevant case law. The newly added limitations, generating one or more customizable dynamically alterable user interfaces; assigning via a user authentication module a first secure user login credential and a second user login credential; authenticating via a source code control module the first secure user login credential; wherein a first user access to the one or more application programs via the source code control module is allowed following authentication of the first secure user login credential. This are standard access control and user management operations carried out using generic computer components. The steps are implemented using generic computer hardware (processors, memory) and software modules, without a transformation or improvement to the underlying technology. Accordingly, the claim does not recite an inventive concept sufficient to transform the abstract idea into patent-eligible subject matter, and is therefore not eligible under §101.
With respect to (c) Examiner would like to point out to applicant that Kalscheuer teaches generating one or more customizable dynamically alterable user interfaces; (By disclosing, The above job posting step process allows city government users to post job announcements using form fill fields to make the job announcement posting, and to upload documents which would contain additional information about the job announcement. Each job announcement posting uses one of over fifty city government standardized job categories and city government standardized job types. The system allows user to edit each job announcement posting at any time, re-post ended job announcements, save job announcements to an archive and post saved job announcements from the archived job announcements table. If a job announcement is an prospective job announcement, the posting results in the prospective employees who submitted their interest or electronic resume being notified over the invention and by e-mail if settings are selected to make e-mail notification to the prospective employee. See at least paragraph [0090] as well as screen of fig. 1-19g as user interface)(examiner interprets generating interfaces for customized job announcement as dynamically alterable user interfaces) assigning via a user authentication module a first secure user login credential and a second user login credential; authenticating via a source code control module the first secure user login credential; wherein a first user access to the one or more application programs via the source code control module is allowed following authentication of the first secure user login credential. (By disclosing, [0049] If city government is not registered to use invention, city government attempting to register may fill out contact information and proceed to next step in registration process which requires entry of main city hall address, telephone number, and URL of city's home page if available. The invention then allows registering user to enter a passcode as an option. The passcode may be provided by the invention administrators to the city government by e-mail or direct mail. The passcode is an alphanumeric code that is randomly generated and preloaded to into database for each city government. If entered by a city government user during registration, passcode matches preloaded city name, county name, and state name, to validate the city government user. If valid, the invention automatically approves user applicant as full registered user of invention for the respective city name. If a passcode does not match the criteria for approval, the user is notified and cannot use the passcode to register. Registration without a passcode causes the registration application to be forwarded to an application pending queue in the Administrative Module where applicant-provided information is displayed to administrative users of the invention side-by-side with other preloaded information on the city government. See at least paragraphs [0045] fig. 3 describes passcode as well as “username/password” which are interpreted as a first secure user login credential and a second user login credential respectively)
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEHA PATEL whose telephone number is (571)270-1492. The examiner can normally be reached Monday-Friday, 8:00 AM - 5:00 PM.
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, Tariq Hafiz can be reached at (571) 272-5350. 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.
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699
Prosecution Insights