Ex Parte 6907530 et al

Patent Trial and Appeal Board

Dec 10, 2012

95001447 (P.T.A.B. Dec. 10, 2012)

UNITED STATES PATENT AND TRADEMARKOFFICE
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.
95/001,447 10/04/2010 6907530 SSL-RE-1 8793
24998 7590 12/10/2012
DICKSTEIN SHAPIRO LLP
1825 EYE STREET NW
Washington, DC 20006-5403
EXAMINER
HENEGHAN, MATTHEW E
ART UNIT PAPER NUMBER
3992
MAIL DATE DELIVERY MODE
12/10/2012 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
____________________

CITRIX SYSTEMS, INC.
Requester

v.

SSL SERVICES, LLC
Patent Owner and Appellant
____________________

Appeal 2012-009951
Inter Partes Reexamination Control No. 95/001,447
Patent 6,907,530 B2
Technology Center 3900
____________________

Before HOWARD B. BLANKENSHIP, JUSTIN T. ARBES, and
BRIAN J. McNAMARA, Administrative Patent Judges.

ARBES, Administrative Patent Judge.

Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

2

DECISION ON APPEAL
Patent Owner SSL Services, LLC appeals under 35 U.S.C. § 134(b)
(2002) from the final decision of the Examiner adverse to the patentability of
claims 1-17. We have jurisdiction under 35 U.S.C. § 315(a) (2002).1
We affirm-in-part.

STATEMENT OF THE CASE
Invention
Patent 6,907,530 B2 (the “‘530 Patent”), which is the subject of the
current inter partes reexamination, issued on June 14, 2005 based on
Application 09/764,459, filed January 19, 2001. The ‘530 Patent does not
claim priority to any earlier applications and does not have any continuation
or divisional applications.
The ‘530 Patent relates to “establishing secured communications
pathways over an unsecured open network, and in particular to a system and
method for using mobile code to secure data transfers between an
application running on a remote server and a client connected to the remote
server via the Internet” (col. 1, ll. 7-12).

1 Our decision will make reference to Patent Owner’s Appeal Brief (“App.
Br.,” filed January 30, 2012) and Rebuttal Brief (“Reb. Br.,” filed May 21,
2012), and the Examiner’s Answer (“Ans.,” mailed April 20, 2012) and
Right of Appeal Notice (“RAN,” mailed October 11, 2011). Third Party
Requester Citrix Systems, Inc. has not filed any papers in this appeal.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

3

Claims
Claims 1-6 have not been amended from the original patent, while
claims 7-17 are newly presented in this reexamination. Claim 1 is
exemplary of the claims on appeal:
1. A system for establishing secured communications
pathways across an open unsecured network using mobile code,
comprising:
an authentication server;
at least one application server arranged to be connected
to the authentication server by a secured pathway; and
at least one platform-independent mobile code
authentication and encryption program,
wherein said authentication server is arranged to supply
said platform-independent mobile code authentication and
encryption program to a user’s computing device upon
authentication of the user,
wherein said platform-independent mobile code
authentication and encryption program is arranged to
authenticate itself to the authentication server to establish a
secure communications pathway without requiring pre-
installation of authentication and encryption client software on
the user’s computing device, and
wherein said platform-independent mobile code
authentication and encryption program is arranged to the
transmit data from the user's computing device to an application
server by encrypting the data and transmitting the data to the
authentication server for forwarding to the application server,
and by decrypting data originating from the application server
and transmitted via the authentication server.
Claims App’x, App. Br. 21.

Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

4

Prior Art
The prior art cited by the Examiner in rejecting the claims on appeal
is:
1. Admitted prior art in the ‘530 Patent (“APA”);
2. Patent 5,602,918, issued Feb. 11, 1997 (“Chen”);
3. Patent 6,901,518 B1, filed Apr. 6, 2000 and issued May 31,
2005 (“Scheifler”);
4. iPlanet Portal Server 3.0 Administration Guide, Sun
Microsystems, Inc., May 2000 (“i-Planet Administration
Guide”);
5. Alan O. Freier et al., “The SSL Protocol: Version 3.0,”
March 1996 (“SSL 3.0 Document”); and
6. i-Planet Software Architecture, Sun Microsystems, Inc.,
1999 (“i-Planet White Paper”).

