Prosecution Insights
Last updated: April 19, 2026
Application No. 14/843,323

METHOD AND APPARATUS FOR CONTROLLING A PROCESS PLANT WITH WEARABLE MOBILE CONTROL DEVICES

Final Rejection §103
Filed
Sep 02, 2015
Examiner
PEACH, POLINA G
Art Unit
2165
Tech Center
2100 — Computer Architecture & Software
Assignee
Fisher-Rosemount Systems Inc.
OA Round
18 (Final)
50%
Grant Probability
Moderate
19-20
OA Rounds
3y 7m
To Grant
73%
With Interview

Examiner Intelligence

Grants 50% of resolved cases
50%
Career Allow Rate
229 granted / 461 resolved
-5.3% vs TC avg
Strong +23% interview lift
Without
With
+23.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 7m
Avg Prosecution
34 currently pending
Career history
495
Total Applications
across all art units

Statute-Specific Performance

§101
17.9%
-22.1% vs TC avg
§103
49.9%
+9.9% vs TC avg
§102
14.5%
-25.5% vs TC avg
§112
11.2%
-28.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 461 resolved cases

Office Action

§103
DETAILED ACTION Status of the Claims Claims 1, 46 have been amended. Claims 22-45 remain withdrawn from a consideration. Claims 1-18, 21 and 46 are presented for examination. 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, 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. ◊ Claim(s) 1 is rejected under 35 U.S.C. 103 as being unpatentable over Chen et al. (US 20050164684) in view of Collin (US 20140304612) and JUNG et al. (US 20110249593). Regarding claim 1, Chen teaches a wearable mobile user interface device for controlling a process plant, the wearable mobile user interface device comprising: a housing configured to secure the wearable device to a user ([0024]-[0025], [0048], [0100]); a processor, disposed within the housing, communicatively coupled to a network; a memory device, disposed within the housing, communicatively coupled to the processor ([0028], F2); a display, disposed within or physically coupled to the housing, communicatively coupled to the processor (F11-14); and one or more routines stored on the memory device and executable by the processor to cause the processor to ([0052]) communicate with one or more servers (see NOTE) communicatively connected to a process controller controlling a physical process executing within the process plant ([0071], [0079]-[0080]), the controller communicatively coupled to a plurality of field devices in the process plant and operating to control the field devices to perform a physical function within the process plant ([0023], [0076]), the one or more stored routines comprising at least a routine for (1) identifying a process control device in physical proximity to the wearable mobile user interface device by one or more sensing units of the wearable mobile user interface device ([0067], [0069], [0097]) detecting information within the process plant, the information being associated with the process control device ([0041]-[0042], [0046]-[0047], [0062], [0096]), and (2) causing a data stream comprising data values ([0046] “obtain the most recent values or data”, F8 see “CURRENT VALUE”, [0058] “obtains the current process value of the selected communication channel from the host system or from the field device”, [0061] “automatically cause messages associated with devices that are physically near the user to appear”, [0067] where “field devices such as electronic sensors, transmitters, current-to-pressure transducers” provide data stream of values, [0058] “obtains the current process value of the selected communication channel from the host system or from the field device … obtained directly from the field device itself via a wireless connection”, [0072]-[0073], [0098] “sent from the host system 390 to the device being controlled via the handheld communicator 330 … in real-time”) associated with the identified process control device to be transmitted ([0062]) by the one or more servers (F15:390, [0080]-[0081]) to the wearable mobile user interface device ([0054], [0057], [0061]) including receiving, from the one or more servers, (3) executing a user interface application ([0049] “a software routine 116 that can be run on the host computer 14 and a block diagram of a software routine 118 that can be run on the portable computer system 30 to implement a shared view or display”) using the data values in the data stream to perform a function with respect to the process control device ([0046], [0062], [0068], [0081] “configure or reconfigure a device, to obtain any other desired and available information from the device or to cause the device to perform a function, such as a control function, a testing function, a communication function”, [0096]), (4) storing operational state information defining the NOTE I), and (5) sending the operational state information defining the share the user interface application on the further user interface device based on the NOTE I - Chen does not explicitly teach “operational state of the user interface application”. Instead, Chen teaches providing “a shared view” of the handheld device 30 to an operator at the host computer. Such shared view, which is a frozen image of the user device is at least indicative of the “state of the user interface application.” Although state depicts operational state of a process or device of interest it is also obviously shows a snapshot image of the application operation on the user device. Still, Chen does not explicitly teach, however Collin or JUNG disclose (4) storing operational state information defining the operational state of the user interface application (Collin [0079], JUNG [0078], [0080], [0145], [0165]), and (5) sending the operational state information defining the operational state of the user interface application to the one or more servers or to another device, to enable a further user interface device using the operational state information to implement the user interface application on the further user interface device based on the operational state information (Collin [0082], JUNG [0165], [0172], [0178]). 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 teachings of Chen to include operational state of the user application and enable a further user interface to implement the user interface application on the further user interface as disclosed by Collin or JUNG. Doing so allows for a transition between the first and second applications to be much smoother for the user as much of the context of the first application can be maintained in the second application and also saves the user a lot of time configuring the second editor in order to approximate the state in which the first editor was before the transition (Collin [0082]). Further Chen does not explicitly teach, however JUNG disclose metadata defining a format of the data values in the data stream ([0019], [0032], [0153]). NOTE - Chen does not explicitly teach a server, instead Chen teaches “the host device 390 and/or with the information repository”, which communicates with a plurality of filed devices and a handheld device [0090]. Although, not explicitly being called as such, the host device 390 is obviously analogous to the claimed server. I.e. by definition a server is a computer or computer program which manages access to a centralized resource or service in a network. The host device 390 is a centralize resource between the field devices and the user’s handled device, and meets a definition of a server. However, to further obviate such reasoning, JUNG discloses one or more servers ([0073], [0090], [0140]). It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Chen as modified to include metadata defining a format and one or more servers as disclosed by JUNG. Doing so would allow the user to effectively respond to the operation-state-changed device over the network (JUNG [0095]). NOTE II Additionally and alternatively an analogous prior art - Tran et al. (US 10027676) and Uola et al. (US 20130275994) likewise discloses prongs (4) and (5) and further obviates the teaching of Chen. ◊ Claim(s) 1-16, 18, 20-21, 46, is/are rejected under 35 U.S.C. 103 as being unpatentable over Peterson et al. (US 20090065578) in view of Collin (US 20140304612) and JUNG et al. (US 20110249593) and in further view of Osterhout et al. (US 20110213664). Regarding claim 1, Peterson teaches a wearable mobile user interface device for controlling a process plant ([0023]), the wearable mobile user interface device comprising: a housing configured to secure the wearable device to a user ([0051]); a processor, disposed within the housing, communicatively coupled to a network (F2-3); a memory device, disposed within the housing, communicatively coupled to the processor; a display, disposed within or physically coupled to the housing, communicatively coupled to the processor; and one or more routines stored on the memory device and executable by the processor to cause the processor to communicate with one or more servers communicatively connected to a process controller ([0020], [0049]-[0050] see “controller 210”, “controllers 110”) controlling a physical process executing within the process plant, the controller communicatively coupled to a plurality of field devices in the process plant and operating to control the field devices to perform a physical function within the process plant ([0028]), the one or more stored routines comprising at least a routine for (1) identifying a process control device in physical proximity to the wearable mobile user interface device ([0070] “operator is now apparently located in close proximity to the module”, [0072], [0075]) by one or more sensing units ([0041], [0046], [0060]) by one or more sensing units of the wearable mobile user interface device detecting information within the process plant, the information being associated with the process control device ([0061]-[0062] “identify the control area, if any, in which a portable device 180 is currently located and provide to the portable device 180 the information related to the scope of operations allowed for the particular user in this area and/or may control the scope of operations (including access to data such as configuration data)”, [0069], [0071], [0087]-[0088]), and (2) causing a data stream ([0037] “operators may be able to directly communicate with … one of the field devices”, [0075] “provide real-time notifications to operators as they move through the facility”, [0096], [0190] “output may be streamed”, [0192] “content from any source may be streamed”, [0003] “sensors (e.g., temperature, pressure and flow rate sensors)”, [0088] “periodic measurement”, [0024] “signal from the electronic tag 182 may be transmitted either periodically”, [0045] “supplying objects with a module periodically transmitting identification information at a known frequency”) comprising data values ([0088] “events may be largely informational, such as a periodic measurement report from a temperature sensor, or warning events, such as borderline readings of a pressure sensor, or alarms, such as unexpected or abnormal conditions detected”) associated with the identified process control device to be transmitted by the one or more servers ([0043] “field devices may be operatively coupled to one of the many types of wireless transmitters”, [0048]-[0049], which is performed by the “access controller or server” [0011], [0023] “devices to communicate with various system elements, such as the server”) to the wearable mobile user interface device ([0075] “provide real-time notifications to operators as they move through the facility”, [0095] “associating events with locations as well as with users for real-time … analysis”) including receiving, from the one or more servers ([0032] “areas need not be static and may fluctuate according to situations, such as malfunctions, which may be detected by the access server 121”, [0061] “sends the collected measurements to … the server 121 … server 121 may, in tum, propagate the information further … and provide to the portable device 180”, [0088]), (3) executing a user interface application ([0038], [0051]) using the data values in the data stream to perform a function with respect to the process control device ([0062]) (see NOTE), (4) storing operational state information defining the operational state of the user interface application, and (5) sending the operational state information defining the operational state of the user interface application to the one or more servers or to another device, to enable a further user interface device using the operational state information to implement the user interface application on the further user interface device based on the operational state information. Although Peterson teaches – “operators carrying portable devices 180 may have access to one or more of the applications that are available at the workstation 120 or may run such applications and have access to the same data made available to the workstation 120” [0037], Peterson does not explicitly teach, however Collin or JUNG disclose (4) storing operational state information defining the operational state of the user interface application (Collin [0079], JUNG [0078], [0080], [0145], [0165]), and (5) sending the operational state information defining the operational state of the user interface application to the one or more servers or to another device, to enable a further user interface device using the operational state information to implement the user interface application on the further user interface device based on the operational state information (Collin [0082], JUNG [0165], [0172], [0178]). 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 teachings of Peterson to include operational state of the user application and enable a further user interface to implement the user interface application on the further user interface as disclosed by Collin or JUNG. Doing so allows for a transition between the first and second applications to be much smoother for the user as much of the context of the first application can be maintained in the second application and also saves the user a lot of time configuring the second editor in order to approximate the state in which the first editor was before the transition (Collin [0082]). Peterson does not explicitly teach, however JUNG disclose metadata defining a format of the data values in the data stream ([0019], [0032], [0153]). It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Peterson as modified to include metadata defining a format and one or more servers as disclosed by JUNG. Doing so would allow the user to effectively respond to the operation-state-changed device over the network (JUNG [0095]). NOTE if Peterson does not explicitly teach, however Osterhout discloses (3) executing a user interface application using the data values in the data stream to perform a function with respect to the process control device ([0353], [0502]-[0503], [0569], [0571], [0575]). 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 teachings of Peterson to execute a user interface application using the data values in the data stream to perform a function with respect to the process control device as disclosed by Osterhout. Doing so would allow for a desired information to be promptly accessed and applied with a minimum of effort, allowing the technician to more quickly perform the needed repair or maintenance and to return the equipment to service (Osterhout [0352]). Regarding claim 2, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the housing has the general form of a wrist watch and is configured to be removably affixed to the user in a manner of a wrist watch (Peterson [0005], [0051], Osterhout F15, 58, [0366]). Regarding claim 3, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the housing is integrated with a pair of glasses (Peterson [0005], [0051], Osterhout F1, 7, 23, [0366]). Regarding claim 4, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the processor is communicatively coupled to a network via an intermediary device (Peterson [0005], [0051], Osterhout [0256], [0361]). Regarding claim 5, Peterson as modified teaches the wearable mobile user interface device of claim 4, wherein the intermediary device is a tablet or a smart phone (Osterhout [0256], Peterson [0005], [0042] “regular portable computer or other handheld device may simply be carried around the facility with a cell phone connected” [0051]). Regarding claim 6, Peterson as modified teaches the wearable mobile user interface device of claim 1, further comprising a biometric sensor (Osterhout [0279], [0285]). Regarding claim 7, Peterson as modified teaches the wearable mobile user interface device of claim 6, wherein the biometric sensor is a heart rate sensor (Osterhout [0279], [0282], [0285]). Regarding claim 8, Peterson as modified teaches the wearable mobile user interface device of claim 6, wherein the biometric sensor is a pulse oximeter (Osterhout [0279], [0419]). Regarding claim 9, Peterson as modified teaches the wearable mobile user interface device of claim 6, wherein the biometric sensor is a fingerprint sensor (Osterhout [0277], [0286]-[0287]). Regarding claim 10, Peterson as modified teaches the wearable mobile user interface device of claim 1, further comprising a geolocation receiver (Osterhout [0298], [0355]). Regarding claim 11, Peterson as modified teaches the wearable mobile user interface device of claim 1, further comprising an RFID or NFC device (Peterson [0024], [0039], Osterhout [0275]). Regarding claim 12, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the one or more routines comprise a notification routine (Peterson [0075]-[0076], [0087]-[0088], Osterhout [0380], [0288]). Regarding claim 13, Peterson as modified teaches the wearable mobile user interface device of claim 12, wherein the notification function notifies the user of the wearable mobile user interface device of an emergency (Peterson [0053]-[0054], [0091], [0093]-[0095], [0051], Osterhout [0402]-[0403]). Regarding claim 14, Peterson as modified teaches the wearable mobile user interface device of claim 12, wherein the notification function notifies the user of the wearable mobile user interface device of a process control alarm (Peterson [0054]-[0055], [0062], [0072], [0095], F6, Osterhout [0402]-[0403]). Regarding claim 15, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the one or more routines further comprise a routine for performing a notification function, and the notification function prompts the user of the wearable mobile user interface device to perform an assigned work item in the process plant (Peterson [0062]), the assigned work item (1) being assigned to the user via a supervisory engine (see NOTE I) of the process plant (Peterson [0059] “operator using the portable device … has been mapped to one or more of the predefined areas of control within the process plant”, “control system may check such information as the operator's area of expertise, level of access or seniority, shift assignment” [0062], [0069]-[0070] “recording "punch in" and "punch out" times in those common situations where operators are expected to be within a certain area during their assigned shifts”, Osterhout [0386]), and (2) being tracked via the supervisory engine ([0020] “A registry, maintaining run time data related to system components and system users”, [0023] “for such purposes as supervising, configuring, troubleshooting, and otherwise maintaining the devices, units, control loops and other parts of the process plant”, [0055] “obtain or store events, alarms, comments and courses of action taken by operators”, [0069] “tracks operators' work hours or other activities”, [0087]-[0088]) until the user has completed the assigned work item (Peterson [0062], [0072] see “alarm acknowledgement”, [0096] see “clearing an alarm”) (see NOTE II). NOTE I Peterson teaches a registry for assigning work shifts, tracking work being performed and mapping operators to domains of control [0054], [0069]. Peterson further teaches “the process control system might have detected a low-severity alarm earlier and may decide to push it to the operator at this time because the operator is now apparently located in close proximity to the module” [0070], “control system may detect these cases automatically and expand the area of access for a particular user or for all users in the system to encompass additional, remote areas or even all areas associated with the system in order to allow these users to deal with the emergency situation” [0095], “automatically detect the operator's location within the plant” [0024]. Therefore, it is reasonable to conclude that process control system which detects an alarm and automatically assigns operator to address a problem is obviously analogous to the claimed supervisory engine. Also see - MPEP 2144.04 (III), the automation of a manual process. NOTE II Peterson does not explicitly teach (2) being tracked via the supervisory engine until the wearer has completed the assigned work item. Instead, Peterson teaches recording and tracking work being performed by the operator, which includes and “alarm acknowledgement”, “clearing an alarm.” However, given that an operator is assigned work based on the alarm, then it is reasonable to conclude that acknowledging and clearing the alarm indicates that a work order assigned based on the alarm is complete. Therefore, the claim limitations not explicitly recited in Peterson are implicit. Regarding claim 16, Peterson as modified teaches the wearable mobile user interface device of claim 1, further comprising a vibration motor, wherein the one or more routines further comprise a notification routine (Peterson [0075]-[0076], [0087]-[0088]), and wherein the notification routine causes the vibration motor to vibrate (Osterhout [0218], [0230], [0280], [0297], [0389]). Regarding claim 18, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the one or more routines stored on the memory device further comprise (Peterson [0076], Osterhout Figure 23, [0318], [0371]) a routine for facilitating guidance of the user to a particular location in a process control environment by receiving an indication of a work item (F10:803-804, 807, [0065], [0087]) associated with the particular location from a supervisory engine ([0023] “for such purposes as supervising, configuring, troubleshooting, and otherwise maintaining the devices, units, control loops and other parts of the process plant”, [0055] “obtain or store events, alarms, comments and courses of action taken by operators”, [0069] “tracks operators' work hours or other activities”, [0087]-[0088], [0059] “operator using the portable device … has been mapped to one or more of the predefined areas of control within the process plant”, “control system may check such information as the operator's area of expertise, level of access or seniority, shift assignment” [0062], [0069]-[0070] “operators may be later used in investigations of problems or in modeling emergency conditions”, “recording "punch in" and "punch out" times in those common situations where operators are expected to be within a certain area during their assigned shifts”)(see ***) and guiding the user to handle the work item at the particular location ([0071]-[0072], [0074]) by providing graphical or vibration-based directional indicators ([0076] “user may see a symbol or text corresponding to a device change colors as the user moves toward or away from the device”, [0078] “user may see the same static display representing the process plant as he or she is moving through various control areas of the process plant … device-specific color indicators may change colors as the user enters or leaves the corresponding areas of control”, F8, Osterhout [0439], [0459]) indicating at least one of (1) when the user is to make a turn while en route to the particular location (Osterhout Figure 23 (see Turn RIGHT in 0.2m), [0318], [0371]) or (2) what direction the user is to proceed while en route to the particular location ([0075] “real-time notifications to operators /-are provided-/ as they move through the facility”, [0038] “The calculated location [-of the devices-] may also be reported to the portable device 180”, [0076] “user may see a symbol or text corresponding to a device change colors as the user moves toward or away from the device”, F8, Osterhout Figure 23 (see Turn RIGHT in 0.2m), [0318], [0371]) (see NOTE I). NOTE I - Peterson teaches the user receives a text notification “as the user moves toward or away from the device”. Thus, Peterson obviously suggests (1) that navigational directions are given to a user while en route to the particular location (i.e. an indication is given with respect to user’s proximity to a device, which is analogous to what direction to proceed). Peterson further teaches providing real-time notifications to users as they move through the plant, changing colors as the user moves toward or away from the device and notifications like “You Have Entered Area LO103,” which obviously suggests (2 another optional limitation) what direction the user is to proceed while en route to the particular location, because the user can determine which direction to proceed based on the displayed notifications. *** Peterson teaches a registry for assigning work shifts, tracking work being performed and mapping operators to domains of control [0054], [0069]. Peterson further teaches “the process control system might have detected a low-severity alarm earlier and may decide to push it to the operator at this time because the operator is now apparently located in close proximity to the module” [0070], “control system may detect these cases automatically and expand the area of access for a particular user or for all users in the system to encompass additional, remote areas or even all areas associated with the system in order to allow these users to deal with the emergency situation” [0095], “automatically detect the operator's location within the plant” [0024]. Therefore, it is reasonable to conclude that process control system which detects an alarm and automatically assigns operator to address a problem is obviously analogous to the claimed supervisory engine. See specifically – [0020] “an access server 121 may be communicatively connected to the one or more process controllers 110,” “controllers 110 may be configured to implement a control strategy” [0022]; [0039] “The server 121 … contain … security levels …the server 121 may … deny or grant (full or partial) access to these control areas to the operator”. [0061] “access server 121 … identify the control area, if any, in which a portable device 180 is currently located and provide to the portable device 180 the information related to the scope of operations allowed for the particular user in this area and/or may control the scope of operations (including access to data such as configuration data) allowed for the particular user based on the control area in which the user is currently located” [0088] “server 121 … monitors the operation of the process control system 100 or 200 and receives, records, and routes event and alarm notifications. In particular, the routine 800 determines the proper recipients of notifications in the process control system.” Therefore, the server 121, which monitors the operation of the process control system and provides users with information related to allowed operations in this area and controls the scope of operations, is construed to be analogous to the claimed “supervisory engine.” Regarding claim 21, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the information detected by the wearable mobile computing device includes data from an RFID or NFC device (Peterson [0024], [0039], Osterhout [0275]). Regarding claim 46, Peterson as modified teaches the wearable mobile user interface device of claim 1, wherein the routine for causing the processor to communicate with the controller controlling a process executing within the process plant further comprises a routine for modifying an operation of a process control device by changing a process control parameter, or a routine for facilitating a commissioning of a process control device (Peterson [0057] “change the configuration if necessary”, [0059], [0062], [0069]-[0070], [0071], [0096] “adding or updating a setpoint or another operational value”). Claim(s) 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Peterson as modified and in further view of Rizzo, III et al. (US 2013/0127980) or NEWELL (US 2013/0145448) or Upton (US 20070188319) or STEWART (US 2014/0232530). Regarding claim 17, Peterson as modified does not explicitly teach, however Rizzo, III discloses the wearable mobile user interface device of claim 16, wherein the notification routine causes the vibration motor to vibrate in a pattern corresponding to a particular notification type selected from a plurality of notification types having respective corresponding vibration patterns ([0107], [0110]). NEWELL analogously discloses claim 17 in [0063]-[0064]. Upton analogously discloses claim 17 in [0065]-[0066]. STEWART analogously discloses claim 17 in [0053]. 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 teachings of Peterson as modified to include vibrate in a pattern corresponding to a particular notification type as disclosed by Rizzo, NEWELL, STEWART or Upton. Doing so would alert user in various ways to help recognize different events. Claim(s) 15, is/are alternatively rejected under 35 U.S.C. 103 as being unpatentable over Peterson as modified and in further view of Moisa et al. (US 2004/0030992) or Barney et al. (US 20120215580). However, if Peterson as modified does not explicitly teach, Moisa discloses claim 15 in [0081], [0100], [0154]. Barney discloses the same in [0046], [0050], [0064] It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Peterson as modified to include assigning work and tracking completion of work by a supervisory engine as disclosed by Moisa or Barney. Doing so would facilitate the management of quality assurance (Moisa [0011]). Claim(s) 18, is/are alternatively rejected under 35 U.S.C. 103 as being unpatentable over Peterson as modified and in further view of Dewey et al. (US 2010/0290359). However, if Peterson as modified does not explicitly teach claim 18, Dewey discloses claim 18 in paragraph [0030]-[0032]. It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Peterson as modified to include a routine one as disclosed by Dewey. Doing so would help a technician or engineer find the physical location of a wireless field device in the field (Dewey [0031]). ◊ Claim(s) 1 is alternatively rejected under 35 U.S.C. 103 as being unpatentable over Peterson et al. (US 20090065578) in view of Usey et al. (US 20080208820) and in further view of Uola et al. (US 20130275994). Regarding claim 1, Peterson teaches a wearable mobile user interface device for controlling a process plant as disclose above. Peterson does not explicitly teach, however Usey discloses –receiving, from the one or more servers, metadata defining a format of the data values ([0069] “Streams are generally defined by a specified protocol and byte/record format based upon the particular source”), the format including an indication of the data format of the one or more parameters as sent within the real-time data stream ([0073] “Metadata generally refers to structured, encoded data that describe characteristics of information-bearing entities to aid in the identification, discovery, assessment, and management of the described entities”, “metadata attributes for a specific stream or file, these attributes may include the headline or title of the file or stream, the subject, the category, the author, the publish date, or any number of other attributes. Essentially, metadata includes any name-value pair”, [0070] “specific to the layout of the byte buffer (i.e. the file or stream format”; “stream is formatted and is subsequently processed by the text formatter component”, “requires knowledge of this format to extract the text from”, [0071]-[0072] “Once the stream or file has been formatted … and associated with the unique content identifier generated by the … stream reader”, [0076], F4B), It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Peterson to include a real-time data streaming and indicating a format of the one or more parameters in the real-time data stream as disclosed by Usey. Doing so allows for fast and efficient retrieval of data without slowing down the operational systems (Usey [0059]). Peterson does not explicitly teach, however Uola discloses (4) storing operational state ([0050]) information defining the operational state of the user interface application ([0018], [0026], [0039]), and (5) sending the operational state information defining the operational state of the user interface application to the one or more servers or to another device, to enable a further user interface device using the operational state information to implement the user interface application on the further user interface device based on the operational state information ([0005], [0031], [0040], [0046]). 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 teachings of Peterson to include operational state of the user application and enable a further user interface to implement the user interface application on the further user interface as disclosed by Uola. Doing so allow users to continue work on the same task utilizing another communication device without explicit effort required of the user (Uola [0004]). Response to Arguments Applicant's arguments, filed 03/03/2026, in regard to the presently amended claims have been fully considered and are addressed in the updated rejections to the claims above. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 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 POLINA G PEACH whose telephone number is (571)270-7646. The examiner can normally be reached Monday-Friday, 9:30 - 5:30. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aleksandr Kerzhner can be reached at 571-270-1760. 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. /POLINA G PEACH/ Primary Examiner, Art Unit 2165 March 18, 2026
Read full office action

Prosecution Timeline

Sep 02, 2015
Application Filed
Sep 02, 2015
Response after Non-Final Action
Dec 03, 2015
Response after Non-Final Action
Dec 21, 2015
Response after Non-Final Action
Mar 14, 2018
Non-Final Rejection — §103
Jun 13, 2018
Response Filed
Aug 08, 2018
Final Rejection — §103
Nov 13, 2018
Response after Non-Final Action
Jan 17, 2019
Applicant Interview (Telephonic)
Jan 17, 2019
Applicant Interview
Jan 31, 2019
Request for Continued Examination
Feb 12, 2019
Response after Non-Final Action
Feb 22, 2019
Non-Final Rejection — §103
May 09, 2019
Response Filed
Jul 18, 2019
Final Rejection — §103
Oct 28, 2019
Response after Non-Final Action
Nov 13, 2019
Non-Final Rejection — §103
Feb 12, 2020
Response Filed
Apr 25, 2020
Non-Final Rejection — §103
Aug 31, 2020
Response Filed
Nov 04, 2020
Final Rejection — §103
Jul 19, 2021
Non-Final Rejection — §103
Oct 25, 2021
Response Filed
Jan 04, 2022
Final Rejection — §103
Apr 14, 2022
Response after Non-Final Action
Jun 09, 2022
Request for Continued Examination
Jun 12, 2022
Response after Non-Final Action
Jun 14, 2022
Non-Final Rejection — §103
Dec 12, 2022
Response Filed
Feb 02, 2023
Examiner Interview (Telephonic)
Feb 13, 2023
Non-Final Rejection — §103
Jun 20, 2023
Response Filed
Jul 06, 2023
Final Rejection — §103
Dec 12, 2023
Request for Continued Examination
Dec 18, 2023
Response after Non-Final Action
Jan 29, 2024
Non-Final Rejection — §103
Jul 01, 2024
Response Filed
Jul 12, 2024
Final Rejection — §103
Nov 18, 2024
Request for Continued Examination
Nov 20, 2024
Response after Non-Final Action
Jan 24, 2025
Non-Final Rejection — §103
Apr 29, 2025
Response Filed
May 18, 2025
Final Rejection — §103
Aug 20, 2025
Response after Non-Final Action
Aug 27, 2025
Request for Continued Examination
Sep 05, 2025
Response after Non-Final Action
Nov 30, 2025
Non-Final Rejection — §103
Mar 03, 2026
Response Filed
Mar 18, 2026
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596921
Stochastic Bitstream Generation with In-Situ Function Mapping
2y 5m to grant Granted Apr 07, 2026
Patent 12585998
DETERMINING QUALITY OF MACHINE LEARNING MODEL OUTPUT
2y 5m to grant Granted Mar 24, 2026
Patent 12585632
METHOD, DEVICE, AND MEDIUM FOR MANAGING ACTIVITY DATA WITHIN AN APPLICATION
2y 5m to grant Granted Mar 24, 2026
Patent 12579191
IDENTIFYING SEARCH RESULTS IN A HISTORY REPOSITORY
2y 5m to grant Granted Mar 17, 2026
Patent 12572575
USING LARGE LANGUAGE MODELS TO GENERATE SEARCH QUERY ANSWERS
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

19-20
Expected OA Rounds
50%
Grant Probability
73%
With Interview (+23.2%)
3y 7m
Median Time to Grant
High
PTA Risk
Based on 461 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month