Ex Parte DeGroot

Board of Patent Appeals and Interferences

Oct 31, 2011

10496506 (B.P.A.I. Oct. 31, 2011)

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.
10/496,506 11/18/2004 Vincent DeGroot DEGR3001FJD 1133
23364 7590 10/31/2011
BACON & THOMAS, PLLC
625 SLATERS LANE
FOURTH FLOOR
ALEXANDRIA, VA 22314-1176
EXAMINER
SORRELL, ERON J
ART UNIT PAPER NUMBER
2182
MAIL DATE DELIVERY MODE
10/31/2011 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 VINCENT DE GROOT

____________________

Appeal 2009-014918
Application 10/496,506
Technology Center 2100
____________________

Before, JONI Y. CHANG, KRISTEN L. DROESCH and
GREGORY J. GONSALVES, Administrative Patent Judges.

CHANG, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-014918
Application 10/496,506
2

STATEMENT OF CASE 1
Endress + Hauser Process Solutions AG (Appellant), the real party in 2
interest, appeals under 35 U.S.C. § 134(a) from a final rejection. 3
The application is the national stage of an international application 4
(PCT/EP02/12980) filed on November 20, 2002, and claims foreign priority 5
under 35 U.S.C. § 365(b) to German Patent Application 101573235, filed on 6
November 23, 2001. Claims 1-8 are pending in the application. 7
We have jurisdiction under 35 U.S.C. § 134(a). We affirm. 8
FINDINGS OF FACT 9
The following findings of fact are supported by a preponderance of 10
the evidence. Additional findings may appear in the Analysis section. 11
The Invention 12
Appellant’s invention is related to a method for operating field 13
devices (e.g., mass flow, pressure and temperature meters) remotely with a 14
control system. (Spec. 1). Appellant’s Figure 2 is reproduced below: 15
16
Figure 2 illustrates a block diagram of a field device and control system. 17
Appeal 2009-014918
Application 10/496,506
3

Claim 1 1
Claim 1 is representative of the subject matter on appeal (references to 2
Figure 2 are provided in the original)1: 3
1. A method for the remote operating and/or remote control of a 4
field device (F1) with a field device application program by 5
means of an operating device with an operating device 6
application program over a data bus, 7
[1] whereby the field device application program and the 8
operating devices application program are different from each 9
other, comprising the steps of: 10
[2] storing in the field device (F1) an intermediate code (Z) 11
describing the functionality of the field device (F1); 12
[3] converting the intermediate code (Z) with an interpreter (J1) 13
into a field device machine code, which is part of the field 14
device application program; 15
[4] transmitting the intermediate code (Z) to the operating 16
device (S); 17
[5] converting the intermediate code (Z) with an interpreter (J2) 18
into an operating device machine code, which is part of the 19
operating device application program, so that the identical 20
functionality of the field device (F1) is available in the 21
operating device; 22
[6] transmitting the field device parameters to the operating 23
device (S); and 24
[7] executing the operating device application program. 25
(App. Br. 7). 26
27

1 Claim 1 is reproduced from the Claim Appendix of the Appeal Brief, with
the numbering in brackets added and the disputed limitations emphasized.
Appeal 2009-014918
Application 10/496,506
4

Prior Art References 1
The prior art references relied upon by the Examiner in rejecting the 2
claims on appeal are: 3
De Groot EP 0 913 750 A1 Published May 6, 1999 4
De Groot US 6,278,960 B1 Issued Aug. 21, 2001 5
Johnson WO 00/77592 A2 Published Dec. 21, 2000 6
David Reilly, “Inside Java: The Java Virtual Machine” 7
(April 21, 2000) (hereafter “Reilly”). 8
De Groot (EP), De Groot, Johnson, and Reilly are prior art under 35 9
U.S.C. § 102(b). 10
Rejection on Appeal 11
Claims 1-8 are rejected under 35 U.S.C. § 103(a) as being 12
unpatentable over De Groot (EP)2, Johnson, and Reilly. (Ans. 4).3 13
Prior Art – De Groot 14
De Groot teaches a method for remotely operating a field device, 15
(e.g., a pressure or temperature gauge) using a controller. (De Groot col. 1 16
lines 10-25). De Groot further describes the following with references to 17
Figure 2 (reproduced below): (1) the field device 201 contains a field device 18
application programmed in JAVA language (labeled as “JAVA source code 19
203” in Fig. 2); (2) the field device 201 contains a JAVA complier 204 that 20
can generate a platform-independent program code (also referred as “JAVA 21
byte code” in the reference, and equated to the claim as “the intermediate 22
code” by the Examiner (see e.g., page 4 of the Answer)); (3) the program 23

