Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300 
` 
`
` 
` 
`UNITED STATES PATENT AND TRADEMARK OFFICE 
` 
` 
` 
` 
`BEFORE THE PATENT TRIAL AND APPEAL BOARD 
` 
` 
` 
` 
` 
`ServiceNow, Inc. 
`Petitioner 
` 
`v. 
` 
`Hewlett‐Packard Company 
`Patent Owner 
` 
`U.S. Patent No. 7,392,300 
`Filing Date: January 8, 2004 
`Issue Date: June 24, 2008 
` 
`TITLE: METHOD AND SYSTEM FOR MODELLING A COMMUNICATIONS NETWORK 
` 
` 
`PETITION FOR INTER PARTES REVIEW 
`OF U.S. PATENT NO. 7,392,300 
` 
` 
`Inter Partes Review No. 2015‐00631 
` 
`
` 
`
`  
`
`

`

`Table of Contents 
` 
`
`Page 
`
` 
`I. 
`
`II. 
`III. 
`
`MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1) .................................. 1 
`A. 
`Real Party‐ln‐lnterest under 37 C.F.R. § 42.8(b)(1) ............................. 1 
`B. 
`Related Matters under 37 C.F.R. § 42.8(b)(2) ..................................... 1 
`Lead and Back‐Up Counsel under 37 C.F.R. § 42.8(b)(3) .................... 1 
`C. 
`D. 
`Service Information ............................................................................ 2 
`E. 
`Power of Attorney .............................................................................. 2 
`PAYMENT OF FEES ‐ 37 C.F.R. § 42.103 ........................................................ 2 
`REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. 
`§§ 42.104 AND 42.108 .................................................................................. 2 
`A. 
`Grounds for Standing under 37 C.F.R. § 42.104(a) ............................. 2 
`Identification of Challenge under 37 C.F.R. § 42.104(b) and 
`B. 
`Statement of Precise Relief Requested .............................................. 3 
`Requirements for Inter Partes Review 37 C.F.R. § 42.108(c) .............. 4 
`C. 
`BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY ........................... 4 
`A. 
`Computer Networks and Network Management Systems ................. 5 
`Structured Data and the eXtensible Markup Language (XML) ........... 7 
`B. 
`SUMMARY OF THE CLAIMED SUBJECT MATTER ........................................... 9 
`A. 
`The Specification of the ’300 Patent ................................................... 9 
`B. 
`The Challenged Claims of the ’300 Patent ........................................ 11 
`CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3) ............................ 13 
`A. 
`“network representation” ................................................................ 13 
`“network model” .............................................................................. 15 
`B. 
`C. 
`“network event” ............................................................................... 16 
`VII.  CLAIMS 1, 7, 8, 10, 21 AND 22 OF THE ’300 PATENT ARE 
`UNPATENTABLE .......................................................................................... 17 
`
`IV. 
`
`V. 
`
`VI. 
`
` 
`
` 
`
`‐i‐
`
`

`

`Table of Contents 
`(continued) 
`
`Page 
`
`b. 
`c. 
`
`Ground 1 – Claims 1, 7, 8, 10, 21 and 22 Are Obvious Over 
`Matheny in View of XML in a Nutshell, Hamner and Arrouye .......... 20 
`1. 
`Prior Art and Date Qualification for Ground 1 ........................ 20 
`Brief Summary of the Prior Art Applied in Ground 1 .............. 20 
`2. 
`3. 
`Claim 1 .................................................................................... 23 
`a. 
`“generating a network representation using 
`computer‐readable code, the computer‐readable 
`code representing structured information" ................. 23 
`“parsing the network representation” ......................... 26 
`“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” ........................................................................ 30 
`“storing the network model in memory” ..................... 32 
`“processing a network event using the network 
`model, wherein the processing includes 
`identifying one or more network objects of the 
`plurality of network objects…” ..................................... 33 
`“…and the processing further includes 
`determining an order of operation on the one or 
`more network objects” ................................................ 41 
`Claim 7 .................................................................................... 46 
`4. 
`Claim 8 .................................................................................... 46 
`5. 
`Claim 10 .................................................................................. 47 
`6. 
`Claim 21 .................................................................................. 49 
`7. 
`Claim 22 .................................................................................. 50 
`8. 
`Ground 2 – Claims 1, 7, 8, 10, 21 and 22 Are Obvious Over 
`Matheny in view of XML in a Nutshell, Hamner and Pitt .................. 51 
`‐ii‐
`
`d. 
`e. 
`
`f. 
`
` 
`
`A. 
`
`B. 
`
` 
`
` 
`
`

`

`Table of Contents 
`(continued) 
`
`Page 
`
` 
`VIII.  CONCLUSION .............................................................................................. 55 
`
` 
`
` 
`
`‐iii‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300 
`
`
`
`Ex. No 
`
`List of Exhibits 
`
`Description of Document 
`
`1001 
`
`U.S. Patent No. 7,392,300 to  Raghu Anantharangachar et al. 
`
`1002 
`
`Declaration of Tal Lavian, Ph.D. 
`
`1003 
`
`1004 
`
`1005 
`
`1006 
`
`1007 
`
`1008 
`
`U.S. Patent App. Pub. No. 2002/0161883 to David Matheny et al. 
`
`Excerpts from Elliotte Rusty Harold et al., XML in a Nutshell (2001), 
`pages 3‐25 & xi‐xvi (Preface) 
`
`U.S. Patent No. 5,796,951 to John F. Hamner et al. 
`
`U.S. Patent No. 6,256,635 to Yan Arrouye et al. 
`
`U.S. Patent No. 5,717,934 to Ronald L. Pitt et al. 
`
`Excerpts from Microsoft Computer Dictionary (3d ed. 1997), 
`Microsoft Press, pages 422‐23 
`
` 
`
` 
`
`‐iv‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`Petitioner ServiceNow, Inc. (“Petitioner”) respectfully submits this Petition 
`
`for  Inter  Partes  Review  of  claims  1,  7,  8,  10,  21  and  22  of  U.S.  Patent  No. 
`
`7,392,300 [Ex. 1001] (“the ’300 patent”). 
`
`I.
`
`MANDATORY NOTICES UNDER 37 C.F.R. § 42.8(A)(1) 
`A.
`
`Real Party‐ln‐lnterest under 37 C.F.R. § 42.8(b)(1) 
`
`The Petitioner, ServiceNow, Inc. is the real party‐in‐interest. 
`
`B.
`
`Related Matters under 37 C.F.R. § 42.8(b)(2) 
`
`The  ’300  patent  is  the  subject  of  one  pending  litigation  involving  the 
`
`Petitioner: Hewlett‐Packard Company v. ServiceNow, Inc., Case No. 14‐CV‐00570 
`
`BLF  (N.D.  Cal.  Feb.  6,  2014),  in  which  the  patent  owner  contends  that  the 
`
`Petitioner infringes the claims of the ’300 patent challenged in this Petition.  
`
`Lead and Back‐Up Counsel under 37 C.F.R. § 42.8(b)(3) 
`
`C.
`Petitioner provides the following designation of counsel. 
` 
`
`LEAD COUNSEL 
`Heidi L. Keefe (Reg. No. 40,673) 
`hkeefe@cooley.com 
`zpatdcdocketing@cooley.com 
`COOLEY LLP 
`ATTN: Patent Group 
`1299 Pennsylvania Ave., NW, Suite 700 
`Washington, DC 20004 
`Tel: (650) 843‐5001  
`Fax: (650) 849‐7400  
`
`BACK‐UP COUNSEL 
`Andrew C. Mace (Reg. No. 63,342) 
`amace@cooley.com 
`zpatdcdocketing@cooley.com 
`COOLEY LLP 
`ATTN: Patent Group 
`1299 Pennsylvania Ave., NW, Suite 700 
`Washington, DC 20004 
`Tel: (650) 843‐5808  
`Fax: (650) 849‐7400  
`
` 
`
` 
`
`‐1‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`D.
`Service Information 
`
`This  Petition  is  being  served  by  FedEx  to  the  current  correspondence 
`
`address  for  the  ’300  patent,  HEWLETT‐PACKARD  COMPANY,  Intellectual  Property 
`
`Administration, 3404 E. Harmony Rd., Mail Stop 35, Fort Collins, CO 80528. The 
`
`Petitioner may be served at the addresses provided above for lead and back‐up 
`
`counsel, and consents to electronic service at those addresses. 
`
`E.
`
`Power of Attorney 
`
`Filed concurrently with this Petition in accordance with 37 C.F.R. § 42.10(b). 
`
`II.
`
`PAYMENT OF FEES ‐ 37 C.F.R. § 42.103 
`
`This  Petition  requests  review  of  six  (6)  claims  of  the  ’300  patent. 
`
`Accordingly,  a  payment  of  $23,000  is  submitted  herewith.  This  payment  is 
`
`calculated  based  on  a  $9,000  request  fee  (for  up  to  20  claims),  and  a  post‐
`
`institution  fee  of  $14,000  (for  up  to  15  claims).  See  37  C.F.R.  §  42.15(a).  This 
`
`Petition meets the fee requirements of 35 U.S.C. § 312(a)(1). 
`
`III.
`
`REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. §§ 42.104 AND 42.108  
`A.
`
`Grounds for Standing under 37 C.F.R. § 42.104(a) 
`
`The  Petitioner  certifies  that  the  ’300  patent  is  available  for  inter  partes 
`
`review  and  that  the  Petitioner  is  not  barred  or  otherwise  estopped  from 
`
`requesting inter partes review on the grounds identified in the present Petition.  
`
`The  Petitioner  is  unaware  of  any  previous  petition  for  inter  partes  review  with 
`
`respect to the ’300 patent. 
` 
`
` 
`
`‐2‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`B.
`Identification of Challenge under 37 C.F.R. § 42.104(b) and 
`Statement of Precise Relief Requested 
`
`The  Petitioner  respectfully  requests  that  the  Board  initiate  inter  partes 
`
`review of claims 1, 7, 8, 10, 21 and 22. This Petition cites the following prior art 
`
`references, included as Exhibits 1003 through 1007: 
` 
`Ex. No. 
`
`Description of Document 
`
`1003  U.S. Patent App. Pub. No. 2002/0161883 to David Matheny et al., 
`published on October 31, 2002 
`Elliotte Rusty Harold et al., XML in a Nutshell (2001) 
`1004 
`1005  U.S. Patent No. 5,796,951 to John F. Hamner et al., filed on December 
`22, 1995 and issuing on August 18, 1998 
`1006  U.S. Patent No. 6,256,635 to Yan Arrouye et al., filed on May 8, 1998 
`and issuing on July 3, 2001 
`1007  U.S. Patent No. 5,717,934 to Ronald L. Pitt et al., filed on October 28, 
`1994 and issuing on February 10, 1998 
`
`The  references  listed  above  qualify  as  prior  art  under  at  least  35  U.S.C  § 
`
`102(b)  (pre‐AIA)  because  each  reference  was  published  more  than  one  year 
`
`before  January  8,  2004,  the  filing  date  of  the  earliest  application  on  the  ’300 
`
`patent.  The grounds on which this Petition is based are listed in the table below. 
` 
`Ground 
`
`Basis for Challenge 
`
`Claims 
`
`1 
`
`2 
`
`1, 7, 8, 10, 
`21, 22 
`1, 7, 8, 10, 
`21, 22 
`
`Unpatentable over Matheny in view of XML in a Nutshell, 
`Hamner and Arrouye, under 35 U.S.C. § 103(a) 
`Unpatentable over Matheny in view of XML in a Nutshell, 
`Hamner and Pitt, under 35 U.S.C. § 103(a) 
`
` 
`
` 
`
`‐3‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`Part VII below provides a detailed explanation as to why each challenged 
`
`claim is unpatentable based on the two grounds identified above.  Part VII also 
`
`explains why the Board should institute IPR on both of these grounds as neither of 
`
`them is “redundant” of the other. 
`
`This  Petition  also  cites  additional  prior  art  materials  for  purposes  of 
`
`providing a technology background and describing the state of the art at the time 
`
`of  the  alleged  invention.  These  materials  are  also  cited  in  the  accompanying 
`
`Declaration of Tal Lavian, Ph.D. (“Lavian Decl.”) [Ex. 1002], a technical expert with 
`
`more than 25 years of technical experience in the networking, communications, 
`
`Internet, and software fields.  (Lavian Decl., Ex. 1002, ¶¶ 7‐15.) 
`
`C.
`
`Requirements for Inter Partes Review 37 C.F.R. § 42.108(c) 
`
`The Board should institute inter partes review of claims 1, 7, 8, 10, 21 and 
`
`22  because  this  Petition  establishes  a  reasonable  likelihood  of  prevailing  with 
`
`respect  to  each  challenged  claim.    Each  limitation  of  each  challenged  claim  is 
`
`disclosed and/or suggested by the prior art, as explained in detail in Part VII. 
`
`IV.
`
`BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY 
`
`The 
`
`’300  patent,  entitled  “Method  and  System 
`
`for  Modelling  a 
`
`Communications  Network,”  discloses  a  technique  for  generating  a  model  of  a 
`
`computer network.  (’300, Ex. 1001, Abstract, 1:39‐48.)  Dr. Lavian’s declaration 
`
` 
`
` 
`
`‐4‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`provides a detailed description of the underlying technology pertinent to the ’300 
`
`patent.  (Lavian Decl., Ex. 1002, ¶¶ 18‐38.)  A summary of that discussion is below. 
`
`A.
`
`Computer Networks and Network Management Systems 
`
`Most  computer  users  today  are  familiar  with  the  basic  idea  behind  a 
`
`computer network.  A computer network is a group of computing devices (often 
`
`called “nodes”) connected to each other.  These nodes communicate with each 
`
`other over a communications medium such as a wired connection.  (Id. ¶ 23.) 
`
`Computer networks come in many different varieties.  The term “local area 
`
`network”  or  “LAN”  typically  refers  to  a  network  having  nodes  restricted  to  a 
`
`limited  area,  such  as  an  office  building.    On  the  other  end  of  the  spectrum,  a 
`
`“wide area network” or “WAN,” as its name implies, typically includes nodes that 
`
`are connected over a much larger area, such as a large geographic region or even 
`
`across international borders.  Many often regard the “Internet” as an example of 
`
`a very large and worldwide wide area network.  (Id. ¶ 24.) 
`
`Regardless of the type of network, as the network grows and the number of 
`
`devices connected to it increases, there is a corresponding increase in the need 
`
`for  software  tools  to  monitor  and  manage  the  network  and  the  computing 
`
`devices  connected  to  it.    An  entire  industry,  often  referred  to  as  “network 
`
`management,”  grew  out  of  this  need  and  was  firmly  in  place  by  January  2004.  
`
`Network  management  tools  allow  administrators  and  other  persons  to,  among 
` 
`‐5‐
`
` 
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`other  things,  identify  and  configure  devices  on  the  network,  monitor  their 
`
`performance,  and  in  some  cases,  create  graphical  displays  to  visualize  the 
`
`network devices and their interconnections.  (Id. ¶¶ 26‐27.) 
`
`By  the  1990s,  almost  all  network  equipment  vendors  provided  network 
`
`management  tools  to  configure  and  manage  their  equipment;  some  vendors 
`
`offered  several  management  tools  to  manage  different  product  lines.    For 
`
`example, Cisco Systems, Nortel Networks and others offered such tools.  Network 
`
`operators and service providers used these tools in a large scale to configure and 
`
`monitor their networks and the devices connected to them.  (Id. ¶¶ 27‐28.) 
`
`The ’300 patent acknowledges that network management tools existed in 
`
`the prior art.  As explained in the Background: “A variety of software products and 
`
`applications currently exist to facilitate network development, management, and 
`
`maintenance.”  (’300, 1:28‐30.)  One example of such a system is disclosed in U.S. 
`
`Patent  No.  5,796,951  to  John  F.  Hamner  (“Hamner”)  [Ex.  1005],  which  issued 
`
`from  an  application  filed  in  December  1995,  more  than  eight  years  before  the 
`
`filing of the application for the ’300 patent.  Hamner explains that “as users place 
`
`more  reliance  upon  computer  networks,”  those  users  “also  demand  more 
`
`sophisticated  capabilities  for  managing  these  networks.    Various  different 
`
`software packages exist for providing users with such capabilities.”  (Hamner, Ex. 
`
`1005,  1:20‐24.)    Hamner  purports  to  provide  such  a  system  that  provides  a 
` 
`‐6‐
`
` 
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`network “Management Console” shown in Figure 2A (shown at right) that lists the 
`
`devices on the network and the tasks that can be performed on the devices.  A 
`
`device window (201) on the left lists the devices on the network organized based 
`
`on the group to which they belong (e.g. the “PC” device group (205)).  (Hamner, 
`
`4:3‐16.)  The network devices are displayed in a “tree hierarchy” that allows the 
`
`user to click on a particular device group, such as the “PC” device group (205), to 
`
`view all of the devices that fall within the 
`
`selected  group.    (Hamner,  4:10‐16.)    The 
`
`right  side  of  Figure  2A  includes  a  task 
`
`window  (202)  that  displays  tasks  and 
`
`categories of network management tasks 
`
`that  can  be  performed  on  a  network 
`
`device.    (Hamner,  4:18‐32.)    “The  user  can  cause  any  displayed  task  to  be 
`
`performed upon a device.”  (Hamner, 4:33‐34.)  
`
`B.
`
`Structured Data and the eXtensible Markup Language (XML) 
`
`Another  concept  mentioned  in  the  ’300  patent  is  the  use  of  “structured 
`
`information,”  such  as  information  represented  using  the  eXtensible  Mark‐up 
`
`Language  (XML).    (Lavian  Decl.,  Ex.  1002,  ¶¶  33.)    One  of  the  steps  of  the 
`
`challenged claims involves generating “structured information” (such as XML) to 
`
`describe objects in the network.  (’300, Ex. 1001, 3:63‐4:10, 9:43‐45 (claim 1).)   
` 
`‐7‐
`
` 
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`The  term  “structured  information”  generally  refers  to  refers  to  data  that 
`
`follows a specific organizational model, such as information stored in a relational 
`
`database according to a specific schema that specifies how the data is stored and 
`
`how  data  elements  relate  to  each  other.    (Lavian  Decl.,  Ex.  1001,  ¶  34.)    An 
`
`example  of  “structured  information”  described  in  the  ’300  patent  is  eXtensible 
`
`Markup Language or “XML.”  XML generally refers to an industry‐standard set of 
`
`rules for encoding information.  As explained in Elliotte Rusty Harold et al., XML in 
`
`a Nutshell (2001) (“XML in a Nutshell”) [Ex. 1004], XML “defines a generic syntax 
`
`used to mark up data with simple, human‐readable tags.”  (XML in a Nutshell, Ex. 
`
`1004, at 3.)  XML also “provides a standard format for computer documents,” and 
`
`“is  flexible  enough  to  be  customized  for  domains  as  diverse  as  web  sites, 
`
`electronic data interchange, vector graphics, genealogy, real‐estate listings, object 
`
`serialization, remote procedure calls and voice‐mail systems.”  (Id.; Lavian Decl. 
`
`¶¶ 35‐37 (describing and providing example uses of XML).) 
`
`XML is an industry standard for encoding information and is widely used for 
`
`sharing information between computer systems and application programs.  (XML 
`
`in a Nutshell, at 6.)  As explained in XML in a Nutshell, “XML is one of the most 
`
`important  developments  in  document  syntax  in  the  history  of  computing,”  and 
`
`had “become the syntax of choice for newly designed document formats across 
`
`almost all computer applications.”  (Id. at Preface, xi.)   
` 
`‐8‐
`
` 
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`V.
`SUMMARY OF THE CLAIMED SUBJECT MATTER 
`A.
`
`The Specification of the ’300 Patent 
`
`The 
`
`’300  patent,  entitled  “Method  and  System 
`
`for  Modelling  a 
`
`Communications Network,” describes a computer‐based technique for creating a 
`
`model of a communications network that identifies objects in the network (e.g. 
`
`devices)  and  the  relationships  between  them.    According  to  the  specification, 
`
`“[t]he communications network modeled may be any type of network such as, for 
`
`example, a local area network, wide area network, virtual private network, or any 
`
`other suitable network configuration.”  (’300, Ex. 1001, 2:37‐41.)   
`
`The  process  of  modeling  a  communications  network  is  summarized  in 
`
`Figure 5.  In the first step, the system generates what the patent calls a “network 
`
`representation” or a “network inventory” that holds information about objects 
`
`on  the  network.    (’300,  Fig.  5  (step  200),  6:34‐35,  3:63‐4:2.)    These  network 
`
`objects may include, for example, “computers, terminals, servers, storage devices, 
`
`database,  routers,  switches,  printers,  communications  lines,  circuits,  and  other 
`
`telecommunications  media  and  devices.” 
`
`  (’300,  4:3‐6.) 
`
`  “The  network 
`
`representation  may  be  generated  automatically  by  a  computer  application  or 
`
`manually  by  a  user  of  the  system.    The  network  representation  may  include  a 
`
`representation of objects in the network and their relationships.”  (’300, 6:40‐44.)   
`
` 
`
` 
`
`‐9‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`The  “network  representation”  may  be  created  using  eXtensible  Markup 
`
`Language  (XML)  or  some  other  form  of  computer‐readable  “structured 
`
`information.”  (’300, Abstract, 3:34‐37, 4:8‐10, 9:18‐25.)  The specification states 
`
`that  using  XML  to  encode  the  network  representation  provides  a  “standards 
`
`compliant representation” that enables the customer to define and customize its 
`
`network model.  (’300, 3:34‐41.)  As explained in Part IV.B above, XML was well‐
`
`known and widely deployed prior to the filing of the ’300 patent. 
`
`The  second  step  of  the  process  (as  shown  Figure  5)  is  to  parse  the 
`
`generated  network  representation.    (’300,  Fig.  5  (step  202).)    The  specification 
`
`does not provide any specific detail about how the parsing step is carried out; it 
`
`simply  states  that  it  occurs.    (’300,  e.g.,  6:44‐45  (“In  step  202,  the  network 
`
`representation is parsed. The parsed network representation is used to generated 
`
`[sic] a network model, step 204.”), 1:44, 3:42‐45.)   
`
`Next,  the  parsed  network  representation  is  used  to  generate  a  “network 
`
`model.”    (’300,  Fig.  5  (step  203),  6:44‐46.)    The  network  model  includes  “a 
`
`plurality  of  network  objects  and  relationships  between  the  plurality  of  network 
`
`objects.”    (’300,  1:44‐46.)    “The  network  model  may  be  stored  in  memory  for 
`
`further use.”  (’300, 1:46‐47.) 
`
`The specification identifies at least two ways in which the system can use 
`
`the  generated  “network  model.”    First,  the  network  model  may  be  used  to 
` 
`‐10‐
`
` 
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`generate a graphical representation of the network.  (’300, Fig. 5 (step 206), 6:46‐
`
`49.)    Second,  the  network  model  may  be  used  to  process  a  “network  event.”  
`
`(’300, Fig. 5 (steps 210, 212, 214, 216), 6:49‐56.)  Processing a network event may 
`
`include  “determin[ing]  the  order  of  operations  needed  to  process  the  network 
`
`event,” and executing the event.  (’300, 6:53‐56, Fig. 5 (steps 216, 218).)   
`
`A  “network  event,”  according 
`
`to 
`
`the  specification,  may 
`
`include 
`
`“provisioning,  circuit  provisioning,  service  provisioning,  switch  provisioning, 
`
`rollback,  and  delete.”    (’300,  2:52‐55.)    As  explained  by  Dr.  Lavian,  the  term 
`
`“provisioning” to persons of ordinary skill in the art “generally refers to a process 
`
`of  making  a  network,  computing  device  or  other  resource  available  to  users.”  
`
`(Lavian  Decl.,  Ex.  1002,  ¶¶  44‐45.)    Provisioning  is  “a  broad  concept  that  can 
`
`involve,  among  other  things,  the  physical  and  software  configuration  of  the 
`
`devices  and  assigning  appropriate  permission  settings  to  users  who  will  access 
`
`them.”  (Id.) 
`
`B.
`
`The Challenged Claims of the ’300 Patent 
`
`This Petition addresses claims 1, 7, 8, 10, 21 and 22.  Of these six claims, 
`
`only three of them—claims 1, 10 and 21—are independent, and all three recite 
`
`similar subject matter.  Representative claims 1, 7 and 8 recite: 
`
`1.  
`
`A  method  of  modelling  a  communications  network  using  a 
`computer system, the method including: 
`
` 
`
` 
`
`‐11‐
`
`

`

`[b] 
`[c] 
`
`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`[a] 
`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. 
`
`[d] 
`[e] 
`
`7.  
`
`8. 
` 
`
` 
`
`A method according to claim 1 wherein the computer‐readable 
`code is in extensible mark‐up language (XML). 
`
`A method according to claim 1, further including: 
`generating  a  graphical  representation  of  the  network  model; 
`and 
`displaying the graphical representation on a display monitor. 
`
`(’300,  Ex.  1001,  9:41‐56  (claim  1),  10:11‐17  (claims  7  and  8).)    The  bracketed 
`
`notations shown in claim 1 (e.g. “[a],” “[b],” etc.) are used below to more easily 
`
`identify these claim limitations in the analysis in Part VII below. 
`
`The other three claims addressed in this Petition largely mirror claims 1, 7 
`
`and  8  listed  above.    Independent  claim  10  is  substantially  the  same  as  claim  1 
`
`except  that  the  first  step  recites  “generating  a  network  representation  in 
`
` 
`
` 
`
`‐12‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`extensible  mark‐up  language  (XML),”  incorporating  the  XML  requirement  from 
`
`claim  7.    Claims  21  and  22  are  “computer  program  product”  claims  that  have 
`
`substantially the same limitations as the steps of claims 1 and 8, respectively. 
`
`VI.
`
`CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3) 
`
`A  claim  subject  to  inter  partes  review  must  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).  As  the  Federal  Circuit  has  recognized,  the 
`
`“broadest reasonable construction” standard is fundamentally different from the 
`
`manner in which the scope of a claim is determined in litigation.  See, e.g., In re 
`
`Swanson, 540 F.3d 1368, 1377‐78 (Fed. Cir. 2008).  Accordingly, the constructions 
`
`proposed  in  this  Petition  represent  the  broadest  reasonable  interpretation  that 
`
`one  of  ordinary  skill  in  the  art  would  assign  to  the  terms  below,  and  not 
`
`necessarily the construction that would be appropriate in litigation. 
`
`A.
`
`“network representation” 
`
`The  broadest  reasonable  interpretation  of  “network  representation”  is 
`
`“information about at least one object in the network or its relationship to the 
`
`network.”  This construction flows from the specification of the ’300 patent: 
`In  one  embodiment,  the  network  representation  is  an 
`XML  document  but  may  be  created  and/or  stored  in 
`memory in any suitable format including, but not limited 
`to,  text,  markup  languages,  programming  languages, 
`
` 
`
` 
`
`‐13‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`database  languages,  graphical  representation,  and  any 
`other 
`computer‐readable 
`format. 
`The  network 
`representation  may  be  generated  automatically  by  a 
`computer  application  or  manually  by  a  user  of  the 
`system.  The  network  representation  may  include  a 
`representation  of  objects  in  the  network  and  their 
`relationships. 
`
`(’300, 6:35‐44 (underlining added).)  The specification also provides the following 
`
`list of examples of “network representation” information: 
`
`representation  may 
`The  communications  network 
`include,  but  is  not  limited  to,  one  or  more  of  the 
`following  elements  in  any  suitable  combination:  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. 
`
`(’300, 2:42‐48 (underlining added).) 
`
`The categories of  information identified in this  list confirm  that “network 
`
`representation”  information,  under  its  broadest  reasonable  construction,  is 
`
`satisfied  by  even  the  most  basic  information  about  a  network  object.    For 
`
`example,  a  “network  representation” 
`
`is  satisfied  by  simply  “circuit  type 
`
`identification” (id.) which simply identifies the type of connection and does not 
`
`necessarily indicate how that node is related to any other node.  (Lavian Decl. ¶ 
`
` 
`
` 
`
`‐14‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`51.)    This  indicates  that  information  about  “relationships”  between  objects, 
`
`although  encompassed  within  “network  representation”  information,  is  not 
`
`required by that term under its broadest reasonable construction. 
`
`In light of the list of exemplary “network representation” information, and 
`
`the  descriptions  above,  “network  representation”  should  be  interpreted  by  the 
`
`Board as “information about at least one object in the network or its relationship 
`
`to the network,” under its broadest reasonable construction. 
`
`B.
`
`“network model” 
`
`The specification and claims of the ’300 patent describe a process in which 
`
`a  “network  representation”  is  generated,  parsed,  and  then  used  to  generate  a 
`
`“network model.”  The Board should interpret “network model” as “information 
`
`about objects in the network and the relationships between them.” 
`
`This construction is supported by both the specification and claim language.  
`
`The specification explains that “[n]etwork models provide a representation of the 
`
`various  objects  that  are  modeled  in  the  network  inventory  and  also  the 
`
`relationships that exist between these objects.”  (’300, 3:20‐23.)  This is consistent 
`
`with  claim  1,  which  recites  the  step  of  “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.”    
`
` 
`
` 
`
`‐15‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`C.
`“network event” 
`
`The specification and claims of the ’300 patent state that once a “network 
`
`model” is generated, that model can be used to process a “network event.”  The 
`
`term  “network  event”  under  its  broadest  reasonable  construction  is  “one  or 
`
`more operations that can be performed on or by a network or network object.”   
`
`This interpretation derives from the specification, which lists provisioning a 
`
`network object or deleting it from the network as examples of network events: 
`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. However, any 
`other  desired  network  events  or  received  data  may  be 
`processed using the present invention.  
`
`(’300,  2:51‐57  (underlining  added).) 
`
`  As  Dr.  Lavian  explains,  the  term 
`
`“provisioning”  the  above‐quoted  passage  is  understood  by  persons  of  ordinary 
`
`skill in the art as broadly referring to the process of making a network, computing 
`
`device or other resource available to users of the network.  (Lavian Decl. ¶ 54.)  
`
`The specification further describes network events as follows: 
`
`In step 206, the system determines whether a graphical 
`representation of the network is to be generated. . .  If 
`no, then the system determines whether an event is to 
`be  processed,  step  210. . .    If  yes,  then  the  system 
`
` 
`
` 
`
`‐16‐
`
`

`

`Petition for Inter Partes Review of  
`U.S. Patent No. 7,392,300
` 
`
`identifies the needed objects in the network model, step 
`214.  In  step  216,  the  system  determines  the  order  of 
`operations needed to process the network event. In step 
`218, the system then executes the event as required. 
`
`(’300, 6:46‐56 (underlining added).)  Based on this description, “network event” 
`
`under its broadest reasonable construction should be interpreted as “one or more 
`
`operations that can be performed on or by a network or network object.” 
`
`VII. CLAIMS 1, 7, 8, 10, 21 AND 22 OF THE ’300 PATENT ARE UNPATENTABLE 
`
`This Petition identifies two grounds on which IPR should be instituted for 
`
`claims 1, 7, 8, 10, 21 and 22 of the ’300 patent: 
` 
`Ground 
`
`Claims 
`
`Basis for Challenge 
`
`1 
`
`2 
`
`1, 7, 8, 10, 
`21, 22 
`1, 7, 8, 10, 
`21, 22 
`
`Unpatentable over Matheny in view of XML in a Nutshell, 
`Hamner and Arrouye, under 35 U.S.C. § 103(a) 
`Unpatentable over Matheny in view of XML in a Nutshell, 
`Hamner and Pitt, under 35 U.S.C. § 103(a) 
`
`Grounds 1 and 2 rely primarily on Matheny and Hamner for the majority of 
`
`the claim limitations, and draw upon XML in a Nutshell, Arr