Petition for Covered Business Method (CBM) Review Patent...

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


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)


‐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.


‐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).


‐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.


‐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


‐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


‐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


‐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


‐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


‐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


‐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).


‐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,


‐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


‐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:


comprising:

[a] a computer processor; and


processor, wherein:





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


‐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.


‐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.”


‐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


‐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.”).)


‐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.)


‐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:


‐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


‐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:


comprising:

[a] a computer processor;


processor, wherein:





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:


‐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


‐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


‐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:


‐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.”


‐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).)


‐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


‐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.


‐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


‐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


‐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.”


‐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


‐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


‐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


‐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


‐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


‐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


‐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


‐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.


‐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‐


‐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


‐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


‐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


‐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


‐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


‐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


‐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


‐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:


‐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


‐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,


‐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:


‐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


‐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


‐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.


‐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.)


‐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


‐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.


‐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


‐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


‐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 . . . .”).)


‐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.)


‐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


‐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.


‐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:


‐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


‐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


‐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.


Claim 24 is similar in many respects to claim 1, but lists the elements in


‐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


‐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:


‐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.


‐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


‐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


‐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”).)


‐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.


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


‐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


‐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


‐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.


‐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.


‐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


‐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

Date post:	18-Feb-2018
Category:	Documents
Upload:	hoangdiep
View:	216 times
Download:	1 times

Petition for Covered Business Method (CBM) Review Patent...

Documents