2 The Examiner uses De Groot (US 6,278,960 B1) as an equivalent English
translation for De Groot (EP 0 913 750 A1).
3 All references to Answer are to the Answer dated April 6, 2009.
Appeal 2009-014918
Application 10/496,506
5

code (JAVA byte code) describes the functionality of the field device 201, 1
and it is stored in the memory 202 of the field device 201; (4) the field 2
device 201 also has a JAVA processor 205 that processes the application 3
program code (JAVA byte code) so that the program code can be executed 4
in the field device 201; (5) in order to enable the controller 208 to remotely 5
operate or control the field device 201, the field device program code (JAVA 6
byte code) is transmitted via the field bus 206 to the controller 208 by the 7
link 213, and the field device parameters 207 (e.g., limiting values of 8
measuring data, design, and range data values) are likewise transferred 9
between the controller 208 and the field device 201; (6) once the field device 10
program code (JAVA byte code) is transmitted to the controller 208, the 11
program code is stored in the controller’s memory 202a, and the controller 12
208 using a JAVA run-time environment (interpreter) converts the JAVA 13
byte code and implements the code in the controller. (De Groot, col. 2, lines 14
34-49 and 63-67; col. 3, lines 1-22; col. 4, lines 2-20). De Groot’s Figure 2 15
is reproduced below: 16
17
Figure 2 of De Groot is a diagram showing a field device and controller. 18
19
Appeal 2009-014918
Application 10/496,506
6

Prior Art – Johnson 1
Johnson also describes a method for remotely operating field devices 2
with control devices or servers. As the Examiner indicates, Johnson’s field 3
device includes a real-time operating system, a Java Virtual Machine, and a 4
virtual machine environment for executing Java byte code (or other 5
intermediate code) in the field device (page 3, paras. 1-2), and Johnson’s 6
control server is also equipped with a Java Virtual Machine (page 5, para. 3). 7
(Ans. 6). 8
Prior Art – Reilly 9
The Examiner cites Reilly to provide the basic information and 10
functional purposes of the programming language Java and Java Virtual 11
Machine that are used in De Groot and Johnson. (Final Rejection 3-4). 12
Reilly describes the following on pages 1-3 (with numbering added): 13
(1) Most programming languages compile source code directly 14
into machine code, suitable for execution on a particular 15
microprocessor architecture. The difference with Java is that it 16
uses bytecode – a special type of machine code. 17
(2) The Java Virtual Machine is responsible for interpreting 18
Java bytecode, and translating this into actions or operating 19
system calls. 20
(3) The Java Virtual Machine forms part of a large system, the 21
Java Runtime Environment (JRE). Each operating system and 22
CPU architecture requires a different JRE. 23
(4) The portability of Java comes from implementations on a 24
variety of CPUs and architectures. Without an available JRE 25
for a given environment, it is impossible to run Java software. 26
(5) Though implementations of Java Virtual Machines are 27
designed to be compatible, no two JVMs are exactly alike. 28
Appeal 2009-014918
Application 10/496,506
7

(6) The Java Virtual Machine provides a platform-independent 1
way of executing code, by abstracting the differences between 2
operating systems and CPU architectures. 3
Appellant’s Contentions 4
Appellant contends that the Examiner should have given patentable 5
weight to the preamble of claim 1, and the cited references do not teach the 6
limitations in the preamble. (App. Br. 5).4 Additionally, Appellant asserts 7
that the combination of the cited references fails “to teach those skilled in 8
the art a method where an intermediate code is used both in the field device 9
and the operating device, with the intermediate code in the field device is 10
transmitted to the operating device where it is converted into an operating 11
device machine code so that the ‘identical functionality of the field device 12
(F1) is available in the operating device.’” (App. Br. 6). Appellant further 13
argues the following: 14
By the pick -and-choose assertion made previously by applicant, the 15
point to be made was that the examiner was selecting without regard 16
for the objective to be achieved; that is, pick-and-choose without 17
regard for the operational effect on the combination. See MPEP 18
2143.01 (VI). It is for this reason that applicant stated that structural 19
elements from the prior art, which bear a resemblance to those used 20
by the present invention, were chosen, but the steps claimed were not 21
being weighed sufficiently. In other words, in the examination of this 22
application, structure was being elevated above the method steps, and 23
in method claims such a procedure can only fail. 24
(App. Br. 5-6). 25
In the reply brief, Appellant asserts the following when referencing 26
the Examiner’s motivation to combine the references (Ans. 7): 27
The significance of this statement is not apparent, and how it relates to 28
why one skilled in the art would arrive at claim 1 from this statement. 29

4 All references to Appeal Brief are to the Brief filed December 29, 2008.
Appeal 2009-014918
Application 10/496,506
8

