Ex Parte Lazarz et al

Board of Patent Appeals and Interferences

Mar 26, 2012

11091996 (B.P.A.I. Mar. 26, 2012)

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/091,996 03/29/2005 Stanislaw Lazarz P/1228-195 4353
2352 7590 03/27/2012
OSTROLENK FABER LLP
1180 AVENUE OF THE AMERICAS
NEW YORK, NY 10036-8403
EXAMINER
NGUYEN, CHUONG P
ART UNIT PAPER NUMBER
3665
MAIL DATE DELIVERY MODE
03/27/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 BOARD OF PATENT APPEALS
AND INTERFERENCES
________________

Ex parte STANISLAW LAZARZ and KURT FLATISCHLER
________________

Appeal 2009-014243
Application 11/091,996
Technology Center 3600
________________

Before JOHN C. KERINS, STEVEN D.A. McCARTHY and
MICHAEL C. ASTORINO, Administrative Patent Judges.

McCARTHY, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE 1
The Appellants1 appeal under 35 U.S.C. § 134 from the Examiner’s 2
final decision rejecting claims 9-16 and 18. Claims 1-8 and 17 are 3
withdrawn from consideration. We have jurisdiction under 35 U.S.C. § 6(b).4

1 The Appellants identify the real party in interest as Scania CV AB.
Appeal No. 2009-014243
Application No. 11/091,996

2
We sustain the rejection of claims 9, 15, 16 and 18 under 35 U.S.C. 1
§ 102(b) as being anticipated by Colson (US 6,236,909 B1, issued May 22, 2
2002) or, in the alternative, under 35 U.S.C. § 103(a) as being unpatentable 3
over Colson;2 and the rejection of claims 10-13 under § 103(a) as being 4
unpatentable over Colson. 5
We do not sustain the rejection of claim 14 under § 102(b) as being 6
anticipated by Colson or, in the alternative, under § 103(a) as being 7
unpatentable over Colson. 8
Claim 9 is the sole independent claim on appeal: 9
9. A method of accessing a specification 10
file stored in a memory unit associated with an 11
electronic control unit, the electronic control unit 12
being connected to a first communication bus, the 13
method comprising: 14
checking an authorization state of a software 15
component of a user-unique key connected to a 16
computer, the computer, in turn, being configured 17
to communicate with the electronic control unit 18
over the first communication bus; and 19
enabling the computer to communicate with 20
the electronic control unit to access the 21
specification file provided that the connected key 22
is set in an active authorization state. 23
24

2 The Examiner entered the rejection of claims 9, 14-16 and 18 under
§ 102(b) as a new ground of rejection in the Answer. (See Ans. 2-3). The
Appellants concede that the Examiner did not specifically indicate that the
rejection of claims 9, 14-16 and 18 under § 103(a), which appeared on pages
3-5 of the Final Office Action mailed February 12, 2005, is withdrawn. (See
Reply Br. 5).
Appeal No. 2009-014243
Application No. 11/091,996

3
ISSUES 1
The Appellants argue the rejections of claims 9, 15, 16 and 18 as a 2
group for purposes of the rejections under § 102(b) and § 103(a). (See App. 3
Br. 3-4; Reply Br. 3-4). Claim 9 is representative. Since the Appellants 4
argue the patentability of claims 9, 15, 16 and 18 under § 102(b) and 5
§ 103(a) on the basis that Colson fails to describe the same claim limitations 6
(compare App. Br. 3-4 with id. 5-7), we need not address the rejection under 7
§ 103(a) separately from the rejection under § 102(b). Although the 8
Appellants argue the rejections of claims 10-13 separately from the rejection 9
of claim 9, the Appellants rely solely on the dependency of claims 10-13 10
from claim 9 as the basis for the patentability of claims 10-13. (See Reply 11
Br. 5). Therefore, we need not address the rejection of claims 10-13 under 12
§ 103(a) separately from the rejection of claim 9 under § 102(b). The 13
Appellants argue the rejections of claim 14 under § 102(b) and § 103(a) 14
separately from the rejections of claim 9. (See App. Br. 4-5; Reply Br. 4-5). 15
Only issues and findings of fact contested by the Appellants will be 16
addressed. See Ex Parte Frye, 94 USPQ2d 1072, 1075-76 (BPAI 2010). 17
This appeal turns on three issues: 18
First, does Colson describe a method including the step 19
of “checking an authorization state of a software component of 20
a user-unique key connected to a computer” as recited in claim 21
9? (App. Br. 3-4; Reply Br. 3-4). 22
Second, does Colson describe a method including a step 23
of “enabling the computer to communicate with the electronic 24
control unit to access the specification file provided that the 25
Appeal No. 2009-014243
Application No. 11/091,996