Patent Owner’s Contentions
Patent Owner contends that the Examiner erred in entering the
following grounds of rejection of claims 1-17:
1. Claims 1-7, 10, 11, and 14-17 under 35 U.S.C. § 103(a) as being
unpatentable over APA in view of Scheifler;
2. Claims 1-5, 7, 10, 11, 14, and 15 under 35 U.S.C. § 103(a) as being
unpatentable over the i-Planet Administration Guide in view of Scheifler;
3. Claim 6 under 35 U.S.C. § 103(a) as being unpatentable over the
i-Planet Administration Guide in view of Scheifler and the SSL 3.0
Document;
4. Claim 6 under 35 U.S.C. § 103(a) as being unpatentable over the
i-Planet Administration Guide in view of Scheifler and Chen;
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

5

5. Claims 16 and 17 under 35 U.S.C. § 103(a) as being unpatentable
over the i-Planet Administration Guide in view of Scheifler and APA;
6. Claims 1-5, 7, 10, 11, 14, and 15 under 35 U.S.C. § 103(a) as being
unpatentable over the i-Planet White Paper in view of Scheifler;
7. Claim 6 under 35 U.S.C. § 103(a) as being unpatentable over the
i-Planet White Paper in view of Scheifler and the SSL 3.0 Document;
8. Claim 6 under 35 U.S.C. § 103(a) as being unpatentable over the
i-Planet White Paper in view of Scheifler and Chen;
9. Claims 16 and 17 under 35 U.S.C. § 103(a) as being unpatentable
over the i-Planet White Paper in view of Scheifler and APA;
10. Claims 8, 9, 12, and 13 under 35 U.S.C. § 112, first paragraph, as
failing to comply with the written description requirement; and
11. Claims 11-13 under 35 U.S.C. § 112, second paragraph, as being
indefinite for failing to particularly point out and distinctly claim the subject
matter which the applicant regards as the invention. See App. Br. 8; Ans. 4-
13; RAN 3-16.

PRINCIPLES OF LAW
Claim Interpretation
“During reexamination, as with original examination, the PTO must
give claims their broadest reasonable construction consistent with the
specification. . . . Therefore, we look to the specification to see if it provides
a definition for claim terms, but otherwise apply a broad interpretation.” In
re ICON Health and Fitness, Inc., 496 F.3d 1374, 1379 (Fed. Cir. 2007).
We must be careful not to read a particular embodiment appearing in the
written description into the claim if the claim language is broader than the
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

6

embodiment. See In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993)
(“[L]imitations are not to be read into the claims from the specification.”).
“Although an inventor is indeed free to define the specific terms used
to describe his or her invention, this must be done with reasonable clarity,
deliberateness, and precision. ‘Where an inventor chooses to be his own
lexicographer and to give terms uncommon meanings, he must set out his
uncommon definition in some manner within the patent disclosure’ so as to
give one of ordinary skill in the art notice of the change.” In re Paulsen, 30
F.3d 1475, 1480 (Fed. Cir. 1994) (citation omitted).

Written Description
The written description requirement of 35 U.S.C. § 112, first
paragraph, requires that “the disclosure of the application relied upon
reasonably convey[] to those skilled in the art that the inventor had
possession of the claimed subject matter as of the filing date.” Ariad
Pharm., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010). One
shows “possession” by descriptive means such as words, structures, figures,
diagrams, and formulas that fully set forth the claimed invention. Lockwood
v. American Airlines, Inc., 107 F.3d 1565, 1572 (Fed. Cir. 1997). It is not
sufficient for purposes of the written description requirement that the
disclosure, when combined with the knowledge in the art, would lead one to
speculate as to modifications that the inventor might have envisioned, but
failed to disclose. Id. “[T]he hallmark of written description is disclosure.
. . . [T]he test requires an objective inquiry into the four corners of the
specification from the perspective of a person of ordinary skill in the art.”
Ariad, 598 F.3d at 1351. Also, the invention claimed does not have to be
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

7

described in ipsis verbis to satisfy the written description requirement.
Union Oil Co. of California v. Atlantic Richfield Co., 208 F.3d 989, 1000
(Fed. Cir. 2000). Whether a specification complies with the written
description requirement is a question of fact. Ariad, 598 F.3d at 1351.

