Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
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,945,860 Filing Date: May 14, 2003 Issue Date: May 17, 2011
TITLE: SYSTEMS AND METHODS FOR MANAGING CONVERSATIONS
BETWEEN INFORMATION TECHNOLOGY RESOURCES
PETITION FOR COVERED BUSINESS METHOD (CBM)
REVIEW OF U.S. PATENT NO. 7,945,860
CBM Review No. 2015‐___
Table of Contents
Page
‐i‐
I. 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
C. Lead and Back‐Up Counsel under 37 C.F.R. § 42.8(b)(3) .................... 1
D. Service Information ............................................................................ 2
E. Power of Attorney .............................................................................. 2
II. PAYMENT OF FEES ‐ 37 C.F.R. § 42.203 ........................................................ 3
III. REQUIREMENTS FOR COVERED BUSINESS METHOD REVIEW 37 C.F.R. §§ 42.304 ...................................................................................................... 3
A. Grounds for Standing Under 37 C.F.R. § 42.304(a) ............................. 3
1. The Petitioner Has Been Sued For Alleged Infringement of the ’860 Patent In Pending Litigation and Is Not Estopped ................................................................................... 3
2. The ’860 Patent Qualifies for CBM Patent Review ................... 4
a. The ’860 Patent is a “Covered Business Method Patent” ........................................................................... 5
b. The ’860 Patent is Not a “Technological Invention” ..... 12
B. Identification of Challenge under 37 C.F.R. § 42.304(b) and Statement of Precise Relief Requested ............................................ 16
C. Claim Construction Under 37 C.F.R. § 42.304(b)(3) .......................... 16
IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY ......................... 16
A. Early History of Conducting Business over the Web ......................... 16
B. Conducting Business Using “Web Services” and XML ...................... 18
V. SUMMARY OF THE CLAIMED SUBJECT MATTER ......................................... 19
A. The Specification of the ’860 Patent ................................................. 19
B. The Challenged Claims of the ’860 Patent ........................................ 21
VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.304(B)(3) ............................ 22
Table of Contents (continued)
Page
‐ii‐
A. “Web service” ................................................................................... 23
B. “conversation” .................................................................................. 24
C. “managed object” and “conversation managed object” .................. 24
1. “managed object” .................................................................. 24
2. “conversation managed object” ............................................. 26
D. “manager” ........................................................................................ 27
E. “interface,” “managed object interface,” “conversation interface” .......................................................................................... 28
1. “interface” .............................................................................. 29
2. “managed object interface” ................................................... 30
3. “conversation interface” ........................................................ 31
VII. CLAIMS 1, 5, 7‐10, 12, 15 AND 24‐26 OF THE ’860 PATENT ARE UNPATENTABLE .......................................................................................... 32
A. Ground 1 – Claims 1, 5, 7‐10, 12, 15 and 24‐26 Are Invalid Under 35 U.S.C. § 101 ....................................................................... 32
1. The Challenged Claims Are Directed to an Abstract Idea ....... 33
a. Claim 1 .......................................................................... 33
b. Claim 5, 7‐9, 12 ............................................................. 36
c. Claim 10 ........................................................................ 37
d. Claim 15 ........................................................................ 37
e. Claim 24 ........................................................................ 38
f. Claim 25 ........................................................................ 39
g. Claim 26 ........................................................................ 39
2. Claims 1, 5, 7‐10, 12, 15, 24‐26 Lack an “Inventive Concept” ................................................................................. 40
a. “Web Service” (Claim 1) ............................................... 40
Table of Contents (continued)
Page
‐iii‐
b. “computer processor” (Claim 1) ................................... 43
c. “computer program product” and “computer storage readable medium” (Claim 24) ......................... 43
d. “SOAP” (Claims 10 and 26) ........................................... 44
e. “manager” (Claim 1) ..................................................... 44
3. Other Limitations .................................................................... 45
B. Ground 2 – Claims 1, 5, 7‐9, 12, 15, 24 and 25 are Obvious over Rizzo in view of Jamison ................................................................... 47
1. Prior Art and Date Qualification for Ground 2 ........................ 47
2. Brief Summary of the Prior Art Applied in Ground 2 .............. 47
3. Claim 1 is Obvious .................................................................. 50
4. Claims 5, 7‐9, 12, and 15 are Obvious .................................... 61
a. Claims 5 and 15 (“Fault Message” Claims) ................... 62
b. Claims 7‐9 and 12 (“Number of Messages” Claims) ..... 64
5. Claim 24 is Obvious ................................................................ 67
6. Claim 25 is Obvious ................................................................ 74
C. Ground 3 – Claims 10 and 26 are Obvious over Rizzo in view of Jamison and in further view of Sturm ............................................... 75
1. Prior Art and Date Qualification for Ground 3 ........................ 75
2. Claims 10 and 26 are Obvious ................................................ 75
VIII. CONCLUSION .............................................................................................. 77
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
List of Exhibits
‐iv‐
Ex. No Description of Document
1001 U.S. Patent No. 7,945,860 to Guillaume N. Vambenepe et al.
1002 Declaration of Tal Lavian, Ph.D.
1003 U.S. Patent No. 7,925,981 to M. Homayoun Pourheidari et al.
1004 Excerpts from Programming Microsoft Outlook and Microsoft Exchange, Thomas Rizzo, 1999
1005 Excerpts from Developing Applications with Exchange 2000, Scott Jamison et al., 2001
1006 Excerpts from Developing XML Solutions, Jake Sturm, 2000
1007 Excerpts from Java Web Services, David A. Chappell et al., March 2002
1008 Excerpts from Applied SOAP: Implementing .NET XML Web Services, Kenn Scribner & Mark Stiver, 2001
1009 Excerpts from XML in a Nutshell, Elliotte Rusty Harold et al., 2001
1010 Excerpts from Microsoft Computer Dictionary, Fifth Edition, 2002
1011 Excerpts from ASP 3.0 Programmer’s Reference, Richard Anderson et al., 2000
1012 Complaint for Patent Infringement in Case No. 14‐CV‐00570 BLF (filed February 6, 2014)
1013 Joint Claim Construction and Prehearing Statement in Case No. 14‐CV‐00570 BLF (March 20, 2015)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐1‐
Petitioner ServiceNow, Inc. (“Petitioner”) respectfully submits this Petition
for Covered Business Method (CBM) review of claims 1, 5, 7‐10, 12, 15 and 24‐26
of U.S. Patent No. 7,945,860 [Ex. 1001] (“’860 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 Petitioner is aware of two related matters under 37 C.F.R. § 42.8(b)(2).
First, on February 6, 2015, the Petitioner filed a Petition for Inter Partes Review of
the ’860 patent, IPR2015‐00716, challenging claims 1, 5, 7‐10, 12, 15 and 24‐26
based on grounds different from those set forth in this Petition.
Second, the Petitioner was sued for alleged infringement of the ’860 patent
in Hewlett‐Packard Co. v. ServiceNow, Inc., Case No. 14‐CV‐00570 BLF (N.D. Cal.
filed Feb. 6, 2014). The patent owner in that litigation contends that the
Petitioner infringes the 11 claims of the ’860 patent challenged in this Petition.
The Petitioner has denied infringement and contends the patents are invalid.
C. Lead and Back‐Up Counsel under 37 C.F.R. § 42.8(b)(3)
Petitioner provides the following designation of counsel.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐2‐
LEAD COUNSEL BACK‐UP COUNSEL
Heidi L. Keefe (Reg. No. 40,673) [email protected] [email protected] COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (650) 843‐5001 Fax: (650) 849‐7400
Andrew C. Mace (Reg. No. 63,342) [email protected] [email protected] COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (650) 843‐5808 Fax: (650) 849‐7400
Phillip E. Morton (Reg. No. 57,835) [email protected] [email protected] Cooley LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (703) 456‐8668 Fax: (703) 456‐8100
D. Service Information
This Petition is being served by FedEx to the current correspondence
address for the ’860 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).
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐3‐
II. PAYMENT OF FEES ‐ 37 C.F.R. § 42.203
This Petition requests covered business method (CBM) review of eleven
(11) claims of the ’860 patent. Accordingly, a payment of $30,000 is submitted
herewith, which is calculated based on a $12,000 CBM Review Petition Fee (for up
to 20 claims) and an $18,000 Post‐Institution Fee (for up to 15 claims).
III. REQUIREMENTS FOR COVERED BUSINESS METHOD REVIEW 37 C.F.R. §§ 42.304
A. Grounds for Standing Under 37 C.F.R. § 42.304(a)
1. The Petitioner Has Been Sued For Alleged Infringement of the ’860 Patent In Pending Litigation and Is Not Estopped
Pursuant to 37 C.F.R. § 42.302(a), Petitioner certifies that it has been
named in litigation pending in the U.S. District Court for the Northern District of
California. See Hewlett‐Packard Co. v. ServiceNow, Inc., Case No. 14‐CV‐00570
BLF (N.D. Cal.). The Complaint in that litigation, filed on February 6, 2014,
specifically accuses the Petitioner of directly and indirectly infringing the ’860
patent. (See Complaint, Ex. 1012, ¶¶ 13, 28‐34.) The case remains pending.
The Petitioner is unaware of any post‐grant review (PGR) of the ’860 patent
filed under 35 U.S.C. § 321(c). The Petitioner certifies that the ’860 patent is
available for covered business method (CBM) review and that the Petitioner is not
barred or otherwise estopped from requesting such review on the grounds
identified in the present Petition.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐4‐
Additionally, the Petitioner does not believe any grounds exist under 35
U.S.C. § 325(d) for the Board to exercise discretion to decline to hear this Petition.
As noted in Part I.B above, the Petitioner filed a Petition for Inter Partes Review of
the ’860 patent, IPR2015‐00716, based on grounds different from those
presented here. For example, the present Petition challenges the patent
eligibility of claims 1, 5, 7‐10, 12, 15 and 24‐26 under 35 U.S.C. § 101, a ground
that cannot be raised in IPR2015‐00716. The present Petition also presents a
ground of invalidity under § 103(a) based on prior art references substantially
different from those discussed in IPR2015‐00716. The primary prior art
references cited in IPR2015‐00716 relate to WebLogic Collaborate, a
comprehensive suite of services for creating collaborative applications using Web
services. In contrast, the prior art cited in the present Petition describes a system
for managing conversations in the context of a helpdesk application based on
features provided by Microsoft Exchange software. Other than the fact that the
references in IPR2015‐00716 and in the present Petition relate broadly to Web
services, there is no technological overlap or redundancy between them.
2. The ’860 Patent Qualifies for CBM Patent Review
Determining whether a patent qualifies for CBM review entails a two‐step
inquiry. First, the Board determines whether the patent meets the definition of a
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐5‐
“covered business method patent” under Section 18 of the AIA. Second, the
Board determines whether the patent is excluded from CBM review because it
covers a “technological invention.” Each requirement is addressed below.
a. The ’860 Patent is a “Covered Business Method Patent”
As explained in more detail in Part V below, the ’860 patent generally
describes a system for monitoring conversations in a “Web service.” (’860,
Abstract.) As this Petition will explain below, the ’860 patent qualifies as a
“covered business method patent” because the alleged invention is directed at a
technique for managing a financial product or service – in particular, operating an
online store that includes online payment processing and billing functions.
The America Invents Act defines a “covered business method patent” as “a
patent that claims a method or corresponding apparatus for performing data
processing or other operations used in the practice, administration, or
management of a financial product or service.” AIA § 18(d)(1). The USPTO has
interpreted “covered business method patent” to encompass patents claiming
activities financial in nature, incidental to a financial activity or complementary to
a financial activity. (See Fed. Reg. Vol. 77, No. 157 at 48734‐35; see also SAP Am.,
Inc. v. Versata Dev. Grp., Inc., No. CBM2012‐00001, Decision to Institute (Paper
No. 36) at p.23 (PTAB Jan. 9, 2013).) Additionally, the Board may find a patent
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐6‐
subject to CBM review even if only one claim meets the definition of a “covered
business method patent.” (Liberty Mutual Ins. Co. v. Progressive Casualty Ins. Co.,
Case CBM‐00002 (Paper No. 66), at p.6 (PTAB January 23, 2014).)
The ’860 patent qualifies as a “covered business method patent” under
these principles. The challenged claims are directed at a system for monitoring
conversations in a “Web service.” The specification explains that a “Web service”
can include any type of business or financial transaction. (’860, Ex. 1001, 1:36‐
40.) “Essentially any transaction or bit of business logic can become a Web
service if it can be accessed and used by another system over a network such as
the Internet.” (’860, 1:40‐43.) The ’860 patent provides an embodiment in which
the claimed system is used for payment processing and billing in an online
ordering system (Figure 2), confirming that the claims cover operations used in
the practice and management of a financial product or service.
This Petition will start its analysis with representative claim 1 which reads:
1. A system for managing a conversation in a Web service,
comprising:
[a] a computer processor; and
[b] a conversation managed object executable on the computer
processor, wherein:
[c] the conversation managed object includes at least one
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐7‐
interface configured to provide management information
about the conversation to at least one manager; and
[d] the at least one interface is configured to provide information
regarding the Web service that contains the conversation.
(’860, Ex. 1001, 10:30‐41 (Claim 1).)
The limitations above are directly reflected in the online ordering system
described in the specification. That system is shown in Figure 2:
(’860, Ex. 1001, Fig. 2 (highlighting added).) Figure 2 above “shows a diagram of
components included in an embodiment of an online shopping service system 200
that can utilize conversation management system 100 (FIG. 1A).” (’860, 9:26‐28.)
Client 202 on the left represents a computer system associated with a purchaser.
(’860, 9:29‐33.) The client communicates with Online Ordering Service 204, an
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐8‐
exemplary Web service. The right side of Figure 2 shows Billing Service 210,
which “can be implemented by a third party in payment processor 212.” (’860,
14:35‐36.) “Billing Service 210 allows the purchaser to pay with a credit card,
checking account, or other suitable payment means for one or more items.”
(’860, 9:44‐46 (underlining added).)
Figure 2 also shows arrows for conversations 214 and 216 depicting the
flow of messages. As explained in the specification, “[i]nformation regarding
transactions, such as the amount to be charged and credit card charge
authorizations, can be exchanged via conversations 214, 216 between online
ordering service 204 and billing service 210.” (’860, 9:36‐39 (underlining added).)
Figure 2 also shows Manager 102, corresponding to the claimed “manager.”
Figure 3 (excerpted at right) shows more
details about the online shopping service in Figure
2. (’860, 4:17‐19, Fig. 3.) It shows conversation
managed object 302 and conversation interface
308 associated with conversation 214. Another
portion of Figure 3 (not shown at the right) shows
a similar block diagram for the Payment Processor 212, containing its own
corresponding conversation managed object and interface components that meet
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐9‐
the claim limitations. (’860, items 212, 306, 312, 216.)
The disclosures associated with Figure 2 and 3 directly track the limitations
of claim 1, as shown in the chart below:
Claim 1 Financial Services Embodiment (Figs. 2 & 3)
1. A system for managing a conversation in a Web service, comprising:
“FIG. 2 shows a diagram of components included in an embodiment of an online shopping service system 200 that can utilize conversation management system 100 (FIG. 1A).” (’860, 9:26‐28.)
“Information regarding transactions, such as the amount to be charged and credit card charge authorizations, can be exchanged via conversations 214, 216 between online ordering service 204 and billing service 210.” (’860, 9:36‐39.)
a computer processor; and a conversation managed object executable on the computer processor, wherein:
“Referring to FIGS. 2 and 3, FIG. 3 shows a block diagram of conversations 214, 216 containing conversation managed objects 302, 306.” (’860, 9:48‐50 (underlining added).)
the conversation managed object includes at least one interface configured to provide management information about the conversation to at least one manager; and the at least one interface is configured to provide information regarding the Web service that
“Conversation managed objects 302, 306 are configured with conversation interfaces 308, 312, and managed object interfaces 314, 318, respectively. Manager 102 can discover interface descriptions 118 to learn about the management capabilities available for conversation interfaces 308, 312, and managed object interfaces 314, 318.” (’860, 9:50‐55 (underlining added).)
“The capability to monitor conversations 214, 216 allows manager 102 to determine the status of transactions between online ordering service 204 and billing service 210, to determine whether conversation
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐10‐
Claim 1 Financial Services Embodiment (Figs. 2 & 3)
contains the conversation. 1
214 or 216 has faulted, and to alert an administrator of the corresponding online ordering service 204 or billing service 210 when a problem with conversation 214 or 216 occurs.” (’860, 9:61‐67 (underlining added).)
As the chart above shows, the ’860 patent expressly discloses use of the
claimed conversation management system to manage a financial product or
service, e.g., monitoring messages relating to payment processing and billing
services. Although the claim chart above focuses on claim 1, substantially the
same limitations are recited in independent claim 24. The only material
difference, for purposes of the CBM eligibility analysis, is that claim 24 adds a
“managed object interface,” but that component is also shown in the financial
embodiment in Figure 3. (’860, Fig. 3 (items 314, 318), 9:52‐55.) Claim 24 and
dependent claims 5, 7‐10, 12, 15, 25, and 26 provide further examples of the kind
of information the “interface” can provide about the messages exchanged in the
1 The Petitioner has provided the chart in the text to show the use of the claimed
methods to perform the financial services described in the specification. The
Petitioner does not concede that the written description supports the issued
claims in the manner required by 35 U.S.C. § 112(a).
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐11‐
conversation, all of which would apply to the financial messages described in the
specification. (’860, 9:36‐39 (“Information regarding transactions, such as the
amount to be charged and credit card charge authorizations, can be exchanged
via conversations 214, 216 . . . .”).) All of these claims therefore encompass
management of a financial product or service, and claim activities that are
incidental or complementary to a financial activity.
In determining whether a patent qualifies as a “covered business method
patent” under the AIA, the Board has looked to the specification to determine
whether it discloses use of the claimed invention for the practice, administration,
or management of financial services. (Salesforce.com, Inc., v. VirtualAgility, Inc.,
CBM2013‐0024 (Paper No. 47) at p.9 (PTAB Sept. 16, 2014) (“The multiple
disclosures in the [specification] of activity that includes financial aspects or
activities of an organization indicates the claimed methods and apparatus can be
used in the practice, administration, or management of a financial product or
service.”) (Final Written Decision).) In the present case, the ’860 patent makes
clear that the claimed techniques can be used to manage and administer financial
activity and relate to monetary matters.
The Petitioner anticipates that the patent owner may assert that the ’860
patent does not qualify as a “covered business method patent” because,
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐12‐
according to the patent owner, its claims do not expressly require that messages
in a conversation contain payment‐related information. However, the Petitioner
is aware of no decision by the Board restricting CBM review to patents that have
claim limitations expressly limiting the claim scope to the financial embodiment in
the specification. The Petitioner respectfully submits that any such interpretation
of § 18(d) would be contrary to the Congressional purpose behind CBM review.
The online ordering and payment processing embodiments in Figure 2 and
3 are the only real‐world examples of use of the alleged invention provided in the
specification. Holding that a “covered business method patent” must have claims
expressly limited to the disclosed financial embodiments would create the
anomalous result that an invention expressly described in the specification as
applying to payment processing—such as the ’860 patent—could evade CBM
review by merely omitting express financial limitations from the claims. The
Petitioner accordingly requests that the Board adhere to its current approach,
expressed in Salesforce.com, Inc. v. VirtualAgility, Inc. and other cases, and hold
that the ’860 patent qualifies as a “covered business method patent.”
b. The ’860 Patent is Not a “Technological Invention”
The definition of a “covered business method patent” in § 18(d)(1) of the
AIA excludes patents for “technological inventions.” To determine whether a
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐13‐
patent covers a “technological invention,” the USPTO considers “whether the
claimed subject matter as a whole recites a technological feature that is novel and
unobvious over the prior art; and solves a technical problem using a technical
solution.” 37 C.F.R. § 42.301(b); see also Office Patent Trial Practice Guide, 77 Fed.
Reg. 48756, 48763‐64 (Aug. 14, 2012) (describing claim drafting techniques that
typically do not render a patent a “technological invention”).
The claims do not recite any technological feature that is novel and non‐
obvious over the prior art. Again using claim 1 as a reference:
1. A system for managing a conversation in a Web service,
comprising:
[a] a computer processor; and
[b] a conversation managed object executable on the computer
processor, wherein:
[c] the conversation managed object includes at least one
interface configured to provide management information
about the conversation to at least one manager; and
[d] the at least one interface is configured to provide information
regarding the Web service that contains the conversation.
(’860, Ex. 1001, 10:30‐41 (Claim 1).)
The only arguably “technological features” in claim 1 recite known
technologies. The claim recites “Web services,” but the patent does not claim to
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐14‐
have invented them and describes them as part of the prior art. (’860, Ex. 1001,
1:32‐43 (“Background”), 2:20‐21 (“Enterprises are adopting Web services
technology to address their business integration needs[.]”).) The claimed
“computer processor” and “interfaces” were generic and known structures to
persons of ordinary skill in the art. (Lavian Decl., Ex. 1002, ¶¶ 25‐29, 57‐60, 97,
98, 186, 200.) And as explained in great detail in Part VII below, the Rizzo and
Jamison prior art references disclose or suggest all limitations of claims 1, 5, 7‐12,
15, 24, and 25 and render those claims obvious under 35 U.S.C. § 103(a). All
limitations of claims 10 and 26 are disclosed or suggested by Rizzo, Jamison and
Sturm, rendering those claims obvious.
Part VII below provides a detailed, limitation‐by‐limitation analysis as to
why the challenged claims as a whole are obvious over the prior art. That same
analysis also demonstrates that the challenged claims as a whole do not claim any
“technological invention” under § 18(d)(1). Because it is not possible in light of
the page limits to repeat that analysis here, the Petitioner refers to and
incorporates that analysis here. (See infra Part VII.B and VII.C.) Because the
challenged claims merely combine prior art elements to achieve the normal,
expected, or predictable result of that combination, the ’860 patent does not
claim a “technological invention” and is therefore eligible for CBM review.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐15‐
The ’860 patent is not a technical solution to a technical problem, but
rather, the application of technology to an existing financial or business process.
The patent makes clear, in fact, that the underlying “service” represented by a
“Web service” need not be technological at all – it may include “real world”
services such as “language translation or currency conversion, performing
calculations for medical claims processing, and handling certain aspects of travel
planning[.]” (’860, 1:36‐40.) The specification acknowledges that Web services
were already being deployed commercially before the alleged invention. (’860,
2:20‐21 (“Enterprises are adopting Web services technology to address their
business integration needs[.]”).) The Background section of the specification
states that “[e]ssentially any transaction or bit of business logic can become a
Web service if it can be accessed and used by another system over a network
such as the Internet.” (’860, 1:40‐43.) The claimed “Web services,” and the
claimed techniques for managing conversations associated with them, do not
represent a “technological invention,” but an application of existing and known
technologies to provide and manage business processes. The ’860 patent
therefore does not qualify as an exempt “technological invention.”
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐16‐
B. Identification of Challenge under 37 C.F.R. § 42.304(b) and Statement of Precise Relief Requested
The Board should initiate covered business method (CBM) review of claims
1, 5, 7‐10, 12, 15 and 24‐26 on the following grounds:
Ground Claims Basis for Challenge
1 1, 5, 7‐10, 12, 15, 24‐26
Unpatentable under 35 U.S.C. § 101
2 1, 5, 7‐9, 12, 15, 24‐25
Unpatentable over Rizzo in view of Jamison, under 35 U.S.C. § 103(a)
3 10, 26 Unpatentable over Rizzo in view of Jamison and Sturm, under 35 U.S.C. § 103(a)
Part VII below provides a detailed explanation as to why each challenged
claim is unpatentable based on these grounds. This Petition cites the 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, ¶¶ 8‐17, Ex. A.)
C. Claim Construction Under 37 C.F.R. § 42.304(b)(3)
An identification and discussion of the claim terms for which construction
by the Board is warranted is set forth in Part VI, below.
IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY
A. Early History of Conducting Business over the Web
“Web services” were not an invention of the ’860 patent, but were an
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐17‐
outgrowth of the World Wide Web and the explosion of its popularity that began
in the 1990s. (Lavian Decl., Ex. 1002, ¶ 25.) During that time, businesses on the
web relied on straightforward web technologies. For example, a web server could
receive a request from a browser using the HyperText Transfer Protocol (“HTTP”)
and process the request using the Common Gateway Interface (“CGI”). CGI
provided an interface for a web server to access an application program or
resource, such as a business application or database. The web server could then
return a response to the web browser in the form of a HyperText Markup
Language (“HTML”) file – in other words, a web page. (Id.)
But as web‐based businesses grew, especially larger enterprises such as
rental car companies and airlines, systems needed to support coordination among
a larger number of distributed systems. (Lavian Decl., Ex. 1002, ¶ 26; Chappell,
Ex. 1007, at p.7.) “Web services” were one of a number of technologies that
attempted to address that issue. (Chappell, Ex. 1007, at p.1; see also id., p.9
(“[T]he base [web services technologies] are not themselves very exciting; they
are just new dressing for the same old distributed‐computing model.”); Scribner,
Ex. 1008, p.12 (“The basic idea behind Web Services isn’t really new. In many
ways, we are just reusing technology that most of us have used for years.”).)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐18‐
B. Conducting Business Using “Web Services” and XML
The Background section of the ’860 patent states that Web services are “an
approach to distributed computing in which interactions are carried out through
the exchange of eXtensible Markup Language (XML) messages.” (’860, 1:32‐34.)
Like Web services themselves, “XML” was not an invention of the ’860 patent.
XML is an industry‐standard set of rules for creating documents that contain
information. (Lavian Decl., Ex. 1002, ¶ 28.) As explained in XML in a Nutshell
(2001), XML “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, and more.”
(Harold, Ex. 1009, at p.3.)
XML became popular in part because it provided a more universal
document format that could facilitate information sharing between computer
systems and applications. (Lavian Decl., Ex. 1002, ¶ 28.) By 2001, two years
before the application for the ’860 patent was filed, it was recognized that “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.” (Harold, Ex. 1009, Preface, xi.)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐19‐
V. SUMMARY OF THE CLAIMED SUBJECT MATTER
A. The Specification of the ’860 Patent
The ’860 patent, entitled “Systems and Methods for Managing
Conversations Between Information Technology Resources,” generally describes a
web service management system that allows a manager to monitor
conversations. Figure 1A provides a general overview of one embodiment:
(’860, Ex. 1001, Fig. 1A.) The management system in Figure 1A includes a
“conversation managed object” 110 that has an interface for exposing
management features of an associated conversation 106 to a manager 102. The
’860 patent describes a “conversation managed object” as follows:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐20‐
Conversation managed objects 108, 110 represent the management
features of resource(s) that conduct conversations 104, 106.
Interfaces in one or more categories can be included in conversation
interfaces 112, 114 for each conversation managed object 108, 110.
Conversation interfaces 112, 114 allow manager 102 to access
information regarding the state of messages related to
corresponding conversations 104, 106.
(’860, 4:26‐33 (underlining added).)
The ’860 patent also states that “[c]onversation managed objects . . . can
be considered managed objects.” (’860, 6:61‐62.) The specification explains that
a managed object “implements managed object interfaces 150 to provide a
common set of basic management capabilities to monitor and/or control the
underlying resource(s) represented by managed object 148 through various
features such as attributes, operations, and event notifications.” (’860, 6:63‐67.)
A key limitation recited in the claims challenged in this Petition is a
“conversation.” One of the management features of a “conversation managed
object,” is its ability to monitor “conversations” associated with a Web service.
The specification describes a “conversation” as follows:
The term “conversation” is a set of related messages sent and
received by a particular conversation. Conversations 104, 106 are
typically invoked by other resources, such as Web services (not
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐21‐
shown).
(’860, 4:45‐48 (underlining added).) As described above, the specification of the
’860 patent describes a financial service having “conversations” that can be
managed using the alleged invention. (’860, Ex. 1001, 9:26‐67, Fig. 2‐3.)
B. The Challenged Claims of the ’860 Patent
The two independent claims addressed in this Petition—claims 1 and 24—
purport to recite a system and computer program product for managing a
conversation. Representative claim 1 recites:
1. A system for managing a conversation in a Web service,
comprising:
[a] a computer processor;
[b] a conversation managed object executable on the computer
processor, wherein:
[c] the conversation managed object includes at least one
interface configured to provide management information
about the conversation to at least one manager; and
[d] the at least one interface is configured to provide information
regarding the Web service that contains the conversation
(’860, 10:30‐41 (Claim 1).) The bracketed notations (e.g., “[a],” “[b],” etc.) were
added to facilitate identification of these limitations in this Petition. The second
independent claim addressed in this Petition is claim 24:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐22‐
24. A computer program product tangibly embodied in a computer
storage readable medium, comprising:
[a] a conversation interface;
[b] a managed object interface associated with the conversation
interface, wherein the conversation interface includes
information for monitoring messages in a conversation,
including:
[b1] at least one of: the number of failed messages; the number of
successful messages; the total number of messages; the last
message received by a resource; the last fault message
received by the resource; and
[b2] at least one of: the identity of resources participating in the
conversation; the number of resources participating in the
conversation; an identifier of the conversation; and an
identifier of the resource that contains the conversation
interface.
(’860, 12:16‐36 (Claim 24).) The other claims addressed in this Petition depend
directly or indirectly from claim 1 or claim 24. This Petition will address those
claims in more detail in Part VII.B below.
VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.304(B)(3)
A claim subject to CBM 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). The “broadest reasonable construction” standard is
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐23‐
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 below represent the broadest
reasonable construction that one of ordinary skill in the art would assign and not
necessarily an appropriate construction in patent infringement litigation.
A. “Web service”
The term “Web service” appears in both of the independent claims (i.e.,
claims 1 and 24) addressed in this Petition. The term is discussed in the
Background section of the specification, which states:
The term Web services, also referred to herein as “services”,
describes an approach to distributed computing in which interactions
are carried out through the exchange of eXtensible Markup Language
(XML) messages. . . . Essentially any transaction or bit of business
logic can become a Web service if it can be accessed and used by
another system over a network such as the Internet.
(’860, 1:32‐34, 1:40‐43 (underlining added).)
As explained by Dr. Lavian, the above statement from the “Background” is
generally consistent with how one of ordinary skill in the art would have
understood “Web service” as of May 2003. (Lavian Decl., Ex. 1002, ¶ 41.)
Accordingly, the term “Web service” under its broadest reasonable construction
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐24‐
should be interpreted as “a service or system that interacts with another system
through the exchange of eXtensible Markup Language (XML) messages.”
B. “conversation”
Independent claims 1 and 24 both recite a “conversation” in a Web service.
The specification provides the following (somewhat circular) definition of this
term: “The term ‘conversation’ is a set of related messages sent and received by
a particular conversation.” (’860, Ex. 1001, 4:45‐46 (underlining added).) Based
on this description, the term “conversation” should be understood to mean “a set
of related messages for exchange of information.”
C. “managed object” and “conversation managed object”
The term “managed object” is recited in a number of ways in the claims.
Claim 1 recites a “conversation managed object,” while independent claim 24
recites a “managed object interface.” This Petition will therefore separately
address “managed object” and “conversation managed object.”
1. “managed object”
The term “managed object” generally refers to an object (such as a
software program, process or system) that is responsible for managing a resource.
The broadest reasonable construction of “managed object” is “an object for
managing a resource.” This definition is supported by the following passage:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐25‐
Referring to FIG.1B, an embodiment of managed object 148 with
managed object interfaces 150 is shown. Managed object 148 is a
management representation of a resource. For example,
conversation managed objects 108, 110 in FIG. 1A can each be
considered managed objects 148.
Managed object 148 implements managed object interfaces 150 to
provide a common set of basic management capabilities to monitor
and/or control the underlying resource(s) represented by managed
object 148 through various features such as attributes, operations,
and event notifications.
(’860, Ex. 1001, 6:58‐67 (underlining added).) This is consistent with an earlier
passage in the specification stating that “[c]onversation managed objects 108,
110 represent the management features of resource(s) that conduct
conversations 104, 106.” (Id., 4:26‐28 (underlining added).)
The specification describes “resources” broadly as including “documents,
images, downloadable files, services, electronic mailboxes, and other resources.”
(Id., 5:58‐60.) The specification also describes “management capabilities” as
including “monitoring, discovery, control, performance, configuration, and
security.” (Id., 5:1‐4.) Based on these disclosures, the broadest reasonable
construction of “managed object” is “an object for managing a resource.”
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐26‐
2. “conversation managed object”
A “conversation managed object” is simply a managed object with one
additional feature – it is associated with a conversation. The term “conversation
managed object” under its broadest reasonable interpretation is “an object for
managing a resource that is associated with a conversation.”
The specification makes clear that conversation managed objects can be
considered managed objects. (’860, Ex. 1001, 6:61‐62.) The key distinction
between the two types of objects is that a “conversation managed object,”
according to the specification, conducts a conversation and has an “interface” to
allow a “manager” to access management features for the conversation:
Conversation managed objects 108, 110 represent the management
features of resource(s) that conduct
conversations 104, 106. Interfaces in
one or more categories can be
included in conversation interfaces
112, 114 for each conversation
managed object 108, 110.
Conversation interfaces 112, 114
allow manager 102 to access information regarding the state of
messages related to corresponding conversations 104, 106.
(Id., 4:26‐33 (underlining added), Fig. 1A (excerpt).)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐27‐
The specification also makes clear that although a “conversation managed
object” is associated with a conversation, the term requires no particular physical
relationship between the “conversation managed object” and the “resource” and
“conversation” with which the object is associated. Conversation managed
objects, according to the specification, “can be implemented as part of the
implementation for conversations 104, 106, such as shown for conversation
managed object 108 [in Fig. 1A], or in a layer external to conversations 104, 106,
as shown for conversation managed object 110.” (Id., 4:40‐44.)
In light of the specification and claim language, the term “conversation
managed object” under its broadest reasonable construction to mean “an object
for managing a resource that is associated with a conversation.”
D. “manager”
Claim 1 states that the conversation managed object “includes at least one
interface configured to provide management information about the conversation
to at least one manager.” As shown below, a “manager” is a “software process
or system for accessing management features.”
The specification of the ’860 patent does not provide specific detail
regarding the implementation of the claimed “manager,” but instead describes it
using almost entirely functional language. In Figure 1A, the manager is depicted
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐28‐
as box 102 on the left. “Referring to FIG 1A, an
embodiment of a conversation management
system 100 that allows manager 102 to
monitor and control one or more
conversations 104, 106 is shown.” (’860, Ex.
1001, 4:23‐26 (underlining added).) This indicates that the “manager” 102 is used
for accessing management features.
The term “manager” does not refer to a human being, but rather, to a
software process or system. The specification makes clear that the “manager” is
software‐based. (Id., 8:57‐62 (“In the embodiments shown, manager 102 . . . [is]
implemented in computer processing systems 160 through 168, respectively.”)
(underlining added).) Accordingly, based on the description in the specification,
the broadest reasonable construction of “manager” is “a software process or
system for accessing management features.”
E. “interface,” “managed object interface,” “conversation interface”
Claim 1 recites an “interface” while claim 24 recites a “conversation
interface” and an associated “managed object interface.” This Petition will
therefore first address “interface,” then turn to the terms that incorporate it.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐29‐
1. “interface”
The specification does not expressly define “interface.” As explained by Dr.
Lavian, the term “interface” is broadly used by persons of ordinary skill in the art
to describe something that connects two systems, processes or actors together.
(Lavian Decl., Ex. 1002, ¶ 56.) For example, a “graphical user interface,” a term
familiar to many computer users, generally describes a way in which a computer
makes its features available to a user through icons, windows, buttons and other
visual indicators. (Id.) A graphical user interface is an “interface” because it
facilitates interaction between the computer and its human operator. (Id.)
Another common use of “interface” is the term “application programming
interface” (API), which refers to a concept that is well known in the art. A person
of ordinary skill in the art would have understood that an API generally provides a
way for a set of software services to be accessed by another software system.
(Id., ¶ 57.) APIs exist at many levels of computer software design and usually take
the form of a set of defined software routines, procedures, functions or methods
that invoke the software services they represent. (Id.) For example, operating
systems such as Microsoft Windows and UNIX provide APIs to allow user
applications to interact with the operating system to perform tasks such as
creating and opening files, sending and receiving information over a network, and
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐30‐
receiving user input from a keyboard, mouse or other input device. An API is an
“interface” because it facilitates interaction between two different software
programs or processes. (Id.)
Both of these examples are consistent with the definition of “interface”
found in the Microsoft Computer Dictionary (5th ed. 2002) [Ex. 1010] which
defines “interface” as “[t]he point at which a connection is made between two
elements so that they can work with each other or exchange information.” (Ex.
1010, at p.279.) The patent specification uses the term “interface” in a way that
is consistent with this definition. (Lavian Decl., Ex. 1002, ¶ 58.) For example, the
specification explains that a “conversation managed object includes one or more
interfaces configured to provide management information about the
conversation to a manager.” (’860, Ex. 1001, 3:26‐29 (underlining added).) These
conversation “interfaces” allow the manager to access information such as the
number of successful and failed messages and the identity of the services
participating in the conversation. (Id., 3:51‐60.) Thus, “interface” under its
broadest reasonable construction should be interpreted as “a connection point
for communication and/or exchange of information.”
2. “managed object interface”
Claim 24 recites a “managed object interface.” The specification generally
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐31‐
describes a “managed object interface” as an interface associated with a
managed object. For example, it states that: “FIG. 1A also shows managed object
interfaces 122 associated with conversation managed object 108, and managed
object interfaces 124 associated with conversation managed object 110. Referring
to FIG.1B, an embodiment of managed object 148 with managed object interfaces
150 is shown.” (’860, 6:55‐59.) Thus, consistent with its plain and ordinary
meaning in light of the specification, “managed object interface” is an “interface
associated with a managed object (i.e., an object for managing a resource).”
3. “conversation interface”
Claim 24 also recites a “conversation Interface.” As with “managed object
interface” discussed above, the specification describes a “conversation interface”
as an interface associated with a conversation. For example, it states that:
“Conversation interfaces 112, 114 allow manager 102 to access information
regarding the state of messages related to corresponding conversations 104,
106.” (’860, 4:30‐33 (underlining added).) The broadest reasonable construction
of “conversation interface” is an “interface associated with a conversation.”
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐32‐
VII. CLAIMS 1, 5, 7‐10, 12, 15 AND 24‐26 OF THE ’860 PATENT ARE UNPATENTABLE
A. Ground 1 – Claims 1, 5, 7‐10, 12, 15 and 24‐26 Are Invalid Under 35 U.S.C. § 101
Claims 1, 5, 7‐10, 12, 15 and 24‐26 of the ’860 patent are invalid pursuant
to the Supreme Court’s decision in Alice Corp. v. CLS Bank International, 134 S. Ct.
2347, 2354 (2014), because they purport to claim an abstract idea of managing or
monitoring a conversation and providing information about it. As the Supreme
Court emphasized, “the primary object of the patent laws” is to “promote,” “not
inhibit further discovery.” Id. at 2355. To this end, Alice made clear that claims
directed to “abstract ideas” are invalid under § 101 unless they contain an
“inventive concept” that “transforms” the idea into something patentable. Id.
A two‐part test governs the patentability of claims covering an “abstract
idea.” First, the Board must determine whether the claims “are directed to a
patent‐ineligible concept,” such as an abstract idea. Alice, 134 S. Ct. at 2355. If so,
the Board proceeds in the second step to “search for an inventive concept – i.e.,
an element or combination of elements that is sufficient to ensure that the patent
in practice amounts to significantly more than a patent upon the ineligible
concept itself.” Id. (quotation marks and brackets omitted). These “additional
elements” must be “more than simply stating the abstract idea while adding the
words ‘apply it.’” Id. at 2357 (quotation marks and brackets omitted). “Thus, if a
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐33‐
patent’s recitation of a computer amounts to a mere instruction to implement an
abstract idea on a computer, that addition cannot impart patent eligibility.” Id. at
2358 (citation, quotation marks, ellipses and brackets omitted). As explained
below, claims 1, 5, 7‐10, 12, 15 and 24‐26 fail both prongs of the Alice test.
1. The Challenged Claims Are Directed to an Abstract Idea
With respect to the first part of the analysis under Alice, the challenged
claims are directed generally to abstract ideas of managing a conversation and
providing information about it. This Petition will address each claim.
a. Claim 1
Claim 1 is directed to the abstract idea of: (1) managing a conversation, and
(2) providing information about the conversation. As this Petition will explain in
Part VII.A.2 discussing the second step of the Alice analysis, most of the
limitations of claim 1 recite generic and nondescript computer components such
as a “computer processor,” a “interface,” a “manager,” a “Web service,” and a
“conversation managed object.” (Lavian Decl., ¶ 186.) Cutting through these
generic computer components leaves the abstract idea of managing a
conversation, and providing information the conversation.
Perhaps the easiest way to understand the abstract nature of claim 1 is to
analogize it to one of the real‐world “services” identified in the specification. The
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐34‐
Background of the ’860 patent explains that business functions that have long
existed outside the realm of the computers, “such as language translation or
currency conversion, performing calculations for medical claims processing, and
handling certain aspects of travel planning can be implemented in a Web service.”
(’860, 1:36‐40.) “Essentially any transaction or bit of business logic can become a
Web service if it can be accessed and used by another system over a network
such as the Internet.” (’860, 1:40‐43.)
These examples confirm that a “Web service” is essentially an application
of computer technologies to carry out or manage existing real‐world services.
Taking the example of “travel planning” described in the Background (’860, 1:39),
traditional travel planning services typically involve three or more participants – a
customer who wants to plan a trip, a travel agent who makes travel arrangements
for the customer, and the airlines and/or hotels that will provide travel and
accommodations. The customer, travel agent and airlines/hotels will typically
exchange a series of messages about the trip (“conversation”), through postal
mail, e‐mail or any other medium of communication. (Lavian Decl., ¶ 186.)
The messages in this “conversation” may include: (1) a message from the
travel agent to the customer providing various airline or hotel options for a trip,
(2) a message from the customer to the travel agent providing payment
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐35‐
information (such as credit card information), (3) a message from the travel agent
to the hotel or airline to book the requested arrangements, (4) a message from
the agent to the customer relaying confirmation numbers and other information
about the booked hotel and/or airlines. This kind of everyday commercial
exchange obviously requires no computer or Web technology. (Id. ¶ 187.)
The specific limitations of claim 1 further
confirm the abstract nature of the claimed subject
matter. Claim 1 includes a “conversation managed
object” that includes an “interface” and provides
“management information about the conversation
to at least one manager.” Using our travel service
analogy, the claimed “management information”
could consist of entries in a written
communications log that records dates and subjects of messages. By opening the
log book, the user can obtain information about the conversation.
Claim 1 concludes with a requirement that the at least one interface be
configured “to provide information regarding the Web service that contains the
conversation.” Using our travel service analogy, this could simply represent the
name or contact information of the travel agency service and/or the name of the
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐36‐
travel agent who is managing the conversation with the customer.
As this analogy shows, claim 1 is directed at the abstract idea of managing a
conversation, and providing information about the conversation. This abstract
idea relates to basic methods of organizing human communication and exists in
the world separate and independent of any computer or technical application.
b. Claim 5, 7‐9, 12
Dependent claim 5 merely recites that the conversation is “configured to
receive messages, and the at least one interface is further configured to provide
information regarding the last message received by the conversation.” This claim
is directed to the same abstract idea as claim 1 and merely adds identifying the
last received message. Using the travel services analogy above, this information
could be ascertained by visually inspecting the communications log book, which
will identify the last received message in the conversation. (Lavian Decl. ¶ 190.)
Dependent claims 7‐9 and 12 are similarly directed to the same abstract
idea as claim 1. Claim 7 recites the ability to provide information about “the
number of successful messages processed by the conversation.” Claim 8 recites
the “number of failed messages,” claim 9 recites “the total number of messages,”
and claim 12 recites the “total number of failed messages.” Using our travel
service analogy above, this information could be ascertained by visually inspecting
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐37‐
the communications log and counting the messages fitting the claimed categories,
using any “Notes” the agent may have written down about the messages.
c. Claim 10
Claim 10 depends from claim 8 and recites that “the messages are
exchanged via a simple object access protocol (SOAP).” As explained in the
discussion of the second step of the Alice framework, the specification concedes
that SOAP existed in the prior art. (’860, 1:62‐64 (“The SOAP specification is a
universally agreed‐upon protocol that uses XML and optionally HTTP together to
invoke functions exposed in Web services.”); Lavian Decl. ¶¶ 192, 208.)
Notably, this claim does not augment or enhance any of the conversation
management features in claim 1 – it simply requires that the messages be
exchanged using a particular protocol. A protocol in the computer realm is
analogous to a specific spoken language in that it specifies the syntax and other
rules required for communication. This claim simply adds the abstract idea of
exchanging messages that follow agreed‐upon rules.
d. Claim 15
Claim 15 adds the ability to notify “at least one manager when one of the
participants in the conversation sent an unexpected fault message.” This claim
adds very little, conceptually, to claim 1. In any form of communication, whether
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐38‐
electronic or human, there is always a possibility that a message will not be
properly sent or received. Using the travel service analogy, if the agent sends a
facsimile message to the customer but the customer’s fax machine is out of
paper, that might result in a fault message notifying the agent that the message
did not go through. This type of information might also be included in a
“communications log.” In either case, claim 15 is directed to the same abstract
idea as claim 1 of managing a conversation and providing information about it.
e. Claim 24
Independent claim 24 is little more than an amalgam of limitations from
claim 1 and some of the dependent claims discussed above. This claim is directed
at the abstract idea of monitoring messages in a conversation. Claim 24 recites a
“conversation interface” that “includes information for monitoring messages in a
conversation.” As explained above, this concept is an abstract one, as shown by
the exemplary travel agency “communications log” discussed above.
Claim 24 goes on to provide two lists of information, requiring that the
information include “at least one” item from each list. Claim 24 is satisfied, for
example, if the information includes “the total number of messages” and “an
identifier of the conversation.” Both of these limitations merely represent ways
in which the abstract idea can be expressed. As explained in connection with
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐39‐
claim 9 above, providing “the total number of messages” flows from the abstract
idea of monitoring messages in a conversation. Providing an “identifier of the
conversation” reflects the abstract idea of giving a name or label to the
conversation in order to identify it – a requirement of monitoring it. Both of
these limitations can be readily practiced in the “real world” without a computer
using the travel communications log example above.
f. Claim 25
Claim 25 depends from claim 24 and requires that the conversation
interface provide “at least one” of a list of further examples of information about
events such as “a participant in the conversation is not responding.” As explained
for claim 15 above, however, in any form of conversation, whether electronic or
human, there is always a possibility that a participant will fail to respond to a
received message. This claim is therefore directed to the same abstract idea as
claim 24 of monitoring conversations.
g. Claim 26
Claim 26 depends from claim 25 and recites that “the messages are
exchanged via a simple object access protocol (SOAP).” This claim is substantially
the same as claim 10 except that it depends from a different claim. It is directed
at the abstract idea of exchanging messages using agreed‐upon rules.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐40‐
2. Claims 1, 5, 7‐10, 12, 15, 24‐26 Lack an “Inventive Concept”
As explained in by the Federal Circuit, “[t]he second step in the analysis
requires us to determine whether the claims do significantly more than simply
describe th[e] abstract method.” Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715
(Fed. Cir. 2014). Claims 1, 5, 7‐10, 12, 15 and 24‐26 contain no inventive concept
or meaningful limitation sufficient to transform them into something more than
the abstract ideas identified above.
These claims at best describe computer‐implemented systems for
managing or monitoring a conversation, but the technology recited in the claims
is standard and generic. This purported technology is recited in five limitations in
the claims: (1) a “Web service,” (2) a “computer processor” (claim 1), (3) a
“computer program product” and related “computer storage readable medium”
(claim 24), (4) “Simple Object Access Protocol” (SOAP) (dependent claims 10 and
26), and (5) a “manager” (claim 1). This Petition will address each below.
a. “Web Service” (Claim 1)
As explained in Part VI.A, a “Web service” refers to “a service or system
that interacts with another system through the exchange of eXtensible Markup
Language (XML) messages.” Although “XML messages” may on the surface
appear to reflect a unique technology, they do not. XML technology was well‐
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐41‐
known and generic well before May 2003. (Harold, Ex. 1009, at 3 (“[XML] provides
a standard format for computer documents.”).) As explained in XML in a Nutshell,
published more than two years before the ’860 patent was filed, XML had already
become widely used:
XML has become the syntax of choice for newly designed document
formats across almost all computer applications. It’s used on Linux,
Windows, Macintosh, and many other computer platforms.
Mainframes on Wall Street trade stocks with one another by
exchanging XML documents. Children playing games on their home
PCs save their documents in XML. Sports fans receive real‐time game
scores on their cell phones in XML. XML is simply the most robust,
reliable, and flexible document syntax ever invented.
(Harold, Ex. 1009, at Preface, xi.) Each of the examples listed above describes a
“Web service,” i.e. a service or system that interacts with another by exchanging
XML messages. (Lavian Decl. ¶ 200.) There is simply no question that by the time
the ’860 application was filed in May 2003, XML was generic and standard
computer technology. (Id.)
The recitation of a “Web service” in claim 1 illustrates the problem
identified in Alice of patent claims that impermissibly preempt the use of an
abstract idea. As explained by Dr. Lavian, there is no meaningful difference
between a claim covering a technique for “managing a Web service,” as claim 1
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐42‐
dos, and a claim simply covering the abstract idea of “managing a service.”
(Lavian Decl., Ex. 1002, ¶ 201.) This is because, as XML in a Nutshell recognizes, it
is difficult to find any services in the modern era that do not rely on the exchange
of messages through networked computer systems. (Id.)
Take the exemplary “travel agency service” described in Part VII.A.1.a,
above. Decades ago, the “conversations” associated with that service might have
taken place through the exchange of letters, facsimile messages or voice
telephone calls that do not require networked computers. But in the modern era,
many if not all aspects of that service would entail messages exchanged between
networked computers. (Lavian Decl., ¶ 202.) As explained in Chappell, Java Web
Services (2002), published more than a year before the ’860 application was filed,
Web services technology was being used to provide on‐line booking and
integration between rental car services and airlines. (Chappell, Ex. 1007, at 6.)
Web services are far more pervasive today than when Chappell and XML in a
Nutshell were published. (Lavian Decl., ¶ 202.)
The specification further confirms that the “Web service” being managed
may include non‐technological services in the “real world” such as “language
translation or currency conversion, performing calculations for medical claims
processing, and handling certain aspects of travel planning” (’860, 1:37‐39.) The
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐43‐
Background of the specification states that “[e]ssentially any transaction or bit of
business logic can become a Web service if it can be accessed and used by
another system over a network such as the Internet.” (’860, 1:40‐43.)
The fact that a “Web service” involves exchange of messages in XML format
is irrelevant and does not reduce the preemption concerns discussed above. As
the examples from XML in a Nutshell discussed above confirm, XML was so
pervasive and engrained in the delivery of services that a “Web service” cannot
meaningfully be distinguished from the underlying “service” it represents. (Lavian
Decl., ¶ 204.) The XML requirement is nothing more than “limiting the use of an
abstract idea to a particular technological environment,” which is not enough.
Alice, 134 S.Ct. at 2358 (internal quotations omitted; citation omitted).
b. “computer processor” (Claim 1)
As the Federal Circuit has explained, “adding a computer to otherwise
conventional steps does not make an invention patent‐eligible.” Ultramercial,
Inc., 772 F.3d at 717 (citing Alice, 134 S.Ct. at 2357). The specification makes clear
that the claimed “computer processor” is a generic computer component. (’860,
9:5‐15, 10:1‐5; Lavian Decl. ¶ 205.)
c. “computer program product” and “computer storage readable medium” (Claim 24)
These limitations do not recite any specific programming or technical
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐44‐
implementation. Like the “computer processor” of claim 1, they merely recite
generic and known computer storage technology. (’860, 9:16‐19.) This language
on its face could describe any computer software program that has been placed
on a persistent storage medium such as a hard disk drive. (Lavian Decl., ¶ 205.)
d. “SOAP” (Claims 10 and 26)
Dependent claims 10 and 26 require that the messages be exchanged “via a
simple object access protocol (SOAP).” SOAP was not an invention of the ’860
patent, but rather, a known and generic technology. (Lavian Decl., ¶ 208.)
The ’860 patent itself acknowledges that SOAP is “a universally‐agreed
upon protocol.” (’860, 1:62‐64.) As explained by Jake Sturm, Developing XML
Solution (2000), published more than two years before the ’860 application was
filed, SOAP was “an industry standard” that “introduces no new concepts—it’s
built entirely from existing technology.” (Ex. 1006, pp.161, 163 (under “SOAP and
the Request/Response Model”).) For the same reasons as XML described above,
SOAP does not provide any inventive concept or meaningful limitation.
e. “manager” (Claim 1)
As explained in Part VI.D above, the term “manager” refers to a “software
process or system for accessing management features.” Nothing in the claim or
specification requires any special programming or implementation for the claimed
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐45‐
“manager” – it is simply a generic software implementation. (Lavian Decl., ¶ 207.)
3. Other Limitations
None of the other limitations in the claims provides any meaningful
limitation that confers patent eligibility under § 101. This is apparent from the
following table showing the remaining constructions for purposes of this Petition:
Claim Term Broadest Reasonable Construction
“conversation” “a set of related messages for exchange of information”
“managed object” “an object for managing a resource”
“conversation managed object”
“an object for managing a resource that is associated with a conversation”
“interface” “a connection point for communication and/or exchange of information”
“managed object interface” “an interface associated with a managed object (i.e. an object for managing a resource)”
“conversation interface” “an interface associated with a conversation”
None of these terms recites any computer technology or requires any
particular software or programming. The concept of an “interface,” as explained
in Part VI.E.1 above, is simply a connection point for communication and/or
exchange of information, and is basic and generic computer technology. (Lavian
Decl., ¶ 207.) Although the specification describes other technologies that can be
used with the alleged invention including SOAP, WSDL, UDDI (’860, 1:60‐2:20), the
“interface” and “object” limitations in claims 1, 5, 7‐9, 12, 15 and 24‐25 do not
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐46‐
refer to or explicitly require any those technologies.
None of the challenged claims provide any technical detail about how
managing or monitoring a conversation must take place, or how conversation‐
related information must be provided. Claim 1, for example, recites
“management information about the conversation,” and an interface that
“provide[s] information regarding the Web service,” but the claim language does
not require any particular management information be provided. The claim does
not specify any particular format or encoding for the conversation or service‐
related information. And the term “conversation” is defined as simply a “set of
related messages for exchange of information,” and this definition is not on its
face even limited to messages exchanged over a computer network. Claim 24
similarly recites a “conversation interface” that “includes information for
monitoring messages in a conversation.” But just like claim 1, the claim does not
specify any implementation details about the claimed monitoring of messages in a
conversation. (Lavian Decl., ¶¶ 209, 210.)
Finally, the Federal Circuit and the Supreme Court have suggested that the
“machine‐or‐transformation test” can provide a “useful clue” to the second step
of Alice. See Ultramercial, Inc., 772 F.3d at 716 (citation omitted). But in this
case, none of the claims are “tied to a particular machine or apparatus,” or
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐47‐
“transform[]a particular article into a different state or thing.” Id. (citing In re
Bilski, 545 F.3d 943, 954 (Fed. Cir. 2008) (en banc)). The method claims recite no
machine or transformation whatsoever. The claims, as noted above, at best
recite general purpose computer equipment that is insufficient to confer patent
eligibility under § 101. Ultramercial, Inc., 772 F.3d at 716‐17. For all of these
reasons, therefore, the challenged claims do not recite patent eligible subject
matter under 35 U.S.C. § 101.
B. Ground 2 – Claims 1, 5, 7‐9, 12, 15, 24 and 25 are Obvious over Rizzo in view of Jamison
1. Prior Art and Date Qualification for Ground 2
Each limitation of claims 1, 5, 7‐9, 12, 15, 24 and 25 is disclosed or
suggested by Thomas Rizzo, Programming Microsoft Outlook and Microsoft
Exchange (1999) (“Rizzo”) [Ex. 1004] and Scott Jamison et al., Developing
Applications with Exchange 2000 (2001) (“Jamison”) [Ex. 1005]. Rizzo and
Jamison qualify as prior art under at least § 102(b) (pre‐AIA) because they were
published more than one year before the earliest filing on the face of the patent.
2. Brief Summary of the Prior Art Applied in Ground 2
a. Rizzo (Ex. 1004)
Programming Microsoft Outlook and Microsoft Exchange (“Rizzo”) is a 1999
reference book that describes certain aspects of Microsoft’s Exchange server
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐48‐
software, a well‐known software program for providing email, calendaring and
contact management services. Exchange is commonly used in conjunction with
Microsoft Outlook, a popular email client program. (Lavian Decl., ¶¶ 68, 69.)
Exchange and Outlook included a series of application programming
interfaces (or “APIs”) that allowed third party software developers to incorporate
Exchange and Outlook features, including email, calendaring and web‐based
access, into their own applications. (Id. ¶ 69.) Rizzo uses these APIs to create a
web‐based “Helpdesk” application that includes a browser‐based interface for
allowing users to submit a help request. (Rizzo, Ex. 1004, at 381‐82, Fig. 11‐10.)
A help technician can monitor and manage received help requests using a
series of web pages associated with the Helpdesk application. (Id. at 362 (“Help
technicians can, in turn, use their web browser to view and answer help requests
as well as schedule meetings with the users to go on site to solve their
problems.”).) One web page provides a list of received help requests:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐49‐
(Id. at p.391, Fig. 11‐15.)
Each Helpdesk request listed in the page above includes a hyperlink that,
when clicked, takes the technician to a page showing information about the
selected request. (Id. at p.397; see also id., p.396 (“When the technician clicks on
one of the hyperlinks in the rendered list of helpdesk tickets, the application calls
another ASP file, message.asp, to render the actual ticket for the technician.”).)
The technician can also send follow‐up messages to the Helpdesk application and
to the user who submitted the help request. (Rizzo, p.396 (“The technician can
then view a number of different items for the ticket, resolve the ticket, or
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐50‐
schedule a meeting with the customer who submitted the ticket.”); see also id.,
pp.405‐410 (describing functionality for technician to schedule a meeting with
user and to resolve a help request); Lavian Decl. ¶¶ 70‐72.)
b. Jamison
Developing Applications with Microsoft Exchange 2000 (“Jamison”) is a
2001 reference book that, like Rizzo, describes aspects of Microsoft Exchange and
teaches software developers on building distributed and collaborative
applications using Exchange. (E.g., Jamison, p.3.) This Petition cites Rizzo above
for the vast majority of the claim limitations, and relies on Jamison for the “Web
service” limitation in claim 1, and limitations in claim 24 and certain dependent
claims relating to providing information about the number of messages.
3. Claim 1 is Obvious
The preamble of claim 1 recites, “[a] system for managing a conversation in
a Web service.” Rizzo, in combination with Jamison, discloses this.
The “Web service” in Rizzo takes the form of the Helpdesk application. The
Helpdesk application, as explained above, provides web‐based features allowing
users and help desk technicians to create, monitor and otherwise manage
Helpdesk requests. (E.g., Rizzo, p.362 (“The Helpdesk application is a web‐based
application that allows users to submit new help requests. Help technicians can,
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐51‐
in turn, use their web browser to view and answer help requests as well as
schedule meetings with the users to go on site to solve their problems.”).) The
process begins with a user submitting a Helpdesk request form that sends
information to the server. (Rizzo, at 385 (“Once the user fills in the helpdesk
ticket information, such as the problem description, the user clicks the Post Now
button on the HTML form.”).) A Helpdesk technician can then use a browser‐
based interface to view the Helpdesk request or schedule an appointment with
the user. (Id. at 397 (Fig. 11‐16); id. at 396 (“The technician can then view a
number of different items for the ticket, resolve the ticket, or schedule a meeting
with the customer who submitted the ticket.”); Lavian Decl., ¶¶ 77‐80.)
The “conversation” in Rizzo takes the form of a user’s Helpdesk request
and messages relating to that request. An exemplary list of requests is shown
Figure 11‐15 from Rizzo, which allows a help technician to view a list containing
information about help requests, including the “Flag” (or status) of each request:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐52‐
(Rizzo, at p.391, Fig. 11‐15.)
Each of the items in Figure 11‐15 above represents a separate
“conversation,” e.g. a Helpdesk request and other messages relating to that
request. As explained in the discussion of the preamble, each help request can
include a number of messages including follow‐up messages and appointments
with the user who submitted the help request. (Rizzo, p.396 (“The technician can
then view a number of different items for the ticket, resolve the ticket, or
schedule a meeting with the customer who submitted the ticket.”); see also id.,
pp.405‐410 (describing functionality for technician to schedule a meeting with
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐53‐
user and to resolve a help request).) The left column in Figure 11‐15 above shows
a “Flag” with the current status of each request. The list in Figure 11‐15 shows
each help request with an “Opened” status, but Rizzo makes clear that each
request could instead have a “Done” status. (Id. at 408 (“Resolving a helpdesk
ticket consists of setting of the ticket to Done . . .”); id. at 409 (source code for
setting field corresponding to “Flag” to “Done”); Lavian Decl., ¶ 93.)
Rizzo therefore discloses “a system for managing a conversation” in the
Helpdesk service. The specification of the ’860 patent specifically lists
“monitoring” as an activity that qualifies as “managing” a resource (such as a
conversation). (’860, 5:1‐4.) As demonstrated above, the Rizzo discloses
functionality that allows a help technician to monitor a help request
(“conversation”), including viewing the current “Opened” or “Done” status
associated with a help request.
As explained in Part VI.A above, the term “Web service” means a “service
or system that interacts with another system through the exchange of eXtensible
Markup Language (XML) messages.” Rizzo does not expressly disclose that the
Helpdesk application—the “Web service”—exchanges XML‐formatted messages.
But the XML requirement would have been obvious in view of Jamison, which
explains that the Microsoft Internet Explorer web browser could directly
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐54‐
exchange XML‐formatted information with a server system running Microsoft
Exchange. (Jamison, Ex. 1005, p.423 (“Internet Explorer 5 (IE5) and later versions
enable you to use XML and browser development tools against Exchange 2000
Server.”).) Jamison explains that one way to do this was by using a functionality
known as “XMLHTTPRequest.” (Id.)
As explained by Dr. Lavian, “XMLHTTPRequest” refers to a software object
that a web browser could use to send and receive XML‐formatted messages.
(Lavian Decl., ¶¶ 74, 82.) Using this object was straightforward. Jamison provides
source code for an example HTML web page that allows a web browser to (a)
send an XML‐formatted message to a web server, and (b) receive an XML‐
formatted response from the server. (Lavian Decl., ¶ 82 (citing Jamison, pp.424‐
25 (“Retrieving XML with XMLHTTP ¶ The following example shows how you can
construct the body of an HTTP/WebDAV PROPFIND request against a direct
Exchange URL[.]”)).)
It would have been obvious to a person of ordinary skill in the art to
combine XML‐formatted messages as disclosed in Jamison with the web‐based
Helpdesk application in Rizzo. (Lavian Decl., ¶¶ 83‐86.) This would have
predictably resulted in the Helpdesk application of Rizzo (the “Web service”) with
the ability to send and receive XML‐formatted messages as disclosed in Jamison.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐55‐
One of ordinary skill in the art would have considered this a simple combination.
To begin with, XMLHTTPRequest was a standard object built‐in to versions
of Microsoft Internet Explorer, specifically designed to allow the browser to
exchange XML‐formatted messages with a server. (See Jamison, Ex. 1005, at 53
(“[T]he MSXML component . . . ships with Internet Explorer 5.0. You can use the
MSXML component to create and send HTTP requests and parse XML data.”).) A
person of ordinary skill in the art would have found it trivial to use this built‐in
feature to exchange XML‐formatted messages. (Lavian Decl., ¶ 85.)
Jamison provides at least two express motivations to combine. First, it
discloses a specific use of the standard XMLHTTPRequest object to send XML‐
formatted messages to a Microsoft Exchange server – the same implementation
Rizzo describes. (Lavian Decl.,¶ 86 (citing Jamison, at pp.424‐25).)
Second, Jamison touts advantages of XML and observes the “hype
surrounding XML.” (Jamison, at 421.) Jamison further explains benefits of XML
by observing that “XML is powerful because it is simple, interoperable, and open.”
(Id.) One of ordinary skill in the art would therefore have been motivated to
combine Rizzo with Jamison to provide a Helpdesk application that provides a
“Web service” that exchanges XML‐formatted messages. (Lavian Decl., ¶ 86.)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐56‐
a. “a computer processor” (1[a])
The first limitation of claim 1 following the preamble recites “a computer
processor.” Rizzo describes the operation of Microsoft’s Exchange Server
software and a Helpdesk application. One of ordinary skill in the art would have
understood that, in order to execute the software described in Rizzo, the system
would have required at least one processor. (Lavian Decl., ¶ 97.) Moreover,
Jamison expressly discloses that the Exchange software requires a “133MHz or
high‐speed Pentium‐compatible CPU” (i.e., computer processor). (Jamison, p.12.)
b. “a conversation managed object executable on the computer processor, wherein the conversation managed object includes at least one interface configured to provide management information about the conversation to at least one manager” (1[b]‐1[c])
Rizzo also discloses limitations [b] and [c] of claim 1. The diagram shown at
the right from Dr. Lavian’s
declaration helps illustrate the
mapping of Rizzo to the claim
limitations. (Lavian Decl., ¶ 95.)
As reflected in the yellow
highlighted boxes, the “conversation managed object” in Rizzo takes the form of
two software components: (1) a series of Active Serve Page (“ASP”) files for the
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐57‐
Helpdesk application, and (2) an Internet Server Application Programming
Interface (“ISAPI”) that executes the ASP files to create the Helpdesk web pages.
More specifically, Rizzo describes a series of Active Server Pages (“ASP”)
files that provide the Helpdesk web pages that enable technicians to monitor and
manage help requests (“conversation”). The term “ASP” or “Active Server Pages”
refers to a technology provided by Microsoft for developers to build web‐based
applications. As explained by Dr. Lavian, and in Rizzo, an ASP file is typically a text
file that contains Hypertext Markup Language (HTML) statements and program
instructions (a “script”). (Lavian Decl., ¶ 101.) These ASP files are processed by
the ISAPI, another server software component, to generate a web page to send to
a requesting web browser. (Id.; Rizzo, at p.217 (“When you install IIS, an Internet
Server Application Programming Interface (ISAPI) component is installed that
processes all files with an .asp extension. This ISAPI component parses the ASP file
and executes the appropriate script.”).) The ASP files and ISAPI component
disclose a “conversation managed object,” as recited in claim 1.
Rizzo further discloses that the conversation managed object “includes at
least one interface,” as recited in the claim. The “interface” in Rizzo takes the
form of the ISAPI component discussed above.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐58‐
Rizzo also discloses that the ISAPI component (the “interface”) is
“configured to provide management information about the conversation to at
least one manager.” Referring back to Dr. Lavian’s diagram at the right, the
“manager” in Rizzo takes the
form of the web pages and web
browser that allow a technician
to monitor and manage help
requests. Rizzo explains that the
ISAPI component is responsible for processing the ASP files generate to the actual
web pages that are presented in the browser:
When you install IIS, an Internet Server Application Programming
Interface (ISAPI) component is installed that processes all files with
an .asp extension. This ISAPI component parses the ASP file and
executes the appropriate script. Second, the actual script is
processed on the web server. The processed results can include
client‐side scripting code but for the most part is just simple HTML.
(Rizzo, p.217 (underlining added); id. at pp.5‐6; Lavian Decl., ¶ 102.)
One of the web pages that the ISAPI component generates by parsing ASP
files is shown in Figure 11‐15 (at the right). This page was generated by parsing a
file called “render.asp,” which is visible in the URL in the address bar. (Rizzo, at
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐59‐
p.391, Fig. 11‐15; id. at p.392 (describing
parsing of “render.asp file for the Helpdesk
application”).) This web page shows a list of
current help requests (“conversations”) and
identifies the current status (e.g. “Opened”)
for each request. (Rizzo, at p.391.)
These disclosures show that the ISAPI component (the “interface”) is
“configured to provide management information about the conversation to at
least one manager.” The “management information” includes entries on the web
page about each help request (“conversation”), including its current “Opened” or
“Done” status. This information is provided through pages in the browser (the
“manager”). (Lavian Decl., ¶ 104.) Rizzo therefore discloses claim 1[b] and 1[c].
c. “and the at least one interface is configured to provide information regarding the Web service that contains the conversation.” (1[d])
Rizzo also discloses all aspects of claim 1[d]. Rizzo discloses that the ISAPI
component (the “interface”) provides information about the Helpdesk application
(“Web service”) that contains the conversation. The “information regarding the
Web service” in Rizzo takes the form of an indication of the number of help
requests received by the Helpdesk application. This information is reflected in
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐60‐
Figure 11‐15, reproduced in relevant part below:
(Rizzo, at p.391 (Fig. 11‐15) (partial figure shown; “Page 1 of 1” annotation
added).) Each help request is shown as a row in Figure 11‐15. The figure has a
textual note that has been enlarged, “Page 1 of 1,” indicating that the Helpdesk
application has received only one page of requests.
Although the web page in Figure 11‐15 shows only one page of information,
Rizzo makes clear that multiple pages may be displayed. “If the number of help
tickets exceeds the RowsPerPage property, the render.asp file for the Helpdesk
application will display graphical navigation arrows as well as text indicating the
current page of information.” (Id., at p.395.) The default number of rows per
page in the Helpdesk application is 25. (Id. (“By default, CDO will break the
content at every 25 rows in the HTML table . . . You can change the default
number of rows rendered by setting the RowsPerPage property . . . .”).)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐61‐
Rizzo therefore discloses that the ISAPI component “is configured to
provide information regarding the Web service that contains the conversation.”
The Helpdesk page shown in Figure 11‐15 indicates that only one page of requests
has been received (which by default means that the number of requests is no
more than 25). (Id.) This qualifies as information “regarding the Web service that
contains the conversation” because it is about the Helpdesk application that
contains the help requests.
4. Claims 5, 7‐9, 12, and 15 are Obvious
Claims 5, 7‐8, 12 and 15 all depend directly or indirectly from claim 1
addressed above. These claims recite the ability of the interface to provide
additional types of basic numerical counts about messages. In particular, these
claims recite the “last fault message returned from the conversation” (claim 5),
“number of successful messages processed by the conversation” (claim 7),
“number of failed messages processed by the conversation” (claim 8), “total
number of messages for the conversation” (claim 9), “total number of failed
messages processed for the conversation” (claim 12), and an “unexpected fault
message” (claim 15). As explained by Dr. Lavian, it would have been trivially
obvious to adapt the claimed “interface” in Rizzo to provide this information.
(Lavian Decl., ¶¶ 150, 151.)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐62‐
a. Claims 5 and 15 (“Fault Message” Claims)
Claim 5 depends from claim 1 and recites: “The system of claim 1, wherein
the conversation is further configured to receive messages, and the at least one
interface is configured to provide information regarding the last fault message
returned from the conversation.” Claim 15 depends from claim 1 and similarly
recites notifying “the at least one manager when one of the participants in the
conversation sent an unexpected fault message.”
With respect to the first part of claim 5, Rizzo clearly discloses that “the
conversation is further configured to receive messages.” As explained above,
when a new help request is posted to the Helpdesk application, a Message object
is created at the server for storing data associated with the request. (E.g., Rizzo,
pp.385‐86 (describing posting a help request and creating a new Message object
and providing sample source code).) The Message object and its associated data
are subsequently used in order for other messages related to that help request to
be sent and received. (E.g., Rizzo, p.391 (Fig. 11‐15), p.392 (“The application then
sets the DataSource property for the container renderer to the Messages
collection in the Helpdesk folder.”).)
Rizzo also discloses that the interface provides the fault message
information recited in claims 5 and 15. For example, a help technician can send a
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐63‐
message to the Helpdesk application to create an appointment with a user. (E.g.,
Rizzo, p.405.) But if an error occurs at the server while creating the appointment,
an error response message is sent to the browser (“manager”):
The final step when you create any meeting request is to call the
Send method on the MeetingItem object, which sends the request to
the recipients you invited to the meeting. If any of the properties you
set are incorrect or empty, CDO will return an error after calling
Send. For this reason, the code checks the Err object in VBScript.
Depending on whether or not an error occurred, the JavaScript client
code will display a success or an error message.
(Rizzo, p.407 (underlining added).)
This error message qualifies as the “last fault message” (claim 5) because it
relates to a help technician’s most recent activity. It also qualifies as an
“unexpected fault message” (claim 15) because the appointment was requested
by the help technician who obviously would have expected the request to be
processed correctly. (Lavian Decl., ¶ 156.) Finally, because the ISAPI component
(the “interface”) processes the Helpdesk application ASP files to create the output
for the requesting web browser, the “interface” in Rizzo provides the claimed
fault message information. Claims 5 and 15 are therefore obvious.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐64‐
b. Claims 7‐9 and 12 (“Number of Messages” Claims)
Claim 7 recites: “The system of claim 1, wherein the conversation is further
configured to receive messages, and the at least one interface is configured to
provide information regarding the number of successful messages processed by
the conversation.” Claim 8 is similar but instead recites “the number of failed
messages,” claim 9 further recites “the total number of messages,” and claim 12
recites “the total number of failed messages,” similar to claim 8.
Rizzo does not appear to expressly disclose that the Helpdesk application
and ISAPI component includes the pieces of information recited in these claims.
But these limitations would have been obvious in view of Jamison, which discloses
a threaded discussion feature supported by Microsoft Exchange Server. Jamison
explains that a discussion, “sometimes referred to as a conversation,” is “a group
of related messages.” (Jamison, p.265 (italics in original).) Threaded discussions,
and their associated messages, can be monitored via a graphical interface, as
shown below:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐65‐
(Jamison, Ex. 1005, p.266 (enlargement added).) As the figure above and
accompanying explanation in Jamison make clear, the graphical display includes
information about the total number of messages in a particular conversation. The
disclosures Rizzo in view of Jamison render obvious claims 7‐9 and 12.
Claims 7 recites the “number of successful messages.” This claim is
disclosed or suggested by Jamison, which shows an exemplary web page above
showing the number of messages (“items”) successfully received in each
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐66‐
conversation. It would have been obvious to one of ordinary skill in the art, in
view of the disclosures of Jamison, that the Helpdesk application screen in Rizzo
(Figure 11‐15), could have been adapted to include information regarding the
number of messages successfully received as recited in claim 7. This would have
predictably resulted in the HTML web pages in Rizzo that further displays the
number of successful messages associated with each help request. (Lavian Decl.
¶ 162.) One of ordinary skill in the art would have also been motivated to add
this feature to allow the technician to monitor the volume of message traffic
associated with a help request. (Id. ¶ 165.)
Claims 8 and 12 both recite that the interface provides information
regarding the “number of failed messages.” Rizzo and Jamison render these
claims obvious for the same reasons as claim 7 discussed above. Rizzo discloses
the ability to distinguish between successful and failed messages. (E.g., Rizzo,
pp.407‐08 (“Depending on whether or not an error occurred, the JavaScript client
code will display a success or error message.”).) It would have been obvious to
adapt the interface of Rizzo to provide information regarding the number of failed
messages processed by the conversation. As explained by Dr. Lavian, the benefits
of providing this type of information were well‐known to persons of ordinary skill
in the art. (Lavian Decl., ¶ 165.) By monitoring the number of failed messages, a
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐67‐
user could more efficiently determine whether the Helpdesk application was
operating correctly. (Id.) Rizzo explains, for instance, that “[i]f you program like
me, your applications probably don’t work correctly the first time you run them”
and notes the Microsoft created, among other things, “error‐trapping tools” and
“logging features” to identify errors. (Rizzo, p.474.) It would have been obvious to
a person of ordinary skill in the art to adapt the interface of Rizzo to provide not
only the total number of messages in a conversation, but also the number of
failed messages in a conversation. The combination would have predictably
resulted in the Helpdesk application of Rizzo improved by providing information
regarding failed messages to more effectively operate and manage the Helpdesk
application. (Lavian Decl. ¶ 166.)
Turning finally to claim 9, which recites “the total number of messages for
the conversation,” this claim would have been obvious over Rizzo in view of
Jamison for the same reasons articulated above. A person of ordinary skill in the
art would have understood that the claimed total number could have been
calculated by adding the number of successful and failed messages. The rationale
and motivation for this combination are the same as claims 7 and 8 above.
5. Claim 24 is Obvious
Claim 24 is similar in many respects to claim 1, but lists the elements in
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐68‐
slightly different order and adds limitations relating to conversation monitoring
information (e.g., number of messages) that are recited in the dependent claims
addressed above. Rizzo in view of Jamison discloses or suggests all limitations of
claim 24 for many of the same reasons as claim 1. As fully explained for claim 1
above, Rizzo and Jamison are fully combinable, and it would have been obvious to
a person of ordinary skill to combine Rizzo with the disclosures of Jamison.
The preamble of claim 24 recites, “[a] computer program product tangibly
embodied in a computer storage readable medium.” As explained in connection
with claim 1[a] above, Rizzo discloses a Helpdesk application (i.e., “computer
program product”) that runs on a server computer. One of ordinary skill in the art
would have understood that, in order for the server computer to execute the
software disclosed in Rizzo, the system would have required a “computer storage
readable medium” to store the software. (Lavian Decl., ¶ 121.) Moreover,
Jamison discloses that the Exchange software requires at a minimum a computer
having “2GB of hard disk space with a minimum of 1GB free space” (i.e., a
“computer storage readable medium”). (Jamison, p.12; Lavian Decl. ¶ 122.)
a. “conversation interface” limitations (24[a], 24[b])
Claim 24 recites a “conversation interface,” followed by a “managed object
interface,” and then ends with lengthy “wherein” clause that refers back to the
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐69‐
“conversation interface.” In the interest of ease of reading and to keep common
claim limitations on one place, this Petition will first address the “conversation
interface” limitations, and then address the “managed object” term.
i. “a conversation interface . . . wherein the conversation interface includes information for monitoring messages in a conversation” (24[a][b])
The “conversation interface” in claim 24 is substantially similar, for
purposes of the application of the claims to Rizzo and Jamison, to the “interface”
of claim 1 discussed above. The diagram at the right shows how this Petition
maps Rizzo to claim 24. The
“conversation interface” takes
the form of the highlighted
ISAPI component (which is also
the “interface” of claim 1).
As explained in Part VII.B.3.b above, the ISAPI component processes ASP
files to generate Helpdesk web pages showing management information about
the help request (“conversation”). An example of such a page is shown in Figure
11‐15 shown in relevant part below, which displays information about a help
request (“conversation”) initiated by Thomas Rizzo:
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐70‐
(Rizzo, p.391 (Fig. 11‐15) (partial figure).)
The web page above includes information for monitoring an initial help
request message and its related subsequent messages. The entry above, for
example, provides information that an initial help request message was sent by
Thomas Rizzo on December 29, 1998, indicates the subject the message, and
states whether a help technician has sent a message to mark the help request as
resolved (i.e., “Opened” or “Done”). (Id.)
The “conversation interface” in Rizzo therefore includes “information for
monitoring messages in a conversation.” The ISAPI interface, by providing the
information on the page discussed above, facilitates the technician in monitoring
the messages relating to the help request.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐71‐
ii. “…including at least one of the number of failed messages; the number of successful messages; the total number of messages; the last message received by a resource; the last fault message received by the resource” (Claim 24[b1])
Rizzo does not appear to expressly disclose that the information provided
by the ISAPI component (“conversation interface”) includes any of the pieces of
information identified in claim 24[b1]. But as explained for dependent claims 7
and 9 above, this information is disclosed or suggested by Jamison.
Dependent claims 7 and 9 discussed above recite, respectively, that the
interface provides information regarding “the number of successful messages
processed by the conversation,” and “the total number of messages for the
conversation.” These two claims match categories of information recited in claim
24[b1] (“the number of successful messages; the total number of messages”).
Accordingly, for the reasons explained for claims 7 and 9 above, claim 24[b1] is
disclosed or suggested by Rizzo in view of Jamison. (Jamison, Ex. 1005, at p.266;
see also analysis in Part VII.B.4.b for dependent claims 7 and 9.)
iii. “and; at least one of the identity of resources participating in the conversation; the number of resources participating in the conversation; an identifier of the conversation; and an identifier of the resource that contains the conversation interface.” (24[b2])
The final portion of claim 24[b] recites that the “information for monitoring
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐72‐
messages in a conversation” includes “at least one of” several pieces of
information including “an identifier of the conversation.” The “identifier of the
conversation” in Rizzo takes the form of a unique identifier that is incorporated
into the URL of a help request appearing on the Helpdesk page.
In particular, as explained above, the Helpdesk application generates a web
page having a hyperlinked list of help requests, one hyperlink for each help
request. (E.g., Rizzo, p.391 (Fig. 11‐15).) Rizzo discloses that each hyperlink
contains information that uniquely identifies the help request, i.e., “an identifier
of the conversation”:
Use the %obj% token when you want to place the unique identifier
for the item as a string in your HTML. This token is used in the
Helpdesk application so that the hyperlink on the third column
passes the unique identifier for the ticket to the next ASP file,
framemsg.asp.
(Rizzo, p.394 (underlining added); see generally id., pp.392‐96 (explaining source
code for render.asp file).) Rizzo thus discloses this limitation. (Lavian Decl. ¶ 143.)
b. “a managed object interface associated with the conversation interface” (Claim 24[b])
The second limitation of claim 24 recites “a managed object interface
associated with the conversation interface.” There is no further mention of this
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐73‐
interface in claim 24. The claim does not expressly recite any particular function
this interface must perform, it simply requires that it exist. In any event, Rizzo
discloses this limitation.
As explained in Part VI.E.2 above, a “managed object interface” is “an
interface associated with a managed object (i.e. an object for managing a
resource).” Using the diagram above (reproduced again at the right), the
“managed object interface”
in Rizzo takes the form of
the highlighted ActiveX Data
Object (“ADO”) component,
which serves as a connection
point for accessing a database (“managed object”).
Rizzo explains that “ADO allows you to connect to many types of
databases.” (Rizzo, p.230.) The Helpdesk application uses ADO to connect to a
Microsoft Access database. (E.g., Rizzo, p.396 (“[The Helpdesk application] uses
ADO and queries an Access database.”).) ADO therefore qualifies as an
“interface” because it comprises a connection point for communication and/or
exchange of information. (See Part V.D.5.a above (construction of “interface”).)
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐74‐
ADO also qualifies as a “managed object interface” because it is associated
with the database (the “managed object”). The database qualifies as a “managed
object” because it manages data about the computer systems of users who
submit help requests. (Rizzo, p.398 (“After establishing a connection [to the
database], three queries are executed against three database tables to figure out
the machine configuration of the current user. This is accomplished by using the
name of the user retrieved from the Helpdesk ticket”); see also id., p.396 (under
“Rendering the Actual Helpdesk Ticket”); Lavian Decl., ¶ 147.) For all of these
reasons, Rizzo and Jamison disclose or suggest each limitation of claim 24.
6. Claim 25 is Obvious
Claim 25 depends from claim 24 and recites that the conversation interface
includes information about “at least one” of a list of events, such as “receipt of an
incorrect message” and “a participant in the conversation sent a fault message.”
Rizzo and Jamison disclose information about both of these events. As explained
in Part VII.B.4.a regarding claims 5 and 15 (the “fault message” claims), Rizzo also
discloses that the interface provides fault message information. For example, a
help technician can send a message to the Helpdesk application to create an
appointment with a user. (E.g., Rizzo, p.405.) But if an error occurs at the server
while creating the appointment, an error response message is sent to the
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐75‐
browser. (Id. at p.407 (“If any of the properties you set are incorrect or empty,
CDO will return an error after calling Send. . . Depending on whether or not an
error occurred, the JavaScript client code will display a success or an error
message.”) (underlining added).) Because the ISAPI component (the
“conversation interface”) processes the Helpdesk application ASP files to create
the output for the requesting web browser, the “conversation interface” in Rizzo
provides the claimed event‐related information. (Lavian Decl. ¶¶ 154‐56.)
C. Ground 3 – Claims 10 and 26 are Obvious over Rizzo in view of Jamison and in further view of Sturm
1. Prior Art and Date Qualification for Ground 3
Each limitation of claims 10 and 26 is disclosed or suggested by Rizzo,
Jamison and Jake Sturm, Developing XML Solutions (2000) (“Sturm”) [Ex. 1006].
Rizzo and Jamison were discussed in Part VII.B above. Sturm qualifies as prior art
under at least § 102(b) (pre‐AIA) because it was published more than one year
before May 14, 2003, the earliest filing on the face of the ’860 patent.
2. Claims 10 and 26 are Obvious
Claims 10 and 26 depend from claims 8 and 25, respectively, and require
that messages be “exchanged via the simple object access protocol (SOAP).”
Claims 8 and 25, from which claims 10 and 26 depend, are obvious for the reasons
stated above. As Dr. Lavian explains, claims 10 and 26 recite nothing of
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐76‐
significance. (Lavian Decl., ¶ 170.) The Simple Object Access Protocol (SOAP) was
not an invention of the ’860 patent, but a well‐known technique for exchanging
XML messages in web services. (Id.) As explained in Sturm, Developing XML
Solutions (2000) [Ex. 1006], “Simple Object Access Protocol (SOAP) version 1.1 is
an industry standard designed to improve cross‐platform interoperability using
the Web and XML.” (Sturm, Ex. 1006, p.161.) Even SOAP itself “introduces no new
concepts—it’s built completely from existing technology.” (Sturm, p.163.)
Neither Rizzo nor Jamison appears to expressly disclose exchanging XML
messages using SOAP. However, this is fully disclosed by Sturm, which explains
that “[y]ou could use the XMLHTTPRequest object to create applications that
build and send SOAP messages to the server.” (Sturm, pp.247‐48; see also id.,
p.249 (“In a real application, you could build the XML document using . . . JScript
or VBScript in a browser application with the values that the user has inputted
into the browser form.”); Lavian Decl., ¶ 171.)
It would have been obvious to one of ordinary skill in the art to combine
Sturm with Rizzo and Jamison, predictably resulting in a Helpdesk application that
used SOAP to exchange messages in a conversation. (Lavian Decl., ¶ 172.) A
person of ordinary skill in the art would have perceived no technical obstacle to
making this combination and, in fact, would have readily appreciated the
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐77‐
combinability of the teachings of these references. (Id.) As explained above, for
example, Jamison teaches that one way for a web browser to exchange XML with
a server is by using an XMLHTTPRequest object. (E.g., Jamison, pp.423, 424‐25.)
Sturm makes clear that “[y]ou could use the XMLHTTPRequest object to create
applications that build and send SOAP messages to the server.” (Sturm, pp.247‐48
(underlining added); see also id., p.249 (“In a real application, you could build the
XML document using . . . JScript or VBScript in a browser application with the
values that the user has inputted into the browser form.”).)
Sturm, moreover, provides express motivations to make this combination.
(Lavian Decl., ¶ 173.) As noted above, Sturm explains that SOAP is an “industry
standard” that has been designed to “improve cross‐platform interoperability.”
(Sturm, Ex. 1006, p.161.) “[F]or larger systems expanding across computers with
multiple platforms,” Sturm explains, “we need a way to enable objects to
communicate with each other. The solution to this problem is SOAP.” (Sturm,
p.162.) Thus, for all of these reasons, the exchange of messages using SOAP as
recited in claims 10 and 26 would have been obvious to a skilled artisan.
VIII. CONCLUSION
The Petitioner respectfully requests institution of CBM of claims 1, 5, 7‐10,
12, 15 and 24‐26, and a finding that those claims are unpatentable.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐78‐
Dated: April 2, 2015 COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (650) 843‐5001 Fax: (650) 849‐7400
Respectfully submitted,
By: /Heidi L. Keefe/ Heidi L. Keefe Reg. No. 40,673 Counsel for Petitioner
ServiceNow, Inc.
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐1‐
CERTIFICATE OF SERVICE I hereby certify, pursuant to 37 C.F.R. §§ 42.6 and 42.105, that a complete copy of the attached PETITION FOR COVERED BUSINESS METHOD (CBM) PATENT REVIEW OF U.S. PATENT NO. 7,945,860, including all exhibits (Nos. 1001‐1013) and related documents, are being served via Federal Express on the 2nd day of April 2015, the same day as the filing of the above‐identified document in the United States Patent and Trademark Office/Patent Trial and Appeal Board, upon the Patent Owner by serving the correspondence address of record with the USPTO as follows:
Hewlett‐Packard Company Intellectual Property Administration 3404 East Harmony Road Mail Stop 35 Fort Collins, CO 80528
and, upon counsel of record for the Patent Owner in the litigation pending before the U.S. District Court for the Northern District of California entitled Hewlett‐Packard Company v. ServiceNow, Inc., Case No. 14‐CV‐00570 BLF (N.D. Cal. filed Feb. 6, 2014) as follows:
Mark D. Flanagan, Esq. WILMER CUTLER PICKERING HALE AND DORR LLP 950 Page Mill Road Palo Alto, CA 94304
Petition for Covered Business Method (CBM) Review of U.S. Patent No. 7,945,860
‐2‐
DATED: APRIL 2, 2015 COOLEY LLP ATTN: Heidi L. Keefe Patent Docketing 1299 Pennsylvania Ave. NW, Suite 700 Washington, D.C. 20004 Tel: (650) 843‐5001 Fax: (650) 849‐7400
/ Heidi L. Keefe / Heidi L. Keefe Reg. No. 40,673