Paper 13
`Date: August 27, 2015
`
`
`
`
`
`
`
`Trials@uspto.gov
`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-00718
`Patent 8,224,683 B2
`_______________
`
`Before RAMA G. ELLURU, JO-ANNE M. KOKOSKI, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`MOORE, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`Date: August 27, 2015
`
`
`
`
`
`
`
`Trials@uspto.gov
`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-00718
`Patent 8,224,683 B2
`_______________
`
`Before RAMA G. ELLURU, JO-ANNE M. KOKOSKI, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`MOORE, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`I.
`INTRODUCTION
`ServiceNow, Inc. (“Petitioner”) filed a Petition to institute an inter
`partes review of claims 12, 32, and 35 (Paper 1; “Pet.”) of U.S. Patent No.
`8,224,683 B2 (Ex. 1001; “the ’683 Patent”). Hewlett-Packard Company
`(“Patent Owner”) waived its right to file a Preliminary Response. Paper 12.
`We have jurisdiction under 35 U.S.C. § 314(a),1 which provides that an inter
`partes review may not be instituted “unless . . . there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of the
`claims challenged in the petition.”
`On this record and for the reasons discussed below, we institute inter
`parties review as to claims 12, 32, and 35.
`
`II.
`BACKGROUND
`Related Proceedings
`A.
`The ’683 Patent is involved in concurrent district court litigation. On
`February 6, 2014, Patent Owner filed an action against Petitioner alleging
`infringement of the ’683 Patent, Hewlett-Packard Company v. ServiceNow,
`Inc., Case No. 14-CV-00570 BLF (N.D. Cal.). Pet. 1; Paper 12, 2.
`
`The ’683 Patent
`B.
`The ’683 Patent is generally directed to monitoring service tickets for
`information technology service providers to ensure that levels of service
`regarding problems identified by customers are met. Ex. 1001, 2:6–10. In
`
`
`1 See Section 6(a) of the Leahy-Smith America Invents Act (“AIA”), Pub.
`L. No. 112-29, 116 Stat. 284, 300 (2011).
`
` 2
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`one embodiment, a monitoring server inspects a service ticket stored in a
`database to determine a deadline for resolving a problem associated with the
`service ticket. Id. at 2:10–13. The server also determines a deadline
`approaching alert time, which is a time at which a help desk user will be
`notified that the deadline is approaching. Id. at 2:13–16. The server then
`alerts a help desk user when the deadline approaching alert time is reached.
`Id. at 2:16–19.
`Figure 1 of the ’683
`Patent illustrates an
`embodiment of the claimed
`subject matter. Figure 1 depicts
`an information technology
`customer service request level
`of service (“LOS”) monitoring
`system 100 that is used by an
`information technology (“IT”)
`provider in order to ensure that
`customer expectations set forth
`in an LOS agreement are met.
`Ex. 1001, 2:61–67.
`When customer 102
`determines that there is an IT
`problem, the customer calls IT help desk user 104, who opens a ticket in a
`database 106. Id. at 3:13–17. Server 108 runs a monitoring program (the
`
` 3
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`LOS WatchDog Server Program) that continuously checks for tickets that
`require attention. Id. at 3:20–24, 3:45–50. Client programs 110 and 112
`display a grid populated with tickets that have reached a specified
`percentage of time before their due date, and are used by customers and
`helpdesk users. See id. at 3:24–27, Fig. 1. When a ticket reaches a specified
`time limit (e.g., 75% of the LOS due date), an alert message window is
`displayed to helpdesk user 104. Id. at 3:34–39.
`
`
`
`Illustrative Claims
`C.
`Challenged claims 12 and 32 are independent, and challenged
`claim 35 depends from claim 32. Claims 12, 32, and 35 are
`reproduced below (bracketed references and some paragraphing
`added).
`
` 12. A computer program product in a non-transitory computer
`readable media for use in a data processing system for
`monitoring service tickets for information technology service
`providers to ensure that levels of service required to be
`provided to a customer pursuant to a contractual agreement
`between the customer and a service provider, are met, the
`computer program product comprising:
`[a] first instructions for inspecting a service ticket in a
`database to determine a deadline for when a problem
`associated with the service ticket must be resolved, with
`the deadline based upon a contractually determined
`severity of the problem and a corresponding
`contractually required time for resolution of the
`problem;
`[b] display instructions for displaying, on a display device at
`the help desk, a graphical display populated with
`
` 4
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`representations of service tickets that have reached a
`predetermined percentage of the time before their due
`date;
`[c] second instructions for determining an deadline
`approaching alert time at which a help desk user must be
`notified that the deadline for resolving the problem must
`be met; and
`[d] third instructions for alerting the help desk user that the
`deadline for resolving the problem is approaching when
`the deadline approaching alert time is reached.
`
`
`
` 32. A system for monitoring service tickets in order to
`provide reminders to a help desk user of impending times for
`actions, the times for actions being provided according to a
`level of service required to be provided to a customer pursuant
`to a contract between the customer and a service provider, the
`system comprising:
`[a] a monitoring server;
`[b] a database; and
`[c] a help desk client;
`[d] wherein
`[i] the database stores tickets and information regarding
`ticket types, ticket severities based on the contract, and
`corresponding contractually required times for actions to
`be performed for each of the ticket types and ticket
`severities;
`[ii] the monitoring server monitors tickets in the database,
`determines when times for actions are approaching, and
`sends alerts to the help desk client alerting the help desk
`user that a time to take a specified action is approaching;
`and
`
` 5
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`[iii] the help desk client displays active tickets to a help
`desk user and provides alerts received from the monitoring
`server to the help desk user.
`
`
`
` 35. The system as recited in claim 32, wherein the active
`tickets displayed are only those that have reached a
`predetermined percentage of the time before their due date.
`Ex. 1001, 12:41–63, 14:32–51, 56–58.
`
`References and Materials Relied Upon
`D.
`Petitioner relies on the following references and materials in support
`of the asserted grounds of unpatentability:
`References and Materials
`MICROSOFT COMPUTER DICTIONARY (5th Ed. 2002)
`US 2002/0123983 (published Sept. 5, 2002) (“Riley”)
`UK Government Central Computer and
`Telecommunications Agency, BEST PRACTICE FOR
`SERVICE SUPPORT (2000) (“Best Practice”)
`US 6,549,894 B1 (issued Apr. 15, 2003, filed May 7,
`1999) (“Simpson”)
`John W. Fronckowiak, BUILDING AN INTRANET FOR
`DUMMIES (1997) (“Fronckowiak”)
`
`Petitioner asserts that Riley and Simpson qualify as prior art under 35 U.S.C.
`§ 102(e).2 Pet. 3–4. Petitioner asserts that Best Practice and Fronckowiak
`qualify as prior art under 35 U.S.C. § 102(b). Id.
`
`1005
`
`1006
`
`Exhibit No.
`1002
`1003
`1004
`
`
`2 The AIA included revisions to 35 U.S.C. § 102 that became effective on
`March 16, 2013. Because the ’683 Patent issued from an application that
`was filed before March 16, 2013, we will refer to the pre-AIA version of 35
`U.S.C. § 102.
`
` 6
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`E.
`
`Asserted Grounds of Unpatentability
`
`Challenged
`Claim(s)
`123
`32 and 35
`
`Statutory Basis
`
`References
`
`35 U.S.C. § 103(a) Riley, Best Practice, Simpson
`35 U.S.C. § 103(a) Riley, Best Practice, Simpson,
`and Fronckowiak
`
`1.
`
`
`III. ANALYSIS
`Claim Construction
`A.
`Claim Construction Standard
`Consistent with the statute and the legislative history of the America
`Invents Act (“AIA”), we interpret claims of an unexpired patent using the
`broadest reasonable interpretation in light of the specification of the
`patent. 37 C.F.R. § 42.100(b); In re Cuozzo Speed Techs. LLC, No. 2014-
`1301, 2015 WL 4097949, at *7–*8 (Fed. Cir. July 8, 2015) (“Congress
`implicitly approved the broadest reasonable interpretation standard in
`enacting the AIA,” and “the standard was properly adopted by PTO
`regulation.”); see also Office Patent Trial Practice Guide, 77 Fed. Reg.
`48,756, 48,766 (Aug. 14, 2012). There is a presumption that claim terms are
`given their ordinary and customary meaning, as would be understood by a
`person of ordinary skill in the art in the context of the specification. See In
`re Translogic Tech. Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). An
`applicant may rebut that presumption by providing a definition of the term in
`
`3 The table on page 4 of the Petition refers to claim 1, rather than
`challenged claim 12, but this reference appears to be a typographical error.
`
` 7
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`the specification with reasonable clarity, deliberateness, and precision. In re
`Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). In the absence of such a
`definition, limitations are not to be read from the specification into the
`claims. In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993).
`
`
`
`
`
`2.
`“monitoring server”
`Petitioner proposes that “monitoring server” be construed as “[a]
`
`computer or software that controls or provides resources for monitoring to
`other computers or software.” Pet. 11 (emphasis omitted). Petitioner bases
`its construction on a definition from the Microsoft Computer Dictionary (Ex.
`1002). See id.
`
`The ordinary and customary meaning of “monitor” is to check, record,
`track, or control something on a regular basis.4 The term “monitor” can also
`refer to a function or device that is involved in observing activity on a data
`communication line.5 The ordinary and customary meaning of “server” is a
`computer or program that responds to requests or commands from a client.6
`
`
`4 See Ex. 3001: “monitor” in CHAMBERS 21ST CENTURY DICTIONARY
`(2001) (“to check, record, track, or control something on a regular basis”)
`(retrieved from
`http://search.credoreference.com/content/entry/chambdict/monitor/0).
`5 See Ex. 3002: “monitor” in DICTIONARY OF COMMUNICATIONS
`TECHNOLOGY (1998) (“A function or device that involves the observation of
`activity on a data communication line without interference.”) (retrieved from
`http://search.credoreference.com/content/entry/wileycommtech/monitor/1).
`6 See Ex. 1002, 474 (“a computer or program that responds to commands
`from a client.”); see also Ex. 3003: “server” in WEBSTER’S NEW WORLD
`COMPUTER DICTIONARY (2003) (“a computer or program that is dedicated to
`providing information in response to external requests”) (retrieved from
`
` 8
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`Thus, the ordinary and customary meaning of “monitoring server” is a
`computer or computer program that checks, records, tracks, controls, or
`observes some thing or activity, and responds to requests or commands from
`a client.
`
`This ordinary and customary meaning is consistent with the usage of
`the term “monitoring server” in the ’683 Patent Specification.7 The intrinsic
`record does not appear to contain any lexicographic definitions or
`disclaimers that would narrow or alter the scope of this claim term. Thus, on
`this record, and for purposes of this Decision, we construe “monitoring
`server” as “a computer or computer program that checks, records, tracks,
`controls, or observes some thing or activity, and responds to requests or
`commands from a client.”
`
`3.
`
`“client”
`Petitioner has not proposed a construction of this claim term.
`The ordinary and customary meaning of “client” is a user or the user’s
`computer or terminal, or a computer program that is used at the user’s end of
`
`
`http://search.credoreference.com/content/entry/webstercom/server/0); Ex.
`3004: “client server” in NEWNES DICTIONARY OF ELECTRONICS (1999) (“In a
`computer network, a computer from which users (clients) can request stored
`data and applications”) (retrieved from
`http://search.credoreference.com/content/entry/bhelec/client_server/0).
`7 See, e.g., Ex. 1001, 3:43–50 (“When a helpdesk agent 104 initially starts
`the [monitoring] program, they click on, for example, the ‘Get Tickets’
`button which starts the monitoring process. The [monitoring] program
`continuously checks for tickets that require attention from a helpdesk agent
`104 periodically, for example, every 5 minutes.”).
`
` 9
`
`
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`the network to request information form a server.8 This ordinary and
`customary meaning is consistent with the usage of “client” in the ’683 Patent
`Specification.9 The intrinsic record does not appear to contain any
`lexicographic definitions or disclaimers that would justify departing from
`this definition. Thus, on this record, and for purposes of this Decision, we
`construe “client” as “a user or the user’s computer or terminal, or a computer
`program that is used at the user’s end of the network to request information
`from a server.”
`
`4.
`
`“active ticket”
`Petitioner proposes that “active ticket” be construed as “[a] ticket that
`is unresolved.” Pet. 13 (emphasis omitted).
`The ordinary and customary meaning of “active” is something that is
`operating or working.10 The ordinary and customary meaning of “ticket” is
`a log of events that is used to track the status of a problem, which is
`
`8 See Ex. 3005: “client” in NEWNES DICTIONARY OF ELECTRONICS (1999)
`(“In a computer network, a user or the user's computer or terminal or the
`code used at the user's end of the network.”) (retrieved from
`http://search.credoreference.com/content/entry/bhelec/client/0); Ex. 3006:
`“client” in WEBSTER’S NEW WORLD COMPUTER DICTIONARY (2003) (“In a
`client/server network, a program that is designed to request information from
`a server.”) (retrieved from
`http://search.credoreference.com/content/entry/webstercom/client/0).
`9 See, e.g., Ex. 1001, 2:16–19 (“The server then alerts the help desk user
`through a client program that the deadline for resolving the problem is
`approaching when the deadline approaching alert time is reached.”).
`10 See Ex. 3007: “active” in CHAMBERS 21ST CENTURY DICTIONARY (2001)
`(“said of a machine, etc: operating; working.”) (retrieved from
`http://search.credoreference.com/content/entry/chambdict/active/0).
`
`10
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`“opened” when a problem occurs and “closed” when a problem is resolved.11
`Thus, the ordinary and customary meaning an “active ticket” is a log of
`events that is used to track the status of a problem, and that has not yet been
`closed.
`The ordinary and customary meaning of “ticket” is consistent with the
`’683 Patent Specification, which refers to tickets being opened in a database
`upon the occurrence of an IT problem, and then closed when the problem is
`resolved.12 Although the Specification does not contain the term “active
`ticket,” the ordinary and customary meaning set forth above—i.e., a ticket
`that has not yet been closed—is consistent with the usage of this term in
`claims 32 and 35.13 The intrinsic record does not appear to contain any
`lexicographic definitions or disclaimers that would justify departing from
`this definition. Thus, on this record, and for purposes of this Decision, we
`
`
`11 See Ex. 3008: “trouble ticket” in DICTIONARY OF COMMUNICATIONS
`TECHNOLOGY (1998) (“A log of error events used to track the status of
`network problems. A trouble ticket is 'opened' when a problem occurs and
`'closed' when the problem is resolved.”) (retrieved from
`http://search.credoreference.com/content/entry/wileycommtech/trouble_tick
`et/0).
`12 See, e.g., Ex. 1001, 3:13–19 (“[W]hen a customer 102 determines that
`there is a problem with the information technology for which the IT provider
`is responsible, the customer 102 calls on IT help desk user 104. . . . IT
`helpdesk user 104 opens a ticket in a database 106. . . .”); Id. at 4:65–67
`(“the problem is resolved . . . and the helpdesk 104 closes the ticket.”)
`13 For example, claim 35 refers to displaying only those “active tickets . . .
`that have reached a predetermined percentage of the time before their due
`date.” Ex. 1001, 14:56–58. This implies that active tickets are tickets that
`have not yet been closed.
`
`
`11
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`construe “active ticket” as “a log of events that is used to track the status of a
`problem, and that has not yet been closed.”
`
`
`
`
`
`B.
`
`Asserted Grounds of Unpatentability
`
`1.
`
`Overview
`Petitioner argues that claim 12 is unpatentable under 35 U.S.C.
`§ 103(a) as obvious over the combination of Riley, Best Practice, and
`Simpson; and that claims 32 and 35 are unpatentable under 35 U.S.C.
`§ 103(a) as obvious over the combination of Riley, Best Practice, Simpson,
`and Fronckowiak.
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are “such
`that the subject matter as a whole would have been obvious at the time the
`invention was made to a person having ordinary skill in the art to which such
`subject matter pertains.” The question of obviousness is resolved on the
`basis of underlying factual determinations, including: (1) the scope and
`content of the prior art; (2) any differences between the claimed subject
`matter and the prior art; (3) the level of skill in the art;14 and (4) objective
`evidence of nonobviousness, i.e., secondary considerations.15 Graham v.
`John Deere Co., 383 U.S. 1, 17–18 (1966).
`
`
`14 For purposes of this Decision, we consider the cited prior art to be
`representative of the level of ordinary skill in the art. See Okajima v.
`Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir. 2001).
`15 The current record does not contain any evidence of secondary
`considerations.
`
`
`12
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`2.
`
`
`
`
`
`Obviousness of Claim 12 over Riley, Best Practice, and Simpson
`a.
`Overview of Riley
`Riley describes a service desk capability that provides assistance
`related to IT issues to internal and external customers. Ex. 1003 ¶¶ 8, 9.
`The service desk of Riley acts as an interface between the end user and those
`responsible for providing IT services, and works within defined Service
`Level Agreements (“SLAs”). Id. ¶ 32. Riley also describes that service
`requests may be escalated (i.e., assigned to higher-level personnel) “if SLAs
`are likely to be impacted,” and teaches that “escalation should be configured
`to occur well before the actual SLA targets are passed, as this can provide an
`opportunity to still get the service request completed within the SLA.” Id.
`¶¶ 141, 143. Riley further describes that the service desk may include tools
`for logging and tracking service requests, i.e., tools that “remind[] personnel
`when to escalate incidents, when to provide status information to users, and
`when service levels are not being met.” Id. ¶¶ 77, 79.
`
`b.
`Overview of Best Practice
`Best Practice is intended to document industry best practices for the
`support and delivery of IT services, and is part of a collection of books
`called the IT Infrastructure Library that are directed to IT service
`management. Ex. 1004, 23.16 Best Practice describes a service desk that
`receives reports of difficulties with IT services, and an incident management
`process for dealing with such incidents. Id. at 29. Best Practice also
`
`16 Citations to Best Practice (Ex. 1004) refer to the page numbers that
`appear in the exhibit footer.
`
`
`13
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`indicates that a goal of incident management is to “restore normal service
`operation as quickly as possible,” where “‘normal service operation’ is
`defined . . . as service operation within Service Level Agreement (SLA)
`limits.” Id. at 95. Best Practice teaches that the service desk should
`“regularly monitor the status and progress towards resolution and against
`service levels of all open Incidents.” Id. at 110. Best Practice sets forth
`certain “tips” for monitoring incidents, including suggesting that service
`desks “[i]dentify [i]ncidents that are liable to breach agreed service level
`targets and inform the assigned solver,” and “[a]gree on escalation values
`and processes such as . . . when 75% of the agreed time for resolution has
`elapsed and the request is still unresolved, the Service Desk should consult
`with the assigned solver on progress . . . .” Id. at 110–11.
`
`c.
`Overview of Simpson
`Simpson describes a computerized docketing system for legal matters
`that alerts users to critical deadlines with a color-coded graphical display.
`Ex. 1005, 3:36–50. The Simpson system (1) compares due dates for actions
`to be taken in legal matters with reference dates, (2) classifies the due dates
`according to the proximity of each to the reference date, and (3) displays
`different classifications of the due dates in different colors in order to alert a
`system user to matters that require attention. Id.
`
`d.
`Analysis
`Petitioner argues that claim 12 is unpatentable under 35 U.S.C.
`§ 103(a) over Riley, Best Practice, and Simpson. Pet. 15. For the reasons
`
`
`14
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`that follow, we are persuaded that the information presented in the Petition
`shows that there is a reasonable likelihood that the Petitioner will prevail
`with respect to claim 12.
`Petitioner has made an adequate showing that Riley teaches or
`suggests all elements of the preamble of claim 12. See Pet. 18–21. The
`service desk of Riley includes a service desk computer network, a system for
`solving problems and incidents reported by customers, and at least one
`repository for storing information useful in solving the problems and
`incidents that is accessible by the computer network. Ex. 1003 ¶¶ 8, 9. We
`are persuaded, on the record before us, that the service desk computer
`network is a “data processing system” of the type required by the preamble.
`We are also persuaded, on this record, that Riley would have taught, or
`suggested to, a skilled artisan that the service desk could be implemented by
`using computer programming stored in non-transitory computer readable
`media. See, e.g., id. ¶ 85 (disclosing that the service desk may be
`implemented by customizing “a call-tracking database tool . . . to comply
`with the desired requirements to ease Service Desk procedures (such as
`escalation, assignment, and prioritization”)). We are further persuaded that
`Petitioner has demonstrated sufficiently that the problem-solving system of
`Riley monitors service tickets (i.e., “service requests”) for information
`technology service providers (i.e., “those responsible for provision of IT
`services within an organization”) to ensure that levels of service required to
`be provided to customers pursuant to contractual agreements (i.e., “target
`
`
`15
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`service levels” set out in “Service Level Agreements (SLAs)”) are met. Id.
`¶ 32.
`
`
`
`
`
`Petitioner also has made an adequate showing that Riley teaches or
`suggests all elements of claim limitation 12[a]. See Pet. 21–26. Riley
`teaches that the service tickets (i.e., service requests of Riley) may be stored
`in a database. Ex. 1003 ¶ 33 (“[t]he service desk may also have a central
`service desk repository 22, such as a database maintained on a memory
`storage device”), Fig. 5 (depicting the storage of logged service requests in
`central service desk repository 22). We are persuaded, on this record, that
`Riley teaches determining a deadline for when a problem associated with a
`service ticket must be resolved. See id. ¶ 140 (disclosing the determination
`of when the target resolution time will be overrun). We are persuaded that
`Riley also teaches, or at least suggests, that these deadlines are determined
`based upon contractually required times for resolution that correspond to
`contractually specified severity levels. See id. (“Usually, a tracking tool
`enables a target resolution time to be specified (as defined in the SLA)
`depending on priority.”).17
`Petitioner has made an adequate showing with respect to claim
`limitation 12[b]. Petitioner asserts that a skilled artisan would have had
`reason to incorporate the relevant aspects of Simpson and Best Practice into
`the system of Riley. See Pet. 26–33.
`
`
`17 Petitioner argues in the alternative that Best Practice teaches that SLAs
`can set forth levels of severity and corresponding required times for
`resolution. Pet. 25–26.
`
`
`16
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`We are persuaded, based on the record before us, that Riley teaches
`displaying information concerning service requests on a display device at the
`help desk. For example, Riley teaches that service desk personnel may be
`notified of service request assignments via “service desk tool-set
`applications, such as a pop-up window delivered to Tier 2 or Tier 3
`personnel.” Ex. 1003 ¶ 137. While Riley does not disclose “a graphical
`display populated with representations of service tickets that have reached a
`predetermined percentage of the time before their due date,” we are
`persuaded, on this record, that Petitioner has made an adequate showing that
`these aspects of limitation 12[b] would have been obvious in view of the
`teachings of Simpson and Best Practice. See Pet. 26–30. The docketing
`system of Simpson includes a graphical display that is populated with
`representations of matters that have upcoming deadlines. Ex. 1005, 5:51–54
`(“Fig. 3 is a screen capture of the color-coded graphical display of critical
`due dates screen. . . . known as the ‘StarBar.’”); 6:2–11 (“Each cell in the
`[StarBar] represents an action docketed by the program. . . . The color
`yellow is used to indicate an imminent critical due date. The color red is
`used to indicate an urgent critical due date. The time periods for ‘imminent’
`and ‘urgent’ status may be programmed by the docketing administrator.”)
`Best Practice teaches certain “tips” for monitoring and tracking IT incidents,
`including that “when 75% of the agreed time for resolution has elapsed and
`the request is still unresolved, the Service Desk should consult with the
`assigned solver on progress.” Ex. 1004, 111.
`
`
`17
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`
`
`
`
`
`We are persuaded, on this record, that a skilled artisan would have had
`reason to incorporate the color-coded display of Simpson into the service
`desk system of Riley. Riley teaches the importance of monitoring service
`requests so that they can be escalated, if necessary, before deadlines are
`reached. Ex. 1003 ¶ 143. Best Practice emphasizes the desirability of
`flagging IT incidents that are not resolved within set percentages of agreed
`deadlines. Ex. 1004, 111. As Petitioner argues (see Pet. 32–33), a skilled
`artisan would have realized that incorporating the color-coded display of
`Simpson into the system of Riley would advantageously allow service desk
`personnel to quickly identify those service requests that are nearing
`deadlines. The result would also be a “combination of familiar elements
`according to known methods . . . [that] does no more than yield predictable
`results” that is “likely to be obvious.” See KSR Int’l Co. v. Teleflex Inc., 550
`U.S. 398, 4164 (2007).
`Petitioner has made an adequate showing, on this record, that Riley
`teaches or suggests all elements of claim limitation 12[c]. See Pet. 33–34.
`As discussed above, Riley describes calculating a deadline for a service
`request (i.e, the time when the target resolution time for a service request
`will be exceeded). Ex. 1003 ¶ 140. We are also persuaded that Petitioner
`has demonstrated that Riley teaches calculating a deadline approaching alert
`time at which a help desk user is notified that a deadline must be met. In
`particular, Riley teaches that service requests may be escalated automatically
`(id. ¶ 140), and that these escalations “should be configured to occur well
`
`
`18
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`before the actual SLA targets are passed” (id. ¶ 143). Riley also teaches that
`a notification is triggered when a service request is escalated. Id. ¶ 137.
`Petitioner has additionally made an adequate showing, on the record
`before us, that Riley teaches or suggests all elements of claim limitation
`12[d]. See Pet. 34–35. As discussed above, a help desk user is notified
`when the deadline approaching alert time is reached, causing a service
`request to be escalated. See Ex. 1003 ¶ 137.
`For the foregoing reasons, and based upon the current record, we
`determine that Petitioner has made a showing sufficient to demonstrate a
`reasonable likelihood that it will prevail in establishing that claim 12 is
`unpatentable under 35 U.S.C. § 103(a) over the combination of Riley, Best
`Practice, and Simpson.
`
`3.
`
`Obviousness of Claims 32 and 35 over Riley, Best Practice, Simpson,
`and Fronckowiak
`a.
`Overview of Fronckowiak
`Fronckowiak is a book that describes how to design and implement a
`corporate Intranet. Ex. 1006, 1.18
`
`b.
`Analysis
`Petitioner argues that claims 32 and 35 are unpatentable under 35
`U.S.C. § 103(a) over Riley, Best Practice, Simpson, and Fronckowiak.
`Pet. 15. Petitioner’s argument regarding claims 32 and 35 is based on its
`argument with respect to claim 12, but adds the Fronckowiak reference to
`
`18 Citations to Fronckowiak (Ex. 1006) refer to the page numbers that
`appear in the exhibit footer.
`
`
`19
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`address additional limitations contained in claims 32 and 35. For the reasons
`that follow, we are persuaded that the information presented in the Petition
`shows that there is a reasonable likelihood that the Petitioner will prevail
`with respect to claims 32 and 35.
`The elements of the preamble of claim 32 are all similar to elements
`of the preamble of claim 12. The language in claim 32 specifying that times
`for actions be provided “according to a level of service required to be
`provided to a customer pursuant to a contract between the customer and
`service provider” is similar to the requirement in claim limitation 12[a] that
`deadlines be based upon “a contractually determined severity of the problem
`and a corresponding contractually required time for resolution of the
`problem.” We are persuaded that Riley teaches or suggests these limitations
`of claim 32 for the reasons discussed above with respect to the similar
`limitations of claim 12.
`As discussed above, we construe the “monitoring server” (claim
`limitation 32[a]) to mean “a computer or computer program that checks,
`records, tracks, controls, or observes some thing or activity, and responds to
`requests or commands from a client.” See supra § III.A.2. We are
`persuaded that Riley teaches or suggests this limitation of claim 32 for the
`reasons discussed above with respect to claim limitations 12[c] and 12[d].
`Specifically, the service desk of Riley (which can be implemented as
`software) tracks and observes service tickets, calculates deadline
`approaching alert times, and sends notifications to help desk users when
`
`
`20
`
`
`
`
`
`
`
`
`
`IPR2015-00718
`Patent 8,224,683 B2
`
`
`deadline approaching alert times are
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