Definiteness
The test for definiteness under 35 U.S.C. § 112, second paragraph, is
whether “those skilled in the art would understand what is claimed when the
claim is read in light of the specification.” Orthokinetics, Inc. v. Safety
Travel Chairs, Inc., 806 F.2d 1565, 1576 (Fed. Cir. 1986) (citations
omitted). Because it is based on claim interpretation, indefiniteness is a
question of law. Biomedino, LLC v. Waters Techs. Corp., 490 F.3d 946, 949
(Fed. Cir. 2007).

ANALYSIS
I. Rejections of Claims 1-7, 10, 11, and 14-17 Under 35 U.S.C. § 103
Patent Owner’s sole challenge to the prior art rejections of claims 1-7,
10, 11, and 14-17 relates to the “authenticate itself” limitation of
independent claims 1 and 4.2 App. Br. 9-16. We select claim 1 as
representative, as Patent Owner argues claims 1 and 4 together and primarily
addresses the language of claim 1. See App. Br. 9-12; 37 C.F.R. §

2 While Patent Owner’s Appeal Brief includes separate headings for a
number of the dependent claims, Patent Owner does not separately argue the
patentability of these claims, instead referring to the arguments made with
respect to the independent claims. See App. Br. 13-16.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

8

41.67(c)(1)(vii).
Claim 1 recites a platform-independent mobile code authentication
and encryption program that is arranged to “authenticate itself to the
authentication server.” In each of the adopted prior art rejections of claim 1,
the Examiner finds that a primary prior art reference (APA, the i-Planet
Administration Guide, or the i-Planet White Paper) teaches all of the
features of the claim other than the “authenticate itself” limitation, and relies
on Scheifler as teaching that limitation. See Ans. 4-8 (citing Exs. N, O, and
S of the Replacement Request for Inter Partes Reexamination filed Oct. 4,
2010 (“Reexam Req.”)). Thus, the issue is whether Scheifler teaches a
platform-independent mobile code authentication and encryption program
arranged to “authenticate itself to the authentication server.”
Patent Owner acknowledges that Scheifler teaches “authentication of
code generally,” but argues that the downloaded code in Scheifler does not
authenticate itself to an authentication server. App. Br. 10-12. Specifically,
according to Patent Owner, the client device in Scheifler verifies locally,
using software on the client device, that downloaded code complies with a
set of necessary security constraints. Id.; Scheifler, Fig. 3 (step 306 of
“Client Verifies P2”), col. 4, ll. 43-45 (“the client uses local, trusted code to
establish trust in a downloaded proxy”). Patent Owner further contends that
“there is no communication with the server” as part of the authentication
process in Scheifler. App. Br. 11-12. Thus, because it is the client device
that authenticates the downloaded code locally, without communicating
authentication information to an authentication server, the downloaded code
does not “authenticate itself to the authentication server” as required by
claim 1. Id. 10-12.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

9

The Examiner cites the authentication process shown in Figure 3 of
Scheifler where a downloaded “mobile code program (proxy) can
authenticate itself to an authentication server so that it is deemed to be
‘trustworthy.’” See, e.g., Reexam Req. 60-61, Ex. N at 2, 7; Ans. 5
(incorporating Ex. N and adopting the proposed rejection based on APA and
Scheifler “for essentially the same reasons as given in the Request”). The
Examiner further finds:
[T]he process in Scheifler ‘518 specifies that the downloaded
code, P1, downloads an additional module, P2, for
authentication. Since P2, as part of its procedure, authenticates
P1 to the authentication server, it is thus the case that P1
authenticates itself to the server by invoking P2. The fact that
P2 is executed locally at the client is irrelevant. The two
modules together constitute the mobile code, and that code is
authenticating itself to the server (“the client then uses P2 to ask
the service if the service trusts P1’s code,” thus asking the
service to authenticate the code, see column 4, lines 39-40;
“The verifyActivatorTrust method will return normally if the
service trusts the activation 10 passed to it (step 420),” see
column 7, lines 47-56).
Ans. 13 (emphasis added).
We begin by interpreting the language of the claim. Patent Owner
argues that “authenticate itself to the authentication server” requires
communicating certain authentication information to the server, while the
Examiner concludes that the phrase at least encompasses a proxy
arrangement such as that disclosed in Scheifler. See App. Br. 11-12; Reb.
Br. 3-4; Ans. 13. Claim 1 does not recite communicating any authentication
information to the authentication server; it only specifies that the program
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