For example, according to the invention, the functionality of the field 1
devices must be known to the operating device. If this is what the 2
examiner means by "interdependency," it must be noted that the 3
interdependency is not to be "removed" as suggested by the examiner. 4
(Reply Br. 2). 5
Appellant argues claims 1-8 together as a group. (App. Br. 5-6). 6
Accordingly, we select claim 1 as the representative claim. 37 C.F.R. 7
§ 41.37(c)(1)(vii). 8
Issue on Appeal 9
The issue is whether the Examiner erred in rejecting claim 1 under 10
35 U.S.C. § 103(a) as being obvious over the cited references. 11
ANALYSIS 12
We have reviewed the Examiner’s rejections in light of Appellant’s 13
arguments. We disagree with Appellant’s contention that the Examiner 14
erred in rejecting claims 1-8 under 35 U.S.C. § 103(a) as being unpatentable 15
over the cited references. 16
With respect to Appellant’s contention that the Examiner should have 17
given patentable weight to the preamble of claim 1 and the combination of 18
the cited references does not teach the limitation “whereby the field device 19
application program and the operating devices application program are 20
different from each other,” the Examiner has expressly stated that patentable 21
weight has been given to the preamble and addressed the limitation in the 22
preamble of claim 1. (Final Rejection 3-4 and 7-8; Advisory Action 2-4; 23
Ans. 6-7 and 9-10)5. For instance, the Examiner explains that “the 24

5 All references to Final Rejection are to the Final Rejection entered on April
8, 2008, and all references to Advisory Action are to the Advisory Action
entered on Aug. 27, 2008.

Appeal 2009-014918
Application 10/496,506
9

fundamental basis for having and using a Java Virtual Machine is to allow 1
operating devices and field (remote) devices that are architecturally different 2
and running different operating applications to communicate with each other 3
without concern for the operating and architecture differences between the 4
operating and field device.” (Ans. 7). The Examiner also in the Final 5
Rejection explains how the prior art field device and controller described in 6
De Groot and Johnson using a Java Virtual Machine would meet the 7
limitation in the preamble: 8
The functionality of the Java Virtual Machine (JVM) is to allow 9
devices to be both architecturally and operating system (application) 10
independent from each other. The JVM acts as an intermediate 11
application that receives/transmits Java bytecode and allows the code 12
to be run on the system or device independent of the operating system 13
or architecture of the system. The fundamental purpose of the Java 14
Virtual Machine is to allow the operating device application program 15
to be different from the field device application program. An example 16
would be the situation where the operating device is running the 17
windows operating system and the field device is operating under the 18
Linux operation system. In order for the two to communicate the 19
JVM is used. The operating device runs the JVM where the 20
commands that are to be sent the field device are received and are 21
converted to Java Bytecode. The Java Bytecode is then transmitted to 22
the field device where the JVM of the field device converts the Java 23
Bytecode to Linux commands to function on the field device. The 24
JVM allows for the operating device application to be independent 25
and different from the field device application program. 26
(Final Rejection 3). 27
The Examiner additionally cites Reilly (“Inside Java: The Java Virtual 28
Machine” page 3, para. 3) and points out the specific teaching that “the Java 29
Virtual Machine provides a platform-independent way of executing code, by 30
abstracting the differences between operating systems and CPU 31
Appeal 2009-014918
Application 10/496,506
10

architectures.” (Final Rejection 7). As such, we find the combination of 1
cited prior art teaches the limitation in the preamble. 2
With respect to Appellant’s contention that the combination of cited 3
prior art does not teach “a method where an intermediate code is used both 4
in the field device and the operating device, with the intermediate code in 5
the field device is transmitted to the operating device where it is converted 6
into an operating device machine so that the ‘identical functionality of the 7
field device (F1) is available in the operating device,’” we agree with the 8
Examiner that the limitation is described in the cited prior art (Ans. 4-5). In 9
particular, De Groot describes that the field device program code 203 (also 10
referred to as “the JAVA byte code” in the reference) which describes the 11
functionality of the field device is transmitted to the controller 208 via the 12
field bus 206, and the field device parameters 207 (e.g., limiting values of 13
measuring data, design, and range data values) are likewise transferred 14
between the controller and the field device. (De Groot, col. 3, lines 4-5 and 15
lines 10-11; col. 4, lines 2-6). We recognize that Java byte codes are used as 16
intermediate code. (Johnson 3 and Reilly 1-3). Moreover, De Groot further 17
describes that: 18
This JAVA byte code is stored in a memory 202a in the controller, 19
this code being platform-independent so that the objects responsible 20
for the parameter description can be made use of in the controller 208 21
by a JAVA run-time environment and a corresponding work surface. 22
This environment is indicated in FIG. 2 schematically at 209. Due to 23
the existence of the JAVA run-time environment in the controller 108 24
the JAVA byte code serving to replace the device description used 25
hitherto can be processed in the controller irrespective of the platform 26
on which this environment is placed. 27
(De Groot, col. 3, lines 12-22). 28
Appeal 2009-014918
Application 10/496,506
11