4
connected key is set in an active authorization state” as recited 1
in claim 9? (App. Br. 4; Reply Br. 4). 2
Third, does Colson describe a method including the step 3
of “setting the software component of the connected key in an 4
inactive authorization state” as recited in claim 14? (App. Br. 5
4-5; Reply Br. 4-5). 6
7
FINDINGS OF FACT 8
The record supports the following findings of fact (“FF”) by a 9
preponderance of the evidence. 10
1. Colson describes an automotive computing platform 102 for an 11
automobile 100. The automotive computing platform 102 includes a 12
computer in the form of a central processing unit 104. (Colson, col. 5, ll. 13
27-33). 14
2. Colson teaches that portable, high-level software applications 15
600 executed by the automotive computing platform 102 need access to the 16
functionality conveyed by devices on the automobile 100. (Colson, col. 2, ll. 17
7-10). These devices are embodied as electronic control units (“ECUs”) 18
114a-114c. (Colson, col. 5, ll. 50-56). The ECU 114a-114c communicate 19
with the automotive computing platform 102 through a gateway 118. (See 20
Colson, col. 6, ll. 16-23). 21
3. Colson’s automotive computing platform 102 hosts a 22
component registry 108. (Colson, col. 5, ll. 41, 42). Colson teaches 23
providing the automotive computing platform 102 with a plurality of 24
program components written as “JavaBeans.” These JavaBean components 25
202a-202c represent device functionality and software services available on 26
Appeal No. 2009-014243
Application No. 11/091,996

5
the automotive computing platform 102. The component registry 108 1
permits software applications 600 to determine the availability of the 2
JavaBean components and establish access to the available components’ 3
functionality. (See Colson, col. 3, ll. 4-11). 4
4. Colson’s automotive computing platform 102 also hosts a 5
lookup mechanism 208. The lookup mechanism 208 permits software 6
applications 600 to query the contents of the component registry 108 and 7
gain reference to one or more of the JavaBean components 202a-202c. 8
(Colson, col. 7, ll. 7-10). 9
5. Colson describes incorporating a smart card 128 into an ignition 10
key to form a smart key 604. The smart key 604 may be used to log on a 11
driver or user of the automobile 100. (Colson, col. 6, ll. 32-34 and 39-41). 12
The smart key 604 includes a digital certificate identifying the driver or user. 13
(Colson, col. 9, ll. 61-65). 14
6. Colson describes a process for logging on a driver. The process 15
includes detecting insertion of a smart key 604 in the ignition of the 16
automobile 100; receiving the certificate information from the smart key 17
604; and creating an authentication token 602 from the certificate 18
information. (Colson, col. 14, ll. 10-19). The authentication token 602 19
includes a user profile name. (Colson, col. 13, ll. 44-45). 20
7. Colson discloses that, when a software application 600 sends a 21
request to the lookup mechanism 208 for a device functionality or a software 22
service, the software application 600 includes the authentication token 602 23
with the request. (Colson, col. 13, ll. 30-33 and 40-41). The lookup 24
mechanism 208 queries a database containing user profiles using the data 25
profile name extracted from the authentication token 602. The database 26
Appeal No. 2009-014243
Application No. 11/091,996

6
returns an authorization level. (Colson, col. 13, ll. 45-50). The lookup 1
mechanism 208 then returns to the software application 600 a JavaBean 2
component 202a-202c, if any, which corresponds to the request and which is 3
within the authorization level returned by the database. (Colson, col. 13, ll. 4
55-67). The JavaBean component 202a-202c enables the software 5
application 600 on the automotive computing platform 102 to communicate 6
with an ECU 114a-114c. 7
8. If the lookup mechanism 208 fails to identify a JavaBean 8
component 202a-202c which corresponds to the request and which is within 9
the authorization level returned by the database, the lookup mechanism 208 10
returns a null value to the software application 600. (Colson, col. 14, ll. 4-11
6). The software application 600 in the automotive computing platform 102 12
is unable to communicate with an ECU 114a-114c if no JavaBean 13
component 202a-202c is returned. 14
9. The Examiner does not identify any disclosure by Colson that 15
the certificate of a smart key 604 might be set to a different authorization 16
state. 17
18
ANALYSIS 19
First Issue 20
The Appellants contend that Colson fails to describe a method 21
including the step of “checking an authorization state of a software 22
component of a user-unique key connected to a computer” as recited in 23
claim 9. (App. Br. 3-4; Reply Br. 3-4). We agree with the Examiner that 24
Colson’s smart key 604 is a user-unique key. (See Ans. 3; see also FF 5). 25
The certificate is a software component of the smart key 604. (See FF 5). 26
Appeal No. 2009-014243
Application No. 11/091,996

