petition for inter partes review of patent 7,925,981 states...
Post on 05-Apr-2020
5 Views
Preview:
TRANSCRIPT
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
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,925,981 Filing Date: May 14, 2003 Issue Date: April 12, 2011
TITLE: SYSTEMS AND METHODS FOR MANAGING
WEB SERVICES VIA A FRAMEWORK OF INTERFACES
PETITION FOR INTER PARTES REVIEW
OF U.S. PATENT NO. 7,925,981
Inter Partes Review No. 2015‐00707
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 ........................... 4
A. Early History of Conducting Business over the Web ........................... 4
B. Modern “Web Services” ..................................................................... 5
V. SUMMARY OF THE CLAIMED SUBJECT MATTER ........................................... 7
A. The Specification of the ’981 Patent ................................................... 7
B. The Challenged Claims of the ’981 Patent .......................................... 9
VI. CLAIM CONSTRUCTION UNDER 37 C.F.R. § 42.104(B)(3) ............................ 11
A. “Web service” ................................................................................... 11
B. “managed object” and “service managed object” ........................... 12
1. “managed object” .................................................................. 12
2. “service managed object” ...................................................... 14
C. “manager” ........................................................................................ 15
D. “Interface,” “Managed Object Interface,” “Service Interface” ......... 17
Table of Contents (continued)
Page
‐ii‐
1. “interface” .............................................................................. 17
2. “managed object interface” ................................................... 19
3. “service interface” .................................................................. 19
E. “conversation” .................................................................................. 20
VII. CLAIMS 1, 22 AND 23 OF THE ’981 PATENT ARE UNPATENTABLE .............. 21
A. Ground 1 – Claims 1, 22 and 23 Are Obvious Over the Collaborate References in view of Fox ............................................. 21
1. Prior Art and Date Qualification for Ground 1 ........................ 21
2. Brief Summary of the Prior Art Applied in Ground 1 .............. 24
3. The Collaborate References Are Properly Combinable .......... 27
4. Claim 1 .................................................................................... 29
a. “the service managed object is associated with the Web service and includes at least one interface configured to allow a manager to access management features for the Web service” (Claim 1[c]) .............................................................................. 34
5. Claim 22 .................................................................................. 47
6. Claim 23 .................................................................................. 58
VIII. CONCLUSION .............................................................................................. 60
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
List of Exhibits
‐iii‐
Ex. No Description of Document
1001 U.S. Patent No. 7,925,981 to M. Homayoun Pourheidari et al.
1002 Declaration of Tal Lavian, Ph.D.
1003 U.S. Patent No. 7,945,860 to Guillaume N. Vambenepe 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐1‐
Petitioner ServiceNow, Inc. (“Petitioner”) respectfully submits this Petition
for Inter Partes Review of claims 1, 22 and 23 of U.S. Patent No. 7,925,981 [Ex.
1001] (“the ’981 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 ’981 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 ’981 patent challenged in this Petition.
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) hkeefe@cooley.com zpatdcdocketing@cooley.com 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) amace@cooley.com zpatdcdocketing@cooley.com COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (650) 843‐5808 Fax: (650) 849‐7400
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐2‐
D. Service Information
This Petition is being served by FedEx to the current correspondence
address for the ’981 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 three (3) claims of the ’981 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 ’981 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐3‐
respect to the ’981 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, 22 and 23 of the ’981 patent 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)
The references listed above qualify as prior art under 35 U.S.C. § 102(b)
because each reference was published more than one year before May 14, 2003,
the earliest application to which the ’981 patent could claim priority. The first
three prior art references are product manuals for a commercial product, BEA
WebLogic Collaborate, sold by BEA Systems, Inc. These manuals, which will
collectively be referred to as the “Collaborate References,” are dated July 2001
and were publicly available on the Internet by no later than August 2001. The
ground on which this Petition is based is listed in the table below.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐4‐
Ground Claims Basis for Challenge
1 1, 22, 23 Unpatentable over the Collaborate References in view of Fox, 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, ¶¶ 5‐14, 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, 22 and 23
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.
IV. BRIEF BACKGROUND OF THE UNDERLYING TECHNOLOGY
A. Early History of Conducting Business over the Web
“Web services” were not an invention of the ’981 patent, but were an
outgrowth of the World Wide Web and the explosion of its popularity that began
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐5‐
in the 1990s. (Lavian Decl., Ex. 1002, ¶ 22.) 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 business application or database.
(Id.) 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.,
Fox, Ex. 1008, at p.482‐83.)
But the industry realized that as web‐based businesses grew, especially
larger enterprises such as rental car companies and airlines, systems would need
to support coordination among a potentially large number of distributed systems.
(Lavian Decl., Ex. 1002, ¶ 23; 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.”).)
B. Modern “Web Services”
The Background section of the ’981 patent states that “web services” are
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐6‐
“an approach to distributed computing in which interactions are carried out
through the exchange of eXtensible Markup Language (XML) messages.” (’981,
1:55‐58.) The term “XML,” like web services generally, was not an invention of
the ’981 patent. XML is an industry‐standard set of rules for creating documents
that contain information. (Lavian Decl., Ex. 1002, ¶ 24.) 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, ¶ 24.) 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 ’981 patent acknowledges that web services were
already being deployed commercially before the alleged invention. (’981, 2:44‐45
(“Enterprises are adopting Web services technology to address their business
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐7‐
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 ’981 Patent
The ’981 patent, entitled “Systems and Methods for Managing Web
Services via a Framework of Interfaces,” generally describes a web service
management system that allows a manager to monitor and control associated
web services. Figure 1A provides a general overview of one embodiment:
(’981, Ex. 1001, Fig. 1A.) The management system in Figure 1A includes a “service
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐8‐
managed object” (e.g., 110) that has an interface for exposing management
features of an associated web service (e.g., 106) to a manager (e.g., 102). The
’981 patent describes a “service managed object” as follows:
Service managed objects 108, 110 represent the management
features of resource(s) that perform services 104, 106. Interfaces in
one or more categories can be included in service interfaces 112, 114
for each service managed object 108, 110. Service interfaces 112,
114 can allow manager 102 to access information regarding the state
of services 104, 106, as well as to control the operation of services
104, 106.
(’981, 4:51‐60 (underlining added).)
The ’981 patent also states that “[s]ervice managed objects . . . can be
considered managed objects.” (’981, 7:27‐29.) The specification explains that a
managed object “implements managed object interfaces . . . to provide a
common set of basic management capabilities to monitor and/or control the
underlying resource(s) represented by managed object . . . through various
features such as attributes, operations, and event notifications.” (’981, 7:30‐35.)
A key limitation recited in the claims challenged in this Petition is a
“conversation.” One of the management features of a “service managed object,”
according to the specification, is its ability to monitor “conversations” associated
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐9‐
with a particular web service. Although the ’981 patent does not define
“conversation,” it incorporates by reference U.S. Patent No. 7,945,860 (“’860
patent”), a related patent that provides more detail about “conversations.” (’981,
Ex. 1001, 1:7‐12.) The ’860 patent, which issued from an application filed on the
same day as the ’981 patent, 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
shown). The messages received by a particular conversation 104, 106
may be sent by more than one other conversation, and a particular
resource, such as a Web service, can invoke multiple conversations
that may or may not be related to the resource’s other
conversations.
(’860, Ex. 1003, 4:45‐52 (underlining added).)
B. The Challenged Claims of the ’981 Patent
The two independent claims addressed in this Petition—claims 1 and 22—
purport to recite a system and computer program product for managing a web
service. Representative claim 1 recites:
1. A system for managing a Web service, comprising:
[a] a computer processor; and
[b] a service managed object executable on the computer
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐10‐
processor, wherein:
[c] the service managed object is associated with the Web service
and includes at least one interface configured to allow a
manager to access management features for the Web service;
and
[d] the at least one interface is configured to provide a list of
conversations associated with the Web service.
(’981, 19:34‐43 (Claim 1).) The bracketed notations (e.g., “[a],” “[b],” etc.) were
added to facilitate easier identification of these limitations in this Petition. The
second independent claim addressed in this Petition is claim 22:
22. A computer program product tangibly embodied in a computer
readable storage medium, comprising:
[a] a service interface; and
[b] a managed object interface associated with the service
interface, wherein
[c] the service interface is configured to include information for
managing a Web service, including information indicating
conversations associated with the service that are in progress.
(’981, 21:31‐39 (Claim 22).) The other claim addressed in this Petition—i.e., claim
23—depends from independent claim 22 listed above. This Petition will address
that claim in more detail in Part VII.A.6 below.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐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 22) 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.
(’981, 1:55‐67 (underlining added).)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐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 would have understood “Web service” as of May 2003. (Lavian Decl., Ex.
1002, ¶ 36.) Accordingly, the term “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. “managed object” and “service managed object”
The term “managed object” is recited in a number of ways in the claims.
Independent claim 1 recites a “service managed object,” while independent claim
22 recites a “managed object interface.” This Petition will therefore separately
address “managed object” and “service managed object.”
1. “managed object”
The term “managed object,” generally speaking, 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” to one of
ordinary skill in the art is “an object for managing a resource.” This definition
flows in part from the following passage of the specification:
Referring to FIG. 1B, an embodiment of managed object 128 with
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐13‐
managed object interfaces 130 is shown. Managed object 128 is a
management representation of a resource. For example, service
managed objects 108, 110 in FIG. 1A can be considered managed
objects 128.
Managed object 128 implements managed object interfaces 130 to
provide a common set of basic management capabilities that allow
manager 102 to monitor and/or control the underlying resource(s)
represented by managed objects 128 through various features such
as attributes, operations, and event notifications.
(’981, Ex. 1001, 7:30‐35 (underlining added).) This is consistent with an earlier
passage in the specification stating that “[s]ervice managed objects 108, 110
represent the management features of resource(s) that perform services 104,
106.” (’981, 4:53‐55 (underlining added).)
The specification describes “resources” broadly as including “documents,
images, downloadable files, services, electronic mailboxes, and other resources.”
(’981, 5:67‐6:2.) The specification also describes “management” as including
“managed object identity, monitoring, discovery, control, performance,
configuration, and security.” (’981, 5:8‐11.) Based on the above passages of the
specification, the Board should find that the broadest reasonable construction of
“managed object” is “an object for managing a resource.”
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐14‐
2. “service managed object”
The specification describes a “service managed object” is a managed object
with an additional characteristic – it is “associated with a service.” As explained
below, the Board should interpret “service managed object” as “an object for
managing a resource that is associated with a service.”
The specification makes clear that that service managed objects can be
considered managed objects. (’981, 7:27‐29.) The key distinction between the
two types of object is that a “service managed object,” according to the
specification, performs a service and has an “interface” to allow a manager to
access management features for the service:
Service managed objects 108, 110
represent the management features
of resource(s) that perform services
104, 106. Interfaces in one or more
categories can be included in service
interfaces 112, 114 for each service
managed object 108, 110. Service
interfaces 112, 114 can allow manager 102 to access information
regarding the state of services 104, 106, as well as to control the
operation of services 104, 106.
(’981, 4:53‐60 (underlining added), Fig. 1A (excerpt).)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐15‐
The claim language is generally consistent with this description. Claim 1,
for example, recites “the service managed object [that] is associated with the
Web service and includes at least one interface configured to allow a manager to
access management features for the Web service.” The underlined portion of the
claim language reflects the “service” aspect of the managed object.
The specification further makes clear that although a “service managed
object” is associated with a service, the term under its broadest reasonable
construction requires no particular physical relationship between the “service
managed object” and its associated “service.” Service managed objects,
according to the specification, “can be implemented within services 104, 106,
such as shown for service managed object 108 [in Fig. 1A], or in a layer external to
services 104, 106, as shown for service managed object 110.” (’981, 4:67‐5:3.)
Thus, in light of the specification and claim language, the Board should find
that a “service managed object” under its broadest reasonable construction is an
“object for managing a resource that is associated with a service.”
C. “manager”
Independent claim 1 recites a “manager.” The term “manager” does not
refer to a human being, but a software process or system. Claim 1 recites that the
“service managed object is associated with the Web service and includes at least
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐16‐
one interface configured to allow a manager to access management features for
the Web service.” As explained below, the Board should find that the broadest
reasonable construction of a “manager” is a “software process or system for
accessing management features.”
The specification of the ’981 patent does not provide specific details about
implementation of the claimed “manager,”
but instead describes it in almost entirely
functional language. In Figure 1A (excerpted
at right), the manager is depicted as box 102
shown on the left of the figure. “Referring to
FIG 1A,” the specification states, “an embodiment of a Web service management
system 100 that allows manager 102 to monitor and control one or more services
104, 106 is shown.” (’981, 4:51‐53.)
As noted, the claim term “manager” does not refer to a human being, but
rather, to a software process or system. The specification of the related U.S.
Patent No. 7,945,860 [Ex. 1003], which is incorporated‐by‐reference into the ’981
patent (at ’981, 1:7‐12), makes clear that the “manager” is software‐based. (’860,
Ex. 1003, 8:57‐62 (“In the embodiments shown, manager 102 . . . [is]
implemented in computer processing systems 160 through 168, respectively.”
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐17‐
(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.”
D. “Interface,” “Managed Object Interface,” “Service Interface”
Independent claim 1 recites an “interface” associated with the “service
managed object,” while independent claim 22 recites a “service interface” and an
associated “managed object interface.” This Petition will therefore first address
the common term “interface,” and then turn to the more specific terms.
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, ¶ 50.) For example, a “graphical user interface,” a term
familiar to many computer users, generally describes a way in which a computer
makes it 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐18‐
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., ¶ 51.) 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
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., ¶ 52.) For example, as mentioned
above with respect to “service managed object,” the specification states that a
“service managed object is associated with the Web service and includes at least
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐19‐
one interface configured to allow a manager to access management features for
the Web service.” (’981, 3:43‐46.) Thus, consistent with its plain and ordinary
meaning to persons of ordinary skill in the art, the term “interface” under its
broadest reasonable construction should be interpreted as “a connection point
for communication and/or exchange of information.”
2. “managed object interface”
Independent claim 22 recites a “managed object interface.” The
specification of the ’981 patent generally describes a “managed object interface”
as an interface associated with a managed object. For example, the specification
states that “FIG. 1A also shows managed object interfaces 122 associated with
service managed object 108, and managed object interfaces 124 associated with
service managed object 110.” (’981, 7:22‐24 (underlining added).) Thus, the term
“managed object interface” should be construed under its broadest reasonable
construction as an “interface associated with a managed object (i.e., an object
for managing a resource).”
3. “service interface”
Independent claim 22 also recites a “service interface.” As with “managed
object interface,” the specification of the ’981 patent generally describes a
“service interface” as an interface associated with a service. For example,
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐20‐
specification states that: “Service interfaces 112, 114 [Fig. 1A] can allow manager
102 to access information regarding the state of services 104, 106, as well as to
control the operation of services 104, 106.” (’981, 4:57‐60 (underlining added).)
A “service interface” under its broadest reasonable construction should be
interpreted as an “interface associated with a service.”
E. “conversation”
Independent claims 1 and 22 both recite “conversations” associated with a
service. As explained below, the term “conversation” should be understood to
mean “a set of related messages for exchange of information.”
The specification states that services can exchange information using
“conversations.” (’981, 14:38‐41 (“Information . . . can be exchanged via
conversations 214, 216 between online ordering service 204 and billing service
210.”), 981, 12:63‐13:6.) As noted in Part V.A above, the specification of the
related U.S. Patent No. 7,945,860 [Ex. 1003], which is incorporated‐by‐reference
into the ’981 patent (’981, 1:7‐12), provides a somewhat circular description of a
“conversation”:
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
shown). The messages received by a particular conversation 104, 106
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐21‐
may be sent by more than one other conversation, and a particular
resource, such as a Web service, can invoke multiple conversations
that may or may not be related to the resource’s other
conversations.
(’860, Ex. 1003, 4:45‐52.) Consistent with these descriptions, the Board should
interpret “conversation” under its broadest reasonable construction as a “set of
related messages for exchange of information.”
VII. CLAIMS 1, 22 AND 23 OF THE ’981 PATENT ARE UNPATENTABLE
This Petition identifies the following ground on which IPR should be
instituted for claims 1, 22 and 23 of the ’981 patent:
Ground Claims Basis for Challenge
1 1, 22, 23 Unpatentable over the Collaborate References in view of Fox, under 35 U.S.C. § 103(a)
A. Ground 1 – Claims 1, 22 and 23 Are Obvious Over the Collaborate References in view of Fox
1. Prior Art and Date Qualification for Ground 1
Each limitation of claims 1, 22 and 23 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐22‐
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 qualify as prior art to the ’981 patent under at
least 35 U.S.C. § 102(b) (pre‐AIA) because they were published more than one
year before May 14, 2003, the earliest filing to which the ’981 patent can claim
priority. Fox likewise qualifies as prior art under § 102(b).
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
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, ¶¶ 142‐47; 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐23‐
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, ¶¶ 143, 144.) 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, ¶ 144;
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, ¶ 144.)
The download page was part of what BEA called its “e‐docs Web Site” (e‐
docs.bea.com), which the Collaborate References themselves describe as a
central source of documentation about BEA’s products. (See Introducing
Collaborate, Ex. 1004, at vi (“The WebLogic Collaborate product documentation is
available on the BEA Systems, Inc. corporate Web site.”); Administering
Collaborate, 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, which is
available on the documentation CD and on the e‐docs Web site at http://e‐
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐24‐
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, ¶ 147.)
Finally, BEA Systems, Inc., the company that made the Collaborate
References, was a well‐known provider of web services products in the early
2000s, claiming more than 11,000 customers worldwide by 2001. (Id. ¶ 148.)
Accordingly, the Collaborate References were sufficiently available that persons
of ordinary skill in the art could have located them with reasonable diligence.
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
entity include other entities with which it conducts business, such as its
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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐25‐
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:
(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.)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐26‐
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.” (emphasis in original).)
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)
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.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐27‐
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
Collaborate References to be combinable. (Lavian Decl., Ex. 1002, ¶¶ 69‐75.)
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. ¶¶ 70, 71.)
In fact, the Collaborate References cite and make express references to
each other. For example, Introducing Collaborate includes a section entitled
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐28‐
“Document Roadmap for WebLogic Collaborate” that lists a number of other
documents that the reader can consult to “find more detailed information about
various features of your WebLogic Collaborate.” (Introducing 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 many
other examples of specific citations and cross‐references to each other. (See, for
example, Introducing Collaborate, Ex. 1004, at 1‐14 (“For details about
administering both system and custom logic plug‐ins, see Administering BEA
WebLogic Collaborate”); id. at 1‐31 (“For complete details about using the
WebLogic Collaborate Administration Console, see Administering BEA WebLogic
Collaborate”), id. (“For details about programming management applications, see
Programming BEA WebLogic Collaborate Management Applications.”).) The
Collaborate References, in fact, specifically encourage the reader to consult each
other. (See, for example, Administering Collaborate, Ex. 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,
therefore, would have been amply motivated to combine and would have
considered them part‐and‐parcel of a single disclosure. (Lavian Decl. ¶ 74.)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐29‐
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 Web service.”
The Collaborate References disclose this. The “Web service” in the Collaborate
References takes the form of the WebLogic Collaborate system.
As explained in Part VI.A above, the term “Web service” should be
understood as “a service or system that interacts with another system through
the exchange of eXtensible Markup Language (XML) messages.” As explained in
the “Overview” section of Introducing Collaborate:
The BEA WebLogic Collaborate™ product is an XML‐ and Java‐
based e‐commerce platform that enables you to implement
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.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐30‐
(Introducing Collaborate, Ex. 1004, at 1‐1 (emphasis added).) The Collaborate
References therefore clearly disclose the claimed “Web service.”
The Collaborate References also disclose “a system for managing a Web
service.” In particular, they describe a series of “administrative services” for
managing the WebLogic Collaborate service. (Id. at 1‐30 to 1‐31.)
The WebLogic Collaborate administration services support
multiple system management functions, including configuring,
administering, and monitoring trading partners, conversations,
collaboration agreements, and more.
Through these services, a WebLogic Collaborate administrator
can create, configure, and manage the components of the
WebLogic Collaborate system.
(Introducing Collaborate, Ex. 1004, at 1‐30 (under “Administration Services”)
(emphasis added).) The Collaborate References therefore also disclose “a system
for managing a Web service.”
a. “a computer processor” (Claim 1[a])
The first limitation of claim 1 recites “a computer processor.” The
Collaborate References disclose this limitation. In particular, 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐31‐
Administering Collaborate, Ex. 1005, at 1‐5 (“On a Windows system, you can start
WebLogic Collaborate with the program icons or from the 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. One of ordinary skill in the art would have understood that, in
order for a system to execute WebLogic Collaborate on a Microsoft Windows or
Unix system, or to run a Java‐based program, the system would have included at
least one computer processor. (Lavian Decl., Ex. 1002, ¶ 83.)
b. "a service managed object executable on the computer processor" (Claim 1[b])
The second limitation of claim 1 recites “a service managed object
executable on the computer processor.” The “service managed object” in the
Collaborate References takes the form of a collection of programs known as the
“BEA WebLogic Collaborate Managed Beans,” also referred as “MBeans.”
These “Managed Beans” or “MBeans” are what is known as “JavaBeans.”
As explained by Dr. Lavian, Java refers to a programming language and software
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐32‐
development platform. The basic unit of Java program is known as a Java “class.”
(Lavian Decl., Ex. 1002, ¶ 85.) The term “JavaBean” describes a particular way to
encapsulate a Java class that, generally speaking, was intended to make software
components in Java more 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 “service
managed object” recited in the claim. The term “service managed object,” as
explained in Part VI.B.2 above, means “an object for managing a resource that is
associated with a service.” The “service” here is WebLogic Collaborate, the “Web
service” as discussed previously. The “resource” being managed is an aspect of
the WebLogic Collaborate service, such as a run‐time instance, delivery channel or
trading partner session. (Programming Collaborate, Ex. 1006, at 2‐3 to 2‐4, Table
2‐1 (listing WebLogic resources managed by MBeans).) As explained below, each
MBean manages at least one of these resources.
The Collaborate References confirm that the Managed Beans (the “service
managed object”) qualify as objects for managing resources associated with the
service (e.g., WebLogic Collaborate):
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐33‐
This document introduces WebLogic Collaborate MBeans and
management applications. MBeans are one of three types of
component applications available within WebLogic Collaborate.
Management applications use MBeans to monitor WebLogic
Collaborate.
(Id. at 1‐1 (under “WebLogic Collaborate Applications”) (underlining added).) The
’981 patent specification specifically lists “monitoring” as an activity that qualifies
as “managing” a resource. (’981, 5:8‐11.) The Collaborate References explain:
For all management applications, WebLogic Collaborate provides a
set of Managed Beans, or MBeans, which are special JavaBeans with
attributes and methods for management operations.
(Programming Collaborate, Ex. 1006, at 1‐3 (italics in original; underlining added).)
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).) The other
MBeans monitor other resources for WebLogic Collaborate such as delivery
channels, active transactions, trading partners, and messages. (Id. at 2‐3 to 2‐4,
Table 2‐1.) Again, as noted previously, “monitoring” qualifies as “managing a
resource” under the ’981 patent. (’981, 5:8‐11.)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐34‐
These MBeans, individually or as a group, clearly qualify as “an object for
managing a resource that is associated with a service,” i.e., the WebLogic
Collaborate service. (Lavian Decl. ¶ 89.) Each MBean manages a resource
associated with the WebLogic Collaborate service including its run‐time instance,
delivery channels, and so forth. (Programming Collaborate, Ex. 1006, at 2‐3 to 2‐
4, Table 2‐1.) The Collaborate References therefore disclose “a service managed
object executable on the computer processor,” as recited in the claim.
a. “the service managed object is associated with the Web service and includes at least one interface configured to allow a manager to access management features for the Web service” (Claim 1[c])
For convenience and ease of reading, this Petition will break this claim
limitation into two parts and address each portion separately.
i. “the service managed object is associated with the Web service” (Claim 1[c], first part)
The “Managed Beans” or “MBeans” in the Collaborate References satisfy
the first part of claim 1[c], “the service managed object is associated with the
Web service.” As noted above, the Managed Beans are associated with the Web
service, i.e., WebLogic Collaborate. (Programming Collaborate, Ex. 1006, at 1‐1
(“Management applications use MBeans to monitor WebLogic Collaborate.”), 1‐
3.) For example, the Managed Bean called “WLCMBean” “[r]epresents a
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐35‐
WebLogic Collaborate instance” and is “[u]sed for monitoring a WebLogic
Collaborate instance at run time.” (Programming Collaborate, Ex. 1006, at 2‐3,
Table 2‐1 (first item in table; underlining added).) The Collaborate References
therefore disclose that “the service managed object is associated with the Web
service,” as recited in the first part of claim 1[c].
ii. “the service managed object . . . includes at least one interface configured to allow a manager to access management features for the Web service” (Claim 1[c], second part)
The Collaborate References also disclose that the Managed Beans (the
“service managed object”) include “at least one interface configured to allow a
manager to access management features for the Web service,” as recited in the
second part of claim 1[c]. Because the “interface” recited in the claim language
must provide a “manager” with access to management features, this Petition will
first address how the Collaborate References disclose the claimed “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 an Internet web browser such as Internet Explorer. (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.,
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐36‐
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
addressed the “manager,” this Petition now turns to the claimed “interface.”
The Collaborate References also disclose the claimed “at least one
interface,” which is “configured to allow” the Administration Console (“manager”)
to the access management features for WebLogic Collaborate (the “Web
Service”). There are at least two separate and independent ways in which the
claimed “interface” can be mapped to the prior art.
First, the “interface” can be Application Programming Interfaces (APIs)
provided by the Managed Beans or MBeans, which provide management
features. The Collaborate References state that the Administration Console (the
claimed “manager”) uses MBeans APIs to access management features:
WebLogic Collaborate provides the application programming
interfaces (APIs) needed to create custom management applications
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐37‐
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
monitor running WebLogic Collaborate instances.”) (underlining added).)
As explained in connection with the earlier limitations of claim 1, these
Managed Beans or MBeans provide various management features, including
monitoring WebLogic Collaborate Instances and monitoring conversations.
(Programming Collaborate, Ex. 1006, at 2‐3 to 2‐4, Table 2‐1.)
As Dr. Lavian explains, an Application Programming Interface or “API,”
including the MBeans API discussed above, satisfies the “interface” claim
limitation because it provides the connection point for communication and/or
exchange of information between the Administration Console and the MBeans.
(Lavian Decl., Ex. 1002, ¶ 97.) Accordingly, the Collaborate References disclose
that the Managed Beans or MBeans (the “service managed object”) include “at
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐38‐
least one interface configured to allow a manager to access management features
for the Web service,” as recited in claim 1[c].
As noted above, there is a second, independent way in which the prior art
discloses the claimed “interface.” The “Administration Console,” as noted above,
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 ordinary skill in the art would have known that the web server that provides
the pages for the Administration Console would have included an “interface” to
(a) receive user selections through the Administration Console, and then (b) use
those selections to interact with other software (such as the MBeans) to retrieve
requested information. (Lavian Decl., Ex. 1002, ¶ 98.)
Such interfaces were well known to persons of ordinary skill in the art by
May 2003. An example of such an interface is the Common Gateway Interface
(CGI) disclosed in Fox. (Id. ¶¶ 99, 22.) Fox (Ex. 1008), which was published more
than six years before the filing date of the patent, describes various technologies
for allowing any web site (such as the Administration Console discussed above) to
interact with external programs. One such technology was known as the
“Common Gateway Interface,” which is an interface that allows a web server to
communicate with other software programs:
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐39‐
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.
(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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐40‐
database searches, send e‐mail, you name it.” (Id. at 484 (under “What Can I Do
with a CGI Script?”) (underlining added).)
Although the Collaborate References alone disclose the claimed
“interface,” the interface would also have been obvious over the Collaborate
References in view of the interface teachings in Fox. This provides a second and
independent ground for showing the obviousness of the claimed “interface.”
As explained by Dr. Lavian, 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. (Lavian Decl., Ex. 1002, ¶ 101.) This would have
predictably resulted in the Administration Console in WebLogic Collaborate (the
claimed “manager”) using a web server interface, such as CGI in Fox, as an
interface between the web server that receives user input and external programs
(such as the Managed Beans or MBeans) that provide functionality in response.
(Id.) This would have allowed the WebLogic Administration Console (the claimed
“manager”) to access management features for the WebLogic Collaborate system
(the claimed “Web service”) service using its web‐based user interface.
(Administering Collaborate, Ex. 1005, at 3‐2 (“The WebLogic Collaborate
Administration Console is used to . . . [m]onitor WebLogic Collaborate, trading
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐41‐
partner sessions, conversations, and collaboration agreements.”).)
One of ordinary skill in the art would have had many motivations to
combine. The technology was not complex. (Lavian Decl., Ex. 1002, ¶ 102.) Web
server interfaces to external programs (CGI being just 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.) CGI scripts
were so pervasive that, as explained in Fox, “CGI scripts are used for doing all of
the ‘cool’ stuff on the Net.” (Id.) One of ordinary skill in the art would certainly
have recognized that in order to implement dynamic web pages such as the
Administration Console pages, which are generated in response to requests and
queries, one could employ an interface such as CGI to facilitate interaction with
external programs. (Lavian Decl., Ex. 1002, ¶ 102.)
c. “the at least one interface is configured to provide a list of conversations associated with the Web service.” (Claim 1[d])
The final limitation of claim 1 requires that “the at least one interface is
configured to provide a list of conversations associated with the Web service.” As
shown in Part VI.E, that the term “conversation” means “a set of related
messages for exchange of information.” The Collaborate References disclose this.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐42‐
As explained above for claim 1[c], the Administration Console uses the
interface (API) provided by the MBeans to access management features for the
WebLogic Collaborate system. These features include retrieving a list of
conversations associated with the WebLogic Collaborate system (the “Web
service”). As noted above, the Collaborate References explain that a
“conversation” is “a series of business messages exchanged between trading
partners.” (Introducing Collaborate, Ex. 1004, at 1‐7 to 1‐8, see also ¶¶ 65‐66
above.) This language indicates that “conversations” in the Collaborate
References are equivalent to the “conversations” recited in the claims.
The Collaborate References disclose several ways in which “a list of
conversations associated with the Web service,” i.e., WebLogic Collaborate, may
be provided:
There are three options for listing active XOCP conversations:
List the conversations for a selected conversation definition
To list the conversations for a selected conversation definition,
select a conversation definition from the navigation tree or
Conversations page, then select the Monitoring tab to view the
list of active conversations for that conversation definition.
List the conversations for a selected delivery channel
To list the conversations for a selected delivery channel, list
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐43‐
delivery channels as described in Monitoring Delivery Channels”
on page 6‐9. When you select a delivery channel from the list, the
number of conversations for that delivery channel is displayed as
part of the summary statistics for the delivery channel. You can
view a list of the conversations for that delivery channel by
clicking the number.
List the conversations for a trading partner session
To list the conversations for a selected trading partner session, list
trading partner sessions as described in “Monitoring Trading
Partner Sessions” on page 6‐7. When you select a trading partner
session from the list, the number of conversations for that trading
partner session is displayed as part of the summary statistics for
the trading partner session. You can view a list of the
conversations for that trading partner session by clicking the
number.
(Administering Collaborate, Ex. 1005, at 6‐10 (under “Monitoring Conversations”)
(italics in original; underlining added).) Selecting a conversation from a
conversation list will bring up a window showing information about the selected
conversation such as the conversation identifier, start time of the conversation,
and other information. (Id. at 6‐11 (Figure 6‐5).)
The quoted text above refers to “XOCP,” which stands for the eXtensible
Open Collaboration Protocol (XOCP). (Introducing Collaborate, Ex. 1004, at 1‐14
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐44‐
(under “XOCP”).) XOCP is “a BEA‐specific business protocol” for providing
messaging services. (Id.) WebLogic Collaborate supports several different
messaging protocols, including XOCP. (Id. at 1‐13 (“WebLogic Collaborate
supports the following business protocols: ▪ XOCP (eXtensible Open Collaboration
Protocol). . .”) (middle of page).)
The prior art also discloses that the conversation lists are provided by the
claimed “interface.” As explained for the preceding claim limitation, this Petition
has described at least independent two ways in which the prior art discloses the
“interface” recited in the claim: (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. Either theory fully discloses an
interface that “is configured to provide a list of conversations associated with the
Web service,” as recited in the claim.
With respect to the first theory in which the “interface” takes the form of
MBeans APIs, one those APIs called “getActiveConversations” provides
the 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
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐45‐
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
plain English, the above‐quoted paragraph describes services provided by MBean
APIs referred to above as “accessor methods.” (Lavian Decl., Ex. 1002, ¶ 109.)
Generally speaking, 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. (Id.) An “accessor
method” generally refers to a method that retrieves (“gets”) data from an object.
In the text quoted above, “getActiveConversations()” refers to 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. (Id. ¶ 110.) As explained above, this method “returns an array of type
ConversationMBean that represents all the active conversations in this session.”
(Programming Collaborate, Ex. 1006 at 2‐10 (underlining added).)
This accessor method is part of the MBean API (the claimed “interface”) as
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐46‐
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
Collaborate instances.”).) The Collaborate References therefore disclose that “the
at least one interface is configured to provide a list of conversations associated
with the Web service,” as recited in claim 1[d]. (Lavian Decl., Ex. 1002, ¶ 111.)
With respect to the second theory shown above in which the “interface” is
a web server interface such CGI (described in Fox), one of ordinary skill in the art
would have recognized that such a web server interface could also have been
“configured to provide a list of conversations associated with the Web service.”
(Id. ¶ 112.) This is because the list of conversations is reported back to the user
through a web page accessible through the Administration Console, as explained
above. (See also Administering Collaborate, Ex. 1005, at 3‐12 (Figure 3‐8).) The
ability to dynamically generate a web page in response to user input, such as a list
of conversations in the Administration Console, is a key reason to use a web
server interface such as the Common Gateway Interface (CGI). (Fox, Ex. 1008, at
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐47‐
485 (describing possible uses of CGI including ability to “create graphic images on‐
the‐fly,” “serve maps,” “send you live video feeds” and “access huge databases”);
Lavian Decl., Ex. 1002, ¶¶ 112, 113.)
Under either theory, therefore, the prior art discloses that “the at least one
interface is configured to provide a list of conversations associated with the Web
service,” as recited in the claim. For all of these reasons, therefore, the
Collaborate References and Fox render claim 1 obvious.
5. Claim 22
Claim 22 is similar in many respects to claim 1, but lists the elements in
slightly different order. The Collaborate References disclose all limitations of
claim 22 for many of the same reasons as claim 1.
The preamble of claim 22 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. (See
Administering Collaborate, Ex. 1005, at 1‐5 (Windows), 1‐7 (UNIX); Introducing
Collaborate, Ex. 1004, at 1‐1 (“WebLogic Collaborate is implemented entirely in
Java and leverages the J2EE standard APIs.”).)
The Collaborate References make clear that the WebLogic Collaborate is
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐48‐
stored on a computer readable storage medium. For example, the Collaborate
References explain that the WebLogic Collaborate software is installed in
particular directories. For example, in order to start WebLogic Collaborate from
Windows, the Collaborate References tell the user to navigate to a directory
called “\bea\wlintegration2.0\collaborate\config\mydomain” and execute a
command called “startWeblogic.” (Administering Collaborate, Ex. 1005, at 1‐6
(under “Starting WebLogic Collaborate from the Command Line”).) One of
ordinary skill in the art would have understood that these disclosures confirm the
presence of a “computer readable storage medium” such as a hard disk drive or
other type of digital storage device. (Lavian Decl., Ex. 1002, ¶ 117.) The
Collaborate References therefore disclose “[a] computer program product
tangibly embodied in a computer readable storage medium.”
a. “service interface” limitations (Claims 22[a], 22[b])
Claim 22 recites a “service interface,” followed by a “managed object
interface,” and then ends with lengthy “wherein” clause that refers to the
“service interface.” In the interest of ease of reading, and to keep the discussion
of common claim limitations in one location, this Petition will first address the
“service interface” limitations, and then address the “managed object” term.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐49‐
i. “a service interface” (Claim 22[a])
The first limitation of claim 22 recites “a service interface.” As explained in
Part VI.D.3 above, the term “service interface” means “an interface associated
with a service.” The “service interface” described in claim 22 is substantially
similar, for purposes of this Petition’s application of the claims to the Collaborate
References, to the “interface” recited in claim 1 discussed above.
As with claim 1, there are at least two separate and independent ways in
which the prior art discloses the claimed “service interface.” First, the Collaborate
References disclose a “service interface” in the form of Application Programming
Interfaces (APIs) provided by the Managed Beans or MBeans, which provide
management features:
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”); see also id. at 2‐5 (“The WebLogic Collaborate Administration Console
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐50‐
uses the JMX API and WebLogic Collaborate MBeans to monitor running
WebLogic Collaborate instances.”).)
The Managed Beans or MBeans API is associated with a service, i.e., the
WebLogic Collaborate service. (Programming Collaborate, Ex. 1006, at 1‐1
(“Management applications use MBeans to monitor WebLogic Collaborate.”), 1‐
3.) For example, the Managed Bean called “WLCMBean” “[r]epresents a
WebLogic Collaborate instance” and is “[u]sed for monitoring a WebLogic
Collaborate instance at run time.” (Programming Collaborate, Ex. 1006, at 2‐3,
Table 2‐1 (first item in table; underlining added).) The Collaborate References
therefore disclose “a service interface,” as recited in claim 1[a].
Under the second theory discussed above, the “service 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 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[d] above, it would have been obvious to one of
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐51‐
ordinary skill in the art to adapt Fox’s teachings about the Common Gateway
Interface (CGI) to the Collaborate References, with no change in their respective
functions. (Lavian Decl., Ex. 1002, ¶¶ 101, 102, 123.) This would have predictably
resulted in the Administration Console in WebLogic Collaborate (the claimed
“manager”) using a web server interface such as the CGI (from Fox) as an
interface associated with a service, i.e., the WebLogic Collaborate system.
(Administering Collaborate, Ex. 1005, at 3‐2 (“The WebLogic Collaborate
Administration Console is used to . . . [m]onitor WebLogic Collaborate, trading
partner sessions, conversations, and collaboration agreements.”).)
As explained for claim 1[d] above, one of ordinary skill in the art would
have had many motivations to combine. Web server interfaces to external
programs (CGI being just one example) were part of the basic repertoire of
knowledge possessed by persons of ordinary skill in the art well before May 2003.
(Lavian Decl., Ex. 1002, ¶¶ 101, 102, 123, 124.) One of ordinary skill in the art
would certainly have recognized that in order to implement dynamic web pages
such as the Administration Console pages, which are generated in response to
requests and queries, one could employ an interface such as CGI to facilitate
interaction with external programs. (Id. ¶ 124.) The Collaborate References
(alone or in combination with Fox) disclose the “service interface” of claim 22[a].
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐52‐
ii. “wherein the service interface is configured to include information for managing a Web service, including information indicating conversations associated with the service that are in progress” (Claim 22[b])
Both of the interfaces described above for the claimed “service interface,”
i.e., the MBeans API and the web server interface (such as CGI), include
“information for managing a Web service, including information indicating
conversations associated with the service that are in progress.”
With respect to the first theory in which the claimed “service interface”
comprises the MBeans APIs, as explained for claim 1[d] above, the Managed
Beans or MBeans provide information for monitoring WebLogic Collaborate
conversations. For example, the Managed Beans 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 Collaborate References also explain
that the APIs provided by the Managed Beans or MBeans (the “service interface”),
such as the getActiveConversations() method discussed for claim 1[d] above,
“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).)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐53‐
With respect to the second theory in which the claimed “service interface”
comprises a web server interface such as the Common Gateway Interface (CGI),
as explained for claim 1[d] above, an interface such as CGI could also have
included “information for managing a Web service, including information
indicating conversations associated with the service that are in progress.” This is
because the list of conversations is reported back to the user through a web page
accessible through the Administration Console, as explained above. The web
server interface would have included “information indicating conversations
associated with the service that are in progress” because, as noted, that interface
was used to obtain and deliver the web page for the Administration Console
listing the active conversations. (Fox, Ex. 1008, at 490 (under “Lesson #4: How to
Use a Script to Access Other Applications”); Lavian Decl., Ex. 1002, ¶¶ 126‐28.)
As explained above, one of ordinary skill in the art would have had ample
motivation to combine. (Id. ¶¶ 112, 128.) The ability to dynamically generate a
web page in response to user input, such as a list of conversations in the
Administration Console, is a key reason to use a web server interface such as CGI.
(Fox, Ex. 1008, at 485.) Therefore, as stated in claim 1[d] above, the Collaborate
References alone, or in combination with Fox, disclose that the service interface
“is configured to include information for managing a Web service, including
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐54‐
information indicating conversations associated with the service that are in
progress.”
b. “a managed object interface associated with the service interface” (Claim 22[b])
The second limitation of claim 22 recites “a managed object interface
associated with the service interface.” There is no further mention of this
interface in claim 22. The claim does not expressly recite any particular function
this interface must perform, it simply requires that it exist. In any event, the
Collaborate References disclose this limitation.
As explained in Part VI.B.1 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 22, 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 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, among other things, supports importing and
exporting data and other system administration tasks using the Administration
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐55‐
Console. (Introducing Collaborate, Ex. 1004, at 1‐29 to 1‐30, 2‐19 to 2‐21.)
As with the “service interface” 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 the following figure:
(Introducing Collaborate, Ex. 1004, at 1‐29 (Figure 1‐9: “WebLogic Collaborate
Services”).) As shown in Figure 1‐29 above from Introducing Collaborate, the
Repository Services (shown in the middle row) interact with the WebLogic
Collaborate Administration Console (shown on the top right) through the
“Administration Services.” (Id. at 1‐28 (“WebLogic Collaborate system
components are configured and managed primarily through the WebLogic
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐56‐
Collaborate Administration Console, which works together with a repository
service.”) (underlining added).)
The Collaborate References explain that “the repository [i]s accessible
through the WebLogic Collaborate Administration Console for system
administration, creation of collaboration agreements by business developers, and
monitoring of trading partners, conversations, collaboration agreements, and so
on.” (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 service interface” under both of the theories outlined above.
In the case in which the “service 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 “service 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 service
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐57‐
interface” under the second theory in which the service 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 or
CGI interface because they both interact with the WebLogic Collaborate
Administration Console.
Second, although the Collaborate References alone sufficiently disclose the
“managed object interface,” this interface could also be found through the
combination of the Collaborate References and Fox. As explained at length
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 one of ordinary skill in the art to adapt the
web server interface and CGI teachings of Fox to the Collaborate References, with
no change in their respective functions. (Lavian Decl., Ex. 1002, ¶¶ 135, 136.)
This would predictably have resulted in a system in which the
Administration Console interfaced with a web server interface, such as the
Common Gateway Interface (CGI) in Fox, to invoke a process for accessing the
WebLogic Collaborate repository. (Id.) Fox expressly discloses that one of the
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐58‐
purposes for which CGI is used is to “do database searches” (id. at 484), or “access
huge databases” (id. 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 therefore have been motivated to use a web server interface such as
CGI to provide an interface for the managed object, i.e. the WebLogic repository.
(Lavian Decl., ¶ 136.) Finally, the managed object interface is “associated with the
service interface” because both interfaces work together to provide management
features for the WebLogic Collaborate Administration Console.
6. Claim 23
Claim 23 depends from independent claim 22 and recites, “[t]he computer
program product of claim 22, wherein the service interface is further configured
to include information regarding at least one of the group of: [i] the last
requested message received by the service; [ii] the last fault message returned
from the service; and [iii] the execution environment for the service.” As
explained above in Part VII.A.5, the Collaborate References alone, or in
combination with Fox, disclose or suggest every limitation of claim 22.
The additional features in claim 23 requires that the service interface is
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐59‐
configured to provide information falling into at least one of the three categories
in the claim. As shown below, although the claims appear to require that only
one of these be met, the Collaborate References disclose all three.
First, the Collaborate References disclose that the service interface could
include information regarding “the last requested message received by the
service.” In particular, the Collaborate References explain that the Administration
Console includes a number of “Monitoring Pages.” (Administering Collaborate,
Ex. 1005, at 6‐3 to 6‐4 (under “WebLogic Administration Console Monitoring
Pages”).) The monitoring page for WebLogic Collaborate can display summary
statistics including the “number of messages sent and received, time of last
message sent and received . . .” (Id. at 6‐4 (Table 6‐1, “WebLogic Collaborate
(WLC) page”) (underlining added).) Because messages are part of a conversation
that initiated and carried about among trading partners, they are “requested.”
Second, the Collaborate References disclose that the service interface could
include information regarding “the last fault message returned from the service.”
For example, in the monitoring page for trading partners, the Administration
Console can display “details of a selected session,” such as “time of last sent and
received message, time of first and last failed message. . .” (Id. at 6‐4, Table 6‐1
“Trading partner page”) (underlining added).)
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐60‐
Third, the Collaborate References disclose that the service interface could
include information regarding “the execution environment for the service.” For
example, the WebLogic Collaborate (WLC) monitoring page in the Administration
Console can show execution environment information such as “[s]tatus (running
or inactive),” and “[s]hutdown options (immediate or terminate).” (Id. at 6‐4
(Table 6‐1, “WebLogic Collaborate (WLC) page”); id. at 6‐6 (Figure 6‐1).)
Therefore, claim 23 is obvious.
VIII. CONCLUSION
The Petitioner respectfully requests institution of IPR of claims 1, 22 and 23
of the ’981 patent, and a finding that those claims are unpatentable.
Dated: February 5, 2015 COOLEY LLP ATTN: Patent Group 1299 Pennsylvania Ave., NW, Suite 700 Washington, DC 20004 Tel: (650) 843‐5001 Fax: (650) 849‐7400
Respectfully submitted,
By: /Heidi L. Keefe/ Heidi L. Keefe Reg. No. 40,673 Counsel for Petitioner
ServiceNow, Inc.
Petition for Inter Partes Review of U.S. Patent No. 7,925,981
‐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 INTER PARTES REVIEW OF U.S. PATENT NO. 7,925,981, including all exhibits (Nos. 1001‐1014) and related documents, are being served via Federal Express on the 5th 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 the Patent Owner by serving the correspondence address of record with the USPTO as follows:
Hewlett‐Packard Company [for Saturday delivery] 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
DATED: FEBRUARY 5, 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
top related