10

“authenticate[s] itself” to the server.3 Further, Patent Owner does not point
to, and we do not find, any specific definition of the phrase in the
Specification of the ‘530 Patent. Rather, the patent indicates that in a
“preferred embodiment,” an authentication and encryption client
authenticates itself to the authentication server “using” additional
authentication information. ‘530 Patent, col. 5, ll. 31-39, 58-60. Thus,
applying the broadest reasonable interpretation of the claim, as we must, see
ICON Health, 496 F.3d at 1379, we agree with the Examiner that the claim
encompasses a program authenticating itself to an authentication server via a
proxy for the server, and does not require communicating authentication
information directly to the server.
Based on this interpretation and the record before us, the
preponderance of the evidence supports the Examiner’s finding that
Scheifler teaches a platform-independent mobile code authentication and
encryption program arranged to “authenticate itself to the authentication
server.” Like the ‘530 Patent, Scheifler is directed to “using downloaded
code to provide secure communication between a client and a remote
service.” Scheifler, col. 1, ll. 13-16. In the exemplary method depicted in
Figure 3, the client device downloads a proxy P1 and then obtains a second
proxy P2 from the first proxy P1 by invoking a method on P1 (steps 302 and

3 Notably, newly added claim 7, which depends from claim 1 and is not
separately argued by Patent Owner, recites that the platform-independent
mobile code authentication and encryption program “includes mobile code
authentication information” and “authenticates itself by sharing the mobile
code authentication information with the authentication server.”
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

11

304). Id., col. 2, ll. 10-14; col. 4, ll. 30-34. Next, the client device verifies
that P2 is trusted (step 306), and uses P2 to authenticate the requested
service (step 308). Id., col. 4, ll. 34-38. The client device then “uses P2 to
ask the service if the service trusts P1’s code.” Id., col. 4, ll. 38-42. It does
so by invoking P2 to obtain a proxy verifier from the service, and passing P1
to the proxy verifier (step 310). Id., col. 2, ll. 19-23; col. 4, ll. 38-42. If P1
is verified by the proxy verifier, P1 is trusted (step 312). Id., col. 4, ll. 38-
45.
As the Examiner found, downloaded proxy P1 authenticates itself to
the server by invoking P2, which communicates with the server to obtain a
proxy verifier and verify P1. See Ans. 5, 13. While P1 authenticating itself
to the server is achieved indirectly (via proxy P2 asking the service for a
proxy verifier and sharing information with the proxy verifier) rather than
directly (e.g., by sharing information directly with the server), we see
nothing in the broad language of the claim prohibiting that type of proxy
arrangement given its broadest reasonable interpretation.
We also note that Patent Owner argues for the first time in its Rebuttal
Brief that the Examiner improperly interpreted the claim limitation of the
platform-independent mobile code authentication and encryption program
being arranged to authenticate itself “without requiring pre-installation of
authentication and encryption client software on the user’s computing
device.” See Reb. Br. 4-6. Specifically, the Examiner interpreted the phrase
as encompassing a computing device that has Java “standard utilities” pre-
installed:
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

12

[T]he specification of ‘530 patent repeatedly uses Java applets
to implement the invention’s functionalities. Such an
embodiment requires the use of the Java platform, which
implicitly involves the installation of the Java platform’s
various standard utilities. Therefore, it would be reasonable to
apprise the scope of the limitation as not applying to such
standard utilities, which includes the Java RMI Security
subsystem [disclosed in Scheifler].
Ans. 14.
Notwithstanding the late presentation of Patent Owner’s argument, we
disagree for two reasons. First, Patent Owner does not address the
Examiner’s factual findings that the cited prior art references teach all of the
limitations of claim 1, including the “pre-installation” limitation, or explain
why the Examiner is incorrect in those findings. See, e.g., Reexam Req. 60-
61, Ex. N at 2 (“the ‘530 patent admits that a java applet can be downloaded
to the web browser on a user’s device (i.e., with no pre-installation),” and
Scheifler “also teaches that the executable [proxy] content may be
downloaded, and hence does not need to be pre-installed”).
Second, the Examiner’s interpretation is reasonable in light of the
Specification of the ‘530 Patent, which repeatedly refers to a “Java applet”
as an exemplary embodiment of the downloaded code. See, e.g., ‘530
Patent, col. 5, ll. 22-28 (the downloaded code can be “a Java applet that can
be executed via the user’s browser software”), claim 2. Patent Owner does
not dispute that the Java platform’s various standard utilities may be pre-
installed on a user’s computing device so that the user’s browser can execute
Java applets (of any type, not just applets relating to authentication and
encryption). We also see no indication in the patent that such standard
utilities would be downloaded along with the disclosed Java applet itself.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

