UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________________________________
`
`Case No. IPR2015-00631
`U.S. Patent No. 7,392,300
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________________________________________
`
`SERVICENOW, INC.,
`
`Petitioner,
`
`v.
`
`HEWLETT-PACKARD COMPANY,
`
`Patent Owner.
`____________________________________________
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`____________________________________________
`
`PATENT OWNER RESPONSE
`UNDER 37 C.F.R. § 42.120
`
`
`
`
`
`
`

`
`
`
`
`I. 
`
`II. 
`
`
`
`TABLE OF CONTENTS
`
`Case No. IPR2015-00631
`U.S. Patent No. 7,392,300
`
`Page
`
`INTRODUCTION ........................................................................................... 1 
`
`THE INVENTION OF THE ’300 PATENT ................................................... 5 
`
`III.  OVERVIEW OF THE CITED PRIOR ART REFERENCES ...................... 14 
`
`A.  Matheny ............................................................................................... 14 
`
`B. 
`
`C. 
`
`D. 
`
`XML in a Nutshell (Harold) ................................................................ 15 
`
`Hamner ................................................................................................ 15 
`
`Pitt ........................................................................................................ 18 
`
`IV.  THE CHALLENGED ’300 PATENT CLAIMS ARE NON-
`OBVIOUS BECAUSE CLAIM LIMITATIONS ARE NOT
`TAUGHT BY THE PRIOR ART .................................................................. 19 
`
`A.  Hamner does not disclose “a network event.” .................................... 20 
`
`1. 
`
`2. 
`
`3. 
`
`The term “network event” should be construed as “an
`action or occurrence within the network that is detected
`or received by the system.” ....................................................... 20 
`
`The tasks described in Hamner are not “network events”
`under the proper construction of the term. ................................ 27 
`
`Hamner does not disclose “a network event” under the
`Board’s construction of the term. ............................................. 33 
`
`B. 
`
`Neither Matheny nor Hamner alone, nor the combination of
`Hamner with Pitt, discloses “processing a network event using
`the network model . . . .” ..................................................................... 35 
`
`1. 
`
`The claimed “identifying” and “determining” sub-steps
`must use the network model and the network event must
`be detected or received before it is processed........................... 36 
`
`
`
`- i -
`
`

`
`
`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`2.  Matheny does not disclose “processing a network event
`using the network model” under the plain language of the
`claims. ....................................................................................... 39 
`
`3. 
`
`4. 
`
`5. 
`
`Hamner does not disclose “identifying one or more
`network objects of the plurality of network objects”
`under the proper reading of the claims. .................................... 42 
`
`Hamner does not disclose “determining an order of
`operation on the one or more network objects” under the
`proper reading of the claims. .................................................... 45 
`
`Pitt does not disclose “determining an order of operation
`on the one or more network objects” under the proper
`reading of the claims. ................................................................ 47 
`
`C.  Matheny does not disclose “a network model.” .................................. 50 
`
`1. 
`
`The claim term “network model” should be construed to
`mean “computer-based representation of a network
`comprising the objects in the network and the
`relationships between them.” .................................................... 51 
`
`2.  Matheny does not disclose a “network model” under the
`proper construction of the term. ................................................ 52 
`
`3.  Matheny does not disclose a “network model” under the
`Board’s construction of the term. ............................................. 54 
`
`V.  A PERSON OF ORDINARY SKILL IN THE ART WOULD NOT
`HAVE COMBINED MATHENY WITH HAMNER, OR MATHENY
`AND HAMNER WITH PITT ....................................................................... 55 
`
`A.  A person of ordinary skill in the art would not have combined
`Matheny with Hamner. ........................................................................ 55 
`
`B. 
`
`A person of ordinary skill in the art would not have combined
`Matheny and Hamner with Pitt. .......................................................... 57 
`
`VI.  CONCLUSION .............................................................................................. 60 
`
`
`
`
`
`
`
`- ii -
`
`

`
`
`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`FEDERAL STATUTES
`
`35 U.S.C. § 103(a) .................................................................................................... 1
`
`35 U.S.C. § 316(e) .............................................................................................. 1, 19
`
`
`
`
`
`- iii -
`
`