...said controller being equipped with a run-time environment in 1
which said program code can be run following transfer from said field 2
device to said controller via said field bus so that remote control and 3
remote operation of said field device is implementable by transferring 4
field device parameters via said field bus in said run-time 5
environment, wherein said field device parameters are, among other 6
things, limiting values of measuring data, design, and range data 7
values. 8
(De Groot, col. 4, lines 8-16). 9
As noted above, Johnson’s field devices and control servers use a real-10
time operating system, a Java Virtual Machine, and a virtual machine 11
environment for executing Java byte code. (Johnson 3, para. 1-2; 5, para. 3). 12
Further, Reilly teaches that the basic function of “the Java Virtual Machine 13
is responsible for interpreting Java bytecode, and translating this into actions 14
or operating system calls.” (Reilly 2). Accordingly, we find that the 15
combination of De Groot, Johnson and Reilly teaches “a method where an 16
intermediate code is used both in the field device and the operating device, 17
with the intermediate code in the field device is transmitted to the operating 18
device where it is converted into an operating device machine so that the 19
‘identical functionality of the field device (F1) is available in the operating 20
device.’” 21
With respect to Appellant’s contention that “the examiner was 22
selecting without regard for the objective to be achieved; that is, pick-and-23
choose without regard for the operational effect on the combination” and 24
Appellant’s argument regarding the Examiner’s motivation to combine the 25
references, we find that the Examiner’s conclusion of obviousness is 26
supported by articulated reasoning with rational underpinning to combine 27
the teachings of De Groot, Johnson and Reilly. In particular, the Examiner 28
Appeal 2009-014918
Application 10/496,506
12

articulated the following reasoning to combine the teachings of cited 1
references (Ans. 7): 2
It would have been obvious to one skilled in the art to combine the 3
teachings of De Groot with Johnson using the motivation of removing 4
the interdependency between the intermediate code and the machine 5
code of the field device just as the JAVA run-time environment on the 6
operating device (controller) allows the intermediate code to be 7
independent of the operating device in respect to machine code 8
(hardware). By removing the interdependency between the 9
intermediate code and machine code allows for generic development 10
of software allowing software to be developed that is not machine 11
specific and can be installed on multiple device platforms reducing the 12
cost of the software. 13
It would have been obvious to combine "Inside Java: The Java Virtual 14
Machine" with De Groot in that "Inside Java: The Java Virtual 15
Machine" since the Java Virtual Machine allows for the executing 16
code to be independent from the operating system and architecture of 17
the operating device and field device. This allows programmers to 18
write programs that are not restricted to a single operating system or 19
architecture. 20
Examiner Note: The Examiner additionally would like to emphasize 21
that the fundamental basis for having and using a Java Virtual 22
Machine is to allow operating devices and field (remote) devices that 23
are architecturally different and running different operating 24
applications to communicate with each other without concern for the 25
operating and architecture differences between the operating and field 26
device. 27
Furthermore, the Examiner’s proposed modification of (1) De Groot’s 28
field device (that generates a platform-independent program code in Java 29
programming language using a Java complier, and executes the Java byte 30
code using a Java processor) to expressly provide a Java Virtual Machine, 31
Java run-time environment and real-time operating system, and (2) De 32
Groot’s controller (that remotely operates and controls the field device by 33
using a Java run-time environment to execute and implement the transferred 34
Appeal 2009-014918
Application 10/496,506
13

Java byte code and field device parameters) to expressly provide a Java 1
Virtual Machine, as taught by Johnson and Reilly, is nothing more than the 2
application of a known technique (using Java Virtual Machine and Java run-3
time environment to run Java byte code) and the predictable use of prior art 4
elements according to their established functions (Java Virtual Machine 5
provides a platform-independent way of executing codes). 6
Moreover, we find that one of ordinary skill in the art at the time of 7
the invention would have been capable of using a Java Virtual Machine and 8
Java run-time environment in a field device as well as in a controller. The 9
Examiner’s proposed modification of De Groot would not change the basic 10
principle of operation of De Groot’s field device and controller, especially in 11
view of the fact that De Groot expressly describes a method of using a Java 12
field device application program, Java complier and Java processor in the 13
field device, and using a Java run-time environment to run the Java byte 14
code in the controller. 15
For the foregoing reasons, we find no error in the Examiner’s 16
rejection of claims 1-8. 17
DECISION 18
Accordingly, we affirm the rejection of claims 1-8 under 35 U.S.C. 19
§ 103(a) as being unpatentable over De Groot, Johnson, and Reilly. 20
No time period for taking any subsequent action in connection with 21
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R. 22
§ 1.136(a)(1)(iv). 23
AFFIRMED 24