13

See id., col. 5, ll. 22-28. Thus, the claim limitation of the program being
arranged to authenticate itself “without requiring pre-installation of
authentication and encryption client software on the user’s computing
device,” given its broadest reasonable interpretation, encompasses the
situation where a computing device has Java standard utilities pre-installed.
Further, Patent Owner argues that “[n]othing in the specification
requires that Java utility code be pre-installed just because an exemplary
embodiment” of the program is a Java applet. Reb. Br. 5 (emphasis
omitted). The question, however, is not whether the claimed device is
required to have pre-installed Java standard utilities in light of the
Specification of the ‘530 Patent, but rather whether the device recited in the
claim, given its broadest reasonable interpretation in light of the
Specification, may have Java standard utilities pre-installed. We conclude
that it may.
In view of the evidence supporting the Examiner’s rejection and
Patent Owner’s arguments to the contrary, we are not persuaded that claims
1-7, 10, 11, and 14-17 have been rejected in error. We therefore sustain the
rejections under 35 U.S.C. § 103.

II. Rejection of Claims 8, 9, 12, and 13 Under
35 U.S.C. § 112, First Paragraph
Claims 8 and 12
Newly added claims 8 and 12 recite mobile code authentication
information that is shared with an authentication server where the mobile
code authentication information “is an encryption key.” The Examiner finds
the claims unsupported by the Specification of the ‘530 Patent because the
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

14

patent “does not suggest that an encryption key is shared in the
authentication, but merely that it is used in the process.” Ans. 12. The
Examiner further finds that the patent does not describe an embodiment
where the “only” mobile code authentication information shared with the
authentication server is the encryption key, as allegedly required by the
phrase “is an encryption key.” Ans. 14-16. According to the Examiner, a
system authenticating itself by sending an encryption key alone is “not
common in the art” and would be “useless since an eavesdropper could
simply take the secret key and re-use it to mimic the sender.” Ans. 15.
Patent Owner contends that the claims are supported by step 5 of the method
described in the ‘530 Patent. App. Br. 17; Reb. Br. 6.
We are persuaded of error in the rejection of claims 8 and 12 as
lacking sufficient written description. As to the Examiner’s first finding that
the ‘530 Patent does not describe an embodiment with an encryption key
being shared, the patent discloses “additional authentication and/or
encryption information, such as encryption keys and algorithms,” and that
“the authentication and encryption client authenticates itself to the gateway
or authentication server using the additional authentication information (step
5).” ‘530 Patent, col. 5, ll. 31-39. Figure 3, reproduced below, shows an
arrow going from the user’s computing device to the authentication server,
demonstrating that information is communicated from the former to the
latter as part of step 5 in the exemplary method:
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

15

Thus, the ‘530 Patent sufficiently describes the sharing of mobile code
authentication information from a user’s computing device to an
authentication server,4 and that an encryption key is one example of such
information.
As to the Examiner’s second finding that the ‘530 Patent does not
support an encryption key as the “only” mobile code authentication
information shared with the authentication server, we disagree that this
feature is a requirement of the claims. The patent discloses “additional
authentication and/or encryption information, such as encryption keys and
algorithms,” indicating that the information may be a single piece of data
(e.g., one of the examples, such as an encryption key). See ‘530 Patent, col.

4 While we find that the ‘530 Patent sufficiently describes an exemplary
embodiment where mobile code authentication information is shared with
the authentication server, such sharing is not required by the broad language
of the independent claims, for the reasons explained above.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

