Petition for Inter Partes Review of Patent 7,945,860...

Petition for Inter Partes 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 INTER PARTES REVIEW

OF U.S. PATENT NO. 7,945,860

Inter Partes Review No. 2015‐00716

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.103 ........................................................ 2

III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. §§ 42.104 AND 42.108 .................................................................................. 2

A. Grounds for Standing under 37 C.F.R. § 42.104(a) ............................. 2

B. Identification of Challenge under 37 C.F.R. § 42.104(b) and Statement of Precise Relief Requested .............................................. 3

C. Requirements for Inter Partes Review 37 C.F.R. § 42.108(c) .............. 4

IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY ........................... 5

A. Early History of Conducting Business over the Web ........................... 5

B. Modern “Web Services” ..................................................................... 6

V. SUMMARY OF THE CLAIMED SUBJECT MATTER ........................................... 7

A. The Specification of the ’860 Patent ................................................... 7

B. The Challenged Claims of the ’860 Patent .......................................... 9

VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3) ............................ 11

A. “Web service” ................................................................................... 11

B. “conversation” .................................................................................. 12

C. “managed object” and “conversation managed object” ................. 12

1. “managed object” .................................................................. 13

2. “conversation managed object” ............................................. 14

D. “manager” ........................................................................................ 15

Table of Contents (continued)

Page

‐ii‐

E. “Interface,” “Managed Object Interface,” “Service Interface” ......... 17

1. “interface” .............................................................................. 17

2. “managed object interface” ................................................... 19

3. “conversation interface” ........................................................ 19

VII. CLAIMS 1, 5, 7‐10, 12, 15 AND 24‐26 OF THE ’860 PATENT ARE UNPATENTABLE .......................................................................................... 20

A. Ground 1 – Claims 1 and 24 Are Obvious Over the Collaborate References in view of Fox ................................................................. 20

1. Prior Art and Date Qualification for Ground 1 ........................ 20

2. Brief Summary of the Prior Art Applied in Ground 1 .............. 22

3. The Collaborate References Are Properly Combinable .......... 25

4. Claim 1 .................................................................................... 27

a. “a computer processor” (Claim 1[a]) ............................ 29

b. "a conversation managed object executable on the computer processor" (Claim 1[b]) .......................... 30

c. “the conversation managed object includes at least one interface configured to provide management information about the conversation to at least one manager” (Claim 1[c]) .......................... 33

d. “the at least one interface is configured to provide information regarding the Web service that contains the conversation” (Claim 1[d]) ....................... 40

5. Claim 24 .................................................................................. 42

a. “conversation interface” limitations (Claims 24[a], 24[b]) ............................................................................ 43

i. “a conversation interface” (Claim 24[a]) ............ 43

Table of Contents (continued)

Page

‐iii‐

ii. “wherein the conversation interface includes information for monitoring messages in a conversation” (Claim 24[b]) ........ 45

iii. “…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;” (Claim 24[b1]) ..................................................... 47

iv. “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.” (Claim 24[b2]) ................................... 49

b. “a managed object interface associated with the conversation interface” (Claim 24[b]) .......................... 50

B. Ground 2 – Claims 5, 7‐9, 12, 15 and 25 Are Obvious Over the Collaborate References in view of Fox and Staub ............................ 54

1. Claims 5, 15 and 25 (“Fault Message” Claims) ....................... 55

2. Claims 7‐9 and 12 (“Number of Messages” Claims) ............... 58

C. Ground 3 – Claims 10 and 26 Are Obvious Over the Collaborate References in view of Fox, Staub and Scribner ............. 59

VIII. CONCLUSION .............................................................................................. 60


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 Introducing BEA WebLogic Collaborate, BEA Systems, Inc., July 2001

1005 Administering BEA WebLogic Collaborate, BEA Systems, Inc., July 2001

1006 Programming BEA WebLogic Collaborate Management Applications, BEA Systems, Inc., July 2001

1007 Excerpts from David A. Chappell et al., Java Web Services (2002), pp. 1‐12

1008 Excerpts from David Fox et al., Web Publisher’s Construction Kit with HTML 3.2 (1996), pp.480‐544

1009 Excerpts from Kenn Scribner et al., Applied SOAP: Implementing .NET XML Web Services (2001), pp.10‐48

1010 Excerpts from Elliotte Rusty Harold et al., XML in a Nutshell (2001), pp. xi‐xvi, 3‐10

1011 BEA Unveils Comprehensive Web Services Strategy and Support For Widest Range of Web Services Standards in the Industry, PR Newswire, Feb. 26, 2001

1012 Microsoft Computer Dictionary (5th ed. 2002), pp.279‐80

1013 BEA and Gauss Interprise Announce Strategic Relationship, Canadian Corporate Newswire, Aug. 27, 2001

1014 Affidavit of Christopher Butler, dated January 15, 2015

1015 U.S. Patent No. 6,891,930 to David B. Staub et al.


‐1‐

Petitioner ServiceNow, Inc. (“Petitioner”) respectfully submits this Petition

for Inter Partes Review of claims 1, 5, 7‐10, 12, 15 and 24‐26 of U.S. Patent No.

7,945,860 [Ex. 1001] (“the ’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 ’860 patent is the subject of one pending litigation involving the

Petitioner: Hewlett‐Packard Company v. ServiceNow, Inc., Case No. 14‐CV‐00570

BLF (N.D. Cal. filed Feb. 6, 2014), in which the patent owner contends that the

Petitioner infringes the claims of the ’860 patent challenged in this Petition. The

Petitioner was served with the Complaint in that action on February 7, 2014.

C. Lead and Back‐Up Counsel under 37 C.F.R. § 42.8(b)(3)

Petitioner provides the following designation of counsel.

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


‐2‐

D. Service Information

This Petition is being personally served at 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).

II. PAYMENT OF FEES ‐ 37 C.F.R. § 42.103

This Petition requests review of eleven (11) claims of the ’860 patent.

Accordingly, a payment of $23,000 is submitted herewith. This payment is

calculated based on a $9,000 request fee (for up to 20 claims), and a post‐

institution fee of $14,000 (for up to 15 claims). See 37 C.F.R. § 42.15(a). This

Petition meets the fee requirements of 35 U.S.C. § 312(a)(1).

III. REQUIREMENTS FOR INTER PARTES REVIEW UNDER 37 C.F.R. §§ 42.104 AND 42.108

A. Grounds for Standing under 37 C.F.R. § 42.104(a)

The Petitioner certifies that the ’860 patent is available for inter partes

review and that the Petitioner is not barred or otherwise estopped from

requesting inter partes review on the grounds identified in the present Petition.

The Petitioner is unaware of any previous petition for inter partes review with


‐3‐

respect to the ’860 patent.

B. Identification of Challenge under 37 C.F.R. § 42.104(b) and Statement of Precise Relief Requested

The Petitioner respectfully requests that the Board initiate inter partes

review of claims 1, 5, 7‐10, 12, 15 and 24‐26 based on the following prior art:

Ex. No. Description of Document

1003 BEA Systems, Inc., Introducing BEA WebLogic Collaborate (July 2001)

1004 BEA Systems, Inc., Administering BEA WebLogic Collaborate (July 2001)

1005 BEA Systems, Inc., Programming BEA WebLogic Collaborate Management Applications (July 2001)

1008 David Fox et al., Web Publisher’s Construction Kit with HTML 3.2 (1996)

1009 Kenn Scribner et al., Applied SOAP: Implementing .NET XML Web Services (2001)

1015 U.S. Patent No. 6,891,930 to David B. Staub et al.

The first five references listed above (Exs. 1003‐1005, 1008, 1009) qualify as

prior art under 35 U.S.C. § 102(b) (pre‐AIA) because each reference was published

more than one year before May 14, 2003, the filing date of the ’860 patent. The