`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`Case No. IPR2015-00631
`U.S. Patent No. 7,392,300
`
`U.S. Patent No. 7,392,300 (the “’300 patent”) is directed to a novel system
`
`and method for modeling a network using structured information and using the
`
`model in an event-driven system to simulate the effect of network events on the
`
`network. ’300 patent (Ex. 1001) at Abstract, 2:51-62. Patent Owner Hewlett-
`
`Packard Company (“HP”) respectfully submits that the challenged claims of the
`
`’300 patent are patentable over the cited prior art.
`
`The Board instituted trial on a single ground set forth in the Petition:
`
`whether independent claims 1, 10, and 21 and dependent claims 7, 8, and 22 are
`
`obvious under 35 U.S.C. § 103(a) over U.S. Patent Publication Number
`
`2002/0161883 to Matheny (“Matheny”) (Ex. 1003) in view of Harold et al., XML
`
`in a Nutshell (2001) (“Harold”) (Ex. 1004), U.S. Patent No. 5,796,951 to Hamner
`
`(“Hamner”) (Ex. 1005), and U.S. Patent No. 5,717,934 to Pitt (“Pitt”) (Ex. 1007).
`
`Although Petitioner also asserted an additional ground of obviousness using the
`
`same first three references and substituting U.S. Patent No. 6,256,635 (Ex. 1006)
`
`for Pitt, the Board did not institute review on that ground.
`
`Petitioner bears the burden of proving that the ’300 patent is unpatentable by
`
`a preponderance of the evidence. 35 U.S.C. § 316(e). Petitioner has failed to
`
`demonstrate obviousness for at least four reasons.
`
`
`
`- 1 -
`
`

`
`
`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`First, Petitioner cannot show by a preponderance of the evidence that the
`
`cited prior art discloses a “network event.” HP respectfully requests that the Board
`
`reconsider its preliminary construction of “network event” as “an action or
`
`occurrence, including actions generated by users of devices on a network, that is
`
`received or detected by a network.” This construction incorrectly substitutes “by a
`
`network” for “by the system” and omits the key requirement that the event occurs
`
`“within the network.” Such a construction is inconsistent with the plain language
`
`of the term and the ’300 specification. The broadest reasonable interpretation of
`
`“network event” in light of the specification and consistent with the plain and
`
`ordinary meaning of “event” is “an action or occurrence within the network that is
`
`detected or received by the system.” Under this construction, the “tasks” disclosed
`
`in the Hamner reference relied on by Petitioner are not “network events.” Rather,
`
`“tasks” are actions selected by the user and then sent to the network for execution,
`
`not actions or occurrences received from the network and detected by the
`
`modeling system as is the case with “network events” in the ’300 patent. Further,
`
`even under the Board’s construction of “network event,” the tasks of Hamner are
`
`not “network events” because they originate at the network management server
`
`that manages the network, not in the network itself.
`
`Second, under the proper reading of “processing a network event using a
`
`network model, wherein the processing includes identifying one or more network
`
`
`
`- 2 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`objects of the plurality of network objects, and the processing further includes
`
`determining an order of operation on the one or more network objects,” Petitioner
`
`cannot show that any of Matheny, Hamner or Pitt, alone or in combination, meets
`
`these limitations. Matheny provides no details about how its “discovery
`
`document” (the alleged “network model”) is used after it has been generated, so it
`
`cannot disclose “processing a network event using a network model.” Nor does
`
`Hamner disclose the claimed sub-steps of “identifying” and “determining.” In
`
`Hamner, the device (the “network object”) must first be selected or discovered, and
`
`only then are the available tasks (the alleged “network event”) displayed or
`
`assigned. This is the opposite order from that required by the ’300 patent claims,
`
`in which the network event is first received or detected by the modeling system,
`
`and then the network objects needed to process the network event are identified.
`
`Moreover, contrary to the Board’s reading of “processing a network event using
`
`the network model…,” the plain language of the claims requires that both the
`
`“identifying…” and “determining…” sub-steps use the “network model,” which
`
`Hamner does not disclose. Finally, Pitt fails to disclose “determining an order of
`
`operation” after an event has been detected or received under the correct reading of
`
`the claims.
`
`Third, Matheny does not disclose a “network model” as required by the
`
`claims. The “discovery document” disclosed in Matheny contains information
`
`
`
`- 3 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`about discovered devices, but Matheny does not disclose that the discovery
`
`document includes information about the relationships between the devices. The
`
`relationships are an essential part of a “network model,” and without them,
`
`Matheny’s discovery document cannot be a network model.
`
`Finally, a person of ordinary skill in the art would not have combined
`
`Matheny with Hamner or Hamner with Pitt. Hamner has no shortcomings
`
`regarding its physical network model that could be cured by Matheny, and the
`
`combination of the two would result in an inoperable system. Further, a person of
`
`ordinary skill in the art would not have combined Hamner with Pitt. Adding the
`
`shutdown sequence rules of Pitt to Hamner’s database would not satisfy the step of
`
`“determining an order of operation on the one or more network objects,” as
`
`Petitioner contends. Moreover, incorporating the other part of Pitt—the user
`
`interface software for creating the shutdown sequence—into the Hamner system
`
`would be very difficult (and indeed Petitioner does not even mention it). Nor is
`
`there any need to do so: the user of the Hamner system already has complete
`
`control over when tasks can be executed and on which devices. Pitt also suffers
`
`from the same deficiencies as Hamner, i.e., failure to disclose first receiving a
`
`network event and then determining an order of operations in response to it.
`
`In this response, HP addresses each of these limitations in turn, under both
`
`the proper construction of the terms and the Board’s preliminary constructions. HP
`
`
`
`- 4 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`also addresses the Board’s specific concerns from its Decision on Institution (Paper
`
`12). In doing so, HP provides a detailed technical analysis in the accompanying
`
`declaration of Dr. Daniel Menascé (Ex. 2008), an expert with 40 years of
`
`experience in the areas of computer science, computer-based systems and software
`
`architectures, and information systems. In addition, HP cites or quotes many
`
`admissions from the deposition of Petitioner’s own expert, Dr. Lavian, to
`
`corroborate the arguments set forth in this response.1
`
`II. THE INVENTION OF THE ’300 PATENT
`
`The ’300 patent teaches and claims a novel method and system for creating a
`
`flexible and easily-configurable model of a network that can be used for event
`
`processing in an event-driven system. ’300 patent (Ex. 1001) at 1:6-8, 2:51-62,
`
`3:55-62; Menascé Decl. (Ex. 2008) ¶ 55. Communications networks consist of a
`
`variety of devices—such as computers, printers, routers, and gateways—
`
`interconnected by communication lines. ’300 patent (Ex. 1001) at 2:36-41. A
`
`network allows computers to communicate with each other and applications
`
`running on these computers to interact. Examples include a browser at a user’s
`
`1 HP’s expert Dr. Menascé sets forth his position on a person of ordinary skill in
`
`his declaration, and he states that his opinions do not change if the definition of a
`
`person of ordinary skill in the art set forth by Petitioner’s expert, Dr. Lavian,
`
`applies. Menascé Decl. (Ex. 2008) ¶¶ 38-40; Lavian Decl. (Ex. 1002) at ¶ 19.
`
`
`
`- 5 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`computer interacting with a web server that could be located in a different
`
`continent. Menascé Decl. (Ex. 2008) ¶¶ 42-47.
`
`An important consideration in the context of network design is the
`
`evaluation of design and maintenance alternatives. Menascé Decl. (Ex. 2008) ¶ 56.
`
`It is costly, time consuming, and potentially disruptive to test the effect of
`
`alternatives in network design on the network itself. Id. An alternative to
`
`experimenting and testing various design and maintenance options on the network
`
`itself is to simulate the network. Id. Simulation is a technique that works on a
`
`model of the system being simulated. Id. Using a computer model to simulate the
`
`architecture and the behavior of the network before any changes are made to the
`
`network can help identify potential problems, thereby reducing costs. ’300 patent
`
`(Ex. 1001) at 1:28-34. For example, in the event of a server failure, using the
`
`model to identify devices connected to the server will help the network
`
`administrator determine which devices will need to be moved to a new server and
`
`how that should be done before any changes are actually done on the network.
`
`Once a plan is in place, the actual replacement of the server should be more
`
`efficient and less disruptive. Menascé Decl. (Ex. 2008) ¶ 56.
`
`The modeling system described in the ’300 patent (also called the “system”
`
`or “network inventory adapter” in the patent) includes computer program code for
`
`modeling the network and then processing network events using the model. ’300
`
`
`
`- 6 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`patent (Ex. 1001) at Abstract, 2:51-62, 3:9-18, 6:17-26. The modeling system first
`
`creates and stores a model of the network called a “network model,” which can be
`
`rebuilt any time there are changes in the network. Id. at 3:42-45, 6:34-46. The
`
`network model can then be used to simulate the effect of events that occur in the
`
`network. Menascé Decl. (Ex. 2008) ¶ 57. Unlike routine functions that can be
`
`selected by a network administrator using a network management tool on a server,
`
`a “network event” in the ’300 patent originates in the network, and the modeling
`
`system detects and responds to it. When a “network event” is detected, the
`
`modeling system uses the “network model”—which reflects the current
`
`configuration of the network—to determine how to respond to the network event.
`
`The ’300 patent thus describes an event-driven system in which the modeling
`
`system responds to and processes network events received from the network. Id. ¶
`
`57.
`
`Exemplary independent claim 1 claims a method for modeling a network
`
`and using the network model to process a network event:
`
`A method of modelling a communications network
`1.
`using a computer system, the method including:
`
`generating a network representation using computer-
`readable code, the computer-readable code representing
`structured information;
`
`parsing the network representation;
`- 7 -
`
`
`
`

`
`
`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`generating a network model using the parsed network
`representation, the network model including a plurality of
`network objects and relationships between the plurality
`of network objects;
`
`storing the network model in memory; and
`
`processing a network event using the network model,
`
`wherein the processing includes identifying one or more
`network objects of the plurality of network objects, and
`
`the processing further includes determining an order of
`operation on the one or more network objects.
`
`’300 patent (Ex. 1001) at claim 1. Claims 10 and 21 are similar. Figure 5 is a flow
`
`chart that illustrates the claimed steps:
`
`
`
`- 8 -
`
`