7
The Appellants do not identify any formal definition of the term 1
“authorization state” in the Specification. The ordinary usage of the word 2
“state” is sufficiently broad to encompass “a mode or condition of being.” 3
(WEBSTER’S THIRD NEW INT’L DICTIONARY (G&C Merriam Co. 1971) 4
(“state,” def. 1a)). Although the Specification refers to an embodiment with 5
an authorization state capable of assuming only two values, active and 6
inactive (see, e.g., Spec. para. [0010]), nothing in the Specification expressly 7
limits the scope of the term “authorization state” so as to require it assume 8
only one of two values. Even in the embodiment referred to in the 9
Specification, the authorization state is merely “associated” with the 10
software component of the user-unique key and is not necessarily a part of 11
the software component or of the key. (Id.) Since a “level” is a mode or 12
condition of being, albeit not a binary mode or condition, the Examiner is 13
correct in finding that Colson’s authorization level is an authorization state. 14
(See Ans. 8). 15
The authentication token 602 is derived from the certificate. (See FF 16
6). When the lookup mechanism 208 queries the database and the database 17
returns an authorization level (see FF 7), the lookup mechanism 208 and the 18
database check the authorization state of (that is, the authorization level) of a 19
software component (that is, the certificate) of a user-unique key (that is, the 20
smart key 604) connected to a computer (that is, the automotive computing 21
platform 102). 22
23
Second Issue 24
The Appellants contend that Colson fails to describe a method 25
including a step of “enabling the computer to communicate with the 26
Appeal No. 2009-014243
Application No. 11/091,996

8
electronic control unit to access the specification file provided that the 1
connected key is set in an active authorization state” as recited in claim 9. 2
(App. Br. 4; Reply Br. 4). The Appellants do not identify any formal 3
definition of the term “active authorization state” in the Specification. One 4
may define an active authorization state as an authorization state which 5
enables some action to be taken. This definition is consistent with the 6
embodiment in the Specification. 7
When the authorization level returned by the database is sufficiently 8
high to permit the lookup mechanism 208 to return a JavaBean component 9
202a-202c to the software application 600, the JavaBean component 202a-10
202c enables the software application 600 on the automotive computing 11
platform 102 to communicate with an ECU 114a-114c. (FF 7). The 12
authorization level is “active” in the sense that the authorization level is 13
sufficiently high to permit the lookup mechanism 208 and the software 14
application 600 to take positive action. In other words, the computer (that is, 15
the automotive computing platform 102) is enabled to communicate with an 16
ECU 114a-114c provided that the connected key (that is, the smart key 604 17
connected to the automotive computing platform 102 through the ignition) is 18
set in an active authorization state. 19
Since the Appellants have not identified any error in the Examiner’s 20
findings, we sustain the rejection of claims 9, 15, 16 and 18 under § 102(b) 21
as being anticipated by Colson. Furthermore, evidence establishing 22
anticipation is also sufficient to establish prima facie obviousness over the 23
anticipating reference. See In re Fracalossi, 681 F.2d 792, 794 (CCPA 24
1982), we sustain the alternative rejection of claims 9, 15, 16 and 18 under 25
Appeal No. 2009-014243
Application No. 11/091,996

9
§ 103(a) as being unpatentable over Colson. Since the Appellants rely solely 1
on the dependency of claims 10-13 from claim 9 as the basis for the 2
patentability of claims 10-13, we sustain the rejection of claims 10-13 under 3
§ 103(a) as being unpatentable over Colson. 4
5
Third Issue 6
The Appellants contend that Colson does not describe a method 7
including the step of “setting the software component of the connected key 8
in an inactive authorization state” as recited in claim 14. (App. Br. 4-5; 9
Reply Br. 4-5). Although the Examiner cites broadly to columns 9-14 of 10
Colson, (See, e.g., Ans. 4 and 9), the Examiner does not identify any 11
disclosure by Colson that the certificate of a smart key 604 might be set to a 12
different authorization state (FF 9). Since the Examiner has not provided 13
sufficient evidence to support the finding that Colson anticipates claim 14, 14
we do not sustain the rejection of claim 14 under § 102(b) as being 15
anticipated by Colson. Since the Examiner’s conclusion that the subject 16
matter of claim 14 would have been obvious from the teachings of Colson 17
rests on the same findings on which the Examiner relied in rejecting claim 18
14 for anticipation (compare Ans. 4 with Ans. 6), we do not sustain the 19
rejection of claim 14 under § 103(a) as being unpatentable over Colson. 20
21
CONCLUSIONS 22
First, Colson describes a method including the step of “checking an 23
authorization state of a software component of a user-unique key connected 24
to a computer” as recited in claim 9. 25
Appeal No. 2009-014243
Application No. 11/091,996

10
Second, Colson describes a method including a step of “enabling the 1
computer to communicate with the electronic control unit to access the 2
specification file provided that the connected key is set in an active 3
authorization state” as recited in claim 9. 4
Third, Colson does not describe a method including the step of 5
“setting the software component of the connected key in an inactive 6
authorization state” as recited in claim 14. 7
8
DECISION 9
We AFFIRM the Examiner’s decision rejecting claims 9-13, 15, 16 10
and 18. 11
We REVERSE the Examiner’s decision rejecting claim 14. 12
No time period for taking any subsequent action in connection with 13
this appeal may be extended under 37 C.F.R. § 1.136(a) (2007). 14
15
AFFIRMED-IN-PART 16
17
18
19
20
Klh 21