sixth reference (Ex. 1015) qualifies as prior art under at least 35 U.S.C. § 102(e)

(pre‐AIA) because it issued from an application filed on December 17, 1999. The

grounds on which this Petition is based are listed in the table below.


‐4‐

Ground Claims Basis for Challenge

1 1, 24 Unpatentable over the Collaborate References in view of Fox, under 35 U.S.C. § 103(a)

2 5, 7‐9, 12, 15, 25

Unpatentable over the Collaborate References in view of Fox and Staub, under 35 U.S.C. § 103(a)

3 10, 26 Unpatentable over the Collaborate References in view of Fox, Staub and Scribner under 35 U.S.C. § 103(a)

Part VII below provides a detailed explanation as to why each challenged

claim is unpatentable based on the ground identified above. This Petition also

cites additional prior art materials for purposes of providing a technology

background and describing the state of the art at the time of the alleged

invention. These materials are also cited in the accompanying Declaration of Tal

Lavian, Ph.D. (“Lavian Decl.”) [Ex. 1002], a technical expert with more than 25

years of technical experience in the networking, communications, Internet, and

software fields. (Lavian Decl., Ex. 1002, ¶¶ 6‐15, Ex. A.)

C. Requirements for Inter Partes Review 37 C.F.R. § 42.108(c)

The Board should institute inter partes review of claims 1, 5, 7‐10, 12, 15

and 24‐26 because this Petition establishes a reasonable likelihood of prevailing

with respect to each challenged claim. Each limitation of each challenged claim is

disclosed and/or suggested by the prior art, as explained in detail in Part VII.


‐5‐

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

outgrowth of the World Wide Web and the explosion of its popularity that began

in the 1990s. (Lavian Decl., Ex. 1002, ¶ 23.) During that time, business could be

conducted on the web using straightforward and simple web technologies. For

example, a web server could receive a request from a web 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 database. (Id.) The web server

could then return a response to the web browser in the form of a HyperText

Markup Language (“HTML”) web page. (Id.; see also Fox, Ex. 1008, at p.482‐83.)

But industry realized that as web‐based businesses grew, especially larger

enterprises such as airlines, systems would need to support coordination among a

potentially large number of distributed systems. (Lavian Decl., Ex. 1002, ¶ 24;

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

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


‐6‐

B. Modern “Web Services”

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,

Ex. 1001, 1:32‐34.) The term “XML,” like web services generally, 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, ¶¶ 25, 26.) 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. 1010, at p.3.) XML was particularly desirable

because it promised a document format that could be shared between computer

systems and application programs. (Lavian Decl., Ex. 1002, ¶¶ 25, 26.) By 2001, 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. 1010, Preface, xi.)

The specification of the ’860 patent acknowledges that web services were


‐7‐

already being deployed commercially before the alleged invention. (’860, Ex.

1001, 2:20‐22 (“Enterprises are adopting Web services technology to address

their business integration needs[.]”).) One such commercial system was

WebLogic Collaborate by BEA Systems, Inc. As discussed in great detail in Part

VII.A below, the prior art references in this petition describing WebLogic

Collaborate describe features to monitor and manage web services.

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 for monitoring a “conversation.” The

specification defines a “conversation” as “a set of related messages sent and

received by a particular conversation.” (’860, 4:45‐46.) Figure 1A provides a

general overview of the conversation management system:


‐8‐

(’860, Fig. 1A.)

The management system in Figure 1A has 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 the

“conversation managed object” as follows:

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


‐9‐

Conversation managed objects “can be considered managed objects.”

(’860, 6:61‐62.) The specification explains that a “[m]anaged 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, 6:63‐67.)

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 in a web service. Representative claim 1 recites:

1. A system for managing a conversation in a Web service,

comprising:

[a] a computer processor;

[b] a conversation managed object executable on the computer

processor, wherein:

[c] the conversation managed object includes at least one

interface configured to provide management information

about the conversation to at least one manager; and

[d] the at least one interface is configured to provide information

regarding the Web service that contains the conversation

(’860, 10:30‐41 (Claim 1).) The bracketed notations (e.g., “[a],” “[b],” “[c],” etc.)


‐10‐

were added to facilitate identification of these limitations in this Petition. The

second independent claim addressed in this Petition is claim 24:

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—i.e.,

claims 5, 7‐10, 12, 15, 25 and 26—depend from claims 1 or 24. This Petition will

address those claims in more detail in Part VII.B and VII.C below.


‐11‐

VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3)

A claim subject to inter partes review must be given its “broadest

reasonable construction in light of the specification of the patent in which it

appears.” 37 C.F.R. § 42.100(b). The “broadest reasonable construction” standard

is fundamentally different from the manner in which the scope of a claim is

determined in litigation. See, e.g., In re Swanson, 540 F.3d 1368, 1377‐78 (Fed.

Cir. 2008). Accordingly, the constructions proposed below represent the broadest

reasonable construction that one of ordinary skill in the art would assign and not

necessarily an appropriate construction in 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 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, Ex. 1001, 1:32‐34, 1:40‐43 (underlining added).)


‐12‐

As explained by Dr. Lavian, the above‐quoted statement in the

“Background” section is generally consistent with how one of ordinary skill in the

art understood “Web service” as of May 2003. (Lavian Decl., Ex. 1002, ¶ 37.)

Accordingly, “Web service” under its broadest reasonable construction 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.”


‐13‐

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:

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


‐14‐

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

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


‐15‐

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

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


‐16‐

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 (excerpted

at right), the manager is depicted 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.”


‐17‐

E. “Interface,” “Managed Object Interface,” “Service 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.

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, ¶ 52.) 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., ¶ 53.) 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


‐18‐

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

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. 1012] 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.

1012, at p. 279.) The patent specification uses the term “interface” in a way that

is consistent with this definition. (Lavian Decl., Ex. 1002, ¶ 54.) 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


‐19‐

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

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


‐20‐

of “conversation interface” is an “interface associated with a conversation.”

VII. CLAIMS 1, 5, 7‐10, 12, 15 AND 24‐26 OF THE ’860 PATENT ARE UNPATENTABLE

A. Ground 1 – Claims 1 and 24 Are Obvious Over the Collaborate References in view of Fox

1. Prior Art and Date Qualification for Ground 1

Each limitation of claims 1 and 24 is disclosed or suggested by (1)

“Introducing BEA WebLogic Collaborate” (“Introducing Collaborate”) [Ex. 1004];

(2) “Administering BEA WebLogic Collaborate” (“Administering Collaborate”) [Ex.

1005]; and (3) “Programming BEA WebLogic Collaborate Management

Applications” (“Programming Collaborate”) [Ex. 1006]. This Petition refers to

these references collectively as the “Collaborate References.” This Petition also

relies on certain disclosures from David Fox et al., Web Publisher’s Construction

Kit with HTML 3.2 (1996) (“Fox”) [Ex. 1008] for certain claim limitations.

The Collaborate References and Fox qualify as prior art to the ’860 patent

under at least 35 U.S.C. § 102(b) (pre‐AIA) because they were published more

than one year before the filing date of the ’860 patent.

The Collaborate References are properly considered printed publications

because they were disseminated or otherwise made available so persons of

ordinary skill in the art, exercising reasonable diligence, could locate them. They

were part of a collection of product manuals and documentation for a commercial


‐21‐

product called BEA WebLogic, offered by BEA Systems, Inc. They show a date of

“July 2011” on their face and copyright pages.

As explained by Dr. Lavian and in the accompanying “Affidavit of

Christopher Butler” from the Internet Archive, the Collaborate References were

publicly available for download from BEA’s website no later than August 2001.

(Lavian Decl., Ex. 1002, ¶¶ 203‐08; Butler Affidavit, Ex. 1014.) The “Internet

Archive” includes a service known as the “Wayback Machine” that has archived

more than 400 billion web pages that were available on the Web, preserving