16

5, ll. 29-31 (emphasis added). Moreover, as Patent Owner points out, parent
claims 7 and 11 specify that the downloaded program or code “includes”
mobile code authentication information. See Reb. Br. 6. Thus, there is
nothing preventing the claimed system and method from using/sharing
additional mobile code authentication information; the claims only require
that the particular piece of mobile code authentication information being
shared so that the program can authenticate itself be an encryption key. See
Mars, Inc. v. H.J. Heinz Co., 377 F.3d 1369, 1376 (Fed. Cir. 2004)
(transitional, open-ended terms “comprising” and “including” are
synonymous).
The ‘530 Patent reasonably conveys to those skilled in the art that the
inventor had possession of the claimed subject matter, including shared
mobile code authentication information that “is an encryption key.”
Accordingly, we do not sustain the rejection of claims 8 and 12 as lacking
sufficient written description under 35 U.S.C. § 112, first paragraph.

Claims 9 and 13
Newly added claims 9 and 13 recite mobile code authentication
information that is shared with an authentication server where the mobile
code authentication information “is different from and does not include
authentication information associated with the user.” The Examiner finds
this limitation unsupported by the Specification of the ‘530 Patent because
“the only types of authentication information that are explicitly disclosed in
the patent are all types that are associated with the user.” Ans. 12, 16. The
Examiner also finds that while the patent discloses “additional authentication
information, such as encryption keys and algorithms” (col. 5, ll. 29-31),
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

17

“such data is inherent in the internal functioning of client authentication
software and there is nothing in the specification to suggest that this
additional data is being shared with the server.” Ans. 12, 16-17. Patent
Owner argues that the limitation is supported by two distinct instances of
authentication information disclosed in column 5 of the patent. App. Br. 18;
Reb. Br. 7-9.
We are persuaded of error in the rejection of claims 9 and 13 as
lacking sufficient written description. The ‘530 Patent discloses two
instances of authentication information in the context of two separate steps
of the exemplary method. In step 2 (shown in Figure 2), the authentication
server downloads a web page to the user’s computing device requesting the
entry of “user authentication information.” ‘530 Patent, col. 4, l. 67-col. 5, l.
2. The user authentication information may be, for example, “a password,
securID, data from a biometrics scanner, or any other identifying
information.” Id., col. 5, ll. 3-7. Later, in step 5 (shown in Figure 3), the
authentication and encryption client downloaded to the user’s computing
device authenticates itself to the authentication server using “additional
authentication and/or encryption information” included in the downloaded
mobile code. Id., col. 5, ll. 29-39. The additional information may be, for
example, “encryption keys and algorithms.” Id., col. 5, ll. 29-31.
Importantly, the authentication in step 5 takes place after the user is
authenticated via the user authentication information and the mobile code is
downloaded to the user’s computing device. Id., col. 5, ll. 15-20, 29-39.
There is no indication in the ‘530 Patent that the downloaded mobile code,
which includes the “additional authentication and/or encryption information”
used to authenticate the client, includes information that was previously used
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

18

to authenticate the user. In addition, the examples given for both types of
authentication information are different – a password, securID, or biometric
data, which are associated with a user, for the “user authentication
information,” and encryption keys and algorithms, which are not associated
with a user, for the “additional authentication and/or encryption
information.” The ‘530 Patent therefore sufficiently describes mobile code
authentication information that “is different from and does not include
authentication information associated with the user.”
Further, even assuming (without deciding) that the Examiner is
correct that the “additional authentication and/or encryption information”
used in step 5 is “inherent” in all client authentication software (Ans. 16-17),
it does not follow that the claims lack written description support. As
explained above, the ‘530 Patent describes with sufficient words and figures
two different instances of authentication information used for two different
purposes in two different steps – “user authentication information” and
“additional authentication and/or encryption information.” The fact that the
latter type may be present in all client authentication software does not mean
that the ‘530 Patent does not describe it.
The ‘530 Patent reasonably conveys to those skilled in the art that the
inventor had possession of the claimed subject matter, including shared
mobile code authentication information that “is different from and does not
include authentication information associated with the user.” Accordingly,
we do not sustain the rejection of claims 9 and 13 as lacking sufficient
written description under 35 U.S.C. § 112, first paragraph.

Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

19

III. Rejection of Claims 11-13 Under 35 U.S.C. § 112, Second Paragraph
Independent claim 4 recites a “method of establishing secured
communications pathways across an open unsecured network using mobile
code, comprising . . . downloading mobile code including an authentication
and encryption client from the authentication server to the user’s computing
device [and] causing the authentication and encryption client to authenticate
itself to the authentication server.” Newly added dependent claim 11 recites
that “the platform-independent mobile code authentication and encryption
program authenticates itself by sharing the mobile code authentication
information with the authentication server.” The Examiner concludes that
claim 11, and claims 12 and 13 dependent therefrom, are indefinite as
lacking antecedent basis for “the platform-independent mobile code
authentication and encryption program.” Ans. 12-13, 17.
Patent Owner acknowledges that the phrase “platform-independent
mobile code authentication and encryption program” does not appear in
parent claim 4, and that “the claim wording could be improved by replacing
the claim 11 ‘platform-independent mobile code authentication and
encryption program’ with ‘the authentication and encryption client’
language of claim 4.” App. Br. 19. Nevertheless, Patent Owner argues that
a person of ordinary skill in the art would understand what is claimed given
the context of both phrases in the claims and how “program” and “client” are
used in the ‘530 Patent. App. Br. 19; Reb. Br. 9.
Given the substantial difference in language between the claims, we
disagree with Patent Owner that a person of ordinary skill would
automatically equate “the platform-independent mobile code authentication
and encryption program” of claim 11 with the “authentication and
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

20

encryption client” of parent claim 4. Claim 11 recites a “program”; claim 4
recites mobile code including a “client.” See Ans. 17. Claim 11 recites a
“platform-independent” program; claim 4 does not recite any platform. See
id. The Specification of the ‘530 Patent also does not support Patent
Owner’s contention that one of ordinary skill would automatically equate the
recited “program” and “client.” The patent discloses that downloaded
mobile code “may be in the form of” a platform-independent program, but
refers to the downloaded mobile code as merely “including” an
authentication and encryption client. ‘530 Patent, col. 5, ll. 15-28. Thus, in
at least some embodiments the mobile code and program may be one and the
same, but the client is only “includ[ed]” in the mobile code (i.e., the
“program” and “client” may be different).
A person of ordinary skill would not understand “the platform-
independent mobile code authentication and encryption program” in claim
11 to refer to the “authentication and encryption client” in claim 4, and
therefore would not understand what is recited in claim 11 when the claim is
read in light of the Specification of the ‘530 Patent. Accordingly, we sustain
the rejection of claims 11-13 as indefinite under 35 U.S.C. § 112, second
paragraph.5

5 The Examiner also determined claims 11-13 to be indefinite based on the
fact that “mobile code” is recited twice in claim 4 and it is unclear to which
instance the “mobile code” in claim 11 refers. Ans. 17. Because we agree
with the Examiner that the entire phrase “the platform-independent mobile
code authentication and encryption program” in claim 11 lacks antecedent
basis and is indefinite, we need not reach this additional basis for rejection.
Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

21

CONCLUSION
We sustain the rejections of claims 1-7, 10, 11, and 14-17 under 35
U.S.C. § 103; do not sustain the rejection of claims 8, 9, 12, and 13 under 35
U.S.C. § 112, first paragraph; and sustain the rejection of claims 11-13 under
35 U.S.C. § 112, second paragraph.

DECISION
The Examiner’s decision adverse to the patentability of claims 1-17 is
affirmed with respect to claims 1-7 and 10-17, but reversed with respect to
claims 8 and 9.
Requests for extensions of time in this inter partes reexamination
proceeding are governed by 37 C.F.R. § 1.956. See 37 C.F.R. § 41.79.

AFFIRMED-IN-PART

cu

Appeal 2012-009951
Reexamination Control No. 95/001,447
Patent 6,907,530 B2

22

Patent Owner:
Dickstein Shapiro LLP
1825 Eye Street NW
Washington, DC 20006-5403

Third Party Requester:
Vista IP Law Group LLP
12930 Saratoga Avenue
Suite D-2
Saratoga, CA 95070