Ex Parte Zhang et al

Patent Trial and Appeal Board

Jun 19, 2014

11759895 (P.T.A.B. Jun. 19, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www.uspto.gov
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
11/759,895 06/07/2007 Kai Zhang YAHOP007-Y02053US00 7068
76133 7590 06/20/2014
MPG, LLP AND YAHOO! INC.
710 LAKEWAY DRIVE
SUITE 200
SUNNYVALE, CA 94085
EXAMINER
BIAGINI, CHRISTOPHER D
ART UNIT PAPER NUMBER
2445
MAIL DATE DELIVERY MODE
06/20/2014 PAPER
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

Ex parte KAI ZHANG and LINLONG JIANG
1

________________

Appeal 2011-006649
Application 11/759,895
Technology Center 2400
________________

Before JEAN R. HOMERE, JASON V. MORGAN, and
JOHNNY A. KUMAR, Administrative Patent Judges.

MORGAN, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s Final
Rejection of claims 1–21. App. Br. 1. We have jurisdiction under 35 U.S.C.
§ 6(b). We AFFIRM.

1
Yahoo! Inc. is the Real Party in Interest. App. Br. 3.
Appeal 2011-006649
Application 11/759,895

2
Invention
Appellants invented a client notification mechanism over HTTP
(hypertext transfer protocol) where an HTTP client transmits a request to a
server over an open TCP (transmission control protocol) connection. “If
client data is not pending at the server upon receipt of the HTTP client
request at the server, the server waits for client data to become available
before sending a server response to the client, thereby maintaining an open
TCP connection.” Abstract.
Exemplary Claims
Claims 1 and 5, reproduced below with key limitations emphasized,
are representative:
1. A method for communicating between a client and a server,
comprising:
opening a transmission control protocol (TCP)
connection between a client and a server;
transmitting a hypertext transfer protocol (HTTP) client
request from the client to the server over the open TCP
connection;
determining whether client data is pending at the server
upon receipt of the HTTP client request at the server;
upon determining that client data is pending at the server,
transmitting a server response including the client data from
the server to the client over the open TCP connection, and
promptly upon receiving the server response at the client,
transmitting a new HTTP client request from the client to the
server; and
upon determining that client data is not pending at the
server, operating the server to wait for client data to become
available before sending a server response to the client so as to
maintain the open TCP connection.
Appeal 2011-006649
Application 11/759,895

3
5. A method for communicating between a client and a server
as recited in claim 1, further comprising:
operating the server to tag each server response
transmitted to the client with a server response sequence
number;
operating the client to include with each new HTTP
client request the server response sequence number tagged to
the server response most recently received by the client; and
upon receiving the new HTTP client request at the server,
operating the server to verify that the server response sequence
number included with the new HTTP client request matches the
server response sequence number tagged to the most recently
transmitted server response.

Rejections
The Examiner rejects claims 1–8, 10–15, and 17–21 under 35 U.S.C.
§ 103(a) as being unpatentable over Khodko (U.S. 2002/0035597 A1; Mar.
21, 2002) and Malkin (U.S. 6,311,206 B1; Oct. 30, 2001). Ans. 4–8.
The Examiner rejects claims 9 and 16 under 35 U.S.C. § 103(a) as
being unpatentable over Khodko, Malkin, and Douglas E. Comer and David
L. Stevens, Internetworking with TCP/IP Volume III: Client Server
Programming and Applications, Windows Sockets Version, Prentice-Hall,
Inc., Upper Saddle River, New Jersey (1997). Ans. 9–11.
ISSUES
1. Did the Examiner err in finding the combination of Khodko and
Malkin teaches or suggests: (1) “upon determining that client data is not
pending at the server, operating the server to wait for client data to become
available before sending a server response to the client so as to maintain the
open TCP connection” and (2) “promptly upon receiving the server response
Appeal 2011-006649
Application 11/759,895

4
at the client, transmitting a new HTTP client request from the client to the
server,” as recited in claim 1?
2. Did the Examiner err in finding the combination of Khodko and
Malkin teaches or suggests “operating the server to tag each server response
transmitted to the client with a server response sequence number,” as recited
in claim 5?
ANALYSIS
Claims 1–4, 7–12, and 16–20
The Examiner finds Khodko’s use of a No Message flag—sent
periodically at predefined intervals to keep a connection alive when no
message is pending—rather than a Message Pending flag teaches or suggests
“upon determining that client data is not pending at the server, operating the
server to wait for client data to become available before sending a server
response to the client so as to maintain the open TCP connection,” as recited
in claim 1. Ans. 4–5 (citing Khodko ¶¶ 18, 28, and 32). Appellants contend
the Examiner erred because:
Khodko’s operation of the server computer 12 to SEND a
predefined ‘No Message’ flag . . . represents the SENDING of a
server response . . . and does not teach or suggest operating a
server to WAIT for client data to become available BEFORE
SENDING a server response to the client, as recited in claim 1.
App. Br. 10; see also Reply Br. 5–7. In other words, Appellants interpret
“operating the server to wait . . . before sending a server response”
(emphasis added) to mean that the server waits before sending any server
response.
We do not find Appellants’ argument persuasive of error because it is
not commensurate in scope with the claimed invention. The broadest
Appeal 2011-006649
Application 11/759,895

5
reasonable interpretation, in light of the Specification, of waiting to send “a
server response” encompasses waiting until client data is available before
sending a particular server response (e.g., Khodko’s Message Pending flag).
That is, the claimed invention does not preclude the server sending other
data, such as No Message Pending flags, while waiting to send the claimed
server response.
Furthermore, even if, for the sake of argument, we were to adopt
Appellants’ interpretation of “a server response” as meaning any server
response, Appellants’ argument would not be persuasive of error. As the
Examiner correctly points out, Appellants’ argument relies on the
assumption “that a new message is not received before the two-minute time-
out period [before a No Message Pending flag is sent] is reached . . . .” Ans.
12. Yet, “if a new message is received in that time period . . . there would be
no other response other th[a]n the new data to be sent.” Id (citing Khodko
¶ 32). In other words, the Examiner correctly interprets claim 1 to
encompass waiting until either client data is available or a predefined
timeout is reached before sending data in the form of either a Message
Pending flag (if client data is available) or a No Message Pending flag (after
a predefined interval without client data available). Ans. 12. Neither the
claim recitations nor the Specification precludes this broad interpretation,
which we find to be reasonable.
For these reasons, we agree with the Examiner the combination of
Khodko and Malkin teaches or suggests “upon determining that client data is
not pending at the server, operating the server to wait for client data to
become available before sending a server response to the client so as to
maintain the open TCP connection,” as recited in claim 1. Id at 4–5.
Appeal 2011-006649
Application 11/759,895

6
The Examiner also finds Khodko’s Java applet 32, which “generates a
new HTTP request to the Web Server” when the applet receives a “message
pending” flag, teaches or suggests “transmitting a server response including
the client data from the server to the client . . . and promptly upon receiving
the server response at the client, transmitting a new HTTP client request
from the client to the server,” as recited in claim 1. Ans. 4 (citing Khodko
¶ 32). Appellants contend the Examiner erred because “the ‘Message
Pending’ flag 48 received by the client 10 of Khodko does not include the
client data from the server 12.” App. Br. 13; see also Reply Br. 10.
We do not find Appellants’ argument persuasive of error because
Appellants do not persuasively distinguish between client data and Khodko’s
Message Pending flag. By sending a Message Pending flag, Khodko’s
server 12 provides information to client 10: “Server 12 needs to send
information to the Client 10.” Khodko ¶ 18. Client 10 uses this information
by submitting an additional request—a request for the information server 10
needs to send to client 10. Id. ¶ 32. The information in the Message
Pending flag is client data because the Message Pending flag indicates that
additional information is available for the client. Therefore, we agree with
the Examiner the combination of Khodko and Malkin teaches or suggests
“promptly upon receiving the server response at the client, transmitting a
new HTTP client request from the client to the server,” as recited in claim 1.
Ans. 4.
Accordingly, we sustain the Examiner’s 35 U.S.C. § 103(a) rejection
of claim 1, and the 35 U.S.C. § 103(a) rejections of claims 2–4, 7–12, and
16–20, which Appellants do not argue separately with persuasive specificity.
App. Br. 15–16 and 18–19.
Appeal 2011-006649
Application 11/759,895

7
Claims 5, 6, 13–15, 18, and 21
The Examiner finds Malkin, either through its use of a database id or
its use of TCP, teaches or suggests “operating the server to tag each server
response transmitted to the client with a server response sequence number,”
as recited in claim 5. Ans. 6 (citing, e.g., Malkin col. 5, ll. 10–12). In
particular, the Examiner finds Malkin’s TCP packets inherently have TCP
sequence numbers, thus teaching or suggesting the use of server response
sequence numbers. Ans. 14. Appellants contend the Examiner erred in
relying on TCP sequence numbers because “[i]t is not always necessary for
TCP packets to include sequence numbers.” Reply Br. 12. However, the
Examiner’s finding accords with what an artisan of ordinary skill in the art
would recognize as being taught or suggested by TCP packets, which are
specified as including a sequence number in their header. See Information
Sciences Institute, DARPA Internet Program Protocol Specification, RFC
793 § 3.1 (Sept. 1981), available at http://www.ietf.org/rfc/rfc793.txt (the
TCP Header Format includes a “Sequence Number” field in bits 32–63).
Appellants do not present arguments or evidence distinguishing the claimed
server response sequence number from TCP packet sequence numbers
(taught or suggested by Malkin’s use of TCP). Therefore, Appellants have
not shown error in the Examiner’s finding that the combination of Khodko
and Malkin teaches or suggests “operating the server to tag each server
response transmitted to the client with a server response sequence number,”
as recited in claim 5.
Accordingly, we sustain the Examiner’s 35 U.S.C. § 103(a) rejection
of claim 5, and claims 6, 13–15, 18, and 21, which Appellants do not argue
separately with persuasive specificity. App. Br. 16–18.
Appeal 2011-006649
Application 11/759,895

8
DECISION
We affirm the Examiner’s decision rejecting claims 1–21.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 41.50(f).

AFFIRMED

ELD