throbber
Paper 12
`
`
`
`
`Trials@uspto.gov
`Date: August 17, 2015
`
`
`
`
`571-272-7822
`
`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
`Patent 7,392,300 B2
`
`
`Before JUSTIN BUSCH, JAMES B. ARPIN, and BARBARA A. PARVIS,
`Administrative Patent Judges.
`
`BUSCH, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`
`I.
`INTRODUCTION
`Petitioner, ServiceNow, Inc., filed a Petition to institute an inter
`partes review of claims 1, 7, 8, 10, 21, and 22 (“the challenged claims”) of
`U.S. Patent No. 7,392,300 B2 (“the ’300 patent”). Paper 1 (“Pet.”). Patent
`Owner, Hewlett-Packard Company, filed a Preliminary Response pursuant
`to 35 U.S.C. § 313. Paper 11 (“Prelim. Resp.”).
`We have authority to determine whether to institute an inter partes
`review. 35 U.S.C. § 314(b); 37 C.F.R. § 42.4(a). On this record and for the
`reasons explained below, we are persuaded that Petitioner shows a
`reasonable likelihood of prevailing with respect to at least one claim. See
`35 U.S.C. § 314(a). Accordingly, we institute an inter partes review.
`
`A.
`
`Related Matters
`
`Patent Owner has asserted the ’300 patent against Petitioner in
`Hewlett-Packard Company v. ServiceNow, Inc., Case No. 14-CV-00570
`(N.D. Cal.). Pet. 1; Paper 5, 2.
`
`B.
`
`The Asserted Grounds
`
`Petitioner relies upon the following references in support of its
`grounds for challenging the identified claims of the ’300 patent:
`
`Exhibit References
`1003
`U.S. Patent Application Publication No. 2002/0161883 A1,
`published October 31, 2002 (“Matheny”)
`Elliotte Rusty Harold and W. Scott Means, XML IN A NUTSHELL:
`A DESKTOP QUICK REFERENCE (2001) (“Harold”).
`U.S. Patent No. 5,796,951, issued August 18, 1998 (“Hamner”).
`U.S. Patent No. 6,256,635 B1, issued July 3, 2001 (“Arrouye”).
`U.S. Patent No. 5,717,934, issued February 10, 1998 (“Pitt”).
`
`1005
`1006
`1007
`
`1004
`
`2
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`Petitioner identifies the following as asserted grounds of
`unpatentability:
`Claims Challenged
`Basis
`References
`Matheny, Harold, Hamner, and Arrouye § 103(a) 1, 7, 8, 10, 21, and 22
`Matheny, Harold, Hamner, and Pitt
`§ 103(a) 1, 7, 8, 10, 21, and 22
`Pet. 3.
`
`C.
`
`The ’300 Patent
`
`The ’300 patent pertains to a system and method for modeling a
`communications network using a computer system. Ex. 1001, 1:6–8. In
`particular, the challenged claims are directed to methods and systems of
`modeling a communication network including generating and parsing a
`network representation, using the parsed representation to generate a
`network model, storing the network model in memory, and processing a
`network event using the network model. Id. at 9:40–12:18. This process is
`shown in Figure 5 of the ’300 patent, which depicts a flowchart of an
`exemplary process for modeling a communications network according to an
`embodiment of the ’300 patent. The ’300 patent explains that the network
`modeled may be any type of network, including local area networks, wide
`area networks, and virtual private networks. Id. at 2:37–39. The network
`representation may include any one or combination of various elements,
`including “circuit level index, circuit type identification, order of operation
`indication, delete circuit identification, underlying circuit index, underlying
`link index, delete object identification, parent circuit identification, and child
`circuit identification.” Id. at 2:42–48. The network representation may
`process any received data or network events, including “provisioning, circuit
`
`3
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`provisioning, service provisioning, switch provisioning, rollback, and
`delete.” Id. at 2:51–57.
`
`D.
`
`The Challenged Claims
`
`Petitioner challenges claims 1, 7, 8, 10, 21, and 22. Pet. 2. Claims 1,
`10, and 21 are independent. Claim 1 is illustrative and reproduced below:
`1. A method of modelling a communications network
`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;
`
`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.
`
`II. ANALYSIS
`
`A.
`
`Claim Construction
`
`“A claim in an unexpired patent shall be given its broadest reasonable
`construction in light of the specification of the patent in which it appears.”
`37 C.F.R. § 42.100(b). Pursuant to that standard, the claim language should
`be read in light of the specification, as it would be interpreted by one of
`ordinary skill in the art. In re Suitco Surface, Inc., 603 F.3d 1255, 1260
`(Fed. Cir. 2010). Thus, we generally give claim terms their ordinary and
`customary meaning. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257
`
`4
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`(Fed. Cir. 2007) (“The ordinary and customary meaning is the meaning that
`the term would have to a person of ordinary skill in the art in question.”)
`(internal quotation marks omitted).
`Petitioner proposes express constructions for three terms, “network
`representation,” “network model” and “network event.” Pet. 13–17. Patent
`Owner proposes different constructions for each of those three terms,
`arguing those definitions are the ordinary and customary meaning. Prelim.
`Resp. 4–18.
`
`1.
`
`“network representation”
`
`Petitioner proposes that network representation be construed as
`“information about at least one object in the network or its relationship to the
`network.” Pet. 13. Petitioner argues that construction “flows from the
`specification” because the ’300 patent describes examples of a network
`representation that would be satisfied by basic information about a single
`network object. Pet. 13–15 (quoting Ex. 1001, 6:35–44, 2:42–48; Ex.
`1002 ¶ 51).
`Patent Owner asserts that the plain meaning of network representation
`is “computer data that represents objects in a network and the relationships
`between them.” Prelim. Resp. 5. Patent Owner argues Petitioner’s
`construction would allow for a network representation to cover “information
`about only a single object or a single relationship, which is insufficient to
`form a representation of a network.” Id. Patent Owner points to portions of
`the ’300 patent describing the “network inventory” and to one sentence
`stating that the network representation may include representations of
`objects and relationships to support its argument. Id. at 5–6 (quoting Ex.
`
`5
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`1001, 6:42–44, 3:66–4:10. Patent Owner also cites to dictionary definitions
`of “network” to argue that a network requires at least two objects and a
`relationship between the two objects. Id. at 6. Finally, Patent Owner asserts
`that a network representation must include multiple objects and the
`relationships between the objects because the claims require generation of a
`network model using the network representation and claim 1 recites that the
`network model includes “a plurality of network objects and relationships
`between the plurality of network objects.” Id. at 6–7.
`On this record, we agree with Petitioner that the broadest reasonable
`interpretation of “network representation” may represent a single object or
`single relationship within a network. Although a network requires a
`plurality of network objects and a relationship or connection between those
`objects, the ’300 patent is clear that the network model generated in the
`claims includes a plurality of objects in a network and the relationships
`between those objects. Neither the claims nor the Specification of the ’300
`patent, however, requires that the recited network representation includes a
`plurality of objects; similarly, the recited network representation need not be
`the only source of information parsed or used to generate the network model.
`The recited system, for example, may parse a network representation of each
`object and each relationship that becomes a part of the network model.
`Furthermore, as pointed out by Petitioner, the Specification explicitly states
`that the network representation may include “one or more” of the identified
`elements “in any suitable combination.” Ex. 1001, 2:42–48 (emphases
`added). Thus, based on this record and for purposes of this decision, we
`construe a network representation to mean information about at least one
`object in the network or a relationship between objects in the network.
`
`6
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`
`2.
`
`“network model”
`
`Petitioner proposes that network model should be construed as
`“information about objects in the network and the relationships between
`them.” Pet. 15 (quoting Ex. 1001, 3:20–23; Ex. 1004 ¶ 18). Patent Owner
`argues Petitioner’s proposed construction gives no meaning to the word
`“model.” Prelim. Resp. 8 (quoting Ex. 1001, 3:20–26, 4:13–15). Patent
`Owner argues the plain meaning of a model is “a representation of a real
`world system,” and the specification of the ’300 patent makes it clear that its
`network model is a computer-based representation of the network. Id. at 8–9
`(quoting Ex. 1001, 4:15–19). Patent Owner asserts the proper construction
`is a “computer-based representation of a network comprising the objects in
`the network and the relationships between them.” Id. at 8.
`Based on this record, we determine that the broadest reasonable
`interpretation of a network model in light of the specification of the ’300
`patent is a computer-based representation of a plurality of objects in a
`network and the relationships between those objects.
`
`3.
`
`“network event”
`
`Petitioner proposes that we construe network event to mean “one or
`more operations that can be performed on or by a network or network
`object.” Pet. 16–17 (quoting Ex. 1001, 2:51–57, 6:46–56). In support of its
`position, Petitioner points to examples listed in the Specification of the ’300
`patent, including various types of provisioning, rollback, and delete. Pet.
`16–17.
`Patent Owner argues that a network event should be construed
`according to its plain meaning, which Patent Owner asserts is “an action or
`
`7
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`occurrence within the network that is detected or received by the system.”
`Prelim. Resp. 10. Patent Owner cites various technical dictionaries from
`near the filing date of the ’300 patent in support of its argument that the
`plain meaning of an event in computer science is “an action or occurrence
`that is detected or received by a system or process,” and that events “often
`will trigger the execution of a program or process.” Id. at 10–11. The
`definitions Patent Owner points to include examples, such as button or key
`presses, system occurrences, or movement of a mouse. Id. Patent Owner
`asserts the ’300 patent similarly describes a network event as something that
`is received from the network and that various operations are triggered in
`response to the receipt of such an event. Id. at 12–13.
`Patent Owner further argues that a network event is not an operation.
`Id. at 14–18. Specifically, Patent Owner asserts that an operation “is an
`action carried out by a computer while executing a program. Id. at 14
`(quoting Exs. 2004, 2006). Patent Owner states that a network event is
`different because it is “an action or occurrence within a network that is
`detected or received by the system.” Id.
`We agree with Patent Owner that a network event is not synonymous
`with an operation, but Patent Owner has not explained sufficiently why
`operations initiated by a user, or the results thereof, cannot be network
`events. In fact, Patent Owner points to multiple definitions of an “event”
`that indicate the action or occurrence may be user actions, including key
`presses and mouse clicks. Id. at 10 (quoting Exs. 2004, 2005). Patent
`Owner states that “a network event can be a message sent from a network
`indicating that a device has been disconnected,” but that assertion follows
`Patent Owner’s submitted evidence that an event is “an action, such as
`
`8
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`moving the mouse or clicking a mouse button, that generates a message.”
`Id. at 11 (quoting Ex. 2001 (emphasis added)).
`On this record and for purposes of this decision, we construe a
`network event to mean an action or occurrence, including actions generated
`by users of devices on a network, that is received or detected by a network.
`
`B. Multiple Grounds
`
`Petitioner asserts that claims 1, 7, 8, 10, 21, and 22 would have been
`obvious over Matheny, Harold, Hamner, and either Arrouye or Pitt under
`35 U.S.C. § 103(a). Pet. 17. In both the first and second grounds asserted,
`Petitioner relies on Matheny, Harold, and Hamner for every limitation
`except for “determining an order of operations on the one or more network
`objects.” Id. at 17–18. Notwithstanding these similarities between the first
`and second grounds, Petitioner argues the grounds are not redundant because
`Arrouye and Pitt: 1) teach the determining step in fundamentally different
`ways; 2) are not technologically similar, except that they both relate to
`network management; and 3) have different motivations for combination
`with the other references. Id. at 18–19. Petitioner provides a rationale for
`combining the various features of the references and a limitation-by-
`limitation analysis of how Petitioner alleges the combinations render the
`challenged claims obvious. Id. at 23–54.
`Petitioner does not identify one ground as clearly stronger than the
`other in some ways or clearly weaker in other ways. Petitioner merely
`provides the analysis for various limitations and asserts that either Arrouye
`or Pitt provides a further teaching of the determining an order of operations
`step. Essentially, Petitioner argues that either Arrouye or Pitt is sufficient
`
`9
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`and, thus, leaves to us the determination of which ground or grounds to
`institute review. In reviewing the Petition, we are persuaded that Pitt
`supports Petitioner’s arguments and, therefore, we exercise our discretion to
`institute review on the ground including Pitt. 37 C.F.R. § 42.108(a).
`
`C. Obviousness over Matheny, Harold, Hamner, and Pitt
`
`Petitioner asserts that claims 1, 7, 8, 10, 21, and 22 would have been
`obvious over Matheny, Harold, Hamner, and Pitt under 35 U.S.C. § 103(a).
`Pet. 51–55. Petitioner provides a limitation-by-limitation analysis of how it
`alleges the combination including Arrouye renders the challenged claims
`obvious. Id. at 23–51. Petitioner relies on Matheny, Harold, and Hamner
`for the same teachings in both grounds, but replaces Arrouye with Pitt. Pet.
`51. Therefore, Petitioner’s argument regarding the teachings and
`combination of Matheny, Harold, and Hamner (Pet. 20–51) apply equally to
`Petitioner’s ground relying partially on Pitt for teaching the determining an
`order of operations step.
`
`1. Matheny
`
`Matheny relates to a network management system for discovering and
`aggregating network devices. Ex. 1003, Abs. Matheny teaches discovery
`agents that collect information from identified network devices (id. ¶¶ 11–
`14) and aggregator agents that process the data the discovery agents collect
`in order to create further information for the network manager (id. ¶ 15).
`Matheny teaches using Extensible Markup Language (XML), or other
`markup language, files to store and share the collected and processed data.
`Id. ¶¶ 16, 19–21. The discovery agents also may create XML relationship
`files indicating how the discovered network objects relate to each other. Id.
`
`10
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`¶ 22. The network manager then may create a discovery document (which
`may use structured information, as indicated by the disclosure of having “a
`top-level node named, for example, <i-discover>”), which coalesces and
`aggregates the information by looping through the discovery files for the
`discovered devices. Id. ¶ 24.
`
`2.
`
`Harold
`
`Harold is a collection of excerpts from a book entitled “XML In a
`Nutshell: A Desktop Quick Reference,” published by O’Reilly. The
`excerpts describe the background and fundamentals of XML. Ex. 1004.
`Harold explains that XML is a markup language. Ex. 1004, 17. Harold
`further teaches that, to store XML data in a database on a server, software on
`the client sends SML data to a server using a network protocol and server-
`side software “receives the XML data, parses it, and stores it in the
`database.” Id. Harold describes XML as providing “cleanly documented,
`well-understood, easy to parse, text-based formats.” Id. at 18. In order to
`“understand the contents of the XML document” a program uses an XML
`parser, which divides the documents into individual attributes and elements,
`to read the document. Id. at 19.
`
`3.
`
`Hamner
`
`Hamner is directed to system and method for managing a computer
`network with multiple devices and a plurality of management tasks that may
`be performed on those devices. Ex. 1005, Abs. Hamner gathers data about
`a network configuration, including the types and quantity of devices, the
`relationships between the network devices, and the tasks that may be
`performed on each device. Id. Hamner stores the collected data in a
`
`11
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`database representing a network map and generates a display, using the data
`in the database, which corresponds to the network map. Id. The display
`shows the devices and the tasks that can be performed on the devices using
`graphical representations of the devices and tasks. Id. Upon selection of a
`device or group, the tasks that may be performed thereon are displayed, and
`the user may select a displayed task to initiate it. Id.
`
`4.
`
`Pitt
`
`Pitt is directed to a “user configurable, rule based sequencing of the
`shutdown of individual devices or the entire computer network.” Ex. 1007,
`Abs. Pitt teaches that each network device is connected to a conventional
`uninterruptable power supply and is provided with shutdown software. Id.
`The system can be user configurable and allows for the shutdown process to
`follow specific rules. Id.
`
`5.
`
`Claims 1 and 21
`
`The limitations recited in claim 1 and 21 are similar, with the
`exception that independent claim 1 recites a method and independent claim
`21 recites a computer program product including instructions to carry out the
`method recited in claim 1. Petitioner asserts the applied references teach
`carrying out the recited method using a computer program product. Pet. 50.
`Petitioner contends that Matheny teaches all of the limitations of claims 1
`and 21, except for the processing a network event step, which includes
`identifying one or more network objects and determining an order of
`operation on the one or more network objects. Id. at 23–33. Petitioner relies
`on a combination of Matheny and Hamner for this processing step. Id. at
`33–43. Petitioner further includes Harold and Pitt to provide additional
`
`12
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`support for teaching the parsing step and the determining an order of
`operation step, respectively. Id. at 28–30, 52–55.
`
`a.
`
`Generating and Parsing a Network Representation
`
`Petitioner alleges, and Patent Owner does not challenge in its
`Preliminary Response, that Matheny teaches modeling a communications
`network, including generating a network representation using computer-
`readable code that represents structured information and parsing the network
`representation. Id. at 23–30. Petitioner points to Matheny’s teaching of
`discovery agents that collect information on network objects and
`relationships that are then stored in XML files called discovery files. Id. at
`23–26. Petitioner asserts this collection of discovery files meets the recited
`network representation, and the process of generating the files meets the
`recited generating a network representation step. Id. Petitioner argues
`Matheny alone inherently teaches the parsing step but that, to the extent
`there is a question whether Matheny teaches that step, the parsing step would
`have been obvious in view of Matheny and Harold. Id. at 26–30 (quoting
`Ex. 1002 ¶ 73 (explaining that parsing XML is necessary to be able to
`extract data from an XML file)). Petitioner contends a person skilled in the
`art would have had reason to use the XML parser taught by Harold in order
`to parse the XML discovery files in Matheny’s network manager, resulting
`in a predictable combination that teaches the recited parsing step. Based on
`the current record, we agree that Matheny, or at least a Matheny-Harold
`combination, teaches a communications network modelling method
`including the recited steps of claims 1 and 21 relating to generating a
`network representation and parsing the network representation.
`
`13
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`
`b.
`
`Generating a Network Model
`
`Petitioner also contends that Matheny teaches “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” and “storing the network model in memory.” Id. at 30–33.
`Petitioner argues the generating a network model step is taught or suggested
`by Matheny’s teaching of the network manager coalescing the XML
`discovery files to generate a discovery document, which Petitioner maps to
`the network model. Id. at 30–32. Petitioner asserts that storing the network
`model in memory is taught or suggested by Matheny’s teaching of storing
`the discovery document in a database. Id. at 32–33.
`Patent Owner argues that Matheny’s discovery document is not a
`network model. Prelim. Resp. 21–23. Specifically, Patent Owner asserts
`Matheny provides no description of the content of the discovery document
`and that the reference does not “indicate[] how parsing the discovered
`information could contribute to the generation of a ‘network model’ as
`required by the challenged claims.” Id.
`Notwithstanding Patent Owner’s argument to the contrary, Petitioner
`points to aspects of Matheny that teach and further suggest the contents of
`the discovery document generated by coalescing the discovery files. In
`particular, Petitioner quotes from the portion of Matheny that discloses
`“loop[ing] through the information in all of the discovery files . . . and
`cop[ying] the data into the discovery document.” Ex. 1003 ¶ 24 (emphasis
`added); see Pet. 30–31. Thus, Matheny teaches that the data is copied from
`all of the discovery files. That portion of Matheny describes using the
`parsed representation of XML discovery files to copy the data into the
`
`14
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`discovery document. Ex. 1003 ¶ 24; Ex. 1004, 19. On this record, we agree
`with Petitioner that Matheny teaches the generating a network model and
`storing the model in memory steps recited in claims 1 and 21.
`
`c.
`
`Processing a Network Event
`
`Petitioner argues the step related to processing a network event using
`the network model, wherein the processing includes identifying one or more
`objects in the network and including determining an order of operation on
`the one or more objects, is taught by a combination of the teachings of
`Matheny, Hamner, and Pitt. Pet. 33–43, 52–55. Petitioner argues Matheny
`teaches that the discovery document, which Petitioner maps to the recited
`network model, can be used to process network events because it “may be
`used to evaluate network performance and possible faults, as well provide
`information needed to reconfigure the network.” Pet. 33–34 (quoting Ex.
`1003 ¶ 2). Petitioner asserts an ordinarily skilled artisan would have
`understood that evaluating network performance and possible faults would
`include identifying one or more network devices. Id. at 34.
`Petitioner further argues that Hamner teaches a network management
`system similar to Matheny and that Hamner’s physical network model
`“represents all known pieces of the managed network 10 and how those
`pieces interrelate” and is stored in a physical model database. Pet. 35
`(quoting Ex. 1005, 7:43–51). Petitioner asserts that Hamner’s tasks, which
`may be performed on the network devices and may include such actions as
`rebooting a workstation and displaying non-functioning printers, meet the
`recited network events limitation. Id. at 36–37. Petitioner argues that,
`“[b]ecause the ‘network model’ is used to determine and store the available
`
`15
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`tasks that may be executed, Hamner discloses use of the ‘network model’ to
`process network events.” Id. at 37.
`Patent Owner argues neither Matheny nor Hamner teaches
`“processing a network event using the network model.” Prelim. Resp. 23–
`30. Patent Owner asserts Matheny’s teaching of evaluating network
`performance and possible faults does not mention processing a network
`event or any details of how Matheny’s network model is used. Id. at 24.
`Patent Owner further asserts Petitioner has not supported its statement that
`an ordinarily skilled artisan would understand evaluating network
`performance and possible faults to include “identifying one or more devices
`in the network,” as required by claims 1 and 21.
`With respect to Hamner, Patent Owner argues that Petitioner
`improperly maps Hamner’s tasks to the recited network event. Id. at 28–30.
`In particular, Patent Owner asserts that Hamner’s tasks are functions that
`exist as scripts stored in a database and are already part of the device. Id. at
`28. Patent Owner further contends that Hamner requires selection of a
`network device to be managed and, subsequently, selection and initiation of
`a task associated with that device, which does not meet the recited
`processing a network event step that describes detecting a network event
`first, then processing the event, including using the network model to
`identify affected network objects and determining an order of operations. Id.
`at 29. Thus, Patent Owner concludes, Hamner’s sequence of steps are
`handled in an order opposite of that recited in the claims 1 and 21.
`On this record and for purposes of this decision, we are persuaded
`Hamner’s tasks meet our construction of a network event, which is an action
`or occurrence, including actions generated by users of devices on a network,
`
`16
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`received or detected by a network. We note, contrary to Patent Owner’s
`arguments, that the claims of the ’300 patent do not recite detecting a
`network event before processing it; in fact, the ’300 patent does not recite
`detecting a network event at all. 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. We further agree with Petitioner
`that Hamner teaches the processing a network event step including
`identifying one or more network objects. Moreover, the claims recite that
`the processing a network event step uses the network model and that the
`processing step includes identifying network objects and determining an
`order of operations. The 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.
`Furthermore, neither party has pointed to anything in the Specification
`of the ’300 patent to provide assistance in understanding what is meant by
`the recited processing a network event step beyond the further recitation that
`the processing includes identifying a network object and determining an
`order of operation. On this record, we are persuaded that Petitioner’s
`mapping is consistent with the claims and the Specification of the ’300
`patent. In particular, Petitioner’s assertion that determining and storing the
`available tasks that may be executed on network objects using Hamner’s
`physical network model meets the recited step of processing a network event
`using the network model is a reasonable interpretation of the recited
`processing step. Moreover, on this record, we are persuaded by Petitioner
`that selection or initiation of certain identified tasks, such as displaying non-
`
`17
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`functioning printers and rebooting selected workstations would result in
`identifying one or more network objects, as recited.
`Petitioner asserts it would have been obvious to combine Matheny and
`Hamner because Matheny discloses generating a network model that may be
`used to evaluate network performance and possible faults and provide
`information necessary to configure the network and Hamner discloses using
`a physical network model to provide a graphical display allowing a user to
`execute tasks on the network objects. Pet. 38–41. Petitioner points out that
`Hamner and Matheny both teach similar systems that discover network
`devices and generate network models in similar ways. Moreover, Petitioner
`asserts an ordinarily skilled artisan would have understood that Hamner’s
`network management system “could take over where Matheny leaves off.”
`Id. at 40 (citing Ex. 1002 ¶ 100). Finally, Petitioner argues an ordinarily
`skilled artisan would have understood that Hamner’s system could provide a
`graphical user interface for Matheny’s network model. Id. at 40–41. On this
`record, we are persuaded by Petitioner that an ordinary skilled artisan would
`have had reason for combining the teachings from Matheny and Hamner and
`arranging the limitations taught, as asserted in Petitoner’s challenge.
`Finally, Petitioner contends that Hamner’s tasks are scripts, which are
`sequences of instructions to perform a specific function and must be
`executed in a predetermined order. Id. at 42–43. Petitioner, thus, concludes
`that Hamner teaches determining an order of operations on a network
`device. Petitioner further argues that Pitt teaches determining an order of
`operations on one or more network objects because Pitt discloses shutdown
`plans for a network. Id. at 52. Petitioner explains that Pitt’s shutdown plans
`include rules that require shutting down affected devices in a
`
`18
`
`

`
`IPR2015-00631
`Patent 7,392,300 B2
`
`preprogrammed sequence. Id. at 53. Petitioner argues incorporating Pitt’s
`shutdown plan with the combined teachings of Matheny and Hamner would
`have taught or suggested all of the limitations of the challenged claims
`because of the advantages, taught by Pitt, in avoiding corrupted or lost data
`or other harmful changes in updating databases or transmitting data to or
`from the device being shut down. Id. at 54 (quoting Ex. 1007, 3:17–23).
`Petitioner additionally points out that one specific task identified in Hamner
`is rebooting devices, which an ordinarily skilled artisan would have
`recognized as benefitting from Pitt’s disclosure. Id. at 54–55.
`In its Preliminary Response, Patent Owner does not argue that either
`Hamner or Pitt fails to teach the recited determining an order of operations
`step or that Pitt’s teachings cannot be combined with those of Hamner and
`Matheny. On this record, we are persuaded by Petitioner that at least the
`combination of Hamner and Pitt teaches the determining an order of
`operations step and that an ordinarily skilled artisan would have had reason
`to combine the teachings of Pitt with those of Matheny and Hamner, as
`suggested by Petitioner. Therefore, at this preliminary stage, we need not
`determine whether Hamner’s tasks alone teach the determining an order of
`operations step.
`On this record, and for the reasons discussed above, we are persuaded
`that Petitioner has shown a reasonable likelihood of prevailing in
`demonstrating that claims 1 and 21 would have been unpatentable over
`Matheny, Harold, Hamner, and Pitt.
`
`19
`
`

`
`IPR2015-00631
`Patent 7,39

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket