ServiceNow, Inc.v.Hewlett-Packard CompanyDownload PDFPatent Trial and Appeal BoardAug 20, 201511327745 (P.T.A.B. Aug. 20, 2015) Copy Citation Trials@uspto.gov Paper 12 571-272-7822 Entered: August 20, 2015 UNITED STATES PATENT AND TRADEMARK OFFICE ____________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ____________ SERVICENOW, INC., Petitioner, v. HEWLETT-PACKARD COMPANY, Patent Owner. ____________ Case IPR2015-00699 Patent 7,610,512 B2 ____________ Before RAMA G. ELLURU, JAMES B. ARPIN, and JO-ANNE M. KOKOSKI, Administrative Patent Judges. KOKOSKI, Administrative Patent Judge. DECISION Denying Institution of Inter Partes Review 37 C.F.R. § 42.108 IPR2015-00699 Patent 7,610,512 B2 2 I. INTRODUCTION ServiceNow, Inc. (“Petitioner”) filed a Petition (“Pet.”) to institute an inter partes review of claims 1–5 and 7 of U.S. Patent No. 7,610,512 B2 (“the ’512 patent,” Ex. 1001). Paper 1. Hewlett-Packard Company (“Patent Owner”) filed a Preliminary Response (“Prelim. Resp.”). Paper 11. We have jurisdiction under 35 U.S.C. § 314. Upon consideration of the Petition and Preliminary Response and the evidence of record, we determine that Petitioner has not established a reasonable likelihood of prevailing with respect to any of the challenged claims of the ’512 patent. Accordingly, we deny the Petition and do not institute an inter partes review. A. Related Proceedings The parties indicate that the ’512 patent is involved in a district court action, in which Petitioner is a party, captioned Hewlett-Packard Co. v. ServiceNow, Inc., Case No. 14-CV-00570-BLF (N.D. Cal.). Pet. 1; Paper 4, 2. Patent Owner also states that the District Court granted Petitioner’s motion for summary judgment of invalidity under 35 U.S.C. § 101 for claims 1, 3, 4, 5, and 7 of the ’512 patent. Prelim. Resp. 33; Ex. 2001, 1. B. The ’512 Patent The ’512 patent, titled “System and Method for Automated and Assisted Resolution of IT Incidents,” is directed to managing and resolving Information Technology (“IT”) incidents related to IT infrastructure. Ex. 1001, 1:7–10. According to the ’512 patent, the described system and method “facilitates resolution of IT incidents by creating repair workflows, storing the repair workflows in a repair workflow repository, and/or IPR2015-00699 Patent 7,610,512 B2 3 subsequently executing the repair workflows in the repair workflow repository.” Id. at 2:31–35. Figure 2 of the ’512 patent is reproduced below: Figure 2 is a block diagram of a system for the automated and assisted resolution of IT incidents as described in the ’512 patent. Id. at 1:58–60. Repair workflows are created at authoring module 202 by defining steps and connecting the steps with transitions. Id. at 5:35–38. Authoring module 202 also creates endpoints for the workflow, such as ERROR, RESOLVED, DIAGNOSED, and NO ACTION TAKEN. Id. at 5:46–50. Flow repository 204 stores and manages the repair workflows created by authoring module 202 by assigning workflows to a hierarchy of folders. Id. at 5:51–55. Flow repository 204 can name, rename, edit, export, import, and delete repair workflows, and also enables a client device to search for repair workflows. Id. at 5:55–59. Repair orchestration module 206 executes the repair workflows by executing the code attached within the operations and transitions in the repair workflows, and “maintains the record details of the execution of repair workflows.” Id. at 5:66–6:2, 6:11–13. IPR2015-00699 Patent 7,610,512 B2 4 Remote action module 208 provides remote actions, such as scripts or code snippets, which are executed on a remote device. Id. at 6:14–17. Repair workflows can be invoked manually using manual interface 210, which guides a user through the execution of the repair workflows. Id. at 6:38–40. Manual interface 210 also provides an interface for searching for a repair workflow in flow repository 204. Id. at 6:61–62. Programmatic interface 212 automatically invokes the execution of repair workflows. Id. at 7:7–8. Repair history and reporting module 214 stores the execution data and provides reports related to various parameters in an enterprise network, such as success rate of a repair workflow and average mean time to repair. Id. at 7:19–28. C. Illustrative Claims Petitioner challenges claims 1–5 and 7 of the ’512 patent. Claims 1 and 7 are independent claims. Claims 2–5 depend, directly or indirectly, from claim 1, which is reproduced below, as is independent claim 7: 1. A computer implemented method for resolving an information technology (IT) incident, comprising: loading a repair workflow having a plurality of steps and transitions between the steps, defined to repair the IT incident on a computing device, each of the steps having one or more inputs, processing logic for the input(s) and one or more outputs; creating a repair frame for the loaded repair workflow on the computing device; creating a repair context for the repair frame on the computing device, and populating the repair frame with configuration data; binding one or more data values to the one or more inputs of the step within the repair context; executing the step’s operation; IPR2015-00699 Patent 7,610,512 B2 5 extracting the one or more outputs of step within the context; and selecting a transition to transition to another step within the context, based at least in part of the extracted one or more outputs. Ex. 1001, 12:64–13:19. 7. An apparatus comprising: a storage medium having a plurality of programming instructions stored in the storage medium, and adapted to enable the apparatus to perform a method; and one or more processors coupled to the storage medium to execute the programming instructions; wherein the method comprises: loading a repair workflow having a plurality of steps and transitions between the steps, defined to repair the IT incident on a computing device, each of the steps having one or more inputs, processing logic for the input(s) and one or more outputs; creating a repair frame for the loaded repair workflow on the computing device; creating a repair context for the repair frame on the computing device, and populating the repair frame with configuration data; binding one or more data values to the one or more inputs of one of the steps within the repair context; processing the bound data values of the one or more inputs of the step within the repair context; executing the step’s operation; extracting the one or more outputs of step within the context; and IPR2015-00699 Patent 7,610,512 B2 6 selecting a transition to transition to another step within the context, based at least in part on the extracted one or more outputs. Id. at 14:5–31. D. Applied References Petitioner applies the following references in its asserted grounds: Name Description Date Exhibit No. Bapat U.S. 6,038,563 Mar. 14, 2000 1007 Balabhadrapatruni Provisional U.S. Provisional App. No. 60/289617 May 8, 2001 1004 Balabhadrapatruni U.S. Patent App. Pub. No. US2002/0178252 A1 Nov. 28, 2002 1003 Tyma Java ™ Primer Plus 1996 1006 Rinehart Enterprise JavaBeans for Dummies © 2002 1005 E. The Asserted Grounds of Unpatentability Petitioner challenges the patentability of claims 1–5 and 7 of the ’512 patent based on the following grounds: References Basis Claim(s) Challenged Balabhadrapatruni, Rinehart, and Tyma § 103(a) 1, 2, 4, 5, and 7 Balabhadrapatruni, Rinehart, Tyma, and Bapat § 103(a) 3 II. ANALYSIS A. Claim Interpretation We interpret claims of an unexpired patent using the “broadest reasonable construction in light of the specification of the patent in which IPR2015-00699 Patent 7,610,512 B2 7 [the claims] appear[].” 37 C.F.R. § 42.100(b). The Board, however, may not “construe claims during IPR so broadly that its constructions are unreasonable under general claim construction principles. . . . ‘[T]he protocol of giving claims their broadest reasonable interpretation . . . does not include giving claims a legally incorrect interpretation.’” Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1298 (citation omitted). “Rather, ‘claims should always be read in light of the specification and teaching in the underlying patent’” and “[e]ven under the broadest reasonable interpretation, the Board’s construction ‘cannot be divorced from the specification and the record evidence.’” Id. (citations omitted). For purposes of this Decision and based on the record before us, we make explicit the interpretation of the claim term “repair context,” as set forth in independent claims 1 and 7. “repair context” Petitioner argues that the term “repair context” should be interpreted to mean “data for managing execution of a workflow.” Pet. 15. Petitioner notes that the Specification does not define “repair context,” but argues that “the steps of the claims reciting a ‘repair context’ appear to correspond to statements in the specification describing a ‘run context.’” Id. at 15–16. Petitioner argues that the Specification also “does not explicitly define ‘run context,’ but rather, defines it by reference [to] some of its functions and capabilities.” Id. at 16. According to Petitioner, the Specification “appears to describe” run context “as a collection of information used in managing execution of the workflow.” Id. at 17. Patent Owner contends that “repair context” should be interpreted as follows: IPR2015-00699 Patent 7,610,512 B2 8 A set of key-value pairs containing data values discovered during a repair run can be pushed into a repair context. The subsequent steps of the repair run use the data values stored in the repair context. Prelim. Resp. 8–9. Patent Owner bases this proposed interpretation on the Specification’s definition of “run context.” Id. at 9. Patent Owner states that the patentee, during prosecution of the ’512 patent, “explained that a ‘repair context’ is the same thing as a ‘run context,’” and, therefore, the terms are used interchangeably. Id. Patent Owner contends that, because all computer programs use data, Petitioner’s proposed interpretation “effectively renders this claim term meaningless in the context of a computer workflow system.” Id. at 11. With respect to claim interpretation, “[u]sually [the specification] is dispositive; it is the single best guide to the meaning of a disputed term.” In re Abbott Diabetes Care Inc., 696 F.3d 1142, 1149 (Fed. Cir. 2012) (citations omitted). Claim terms should generally be given their ordinary and customary meaning, except “1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of a claim term either in the specification or during prosecution.” Thorner v. Sony Computer Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012). “To act as its own lexicographer, a patentee must ‘clearly set forth a definition of the disputed claim term’ other than its plain and ordinary meaning.” Id. (quoting CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002)). As recognized by both Petitioner and Patent Owner, the Specification provides a definition of the term “run context,” which both parties recognize is used consistently (or interchangeably) with the term “repair context” in IPR2015-00699 Patent 7,610,512 B2 9 the ’512 patent. See Pet. 16; Prelim. Resp. 9; Ex. 1001, 3:22–28. As an initial matter, we are persuaded that the Specification uses the terms “run context” and “repair context” interchangeably. In particular, based on our review of the parties’ respective positions and the Specification, we are persuaded that Patent Owner acted as its own lexicographer by defining “run context” (and thus, “repair context”) in the Specification. The Specification defines “run context” by stating that “[a] set of key-value pairs containing data values discovered during a repair run can be pushed into a run context.” Ex. 1001, 3:22–24 (emphasis added). The Specification further states that the “subsequent steps of the repair use the data values stored in the run context.” Id. at 3:24–25 (emphasis added). Petitioner’s proposed interpretation, however, sidesteps the Specification’s definition and urges a broader definition based on its contention that the Specification “describes what a ‘run context’ can do, or what information can be pushed into it, but does not say what it actually is.” Pet. 16. As set forth above, we disagree with Petitioner that the Specification does not provide a definition of “run context.” Based upon this record, we are persuaded that Patent Owner acted as its own lexicographer and defined “run context,” and, therefore, defined “repair context,” as “storage for data values discovered during a repair run.” B. Obviousness over Balabhadrapatruni, Rinehart, and Tyma Petitioner contends that claims 1, 2, 4, 5, and 7 would have been obvious under 35 U.S.C. § 103(a) over the combination of Balabhadrapatruni, Rinehart, and Tyma. Pet. 19–54. Petitioner relies on a Declaration by Arthur T. Brody, Ph.D. (“the Brody Declaration,” Ex. 1002) in support of its contentions. Id. IPR2015-00699 Patent 7,610,512 B2 10 1. Overview of Balabhadrapatruni Balabhadrapatruni is directed to “a system for provisioning services over a network which includes an executable element generator operable to generate executable scripts recognized across an execution environment.” Ex. 1003 ¶ 7. Balabhadrapatruni describes a service provisioning engine that may use a workflow manager to provide services in “an automated, modular manner.” Id. ¶ 8. According to Balabhadrapatruni, a workflow is defined to correspond to a specific service request using executable scripts called workflow definition files, and “includes a series of tasks executed according to the sequence, conditions, and states specified by the workflow.” Id. Task definition files incorporated into the workflow definition files include additional executable scripts that define each task. Id. Balabhadrapatruni describes an embodiment that includes a workflow manager. Id. ¶¶ 42–46. In the embodiment, a workflow manager reads executable scripts that include workflow definition files, task definition files, and workflow configuration files, and directs a workflow engine to execute the scripts to complete a provisioning request. Id. ¶ 42. Balabhadrapatruni states that the workflow engine invokes the task definition files in a specific order, such that the output of one task can be the input to the next task. Id. ¶ 44. Balabhadrapatruni also states that “[f]ault detection and correction states may be defined to ascertain success or failure of a provisioning request,” or portion thereof. Id. ¶ 45. According to Balabhadrapatruni, the workflow definition files, task definition files, and workflow configuration files “may be implemented as XML files,” and “[t]he workflow manager may be implemented as a session bean in an enterprise Javabeans (EJB) container.” Id. ¶ 46. IPR2015-00699 Patent 7,610,512 B2 11 2. Overview of Rinehart Rinehart is a reference book directed to Enterprise JavaBean technology. Ex. 1005. Rinehart includes chapters that describe Enterprise JavaBean architecture (id. at 20–31), and how to define elements and descriptors in an application’s structure (id. at 32–48). 3. Overview of Tyma Tyma is a text book directed to the Java programming language. Ex. 1006. Tyma includes chapters that describe designing methods in Java (id. at 20–42), defining exceptions and debugging programs (id. at 43–61), and how to use data structures (id. at 62–102). 4. Analysis Petitioner contends that the combination of Balabhadrapatruni, Tyma, and Rinehart teaches all of the limitations of independent claims 1 and 7. Pet. 23–49, 52–54. For example, Petitioner contends that Balabhadrapatruni discloses the “creating a repair context for the repair frame on the computing device” limitation that appears in both claims 1 and 7 because it describes a workflow manager, a workflow engine, and executable scripts that “comprise computer data (including data files and scripts) that work together for ‘managing execution of a repair workflow.’” Id. at 37. Specifically, Petitioner relies on Balabhadrapatruni’s description of the embodiment shown in Figure 6 as disclosing the “creating a repair context for the repair frame on the computing device” limitation: In a particular embodiment, shown in FIG. 6, a workflow manager is employed. Referring to FIG. 6, the service provisioning engine 22 includes a workflow manager 70 and a workflow engine 72. The executable scripts further include workflow definition files 74, task definition files 76, and workflow configuration files 78. The workflow manager 70 IPR2015-00699 Patent 7,610,512 B2 12 reads the executable scripts, and directs the workflow engine 72 to execute the executable scripts to complete a provisioning request 82 for a particular provisioning object 80 on the LBAN 16. Id. at 36–37 (citing Ex. 1003 ¶ 42). Patent Owner argues that Balabhadrapatruni does not meet the “creating a repair context on the computing device” limitation because the workflow manager, workflow engine, and executable scripts are not “capable of being populated with key-value pairs containing data values discovered during execution of a repair workflow, as required by” Patent Owner’s proposed interpretation of “repair context.” Prelim. Resp. 30. We are not persuaded by Petitioner’s arguments. As set forth above, we interpret “repair context” to mean “storage for data values discovered during a repair run.” See supra Section II.A. Petitioner does not direct us to, nor do we discern, anything in Balabhadrapatruni that stores data values discovered during a repair run (which the Specification defines as “an execution of a repair workflow” (Ex. 1001, 3:21)). The teachings in Balabhadrapatruni, upon which Petitioner relies, generally describe the use of a workflow manager in executing a response to a provisioning request (see Ex. 1001 ¶¶ 42–46), but do not describe the step of creating storage for data values discovered during the execution of the described workflow. Petitioner does not rely upon Rinehart or Tyma to teach this limitation. Consequently, we are not persuaded that Petitioner has demonstrated that the combination of Balabhadrapatruni, Rinehart, and Tyma teaches the “creating a repair context for the repair frame on the computing device” limitation of claims 1 and 7. IPR2015-00699 Patent 7,610,512 B2 13 Accordingly, we are not persuaded that Petitioner has established a reasonable likelihood of showing that independent claim 1 and claims 2, 4, and 5 that depend therefrom, and independent claim 7, would have been obvious over the combination of Balabhadrapatruni, Rinehart, and Tyma. C. Obviousness over Balabhadrapatruni, Rinehart, Tyma, and Bapat Petitioner contends that claim 3 would have been obvious under 35 U.S.C. § 103(a) over the combination of Balabhadrapatruni, Rinehart, Tyma, and Bapat. Pet. 54–58. Petitioner relies on the Brody Declaration in support of its contentions. Id. Claim 3 depends from claim 1, via intervening claim 2, and further recites “receiving from a requestor a request to resolve an IT incident, determining whether the user has requestor [the] requisite authority to make the request, and rejecting the request if the requestor is determined not to have the requisite authority to make the request.” Ex. 1001, 13:22–27. As set forth above, we are not persuaded that Petitioner has demonstrated that the combination of Balabhadrapatruni, Rinehart, and Tyma teaches the “creating a repair context for the repair frame on the computing device” limitation of claim 1. Petitioner does not rely on Bapat to cure this deficiency in the combination of Balabhadrapatruni, Rinehart, and Tyma. Accordingly, we are not persuaded that Petitioner has established a reasonable likelihood of showing that claim 3 would have been obvious over the combination of Balabhadrapatruni, Rinehart, Tyma, and Bapat. IPR2015-00699 Patent 7,610,512 B2 14 III. CONCLUSION For the foregoing reasons, we are not persuaded that Petitioner has demonstrated a reasonable likelihood that at least one of the challenged claims of the ’512 patent is unpatentable based on the asserted grounds. IV. ORDER In consideration of the foregoing, it is hereby: ORDERED that the Petition is denied. PETITIONER: Heidi L. Keefe Andrew C. Mace Phillip E. Morton Mark Weinstein COOLEY LLP hkeefe@cooley.com amace@cooley.com pmorton@cooley.com mweinstein@cooley.com PATENT OWNER: Joseph J. Haag Jason D. Kipnis WILMER CUTLER PICKERING HALE AND DORR LLP Joseph.Haag@wilmerhale.com Jason.Kipnis@wilmerhale.com Copy with citationCopy as parenthetical citation