`
`
`
`
`
`
`
`Case No. IPR2015-00631
`U.S. Patent No. 7,392,300
`
`
`
`’300 patent (Ex. 1001) at Fig. 5, 6:32-34. The system first generates a network
`
`representation in step 200 using structured code, such as eXtensible Markup
`
`Language (“XML”). Id. at 6:34-36. The “network representation” contains the
`
`inventory of devices on the network such as servers, printers, computers, and
`
`routers and the relationships between them. Id. at 3:67-4:8 (listing exemplary
`
`devices), 6:42-44. The system then “parses” the network representation—i.e., the
`
`
`
`- 9 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`XML code is read and divided into individual elements according to XML rules—
`
`in step 202 to create the network model in step 204. Id. at 6:44-46.
`
`After creating the network model, the modeling system uses it to process
`
`“network events” that occur in the network. Examples of network events given in
`
`the patent include provisioning or deleting a network device, but other events in
`
`the network can also be detected and processed using the network model and
`
`modeling system. Id. at 2:52-58 (listing examples relevant to a dial-up network).
`
`In step 210, the modeling system determines whether a network event has
`
`been received for processing. Id. at 6:49-51 (“[T]hen the system determines
`
`whether an event is to be processed, step 210.”) (emphasis added). If a network
`
`event has been received, the modeling system will need to respond to the event by
`
`updating the network model in some way, depending on the type of event.
`
`Menascé Decl. (Ex. 2008) ¶ 61. To do this, the modeling system first identifies the
`
`network objects (the network devices) in the network model that may need to be
`
`updated or deleted or are otherwise affected by the network event. ’300 patent
`
`(Ex. 1001) at 6:52-53 (“If yes, then the system identifies the needed objects in the
`
`network model, step 214.”). The modeling system then determines which objects
`
`will need to be operated on, the operation needed for each object (i.e., update or
`
`delete), and the order in which those operations will occur. Id. at 6:53-55 (“In step
`
`216, the system determines the order of operations needed to process the network
`
`
`
`- 10 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`event.”), 5:9-11 (“The adapters 34 [system of the invention] may support specific
`
`operations and allow for various operations to be triggered by certain events and
`
`commands.”) (emphasis added throughout). These operations are then executed in
`
`order. Id. at 6:55-56. In this manner, the network event is processed using the
`
`network model, and the network model will then reflect any changes to the
`
`network triggered by the network event. Menascé Decl. (Ex. 2008) ¶¶ 57-62.
`
`The following example illustrates the processing of a network event and the
`
`importance of determining the order of operation on the network objects. In this
`
`example, the network has (among other components) a server with several devices,
`
`such as printers and computers, connected to it. The network model, which
`
`includes network objects representing the server and connected devices, is
`
`generated and stored in a database. See ’300 patent (Ex. 1001) at 8:48-49 (“In one
`
`embodiment, the model is generated in a network database.”). The modeling
`
`system then receives a network event from the network notifying it that the server
`
`has failed and needs to be replaced.
`
`Replacing the server in the network model requires deleting the server
`
`database record and adding the new server record. But the old server object cannot
`
`simply be deleted first, because doing so will also delete the connections to the
`
`devices connected to the server, leaving no way to find these previously-connected
`
`devices when it is time to connect them to the new server. In other words, they
`
`
`
`- 11 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`would be orphaned objects. Menascé Decl. (Ex. 2008) ¶¶ 63-64. To avoid this
`
`problem, all the dependencies related to the failed server—such as the connected
`
`devices—must first be examined by following the connections in the database (the
`
`network model) until each such device is identified. Id. ¶ 65. In this example, the
`
`old server object in the network model is first located (such as by server name),
`
`and then all devices connected to or communicating with the server are identified
`
`by following all the connections in the database. Id. The new server object record
`
`is then added to the database, and the records for the devices connected to the old
`
`server are updated to instead connect to the new server object. The old server
`
`object will no longer be connected to anything, so it can be deleted with no risk of
`
`leaving orphaned devices. Id.
`
`By examining the connections in the network model to identify these
`
`interdependencies before acting on any changes required by the network event, the
`
`modeling system will determine the network objects affected by the network event,
`
`the operations that must be performed on them to process the event, and the order
`
`in which the operations on the network objects will be performed. ’300 patent at
`
`Abstract, 3:15-18. This will allow changes to be made to the network model (and
`
`the network itself) in a manner that will prevent such errors as orphaned devices.
`
`Menascé Decl. (Ex. 2008) ¶ 66. The modeling system cannot identify network
`
`objects and determine the order of operations until the “network event” has been
`
`
`
`- 12 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`received—the system must first know the nature of the network event. The system
`
`also must use the most recent version of the network model to simulate accurately
`
`how the network event will affect the physical network. Id. ¶¶ 66-67.
`
`The ’300 patent also contains an example that illustrates the claimed steps.
`
`Column 7 contains an XML network model representing portions of the network
`
`shown in Figures 2 and 3. This model is used for performing a rollback operation
`
`in response to a network event indicating that a provisioning operation (here,
`
`making a circuit available for use) on the network has failed. Menascé Decl. (Ex.
`
`2008) ¶¶ 68-72. When the network event is received from the network, the
`
`modeling system first identifies the network objects—i.e., the circuits that have
`
`been created as part of the provisioning operation—in the network model by
`
`locating each circuit (using the “Circuit” tag) where the DeleteCircuit field is
`
`“YES” and any underlying physical links on which the virtual circuits depend (and
`
`that must also be deleted). ’300 patent (Ex. 1001) at 7:44-45 (“‘DeleteCircuit’
`
`identifies whether or not a particular circuit needs to be deleted.”), 7:53-55
`
`(“‘UnderlyingLinkindex’ identifies whether or not the circuit has an underlying
`
`link.”). The modeling system will then determine the order that each circuit and
`
`link must be deleted using the numerical values in the “Index” field for circuits and
`
`the “UnderlyingLinkindex” field for physical links. Id. at 7:42-44 (“The Index
`
`field identifies the order in which the circuits are to be deleted.”) (emphasis
`
`
`
`- 13 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`added), 7:55-57 (“If an underlying link exists, the underlying link index has
`
`numerical value identifying the order in which it is to be deleted.”) (emphasis
`
`added). The modeling system will then be able to delete the objects representing
`
`the physical links and the circuits in the proper order. Id. at 8:25-31. For example,
`
`no physical link is deleted before all the virtual circuits dependent on the physical
`
`link are first deleted. Menascé Decl. (Ex. 2008) ¶¶ 73-77.
`
`III. OVERVIEW OF THE CITED PRIOR ART REFERENCES
`
`A. Matheny
`
`The Petition relies on the Matheny patent publication (Ex. 1003) for several
`
`limitations in the challenged independent claims. Petition at 17, 24-34. Matheny
`
`is directed to a system and method for collecting and coalescing information about
`
`devices discovered on a network. Matheny (Ex. 1003) at Abstract. Matheny uses
`
`discovery “agents” to poll targeted devices on the network and collect information
`
`about them. Id. ¶ 0011. Matheny teaches saving the discovered information in
`
`files and then aggregating and “coalescing” the data discovered about devices into
`
`a “discovery document.” Id. ¶¶ 0021-0022, 0024.
`
`Although Matheny explains that network management tools “may be used to
`
`determine the operational status of equipment and transmission facilities and to
`
`obtain notification of faults and threshold conditions, e.g., network traffic
`
`bottlenecks” (id. ¶ 0001), Matheny contains no details about how its “discovery
`
`
`
`- 14 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`document” is used after it has been created, and thus does not disclose using the
`
`discovery document to “process[] a network event.” Menascé Decl. (Ex. 2008) ¶¶
`
`79-84. Instead, Matheny is directed solely to the discovery process to create the
`
`“discovery document.” Id.; Matheny (Ex. 1003) at Abstract.
`
`B. XML in a Nutshell (Harold)
`
`Harold is a 2001 desktop reference manual that explains the rules of XML
`
`that apply to all XML documents. The excerpt of Harold relied on by Petitioner
`
`contains an introduction to how XML works, discusses some of the fundamentals
`
`of XML (including tags and elements), and discloses how to write simple XML
`
`documents. Harold (Ex. 1004) at 9-37; Menascé Decl. (Ex. 2008) ¶ 85.
`
`C. Hamner
`
`The Petition relies on the Hamner patent (Ex. 1005) for “processing a
`
`network event.” Petition at 17, 34-43. Hamner is directed to an apparatus for
`
`providing network management services that allows a user to perform certain
`
`“tasks” on the devices in the network by using a user interface that displays a
`
`logical view of the network. Hamner (Ex. 1005) at 2:46-47, 3:57-59, 4:33-38.
`
`Some examples of tasks in Hamner include “viewing the screen of a particular PC;
`
`displaying packet counts; running a report; executing a remote virus scan;
`
`rebooting selected workstations; displaying print jobs; or, displaying non-
`
`functioning printers.” Id. at 3:51-56. Hamner also states that a “task consists
`
`
`
`- 15 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`essentially of an atomic script” and associated parameters (such as the device on
`
`which the task will be performed) (id. at 11:3-6), but does not disclose how tasks
`
`are assigned to devices, written, or executed.
`
`The features of Hamner, including its management console of Figure 2A
`
`described below, are implemented in a management server 12 connected to a
`
`network 10. See id. at Fig. 1, 3:25-40; Lavian Dep. (Ex. 2009) at 56:23-25. The
`
`software disclosed in Hamner includes a discovery manager 301, a database engine
`
`302, a physical network model 303, a view generator 304, and a task manager 305.
`
`Hamner (Ex. 1005) at Fig. 3, 4:59-63. The discovery module 301 collects data
`
`about the devices on the network and adds the information to the physical network
`
`model 303, which is stored in the physical model database. Id. at 5:27-33. The
`
`task manager 304 determines which tasks can be performed on the network, and
`
`associates each task with the devices and groups of devices on which the task can
`
`be performed. Id. at 5:33-37, Fig. 10.
`
`Figure 2A of Hamner depicts the user interface of the management server
`
`12, with two main windows: a device window 201 and a task window 202.
`
`
`
`- 16 -
`
`