them as they existed at the time of capture. (Ex. 1014, ¶¶ 2‐4.) The Wayback

Machine records the date and time of capture and encodes it into the document’s

Internet Archive URL. (Id. ¶ 5; Lavian Decl., Ex. 1002, ¶¶ 204, 205.) In this case,

the Internet Archive captured a webpage entitled “BEA WebLogic Collaborate 2.0:

PDF” that includes download links to various documents (in PDF form), including

the Collaborate References cited in this Petition. (Lavian Decl., Ex. 1002, ¶¶ 206,

207; Butler Aff., Ex. 1014, Ex. A (BEA download page).) Based on the date of

capture recorded by the Internet Archive, the page was publicly accessible

through the web by no later than August 29, 2001. (Lavian Decl., Ex. 1002, ¶ 205.)

The download page was part of what BEA called its “e‐docs Web Site” (e‐

docs.bea.com), which the Collaborate References identify as a central source of


‐22‐

documentation about BEA’s products. (See Ex. 1004, at vi (“The WebLogic

Collaborate product documentation is available on the BEA Systems, Inc.

corporate Web site.”); Ex. 1005, at x (“From the BEA Home page, click on Product

Documentation or go directly to the ‘e‐docs’ Product Documentation page at

http://e‐docs.bea.com.”); id. at xi (“A PDF version of this document is available

from the BEA WebLogic Collaborate documentation Home page . . . at http://e‐

docs.bea.com.”).) There is no indication that a person of ordinary skill in the art

would have experienced any difficulties downloading the Collaborate References

from BEA’s website. (Lavian Decl., Ex. 1002, ¶ 208.)

Finally, BEA Systems, Inc., the company that produced the Collaborate

References, was a well‐known web services product provider in the early 2000s,

claiming more than 11,000 customers worldwide by 2001. (Id. ¶ 209 (citing Ex.

1013).) Accordingly, the Collaborate References qualify as printed publications.

2. Brief Summary of the Prior Art Applied in Ground 1

The “Collaborate References” collectively describe certain management

features of a software program called “WebLogic Collaborate,” Release 2.0, from

BEA Systems, Inc. In broad overview, WebLogic Collaborate was a program

designed to facilitate an exchange of messages (e.g., through “conversations”)

between an entities and their “trading partners.” The “trading partners” of an


‐23‐

entity include other entities with which it conducts business, such as customers

and suppliers. (Introducing Collaborate, Ex. 1004, at 1‐4, 1‐6 (Fig. 1‐1), 1‐7 (Fig. 1‐

2).) “Business partners in an e‐commerce community can range in size from large

enterprises to small divisions within an enterprise.” (Id. at 1‐4.)

As explained in Introducing Collaborate, the term “trading partner” refers

to “an entity that has an agreement with another entity to participate in a specific

business exchange, or conversation, in a specific role that is defined for the

conversation.” (Id. at 1‐5.) For example, an organization could set up a

community for inventory management in which its “trading partners” consisted of

corporate departments within the organization. (Id. at 1‐4.)

The “trading partners” involved run the WebLogic Collaborate software (or

compatible collaboration software provided by a third party) to form an e‐

community. An example of such an “e‐community” is shown in Figure 1‐2 below,

which shows use of the WebLogic Collaborate for an auction service:


‐24‐

(Id. at 1‐7 (Fig. 1‐2).) Figure 1‐2 above shows use of WebLogic Collaborate for an

auction service in which a “Net Market” (the center box) serves as an auction

broker between a Buyer and Sellers. (Id.)

Once joined into an e‐community, these trading partners may participate in

a “conversation.” Within WebLogic Collaborate, a “conversation” is “a series of

