Petitioner’s Reply in Support of Petition
`IPR2015-00631
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`SERVICENOW, INC.
`Petitioner
`
`v.
`
`HEWLETT-PACKARD COMPANY
`Patent Owner
`
`Case IPR2015-00631
`U.S. Patent No. 7,392,300
`
`
`
`PETITIONER’S REPLY
`
`
`
`
`
`
`
`IPR2015-00631
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`SERVICENOW, INC.
`Petitioner
`
`v.
`
`HEWLETT-PACKARD COMPANY
`Patent Owner
`
`Case IPR2015-00631
`U.S. Patent No. 7,392,300
`
`
`
`PETITIONER’S REPLY
`
`
`
`
`
`
`
`
`Table of Contents
`
`
`Page
`
`
`I.
`
`HAMNER DISCLOSES THE “NETWORK EVENT” OF THE ’300
`PATENT ......................................................................................................... 1
`A.
`The Patent Owner’s Construction of “Network Event” is Wrong ....... 1
`1.
`The Intrinsic Evidence Supports Petitioner’s
`Interpretation .............................................................................. 2
`The Patent Owner’s Construction Should Be Rejected ............. 6
`2.
`B. Hamner Discloses a “Network Event” Under Any Construction ........ 8
`1.
`Patent Owner Does Not Dispute that Hamner Discloses
`Network Events Under Petitioner’s Proposal ............................ 8
`The Prior Art Discloses Network Events Even Under the
`Patent Owner’s or the Initial Board Construction ..................... 9
`II. MATHENY DISCLOSES A “NETWORK MODEL ” ............................... 17
`A.
`The Patent Owner’s Construction of “Network Model” is
`Wrong ................................................................................................. 17
`B. Matheny Discloses a “Network Model” ............................................ 19
`III. MATHENY, HAMNER AND PITT ARE PROPERLY
`COMBINABLE ............................................................................................ 21
`A. Matheny + Hamner ............................................................................. 21
`B. Matheny + Hamner + Pitt ................................................................... 23
`IV. CONCLUSION ............................................................................................. 25
`
`2.
`
`
`
`
`
`‐i‐
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`The Petitioner respectfully submits the following Reply:
`
`I.
`
`Hamner Discloses the “Network Event” of the ’300 Patent
`
`The patent owner’s first and primary argument is that Hamner does not
`
`disclose a “network event” and therefore does not disclose the step of “processing
`
`a network event” under its proposed construction. As explained in detail below,
`
`the patent owner’s arguments are wrong for two separate reasons. First, the patent
`
`owner has adopted and applied an incorrect construction of “network event.”
`
`Second, the patent owner’s arguments fail because even under the patent owner’s
`
`construction, Hamner discloses the claimed network events.
`
`A. The Patent Owner’s Construction of “Network Event” is Wrong
`
`This brief represents the Petitioner’s first opportunity since the filing of the
`
`IPR petition more than a year ago to address the proper construction of “network
`
`event.” The patent owner, in both its Preliminary Response and its subsequent
`
`Response, ignores the description of “network events” in the specification and
`
`relies instead on extrinsic evidence such as dictionaries and other external
`
`references. The Board should reject the patent owner’s approach and adopt a
`
`construction of “network event” consistent with
`
`its use
`
`throughout
`
`the
`
`specification.
`
`The Federal Circuit has made clear that “the specification ‘is always highly
`
`relevant to the claim construction analysis. Usually, it is dispositive; it is the single
`
`
`
`
`
`-1-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`best guide to the meaning of a disputed term.’” Phillips v. AWH Corp., 415 F.3d
`
`1303, 1315 (Fed. Cir. 2005) (en banc) (quoting Vitronics Corp. v. Conceptronic,
`
`Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). Extrinsic evidence such as dictionary
`
`definitions, on the other hand, is generally less reliable. Id. at 1318-19.
`
`The Federal Circuit in Phillips warned that the approach of conducting claim
`
`construction using dictionary definitions impermissibly shifts the focus away from
`
`the patent specification. “The main problem with elevating the dictionary to such
`
`prominence is that it focuses the inquiry on the abstract meaning of words rather
`
`than on the meaning of claim terms within the context of the patent.” Id. at 1321.
`
`This is precisely what the patent owner’s proposed construction of “network
`
`event” attempts to do. The specification provides dispositive guidance on the
`
`meaning of “network event.” As explained below, a person of ordinary skill in the
`
`art would have understood “network event,” as used in the patent, to refer to one or
`
`more operations that can be executed on or by a network or network device. (Ex.
`
`1002, ¶ 54; Ex. 1011, ¶ 6.) A simpler yet equivalent formulation would be an
`
`action or occurrence that takes place in the network.
`
`1.
`
`The Intrinsic Evidence Supports Petitioner’s Interpretation
`
`The key dispute as to the meaning of “network event” is straightforward.
`
`The patent owner contends that an “event” is a signal, such as a hardware or
`
`software interrupt, that notifies a computer that something needs attention.
`
`
`
`
`
`-2-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`(Response at 32; Menascé Decl. ¶¶ 49-53.) The patent owner further states that
`
`“[a]lthough a ‘network event’ can trigger an operation, command, or programs, the
`
`network event is not itself an operation, command, or program and is not executed
`
`or performed.” (Response at 32 (emphasis in original).)
`
`But this is exactly where the patent owner’s analysis falls apart. A “network
`
`event” in the context of the patent is the operation to be executed or performed, not
`
`the preceding occurrence that triggered it. For example, the specification describes
`
`a “network event” as something that is “executed”:
`
`Network events may be executed using the communications
`network representation. The network event may be selected
`from the group consisting of provisioning, circuit provisioning,
`service provisioning, switch provisioning, rollback, and delete.
`
`(’300, Ex. 1001, 2:51-55 (underlining added).) The passage above lists exemplary
`
`network events (e.g. provisioning, rollback, delete, etc.) that “may be executed
`
`using the communications network representation.” (Id. (emphasis added).) This
`
`list of executable network events is also reflected in dependent claims 5 and 19.
`
`(’300, claims 5 & 19 (“ . . . wherein the network event comprises at least one of
`
`provisioning, circuit provisioning, service provisioning, switch provisioning,
`
`rollback, and delete . . .”).)
`
`
`
`
`
`-3-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`The fact that a “network event” is an operation that is executed is further
`
`supported by Figure 5 (excerpted at right),
`
`which shows a flowchart describing the
`
`“processing a network event” step. In step
`
`210, the system determines if a network
`
`event needs to be processed. If so, the
`
`system
`
`identifies
`
`the needed network
`
`objects (step 214), then determines the
`
`order of operation (step 216). (’300, Ex.
`
`1001, 6:49-55.) “In step 218, the system then executes the event as required.”
`
`(’300, 6:55-56 (emphasis added).)
`
`The patent’s consistent and repeated description of “network events” as
`
`being “executed” undermines the core premise of the patent owner’s position –
`
`that a “network event is not itself an operation, command, or program and is not
`
`executed or performed.” (Response at 32.) The patent owner’s brief, in fact, does
`
`not cite or address any of the passages of the specification discussed above that
`
`expressly describe network events as operations that are executed.
`
`Other passages in the specification similarly describe the exemplary network
`
`events listed above (e.g. provisioning, rollback, delete) with synonyms such as
`
`“operations,” “implementations,” “service functions,” all of which refer to actions
`
`
`
`
`
`-4-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`that are executed. (’300, Ex. 1001, e.g., 3:45-48 (“The adapter may also refer to
`
`the XML document representation while performing operations on the objects in
`
`the network inventory, the operations including, but not limited to, provisioning,
`
`rollback, and delete.”) (emphasis added), 8:33-35 (describing each exemplary
`
`network event as an “operation”), 8:48-52 (same; each exemplary network event
`
`described as a “service function”), 6:57-61 (same; exemplary rollback network
`
`event described as an “implementation” that “may be automated to execute”).)
`
`The patent owner’s primary support for its definition of “network event”
`
`comes from a passage in the specification describing an exemplary “rollback”
`
`network event. The patent owner claims that the “network event” in this example
`
`is “the failure of a provisioning operation, which triggers an automated rollback
`
`operation.” (Response at 23 (emphasis added).)
`
`But this argument is directly refuted by the specification, which makes clear
`
`that the “network event” in this example is the rollback operation, not the
`
`preceding failure that may have triggered it. (’300, Ex. 1001, 7:64-65 (“When the
`
`adapter receives an event to rollback a line, the adapter gets a Service Instance ID
`
`(SIID) as input.”) (underlining added), 2:52-55 (“The network event may be
`
`selected from the group consisting of . . . rollback . . . .”).) The specification
`
`nowhere refers to “failure of a provisioning operation” as a “network event.” In
`
`fact, the rollback example includes exemplary XML code that defines the network
`
`
`
`
`
`-5-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`model and the operations for the rollback event. (Ex. 1011, ¶¶ 19, 20.) That XML
`
`code contains no reference to a provisioning failure or any other preceding
`
`occurrence that may have triggered the rollback event. (Id. ¶ 20.) Moreover, the
`
`specification contains no description whatsoever as to how any of the other
`
`exemplary network events (e.g. provisioning, circuit provisioning, service
`
`provisioning, switch provisioning, and delete) are triggered – further confirming
`
`that the term “event” refers to the operation to be performed and not a preceding
`
`occurrence that triggered it.
`
`Accordingly, the term “event” in the patent should carry its ordinary and
`
`everyday parlance, similar to how the phrase “sporting event” refers to the Super
`
`Bowl. An event is simply something that happens, not the preceding occurrence
`
`that may have led to it. Much the way no one would refer to a sporting event such
`
`as the Super Bowl by referring to earlier playoff games, a person of ordinary skill
`
`in the art would not refer to a “provisioning event” or a “rollback event” by
`
`reference to the preceding occurrence that caused it. (Ex. 1011, ¶¶ 9, 15, 16.) The
`
`term “network event” in the context of the ’300 patent is simply an operation,
`
`action, occurrence, etc., that is performed or takes place in the network.
`
`2.
`
`The Patent Owner’s Construction Should Be Rejected
`
`The patent owner asserts that “network event” should be construed as “an
`
`action or occurrence within the network that is detected or received by the system.”
`
`
`
`
`
`-6-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`(Response at 20.) The patent owner’s position is irremediably flawed because, as
`
`explained previously, it attempts to move the term “network event” away from the
`
`actual action or occurrence it describes – as explained in the specification – and
`
`toward some earlier, undescribed, and unclaimed triggering occurrence. The
`
`specification and claims do not describe any process of detecting events, further
`
`showing that the dictionary definitions cited by the patent owner are inapplicable.
`
`The patent owner’s construction also requires that a network event occur
`
`“within the network.” Although this requirement may on its face seem innocuous,
`
`the patent owner’s expert admitted at his deposition that it has a more covert
`
`purpose. He explained that the intent behind the phrase, “within the network,” was
`
`to limit the claim to “network events” generated by computers other than the one
`
`that is performing the claim steps. (Ex. 1011, ¶ 27; Ex. 1012, at 110:4-112:9.)
`
`This purported requirement was conjured by the patent owner to assert that the
`
`mouse click in Hamner does not qualify as a “network event” because the event
`
`originated from, and was processed by, the same computer. (Response at 17-18.)
`
`But the claims place no restrictions on where a “network event” must originate.
`
`The claims do not recite generation or receipt of network events, let alone specify a
`
`particular computer on which those actions must occur.
`
`The patent owner repeatedly asserts that the term “network event” imposes a
`
`further requirement that the event be “unpredictable.” (Response at 21, 31-32.)
`
`
`
`
`
`-7-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`But the patent owner’s expert abandoned this position at his deposition, conceding
`
`that “events” in computer science need not be unpredictable, and moreover, that
`
`the patent owner’s proposed construction did not require unpredictability. (Ex.
`
`1012, at 68:25-69:8, 27:16-20, 29:23-30:5; see also Ex. 1011, ¶¶ 29, 30.)
`
`The Board should accordingly adopt the Petitioner’s original construction of
`
`“network event,” i.e. one or more operations that can be performed on or by a
`
`network or network object. The Petitioner would also not object to a simpler and
`
`equivalent formulation incorporating the Board’s existing “action or occurrence”
`
`language – “an action or occurrence that is performed or takes place in the
`
`network.” In either case, the original proposal adopted by the Board, and the one
`
`advanced by the patent owner, should be rejected for the reasons stated above.
`
`B. Hamner Discloses a “Network Event” Under Any Construction
`1.
`Patent Owner Does Not Dispute that Hamner Discloses
`Network Events Under Petitioner’s Proposal
`
`The patent owner provides no argument that Hamner fails to disclose a
`
`“network event” under the Petitioner’s proposed construction. The patent owner’s
`
`expert admitted, moreover, that he did not analyze whether the prior art disclosed
`
`the claim limitations of the ’300 patent if the Petitioner’s proposed construction is
`
`adopted. (Ex. 1012, at 70:4-23, 73:16-74:9.) If the Board agrees with the
`
`Petitioner on the meaning of “network event,” therefore, the patent owner’s
`
`arguments on these limitations may be summarily rejected.
`
`
`
`
`
`-8-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`2.
`
`The Prior Art Discloses Network Events Even Under the
`Patent Owner’s or the Initial Board Construction
`
`a. Hamner Discloses Network Events
`Hamner discloses the receipt and processing of a “network event” even
`
`under the construction proposed by the patent owner and initially adopted by the
`
`Board. The patent owner provides no coherent explanation as to why a “task” in
`
`Hamner does not qualify as an “action or occurrence that is detected or received by
`
`the system.” As the Board acknowledged in its institution decision, “Hamner’s
`
`tasks are actions that may be initiated by a user on various network devices, the
`
`execution or initiation of which may be detected by the network.” (Institution
`
`Decision at 17.) As explained previously, the term “network event” does not
`
`require that a network event be unpredictable, or that the origination and
`
`processing of a network event take place on different computers. Tasks in Hamner
`
`are actions that are detected by the system that meet the proposed construction.
`
`Moreover, even if the “tasks” themselves did not qualify as a network event,
`
`the patent owner does not appear to dispute that the user action to initiate the task
`
`(such as double-clicking the task icon) would qualify as an event. (Response at 28-
`
`29.) The patent owner concedes that such user action results in the receipt and
`
`detection of an “event” by the system. (Id. at 21-22.) Accordingly, if the Board
`
`defined “network event” in the manner suggested by the patent owner, Hamner
`
`would still disclose this limitation. (Ex. 1011, ¶ 23.)
`
`
`
`
`
`-9-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`The patent owner contends that tasks and the activation of tasks by a user do
`
`not qualify as “network events” because they do not meet its new (and
`
`unsupported) requirement that the event originate within the network. (Response at
`
`28-29.) But as explained above, this proposed requirement on its face does not
`
`require that the network event originate and be processed by different computers.
`
`Moreover, Hamner discloses a networked environment in which each computer is
`
`coupled via a network to other computers. (Hamner, Ex. 1005, 3:25-33, Fig. 1.)
`
`The network includes a “management server 12,” and “[a]t least some of the
`
`services, including control software for coordinating the various services, are
`
`implemented within the management server 12.” (Id. at 3:33-35; see also id., 2:56-
`
`58.) Figure 2A discloses a “Management Console” that allows a task to be
`
`selected for execution. (Hamner, Fig. 2A, 11:25-27.) These tasks can include
`
`actions such as viewing the screen of a particular PC, rebooting selected
`
`workstations, among others. (Ex. 1002, ¶ 96 (quoting from Hamner, 3:51-56).)
`
`Because of the networked nature of the communications system in Hamner,
`
`the selection of a task for execution on a network device clearly occurs “within the
`
`network.” The user action could occur on the management server 12 or on one of
`
`the personal computers connected to it. (Ex. 1011, ¶ 25, 26.) It does not matter
`
`either way because the user action originates from, and specifies a task to be
`
`performed on, a computer or computers that are part of the network. (Id. ¶ 27.)
`
`
`
`
`
`-10-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`The proposed “within the network” limitation is therefore satisfied.
`
`b. Hamner Discloses “Processing the Network Event
`Using the Network Model” and its Subsequent Steps.
`
`The patent owner next contends that Hamner does not disclose the step of
`
`processing the network event using the network model. The patent owner’s
`
`arguments start by asserting that the “identifying” and “determining” steps must
`
`use the network model. (Response at 36-37.) But the claims only require that the
`
`step of “processing the network event” use the network model. As the Board
`
`correctly observed, “[t]he claims allow for the processing step to include other
`
`steps and do not recite that the identifying and determining steps require the use of
`
`the network model.” (Institution Decision at 17.) Nevertheless, even if the patent
`
`owner’s position were adopted, Hamner still discloses the claimed processing step
`
`and the “identifying” and “determining” steps using the network model.
`
`The patent owner does not appear to dispute that Hamner discloses the step
`
`of “processing a network event using the network model,” and appears only to
`
`dispute the “identifying” and “determining” steps. (Response at 42, 45.) The
`
`Petitioner will address those arguments in turn.
`
`(1)
`The patent owner asserts that Hamner does not disclose the step of
`
`“Identifying One or More Network Objects”
`
`“identifying one or more network objects of the plurality of objects.” (Response at
`
`42-45.) But its arguments are based on a timing argument about when the steps
`
`
`
`
`-11-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`occur in Hamner, which in turn is based on the false assumption that “processing
`
`the network event” as recited in the claim can occur only when the user actually
`
`selects a task for execution. (Id.)
`
`The term “processing” claims encompasses a broad range of activities that
`
`can occur before network event execution. The claims state that the processing can
`
`include “identifying one or more network objects,” and “determining an order of
`
`operation on the one or more network objects.” The specification makes clear that
`
`these two steps (shown as steps 214 and 216 in Figure 5) occur before the network
`
`event is actually executed (step 218). (’300, 6:52-56; Fig. 5.)
`
`Hamner discloses a similar sequence. As explained in the Petition, the
`
`processing of network events (tasks) occurs in Hamner when the system uses the
`
`network model to identify the network devices and the tasks that can be performed
`
`on them. (Petition at 36-38.) In particular, Hamner discloses a group view
`
`generator 341 that uses the network model to identify device groups and the
`
`devices within them. (Petition at 38 (citing Hamner, 9:61-67); Ex. 1002, ¶¶ 95-
`
`97.) The task manager 305 then determines which tasks can be performed on the
`
`devices. (Ex. 1002, ¶ 95 (citing Hamner, 11:8-11, 11:18-21).) Hamner therefore
`
`discloses the steps of “processing the network event,” and “identifying one or more
`
`network objects,” both using the network model.
`
`The patent owner asserts that “tasks in Hamner are handled in the reverse
`
`
`
`
`
`-12-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`order from that required by the claimed steps, i.e., the device (the alleged ‘network
`
`object’) is identified first, and then a task (the alleged ‘network event’) is selected.”
`
`(Response at 45.) This argument boils down to the assertion that the steps of
`
`“processing a network event,” and “identifying one or more network objects of the
`
`plurality of network objects,” must occur in the order recited in the claim.
`
`(Response at 43-44.) But the claims impose no such requirement.
`
`Federal Circuit law is clear that “[u]nless the steps of a method actually
`
`recite an order, the steps are not ordinarily construed to require one.” Interactive
`
`Gift Express, Inc. v. Compuserve, Inc., 256 F.3d 1323, 1342 (Fed. Cir. 2001). In
`
`fact, it is improper to import a particular sequence into the claims even if that
`
`sequence is the sole embodiment in the specification. See Altiris, Inc. v. Symantec
`
`Corp., 318 F.3d 1363, 1371 (Fed. Cir. 2003).
`
`In the present case, nothing in the structure or logic of the claim requires that
`
`these steps be performed in order. The “processing” step, for example, does not
`
`provide the antecedent basis for any terms in the “identifying” step. Nothing in the
`
`claim suggests that the “identifying” step cannot occur before, after, or
`
`concurrently with, the “processing” step.
`
`And even if the “processing” and “identifying” steps had to occur in the
`
`order recited, Hamner would still disclose them. The patent owner plainly
`
`acknowledges that after the user selects the task to execute, Hamner passes the
`
`
`
`
`
`-13-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`identity of the network device on which it will be performed as a “parameter” to
`
`the task script. (Response at 44 (quoting Hamner, 11:4-5); see also Hamner, 8:67-
`
`9:2 (“If a device has a task, then that task is performable taking the device as a
`
`parameter.”), 11:11-17 (same).) This “parameter” identifies the network device on
`
`which the task is to be performed. (Ex. 1011, ¶ 37; Ex. 1012, at 96:3-99:3.) The
`
`passing of this parameter to the task, which occurs after the task is selected,
`
`qualifies a separate act of “identifying one or more network objects of the plurality
`
`of objects.” (Ex. 1011, ¶¶ 37, 38). The patent owner’s argument therefore fails.
`
`(2)
`The patent owner also erroneously asserts that Hamner and Pitt do not
`
`“Determining an Order of Operation”
`
`disclose the final step of “determining an order of operation on the one or more
`
`network objects.” (Response at 45-50.) The Petitioner will address this argument
`
`separately as to Hamner and Pitt.
`
`(a) Hamner
`The tasks in Hamner comprise scripts that include a sequence of instructions
`
`for performing operations on a network device. (Ex. 1002, ¶¶ 102-104, 106; Ex.
`
`1012, at 99:8-100:22.) The process of identifying and then executing a script
`
`clearly involves determining an order of operation – in fact, determining that order
`
`is fundamental to the execution of any computer program. (Ex. 1002, ¶ 106; Ex.
`
`1011, ¶ 40.) The patent owner does not dispute this.
`
`
`
`
`
`-14-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`The patent owner instead contends that identifying or executing a script in
`
`Hamner does not make use of the “network model.” (Response at 46.) As
`
`explained above, however, the claims do not require that the step of “determining
`
`an order of operation” use the network model. And even if they did, as explained
`
`previously, it is undisputed that the identity of network device on which the task is
`
`to be performed is passed as a “parameter” to the script. (Ex. 1012, ¶ 43; see also
`
`Hamner, Ex. 1005, 8:65-9:6, 11:3-6 & 11:11-18 (explaining how parameters are
`
`passed into the script identifying the target network device).) The identification of
`
`the network device is obtained from the network model. (Hamner, Ex. 1005, 7:43-
`
`45, 8:47-57 (explaining that information about the network devices is stored in the
`
`physical network model).) Execution of a task (and the resulting determination of
`
`the order of operation) therefore depends on parameter information obtained from
`
`the network model in Hamner.
`
`The patent owner next contends that “when the task is selected, the script
`
`had already been written and the order of operations on the network objects had
`
`already been determined.” (Response at 46.) There are at least two fatal flaws
`
`with this argument. First, when a script (or any other computer program) is first
`
`written, the order of operations to be performed is uncertain until the program is
`
`actually executed. (Ex. 1011, ¶ 41.) This is because computer programs decide
`
`which instructions to carry out based on conditions that were unknown at the time
`
`
`
`
`
`-15-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`the script is written. For example, a computer program can state the condition, “if
`
`condition [X] is true, execute code [A], otherwise execute code [B].” Condition
`
`[X] is by definition unknown at the time the program is written; in fact, the whole
`
`purpose of the “if-then” conditional statement is to allow the program to account
`
`for that condition that becomes known during execution. (Id.) As patent owner’s
`
`own expert conceded, the actual “order of operation” of a script in Hamner (or any
`
`computer program for that matter) is not known until the script is executed. (Ex.
`
`1012, at 102:12-103:3.)
`
`Second, even if the “order of operation” was predetermined when the script
`
`was written, the claim does not require that “determining an order of operation”
`
`occur only once, i.e. when the script is written. The claim does not require an
`
`order of operation be determined “for the first time.” Any subsequent instance in
`
`which the script is executed satisfies this requirement.
`
`(b) Pitt
`Even if Hamner alone does not disclose “determining an order of operation,”
`
`this step is disclosed by Pitt. (Petition at 51-55.) The patent owner’s arguments on
`
`Pitt rely on many of the same flawed arguments it presented for Hamner.
`
`The patent owner first contends that Pitt does not disclose determining an
`
`order of operation as part of processing a network event using a network model.
`
`(Response at 47-48.) But this is a misstatement of how the Petition mapped Pitt to
`
`
`
`
`
`-16-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`the claim limitations. The Petition cited Pitt only for the step of determining an
`
`order of operation in the independent claims. (Petition at 51.) The other aspects of
`
`the processing limitations, including the “network event” and the “network
`
`model,” were provided by Hamner. (Id.) As explained above, Hamner discloses
`
`tasks including “rebooting selected workstations” (Hamner, 3:54‐55), an operation
`
`just like a shutdown in Pitt in that both cause unavailability of devices from the
`
`network. (Ex. 1002, ¶¶ 130, 131.) The execution of this task uses the physical
`
`network model in Hamner for the reasons explained above.
`
`The patent owner’s arguments also erroneously assume that “determining”
`
`can occur only when the shutdown schedule is written. (Response at 48-49.) But
`
`the claim does not require an order of operation be determined “for the first time,”
`
`as noted. Just like the rebooting event in Hamner, the shutdown event in Pitt can
`
`be executed in response to user action. (Ex. 1002, ¶ 126 (citing Pitt, 4:10‐12).)
`
`II. Matheny Discloses A “Network Model ”
`
`The patent owner next contends that Matheny fails to disclose a “network
`
`model” under its own construction or the construction initially adopted by the
`
`Board. (Response at 50-55.) As shown below, the patent owner is wrong.
`
`A. The Patent Owner’s Construction of “Network Model” is Wrong
`
`Relying again on an inapposite dictionary definition, the patent owner
`
`asserts that “network model” should be construed as a “computer-based
`
`
`
`
`
`-17-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`representation of a network comprising the objects in the network and the
`
`relationships between them.” (Response at 51 (underlining added).) This differs
`
`from the Board’s initial construction, a “computer-based representation of plurality
`
`of objects in a network and the relationships between those objects.” (Id.)
`
`The key difference here is that the patent owner would require a
`
`“representation of a network,” instead of a “representation of a plurality of objects
`
`in a network,” as the Board concluded. The patent owner’s expert confirmed that
`
`the intention behind its proposal was to require that a “network model” represent
`
`the entire network, not simply a portion of it. (Ex. 1012, at 74:16-75:16.) But
`
`nothing in the claims or specification requires that a “network model” represent all
`
`aspects of the network. The claims merely recite a network model that includes “a
`
`plurality of network objects and relationships between the plurality of network
`
`objects.” Nothing in the claims requires that a “network model” represent “all
`
`network objects,” only a plurality of them.
`
`The specification also makes clear that a network model need only contain
`
`information about those network objects that are relevant to the network event
`
`being processed. In fact, the patent owner’s expert conceded that the exemplary
`
`network model in the specification does not represent the entire network. (Ex.
`
`1011, ¶ 51; Ex. 1012 (Menascé Depo.) at 126:17-128:2.) As patent owner’s expert
`
`explained, the exemplary network model in the specification does not include the
`
`
`
`
`
`-18-
`
`
`
`
`
`Petitioner’s Reply in Support of Petition
`IPR2015-00631
`Internet protocol connection 60 or the fast Ethernet connection 70 shown in Figure
`
`3. (Ex. 1012, at 127:3-128:2.) The patent owner’s definition would impermissibly
`
`exclude the exemplary “network model” in the specification. (Ex. 1011, ¶ 51.)
`
`B. Matheny Discloses a “Network Model”
`
`The patent owner next contends that Matheny does not disclose a “network
`
`model” because the discovery document is allegedly built only from the files
`
`describing the discovered nodes and does not incorporate the “relationship files.”
`
`(Response at 52-53.) This assertion is based on a mischaracterization of Matheny.
`
`Matheny discloses a “discovery agent” 106 that creates two types of files for
`
`the devices it discovers. (Matheny, Ex. 1003, ¶¶ 0020-0022.) First, the discovery
`
`agent “collects data from each device it discovers (block 310) and places the
`
`collected data in a file created for that device in the discovery directory (block
`
`312).” (Id. ¶ 0021.) This “discovery directory” in the embodiment described in
`
`Matheny is called: “/somepath/command/1234567.” (Id. ¶¶ 0020, 0021.)
`
`Second, “[t]he discovery agent may also create a relationship file, which
`
`indicates how the discovered nodes relate to each other.” (Id. ¶ 0022.) This
`
`relationship file is stored in the exact same “discovery directory” as the device
`
`information file discussed above. (Id. (“The relationship file may have the name
`
`‘/somepath/command/1234567/1234567.xml’.”).)
`
` The patent owner’s expert
`
`agreed with all of this. (Ex. 1012, at 76:12-78:23.)
`
`
`
`
`
`-19-
`
`
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
