Ex Parte Igarashi

Board of Patent Appeals and Interferences

Oct 19, 2009

10284118 (B.P.A.I. Oct. 19, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte NORIHIKO IGARASHI
____________

Appeal 2009-001732
Application 10/284,118
Technology Center 2100
____________

Decided: October 19, 2009
____________

Before HOWARD B. BLANKENSHIP, JOHN A. JEFFERY, and
ST. JOHN COURTENAY III, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Appellant appeals under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 5-7, and 15-27. We have jurisdiction under 35 U.S.C.
§ 6(b). We affirm.

Appeal 2009-001732
Application 10/284,118

2
STATEMENT OF THE CASE
Appellant invented a system for data exchange between terminals in a
peer-to-peer network. Specifically, a terminal management means
determines whether a data acquisition request source terminal and a request
destination terminal are in an on-line state (i.e., connected to the network).
If the request destination terminal is in an off-line state, (1) a data
acquisition request is held as a waiting request; (2) connection conditions
corresponding to the request destination terminal are acquired; and (3) the
connection conditions are sent to the request source terminal. But when the
request destination terminal is in an on-line state, the data acquisition request
is sent to the request destination terminal, and transfer of the request target
data is commenced.1 Claim 1 is illustrative with the key disputed limitation
emphasized:
1. A data acquisition system for carrying out acquisition of data
between terminals on a network, comprising:

multiple user terminals including a first user terminal which
holds data and a second user terminal which downloads the data held
by the first user terminal, wherein

a content management apparatus manages the data held by each
user terminal and comprises

a data management table holding data management
information including a data name of data held by each user
terminal, a hash function value generated for the data, and a
name of each user terminal which holds the data, and

a data management unit, when receiving a download
request from the second user terminal, acquiring a hash function

1 See generally Abstract; Spec. ¶¶ 0004-10.
Appeal 2009-001732
Application 10/284,118

3
value of target data to be downloaded from a data name
specified in the download request, based on the data
management information, extracting one or more user terminals
which hold data with a hash function value equal to the
acquired hash function value, and notifying the second user
terminal of the one or more user terminals;

a data management table indicating data held by corresponding
terminals;

terminal management means for determining whether a data
acquisition request source terminal and a request destination terminal
are in an on-line state of being connected to the network, or are in an
off-line state of not being connected to the network;

connection conditions management means for acquiring a
connection log for the request destination terminal and managing
connection conditions for each item of data of the request destination
terminal; and

data management means for, when a data acquisition request is
received from the request source terminal, extracting the terminal
holding target data of the data acquisition request as a request
destination terminal, and when the request destination terminal is in
an online state, sending the data acquisition request to the request
destination terminal and starting transfer of the request target data,
and when the request destination terminal is in an off-line state,
holding the data acquisition request as a waiting request, acquiring
connection conditions corresponding to the request destination
terminal, and sending the connection conditions to the request source
terminal.

Appeal 2009-001732
Application 10/284,118

4
The Examiner relies on the following as evidence of unpatentability:
O’Brien US 6,351,776 B1 Feb. 26, 2002

Raciborski US 6,658,000 B1 Dec. 2, 2003
(filed Sept. 18, 2000)
Cudd US 2004/0044740 A1 Mar. 4, 2004
(filed Aug. 30, 2001)

1. The Examiner rejected claims 1, 5-7, 15-25, and 27 under 35 U.S.C.
§ 103(a) as unpatentable over Raciborski and Cudd. Ans. 3-11.
2. The Examiner rejected claim 26 under 35 U.S.C. § 103(a) as
unpatentable over Raciborski, Cudd, and O’Brien. Ans. 11-12.
Rather than repeat the arguments of Appellant or the Examiner, we
refer to the Briefs and the Answer2 for their respective details. In this
decision, we have considered only those arguments actually made by
Appellant. Arguments which Appellant could have made but did not make
in the Briefs have not been considered and are deemed to be waived. See 37
C.F.R. § 41.37(c)(1)(vii).

THE OBVIOUSNESS REJECTION OVER RACIBORSKI AND CUDD
Regarding representative claim 1,3 the Examiner finds that Raciborski
discloses a data acquisition system with all the claimed subject matter except

2 Throughout this opinion, we refer to (1) the Appeal Brief filed September
27, 2007; (2) the Examiner’s Answer mailed December 7, 2007; and (3) the
Reply Brief filed February 7, 2008.
3 Appellant argues independent claims 1, 15, and 22 together as a group, but
does not separately argue the dependent claims apart from claim 25. See
App. Br. 7-9. Accordingly, we group claims 1, 5-7, 15-24, and 27 together,
and select claim 1 as representative. See 37 C.F.R. § 41.37(c)(1)(vii). We
also treat claims 25 and 26 separately.
Appeal 2009-001732
Application 10/284,118

5
for first and second user terminals that hold and download data, respectively.
The Examiner, however, cites Cudd for teaching that clients can hold cached
files downloadable by other clients. Based on this teaching, the Examiner
concludes that it would have been obvious to implement Raciborski’s origin
servers as other user terminals or clients to improve downloading speed and
reliability. Ans. 5-6.
Appellant argues that while Raciborski maintains the origin server’s
on-/off-line status, Raciborski does not check the user terminal’s on-line
connection status. App. Br. 7-8; emphases added. Appellant emphasizes
that Raciborski is limited to the origin server, and does not address the
connection status of a computer querying the origin server. Reply Br. 2.
Appellant adds that Cudd likewise fails to check the on-line connection state
of a data acquisition request source terminal. App. Br. 7-8; Reply Br. 2-3.
The Examiner, however, contends that since (1) Raciborski checks the
origin servers’ on-/off-line status, and (2) Raciborski and Cudd collectively
suggest that origin servers can be implemented as user terminals, the prior
art therefore teaches determining the on-/off-line status of the user terminals
as claimed. Ans. 13-14.
Regarding claim 25, Appellant argues that Raciborski does not teach
or suggest selecting a user terminal which has not been selected as the
requested terminal upon entering an off-line state while transferring the
downloaded data. App. Br. 8; emphasis in original. The Examiner,
however, contends that Raciborski teaches such a feature in view of its
piecemeal streaming capability. Ans. 14-15. The Examiner adds that
Raciborski also queries sources of content for their status and determines
alternative sources of content when one is unavailable. Id.
Appeal 2009-001732
Application 10/284,118

6
The issues before us, then, are as follows:

ISSUES
Under § 103, has Appellant shown that the Examiner erred by finding
that Raciborski and Cudd collectively teach or suggest:
(1) terminal management means for determining whether a data
acquisition request source terminal and request destination terminal are in an
on-line or off-line state as recited in claim 1?
(2) selecting a user terminal which has not been selected as the
requested terminal upon entering an off-line state while transferring the
downloaded data as recited in claim 25?

FINDINGS OF FACT
The record supports the following findings of fact (FF) by a
preponderance of the evidence:
Raciborski
1. Raciborski discloses a system that routes delivery of content via a
network. In one embodiment, content distribution system 100 includes
active directory 104, origin server(s) 108, client computer(s) 112, content
exchange(s) 116, and Internet 120. Raciborski, Abstract; col. 3, ll. 5-11; Fig.
1.
2. A client computer 112 interacts with the active directory 104 to
select a content object to download, and the request is forwarded to the
appropriate origin server 108 along with preference information from the
client computer. Based on various factors including the preference
information, the origin server decides from where to download the object.
Appeal 2009-001732
Application 10/284,118

7
The origin server then redirects the client computer to the preferred source
of information. Raciborski, col. 3, ll. 11-23, 55-61; col. 9, ll. 50-59; Fig. 1.
3. The preferred source of information could be (1) the origin server
itself, or (2) a content exchange 116. Raciborski, col. 3, ll. 21-23, 62-63.
4. Active directory 104 includes a server manager 208 that maintains
information on all client computers, origin servers, and content exchanges.
The information related to client computers and origin servers is maintained
in subscriber database 224. Raciborski, col. 6, ll. 19-25; Fig. 2.
5. The subscriber database 224 includes the origin server’s on-/off-
line status. Raciborski, col. 6, ll. 27-31.
6. Server database 228 maintains information on content objects for
all origin servers. To maintain current information in the server database,
server manager 208 periodically interacts with the origin server to, among
other things, determine if the origin server has gone off-line. If so, (1) the
entries in the server database 228 corresponding to that origin server are
removed, and (2) the status information in the subscriber database 224 is
updated. Raciborski, col. 6, ll. 36-51; Fig. 2.
7. Origin server 108 directs the client computer to a content exchange
116 that can efficiently deliver the desired content object. To this end, the
origin server includes a content manager 312 and a health check 330.
Raciborski, col. 8, ll. 18-30; col. 9, ll. 13-31; Fig. 3A.
8. The content manager can regulate access to content objects. When
a client computer attempts to download a content object associated with a
content manager, a login dialog can be presented. The user can then enter a
user name and/or password in the login dialog to enable redirecting the
Appeal 2009-001732
Application 10/284,118

8
client computer to a source for the content object. Raciborski, col. 9, l. 60 −
col. 10, l. 1.
9. When a client object is selected, the client computer’s preference
information 512 is communicated to the content object manager 312 which,
in turn, selects an appropriate content exchange 116 for the client computer.
Raciborski, col. 13, ll. 60-66; Fig. 4B.
10. The preference information 512 is a result of network analysis
performed from the client computer perspective and is updated periodically
(e.g., every hour) via automated tests or manually. Raciborski, col. 13, l. 60
− col. 14, l. 1.
11. Content exchanges 116 are caches for content objects. When a
requested content object or portion thereof is not found from a content
exchange, the content exchange then requests other content exchanges for
that object. While the content exchange is gathering the content object, the
client computer receives the initial portions that are available. Raciborski,
col. 4, ll. 26-39.
12. Content objects can include (1) previously-stored information, or
(2) a streaming feed of information. Raciborski, col. 3, ll. 51-52.
13. As content exchanges 116 become available or unavailable, their
operational status is reported to the server manager 208. Raciborski, col. 7,
ll. 32-35.

Cudd
14. Cudd discloses a method of downloading or uploading data via a
network including Clients A and B whose terminals hold previously-
downloaded web pages in cache. The enhanced browsers open the caches of
Appeal 2009-001732
Application 10/284,118

9
their respective client terminals for access by other network users. The
client terminals therefore act like proxy servers for faster and more reliable
downloads. Cudd, Abstract; ¶¶ 0025-27; Fig. 2.

PRINCIPLES OF LAW
In rejecting claims under 35 U.S.C. § 103, it is incumbent upon the
Examiner to establish a factual basis to support the legal conclusion of
obviousness. See In re Fine, 837 F.2d 1071, 1073 (Fed. Cir. 1988). If the
Examiner’s burden is met, the burden then shifts to the Appellant to
overcome the prima facie case with argument and/or evidence. Obviousness
is then determined on the basis of the evidence as a whole and the relative
persuasiveness of the arguments. See In re Oetiker, 977 F.2d 1443, 1445
(Fed. Cir. 1992).

ANALYSIS
Claims 1, 5-7, 15-24, and 27
Based on the record before us, we find no error in the Examiner’s
obviousness rejection of representative claim 1. Although Raciborski’s on-
/off-line status determination is described in connection with the origin
server (FF 5-6), we nonetheless see no reason why such a server could not
function as a terminal as well (or vice-versa), particularly in view of Cudd’s
teaching that client terminals can also effectively function as servers. See FF
14. Nor is there any evidence before us that would preclude the client
computers 112 in Raciborski from functioning as servers for other client
computers (e.g., origin servers) in light of Cudd’s teaching. As such, these
server/terminals would each contain functionality commensurate with
Appeal 2009-001732
Application 10/284,118

10
Raciborski’s origin servers that would, among other things, determine their
on-line and off-line status. See FF 6. We therefore find no error in the
Examiner’s position that Raciborski and Cudd collectively suggest
determining whether a data acquisition request source terminal and request
destination terminal are in an on-line or off-line state as claimed.
We further note that Raciborski’s system also effectively determines
the client computer’s on-/off-line state by virtue of its interactive content
regulation function. See FF 8. Notably, when a client computer attempts to
download a certain content object, the origin server’s content manager can
redirect the client computer to the appropriate source only upon entering the
appropriate user name and password in a login dialog. Id. Since the client
computer in Raciborski must be on-line for this interactive functionality to
occur (i.e., for the origin server to receive and process the user name and
password transmitted from the client computer), the origin server would
effectively determine the client computer’s on-line status as part of this
gatekeeping role. See id.
We reach a similar conclusion regarding the client computer’s
communicating preference information to the origin server upon selecting a
client object in Raciborski. See FF 2 and 9. Upon receiving this preference
information, the origin server then selects an appropriate content exchange
for the client computer. Id. As such, the origin server would effectively
determine the client computer’s on-line status by requiring that the client
computer transmit preference information to the origin server before it
selects the appropriate content exchange. See id. That this transmitted
preference information is updated often (e.g., every hour) (FF 10) only
bolsters our conclusion that determining the on-line status of the client
Appeal 2009-001732
Application 10/284,118

11
computer to facilitate this network-based functionality would have been
obvious to ordinarily skilled artisans.
For the foregoing reasons, Appellant has not persuaded us of error in
the Examiner’s rejection of representative claim 1.4 Therefore, we will
sustain the Examiner’s rejection of that claim, and claims 5-7, 15-24, and 27
which fall with claim 1.

Claim 25
We will also sustain the Examiner’s rejection of claim 25. As the
Examiner indicates (Ans. 14-15), Raciborski not only teaches that content
objects can be streamed (FF 12), but also that the client computer can
receive the initial portions of content that are available (FF 11). This
teaching reasonably suggests that content can be streamed to the client
computer in a piecemeal fashion as it becomes available. See FF 11-12.
Even assuming that the origin server is determined before streaming
in this scenario (see FF 2) as Appellant argues (Reply Br. 4), Raciborski
nevertheless teaches that if a requested content object or portion thereof is

4 Although Appellant presents arguments directed to (1) storing the
connection status in a connection log (Reply Br. 2); (2) acquiring a
connection log for the request destination terminal (Reply Br. 3); and (3)
acquiring a hash function value for target data (id.), these arguments were
not presented in the Appeal Brief, but were raised for the first time in the
Reply Brief. Compare App. Br. 7-8 with Reply Br. 2-3. Accordingly, these
arguments are deemed to be waived. See Optivus Tech., Inc. v. Ion Beam
Appl’ns S.A., 469 F.3d 978, 989 (Fed. Cir. 2006) (“[A]n issue not raised by
an appellant in its opening brief . . . is waived.”) (citations and quotation
marks omitted).

Appeal 2009-001732
Application 10/284,118

12
not found from a particular content exchange, it then requests other content
exchanges for that object. FF 11. Raciborski also notes that content
exchanges can become available or unavailable and, as such, their status is
reported to the server manager. FF 13.
Based on these teachings, we agree with the Examiner (Ans. 14-15)
that Raciborski at least suggests querying alternative sources of content to
complete requests for streamed content objects that have only been partially
fulfilled in the event that the primary source of content becomes unavailable
(e.g., during streaming). Although these sources of content are content
exchanges, Raciborski nonetheless indicates that either content exchanges or
origin servers can function as preferred sources of information to which
client computers are directed. FF 3; emphasis added. We therefore see no
reason why these fundamental teachings regarding content exchanges and
origin servers could not be applied to user terminals, particularly in view of
Cudd’s teaching that client terminals can also effectively function as servers
as we noted previously. See FF 14. That Raciborski teaches that content
exchanges are caches for content objects (FF 11)—a function commensurate
with Cudd’s caching function (FF 14)—only bolsters our conclusion that
Raciborski’s teachings regarding content exchanges would have been
reasonably applicable to user terminals.
For the foregoing reasons, Appellant has not persuaded us of error in
the Examiner’s rejection of claim 25. Therefore, we will sustain the
Examiner’s rejection of that claim.

Appeal 2009-001732
Application 10/284,118

13
THE OBVIOUSNESS REJECTION OVER RACIBORSKI, CUDD, AND O’BRIEN
Likewise, we will sustain the Examiner's obviousness rejection of
claim 26 over Raciborski, Cudd, and O’Brien (Ans. 11-12). Appellant has
not particularly pointed out errors in the Examiner’s reasoning to
persuasively rebut the Examiner's prima facie case of obviousness for the
particular limitations of claim 26. See App. Br. 7-8; see also Reply Br. 1-4.
Thus, we are not persuaded that the Examiner erred in rejecting claim 26 for
the reasons discussed above. The rejection is therefore sustained.

CONCLUSION
Appellant has not shown that the Examiner erred in rejecting claims 1,
5-7, and 15-27 under § 103.

ORDER
The Examiner’s decision rejecting claims 1, 5-7, and 15-27 is
affirmed.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED

msc
STAAS & HALSEY LLP
SUITE 700
1201 NEW YORK AVENUE, N.W.
WASHINGTON DC 20005