DETAILED ACTION
This Final Office Action is in response to Applicant's arguments filed on September 11, 2025. Applicant has amended claims 16, 20, 25, 30-31 and added claims 36-39. Currently, claims 16-18, 20, 22-28, 30-31, 36-39 are pending. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendments
The 35 U.S.C. 101 rejections of claims 16-18, 20, 22-28, 30-31 are maintained in light of applicant’s amendments to claims 16, 20, 25, 30-31.
The 35 U.S.C. 103 rejections of claims 16-18, 20, 22-28, 30-31 are maintained in light of applicant’s amendments to claims 16, 20, 25, 30-31.
Response to Arguments
Applicant’s remarks submitted on 9/11/25 have been considered but are not persuasive. Applicant argues on p. 7 of the remarks that the 101 rejection is improper. Examiner disagrees. Applicant argues on p. 8 of the remarks that the amended language show an improvement to a specific problem, resolving inefficiencies in manufacturing processes. Examiner disagrees and notes the improvement is to the abstract idea of "selecting a set of stored role card objects determined to correspond to a received plan wherein each role card object of the selected set of stored role card objects defines a corresponding standard duration and generating a workflow dataset that includes the selected set of stored role card objects and providing the generated workflow dataset having the selected set of stored role card objects presented therein and recording a corresponding actual duration for each role card object of the presented role card objects based on a corresponding set of inputs received for the role card object and calculating a corresponding variation value for each role card object included in the generated workflow dataset based on the defined corresponding standard duration and the recorded corresponding actual duration and generating and providing metrics data that is generated based at least in part on the variation values calculated for at least a portion of the role card objects included in the generated workflow dataset and corresponding plant data and generating a notification when the calculated variation value of a completed role card object exceeds a defined threshold variance value and collecting an input associated with the calculated variation value of a completed role card object exceeds a defined threshold variance value and generating a second data set using the collected input to resolve the issue of the calculated variation value of a completed role card object exceeds a defined threshold value.” Applicant on p. 11 notes that the metric and operational data such as sensors. Examiner notes that these characteristics are considered additional elements but the abstract idea is still reasonably described as organized human activity because the claims show generating workflow dataset which is based on role card objects, which are a type of business relations, and that data is analyzed based on duration data where the generated metrics data is a type of organization of such business relations data where the claims and specification make it clear the improvement is to frameworks that have been adopted by organizations seeking to eliminate waste, increase efficiency, improve quality, and/or reduce variation in operational activities, including production, maintenance, management, development, and the like which can be considered business relations data. Applicant argues on p. 13 of the remarks that the claims include plant data received from various sensors. Examiner notes that using sensors to collect data is an additional element that is a useful tool for implementing the abstract idea and are also considered routine, conventional and well-understood. Therefore, the 101 rejections are maintained. Applicant argues on p. 14 of the remarks that the 103 rejections are maintained. Examiner disagrees. Examiner notes that Baier teaches the amended language at para [0082]-[0084] by showing a confidence value compared to a threshold value which is a variance exceeding a threshold and where such a result is used for automated actions based on the inference where the actions are associated with being correct and providing a benefit based on cost which can reasonably be considered resolving an issue. Therefore, the 103 rejections are maintained.
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 16-18, 20, 22-28, 30-31 are clearly drawn to at least one of the four categories of patent eligible subject matter recited in 35 U.S.C. 101 (method, non-transitory computer readable medium, and system). Claims 16-18, 20, 22-28, 30-31 , 36-39 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 16 and 25 recites the abstract idea of selecting a set of stored role card objects determined to correspond to a received plan wherein each role card object of the selected set of stored role card objects defines a corresponding standard duration and generating a workflow dataset that includes the selected set of stored role card objects and providing the generated workflow dataset having the selected set of stored role card objects presented therein and recording a corresponding actual duration for each role card object of the presented role card objects based on a corresponding set of inputs received for the role card object and calculating a corresponding variation value for each role card object included in the generated workflow dataset based on the defined corresponding standard duration and the recorded corresponding actual duration and generating and providing metrics data that is generated based at least in part on the variation values calculated for at least a portion of the role card objects included in the generated workflow dataset and corresponding plant data and generating a notification when the calculated variation value of a completed role card object exceeds a defined threshold variance value and collecting an input associated with the calculated variation value of a completed role card object exceeds a defined threshold variance value and generating a second data set using the collected input to resolve the issue of the calculated variation value of a completed role card object exceeds a defined threshold value. The claims are directed to a type of analysis of workflow data based on durations. Under prong 1 of Step 2A, these claims are considered abstract because the claims are certain methods of organizing human activity such including business relations. Applicant’s claims are organized human activity because the claims show generating workflow dataset which is based on role card objects, which are a type of business relations, and that data is analyzed based on duration data where the generated metrics data is a type of organization of such business relations data. Under prong 2 of Step 2A, the judicial exception is not integrated into a practical application because the claims (the judicial exception and any additional elements individually or in combination such as a digital operations system, computing device, electronic plan based on metadata and displaying by the computing device and a graphical user interface, modifiable using a GUI and plant data collected through plant sensors) are not an improvement to a computer or a technology, the claims do not apply the judicial exception with a particular machine, the claims do not effect a transformation or reduction of a particular article to a different state or thing nor do the claims apply the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment such that the claims as a whole is more than a drafting effort designed to monopolize the exception. These limitations at best are merely implementing an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements individually or in combination such as a digital operations system, computing device, electronic plan based on metadata and displaying by the computing device and a graphical user interface, modifiable using a GUI and plant data collected through plant sensors (as evidenced by p. 6-7, 13-14, 52-54 of applicant’s own specification) are well understood, routine and conventional in the field. Dependent claims 17-18, 20, 22-24, 26-28, 30-31, 36-39 also do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements either individually or in combination are merely an extension of the abstract idea itself by further showing wherein the selected set of stored role card objects is arranged in the generated workflow dataset based on the received electronic plan and modifying, by the computing device, the generated workflow dataset based on an additional role card object generated based on another set of received inputs and providing for display, by the computing device, the modified workflow dataset having the selected set of stored role card objects and the generated additional role card object presented therein and wherein the metrics data is generated based further in part on the determination that the calculated variance value corresponding to each role card object of at least the portion of the role card objects included in the generated workflow dataset exceeds the defined threshold variance value and determining, by the computing device, a progress of the generated workflow dataset based on a scheduled start time associated with the generated workflow dataset and one or more recorded actual durations associated with the role card objects included therein and wherein the progress is determined based further on the standard durations defined by the role card objects included in the generated workflow dataset and wherein the metrics data is generated based further in part on a selected metric criteria and wherein the GUI is generated based further in part on the stored dimension value and a workflow analysis means for generating metrics data associated with at least the generated workflow dataset, the metrics data being generated based at least in part on the calculated variation value and the determination that the calculated variation value exceeds the defined threshold variation value and a metric defining means for generating a selectable metric criteria associated with the generated analytics interface based on one or more inputs received via a metric interface, wherein the generated selectable metric criteria is employable to filter at least the particular role card object and a workflow management means for storing an association between the particular role card object and a selected user account and wherein the second dataset is an action dataset for resolving a task of a role card object included in a generated workflow dataset being determined to have a calculated variance exceeding a threshold variance and wherein the second dataset is an initiative dataset for resolving a task of a role card object included in a plurality of generated workflow datasets being determined to have a calculated variance exceeding a threshold variance.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned 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.
Claim 16-18, 20, 22-28, 30-31, 36-39 are rejected under 35 U.S.C. 103 as being unpatentable over Baier et al. (US 2009/0088875 A1) (hereinafter Baier) in view of Webb (US 2015/0142491 A1) in view of Martin (US 20050234815 A1).
Claims 16 and 25:
Baier, as shown, discloses the following limitations of claims 16 and 25:
A computer-implemented method for operating a digital operations system (and corresponding non-transitory computer readable medium – see para [0186]-[0188], showing equivalent computing functionality) comprising: selecting, by a computing device, a set of stored role card objects determined to correspond to a received electronic plan based on metadata included in each role card of the set of stored role card objects, wherein each role card object of the selected set of stored role card objects defines a corresponding standard duration (see para [0086], "The methodology allows for a user, upon authentication to the machine, to have a rich, customized visualization generated that facilitates achieving his/her goals. For example, different visualizations would be presented as a function of task at hand, operator role, operator preferences, context of the operation, state of the machine, access rights, strengths or weaknesses of the operator, operator cognitive load, extrinsic factors, complexity of task, duration of task, upcoming tasks, past tasks, etc" and see para [0129], "Utilizing the user identification, information retrieval component 3202 can determine and/or track the context of each user 3204. This information can be retrieved from one or more database or other storage/retrieval means that can include a user/role context data component 3210 and/or a user/role historical data component 3212. The context of each user can be, for example, the role, position, responsibilities, authorized programs, areas or regions of interest, activities, etc. as it relates to the particular user.") and is modifiable using a graphical user interface (GUI) (see para [0059], "It is noted that the interfaces described herein can include a Graphical User Interface (GUI) to interact with the various components for providing industrial control information to users. This can include substantially any type of application that sends, retrieves, processes, and/or manipulates factory input data, receives, displays, formats, and/or communicates output data, and/or facilitates operation of the enterprise. For example, such interfaces can also be associated with an engine, editor tool or web browser although other type applications can be utilized. The GUI can include a display having one or more display objects (not shown) including such aspects as configurable icons, buttons, sliders, input boxes, selection options, menus, tabs and so forth having multiple configurable dimensions, shapes, colors, text, data and sounds to facilitate operations with the interfaces." and see para [0065], " In addition to object or information selection, input can correspond to entry or modification of data. Such input can affect the display and/or automation devices. For instance, a user could alter the display format, color or the like. Additionally or alternatively, a user could modify automation device parameters." and see para [0142], "In addition to object or information selection, input can correspond to entry or modification of data. Such input can affect the display and/or automation devices. For instance, a user could alter the display format, color or the like. Additionally or alternatively, a user could modify automation device parameters.");
generating, by the computing device, a workflow dataset that includes the selected set of stored role card objects (see para [0088], "FIG. 8 illustrates an embodiment of a system 800 that generates customized visualizations as a function of mash-ups of display objects (e.g., web pages, windows, portals, video, images, text boxes, pop-ups, alerts, etc.). Through use of mash-ups (e.g., a collection of information from different sources), a rich customized visualization can be generated that allows a user to leverage information, from a variety of sources, through a common integrated interface. The system 800 includes a mash-up component 802 that provides for a user to associate a plurality of different sources and combine output from such sources into a common interface. For example, a user can designate a variety of sources to use (e.g., alarm services, network health, workflow applications, real-time video feeds, prognostic data, diagnostic data, real-time machine operation data, remote web services, analytical tools, search engines, network or device health monitors, instructional sources, communication sources . .. ) in connection with generating a highly glanceable interface that facilitates the user receiving substantially all desired information through a common interface that is designed to optimize consumption of the information in accordance with the user's needs, context, preferences, capabilities, etc.");
providing for display, by the computing device, the generated workflow dataset having the selected set of stored role card objects presented therein (see para [0086], "The methodology allows for a user, upon authentication to the machine, to have a rich, customized visualization generated that facilitates achieving his/her goals. For example, different visualizations would be presented as a function of task at hand, operator role, operator preferences, context of the operation, state of the machine, access rights, strengths or weaknesses of the operator, operator cognitive load, extrinsic factors, complexity of task, duration of task, upcoming tasks, past tasks, etc.");
collecting an input associated with the calculated variation value of a completed role card object exceeds a defined threshold variance value (see para [0082], "At 502 context of an information session is inferred or determined. The inference or determination can be a based on content of information, context of a sending entity or recipient entity, extrinsic information, etc. Learning context of the session substantially facilitates generating a visualization that is meaningful to the goals of the entity or session. At 504 entity intent is inferred or determined. A variety of information sources or types can be employed in connection with this act. For example, roles of the entity, access rights, prior interactions, what the entity is currently doing, entity preferences, historical data, entity declaration of intent, . . . can be employed in connection with inferring or determining intent of the entity. At 506 data associated with acts 502 and 504 are analyzed. A variety of analytical techniques (e.g., probabilistic, statistical, rules-based, utility-based analysis, look-up table . . . ) can be employed in connection with analyzing the data in connection with generating a relevant and meaningful visualization in accordance with embodiments described herein. For example, confidence levels can be calculated in connection with inferred context or intent, and if the confidence level meets a particular threshold (e.g., >80% confidence) automated action can be taken based on the inference. In addition or alternatively, for example, a utility-based analysis can be performed that factors the cost of taking an incorrect action in view of the benefits associated with the action being correct. If the benefits exceed the costs, an action may be taken. At 508, a determination is made as to whether or not the data is in an acceptable format. If not the data is reformatted at 510. If yes, the information is presented to the user as a rich, customized visualization that is a function of context, state, or preferences."); and
generating a second dataset using the collected input to resolve the issue of the calculated variation value of a completed role card object exceeds a defined threshold variance value (see para [0082]-[0084], especially " FIG. 6 illustrates one particular embodiment in connection with a methodology 600 for generating visualizations associated with alarms. At 602, context associated with a communication (e.g., message, session, alarm, event) is inferred or determined. For example, content associated with the communication can be analyzed (e.g., via key words, MLS techniques, classifiers, inflection of voice, priority settings, to facilitate inferring or determining context associated with a communication. At 604, user context or state if inferred or determined. At 606, device capabilities are inferred or determined. At 608, alarm data is reformatted so that it can be delivered in accordance with nature of the alarm, user context or state, user role, cognitive capability, and device capability. Once the data is re-formatted to optimize delivery and consumption thereof, the formatted data is delivered to the rendering device. Thus, alarm data is analyzed and re-formatted so as to facilitate optimizing delivery of the alarm information to a user and particular device being employed. For example, if the user is at a remote location with a lot of ambient noise, and only a cell phone is available, the alarm would be delivered as a text message rather than relying on audible broadcast (given the excessive ambient noise which could hamper a user fully interpreting an audio delivery of the alarm information). Moreover, given limited screen real estate associated with the cell phone, the alarm information may be truncated so as to focus on most relevant language (e.g., alarm, location, when, where, status). On the other hand, if the user was in an office in front of a multi-screen computer system with a broadband connection, the alarm information may be provided as text, audio, images, video, chat sessions, etc. since there are more resources to utilize to convey the information as well as provide for the user to react to the alarm information.")
Baier, however, does not explicitly disclose recording, by the computing device, a corresponding actual duration for each role card object of the presented role card objects based on a corresponding set of inputs received for the role card object. In analogous art, Webb discloses the following limitations:
recording, by the computing device, a corresponding actual duration for each role card object of the presented role card objects based on a corresponding set of inputs received for the role card object (see para [0060], "As activities are received from the field they are checked for the correct sequencing and various calculations are performed to enrich the data, such as calculating the duration of each activity (operation 1). Activities may be passed through to a component or module (within the Activity Processing Engine 104) which (in operation 2) generates the appropriate service delivery milestones (e.g. arrived, broken appointment, closed fixed, etc.) and calculates service effectiveness KPIs (Key Performance Indicators). The service delivery milestones may, for example, be derived based on data entered into the component running on the mobile device 102 (e.g. and communicated to the Activity Processing Engine 104 as Params in the examples above) and/or by options taken within the activity-based workflow. For example, the possible exits from a transition activity (the activity which starts when the worker arrives at the correct location) may be `person not at home` or `started assessment of appliance`. Selection of `person not at home` may be interpreted, when generating the service delivery milestones, as closing the task.");
calculating, by the computing device, a corresponding variation value for each role card object included in the generated workflow dataset based on the defined corresponding standard duration and the recorded corresponding actual duration (see para [0061], "Outputs from operations 1 and 2 are fed into a behavioral analysis module (within the Activity Processing Engine 104) which looks for `interesting things` which are judged by the employer to be of value in their operation (operation 3). These `interesting things` which are pre-defined within the system may be referred to as `anomalous events` and examples of these include (but are not limited to): gaps in location and/or time (e.g. where a worker started a shift and then did not leave for their first task for 30 minutes), variations from plan, variance in reported vs. actual timing; oddities in relationships between activities, activities and tasks or activities and parameters associated with the activity e.g. activity not taking place at the right location."); and
generating and providing for display, by the computing device, metrics data that is generated based at least in part on the variation values calculated for at least a portion of the role card objects included in the generated workflow dataset (see para [0046], "he system 100 further comprises an Activity Processing Engine 104 which runs remotely from the mobile device 102 and, although only a single mobile device 102 is shown in FIG. 1, the Activity Processing Engine 104 communicates with and receives data from a plurality of mobile devices 102. In an example, the Activity Processing Engine 104 may receive data from tens, hundreds or even thousands of mobile devices 102, with each mobile device 102 being associated with a different field-based worker. As is described in more detail below, the Activity Processing Engine 104 (which may comprise computer-executable instructions running on a server) receives and stores the data received in a data store (or data warehouse) 106 which may be co-located with or remote from the Activity Processing Engine 104. The Activity Processing Engine 104 also analyses and manipulates the data received (e.g. to compute the traditional task-centered milestones) and generates a GUI 108 which displays performance management information for the field-based workers. This GUI 108 may be displayed on a computing-device which is co-located with the Activity Processing Engine 104 or the GUI 108 may be displayed on a remote computing device (e.g. where the Activity Processing Engine 104 does not run in the central office or where the field-based worker's manager is not based in the central office).")
generating a notification when the calculated variation of a completed role card object exceeds a defined threshold variance value (see para [0111], "Parameters which are used by the Activity Processing Engine 1100, such as rule sets and thresholds, are stored in a configuration module 1104. This enables the parameters to be varied and in various examples, different parameters (e.g. rule sets and thresholds) may be stored for different types of field-worker. These parameters may, for example, include the weights used in generating KPAs and the overall shift score, activity duration thresholds (i.e. the expected time or range of time for an activity), the expected time between certain milestones (e.g. first travel, last work, etc.), the paid time for a worker (e.g. their contracted shift length). The configuration module 1104 feeds the parameters into one or more calculators 1106 and a normalization module 1108." and see para [0115], "In various examples, the Activity Processing Engine 1100 may further comprise an exception and alert service 1128 which provides notifications (e.g. to a manager of a field-worker) when particular exceptions occur. These notifications may be configured dependent upon an organization's requirements and provide real-time notifications of problems which may be useful if the perspective views described above are not constantly monitored." and see para [0087], [0093])
Webb further discloses the limitation of claim 25:
provide for display a graphical user interface that is generated based on at least a portion of the variation values calculated for the role card objects included in the generated workflow dataset (see para [0061]-[0062], "Outputs from operations 1 and 2 are fed into a behavioral analysis module (within the Activity Processing Engine 104) which looks for `interesting things` which are judged by the employer to be of value in their operation (operation 3). These `interesting things` which are pre-defined within the system may be referred to as `anomalous events` and examples of these include (but are not limited to): gaps in location and/or time (e.g. where a worker started a shift and then did not leave for their first task for 30 minutes), variations from plan, variance in reported vs. actual timing; oddities in relationships between activities, activities and tasks or activities and parameters associated with the activity e.g. activity not taking place at the right location. All the information (including the anomalous events generated in operation 3) is fed through to a normalization and scoring module which allows the data to be aggregated up to a single score for each worker's shift (operation 4) and which may be presented in the GUI 108, e.g. form of a field-worker scorecard. As is described in more detail below, although the normalization and scoring module may generate (in operation 4) a single score for each field-worker's shift, in some examples a single score may not be generated and instead a plurality of scores may be generated (without a single aggregate score). Where a single score is generated, this may be presented alongside more detailed information in the GUI 108.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Webb with Baier because including the actual duration enables more effective analysis of real-time performance data (see Webb, para [0001]-[0002], [0061]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the method of managing task-driven field based workers as taught by Webb in the visualization system that generates a visualization of manufacturing operations of Baier, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Bair and Webb, however, do not specifically disclose generating and providing for display, by the computing device, metrics data that is generated based at least in part on the variation values calculated for at least a portion of the role card objects included in the corresponding plant data collected through plant sensors. In analogous art, Martin discloses the following limitations:
generating and providing for display, by the computing device, metrics data that is generated based at least in part on the variation values calculated for at least a portion of the role card objects included in the…corresponding plant data collected through plant sensors (see para [0043], "The methods and systems described herein utilize the availability of real-time economic performance measures of assets such as components in a process plant, and economic data generated thereby. Such real-time performance measures are described in, e.g., U.S. Pat. No. 5,134,574, which is incorporated by reference herein in its entirety. These real-time economic measures are directly calculated from operational performance data that are collected in real-time from sensors located, for example, at the plant floor in the plant automation systems of an industrial plant. This sensor-based information has been the domain of plant engineering, but provides a wealth of knowledge on what is going on in an industrial plant in real-time and to the process unit level and below, if necessary. To compute the economic value of the assets, certain economic information related to the collected operational data are needed. This economic information may come from a variety of sources, such as but not limited to accounting models that are constructed within the process control system. This makes the economic information in the plant available in real-time and to the plant equipment level. The economic value of an operations-related activity within a plant is thus discernable by calculating the value using the collected operational data and the economic information taken from the variety of sources." and see para [0048], "Thus, to make optimal use of the real-time display of economic performance data, the data should be presented in a prioritized format, such that the current primary economic goal is displayed first, followed by the secondary goal, the tertiary goal, and so forth. Prioritization of the displayed economic performance data may be accomplished by contextualizing the finance data to the manufacturing strategy. This contextualization may be done by prioritizing the financial models for each unit of the plant, such as a process unit, according to the manufacturing strategy of the plant. To accomplish this, the manufacturing strategy, which is commonly developed for the plant as a whole, may be decomposed to the process area and process unit levels. This is accomplished through a process called a Vollmann Decomposition. This process identifies the metrics for each unit in prioritized order. These metrics are then displayed according to priority to the operators and maintenance personnel responsible for the appropriate plant sections.")
It would have been obvious to one or ordinary skill in the art at the time of the invention to combine the teachings of Martin with Baier and Webb because generating metrics data from plant data provides a commercial real world use of optimize such plants (see Martin, para [0005]-[0010]).
Moreover, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the system for optimization of economic value from asset sets as taught by Martin in the Baier and Webb combination, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 17 and 26:
Further, Baier discloses the following limitations:
wherein the selected set of stored role card objects is arranged in the generated workflow dataset based on the received electronic plan (see para [0094], "The optimization component 1302 facilitates arrangement of items or objects within the mash-up to optimize the mash-up in connection with desired goals or uses. For example, if certain display objects are utilizing a significant amount of bandwidth and slowing down overall system resources, the optimization component can modify frequency of refresh, or filter non-relevant data, resize display objects, turn-off display objects, etc. Moreover, the optimization component can dynamically reposition, re-size, re-orient, display objects as a function of determined or inferred user preferences, needs, priorities, or goals, for example. AI based techniques can be employed to explicitly or implicitly train the optimization component to automated actions in accordance with particular events, states, conditions, extrinsic information, on-going actions, etc.")
Claims 18 and 27:
Further, Baier discloses the following limitations:
modifying, by the computing device, the generated workflow dataset based on an additional role card object generated based on another set of received inputs (see para [0141]-[0142], "The interface component 4202 receives input concerning displayed objects and information. Interaction component 4202 can receive input from a user, where user input can correspond to object identification, selection and/or interaction therewith. Various identification mechanisms can be employed. For example, user input can be based on positioning and/or clicking of a mouse, stylus, or trackball, and/or depression of keys on a keyboard or keypad with respect to displayed information. Furthermore, the display device may be by a touch screen device such that identification can be made based on touching a graphical object. Other input devices are also contemplated including but not limited to gesture detection mechanisms (e.g., pointing, gazing . . . ) and voice recognition. In addition to object or information selection, input can correspond to entry or modification of data. Such input can affect the display and/or automation devices. For instance, a user could alter the display format, color or the like. Additionally or alternatively, a user could modify automation device parameters. By way of example and not limitation, a conveyor motor speed could be increased, decreased or halted. It should be noted that input need not come solely from a user, it can also be provided by automation devices. For example, warnings, alarms, and maintenance schedule information, among other things, can be provided with respect to displayed devices."); and
providing for display, by the computing device, the modified workflow dataset having the selected set of stored role card objects and the generated additional role card object presented therein (see para [0144], "Context component 4204 can detect, infer or determine context information regarding an entity or application. Such information can include but is not limited to an entity's identity, role, location (logical or physical), current activity, similar or previous interactions with automation devices, context data pertaining to automation devices including control systems, devices and associated equipment. Device context data can include but is not limited to logical/physical locations and operating status (e.g., on/off, healthy/faulty … ). The context component 4204 can provide the determined, inferred, detected or otherwise acquired context data to visualization component 4206, which can employ such data in connection with deciding on which base presentations and or items to display as well as respective format and position.").
Claims 20, 22-24, 28, 30-31:
Baier does not specifically disclose providing for display, by the computing device, an input field associated with a particular role card object of the presented role card objects based on determining that the corresponding calculated variance value exceeds a defined threshold variance value. In analogous art, Webb discloses the following limitations:
wherein the metrics data is generated based further in part on the determination that the calculated variance value corresponding to each role card object of at least the portion of the role card objects included in the generated workflow dataset exceeds the defined threshold variance value (see para [0111]-[0112], where the metrics can be calculated based on the parameters which includes thresholds and see para [0093])
determining, by the computing device, a progress of the generated workflow dataset based on a scheduled start time associated with the generated workflow dataset and one or more recorded actual durations associated with the role card objects included therein (see para [0124], "A plan perspective which provides a real-time display of progress against plan in terms of cumulative tasks completed and a comparison of the duration of work activities associated with each task with the aim of feeding back information in order to refine future planning cycles, whether manual or automated. As the system stores a record of the expected time for each activity (or activity type), it can display in single screen data on the number of tasks which are within the expected time and the number of tasks are currently over-running. As the data is provided in real-time, a manager can monitor this screen and provide real-time assistance to field-based workers who are engaged in a task which is over-running.")
wherein the progress is determined based further on the standard durations defined by the role card objects included in the generated workflow dataset (see para [0090] and Figs 8, 21, where an hour can be considered to show the standard duration of time)
wherein the metrics data is generated based further in part on a selected metric criteria (see para [0086], "Ultimately this KPI information is an enabler, it allows a business to aggregate and compare performance across different dimensions--both the organizational structure and time in the first instance--to better understand a business. It is only by reviewing these performance perspectives in combination, that a business can identify effective improvement strategies. Established from a configurable mix of underlying metrics, and with the ability to apply configurable weightings to the contribution of these metrics, the KPIs themselves are calculated/presented in a `normalized scale` (0-100), to allow simplified evaluation by the User. The configuration allows the KPIs to better reflect the specific strategies and policies of the individual Customer operation, and to enable a meaningful single `day score` (as shown in section 8 of the score card) to be calculated/presented. By simplifying a complex combination of metrics, across multiple different performance perspectives, the provision of a single `day score` represents an opportunity to enable much improved communication and comparison of performance throughout the operation (and most importantly to the Field Workers themselves). Once normalized, this single score may be used in many different ways (e.g. to generate league tables, influence scheduling rules, etc.).")
wherein the additional role card object is not selected based on the received electronic plan (see para [0126], "This moderation assists in highlighting exceptions to viewers of the GUI and filters out the normal activities from those activities which might otherwise be seen as anomalies. The data that is displayed within a single perspective screen may be for all field-based workers or the GUI may provide the ability to select a (proper) subset of the organization and then the perspectives relate only to the selected subset. A user may also be able to filter the data which is shown in a perspective by other criteria (e.g. field-based worker, client, SLA, etc.).")
wherein the GUI is generated based further in part on the stored dimension value (see para [0113], "The data which is displayed within the GUI (or dashboard) 1118 is accessed from the database 1110 using data queries performed by a data query service 1120. Although FIG. 11 shows that the normalization process is performed on the fly by a normalization module 1108 which is separate from the aggregation service 1114 and acts on data received using data queries, in other examples, the normalization module 1108 may form part of the aggregation service 1114 with the normalized values being stored in the database 1110 and then extracted by the data query service 1120 when required for inclusion within the GUI 1118.")
It would have been obvious to one of ordinary skill in the art at the time of the invention to include the method of managing task-driven field based workers as taught by Webb in the visualization system that generates a visualization of manufacturing operations of Baier, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claims 36-39:
Further, Baier discloses the following limitations:
wherein the second dataset is an action dataset for resolving a task of a role card object included in a generated workflow dataset being determined to have a calculated variance exceeding a threshold variance (see para [0082]-[0084], where the alarm data is the action data set that is reformatted until acceptable for optimization based on inferences based on threshold which shows behaving as an action dataset and an initiative dataset given broadest reasonable interpretation);
wherein the second dataset is an initiative dataset for resolving a task of a role card object included in a plurality of generated workflow datasets being determined to have a calculated variance exceeding a threshold variance (see para [0082]-[0084], where the alarm data is the action data set that is reformatted until acceptable for optimization based on inferences based on threshold which shows behaving as an action dataset and an initiative dataset given broadest reasonable interpretation)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 8578493 B1
US 8117127 B1
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 SUJAY KONERU whose telephone number is (571)270-3409. The examiner can normally be reached M-F, 8:30 AM to 5 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 on 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.
/SUJAY KONERU/
Primary Examiner, Art Unit 3624