business messages exchanged between trading partners.” (Id. at 1‐7 to 1‐8; see

also id. (“The business messages that can be exchanged between participants in

the conversation are determined by the roles the trading partners play in the

conversation.”)

A conversation “[m]ay be complex and long‐running, or short‐lived.” (Id.)

WebLogic Collaborate operates as a “Web service” in that messages exchanged

between trading partners take the form of eXtensible Markup Language (XML)


‐25‐

messages using standard Web protocols such as HTTP. (Id. at 1‐13 (“A business

message is the basic unit of communication among trading partners and is

exchanged as part of a conversation. A business message contains one or more

XML business documents, one or more attachments, or a combination of both.”

(underlining added)), 1‐1 (“WebLogic Collaborate supports HTTP because the

World Wide Web is the ubiquitous communication medium for e‐business.”).)

Finally, WebLogic Collaborate provides an “Administration Console”

accessible through a web browser that allows a user to manage various aspects of

the collaboration system. (Id. at 1‐30 to 1‐31.) Additional detail regarding the

disclosures of the Collaborate References is provided below.

Fox is a 1996 web programming textbook describing various well‐known

Web technologies such as using the Common Gateway Interface (CGI). This

Petition relies on Fox in combination with the Collaborate References for the

“interface” limitations of the challenged claims. A further discussion of Fox is

provided below in the discussion of the claim limitations for which it is cited.

3. The Collaborate References Are Properly Combinable

Each of the Collaborate References cited in this Petition describes some

aspect of the WebLogic Collaborate features used to show the claim limitations.

As explained by Dr. Lavian, one of ordinary skill in the art would have found the


‐26‐

Collaborate References to be combinable. (Lavian Decl., Ex. 1002, ¶¶ 73‐82.)

It is hard to imagine an easier case for combinability than the Collaborate

References. All three documents describe aspects of the same software program,

BEA WebLogic Collaborate, and even the same version of that software (Release

2.0). They were all produced by the same company and bear the same date. One

of ordinary skill in the art would naturally have treated the Collaborate

References as a group of related documents and consulted them together to

ascertain the various features of WebLogic Collaborate. (Id. ¶¶ 74, 75.)

In fact, the Collaborate References cite and make express references to

each other. For example, Introducing Collaborate includes a section entitled

“Document Roadmap for WebLogic Collaborate” that lists other documents that

the reader can consult to “find more detailed information about various features

of your WebLogic Collaborate.” (Ex. 1004, at 1‐32.) That section specifically lists

the other two Collaborate References. (Id. at 1‐32 (listing Administering

Collaborate), 1‐34 (listing Programming Collaborate).) The Collaborate

References are replete with other examples of specific citations and cross‐

references to each other. (See, for example, Introducing Collaborate, Ex. 1004, at

1‐14 and 1‐31.) The Collaborate References, in fact, specifically encourage the

reader to consult each other. (See, for example, Administering Collaborate, Ex.


‐27‐

1005, at x (“Before reading this document, we recommend that you read the

Introducing BEA WebLogic Collaborate document.”).) A person of ordinary skill in

the art would have been amply motivated to combine and would have considered

them part‐and‐parcel of a single disclosure. (Lavian Decl. ¶ 78.)

With respect to some claim limitations relating to interfaces, this Petition

applies the teachings of the Fox reference (Ex. 1008) in combination with the

Collaborate References. Because this Petition cites Fox only with respect to

certain limitations, it will address the rationale and motivation to combine in the

claim limitations where Fox has been applied.

4. Claim 1

The preamble of claim 1 recites, “[a] system for managing a conversation in

a Web service.” As explained above, “Web service” should be understood as a

“service or system that interacts with another system through the exchange of

eXtensible Markup Language (XML) messages.” The term “conversation” refers

to a “set of related messages for exchange of information.”

The “Web service” in the Collaborate References takes the form of the

WebLogic Collaborate system:

The BEA WebLogic Collaborate™ product is an XML‐ and Java‐

based e‐commerce platform that enables you to implement


‐28‐

complex e‐commerce systems on the Web. . . XML is used as a

standard format for documents exchanged by business

partners. WebLogic Collaborate supports HTTP because the

World Wide Web is the ubiquitous communication medium for

e‐business.

(Introducing Collaborate, Ex. 1004, at 1‐1 (emphasis added).) The WebLogic

Collaborate system therefore clearly qualifies as a “Web service.”

The Collaborate References also disclose “a system for managing a

conversation in a Web service.” According to the Collaborate References,

“[w]hen trading partners join other trading partners to form an e‐community with

a specific purpose, they participate in a conversation.” (Introducing Collaborate,

Ex. 1004, at 1‐7 (under “Defining Conversations and Roles”) (italics in original).)

“In WebLogic Collaborate, a conversation . . . [i]s a series of business messages

exchanged between trading partners. . .” (Id. (underlining added).) The

Collaborate references therefore disclose a “conversation in a web service.”

They also disclose a system for managing such a conversation. As noted

previously, “monitoring” is one example of “managing” under the ’860 patent.

(’860, 5:1‐4.) The Collaborate References provide a system for managing

conversations, for example, by providing management features:


‐29‐

Managing Conversations

Critical to managing successful relationships between trading

partners is the ability to provide robust services to ensure the

integrity of business messages while they are being exchanged

in various types of trading partner collaborations. WebLogic

Collaborate provides a messaging service and a conversation

coordination service, as described in the following sections.

(Introducing Collaborate, Ex. 1004, at 1‐26 (under “Managing Conversations”)

(boldface type in original; underlining added).)

For example, as described in more detail in subsequent claim limitations,

the Collaborate References describe specific features for monitoring and listing

conversations. (Administering Collaborate, Ex. 1005, at 6‐10 (under “Monitoring

Conversations”).) The Collaborate References therefore clearly disclose “a system

for managing a conversation in a Web service,” as recited in the preamble.

a. “a computer processor” (Claim 1[a])

The first limitation of claim 1 recites “a computer processor.” The

Collaborate References explain that BEA WebLogic Collaborate is a software

product that runs, for example, on the Microsoft Windows and UNIX operating

systems. (See Administering Collaborate, Ex. 1005, at 1‐5 (“On a Windows

system, you can start WebLogic Collaborate with the program icons or from the


‐30‐

command line.”); id. at 1‐7 (describing starting WebLogic Collaborate in UNIX).)

Additionally, the Collaborate References explain that “WebLogic

Collaborate is implemented entirely in Java and leverages the J2EE standard

APIs.” (Introducing Collaborate, Ex. 1004, at 1‐1.) The term “Java” and “J2EE”

generally refer to an object‐oriented programming language and platform

originally developed by Sun Microsystems. (Lavian Decl. ¶ 90.) One of ordinary

skill in the art would have understood that executing WebLogic Collaborate on a

Microsoft Windows or Unix system, or to run a Java‐based program required at

least one computer processor. (Id.)

b. "a conversation managed object executable on the computer processor" (Claim 1[b])

The claimed “conversation managed object” in the Collaborate References

takes the form of a collection of software programs known as the “BEA WebLogic

Collaborate Managed Beans,” also referred as “MBeans.” These “Managed

Beans” or “MBeans” are what is known as “JavaBeans.” Java, as mentioned

earlier, refers a programming language and software development platform. The

basic unit of Java program is known as a Java “class.” (Lavian Decl., ¶ 92.) The

term “JavaBean” describes a particular way to encapsulate a Java class that,

generally speaking, was intended to make software components in Java more


‐31‐

reusable from one program to another. (Id.) Accordingly, the “Managed Beans”

or “MBeans” in the Collaborate References describe software functionality

encapsulated as “Java Beans” that, when executed by a processor in a computer,

perform certain functions. (Id.)

The collection of these “Managed Beans” corresponds to the “conversation

managed object” recited in the claim. The term “conversation managed object,”

as explained in Part VI.C.2 above, means an “object for managing a resource that

is associated with a conversation.” Here, the “resource” being managed is an

aspect of the WebLogic Collaborate service, such as a trading partner session or

delivery channel. (Programming Collaborate, Ex. 1006, at 2‐3 to 2‐4, Table 2‐1

(listing WebLogic resources managed by MBeans).)

The Collaborate References confirm that these resources may be

“associated with a conversation.” (Administering Collaborate, Ex. 1005, at 6‐4 to

6‐5, Table 6‐1.) For example, the Administration Console in WebLogic Collaborate

allows users to monitor a run‐time instance, trading partner session or delivery

channel – and list the conversations associated with these resources. (Id. at 6‐4

(“Trading partner page [:] Sessions . . . ▪ From the detail of a selected session, link

to a list of the conversations or a list of the outstanding messages.”); id. (“Trading

partner page [:] Delivery Channels . . . ▪ View the details of a selected delivery


‐32‐

channel (status, trading partner sessions, conversations, collaboration

agreements, messages sent).” (underlining added to both).)

These resource monitoring features are provided by the MBeans, the

claimed “conversation managed object.” The Collaborate References describe at

least six different MBeans that are associated with WebLogic Collaborate. (Id. at

2‐3, Table 2‐1.) For example, the MBean called “WLCMBean” is “[u]sed for

monitoring a WebLogic Collaborate instance at run time.” (Id. (first item in Table

2‐1; underlining added).) Another MBean described in the Collaborate

References, “DeliveryChannelMBean,” is “[u]sed for monitoring delivery

channels on WebLogic Collaborate at run time.” (Id. (second item in Table 2‐1).)

The other MBeans perform other management tasks for WebLogic

Collaborate such as monitoring trading partners, monitoring messages for

WebLogic Collaborate and so forth. (Id. at 2‐3 to 2‐4, Table 2‐1.) As noted

previously, the specification of the ’860 patent expressly lists “monitoring” as an

example of managing a resource. (’860, Ex. 1001, 5:1‐4.)

These MBeans, individually or as a group, clearly qualify as “an object for

managing a resource that is associated with a conversation.” The Collaborate

References therefore disclose “a conversation managed object executable on the

computer processor,” as recited in the claim.


‐33‐

c. “the conversation managed object includes at least one interface configured to provide management information about the conversation to at least one manager” (Claim 1[c])

The Collaborate References also disclose that the Managed Beans (the

“conversation managed object”) include “at least one interface configured to

provide management information about the conversation to at least one

manager.” Because the claimed “interface” provides management information to

a “manager,” this Petition will first address the “manager.”

The “manager” in the Collaborate References takes the form of an

Administration Console, a web‐based user interface that can be accessed by an

administrator using a web browser. (See Administering Collaborate, Ex. 1005, at

1‐8 to 1‐9, Figure 1‐1.) The Administration Console provides access to

management features of the Web service, i.e., WebLogic Collaborate:

You can use the WebLogic Collaborate Administration Console to:

Configure WebLogic Collaborate preferences, trading partners,

conversation definitions, collaboration agreements, business

protocol definitions, and logic plug‐ins

Export and import configured elements

Monitor and control WebLogic Collaborate, trading partner

sessions, conversations, and collaboration agreements

(Administering Collaborate, Ex. 1005, at 1‐7 (underlining added).) Having


‐34‐

addressed the “manager,” this Petition will now turn to the claimed “interface.”

The Collaborate References also disclose “at least one interface configured

to provide management information about the conversation” to the

Administration Console (“manager”). There are at least two separate and

independent ways in which the prior art discloses this “interface.”

First, the “interface” can take the form of Application Programming

Interfaces (APIs) provided by the Managed Beans or MBeans, which provide

management information to the Administration Console. The Collaborate

References plainly state, in fact, that the Administration Console (the claimed

“manager”) uses these MBeans APIs to access this management information:

WebLogic Collaborate provides the application programming

interfaces (APIs) needed to create custom management applications

that monitor run‐time activity on WebLogic Collaborate nodes. The

WebLogic Collaborate Administration Console tools also use these

APIs to provide real‐time monitoring information.

These APIs consist of sets of Java Management Extensions (JMX)

Managed Beans, or MBeans, which are special JavaBeans with

attributes and methods for management operations.

(Programming Collaborate, Ex. 1006, at 2‐2 (under “MBeans and the MBean

Server”) (underlining added); see also id. at 2‐5 (“The WebLogic Collaborate

Administration Console uses the JMX API and WebLogic Collaborate MBeans to


‐35‐

monitor running WebLogic Collaborate instances.”) (underlining added).)

An Application Programming Interface or “API,” including the MBeans API

discussed above, satisfies the “interface” claim limitation, as explained in Part

VI.E above, because it provides the connection point for communication and/or

exchange of information between the Administration Console and the MBeans.

As explained in Part VI.B, a “conversation” is a “set of related messages for

exchange of information.” These Managed Beans or MBeans (“interface”)

provide management information about the conversation. In particular, one

those MBeans APIs, called “getActiveConversations,” provides a list of

the conversations in a WebLogic Collaborate session:

MBeans that are logically related have accessor methods to retrieve references

to each other. These methods are strongly typed and return exact MBean

types. For example, the WLCMBean.getActiveDeliveryChannels()

method returns an array of type DeliveryChannelMBean that represents all the

active delivery channels in the system. Similarly, the

TradingPartnerSessionMBean.getActiveConversations()

method returns an array of type ConversationMBean that represents all

the active conversations in this session.

(Programming Collaborate, Ex. 1006 at 2‐10 (under “Step 6: Navigate Across

MBeans”) (underlining added).)

As explained by Dr. Lavian, who has translated the above paragraph into


‐36‐

plain English, the above‐quoted paragraph describes services provided by MBean

APIs referred to above as “accessor methods.” (Lavian Decl. ¶ 106.) A “method”

in Java (and in object oriented programming in general) refers to software or

instructions that can be invoked (or “called”) from another software process by

using the method’s name. An “accessor method” generally refers to a method

that retrieves (“gets”) data from an object. (Id.)

The accessor method “getActiveConversations()” in the text above is an

accessor method that can be invoked by an application – such as the

Administration Console – to retrieve a list of active conversations in the WebLogic

Collaborate session. As explained above, this method “returns an array of type

ConversationMBean that represents all the active conversations in this session.”

(Id. at 2‐10 (underlining added).)

This accessor method is part of the MBeans API (the claimed “interface”) as

previously mentioned. The Collaborate References further disclose that the

Administration Console uses the MBeans APIs to provide the list of conversations.

(Id. at 2‐2 (“The WebLogic Collaborate Administration Console tools also use

these APIs to provide real‐time monitoring information.”) (under “MBeans and

the MBean Server”), 2‐5 (“The WebLogic Collaborate Administration Console uses

the JMX API and WebLogic Collaborate MBeans to monitor running WebLogic


‐37‐

Collaborate instances.”).) The Collaborate References therefore disclose that the

Managed Beans or MBeans (the “conversation managed object”) include “at least

one interface configured to provide management information about the

conversation,” as recited in claim 1[c].

As noted previously, there is a second way in which the prior art discloses

the claimed “interface.” The “Administration Console,” is a web‐based user

interface that allows an administrator to access management features. (See

Administering Collaborate, Ex. 1005, at 1‐8 to 1‐9, Figure 1‐1.) One of these

features allows the user to bring up a list of conversations. (Id. at 6‐10 (under

“Monitoring Conversations”).) Selecting a conversation from the conversation list

will bring up a web page showing information about the selected conversation

such as its conversation identifier, start time of the conversation, and other

information. (Id. at 6‐11 (Figure 6‐5).)

One of ordinary skill in the art would have appreciated that the web server

that provides web pages for the Administration Console – including pages that

provide management information about the conversation – would have included

an “interface” to receive user selections through the Administration Console and

then use that input to interact with other software (e.g., MBeans) to, for example,

retrieve requested conversation information. (Lavian Decl., Ex. 1002, ¶ 111.)


‐38‐

These web server interfaces were well known to persons of ordinary skill in

the art by May 2003. (Id. ¶ 112.) One example is the Common Gateway

Interface (CGI) disclosed in Fox (Ex. 1008). Fox, which was published more than

six years before the ’860 filing date, explains that CGI allows a web server to

communicate with other software programs:

The Common Gateway Interface—or CGI—is a method that lets you

access external programs on a Web server and usually send the

results to a Web browser. . . These programs can be any executable

code, script or program supported by the operating system that runs

your server.

(Fox, Ex. 1008, at 482 (under “Lesson #1: What is CGI?”) (underlining added).)

These programs that can be accessed using CGI are called “CGI scripts,” and

they can be written in any programming language supported by the server. (Id.)

CGI scripts could be used for various purposes including accessing databases:

Why is it called the Common “Gateway” Interface? Well, the answer

is simple: The Common Gateway Interface was originally intended as

a “gateway” between WWW clients and other programs that could

be run remotely on your server. Many CGI scripts, especially those

that access databases, simply execute another application on the

server and redirect its output with whatever formatting changes are

required to the HTTP server, and then to the client that requested

the script.


‐39‐

(Id. at 490 (under “Lesson #4: How to Use a Script to Access Other Applications”)

(underlining added).) Fox further explains that a program accessed through the

CGI interface can perform a wide range of tasks. “It can access other programs,

open files, read from files, create graphics, dial your modem, call your mother, do

database searches, send e‐mail, you name it.” (Id. at 484 (under “What Can I Do

with a CGI Script?”) (underlining added).)

Although the MBeans in the Collaborate References alone satisfy the

claimed “interface,” the claimed interface would also have been obvious over the

Collaborate References in view of the web server interface teachings in Fox. It

would have been obvious to one of ordinary skill in the art to adapt Fox’s

teachings about web server interfaces such as the Common Gateway Interface

(CGI) to the Collaborate References, with no change in their respective functions.

This would have predictably resulted in the Administration Console (the claimed

“manager”) using a web server interface such CGI as an interface between the

server that receives the user’s input and external programs (such as the Managed

Beans or MBeans) that provide functionality in response to that user input.

(Lavian Decl. ¶ 117.) This would have allowed the Administration Console (the

“manager”) to provide management information about the conversation through

its web‐based user interface. (Administering Collaborate, Ex. 1005, at 3‐2 (“The


‐40‐

WebLogic Collaborate Administration Console is used to . . . [m]onitor WebLogic

Collaborate, trading partner sessions, [and] conversations . . . .”).)

As explained by Dr. Lavian, one of ordinary skill in the art would have had

many motivations to combine. (Lavian Decl., Ex. 1002, ¶ 119.) The technology

was not complex, and web server interfaces (CGI being one example) were “part

of the basic repertoire of knowledge possessed by persons of ordinary skill in the

art well before May 2003.” (Id.) As explained in Fox in 1996, “[a]s you read this,

CGI scripts are coming to life all over the world.” (Fox, Ex. 1008, at 485.) One of

ordinary skill in the art would have recognized that one could employ an interface

such as CGI to facilitate interaction with external programs. (Lavian Decl. ¶ 120.)

d. “the at least one interface is configured to provide information regarding the Web service that contains the conversation” (Claim 1[d])

As explained above for claim 1[a], the claimed “Web service” in the prior

art corresponds to the WebLogic Collaborate system. As noted for the preceding

claim limitation (1[c]), there are at least independent two ways in which the prior

art discloses the claimed “interface” of claim 1: (1) application programming

interfaces (APIs) provided by the Managed Beans or MBeans; and (2) a web server

interface such as the Common Gateway Interface (CGI) in Fox. Both theories also

satisfy all aspects of claim 1[d].


‐41‐

With respect to the first theory in which the “interface” takes the form of

MBeans APIs, the Collaborate References specifically disclose that the APIs

provide information regarding WebLogic Collaborate (the “Web service”):

WebLogic Collaborate provides the application programming

interfaces (APIs) needed to create custom management applications

that monitor run‐time activity on WebLogic Collaborate nodes. The

WebLogic Collaborate Administration Console tools also use these

APIs to provide real‐time monitoring information.

These APIs consist of sets of Java Management Extensions (JMX)

Managed Beans, or MBeans, which are special JavaBeans with

attributes and methods for management operations.

(Programming Collaborate, Ex. 1006, at 2‐2 (under “MBeans and the MBean

Server”) (underlining added).)

The Collaborate References further state: “The WebLogic Collaborate

Administration Console uses the JMX API and WebLogic Collaborate MBeans to

monitor running WebLogic Collaborate instances.”) (Id. at 2‐5 (underlining

added).) As explained previously, the WebLogic Collaborate service contains the

claimed conversation. The MBeans API (the claimed “interface”) is therefore

“configured to provide information regarding the Web service that contains the

conversation,” as recited in claim 1[d].

With respect to the second theory outlined above in which the claimed


‐42‐

“interface” takes the form of a web server interface (such as CGI disclosed in Fox),

one of ordinary skill in the art would have recognized that an interface such as CGI

could also have been “configured to provide information regarding the Web

service that contains the conversation.” This is because information about the

WebLogic Collaborate service is reported to the user through the Administration

Console, as explained above. (See also Administering Collaborate, Ex. 1005, at 6‐5

to 6‐6 (Fig. 6‐1) (showing current status of WebLogic Collaborate).) The ability to

dynamically generate a web page in response to user input, such as an

Administration Console page showing the current status of the WebLogic

Collaborate service, is a key reason to use a web server interface such as the

Common Gateway Interface (CGI). (Lavian Decl. ¶ 126.)

Under either theory, the prior art discloses that “the at least one interface

is configured to provide information regarding the Web service that contains the

conversation,” as recited in the claim. For all of these reasons, therefore, the

Collaborate References and Fox disclose each element of claim 1.

5. Claim 24

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

slightly different order and adds limitations relating to conversation monitoring

information (e.g., “number of failed messages”). The Collaborate References


‐43‐

disclose all limitations of claim 24 for many of the same reasons as claim 1.

The preamble of claim 24 recites, “[a] computer program product tangibly

embodied in a computer readable storage medium.” As explained in connection

with claim 1[a] above, BEA WebLogic Collaborate is a Java‐based computer

program product that runs on a Windows‐ or UNIX‐based computer system. The

software is also stored on a computer readable storage medium. For example,

the Collaborate References explain that the WebLogic Collaborate software is

installed in particular file directories on the user’s computer. (See Administering

Collaborate, Ex. 1005, at 1‐6.) One of ordinary skill in the art would have

understood that this shows a “computer readable storage medium” such as a

hard disk drive or other type of digital storage device. (Lavian Decl. ¶ 131.)

a. “conversation interface” limitations (Claims 24[a], 24[b])

Claim 24 recites a “conversation interface,” followed by a “managed object

interface,” and then concludes with a lengthy “wherein” clause that refers back to

the “conversation interface.” For convenience, therefore, this Petition will first

address the “conversation interface” limitations and then the “managed object.”

i. “a conversation interface” (Claim 24[a])

A “conversation interface” is an “interface associated with a conversation.”

(See Part VI.E.3, above.) The “conversation interface” recited in claim 24 is


‐44‐

substantially similar, for purposes of this Petition, to the “interface” of claim 1.

Accordingly, the same teachings identified for the “interface” in claim 1 are also

applicable to the “conversation interface” in claim 24.

In particular, as with claim 1, there are at least two separate and

independent ways in which the prior art discloses the claimed “conversation

interface.” First, the Collaborate References disclose a “conversation interface”

in the form of Application Programming Interfaces (APIs) provided by the

Managed Beans or MBeans, which provide management features. (Programming

Collaborate, Ex. 1006, at 2‐2 and 2‐5.) These Managed Beans or MBeans

(“conversation interface”) are associated with a conversation. In particular, one

those MBeans APIs, called “getActiveConversations,” can be invoked by

an application to provide a list of the conversations in a WebLogic Collaborate

session. (Id. at 2‐10 (discussion under “Step 6: Navigate Across MBeans”); see

also discussion in Part VI.A.4.) The MBeans API (“conversation interface”),

therefore, is associated with a conversation.

Under the second theory discussed above, the “conversation interface”

takes the form of a web interface such as the Common Gateway Interface (CGI)

disclosed in Fox. This interface, as discussed previously, provides a “gateway” in

which a web server (such as the one providing the Administration Console) can


‐45‐

interact with another application program to perform certain tasks, such as

querying databases. (Fox, Ex. 1008, at 482 (under “Lesson #1: What is CGI?”); id.

at 490 (under “Lesson #4: How to Use a Script to Access Other Applications”); id.

at 494 (under “What Can I Do with a CGI Script?”).)

As explained for claim 1[c] above and by Dr. Lavian, it would have been

obvious to one of ordinary skill in the art to adapt Fox’s teachings about the

Common Gateway Interface (CGI) to the Collaborate References. (Lavian Decl.,

Ex. 1002, ¶¶ 117‐120, 138, 139.) This would have predictably allowed the

Administration Console to provide a web server interface such as CGI as an

interface associated with a conversation. (Administering Collaborate, Ex. 1005, at

3‐2 (“The WebLogic Collaborate Administration Console is used to . . . [m]onitor

WebLogic Collaborate, trading partner sessions, conversations . . . .”) (underlining

added).) As discussed in detail above, one of ordinary skill in the art would have

had many motivations to combine. (Lavian Decl., Ex. 1002, ¶¶ 117‐120, 138, 139.)

ii. “wherein the conversation interface includes information for monitoring messages in a conversation” (Claim 24[b])

Both interfaces described above for the claimed “conversation interface,”

i.e. the MBeans API and the web server interface (such as CGI), include

“information for monitoring messages in a conversation.” With respect to the


‐46‐

MBeans APIs, as explained for claim 1[c] above, the Managed Beans or MBeans

provide information for monitoring messages in WebLogic Collaborate

conversations. For example, the MBeans can produce lists of conversations for

display in the WebLogic Collaborate Administration Console. (See Part VI.C.1

above; see also Administering Collaborate, Ex. 1005, at 6‐10 (under “Monitoring

Conversations”).) The getActiveConversations() method discussed above, for

example, will “return[] an array of type ConversationMBean that represents all

the active conversations in this session.” (Programming Collaborate, Ex. 1006 at

2‐10 (under “Step 6: Navigate Across MBeans”) (underlining added).) This lets the

user monitor a conversation using the Administration Console. (Administering

Collaborate, Ex. 1005, at 6‐11, Figure 6‐5 (“Monitoring a Conversation”).)

With respect to the second theory outlined above in which the claimed

“conversation interface” comprises a web server interface such as the Common

Gateway Interface (CGI), as explained in great detail for claim 1[d], an interface

such as CGI could also have included “information for monitoring messages in a

conversation.” This is because the conversation monitoring information is

reported back to the user through a web page accessible through the

Administration Console, as explained above. (Administering Collaborate, Ex.

1005, at 6‐11, Figure 6‐5 (“Monitoring a Conversation”).)


‐47‐

The web server interface would have included “information for monitoring

messages in a conversation” because, as noted previously, that interface was

used to obtain and deliver the web page for the Administrative Console showing

the monitoring information. (Fox, Ex. 1008, at 490 (under “Lesson #4: How to Use

a Script to Access Other Applications”).) As explained previously, one of ordinary

skill in the art would have had ample motivation to combine the Collaborate

References with Fox. Therefore, the Collaborate References alone, or in

combination with Fox, disclose that the conversation interface “includes

information for monitoring messages in a conversation.”

iii. “…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;” (Claim 24[b1])

Claim 24[b1] continues by requiring that the “information for monitoring

messages in a conversation” include “at least one of” several pieces of

information including “the last message received by a resource” and “the total

number of messages.” The Collaborate References disclose both of these.

In particular, the Collaborate References disclose message information for

various WebLogic Collaborate resources, including a trading partner session or

WebLogic runtime instance. (Administering Collaborate, Ex. 1005, at 6‐4 to 6‐5


‐48‐

(Table 6‐1).) For example, the system maintains, for a trading partner session,

“time of last sent and received message” and “number of messages sent.” (Id. at

6‐4 (in “Trading partner page,” “Sessions” column, second bullet point); id.

(showing same information for WebLogic instance).) Figure 6‐4 shows this

information to a user through a web page in Administration Console:

(Administering Collaborate, Ex. 1005 at 6‐8.)

The screen above shows (among other things) the total number of

messages and the date and time of the last message received. Another figure

(Figure 6‐2) lists the number of “Messages Sent” and “Messages Received,”

further disclosing a total message count. (Id. at 6‐2 (Fig. 6‐2 (“Server Statistics”).)

It would have been known and obvious to one of ordinary skill that the MBeans

APIs (the “conversation interface”) provide this monitoring information to the

Administration Console. (See Programming Collaborate, Ex. 1006, at 2‐2 (“The

WebLogic Collaborate Administration Console tools also use these APIs to provide


‐49‐

real‐time monitoring information.”) (under “MBeans and the MBean Server”).)

This limitation would also have been trivially obvious to a person of

ordinary skill in the art. As explained by Dr. Lavian, the count of successful, failed

and total messages, and information about the last message received, are basic

pieces of statistical information that any management system could have tracked,

for example, using basic server communication logs. (Lavian Decl. ¶¶ 154‐55.) A

person of ordinary skill in the art would have found this limitation obvious over

the teachings of Collaborate References.

iv. “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.” (Claim 24[b2])

The monitoring information in claim 24[b2] could include “an identifier of

the conversation.” This is shown in Figure 6‐5 below

(Administering Collaborate, Ex. 1005 at 6‐11.)


‐50‐

The text following the label “Conversation:” provides “an identifier of the

conversation.” (Id. (“Identifying information, start time, self‐initiated indicator,

time of last message, and identity of last sender are displayed.”) (underlining

added).) It also shows “the identity of resources participating in the

conversation,” as recited in claim 24[b2]. This is shown in the “Last Sender:” field,

which identifies the trading partner that sent the last message to the

conversation. The Collaborate References therefore disclose claim 24[b2].

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

interface in claim 24. The claim does not expressly recite any particular function

this interface must perform, it simply requires that it exist.

The Collaborate References disclose this limitation. As noted 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).” For purposes of claim 24, the

“managed object” takes the form of a repository service that manages a

resource, e.g., configuration and other information for WebLogic Collaborate.

(Introducing Collaborate, Ex. 1004, at 1‐29 (“The repository service stores data


‐51‐

into the repository.”); Administering Collaborate, Ex. 1005, at 7‐1 (“The repository

is a database that stores configuration information for WebLogic Collaborate.”)

(under “Working with the Repository”).) The repository offers data importing and

exporting and other features through the Administration Console. (Introducing

Collaborate, Ex. 1004, at 1‐29 to 1‐30, 2‐19 to 2‐21.)

As with the “conversation interface” of this claim discussed above, there

are at least two ways in which the prior art discloses the claimed “managed object

interface.” First, the “managed object interface” takes the form of the interface

that facilitates the connection between the

repository services and the Administration

Console. The relationship between these

components is shown in Figure 1‐9 of

Introducing Collaborate at right. (Ex. 1004,

at 1‐29 (Figure 1‐9: “WebLogic Collaborate Services”).) As shown in Figure 1‐29,

the Repository Services (middle row) interface with the WebLogic Collaborate

Administration Console (top right) through the “Administration Services.” (Id. at

1‐28 (“WebLogic Collaborate system components are configured and managed

primarily through the WebLogic Collaborate Administration Console, which works

together with a repository service.”) (underlining added).) The presence of this


‐52‐

interface is further confirmed by the fact that the repository service is accessible

through Administration Console web pages. (Introducing Collaborate, Ex. 1004, at

1‐30.) The Collaborate references therefore disclose an “interface” associated

with the repository service.

The Collaborate References disclose that this “managed object interface” is

“associated with the conversation interface” under both of the theories outlined

above. In the case in which the “conversation interface” comprises the Managed

Beans or MBeans APIs, this association is clearly shown in Figure 1‐9 above. That

figure shows “Administrative Services” facilitating connection from the

Administration Console, for both the MBeans Server (which provides the MBeans

and their associated APIs) and the Repository Services. The repository service is

associated with the MBeans APIs that comprise the “conversation interface”

because, among other things, both interfaces work together to provide

management features for the WebLogic Collaborate Administration Console.

This managed object interface is also “associated with the conversation

interface” under the second theory in which the interface comprises a web server

interface such as CGI used to obtain conversation information. Under this theory,

the “managed object interface” is associated with the web server interface

because both interact with the WebLogic Collaborate Administration Console.


‐53‐

Second, although Collaborate References alone disclose the “managed

object interface,” this interface could also be found through the combination of

the Collaborate References and Fox. As have explained in great detail above, web

server interfaces such as CGI provide a mechanism for a web server to receive

input from a web browser through a web page (such as the Administration

Console), and interface with an external application to create a customized web

page in response to the user’s request. (Fox, Ex. 1008, at 484‐85.) It would have

been obvious to adapt the web server interface and CGI teachings of Fox to the

Collaborate References. (Lavian Decl. ¶¶ 168‐69.)

This would predictably have resulted in a system in which the

Administration Console used a web server interface such as CGI to access the

WebLogic Collaborate repository. Fox expressly discloses that one of the

purposes for which CGI is used is to “do database searches” (id. at 484), or “access

huge databases” (Fox, Ex. 1008, at 485). The WebLogic repository, as noted

above, comprises a database. (Administering Collaborate, Ex. 1005, at 7‐1 (“The

repository is a database that stores configuration information for WebLogic

Collaborate.”) (under “Working with the Repository”).)

One of ordinary skill in the art would have been motivated to use a web

server interface such as CGI to provide an interface for the managed object, i.e.


‐54‐

the WebLogic repository. (Lavian Decl., Ex. 1002, ¶ 170.) Finally, as noted above,

the managed object interface is “associated with the conversation interface”

because both interfaces work together to provide management features for the

Administration Console. For all of these reasons, claim 24 is obvious.

B. Ground 2 – Claims 5, 7‐9, 12, 15 and 25 Are Obvious Over the Collaborate References in view of Fox and Staub

Claims 5, 7‐9, 12, 15 and 25 depend from claims 1 or 24 and recite

providing additional types of statistical information about messages. They recite

the “last fault message returned from the conversation” (claim 5), “number of

successful messages processed by the conversation” (claim 7), and so forth.

These claims offer nothing non‐obvious over the Collaborate References

and Fox. As explained by Dr. Lavian, it would have been obvious to adapt the

claimed “interface” (claim 1) or “conversation interface” (claim 24) in the

Collaborate References to provide this information. This information represents

the type of basic statistics that management systems routinely maintained and

tracked. (Lavian Decl., Ex. 1002, ¶ 174.) This information could have been readily

derived, for example, from basic server communication logs that record sent and

received messages, and the success or failure of those messages. (Id.)

In fact, the Collaborate References state that “WebLogic Collaborate


‐55‐

provides a logging capability for error and information messages. All WebLogic

Collaborate log messages are time‐stamped, and can be sent to the WebLogic

Server log, or to a separate log file.” (Introducing Collaborate, Ex. 1004, at 1‐32

(under “Logging Service”) (underlining added).) The Collaborate References also

disclose providing failed message information such as the “time of first and last

failed message.” (Administering Collaborate, Ex. 1005 at 6‐4 (“Trading partner

page,” “Sessions,” second bullet point) (underlining added).)

It would have taken no stretch of a skilled artisan’s imagination to adapt

the claimed “interface” in WebLogic Collaborate to provide each of the specific

types of information recited in claims 5, 7‐9, 12, 15 and 25. (Lavian Decl., Ex.

1002, ¶ 177.) These additional features are also obvious in view of Staub [Ex.

1015], which discloses a technique for recording, processing and tallying network

errors and fault messages, as explained below. (Staub, Ex. 1015, 1:7‐9, 1:54‐61.)

1. Claims 5, 15 and 25 (“Fault Message” Claims)

These claims recite similar subject matter relating to “fault messages” and

will thus be addressed here. It would have been obvious to adapt the “interface”

of the Collaborate References to provide the fault message information in claims

5, 15 and 25. As noted, the references already disclose recording the “time of

first and last failed message.” (Administering Collaborate, Ex. 1005 at 6‐4.)


‐56‐

Moreover, Staub discloses a method and system for receiving, recording and

processing fault messages. “A system for cataloging and detecting network faults,

includes a communication interface for receiving a fault message from a

network.” (Staub, Ex. 1015, 1:54‐56 (underlining added).) The network fault is

parsed, and “[a]n associative database is connected to the parser and stores a

tally for the fault message.” (Id., 1:58‐59 (underlining added).) If the tally of

network faults exceeds a specific “threshold,” a problem message is sent to an

operator interface. (Id., 2:38‐39.)

As explained by Dr. Lavian, it would have been obvious to adapt Staub to

the Collaborate References, with no change in their respective functions,

predictably resulting in the claimed “interface” of WebLogic Collaborate providing

information about the “last fault message” (claim 5), an “unexpected fault

message” (claim 15) and that “a participant in the conversation sent a fault

message” (claim 25). (Lavian Decl. ¶ 184.)1 As noted above, the Collaborate

1 The Collaborate References clearly disclose that “the conversation is further

configured to receive messages,” as recited in claims 5, 7 and 8. (See Introducing

Collaborate, 1004, at 1‐7 to 1‐8 (a conversation “[i]s a series of business messages

exchanged between trading partners.”); Lavian Decl., Ex. 1002, ¶ 180.)


‐57‐

References already disclose an interface that provides information about the “last

failed” message, and expressly disclose features for logging error messages. One

of ordinary skill in the art would have found it trivial to add the ability to provide

information about fault messages as well. (Id. ¶ 185.) Fault messages are

common in any network, and persons of ordinary skill in the art used fault

messages to monitor network performance. (Id. ¶ 186.) Staub provides an

express motivation by explaining that “network devices generate error

messages,” and “[t]hese error messages help technicians repair the network

devices.” (Staub, Ex. 1015, 1:13‐15 (underlining added).) These claims are

therefore obvious. (Lavian Decl., Ex. 1002, ¶ 188.)

Claim 15 further recites notifying the manager that “one of the participants

in the conversation sent an unexpected fault message.” In Staub, each time a

“fault message” is received, Staub calculates a “tally” and compares it against a

predetermined threshold. (Staub, Ex. 1015, 2:28‐30.) “When a tally threshold is

exceeded a network problem message is sent to the operator interface 32.” (Id.,

2:38‐39 (underlining added).) One of ordinary skill in the art would have

understood that the purpose of creating such a threshold is to be able to detect

when a greater‐than‐expected number of particular types of fault messages were

received. (Lavian Decl. ¶¶ 189‐91.) Staub therefore discloses and renders


‐58‐

obvious the additional feature recited in claim 15.

2. Claims 7‐9 and 12 (“Number of Messages” Claims)

Claims 7‐9 and 12 recite additional statistical information about messages.

(See Claim 7 (“information regarding the number of successful messages

processed by the conversation.”), claim 8 (“number of failed messages”), claim 9

(“total number of messages”), claim 12 (“total number of failed messages”). The

Collaborate References specifically disclose the ability to retrieve information

such as “number of messages sent, number of messages outstanding, time of last

sent and received message, [and] time of first and last failed message.”

(Administering Collaborate, Ex. 1005 at 6‐4 (“Trading partner page,” “Sessions,”

second bullet point) (underlining added).) It would have been obvious to one of

ordinary skill in the art that the claimed “interface” in WebLogic Collaborate could

have been adapted to include the total number of messages for a conversation, as

well as the number of successful and failed messages. (Lavian Decl., Ex. 1002, ¶¶

195‐97.) The interface already keeps track of the number of messages and the

last failed message, and provides logging capability as previously discussed.

Moreover, Staub specifically discloses the ability to record the total number of

fault messages. It would have obvious that the interface could provide the

number of successful, failed or total, for example, by simple addition or


‐59‐

subtraction. (Id.)

C. Ground 3 – Claims 10 and 26 Are Obvious Over the Collaborate References in view of Fox, Staub and Scribner

Claims 10 and 26 depend from claims 8 and 25, respectively, and require

that the messages be “exchanged via the simple object access protocol (SOAP).”

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. As explained in Scribner: “Although SOAP isn’t officially an Internet

standard, it has been widely adopted by the Internet community, including the

Electronic Business XML (ebXML) organization, for its transport and routing

layer.” (Scribner, Ex. 1009, at 20 (under “SOAP”) (underlining added).)

It would have been obvious to one of ordinary skill in the art to combine

Scribner, predictably resulting in a WebLogic Collaborate messaging system using

SOAP to exchange messages in a conversation. Scribner and the Collaborate

References, moreover, provide express motivations to combine. Scribner notes

that SOAP had been “widely adopted” and had been incorporated into the

“ebXML” standard. (Scribner, Ex. 1009, at 19‐20.) The Collaborate References

state that WebLogic Collaborate uses the “ebXML” standard for conversation

message routing. (Introducing Collaborate, Ex. 1004, at 1‐14 (“The eXtensible


‐60‐

Open Collaboration Protocol (XOCP) is a BEA‐specific business protocol. The XOCP

business protocol supports the standards‐based ebXML Transport . . . .”).)

One of ordinary skill in the art, therefore, would have understood the

Collaborate References to inherently disclose message exchange using SOAP. In

any event, the exchange of messages using SOAP as recited in claims 10 and 26

would have been obvious to one of ordinary skill in the art. (Lavian Decl., Ex.

1002, ¶ 202.)

VIII. CONCLUSION

The Petitioner respectfully requests that the Board institute IPR on claims 1,

5, 7‐10, 12, 15 and 24‐26 of the ’860 patent and find them unpatentable.

Dated: February 6, 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. Sections 42.6, that a complete copy

of the PETITIONER’S PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO.

7,945,860, and EXHIBITS 1001 to 1015, and related documents are being served

via Federal Express on the 6th day of February, 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 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. Feb. 6, 2014) as follows:

Mark D. Flanagan, Esq. Wilmer Cutler Pickering Hale and Dorr LLP 950 Page Mill Road Palo Alto, CA 94304

DATED: February 6, 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


‐2‐

CERTIFICATE OF SERVICE

I hereby certify, pursuant to 37 C.F.R. Sections 42.6, that I have caused to

be personally served upon the Patent Owner, by serving the correspondence

address of record with the USPTO as noted below, a complete copy of the

PETITIONER’S PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO.

7,945,860, and EXHIBITS 1001 to 1015, and related documents on the 7th day of

February, 2015:

Hewlett‐Packard Company [for Saturday Delivery] Intellectual Property Administration 3404 East Harmony Road Mail Stop 35 Fort Collins, CO 80528

DATED: February 6, 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:	vokhue
View:	219 times
Download:	0 times

Petition for Inter Partes Review of Patent 7,945,860...

Documents