Ex Parte Pelz et al

Board of Patent Appeals and Interferences

Aug 16, 2012

09913992 (B.P.A.I. Aug. 16, 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.
09/913,992 03/21/2002 Rodolfo Mann Pelz 10191/1969 8032
26646 7590 08/17/2012
KENYON & KENYON LLP
ONE BROADWAY
NEW YORK, NY 10004
EXAMINER
WEST, JEFFREY R
ART UNIT PAPER NUMBER
2857
MAIL DATE DELIVERY MODE
08/17/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 RODOLFO MANN PELZ and OLIVER VOGT
____________

Appeal 2010-006367
Application 09/913,992
Technology Center 2800
____________

Before JOSEPH L. DIXON, LANCE LEONARD BARRY, and
CARL W. WHITEHEAD, JR., Administrative Patent Judges.

DIXON, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2010-006367
Application 09/913,992

2
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from a rejection of claims
11, 12, 14, 16-23, and 26. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
The claims are directed to a service element in a motor vehicle for
performing error diagnosis in system components. Claim 11, reproduced
below, is illustrative of the claimed subject matter:
11. A service element that belongs to a distributed
system in a motor vehicle as a component, the distributed
system further including other components that are independent
of one another and interconnected by a bus, the service element
comprising:

a processing device disposed in the motor vehicle and
adapted to perform operations including the operations of:

configuring the other components;

maintaining the other components;

performing an error diagnosis of software running on the
other components, and, if the software on one of the other
components has an error, correcting that software;

allowing a remote diagnosis of the other components of
the distributed system to be carried out, wherein the remote
diagnosis includes testing at least one of the other components;
and

performing an emergency function.

Appeal 2010-006367
Application 09/913,992

3
REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Worger

Boatwright

Ishii

Gray

Buckley

Chou

Razavi

de Bellefeuille

US 4,866,713

US 5,465,207

US 5,964,813

US 6,185,491 B1

US 6,246,935 B1

US 6,330,499 B1

US 6,370,449 B1

US 6,512,968 B1
Sep. 12, 1989

Nov. 7, 1995

Oct. 12, 1999

Feb. 6, 2001
(filed July 31, 1998)

Jun. 12, 2001
(filed Dec. 28, 1998)

Dec. 11, 2001
(filed July 21, 1999)

Apr. 9, 2002
(filed June 14, 1999)

Jan. 28, 2003
(filed Oct. 31, 1997)

REJECTIONS
§ 112, First Paragraph
Claims 11, 12, 14, and 16-23 stand rejected under 35 U.S.C. § 112,
first paragraph, as failing to comply with the enablement requirement.
Claim 26 stands rejected under 35 U.S.C. § 112, first paragraph, as
failing to comply with the written description requirement.

Appeal 2010-006367
Application 09/913,992

4
Prior Art Rejections
Claims 11, 12, 14, 17-20, and 23 stand rejected under 35 U.S.C.
§ 103(a) as being unpatentable over Razavi and de Bellefeuille.
Claims 11, 12, 14, 16-21, and 23 stand rejected under 35 U.S.C.
§ 103(a) as being unpatentable over Gray, Buckley, and Chou.
Claim 16 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Razavi, de Bellefeuille, and Chou.
Claim 21 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Razavi, de Bellefeuille, and Boatwright.
Claim 22 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Razavi, de Bellefeuille, and Ishii.
Claims 22 and 26 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Gray, Buckley, Chou, and Worger.
Claim 26 stands rejected under 35 U.S.C. § 103(a) as being
unpatentable over Razavi, de Bellefeuille, Chou, and Ishii.

ANALYSIS
The Enablement Rejection
The Examiner finds that Appellants’ Specification lacks enablement
for the limitations “performing an error diagnosis of software running on the
other components” and “allowing a remote diagnosis of the other
components of the distributed system to be carried out, wherein the remote
diagnosis includes testing at least one of the other components,” as recited in
independent claim 11, and for similar limitations recited in independent
claim 19 (Ans. 4-7). Appellants contend that one of ordinary skill in the art
Appeal 2010-006367
Application 09/913,992

5
would have understood the claimed diagnosis and testing without undue
experimentation (App. Br. 5-6). We agree with Appellants.
Appellants assert that the “actual diagnosis routines and test routines
are well known in the art, and selected based on context of specific
implementation” (App. Br. 6). The Specification supports such an
interpretation of claim 11 that defines the claim terms “diagnosis” and
“testing” as known methods for performing “diagnosis” and “testing.” For
example, the Specification provides that “self-diagnosis, which is performed
by software, is carried out using a suitable method,” and that “[a] method
known for this is the checksum method” (Spec. 7:8-10). Although the scope
of known “diagnosis” and “testing” methods may be broad, and the
Specification’s description of “diagnosis” and “testing” methods is merely
exemplary, “[t]he specification need not disclose what is well known in the
art.” In re Buchner, 929 F.2d 660, 661 (Fed. Cir. 1991) (citing Lindemann
Maschinenfabrik GMBH v. American Hoist & Derrick Co., 730 F.2d 1452,
1463 (Fed. Cir. 1984). Given that such “diagnosis” and “testing” routines as
encompassed by claim 11 are well known in the art (see App. Br. 6), we find
that that claim 11 does not lack enablement for want of description of how to
perform “diagnosis” and “testing.”
Further, the Examiner’s enablement rejection provides that it is
“unclear to one having ordinary skill in the art how the remote diagnosis and
testing differ and raises the issue as to whether or not the remote diagnosis
and testing are indeed different from each other” (Ans. 4-5). To the extent
that the Examiner’s statement comments on the definiteness of claim 11, we
note that no rejection based on indefiniteness is before us. In any case, we
agree with Appellants that one of ordinary skill in the art would have
Appeal 2010-006367
Application 09/913,992

6
understood that testing is a part of performing a diagnosis (see App. Br. 6).
That is, one must gather information, such as through testing, to complete a
diagnosis.
Therefore, we find that the Examiner erred in rejecting independent
claim 11, independent claim 19, which includes similar limitations, and
dependent claims 12, 14, 16-18, and 20-23 as failing to comply with the
enablement requirement.

The Written Description Rejection
The Examiner finds that Appellants’ Specification fails to provide
written description support for the claim 26 limitations “a processing device
disposed in the motor vehicle and adapted to perform operations including
the operations of: automatically, and at predefined intervals, performing an
error diagnosis of software running on the other components; for each of a
first subset of errors diagnosed in the error diagnosis step, repair the error;
and for each of a second subset of errors diagnosed in the error diagnosing
step, contact a provider and allow the provider to responsively remotely
repair the error” (Ans. 7-11). Appellants contend that the Specification as
originally filed does in fact provide written description support for claim 26
(App. Br. 7-8). We agree with Appellants.
Specifically, the Examiner finds that the Specification “does not
support a local error diagnosis by the on-vehicle processing device nor that
the diagnosis is an error diagnosis of software” (Ans. 8). However, the
Specification discloses:
In regular intervals, service element 2 checks the components,
which are connect to bus 1, and to which service element 2 also
belongs. Therefore, a self-diagnosis is also carried out. This
Appeal 2010-006367
Application 09/913,992

7
self-diagnosis, which is performed by software, is carried out
using a suitable method.

A method known for this is the checksum method. CRC
(cyclical redundancy check) sums are calculated using code
segments of the software, and are compared. In this manner, an
incorrect code can be identified . . .

(Spec. 7:6-12). Moreover, originally-filed claim 3 recites “the service
element . . . carries out an error diagnosis of software running on the other
components . . . .” We find that the cited portion of the Specification and
original claim 3 provide written description support for the claim 26 feature
“the service element comprising: a processing device . . . to perform
operations including the operations of . . . performing an error diagnosis of
software running on the other components.”
The Examiner also finds that the Specification describes that when “a
first subset of errors is diagnosed, the service element contacts a service
provider to repair the error and if a second subset or errors is diagnosed, the
service provider is also contacted” (Ans. 10). In other words, even if a self-
diagnosis is performed, the remote service provider will perform the error
repair in all cases, not the service element. However, the Specification
describes that, after diagnosing an error in component software, “if the
remaining software of the service element has the independent capability,
then the software can be repaired, e.g., by loading new software parts, so-
called patches” (Spec. 7:12-14). Further, the Specification also describes
that “[s]ervice element 2 also contacts the service provider, using
communication means 4, when service element 2 can no longer eliminate an
error itself” (Spec. 5:19-20) (emphasis added). Additionally, originally-filed
claim 3 recites “the service element . . . in the case of an error, corrects the
Appeal 2010-006367
Application 09/913,992

8
software . . . .” Thus, we find that the Specification and original claim 3
provide adequate written description support for the claim 26 feature “for
each of a first subset of errors diagnosed in the error diagnosis step, repair
the error.”
Therefore, we find that the Examiner erred in rejecting independent
claim 26 as failing to comply with the written description requirement.

The Obviousness Rejection over Razavi and de Bellefeuille
Appellants contend that Razavi and de Bellefeuille fail to disclose “a
processing device disposed in the motor vehicle and adapted to perform
operations including the operations of: configuring the other components;
maintaining the other components;” and “performing an emergency
function,” as recited in representative independent claim 11 (App. Br. 8-11).
We disagree.
Razavi discloses:
[T]he configuration of the vehicle components as network
devices on an in-car sub-network simplifies installation and
removal of the devices, hence re-configuration of the vehicle.
This system thereby makes it possible to remove outdated
components and replace them with new components, even
though the new components may have different features or
require different data or other signals from the vehicle or its
components. Similarly, components which execute associated
software, display data or provide services can be upgraded by
downloading new software, data or services (“upgrade data”) to
the components through the in-car sub-network. This software
may be quickly and easily retrieved from sources external to the
in-car sub-network, such as web pages or LANs which can be
accessed through the communication devices on the in-car sub-
network. The software can be retrieved by one device (e.g., a
wireless modem,) conveyed through the network and installed
Appeal 2010-006367
Application 09/913,992

9
in a second device (e.g., a GPS locator) as easily as
downloading a web page.

(Razavi, col. 13, ll. 46-64). Appellants argue that Razavi does not mention
“what device does the ‘install[ing] in a second device’” (see App. Br. 10-
11). However, we agree with the Examiner and find that Razavi’s compute
platform 22 performs such upgrades, for the reasons discussed in the Answer
(see Ans. 12, 45-52). Specifically, Razavi discloses: “In-car sub-network is
built around an on-board compute platform 22. . . . All of the components of
the in-car sub-network are either directly plugged into the compute platform
or coupled to do [sic] it via an Ethernet connection” (Razavi, col. 6, ll. 12-
18; Fig. 2). Thus, because Razavi’s compute platform 22 is the central hub
of the in-car sub-network 20 (see id.) we find that the compute platform
controls the network, including “configuration of the vehicle components as
network devices” (Razavi, col. 13, ll. 46-47)—i.e., “configuring the other
components”—and “downloading new software, data or services . . . to the
components through the in-car sub-network” (Razavi, col. 13, ll. 55-57)—
i.e., “maintaining the other components.” We are thus not persuaded by
Appellants’ argument (App. Br. 9-11; Reply Br. 5-6) that Razavi and de
Bellefeuille fail to disclose “a processing device . . . to perform operations
including the operations of: configuring the other components; maintaining
the other components.”
We are also not persuaded by Appellants’ argument (App. Br. 8-9;
Reply Br. 4-5) that Razavi and de Bellefeuille fail to disclose a “processing
device . . . to perform . . . an emergency function.” Claim 11 does not define
a specific “emergency function” to be performed by the claimed service
element, and Appellants’ Specification provides only exemplary functions,
Appeal 2010-006367
Application 09/913,992

10
for example, “sensors to detect an emergency situation, e.g., an accident”; “a
video camera . . . in order to conduct an image analysis, so that, in the case
of the user being attacked, an emergency call is immediately executed”; and
“voice analysis . . . in order to conduct a condition analysis” (Spec. 8:4-12).
Accordingly, we agree with the Examiner and find that Razavi’s “emergency
assistance signaling” service meets the limitation of “performing an
emergency function” (see Ans. 12, 39, 43; Razavi, col. 1, ll. 42-47). Further,
we agree with the Examiner and find that it would have been obvious for
Razavi’s compute platform 22 to perform the emergency assistance
signaling because Razavi’s invention seeks to integrate such vehicle services
through an in-car sub-network 20, with compute platform 22 at the center of
the in-car sub-network (see Ans. 39-42; Razavi, col. 6, ll. 10-18; Fig. 2).
We are therefore not persuaded that the Examiner erred in rejecting
claim 11, and claims 12, 14, 17-20, and 23 not separately argued.

The Other Obvious Rejections
Although Appellants nominally argue claims 16, 21, 22, and 26
separately, Appellants rely on the arguments presented for claims 11 and 19,
and provide no new arguments (see App. Br. 12-13). We therefore sustain
the rejections of claims 16, 21, 22, and 26 for the reasons discussed above.
The Examiner’s rejections of claims 11, 12, 14, 16, 21, and 23 over
Gray, Buckley, and Chou, and claims 22 and 26 over Gray, Buckley, Chou,
and Worger are cumulative to the other obvious rejections. As discussed
above, we sustain the rejections of these same claims over Razavi, de
Bellefeuille, Chou, Boatwright, and Ishii. Therefore, we do not reach the
cumulative rejections over Gray, Buckley, Chou, and Worger.
Appeal 2010-006367
Application 09/913,992

11
CONCLUSIONS OF LAW
The Examiner erred in rejecting claims 11, 12, 14, 16-23, and 26
under 35 U.S.C. § 112, first paragraph, but did not err in rejecting claims 11,
12, 14, 16-23, and 26 under 35 U.S.C. § 103(a).

DECISION
For the above reasons, we affirm the rejections of claims 11, 12, 14,
16-23, and 26.
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). See 37
C.F.R. § 41.50(f).

AFFIRMED

Vsh