Ex Parte Mayo et al

Board of Patent Appeals and Interferences

Apr 22, 2010

10629040 (B.P.A.I. Apr. 22, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________
BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________
Ex parte ROBERT N. MAYO,
PARTHASARATHY RANGANATHAN,
ROBERT J. STETS, JR.,
and DEBORAH A. WALLACH
____________
Appeal 2009-001470
Application 10/629,0401
Technology Center 2400
____________
Decided: April 22, 2010
____________
Before LEE E. BARRETT, LANCE LEONARD BARRY, and
JAMES R. HUGHES, Administrative Patent Judges.

BARRETT, Administrative Patent Judge.

DECISION ON APPEAL
This is a decision on appeal under 35 U.S.C. § 134(a) from the final
rejection of claims 1-30. We have jurisdiction pursuant to 35 U.S.C. § 6(b).
We affirm.

1 Filed July 28, 2003, titled "Directing Client Requests in an
Information System Using Client-Side Information."
Appeal 2009-001470
Application 10/629,040

2
STATEMENT OF THE CASE
The invention
The invention relates to an information system with mechanisms for
directing incoming client requests to individual access subsystems based on
client-side information associated with the client requests. The client-side
information enables a client to direct the assignment of the client requests in
a manner that enhances overall response time in the information system
while minimizing loss of valuable cached information caused by power
reduction in the information system. The information system includes a set
of access subsystems each for use in accessing a persistent store in the
information system in response to a client request and further includes a
transaction director that assigns the client request to the access subsystems in
response to a set of client-side information associated with the client request.
Spec. 3, ll. 3-19. The access subsystems may be, for example, information
servers or hardware/software subsystems within an information server, CPU
subsystems in an information server, etc. Spec. 5, ll. 7-11.
The client-side information may be information useful in prioritizing
the client request or in determining the handling of the client request.
Spec. 5, ll. 24-29. The client-side information can be many things, such as:
information relating to the client or a user of the client (Spec. 6, ll. 3-5); an
indication of the potential frequency of client requests (Spec. 6, ll. 14-16); an
indication of the priority of the data targeted by the client request (Spec. 6,
ll. 27-29); hints on where data targeted by a client request may be stored
(Spec. 7, ll. 6-8); a cost indication (Spec. 7, ll. 15-17); computational
Appeal 2009-001470
Application 10/629,040

3
intensity associated with performing the client request (Spec. 7, ll. 24-26);
samples from sensors (Spec. 8, ll. 5-7); hardware capabilities associated with
the client (Spec. 8, ll. 11-13); an indication of the type of application in the
client that generated the client request, where "[t]he transaction director 20
may assign the client request 60 to the access subsystems 30-34 in response
to the indicated application" (Spec. 8, ll. 24-27); the location of the client
(Spec. 8, ll. 31-32); a cookie directing the handing of the request (Spec. 9,
ll. 5-14); a priority metric (Spec. 9, l. 30 to Spec. 10, l. 2), etc.

The claims
Independent claims 1 and 16 are reproduced below:
1. An information system, comprising:
a set of access subsystems each for use in accessing a persistent
store in the information system in response to a client request from a
client of the information system;
transaction director that determines which of the access
subsystems is to handle the client request in response to a set of client-
side information associated with the client request wherein the client-
side information is generated by the client.

16. A method for directing a client request in an information
system including determining which of a set of access subsystems in
the information system is to handle the client request in response to a
set of client-side information associated with the client request
wherein the client-side information is generated by a client of the
information system.

Appeal 2009-001470
Application 10/629,040

4
The references

Toga 5,987,504 Nov. 16, 1999
Freeman US 2001/0049717 A1 Dec. 6, 2001
Baumann US 2002/0099844 A1 Jul. 25, 2002
Amon US 7,110,962 B2 Sept. 19, 2006
(filed Oct. 31, 2001)

Ben Laurie and Peter Laurie, Apache: The Definitive Guide §§ 6.4,
11.5 (2d ed. 1999) ("Laurie").

W3C: HTTP Request fields, http://web.archive.org/web/
19970606013505/http://www.w3.org/Protocols/HTTP/
HTRQ_Headers.html (June 6, 1997) ("W3C.org").

The rejections
Claims 1, 2, 10, 13, 15-17, 25, 28, and 30 stand rejected under
35 U.S.C. § 102(b) as anticipated by Freeman.
Claims 3, 7, 10-12, 18, 22, and 25-27 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over Freeman and Toga.
Claims 4 and 19 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Freeman and Baumann.
Claims 5, 14, 20, and 29 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Freeman and Amon.
Claims 6 and 21 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Freeman and Laurie.
Claims 14 and 29 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Amon.
Appeal 2009-001470
Application 10/629,040

5
Claims 8, 9, 23, and 24 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Freeman and W3C.org.

ANTICIPATION
Issue
Does Freeman teach a "transaction director that determines which of
the access subsystems is to handle the client request in response to a set of
client-side information associated with the client request wherein the client-
side information is generated by the client" as recited in system claim 1 and
a corresponding limitation in method claim 16?

Principles of law
"Anticipation requires the presence in a single prior art disclosure of
all elements of a claimed invention arranged as in the claim. A prior art
disclosure that 'almost' meets that standard may render the claim invalid
under § 103; it does not 'anticipate.'" Connell v. Sears, Roebuck & Co.,
722 F.2d 1542, 1548 (Fed. Cir. 1983) (internal citations omitted).

Findings of fact
Freeman relates to communication between servers. An administrator
will often provide a user with access to a number of application servers that
host the user's application to minimize response time, maximize the system
throughput, and generally give the appearance that the user's application is
executing at the client. However, as the number of application servers
grows larger, the administrative burden becomes significant, effectively
Appeal 2009-001470
Application 10/629,040

6
limiting the size of these networks. ¶ 0003. Freeman addresses this
potential problem. ¶ 0004.
Freeman describes that a server communicates with every other server
and a server 180 attempting to find an application program requested by a
client 120 may communicate with every other server 180 in the server
farm 110 to find one or more servers hosting the application. ¶ 0115.
As shown in Figure 3, every server 180 has a service locator 354 that
identifies a server 180 for servicing events issued to other subsystems.
"[T]he term 'event' is broad enough to encompass any sort of message or
packet that includes control information (such as the identity of the source
subsystem and the destination subsystem) and payload data." ¶ 0128. The
identified server 180 can be local or remote. A source subsystem 300 may
create or issue an event for which the host of the destination subsystem is
not determined before the source subsystem issues the event. The source
subsystem issues a call to service locator 354 to either obtain the address of
the server 180 hosting the destination subsystem 300 or request that the
service locator 354 deliver an event to the destination subsystem 300 on
behalf of the source subsystem 300. ¶ 0191.
The service locator system service module 354 tracks which services
are available on which servers 180 in a zone and determines where requests
for service should be directed. ¶ 0234.
An event 700 includes an event header 710 and event data 730. The
event header 710 includes a "unique identifier (UID) 722 identifying a
source subsystem." ¶ 0252.
Appeal 2009-001470
Application 10/629,040

7
The source subsystem 300 does not deliver an event, but calls a
function of the service locator 354 which then determines the target server.
¶ 0277.
A load management subsystem (LMS) provides a load management
capability that selects which server 180 in the server farm 110 will service a
client request, i.e., which server 180 will execute an application for a
client 120. ¶ 0350. The LMS is rule-based, where a rule is one or more
criteria that influences how a LMS will direct inquiries. ¶ 0351. Examples
of conditional rules that may be used to determine to which server 180 to
direct a request include: whether the number of clients 120 that may connect
to a server 180 is limited; the number of application licenses available to a
server 180; whether a client is physically proximate to a server; etc. ¶ 0356.

Analysis
The limitation at issue is a "transaction director that determines which
of the access subsystems is to handle the client request in response to a set of
client-side information associated with the client request wherein the client-
side information is generated by the client" in system claim 1 and a
corresponding limitation in method claim 16. The client-side information
does not select a particular access subsystem, but is used by the transaction
director to determine which access subsystem is to handle the client request.
Any information generated by the client, which is used to assign a client
request to an access subsystem will meet the claim limitation; the types of
information are summarized in the description of the invention, supra.
Appeal 2009-001470
Application 10/629,040

8
The Examiner finds that Freeman meets the limitations in two ways.

1.
First, the Examiner finds that "Freeman et al.'s source subsystem
corresponds to said client, destination subsystem corresponds to said access
subsystem, and service locator corresponding to said transaction director
(Figs. 7B and 8A, [0255-0260, 0275-0277])." Final Office Action 2.
Appellants interpret that the Examiner finds the unique identifier
(UID) 722 to be the "client-side information." Br. 7. Appellants argue that
UID 722 is not information generated by the client 120. It is argued that
source subsystem UID 722 is information generated by a subsystem inside a
server 180 in the server farm 110, and "[c]learly, events passed between
subsystems inside a server as taught by Freeman do not anticipate a set of
client-side information generated by a client in a client request as claimed in
claims 1 and 16." Id.
The Examiner finds that Freeman describes that the source subsystem
may be on a different server than the destination subsystem and "[t]hus, . . .
the source subsystem does indeed serve as the client, and the UID, generated
at said source subsystem, serves as client-side information." Ans. 11.
Appellants reply that "even if one were to accept the examiner's
characterization of a subsystem of a server as a client of another subsystem
of the server, the UID 722 is still not information generated by a client of an
information system as claimed in claims 1 and 16." (Footnote omitted.)
Reply Br. 2
Appeal 2009-001470
Application 10/629,040

9
It is always difficult to address a rejection which relies on a broad and
unusual claim interpretation rather than the ordinary and conventional
meanings of the words. One problem is determining whether the
interpretation is "reasonable." Another problem is determining whether the
reference can be fairly said to enable one of ordinary skill in the art to make
the claimed invention, as required of an anticipatory reference, since the
rejection is based on a claim interpretation which is not apparent on its face.
In this case, the Examiner reads the claimed "client" not on the client 120 in
Figure 1 of Freeman, but on a source subsystem of a server as the "client" of
a destination server. The final rejection does not explain what information
corresponds to the claimed "client-side information," but merely points to
several paragraphs in Freeman. This is not helpful. In the response to
Appellants' interpretation that the Examiner must be referring to UID 722,
the Examiner states that "the UID, generated at said source subsystem,
serves as client-side information." Ans. 11. However, the Examiner does
not explain how the UID 722 is used by the service locator (said to
correspond to the transaction director) to determine which access subsystem
is to handle the client request. The fact that the UID 722 indicates the
source server does not establish the other characteristics of the client-side
information. Thus, the Examiner has not established that the UID 722 is
"client-side information" in this rationale.

Appeal 2009-001470
Application 10/629,040

10
2.
Second, the Examiner asserts a new rationale in the Examiner's
Answer that the client 120 makes a request for execution of an application
and "[b]ased on this request, which is generated by said client and thus
contains client-side information, the receiving server (which in this
embodiment represents said transaction director) searches for an access
subsystem (in this case, the access subsystem is also a server) that hosts the
application requested by the client, and routes the client request to that
access subsystem/server ([0115, 0195, 0196])." Ans. 4.
Appellants reply that "the examiner's argument that Freeman routes a
client request to a server in the server farm 110 based on which application
is specified in the client request rests on the false assumption that there is no
overlap in the applications that are hosted by different servers in the server
farm 110." Reply Br. 2. It is argued that Freeman teaches that the same
application is hosted by multiple servers in the server farm 110 (¶¶ 0003 &
0351) and that a server in the server farm 110 is selected to execute an
application in response to overall server and network load so as to minimize
the response time to a client request (¶ 0351, ll. 7-10). Id. "If multiple
servers in the server farm host a particular application then there would be
no way to select which server is to handle a client request for that particular
application based upon the name of the application as argued by the
examiner." Id. at n.4. Finally, it is noted that paragraphs 0351-0364 of
Freeman describe rules for managing server and network load and "none of
Appeal 2009-001470
Application 10/629,040

11
the rules take into account information generated by the client 120 as
claimed in claims 1 and 16." Id. at 3.
In view of the breadth of the claims and the description of client-side
information, we affirm the Examiner's rejection. Appellants' arguments
about multiple servers hosting a particular application are not commensurate
in scope with the claims. The claims recite that a transaction director
determines which access system is to handle the client requires, which does
not preclude the transaction director selecting an access system from among
several access systems which could handle the client request. The client
request does not have to correspond to a unique access system.
Consider, for example, the case where a client submits a request for a
particular application program, a type of client-side information. The
system will locate one or more servers hosting the requested application
(¶¶ 0115, 0350) and therefore "determines which of the access subsystems is
to handle the client request" as claimed. This is consistent with the
Specification which describes that the client-side information can be the type
of application:

The client-side information 62 may include an indication of the type
of application in the client 10 that generated the client request 60. The
transaction director 20 may assign the client request 60 to the access
subsystems 30-34 in response to the indicated application. For
example, the access subsystems 30-34 may be individually allocated
for handling particular types of applications.

Spec. 8, ll. 22-29. Again, the claims do not preclude more than one access
subsystem handling the same application.
Appeal 2009-001470
Application 10/629,040

12
Conclusion
Freeman teaches a "transaction director that determines which of the
access subsystems is to handle the client request in response to a set of
client-side information associated with the client request wherein the client-
side information is generated by the client" as recited in system claim 1 and
a corresponding limitation in method claim 16. The rejection of claims 1, 2,
10, 13, 15-17, 25, 28, and 30 under 35 U.S.C. § 102(b) is affirmed.

OBVIOUSNESS
Appellants argue that the references applied to the rejections of the
dependent claims in the obviousness rejections do not cure the deficiencies
of Freeman as recited in the independent claims. Br. 8-12. Appellants do
not argue the separate patentability of the dependent claims. Thus, the
rejections of the claims under 35 U.S.C. § 103(a) stand with the rejection of
the independent claims. Accordingly, the rejections of claims 3-12, 14,
18-27, and 29 under 35 U.S.C. § 103(a) are affirmed.

Appeal 2009-001470
Application 10/629,040

13
CONCLUSION
The rejection of claims 1, 2, 10, 13, 15-17, 25, 28, and 30 under
35 U.S.C. § 102(b) is affirmed.
The rejections of claims 3-12, 14, 18-27, and 29 under 35 U.S.C.
§ 103(a) are affirmed.
Requests for extensions of time are governed by 37 C.F.R. § 1.136(b).
See 37 C.F.R. § 41.50(f).

AFFIRMED

erc

HEWLETT-PACKARD COMPANY
Intellectual Property Administration
3404 E. Harmony Road
Mail Stop 35
FORT COLLINS, CO 80528