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 . 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.
DETAILED ACTION
The following Non-Final Office Action is in response to Request for Continued Examination filed on 2/16/2026.
Continued Examination under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 2/16/2026 has been entered.
Status of Claims
Claims 1-20 are currently pending.
Claims 1, 10, 17 are currently amended.
Claims 1-20 are currently under examination and have been rejected as follows.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Amendment
The previously pending rejections under 35 USC 101 will be maintained. The 101 rejection is updated in view of the amendments.
New grounds for rejection 35 USC 103 are applied as necessitated by the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Response to Arguments
Regarding Applicant’s remarks pertaining to 35 USC 101:
Step 2A Prong 1:
Applicant argues on page 9 of remarks 2/16/2026:
“The Applicant respectfully submits that one or more features of amended independent claim 1 cannot be performed or executed by the human mind. These steps are inextricably tied to a machine or device…. These operations involve real-time geolocation verification, conditional logic for enabling execution, dynamic decision-making based on live progress data, and automated template mutation for reassignment, none of which can be executed mentally or manually by a human.”
Examiner respectfully finds the argument unpersuasive. Rather than relying on Mental Processes (MPEP 2106.04(a)(2) III), Examiner submits the claims recite, describe or set forth an abstract idea under the grouping of Certain Methods of Organized Activity (MPEP 2106.04(a)(2) III). Specifically, requesting human field activity and providing workflow instructions to carry out operations in the field in an industrial environment fall within following rules or instructions as it pertains to managing personal behavior or relationships or interactions between people, as well as commercial or legal interactions (including agreements in the form of contracts, legal obligations, and business relations); and monitoring and attending to assets’ operational states falls within mitigating risk. The use of technology to achieve the functions of the claims does not preclude the recitation, description, or setting forth an abstract idea.
Step 2A Prong 2:
Applicant argues on page 10 of remarks 2/16/2026:
“…the subject matter of amended independent claim 1 facilitates enhanced operational accuracy and efficiency by enabling execution gating based on geolocation verification, dynamic task adaptation, and closed-loop progress tracking…. This real-time, machine-driven approach improves responsiveness, reduces reliance on manual coordination, and minimizes the risk of miscommunication or delay. Additionally, the system enables closed-loop feedback by capturing task progress and updating templates dynamically, thereby supporting continuous process optimization and resource planning. These capabilities collectively demonstrate that the claimed invention is not merely theoretical but is a practical, machine-implemented solution that addresses real-world challenges in industrial environments.”
Examiner respectfully disagrees. The improvements asserted by applicant - such as enhanced operational accuracy and efficiency, minimizing risk of miscommunication or delay, and continuous process optimization and resource planning - use technology to improve the processes, but it remains unclear how the technology itself is improved. Further, the reduction in reliance on manual coordination may be seen as mere automation of a manual process, in itself insufficient to show an improvement in computer functionality (see MPEP 2106.05(a)iii).
Step 2B:
Applicant argues on page 12 of remarks 2/16/2026:
“Thus, subject matter of amended independent claim 1 automates translation, delivery, and state management of HFAs, and reduces or eliminates dependence on manual coordination by the control room and enables faster, more reliable task execution. Further, the amended independent claim 1 emphasizes that direct communication of commands to field devices leads to quicker and more accurate transfer of instructions and faster confirmation of completion. Because templates can be updated to reflect partial completion and reassignment, the claimed method reserves continuity of operations even when personnel change mid-task. This leads to improved operational efficiency, reduced delay, minimized risk of error, and tighter integration between industrial control infrastructure and by mobile computing endpoints.”
Examiner respectfully disagrees. As similarly submitted above, the improvements asserted by applicant – in this case, enabling faster, more reliable task execution (by human field operators), quicker and more accurate transfer of instructions and faster confirmation of completion, and reserving continuity of operations even when personnel change mid-task – use technology to improve an entrepreneurial processes, but it again remains unclear how the technology itself is improved.
Thus, the rejection under 35 USC 101 is maintained. The 101 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Regarding Applicant’s remarks pertaining to 35 USC 102/103:
Applicant argues on page 13 of remarks 2/16/2026:
“McAdam does not disclose the ordered control logic and gates recited in the amended claims. It is silent about: (i) a mandatory, post-transmission acknowledgment confirming receipt of a command at the field device as a prerequisite to subsequent steps; (ii) device-side geolocation verification used as an execution gate i.e., determining that the communication device
is physically at the equipment's geolocation before enabling or displaying instructions; (iii) generating an on-device prompt expressly to capture a "partial completion" status (as opposed to
generic "next step" or final completion flows); and (iv) dynamically modifying the machine-readable command/template instance based on partial completion and, upon reassignment, automatically updating the command to specify the remaining steps for a successor operator. McAdam teaches threshold-driven workflow modification and rich example screens, but nowhere requires acknowledgment gating, geo-fenced enablement, partial-completion prompting or template-level mutation with remaining-steps re-computation upon reassignment, nor does it implement these features in the claimed sequence.”
Examiner respectfully disagrees. Disclosure of the claims as amended is further supported by Mohebi, McAdam, and newly presented art reference Ehrman et al. US 20090099897 A1, hereinafter Ehrman. Additional support from Mohebi can be found at ¶ [0042], Fig. 7 and related text, and ¶ [0049]. Additional support from McAdam can be found at ¶ [0053]. New support from Ehrman can be found at ¶ [0211]-[0212], and [0266]. Citations and additional details are provided in the 103 rejection section below.
Applicant argues on page 14 of remarks 2/16/2026:
“The proposed combination of Mohebi and McAdam still fails because these references operate in fundamentally different paradigms and do not address the ordered, device-gated control logic recited in the amended claims…. In short, Mohebi addresses tag-centric task issuance and syncing, and McAdam addresses limit-aware screen sequencing; neither teaches or suggests the claimed sequence of transmit, receive device acknowledgment, verify geolocation as an execution gate, enable or display instructions, prompt for partial completion, and dynamically mutate the template and update remaining steps upon reassignment.”
Examiner respectfully disagrees. Additional support for the “device-gating” although not explicit in the claims, is provided at Mohebi ¶ [0042], Fig. 7 and related text, and ¶ [0049]. These additional citations plus McAdam ¶ [0053] and Ehrman ¶ [0211]-[0212], and [0266] provide the disclosure in combination to address the concepts argued above. See 103 rejection for additional details on rationale to combine the references, each analogous art in the field of industrial field operator management.
Applicant argues on page 14 of remarks 2/16/2026:
“Moreover, the Office Action provides no articulated motivation why a person of ordinary
skill would combine Mohebi's tag and task logistics with McAdam's limit-based screen switching
to arrive at the claimed geolocation-gated execution, closed-loop acknowledgment, partial-completion capture, and reassignment-based dynamic template re-computation. The two references solve different problems in different technical contexts, Mohebi focuses on asset tagging, offline synchronization, and task dashboards; McAdam focuses on modifying a mobile workflow based on sensor limits, and neither recognizes the problem of enforcing device-side geolocation as a precondition to enabling execution, requiring deterministic acknowledgment before proceeding, or mutating a workflow-management compatible command or template to encode partial completion and automatically compute remaining steps upon reassignment. Implementing the claimed sequence demands non-trivial engineering at both device and server
tiers (including geofence determination tied to equipment geotags, UI gating and acknowledgment
ordering, and template-level mutation that redefines subsequent instructions), which neither reference hints at nor suggests.”
Examiner respectfully disagrees. The geolocation precondition is addressed by additional support from Mohebi ¶ [0042], Fig. 7 and related text, and ¶ [0049] and the reassignment functionality is supported by new reference Ehrman ¶ [0211]-[0212], and [0266]. Despite ultimately solving different technical problems, each reference in combination teaches the claimed invention in the context of industrial field operator management, disclosing the claimed methodology/functionality enroute to their ultimate solutions. See 103 rejection for additional details on rationale to combine the references.
Thus, new grounds of rejection under 35 USC 103 are applied as necessitated by the amendments. The 103 rejection is updated in view of the amendments.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-9 are directed to a method or process which is a statutory category.
Claims 10-16 are directed to a system or machine which is a statutory category.
Claims 17-20 are directed to a non-transitory computer-readable medium or article of manufacture which is a statutory category.
Step 2A Prong One: The claims recite, describe, or set forth a judicial exception of an abstract idea (see MPEP 2106.04(a)). Specifically, the claims recite, describe or set forth following rules or instructions, including: “receiving a human field activity (HFA) request corresponding to an operation to be performed by a field operator”, “generating… command using a template… specifying attributes of… equipment”, “manage operation of… equipment based on a predefined standard operating procedures (SOPs)”, “transmitting… the HFA command to… the field operator”; “receive at least partial completion status of completion of the operation”; “dynamically modifying, the HFA command template to reflect the partial completion status of the operation”; and “[display] information corresponding to the remaining steps defined by the updated HFA command” at independent claims 1, 10, 17. Additionally, the claims recite, describe or set forth mitigating risk including: “obtaining real-time operational data from one or more sensors monitoring the at least one equipment… representing a current operational state of the at least one equipment”; “enabling the field operator to perform the HFA request as specified in the HFA command”; “determining… whether the communication device is at a geolocation of the at least one equipment”; and “wherein the HFA command is generated using real-time operational data obtained from… monitoring the at least one equipment to represent a current operational state of the at least one equipment” at independent claims 1, 10, 17. Requesting human field activity and providing workflow instructions to carry out operations in the field in an industrial environment fall within following rules or instructions as it pertains to managing personal behavior or relationships or interactions between people, as well as commercial or legal interactions (including agreements in the form of contracts, legal obligations, and business relations); and monitoring and attending to assets’ operational states falls within mitigating risk; each under the larger abstract grouping of Certain Methods of Organizing Human Activity (MPEP 2106.04(a)(2) II). Accordingly, the claims recite an abstract idea.
Step 2A Prong Two: Independent claims 1, 10, 17 recite the following additional elements: “template”, “workflow management system”, “communication device”, “human field activity (HFA) service system”, “application”, “collector module”, “communication module”, “sensors”, “equipment”, “display”, and “non-transitory computer-readable medium”. The capabilities of these additional elements include obtaining real-time operational data from equipment sensors; receiving field operation requests for equipment in a facility; determining proximity of field devices to field equipment; generating standard operating procedure commands for a workflow; tracking progress on the workflow; re-assigning field operators; basing the commands on equipment attributes and operational states obtained in real-time with the sensors; transmitting the commands to a human field operator’s device; and displaying remaining workflow steps. The additional elements are recited at a high level of generality (i.e. as a generic computer performing functions of collecting, organizing, communicating and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components. Therefore, these functions can be viewed as not meaningfully different than a business method or mathematical algorithm being applied on a general-purpose computer as tested per MPEP 2106.05(f)(2)(i), or requiring the use of software to tailor information and provide it to the user on a generic computer as tested per MPEP 2106.05(f)(2)(v). The claims are directed to an abstract idea and the judicial exception does not integrate the abstract idea into a practical application.
Step 2B: According to MPEP 2106.05(f)(1), considering whether the claim recites only the idea of a solution or outcome i.e., the claims fail to recite the technological details of how the actual technological solution to the actual technological problem is accomplished. The recitation of claim limitations that attempt to cover an entrepreneurial and thus abstract solution to an entrepreneurial problem with no technological details on how the technological result is accomplished and no description of the mechanism for accomplishing the result do not provide significantly more than the judicial exception.
Dependent claims 3, 12, 19 recite the additional element “HMI screensHMI”. Dependent claims 6, 13 recite the additional element “network”. These additional elements are also recited at a high level of generality (i.e. as a generic computer performing functions of collecting, communicating and presenting data, etc.) such that they amount to no more than mere instructions to apply the exception using generic computer components or requiring the use of software to tailor information and provide it to the user on a generic computer.
Further, dependent claims 4-5, 7-9, 11, 14-16, 18, 20 merely incorporate the additional elements recited in claims 1, 10, 17 along with further narrowing of the abstract idea of claims 1, 10, 17 along with their execution of the abstract idea. Specifically, dependent claims narrow the template, workflow management system, communication device, human field activity (HFA) service system, application, collector module, communication module, non-transitory computer-readable medium, HMI screens, and network to capabilities such as receiving, comprising, sensing, transmitting, generating, detecting, queueing, including, selecting, updating, and specifying various forms of data such as responses, commands, statuses, equipment attributes, types, geolocations, identifications, parameters, prompts, instructions, task items, pictures, distances, etc. which, when evaluated per MPEP 2106.05(f)(2) represent mere invocation of computers to perform existing processes. Therefore, the additional elements recited in the claimed invention individually and in combination fail to integrate a judicial exception into a practical application (Step 2A prong two) and for the same reasons they also fail to provide significantly more (Step 2B). Thus, claims 1-20 are reasoned to be patent ineligible.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
REJECTIONS BASED ON PRIOR ART
Examiner Note: Some rejections will be followed/begin by an “EN” that will denote an examiner note. This will be placed to further explain a rejection.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claim Rejections - 35 USC § 103
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.
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.
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.
Claim(s) 1-5, 7-12, 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over:
Mohebi et al. US 20230334280 A1, hereinafter Mohebi, in view of
McAdam et al. US 20190266575 A1, hereinafter McAdam, and in further view of Ehrman et al. US 20090099897 A1, hereinafter Ehrman. As per,
Regarding Claim 1: Mohebi teaches “A method, comprising:
“receiving a human field activity (HFA) request corresponding to an operation to be performed by a field operator, the operation relating to at least one equipment in a facility” (Mohebi ¶ [0082]: In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags [EN: requests] to one or more facility assets [EN: equipment] at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented [EN: requested] at the field device);
[..]
“generating, based on the HFA request [and the real time operational data], an HFA command using a template, the HFA command specifying attributes of the at least one equipment in a format compatible with a workflow management system, the workflow management system being implemented to manage operation of the at least one equipment based on a predefined standard operating procedures (SOPs), [..]” (Mohebi ¶ [0063]: As depicted in FIG. 12, the system 1200 can include the task map 218 and an asset-specific tasks list 1202 [EN: template] for viewing the task data 210 for a particular facility asset 104. ¶ [0047]: …the task list 302 [EN: template] can be a list or spreadsheet with a row 304 of the task list 302 representing an asset task, and a column 306 of the task list 302 representing a particular type of asset data 208 or task data 210. For instance, one or more columns can represent an asset identifier, an asset type, an applicable standard for the asset, a facility name associated with the asset, an asset description [EN: attribute specification], a task identifier, a task category, a task status, a task frequency, a task opened date, a task completed date, and the like. The task list 302 can include one or more interactive elements (e.g., the task identifiers) that, upon receiving a user input, cause the site operator UI 124 to present additional details regarding the selected task or task entry. The task list 302 can be used for workflow planning at the operational site 106 by selecting which tasks or task filters [EN: configurable parameters] to apply to asset task lists that are downloaded to field operator devices 110, as discussed below. [Also see figs. 3, 7 and related text]); “and
“transmitting, via the workflow management system, the HFA command to an application executing on a communication device of the field operator” (Mohebi ¶ [0032]: The field device 110 can conduct the data syncs 116 [receive commands] with the site operator device 108 (e.g., upon performing the asset task). For instance, the operational site 106 can include a local area network (LAN) or intranet to provide a communication channel between the field device(s) 110 and the site operator device 108);
“determining, by the application, whether the communication device is at a geolocation of the at least one equipment” (Mohebi ¶ [0042]: …The asset tag(s) 204 can be a Near Field Communication (NFC) tag that uses RFID to provide information, such as the tag identifier(s) 214, to the field device(s) 110…. The sensors 202 on the field device 110 can include an NFC reader for reading the tag identifier(s) 214 from the asset tag(s) 204 when the field device(s) 110 is in close proximity to the asset tag(s) 204. In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110);
“upon successful determination, enabling the field operator to perform the HFA request as specified in the HFA command” (See Mohebi Fig. 7: “Tap Phone to NFC tag to find and start task” and Fig. 7 related text);
“generating a prompt on the communication device of the field operator to receive at least partial completion status of completion of the operation; dynamically modifying, the HFA command template to reflect the partial completion status of the operation [..]” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like)
[..] “and
“executing, by the application on a display of the communication device associated with the [other] field operator, information corresponding to the remaining steps defined by the updated HFA command” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like).
Although Mohebi teaches generating and sending an equipment operating procedure command to a human field operator, Mohebi does not specifically teach monitoring the operational state of the equipment with sensors in real time to generate the command, nor reassigning tasks to other operators in the field.
However, McAdam in analogous art of industrial field operator management teaches or suggests:
“obtaining real-time operational data from one or more sensors monitoring the at least one equipment, the real-time operational data representing a current operational state of the at least one equipment” (McAdam ¶ [0053]: Corrective action may be taken based on determining this equipment information. For example, if the equipment is showing signs of wear or failure, corrective actions may be taken, such as taking an inventory of parts to ensure replacement parts are available, ordering replacement parts, and/or calling in repair personnel to the site. Certain parts of equipment may be replaced immediately. Other parts may be safe to continue to use, but a monitoring schedule may be adjusted. Alternatively or additionally, one or more inputs or controls relating to a process may be adjusted as part of the corrective action. These and other details about the equipment, sensors, processing of sensor data, and actions taken based on sensor data are described in further detail below. Such corrective actions may be implemented as part of a modified mobile workflow. Such a mobile workflow may include step-by-step instructions/procedures for a field worker to implement and the workflow may be modified in response to a current operating condition for a measurable element, such as a pressure measurement, of an asset, such as a PSA unit. For example, a field worker repairing or working on a piece of equipment as part of a multi-step workflow may receive, at a device, an updated workflow or next step [EN: HFA command] in the workflow based on the current operating condition for the measurable element);
[..]
“wherein the HFA command represents the current operational state of the at least one equipment” (see again McAdam ¶ [0053]).
McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi’s facility asset tracking system and method to have included McAdam’s teachings around monitoring the operational state of the equipment with sensors in real time to generate an equipment operating procedure command. The benefit of these additional features would have improved plant efficiency through responsive maintenance for conditions requiring deviation from standard field procedures (McAdam ¶ [0002, 0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Furthermore, Ehrman in analogous art of industrial field operator management teaches or suggests:
“[..] to reassign the operation to another field operator (Ehrman ¶ [0211]: The task may remain assigned to the particular operator until it is indicated as being completed, cannot be completed, canceled by the operator, or until a predetermined period of time passes without the task being completed when it may be reassigned to another operator. ¶ [0212]: The work request dispatch engine 200 may also maintain and manage the work requests. In particular, the work request dispatch engine 200 may load balance work between operators based on system configuration parameters and a set of heuristics. For example, if a task has been assigned to an operator who has failed to complete it after a predetermined amount of time, cancels the task, or is currently working on a different work request, the task may be reassigned to another operator that is available and can complete the task);
“upon reassignment of the operation to the other field operator, updating the HFA command to specify remaining steps in the operation to be performed” (Ehrman end-¶ [0266]: The operator may be given a prompt to indicate that the work request is in progress and/or near completion. The work request assignment engine 280 may respond by reassigning the task to the operator and providing additional time for completion).
Ehrman, McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi / McAdam’s facility asset tracking system and method to have included Ehrman’s teachings around reassigning tasks to other operators in the field. The benefit of these additional features would have increased continuity and accuracy of assigning work requests in an asset management system (Ehrman ¶ [0008]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam and Ehrman (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam and Ehrman above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 2: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Mohebi further teaches “The method of claim 1, wherein the HFA command comprises at least one actionable task item pertaining to the operation to be performed by the field operator on the at least one equipment” (Mohebi ¶ [0030]: FIG. 16 illustrates an example method 1600 to track facility assets 104 using the asset tracking platform 102, which can be performed by any of the systems 100-1500 disclosed herein. ¶ [0082] In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags to one or more facility assets at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented at the field device [Also see Fig 16 and related text]).
Regarding Claim 3: Mohebi / McAdam teaches all the limitations of claim 2 above.
Mohebi further teaches “The method of claim 2, wherein the at least one actionable task item and the attributes are depicted on the communication device as a series of HMI screens to guide the field operator on the operation to be performed on the at least one equipment” (See Mohebi field device user interface 118 screens in Figs. 4-14. Mid-¶ [0031]: …For instance, one or more field personnel responsible for performing asset tasks (e.g., operational tasks, monitoring tasks, maintenance tasks, etc.) can carry the field device(s) 110 to the physical locations of the facility asset(s) 104 and use the field device(s) 110 to access the workflow data 114 and/or generate new workflow data 114. For instance, an application of the asset tracking platform 102 executing on the device(s) 110 can download the workflow data 114 from the 108 and/or cause the device(s) 110 to generate a field device user interface (UI) 118 representing the workflow data 114 to complete particular asset task [EN: task item] for the facility asset 104).
Regarding Claim 4: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Mohebi further teaches “The method of claim 1 further comprising:
“receiving a response from the communication device of the field operator, the response comprising an indication of execution of the HFA command, and based on the response, transmitting a status of completion of the HFA command to an application from where the HFA request is received” (Mohebi mid-¶ [0082]: At operation 1608, the method 1600 performs a task execution procedure corresponding to a task entry of the asset task list by scanning a physical asset tag of the one or more physical asset tags to generate task completion data. At operation 1610, the method 1600 uploads the task completion data from the field device to a site operator device at the operational facility site).
Regarding Claim 5: Mohebi / McAdam / Ehrman teaches all the limitations of claim 4 above.
Mohebi further teaches “The method of claim 4, further comprising generating a prompt for the response from the communication device of the field operator” (Mohebi ¶ [0067]: A create work order prompt can be presented in response to receiving an input at a work order button (e.g., as shown in FIG. 4) to create the work order task. The work order prompt can receive asset data 208 and task data 210 associated with the work order and generated by the field personnel manually (e.g., including the facility or operational site name, the asset type, comments or description of the problem, an inspector name, an inspection company, an estimated cost, a priority level, attachments, etc.). Upon creating the work order task, the field device(s) 110 can perform a data syncs 116 (as discussed above) to add the work order task to the workflow data 114).
Regarding Claim 7: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Mohebi further teaches “The method of claim 1, further comprising; detecting the communication device to be unavailable to receive the HFA command; and queuing the HFA command until the communication device is available for receiving the HFA command” (Mohebi mid-[0032]: …In some instances, the field device 110 can conduct the data sync 116 from various locations throughout the operational site 106 that have local network connectivity with the site operator device 108 (e.g., wired and/or wireless). Additionally or alternatively, the field device(s) 110 can perform the data syncs 116 [EN: receive command] in response to being [EN: available] within a predetermined distance of the site operator device 108, for instance, when the field personnel returns to an operations room or administrative building of the operational site 106).
Regarding Claim 8: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Mohebi further teaches “The method of claim 1, wherein the attributes include at least one of a type, geolocation, and identification of the at least one equipment” (Mohebi [0037]: In some examples, the workflow data 114 can include asset data 208. The asset data 208 can be information associated with the facility assets 104 distributed throughout the operational site 106. For instance, the asset data 208 can include an asset type, an asset identifier, an applicable standard (e.g., industry standard) for the asset, a facility name associated with the asset, an asset description, and the like. ¶ [0038]: The workflow data 114 can, in some scenarios, include an asset map 216 and/or a task map 218. The asset map 216 can be a map generated and presented at the field device(s) 110 or the site operator device 108 showing the facility assets 104 as one or more visual indicators layered over a map of the operational site 106. ¶ [0042]: In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110).
Regarding Claim 9: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Mohebi further teaches “The method of claim 1, further comprising selecting, based on the attributes of the at least one equipment and the operation to be performed on the at least one equipment, the template from a library of predefined templates” (See Mohebi centralized library of workflow templates: ¶ [0031]: The site operator device 108 can receive, aggregate, and/or store workflow data 114 for the operational site 106. The workflow data 114 can include data related to the facility asset(s) 104 (e.g., as discussed in greater detail below) that is continually updated via a plurality of data syncs 116 from the device(s) 110. ¶ [0047]: …the task list 302 [EN: template] can be a list or spreadsheet with a row 304 of the task list 302 representing an asset task, and a column 306 of the task list 302 representing a particular type [EN: pre-defined] of asset data 208 or task data 210. For instance, one or more columns can represent an asset [EN: equipment] identifier, an asset [EN: equipment] type, an applicable standard for the asset, a facility name associated with the asset, an asset description, a task [EN: operation] identifier, a task [EN: operation] category, a task status, a task frequency, a task opened date, a task completed date, and the like. The task list 302 can include one or more interactive elements (e.g., the task identifiers) that, upon receiving a user input, cause the site operator UI 124 to present additional details regarding the selected task or task entry. The task list 302 can be used for workflow planning at the operational site 106 by selecting which tasks or task filters [EN: configurable parameters] to apply to asset task lists that are downloaded to field operator devices 110, as discussed below. [Also see figs. 3, 7 and related text]).
Regarding Claim 10: Mohebi teaches “A human field activity (HFA) service system, comprising:
“one or more processors;
“a human field activity (HFA) collector module coupled to the one or more
processors, wherein the HFA collector module is configured to:
“identify, based on an HFA request, an operation to be performed by a field operator on an equipment in a facility” (Mohebi ¶ [0082]: In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags to one or more facility assets [EN: equipment] at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented at the field device);
“select, based on the HFA request, a template from a library of predefined templates, the template comprising configurable parameters readable by a workflow management system, wherein the workflow management system is implemented to manage operation of the equipment based on a predefined standard operating procedures (SOPs) of the facility” (See Mohebi centralized library of workflow templates: ¶ [0031]: The site operator device 108 can receive, aggregate, and/or store workflow data 114 for the operational site 106. The workflow data 114 can include data related to the facility asset(s) 104 (e.g., as discussed in greater detail below) that is continually updated via a plurality of data syncs 116 from the device(s) 110. ¶ [0047]: …the task list 302 [template] can be a list or spreadsheet with a row 304 of the task list 302 representing an asset task, and a column 306 of the task list 302 representing a particular type [EN: pre-defined] of asset data 208 or task data 210. For instance, one or more columns can represent an asset identifier, an asset type, an applicable standard for the asset, a facility name associated with the asset, an asset description, a task identifier, a task category, a task status, a task frequency, a task opened date, a task completed date, and the like. The task list 302 can include one or more interactive elements (e.g., the task identifiers) that, upon receiving a user input, cause the site operator UI 124 to present additional details regarding the selected task or task entry. The task list 302 can be used for workflow planning at the operational site 106 by selecting which tasks or task filters [EN: configurable parameters] to apply to asset task lists that are downloaded to field operator devices 110, as discussed below. [Also see figs. 3, 7 and related text]);
[..]
“generate [based on the real time operational data], an HFA command by conforming at least one actionable task item specifying an action involved in the operation and attributes of the equipment associated with the HFA request into the configurable parameters of the template, [..]” (Mohebi ¶ [0030]: FIG. 16 illustrates an example method 1600 to track facility assets 104 using the asset tracking platform 102, which can be performed by any of the systems 100-1500 disclosed herein. ¶ [0082] In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags to one or more facility assets at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented at the field device [Also see Fig 16 and related text]); and
“a communication module coupled to the one or more processors, wherein the communication module is configured to transmit the HFA command to a client of the workflow management system accessible by the field operator” (Mohebi ¶ [0032]: The field device 110 can conduct the data syncs 116 [EN: receive commands] with the site operator device 108 (e.g., upon performing the asset task). For instance, the operational site 106 can include a local area network (LAN) or intranet [EN: communication module] to provide a communication channel between the field device(s) 110 and the site operator device 108);
“determine, by the by the client of the workflow management system, that a communication device of the field operator is at a geolocation of the at least one equipment” (Mohebi ¶ [0042]: …The asset tag(s) 204 can be a Near Field Communication (NFC) tag that uses RFID to provide information, such as the tag identifier(s) 214, to the field device(s) 110…. The sensors 202 on the field device 110 can include an NFC reader for reading the tag identifier(s) 214 from the asset tag(s) 204 when the field device(s) 110 is in close proximity to the asset tag(s) 204. In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110);
“upon successful determination, enable the field operator to perform the HFA request as specified in the HFA command” (See Mohebi Fig. 7: “Tap Phone to NFC tag to find and start task” and Fig. 7 related text);
“generate a prompt on the communication device of the field operator to receive at least partial completion status of completion of the operation; dynamically modify the HFA command template to reflect the partial completion status of the operation [..]” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like)
[..] “and
“execute on a display of the communication device associated with the [other] field operator, information corresponding to the remaining steps defined by the updated HFA command” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like).
Although Mohebi teaches generating and sending an equipment operating procedure command to a human field operator, Mohebi does not specifically teach monitoring the operational state of the equipment with sensors in real time to generate the command, nor reassigning tasks to other operators in the field.
However, McAdam in analogous art of industrial field operator management teaches or suggests:
“obtain real-time operational data from one or more sensors monitoring the at least one equipment, the real-time operational data representing a current operational state of the equipment” (McAdam ¶ [0053]: Corrective action may be taken based on determining this equipment information. For example, if the equipment is showing signs of wear or failure, corrective actions may be taken, such as taking an inventory of parts to ensure replacement parts are available, ordering replacement parts, and/or calling in repair personnel to the site. Certain parts of equipment may be replaced immediately. Other parts may be safe to continue to use, but a monitoring schedule may be adjusted. Alternatively or additionally, one or more inputs or controls relating to a process may be adjusted as part of the corrective action. These and other details about the equipment, sensors, processing of sensor data, and actions taken based on sensor data are described in further detail below. Such corrective actions may be implemented as part of a modified mobile workflow. Such a mobile workflow may include step-by-step instructions/procedures for a field worker to implement and the workflow may be modified in response to a current operating condition for a measurable element, such as a pressure measurement, of an asset, such as a PSA unit. For example, a field worker repairing or working on a piece of equipment as part of a multi-step workflow may receive, at a device, an updated workflow or next step in the workflow based on the current operating condition for the measurable element);
[..]
“wherein the HFA command represents the current operational state of the at least one equipment” (see again McAdam ¶ [0053]).
McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi’s facility asset tracking system and method to have included McAdam’s teachings around monitoring the operational state of the equipment with sensors in real time to generate an equipment operating procedure command. The benefit of these additional features would have improved plant efficiency through responsive maintenance for conditions requiring deviation from standard field procedures (McAdam ¶ [0002, 0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Furthermore, Ehrman in analogous art of industrial field operator management teaches or suggests:
“[..] to reassign the operation to another field operator (Ehrman ¶ [0211]: The task may remain assigned to the particular operator until it is indicated as being completed, cannot be completed, canceled by the operator, or until a predetermined period of time passes without the task being completed when it may be reassigned to another operator. ¶ [0212]: The work request dispatch engine 200 may also maintain and manage the work requests. In particular, the work request dispatch engine 200 may load balance work between operators based on system configuration parameters and a set of heuristics. For example, if a task has been assigned to an operator who has failed to complete it after a predetermined amount of time, cancels the task, or is currently working on a different work request, the task may be reassigned to another operator that is available and can complete the task);
“upon reassignment of the operation to the other field operator, update the HFA command to specify remaining steps in the operation to be performed” (Ehrman end-¶ [0266]: The operator may be given a prompt to indicate that the work request is in progress and/or near completion. The work request assignment engine 280 may respond by reassigning the task to the operator and providing additional time for completion).
Ehrman, McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi / McAdam’s facility asset tracking system and method to have included Ehrman’s teachings around reassigning tasks to other operators in the field. The benefit of these additional features would have increased continuity and accuracy of assigning work requests in an asset management system (Ehrman ¶ [0008]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam and Ehrman (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam and Ehrman above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 11: Mohebi / McAdam / Ehrman teaches all the limitations of claim 10 above.
Mohebi further teaches “The system of claim 10, wherein the HFA collector module is to select the template, from the library of predefined templates, based on a type of the equipment and the operation to be performed on the equipment” (See Mohebi centralized library of workflow templates: ¶ [0031]: The site operator device 108 can receive, aggregate, and/or store workflow data 114 for the operational site 106. The workflow data 114 can include data related to the facility asset(s) 104 (e.g., as discussed in greater detail below) that is continually updated via a plurality of data syncs 116 from the device(s) 110. ¶ [0047]: …the task list 302 can be a list or spreadsheet with a row 304 [EN: template] of the task list 302 representing an asset task, and a column 306 of the task list 302 representing a particular type [EN: pre-defined] of asset data 208 or task data 210. For instance, one or more columns can represent an asset [EN: equipment] identifier, an asset [EN: equipment] type, an applicable standard for the asset, a facility name associated with the asset, an asset description, a task [EN: operation] identifier, a task [EN: operation] category, a task status, a task frequency, a task opened date, a task completed date, and the like. The task list 302 can include one or more interactive elements (e.g., the task identifiers) that, upon receiving a user input, cause the site operator UI 124 to present additional details regarding the selected task or task entry. The task list 302 can be used for workflow planning at the operational site 106 by selecting which tasks or task filters [EN: configurable parameters] to apply to asset task lists that are downloaded to field operator devices 110, as discussed below. [Also see figs. 3, 7 and related text]).
Regarding Claim 12: Mohebi / McAdam / Ehrman teaches all the limitations of claim 10 above.
Mohebi further teaches “The system of claim 10, wherein the communication module is further to present the at least one actionable task item and the attributes as a series of HMI screens displayable by the client of the workflow management system” (See Mohebi field device user interface 118 screens in Figs. 4-14. Mid-¶ [0031]: …For instance, one or more field personnel responsible for performing asset tasks (e.g., operational tasks, monitoring tasks, maintenance tasks, etc.) can carry the field device(s) 110 to the physical locations of the facility asset(s) 104 and use the field device(s) 110 to access the workflow data 114 and/or generate new workflow data 114. For instance, an application of the asset tracking platform 102 executing on the device(s) 110 can download the workflow data 114 from the 108 and/or cause the device(s) 110 to generate a field device user interface (UI) 118 representing the workflow data 114 to complete particular asset task [EN: task item] for the facility asset 104).
Regarding Claim 14: Mohebi / McAdam / Ehrman teaches all the limitations of claim 10 above.
Mohebi further teaches “The system of claim 10, wherein the configurable parameters include at least one of a geolocation of the equipment and identification of the equipment” (Mohebi [0037]: In some examples, the workflow data 114 can include asset data 208. The asset data 208 can be information associated with the facility assets 104 distributed throughout the operational site 106. For instance, the asset data 208 can include an asset type, an asset identifier, an applicable standard (e.g., industry standard) for the asset, a facility name associated with the asset, an asset description, and the like. ¶ [0038]: The workflow data 114 can, in some scenarios, include an asset map 216 and/or a task map 218. The asset map 216 can be a map generated and presented at the field device(s) 110 or the site operator device 108 showing the facility assets 104 as one or more visual indicators layered over a map of the operational site 106. ¶ [0042]: In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110).
Regarding Claim 15: Mohebi / McAdam / Ehrman teaches all the limitations of claim 10 above.
Mohebi further teaches “The system of claim 10, wherein the communication module is to further:
“receive a response from the client of the workflow management system, the response comprising an indication of execution of the HFA command” (Mohebi mid-¶ [0082]: At operation 1608, the method 1600 performs a task execution procedure corresponding to a task entry of the asset task list by scanning a physical asset tag of the one or more physical asset tags to generate task completion data), “and
“based on the response, update a status of completion of the HFA command at the workflow management system, wherein workflow management system is to further update the status at the source” (Mohebi mid-¶ [0082]: At operation 1610, the method 1600 uploads the task completion data from the field device to a site operator device at the operational facility site).
Regarding Claim 16: Mohebi / McAdam / Ehrman teaches all the limitations of claim 15 above.
Mohebi further teaches “The system of claim 15, wherein the communication module is further to generate a prompt for the response from the client” (Mohebi ¶ [0067]: A create work order prompt can be presented in response to receiving an input at a work order button (e.g., as shown in FIG. 4) to create the work order task. The work order prompt can receive asset data 208 and task data 210 associated with the work order and generated by the field personnel manually (e.g., including the facility or operational site name, the asset type, comments or description of the problem, an inspector name, an inspection company, an estimated cost, a priority level, attachments, etc.). Upon creating the work order task, the field device(s) 110 can perform a data syncs 116 (as discussed above) to add the work order task to the workflow data 114).
Regarding Claim 17: Mohebi teaches “A non-transitory computer-readable medium comprising instructions executable by a processing resource to:
[..]
“generate a human field activity (HFA) command based on an HFA request, the real time operational data and a template, wherein the HFA request specifies an operation to be done on an equipment in a facility by a field operator (Mohebi ¶ [0082]: In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags to one or more facility assets [EN: equipment] at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented at the field device),
“wherein the template provides a format to specify attributes of the equipment in the HFA command, the format being compatible with a workflow management system that manages standard operating procedures (SOPs) of the facility, and wherein the attributes include at least one of a type, and identification of the equipment, [..]” (Mohebi ¶ [0063]: As depicted in FIG. 12, the system 1200 can include the task map 218 and an asset-specific tasks list 1202 [EN: template] for viewing the task data 210 for a particular facility asset 104. ¶ [0047]: …the task list 302 [EN: template] can be a list or spreadsheet with a row 304 of the task list 302 representing an asset task, and a column 306 of the task list 302 representing a particular type of asset data 208 or task data 210. For instance, one or more columns can represent an asset [EN: equipment] identifier, an asset [EN: equipment] type, an applicable standard for the asset, a facility name associated with the asset, an asset description [EN: attribute specification], a task identifier, a task category, a task status, a task frequency, a task opened date, a task completed date, and the like. The task list 302 can include one or more interactive elements (e.g., the task identifiers) that, upon receiving a user input, cause the site operator UI 124 to present additional details regarding the selected task or task entry. The task list 302 can be used for workflow planning at the operational site 106 by selecting which tasks or task filters [EN: configurable parameters] to apply to asset task lists that are downloaded to field operator devices 110, as discussed below. [Also see figs. 3, 7 and related text]);
“transmit the HFA command to a communication device of the field operator; receive a response from the communication device indicating receipt of the HFA command at the communication device” (Mohebi ¶ [0032]: The field device 110 can conduct the data syncs 116 [EN: receive commands, send response] with the site operator device 108 (e.g., upon performing the asset task). For instance, the operational site 106 can include a local area network (LAN) or intranet [EN: communication module] to provide a communication channel between the field device(s) 110 and the site operator device 108);
“determine that the communication device of the field operator is at a geolocation of the at least one equipment” (Mohebi ¶ [0042]: …The asset tag(s) 204 can be a Near Field Communication (NFC) tag that uses RFID to provide information, such as the tag identifier(s) 214, to the field device(s) 110…. The sensors 202 on the field device 110 can include an NFC reader for reading the tag identifier(s) 214 from the asset tag(s) 204 when the field device(s) 110 is in close proximity to the asset tag(s) 204. In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110);
“upon successful determination, enable the field operator to perform the HFA request as specified in the HFA command” (See Mohebi Fig. 7: “Tap Phone to NFC tag to find and start task” and Fig. 7 related text);
“generate a prompt on the communication device of the field operator to receive at least partial completion status of completion of the operation; dynamically modify the HFA command template to reflect the partial completion status of the operation [..]” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like)
[..] “and
“execute on a display of the communication device associated with the [other] field operator, information corresponding to the remaining steps defined by the updated HFA command” (Mohebi ¶ [0049]: Moreover, the field operator dashboard 402 can include a data sync button for initiating the data syncs 116 in response to an input, a view tasks button for viewing the downloaded task list 702 (discussed below regarding FIG. 7), and/or a work order button for initiating the creation of a work order (e.g., discussed below regarding FIG. 14). Once one or more tasks listed in the downloaded task list 702 are completed, task completion data is generated, such as a status change for the completed task (e.g., from open or in-progress to closed), a task completion time, a task attachment or comment, a red flag, a task completion field device location, a notification at the field operator dashboard 402 (e.g., or other interface of the field device UI 118) indicating that the change has occurred, and the like).
Although Mohebi teaches generating and sending an equipment operating procedure command to a human field operator, Mohebi does not specifically teach monitoring the operational state of the equipment with sensors in real time to generate the command.
However, McAdam in analogous art of industrial field operator management teaches or suggests:
“obtain real-time operational data from one or more sensors monitoring the at least one equipment, the real-time operational data representing a current operational state of the at least one equipment” (McAdam ¶ [0053]: Corrective action may be taken based on determining this equipment information. For example, if the equipment is showing signs of wear or failure, corrective actions may be taken, such as taking an inventory of parts to ensure replacement parts are available, ordering replacement parts, and/or calling in repair personnel to the site. Certain parts of equipment may be replaced immediately. Other parts may be safe to continue to use, but a monitoring schedule may be adjusted. Alternatively or additionally, one or more inputs or controls relating to a process may be adjusted as part of the corrective action. These and other details about the equipment, sensors, processing of sensor data, and actions taken based on sensor data are described in further detail below. Such corrective actions may be implemented as part of a modified mobile workflow. Such a mobile workflow may include step-by-step instructions/procedures for a field worker to implement and the workflow may be modified in response to a current operating condition for a measurable element, such as a pressure measurement, of an asset, such as a PSA unit. For example, a field worker repairing or working on a piece of equipment as part of a multi-step workflow may receive, at a device, an updated workflow or next step [EN: HFA command] in the workflow based on the current operating condition for the measurable element);
[..]
“wherein the HFA command represents the current operational state of the at least one equipment” (see again McAdam ¶ [0053]).
McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi’s facility asset tracking system and method to have included McAdam’s teachings around monitoring the operational state of the equipment with sensors in real time to generate an equipment operating procedure command. The benefit of these additional features would have improved plant efficiency through responsive maintenance for conditions requiring deviation from standard field procedures (McAdam ¶ [0002, 0006]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Furthermore, Ehrman in analogous art of industrial field operator management teaches or suggests:
“[..] to reassign the operation to another field operator” (Ehrman ¶ [0211]: The task may remain assigned to the particular operator until it is indicated as being completed, cannot be completed, canceled by the operator, or until a predetermined period of time passes without the task being completed when it may be reassigned to another operator. ¶ [0212]: The work request dispatch engine 200 may also maintain and manage the work requests. In particular, the work request dispatch engine 200 may load balance work between operators based on system configuration parameters and a set of heuristics. For example, if a task has been assigned to an operator who has failed to complete it after a predetermined amount of time, cancels the task, or is currently working on a different work request, the task may be reassigned to another operator that is available and can complete the task);
“upon reassignment of the operation to the other field operator, update the HFA command to specify remaining steps in the operation to be performed” (Ehrman end-¶ [0266]: The operator may be given a prompt to indicate that the work request is in progress and/or near completion. The work request assignment engine 280 may respond by reassigning the task to the operator and providing additional time for completion);
Ehrman, McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi / McAdam’s facility asset tracking system and method to have included Ehrman’s teachings around reassigning tasks to other operators in the field. The benefit of these additional features would have increased continuity and accuracy of assigning work requests in an asset management system (Ehrman ¶ [0008]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of McAdam and Ehrman (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of McAdam and Ehrman above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 18: Mohebi / McAdam / Ehrman teaches all the limitations of claim 17 above.
Mohebi further teaches “The non-transitory computer-readable medium as claimed in claim 17 further comprising instructions executable by the processing resource to specify at least one actionable task item corresponding to the operation in the HFA command” (Mohebi ¶ [0030]: FIG. 16 illustrates an example method 1600 to track facility assets 104 using the asset tracking platform 102, which can be performed by any of the systems 100-1500 disclosed herein. ¶ [0082] In some examples, at operation 1602, the method 1600 assigns one or more physical asset tags to one or more facility assets at an operational facility site. At operation 1604, the method 1600 downloads an asset task list to a field device from an operational site device at the operational facility site. At operation 1606, the method generates an asset map and/or a task map representing task entries of the asset task list to be presented at the field device [Also see Fig 16 and related text]).
Regarding Claim 19: Mohebi / McAdam / Ehrman teaches all the limitations of claim 18 above.
Mohebi further teaches “The non-transitory computer-readable medium as claimed in claim 18 further comprising instructions executable by the processing resource to present the at least one actionable task item and the attributes as a series of HMI screens on the communication device (See Mohebi field device user interface 118 screens in Figs. 4-14. Mid-¶ [0031]: …For instance, one or more field personnel responsible for performing asset tasks (e.g., operational tasks, monitoring tasks, maintenance tasks, etc.) can carry the field device(s) 110 to the physical locations of the facility asset(s) 104 and use the field device(s) 110 to access the workflow data 114 and/or generate new workflow data 114. For instance, an application of the asset tracking platform 102 executing on the device(s) 110 can download the workflow data 114 from the 108 and/or cause the device(s) 110 to generate a field device user interface (UI) 118 representing the workflow data 114 to complete particular asset task [task item] for the facility asset 104).
Regarding Claim 20: Mohebi / McAdam / Ehrman teaches all the limitations of claim 17 above.
Mohebi further teaches “The non-transitory computer-readable medium as claimed in claim 17 further comprising instructions executable by the processing resource to specify geolocation of the equipment, picture of the equipment, distance of the equipment from a current GPS position of the field operator in the facility as one of the attributes of the equipment in the HFA command (Mohebi mid-[0042]: …The asset tag(s) 204 can be a Near Field Communication (NFC) tag that uses RFID to provide information, such as the tag identifier(s) The sensors 202 on the field device 110 can include an NFC reader for reading the tag identifier(s) 214, to the field device(s) 110… The sensors 202 on the field device 110 can include an NFC reader for reading the tag identifier(s) 214 from the asset tag(s) 204 when the field device(s) 110 is in close proximity [EN: distance] to the asset tag(s) 204. In some scenarios, location data 222 associated with the field device(s) 110 (e.g., global positioning satellite (GPS) coordinates) can be associated with the tag identifier 214 (e.g., and the corresponding facility assets 104 to which the asset tag 204 is attached) upon reading the asset tag 204 with the field device(s) 110. ¶ [0060]: In some examples, the asset map 216 is generated once one or more asset tag(s) 204 are attached and assigned to the facility assets 104 or equipment. The asset map 216 can include a map image (e.g., bird's eye view) of the operational site 106 or a portion of the operational site 106 (e.g., using a zoom or scroll) with one or more asset indicators 1002 layered over the map image. The one or more asset indicators 1002 can be color coded with colors corresponding to the different asset types (e.g., filter, general, tank, separator, pump, loading, valve, hydrant, and the like). Moreover, the asset indicators 1002 can include a number or letter indicating the asset types. [Also see labeled images of assets on asset map in Fig. 10 and related text]).
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Claims 6, 13 are rejected under 35 U.S.C. 103 as being unpatentable over:
Mohebi / McAdam / Ehrman as applied above, in further view of
Campbell US 20180024847 A1 hereinafter Campbell. As per,
Regarding Claim 6: Mohebi / McAdam / Ehrman teaches all the limitations of claim 1 above.
Although Mohebi teaches generic network architectures used to communicate HFA requests, Mohebi does not specifically teach the utilization of a hierarchical or topological collection of networks used to communicate HFA requests.
However, Campbell in analogous art of industrial field operator management teaches or suggests “The method of claim 1, wherein the HFA request is received from an application at network level 1 through network level 3 of a network implemented in the facility” (Campbell ¶ [0047]: FIG. 2 illustrates an expanded plant network and communication system 110 in which a fleet management system 112 may be used to manage one or more fleets of portable devices [EN: which receive HFA requests] (such as the portable devices 100 of FIG. 1), or in some cases stationary devices [EN: which receive HFA requests], associated with or used in a plant environment or other industrial setting. The plant network and communication system 110 (or other industrial setting or environment) includes or is connected to an external server network 114 which may be located at an external (to the plant) site, such as in the cloud. The plant network and communication system 110 additionally includes a set of interconnected communication networks at the plant site (or at multiple plant sites or locations). In particular, the plant networks illustrated in FIG. 2 include a top level or business network 116, a plant administrative network 118, and a plant device network 120 which is connected to one or more control networks 122 (only one of which is illustrated in FIG. 2). As will be understood, the plant network 120 and the control network 122 may be the network 10 and sub-networks connected thereto for supporting the field devices 15-22 illustrated in FIG. 1. [Also see Fig. 2 and related text]).
Campbell, Ehrman, McAdam and Mohebi are found as analogous art of industrial field operator management. It would have been obvious to one skilled in the art, before the effective filing date of the invention, to have modified Mohebi’s facility asset tracking system and method to have included Campbell’s teachings around the use of hierarchical networks for field operation. The benefit of these additional features would have improved the support for and communication among the evolving needs of a modern variety of portable fleet devices in the industrial setting (Campbell ¶ [0014]). The predictability of such modifications and/or variations, would have been corroborated by the broad level of skill of one of ordinary skills in the art as articulated by Mohebi in view of Campbell, Ehrman and McAdam (see MPEP 2143 G).
Further, the claimed invention could have also been viewed as a mere combination of old elements in a similar field of industrial field operator management. In such combination each element would have merely performed same organizational and managerial function as it did separately. Thus, one of ordinary skill in the art would have recognized that, given existing technical ability to combine the elements, as evidenced by Mohebi in view of Campbell, Ehrman and McAdam above, the to- be combined elements would have fit together like pieces of a puzzle in a logical, complementary, technologically feasible and/or economically desirable manner. Thus, it would have been reasoned that the results of the combination would have been predictable (see MPEP 2143 A).
Regarding Claim 13: Mohebi / McAdam / Ehrman teaches all the limitations of claim 10 above.
Although Mohebi teaches generic network architectures used to communicate HFA requests, Mohebi does not specifically teach the utilization of a hierarchical or topological collection of networks used to communicate HFA requests.
However, Campbell in analogous art of industrial field operator management teaches or suggests “The system of claim 10, wherein the HFA collector module is configured to receive the HFA request from a source at any network level of a network implemented in the facility” (Campbell ¶ [0047]: FIG. 2 illustrates an expanded plant network and communication system 110 in which a fleet management system 112 may be used to manage one or more fleets of portable devices [EN: which receive HFA requests] (such as the portable devices 100 of FIG. 1), or in some cases stationary devices [EN: which receive HFA requests], associated with or used in a plant environment or other industrial setting. The plant network and communication system 110 (or other industrial setting or environment) includes or is connected to an external server network 114 which may be located at an external (to the plant) site, such as in the cloud. The plant network and communication system 110 additionally includes a set of interconnected communication networks at the plant site (or at multiple plant sites or locations). In particular, the plant networks illustrated in FIG. 2 include a top level or business network 116, a plant administrative network 118, and a plant device network 120 which is connected to one or more control networks 122 (only one of which is illustrated in FIG. 2). As will be understood, the plant network 120 and the control network 122 may be the network 10 and sub-networks connected thereto for supporting the field devices 15-22 illustrated in FIG. 1. [Also see Fig. 2 and related text]).
Rationales to have combined/modified Mohebi / McAdam / Ehrman / Campbell are above and reincorporated.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Conclusion
The following art is made of record and considered pertinent to Applicant’s disclosure:
Balentine et al. US 20120296448 A1, Software lockout coordination between a process control system and an asset management system.
Dalal et al. US 20200026257 A1, Augmented reality (AR) based fault detection and maintenance.
Decker et al. US 20240112114 A1, Management of job safety analysis records.
Hinckley et al. US 20140278717 A1, Method for guided data collection management.
Kozma et al. "Dynamic Multilevel Workflow Management Concept for Industrial IoT Systems," in IEEE Transactions on Automation Science and Engineering, vol. 18, no. 3, pp. 1354-1366, July 2021, doi: 10.1109/TASE.2020.3004313.
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9131867
Krishnaswamy et al. US 20220198565 A1, Management of a portfolio of assets.
Maddox, Jr. et al. US 20050182650 A1, Maintenance and inspection system.
Maggiore et al. US 20200142388 A1, Assisting execution of manual protocols at production equipment.
Mitti et al. US 20160140499 A1, Engineering document mobile collaboration tool.
Norman WO 2020013909 A1, Block-based prediction for manufacturing environments.
Phillips et al. US 20170243141 A1, Oil-field electronic run tickets.
Qian et al. US 20210382915 A1, Methods, systems and computer program products for data synchronization in industrial plants.
Rose et al. US 20190171186 A1, Dynamically establishing communication between mobile equipment and a process controller.
Webb US 20150142491 A1, Management of field-based workers.
Witter et al. US 20080313006 A1, Systems, methods, and devices for managing emergency power supply systems.
Ranjan et al. US 20240264895 A1, Root cause analysis within a centralized service management platform.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Any inquiry concerning this communication or earlier communications from the examiner should be directed to REED M. BOND whose telephone number is (571) 270-0585. 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, Patricia Munson can be reached at (571) 270-5396. 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.
/REED M. BOND/Examiner, Art Unit 3624 May 8, 2026
/HAMZEH OBAID/Primary Examiner, Art Unit 3624 May 11, 2026
Prosecution Insights