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 .
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-8 are rejected under 35 U.S.C. 101 for containing an abstract idea without significantly more.
Regarding claim 1:
Claim 1 – Step 1 – Is the claim to a process, machine, manufacture or composition of matter?
Yes, the claim is to a machine.
Claim 1 – Step 2A – Prong 1 – Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes, the claim recites an abstract idea.
“at least one decision diagram, wherein each decision diagram represents the transition relation of a deterministic finite state machine model of at least one system component, wherein the variables in the decision diagram are ordered so that input and current-state variables precede next-state variables;” – this limitation recites a mental process by way of arranging information in a diagram and following ‘if-then’ rules in a chosen order to look up or infer the next result. A person could, with paper and pencil, list the current state and inputs, consult the diagram’s branches in that order, and write down the next-state value, i.e., steps “performed in the human mind” (organizing, evaluating, deciding) with or without a computer. See MPEP § 2106.04(a)(2)(III) (mental processes).
“data representation of input and current-state variables of transition relations, wherein transition relations are represented by decision diagrams;” – this recites a mental process by way of organizing information about current state and inputs and applying ordered if-then rules along a diagram to decide outcomes. A person could, with pencil and paper, list the input/current-state values, associate them with labeled branches in the diagram, and determine the result by following the path, i.e., steps capable of performance in the human mind (organizing, evaluating, deciding), with or without a computer. See MPEP § 2106.04(a)(2)(III) (mental processes).
“traverse the decision diagram to determine the next state” – recites a mental process by following an ordered set of if-then branches with known inputs/current-state to arrive at a next-state conclusion. A person could, with pencil and paper, start at the diagram’s root, check the input/current-state conditions in sequence, choose the appropriate branch at each decision point, and write down the resulting next state, steps capable of performance in the human mind (organizing, evaluating, deciding) with or without a computer. See MPEP § 2106.04(a)(2)(III) (mental processes).
“map received requests to the values of input variables” – recites data mapping/classification steps that can be performed conceptually as mental processes (organizing information and applying rules). See MPEP § 2106.04(a)(2)(III) (metal processes).
“map the values of current-state and next-state variables to functions” - recites data mapping/classification steps that can be performed conceptually as mental processes (organizing information and applying rules). See MPEP § 2106.04(a)(2)(III) (metal processes).
Claim 1 – Step 2A – Prong 2 – Does the claim recite additional elements that integrate the judicial exception into a practical application?
No, there are no additional elements that integrate the judicial exception into a practical application.
The additional elements are:
“at least one computer program to at least: receive requests” – merely data gathering (pre-solution input) in a generic environment (request = system call/API/ISR); does not integrate the exception. See MPEP § 2106.05(g); 2106.04(d).
“update input and current-state variables” – writing/assigning variable values in software is insignificant extra-/post-solution activity and does not improve computer technology; the disclosure frames these as ordinary program-variable assignments as part of the generic management routine. See MPEP § 2106.05(g).
“and execute functions to change the state and/or configuration of a computer system or its part upon updating current-state variables;” – implementing the computed next state by calling generic functions (e.g., procedure/remote calls, instructions, register/memory writes, system calls) is insignificant extra-solution activity/post-solution use that does not improve computer technology or integrate the exception into a practical application. The specification itself characterizes these as routine control outputs; it even teaches either sequence, functions before or after updating current-state variables, underscoring conventionality rather than a specific technological improvement. See MPEP § 2106.05(g); 2106.04(d).
“at least one processing unit to execute the computer program.” – merely invoking a generic processor to run the recited software does not integrate the exception into a practical application. The spec frames the management unit as software executing on a processing unit and lists ordinary examples (processor, multi-core processor, coprocessor, microcontroller, etc.), i.e., conventional hardware.
Claim 1 – Step 2B – Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, there are no additional elements that amount to significantly more than the judicial exception. The additional elements are:
“at least one computer program to at least: receive requests” – receiving/handling such calls is well-understood, routine, and conventional (WURC) in ordinary software running on processors, as described by the spec’s generic implementation. See MPEP § 2106.05(d).
“update input and current-state variables” – such variable updates are well-understood, routine, and conventional (WURC) in the disclosed environment; variables are implemented as standard program variables (e.g., C/C++) on a processing unit executing the software. No inventive concept.
“and execute functions to change the state and/or configuration of a computer system or its part upon updating current-state variables;” – considered individually and in combination, performing such routine calls/writes in response to state updates is well-understood, routine, and conventional (WURC) in ordinary software environments as described (generic management unit executing software on a processor; control effected via system/API calls or register writes). Thus, no “inventive concept”. See MPEP § 2106.05(d).
“at least one processing unit to execute the computer program.” – using such off-the-shelf processors to execute software is well-understood, routine, and conventional (WURC) in this field, per the disclosure (management system implemented in software and executed on a dedicated processor and/or multiple processors). No inventive concept. See MPEP § 2106.05(d).
Regarding claim 2:
Claim 2 – Step 1 – Is the claim to a process, machine, manufacture or composition of matter?
Yes, the claim is to a machine.
Claim 2 – Step 2A – Prong 1 – Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes, the claim recites an abstract idea. Claim 2 depends from claim 1 which was found to recite an abstract idea (see rejection of claim 1).
Claim 2 – Step 2A – Prong 2 – Does the claim recite additional elements that integrate the judicial exception into a practical application?
No, there are no additional elements that integrate the judicial exception into a practical application.
The additional elements are:
“annotations of nodes and/or edges of at least one decision diagram, wherein annotations represent additional information associated with nodes and/or edges.” – merely attaching metadata (e.g., values on nodes/edges) to the decision-diagram structure is generic data structuring/labeling within the abstract model. The specification itself describes annotations as values like power or time placed on nodes to estimate consumption/latency along a path, i.e., extra information used by (or alongside) the abstract computation, not an improvement to computer functioning or another practical application. See MPEP § 2106.04(d); 2106.05(a), (g), (f).
Claim 2 – Step 2B – Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, there are no additional elements that amount to significantly more than the judicial exception. The additional elements are:
“annotations of nodes and/or edges of at least one decision diagram, wherein annotations represent additional information associated with nodes and/or edges.” – considered individually and in combination, annotating graph nodes/edges with such values is well-understood, routine, and conventional information attachment in a generic computing context as presented (no specialized hardware or unconventional technique is claimed; the spec gives high-level examples like summing annotated power values or using time values). Thus, no “inventive concept”. See MPEP § 2106.05(d).
Regarding claim 3:
Claim 3 – Step 1 – Is the claim to a process, machine, manufacture or composition of matter?
Yes, the claim is to a machine.
Claim 3 – Step 2A – Prong 1 – Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes, the claim recites an abstract idea. Claim 3 depends from claim 1 which was found to recite an abstract idea (see rejection of claim 1).
Claim 3 – Step 2A – Prong 2 – Does the claim recite additional elements that integrate the judicial exception into a practical application?
No, there are no additional elements that integrate the judicial exception into a practical application.
The additional elements are:
“at least one input buffer to store information about received requests, wherein received requests are postponed for later processing;” – storing request information for later handling is data gathering/storage around the abstract computation (extra-/pre-solution activity); it does not improve computer technology or integrate the exception into a practical application. The spec describes straightforward buffering when the management unit decides to postpone processing. See MPEP § 2106.05(g).
“at least one timer to schedule timeouts;” – scheduling/cancelling a timeout is a generic control mechanism coordinating when to resume the abstract routine; it is extra-solution control flow and does not integrate the exception. The spec gives a typical patter: set a timeout on postpone; cancel if a new input arrives; otherwise handle on expiration. See MPEP § 2106.05(g).
“software functions and data for postponed processing of received requests, canceling timeouts, and dismissing requests.” – generic “software functions and data” that implement deferred handling/cancel/dismiss are result-oriented program control in a routine environment; they do not effect a specific improvement to the computer itself. See MPEP § 2106.05(g).
Claim 3 – Step 2B – Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, there are no additional elements that amount to significantly more than the judicial exception. The additional elements are:
“at least one input buffer to store information about received requests, wherein received requests are postponed for later processing;” – using an input buffer/queue to hold requests for deferred handling is well-understood, routine, and conventional (WURC) in generic software/OS practice as reflected by the disclosure’s ordinary buffering description; no “inventive concept”. See MPEP § 2106.05(d).
“at least one timer to schedule timeouts;” – timers/timeouts are well-understood, routine, and conventional (WURC) OX/software constructs; the disclosure presents standard behavior without unconventional implementation; thus, no inventive concept. See MPEP § 2106.05(d).
“software functions and data for postponed processing of received requests, canceling timeouts, and dismissing requests.” – considered individually and as an ordered combination with the buffer and timer, these are well-understood, routine, and conventional program operations (deferred execution, timeout cancelation, request dismissal) of the kind the spec treats as ordinary management logic; no inventive concept. See MPEP § 2106.05(d).
Regarding claim 4:
Claim 4 – Step 1 – Is the claim to a process, machine, manufacture or composition of matter?
Yes, the claim is to a machine.
Claim 4 – Step 2A – Prong 1 – Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes, the claim recites an abstract idea. Claim 4 depends from claim 1 which was found to recite an abstract idea (see rejection of claim 1).
Claim 4 – Step 2A – Prong 2 – Does the claim recite additional elements that integrate the judicial exception into a practical application?
No, there are no additional elements that integrate the judicial exception into a practical application.
The additional elements are:
“data representation of output variables, wherein output variables represent outputs of finite state machines;” – choosing/using output variables is generic data structuring within the abstract model (no improvement to computer technology). See MPEP § 2106.05(a), 2106.05(f), 2106.05(g). The spec treats outputs as values computed when state/input variables change.
“at least one function to update values of output variables;” – updating/assigning output-variable values after a transition is insignificant within-/post-solution activity that merely implements the abstract computation’s results. See MPEP § 2106.05(g). The spec describes routine evaluation/assignment upon variable changes.
“at least one function to generate output requests.” – emitting an output request/message following the computation is post-solution activity (generic communication/notification); does not integrate the exception into a practical application. See MPEP § 2106.05(g); 2106.04(d). The spec expressly lists generating an output request 446 or changing component state/configuration via routine calls/writes.
Claim 4 – Step 2B – Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, there are no additional elements that amount to significantly more than the judicial exception. The additional elements are:
“data representation of output variables, wherein output variables represent outputs of finite state machines;” – representing outputs as program variables is well-understood, routine, and conventional (WURC) per the disclosed generic implementation. See MPEP § 2106.05(d).
“at least one function to update values of output variables;” – routine program assignments is a generic environment (variables implemented as ordinary program variables) lack an inventive concept. See WURC, MPEP § 2106.05(d).
“at least one function to generate output requests.” – generating such requests via procedure calls, system calls, or register writes is well-understood, routine, and conventional (WURC) activity in the disclosed generic setup. See MPEP § 2106.05(d).
Regarding claims 5-7 (method claims)
Each of claims 5-7 is the method analog of the already-analyzed apparatus/system claims (5 <-> 1, 6 <-> 4, 7 <-> 3). The recited steps (e.g., representing the FSM transition relation with a decision diagram; receiving/mapping requests; traversing to determine next state; executing configuration-changing functions; computing/updating outputs and generating output requests; postponing via timers and canceling on new inputs;) merely restate in step form the same functional limitations previously analyzed for claims 1, 4, and 3 and do not materially change the prior-art/eligibility analysis. Under Step 2A (Prong 1/Prong 2), the method form does not add a different judicial exception or integrate it into a practical application; under Step 2B, the steps are implemented on generic computing components and are well-understood, routine, and conventional (WURC). Accordingly, claims 5-7 are rejected under 35 U.S.C. § 101 for the same reasons discussed above for claims 1, 4, and 3, respectively.
Regarding claim 8:
Claim 8 – Step 1 – Is the claim to a process, machine, manufacture or composition of matter?
Yes, the claim is to a process (method).
Claim 8 – Step 2A – Prong 1 – Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes, the claim recites an abstract idea. Claim 8 depends from claim 5 which was found to recite an abstract idea (see rejection of claim 5; see also claim 1, the apparatus/system analog of claim 5).
Claim 8 – Step 2A – Prong 2 – Does the claim recite additional elements that integrate the judicial exception into a practical application?
No, there are no additional elements that integrate the judicial exception into a practical application.
The additional elements are:
migrating the management of the computer system or its part from one processing unit to another. – moving where the abstract state-management routine executes is insignificant extra-solution activity and implementation choice about where to run the abstract computation; it does not affect an improvement to the functioning of the computer itself or integrate the exception into a practical application. See MPEP § 2106.05(g) (insignificant extra-solution activity; mere output/route/placement that does not meaningfully limit the claim); see also MPEP § 2106.05(f) (mere instructions to apply an exception).
Claim 8 – Step 2B – Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, there are no additional elements that amount to significantly more than the judicial exception. The additional elements are:
migrating the management of the computer system or its part from one processing unit to another. – considered individually and in combination, this limitation reflects well-understood, routine, and conventional (WURC) computer operations (e.g., task placement, load balancing, failover, power-aware scheduling) performed on generic processors. It does not add a specific technological improvement or unconventional arrangement and therefore does not amount to “significantly more” than the abstract idea. See MPEP § 2106.05(d).
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.
Claims 1, 3-8 are rejected under 35 U.S.C. 103 as being unpatentable over Filkorn (US5491639) in view of He (US10775874B2).
Regarding claim 1, Filkorn in view of He teach at least a system for the management of a computer system or its part, the system comprising:
one decision diagram, wherein each decision diagram represents the transition relation of a deterministic finite state machine model of at least one system component, - Filkorn teaches this:
“the corresponding transition relation … is represented with the aid of a binary decision diagram of the characteristic function of this transition relation.” (Filkorn, col. 6, lines 60-64)
Filkorn models deterministic systems as Mealy automata:
“the behavior of a synchronous sequential digital circuit can be modeled by the model of the finite state machine, more accurately called Mealy automaton” (Filkorn, col. 3. Lines 7-9)
data representation of input and current-state variables of transition relations, wherein transition relations are represented by decision diagrams; - Filkorn teaches this limitation:
“the states and input and output signals … are boolean vectors and the output and transition functions are … vector-valued boolean functions … [and] binary decision diagrams” (Filkorn, col. 6, lines 20-27)
at least one computer program to at least; Filkorn teaches this limitation in part. Filkorn teaches next-state computation over the BDD transition relation:
“only … substitution and OR combination on binary decision diagrams are required for carrying out the iteration step” (Filkorn, col. 8, lines 11-13)
Filkorn does not teach:
“at least one function to be executed to change the state and/or configuration of at least one system component;”
“wherein the variables in the decision diagram are ordered so that input and current-state variables precede next-state variables”
“… receive requests, map received requests to the values of input variables, update input and current-state variables, … map the values of current-state and next-state variables to functions, and execute functions to change the state and/or configuration of a computer system or its part upon updating current-state variables;“
“at least one processing unit to execute the computer program.”
He, however, teaches these limitations:
at least one function to be executed to change the state and/or configuration of at least one system component; - He discloses concrete configuration-changing actions during transitions:
“CGPLL output should be clock gated … a programmable delay is added … LPDDR4 PHY is retrained” (He, col. 15, lines 35-42)
“ramping the voltage back up” (He, col. 15, lines 22-23)
… receive requests, map received requests to the values of input variables, update input and current-state variables, … map the values of current-state and next-state variables to functions, and execute functions to change the state and/or configuration of a computer system or its part upon updating current-state variables; - He teaches these limitations:
“entry and exit conditions … include exit signals from a local advanced programmable interrupt controller (LAPIC) timer, fusion control hum (FCH) timer, USB, general purpose IO for the S5 domain (GPIO (S5)), GPIO for the S0 domain (GPIO (S0)), PCIe, On-die WiFi, audio coprocessor wakeup-on-voice (ACP (WOV)), and the power button.” (He, col. 16, lines 10-11, 28-29)
“receives latency information, e.g., a latency tolerance report (LTR) … this tolerance is compared with the latency required to recover the SO state” (He, col. 6, lines 10-11, 14-15)
at least one processing unit to execute the computer program. – He discloses:
“The methods or flow charts provided herein can be implemented in a computer program, software, or firmware incorporated in a non-transitory computer-readable storage medium for execution by a general purpose computer or a processor.” (He, col. 17, lines 25-29)
“A computer processing device includes a processor coupled to a memory. The processor includes circuitry to transition among a plurality of power management states” (He, col. 1, lines 46-48)
“In some implementations, the state transitions are managed by an operating system (OS) executing on the processor, and by hardware units. … The various hardware, firmware, and software components which manage the state transitions are referred to as the state mechanism or state machine.” (He, col. 13, lines 28-30, 37-40)
Neither Filkorn nor He expressly teach:
wherein the variables in the decision diagram are ordered so that input and current-state variables precede next-state variables
In view of the teachings, however, Filkorn performs next-state/image computation by applying the existence operator with respect to the inputs via substitution and OR on BDDs; Reference He evaluates entry conditions in the current state before any transition. A POSITA would have ordered the decision-diagram variables with input/current-state before next-state to mirror that evaluation flow and streamline the known BDD operations, an obvious rearrangement of parts that does not change function (MPEP § 2144.04(VI)(C)), and alternatively a routine optimization of a result-effective parameter (MPEP § 2144.05(II)).
Filkorn emphasizes that the BDD approach lets the iteration/transition computations be done efficiently: “all operations needed for constructing the fixed-point set can be implemented very efficiently with the aid of binary decision diagrams.” He provides the representation/engine (BDD transition relation + substitution), while He provides the controller context (processor-executed logic with conditions, timers, and concrete configuration-changing actions). A POSITA implementing He's controller would predictably adopt Filkorn’s BDD FSM engine to compactly encode and evaluate transitions and then trigger He’s taught actions, a simple substitution of one known FSM representation for another yielding no unexpected result.
Regarding claim 3, Filkorn in view of He, teach a system of claim 1, further comprising:
Filkorn does not teach these limitations:
at least one input buffer to store information about received requests, -
wherein received requests are postponed for later processing;
at least one timer to schedule timeouts;
software functions and data for postponed processing of received requests, canceling timeouts, and dismissing requests.
He, however, teaches these limitations:
at least one input buffer to store information about received requests – He’s controller explicitly operates on messages/events during the deferral window:
“receiving a message from an operating system” (He, col. 18, lines 26)
“receipt of the operating system hint,” (He, col. 12, lines 41-42)
He also checks whether clients “have interrupts pending” before processing, i.e., requests/events are retained pending service:
“whether no Data Fabric clients are attempting to access memory or have interrupts pending” (He, col. 14, lines 3-4)
And He’s deferral loop shows state must be re-evaluated after expiry (or OS hint) and sometimes returned (abandoned) instead of taken, i.e., the decision is postponed, requiring the controller to preserve request/context until the later check:
“After expiry of the timer or receipt of the operating system hint, the entry conditions … are again checked … the system returns to step 610” (He, col. 13, lines 3-5)
Given He’s explicit message receipt, pending interrupts, and timer-based deferral + re-check, a POSITA would employ a routine input buffer/queue to store the received request/event information during the deferral window so the controller can (i) re-evaluate on timer expiry or (ii) cancel/dismiss on arrival of a superseding event, a common-sense, predictable implementation in event-driven controllers. This buffer is the ordinary mechanism to maintain request context between the time of receipt and the later processing mandated by He’s deferral flow.
wherein received requests are postponed for later processing; - He defers action until a timer event and re-checks conditions thereafter:
“after expiry of the first sub-state residency timer … re-determine whether the entry condition … is satisfied.” (He, col. 17, lines 60-65)
“prior to entering … start a pre-entry timer … after expiry of the pre-entry timer, … return to the first power management state if the entry condition … is not re-determined to be satisfied.” (He, col. 18, lines 1-8)
at least one timer to schedule timeouts; -– He expressly delays the transition and re-checks after expiry of a timer, if conditions aren’t still met, the pending transition is abandoned/returned:
“a timer (e.g., a hysteresis timer) is … Started … After expiry of the timer … the entry conditions … are again checked … On a condition … that the conditions are not still satisfied, the system returns to step 610.” (He, col. 12, lines 35-49)
“After expiry of the timer … if conditions are met after expiry … the state transitions. If the conditions are no longer met after expiry of the timer, the state does not transition and the timer is reset.” (He, col. 12, lines 2-5)
“prior to entering … start a pre-entry timer, re-determine whether the entry condition … is satisfied after expiry of the pre-entry timer … and return to the first power management state if the entry condition … is not re-determined to be satisfied.” (He, col. 18, lines 12-19)
“FIG. 6 is a flow chart illustrating example transitions among long idle states based on hysteresis timers;” (He, col. 1, lines 37-38)
These passages show the controller postpones acting on the “request” to enter a deeper state until a timer event, then re-evaluates; if the condition no longer holds, it returns/cancels instead of proceeding, i.e., later processing after deferral.
software functions and data for postponed processing of received requests, canceling timeouts, and dismissing requests. – He provides explicit cancel/abort behavior when conditions fail on re-check:
“return to the first power management state if the entry condition … is not re-determined to be satisfied.” (He, col. 18, lines 6-8)
He also enumerates concrete entry/exist signals that act as the “requests/events” the controller handles:
“The example exit conditions include exit signals from a local advanced programmable interrupt controller (LAPIC) timer, fusion control hub (FCH) timer, USB, general purpose IO for the S5 domain (GPIO (S5)), GPIO for the SO domain (GPIO (SO)), PCie, On-die WiFi, audio coprocessor wakeup-on-voice (ACP (WOY)), and the power button.” (He, col. 16, lines 28-33)
Filkorn supplies the BDD/FSM decision framework; He provides verbatim disclosure of timers (residency, pre-entry, hysteresis), postponement until expiry, re-checking, and return (cancel/dismiss) behavior, as well as specific request/event sources. Implementing an input buffer for the deferred requests would have been a routine, predictable design choice to a POSITA at the time of the claimed invention.
Regarding claim 4, Filkorn in view of He, teach a system of claim 1, further comprising:
data representation of output variables, wherein output variables represent outputs of finite state machines; - Filkorn teaches this limitation. Filkorn expressly models Mealy machines with outputs and represents output functions with decision diagrams:
“the states and input and output signals … are boolean vectors and the output and transition functions are … vector-valued boolean functions,” (Filkorn, col. 6, lines 20-27)
with BDDs introduced for representing and operating on these functions; further, Filkorn computes an output relation by combining BDDs of the output functions (EXOR +
∋
over inputs). This teaches the claimed representation of outputs in the same decision-diagram framework.
at least one function to update values of output variables; - Filkorn teaches this limitation. In Filkorn, outputs are evaluated as functions of state/input within the BDD engine, i.e., output values are computed/updated as the state/input context changes:
“for each output one binary decision diagram is calculated … [then] the existence operator … is applied.” (Filkorn, col. 7, lines 22-26)
Filkorn does not however teach:
at least one function to generate output requests.
He, however, teaches this limitation:
at least one function to generate output requests. – He teaches that, upon deciding a power/state transition, the controller performs concrete actions (requests/commands) that change system configuration:
“CGPLL output should be clock gated … a programmable delay is added … LPDDR4 PHY is retrained.” (He, col. 15, lines 35-42)
These are quintessential “output requests” issued from the controller in response to FSM outcomes.
Filkorn teaches outputs of an FSM represented and evaluated via decision diagrams; He teaches emitting configuration-changing actions (requests) based on controller decisions. A POSITA would combine them so that output variables are represented/updated within the decision-diagram framework (Filkorn) and drive generation of output requests to enact configuration/state changes (He)
Regarding claims 5-7 (method claims):
Each of claims 5-7 is the method analog of the already-analyzed apparatus/system claims (5 [Wingdings font/0xDF][Wingdings font/0xE0] 1, 6 [Wingdings font/0xDF][Wingdings font/0xE0] 4, 7 [Wingdings font/0xDF][Wingdings font/0xE0] 3). The recited steps (e.g., representing the FSM transition relation with a decision diagram; receiving/mapping requests; traversing to determine next-state; executing configuration-changing functions; computing/updating outputs and generating output requests; postponing via timers and cancelling on new inputs) merely restate in step form the same functional limitations previously analyzed for claims 1, 4, and 3 and do not materially change the prior-art analysis. Accordingly, claims 5-7 are rejected under 35 U.S.C. § 103 as unpatentable over Filkorn in view of He for the same reasons discussed above for claims 1, 4, and 3 respectively.
Regarding claim 8, Filkorn in view of He, teach the method of claim 5, further comprising:
migrating the management of the computer system or its part from one processing unit to another. – Filkorn does not teach this limitation. He, however, teaches this limitation. He teaches the claimed computing environment with multiple available processing units/cores and software/firmware execution, e.g.:
“one or more processor cores, wherein each processor core can be a CPU or a GPU.” (He, col. 2, lines 37-38)
“The methods or flow charts provided herein can be implemented in a computer program, software, or firmware … for execution by a general purpose computer or a
processor.” (He, col. 17, lines 7-8, 28-29)
And He discloses that the SoC includes an ADP/GPU with compute units and a scheduler that:
“performs operations related to scheduling various wavefronts on different compute units.” (He, col. 2, lines 37-38)
Given He’s disclosure of the management logic (OS/firmware “state mechanism or state machine”) executed by a processor and a device having multiple processing units/cores (CPU/GPU; same die or multiple dies), a POSITA would have found it obvious to place and, when needed, re-place (migrate) the software management task among the available processing units to meet power, latency, or availability goals, i.e., a predictable implementation of known task placement/load-balancing/failover within the disclosed multi-processor environment, without changing the function of the manager. See MPEP § 2144.04(VI)(C) (rearrangement of parts – obvious where reordering/relocating elements of a known system does not produce a new or unexpected result), and alternatively § 2144.04(IV) (design choice)/§2144.05 (optimization/result-effective variable).
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Filkorn in view of He and in further view of Hungar (US9141708).
Regarding claim 2, Filkorn in view of He, and in further view of Hungar, teach a system of claim 1, further comprising:
annotations of nodes and/or edges of at least one decision diagram, wherein annotations represent additional information associated with nodes and/or edges. – Hungar teaches this this. Hungar teaches annotating nodes/edges of decision diagrams with additional information. Hungar’s selection structure is an ADD in which edges are associated with input-condition properties:
“The edges have associated properties of the input elements.” (Hungar, col. 10, lines 58-59)
“The selection structure is an Algebraic Decision Diagram (ADD) … terminal nodes, each representing a subset of candidate results having an accumulated weight.” (Hungar, Abstract)
“In response to a query … the ADD is traversed … to reach at least one terminal node having a maximum accumulated weight … ” (Hungar, Abstract)
“keeping at least one result predicate in the set of result predicates to be represented by the terminal node, the at least one result predicate having a maximum accumulated
weight among the set of result predicates; … and removing result predicates not having the maximum accumulated weight from the set of result predicates represented by the terminal node;” (Hungar, col. 21, lines 14-21)
These passages show edge properties and node weights, satisfying the claimed limitation.
Given Filkorn’s diagram-centric transition evaluation (substitution/
∋
+ OR on BDDs) and He’s policy-driven runtime controller (conditions, timers, exit latencies), a POSITA would associate the policy/selection data directly on the diagram as in Hungar (edge properties; terminal-node accumulated weights) to guide transversal/selection, a predictable data-structuring optimization with routine benefits (fast traversal, deterministic selection, and explainable choices). Filkorn’s symbolic engine (“only … substitution and OR combination … are required for carrying out the iteration step”) naturally benefits form labeled edges/nodes that carry decision predicates and selection weights; He provides the real-time use case (timed/conditioned transitions) where such annotations are functionally used.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL COLEMAN whose telephone number is (571)272-4687. The examiner can normally be reached Mon-Fri.
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, David Yi can be reached at (571) 270-7519. 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.
/PAUL COLEMAN/Examiner, Art Unit 2126
/DAVID YI/Supervisory Patent Examiner, Art Unit 2126