`
`
`
`
`
`
`
`Case No. IPR2015-00631
`U.S. Patent No. 7,392,300
`
`
`
`Id. at Fig. 2A, 4:2-4. When the user (such as a network administer) selects a
`
`specific device or device group from the device window 201 on the left, the task
`
`manager 305 of Hamner will calculate the available tasks for the device or device
`
`group and display them in the task window 202 on the right. Id. at 4:17-32, 11:22-
`
`25, Fig. 2A. The user can then select an available task (211, 212, 213) associated
`
`with the selected device to be performed on the device. Id. at 4:33-39, Fig. 2A. In
`
`other words, Hamner describes a network management tool in which the user of
`
`the management server first views the devices on the network, selects a device
`
`causing the tasks available for the device to display, and then initiates the task by
`
`selecting it. Hamner does not disclose receiving a network event from the network
`
`and then processing the network event by “identifying” the objects affected by the
`
`event and determining the order that the objects must be processed to respond to
`
`the event. A “task” in Hamner does not originate in the network and is not
`
`
`
`- 17 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`“detected or received” by the management server; instead, the “tasks” originate in
`
`the management server itself. Menascé Decl. (Ex. 2008) ¶¶ 86-91.
`
`D.
`
`Pitt
`
`The Petition cites Pitt (Ex. 1007) for a single limitation: “determining an
`
`order of operation on the one or more network objects.” Petition at 18, 51-55. Pitt
`
`is directed to a sequential computer network shutdown system and process. Pitt
`
`(Ex. 1007) at 1:21-22. Pitt discloses a two-part system: user interface software for
`
`configuring a rules-based shutdown plan that will be installed on each network
`
`device, and a process for executing the shutdown plan when scheduled or manually
`
`activated. Id. at 2:43-56, 3:34-37, Figs. 2, 3. In the configuration process, the user
`
`interface builds a list of computers on the network, identifies any
`
`interdependencies between devices, and recommends a shutdown schedule for
`
`each device based on the interdependencies and the available run time provided by
`
`the UPS (uninterruptible power supply) connected to the device. Id. at 4:13-46.
`
`The shutdown plan executes in response to a manual request, a scheduled
`
`shutdown, or a power failure. Id. at 5:12-18. Accordingly, in Pitt, the shutdown
`
`schedule itself—including the order of operations performed in that shutdown—is
`
`determined before the occurrence of the shutdown request, scheduled shutdown, or
`
`power failure. Menascé Decl. (Ex. 2008) ¶¶ 92-95.
`
`
`
`- 18 -
`
`

`
`
`Case No. IPR2015-00631
`
`U.S. Patent No. 7,392,300
`
`
`IV. THE CHALLENGED ’300 PATENT CLAIMS ARE NON-OBVIOUS
`BECAUSE CLAIM LIMITATIONS ARE NOT TAUGHT BY THE
`PRIOR ART
`
`The Board construed three terms from the ’300 patent claims: “network
`
`representation,” “network model,” and “network event.” Decision on Institution
`
`(Paper 12) at 5-9. The Board also noted that the phrase “using the network model”
`
`does not limit the “identifying” and “determining” sub-steps of “processing a
`
`network event using the network model….” Id. at 17. For the purposes of this
`
`inter partes review, HP does not dispute the Board’s construction of “network
`
`representation.” HP does, however, respectfully request reconsideration of the
`
`Board’s preliminary construction of “network event” and “network model” and
`
`interpretation of the “identifying” and “determining” sub-steps as not requiring use
`
`of the “network model.”
`
`Under either reading of the claims, however, Petitioner has failed to meet its
`
`burden of proving by a preponderance of the evidence (see 35 U.S.C. § 316(e)) that
`
`the challenged claims of the ’300 patent are unpatentable over the proposed
`
`combinations. The claims are patentable because (a) Hamner does not disclose a
`
`“network event,” (b) neither Matheny nor Hamner alone, nor the com