Ex Parte Mann et al

Patent Trial and Appeal Board

Apr 9, 2014

11147582 (P.T.A.B. Apr. 9, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
__________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
__________

Ex parte JOSEPH FRANCIS MANN, CLINTON DUANE BRITT,
STEVEN MARK CISLER, ROBERT F. LLOYD, and KRISTA MANN
__________

Appeal 2012-000127
Application 11/147,582
Technology Center 2100
__________

Before, TONI R. SCHEINER, DEMETRA J. MILLS, and
JEFFREY N. FREDMAN, Administrative Patent Judges.

FREDMAN, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal1 under 35 U.S.C. § 134 involving claims to a
configurable interface method and configurable interface. The Examiner
rejected the claims as anticipated and as obvious. We have jurisdiction
under 35 U.S.C. § 6(b). We reverse.

1 Appellants identify the Real Party in Interest as Rockwell
Automation Technologies, Inc. (see App. Br. 2).
Appeal 2012-000127
Application 11/147,582

2
Statement of the Case
Background
“[H]uman machine interfaces or ‘HMIs’ are commonly employed for
monitoring or controlling various processes. The HMIs may read from or
write to specific registers such that they can reflect the operating state of
various machines, sensors, processes, and so forth” (Spec. 1 ¶ 0002). The
Specification teaches that “interface devices and control monitoring devices
in general store code for executing their functionality . . . However, many
devices do not permit such code to be extracted from their memory or
operating system, or make editing of the code quite difficult” (Spec. 1-2 ¶¶
0003-0004).
The Claims
Claims 1-21 and 23 are on appeal. Claim 1 is representative and reads
as follows:
1. A configurable interface method comprising:
enumerating properties of a device element by an access
module resident on an interface device in response to a query in a
design-time environment, the device element including a specific
property type configured to store editable code and editable code
stored in the property type; and
serving the editable code and an editing environment from the
interface device to a configuration station for editing the editable code
in the editing environment.

The issues
A. The Examiner rejected claims 1, 2, 4-7, 9-11, 13-16, 21, and 23 under
35 U.S.C. § 102(b) as anticipated by Crater2 (Ans. 4-10).

2 Crater et al., US 6,201,996 B1, issued Mar. 13, 2001.
Appeal 2012-000127
Application 11/147,582

3
B. The Examiner rejected claims 3, 8, 12, and 17 under 35 U.S.C.
§ 103(a) as obvious over Crater and Solton3 (Ans. 10-12).
C. The Examiner rejected claims 18-20 under 35 U.S.C.
§ 103(a) as obvious over Crater and Chapman4 (Ans. 12-13).
A 35 U.S.C. § 102(b) over Crater
The Examiner finds that Crater teaches a “configurable interface
method comprising . . . web access to industrial controllers . . . visualization
of the control function is itself implemented as an object component . . . the
web page, configured as an object component, may be programmed to
obtain the appropriate state and/or diagnostic data from other object
components” (Ans. 4). The Examiner finds that Crater teaches “the viewer
obtains a configuration property sheet . . . allows the viewer to reconfigure
various aspects of the applet” (Ans. 4-5). The Examiner finds that the
“controller maintains a web page that it serves to the browser upon
connection . . . may allow the viewer to modify particular visual attributes ...
authorized users with access to the object components, thereby facilitating
remote programming” (Ans. 5).
The issue with respect to this rejection is: Does the evidence of record
support the Examiner’s conclusion that Crater teaches “editable code stored
in the property type” and “serving the editable code” as required by claim 1?

3 Solton et al., US 5,911,070, issued Jun. 8, 1999.
4 Chapman et al., US 2004/0021679 A1, published Feb. 5, 2004.
Appeal 2012-000127
Application 11/147,582

4
Findings of Fact
1. Crater teaches:
web access to industrial controllers with the programming
benefits of object-oriented design to achieve a highly
integrated system amenable to ready customization and
modification. . . . operation of an industrial controller is
organized into a series of procedures. These procedures
include performance of the control function as well as
display of a visual representation relevant to that function

(Crater, col. 3, ll. 59-66).
2. Crater teaches that a “web page, configured as an object
component, may be programmed to obtain the appropriate state and/or
diagnostic data from other object components when the web page is
accessed via a browser” (Crater, col. 4, ll. 14-17).
3. Crater teaches that the “web page may contain instructions
executable on the browser that cause the browser to periodically query the
controller for data” (Crater, col. 4, ll. 22-25).
4. Crater teaches that:
Property sheet 500 is generated by a function
embedded within the applet code; it is responsive to viewer
input and allows the viewer to reconfigure various aspects of
the applet, including: 1. The object and item (state,
diagnostic, metric, etc.) being queried within the controller;
2. A button causing a chart to be displayed; 3. The text to
display preceding the number (“Station 1 Cap Time:”); 4.
The text to display following the number (“Milliseconds”);
5. The text color and background color; and 6. High and low
alarm levels, and the text and background colors to change
to if these levels are reached.

(Crater, col. 22, ll. 6-20).
Appeal 2012-000127
Application 11/147,582

5

5. Crater teaches that:
Property sheet 500 may allow the viewer to modify other
aspects of the associated applet, including its mode of
operation. . . . The viewer’s modifications of default values
may be saved in non-volatile storage on the viewer’s
computer (e.g., as so-called “cookies”) so that the next time
he accesses the web page, the applets will run as previously
modified.

(Crater, col. 22, ll. 53-63)(emphasis added).
6. Crater teaches that the “dynamic display may respond to viewer
actions taken via the browser. For example, the display may allow the
viewer to modify particular visual attributes, thereby enabling creation of a
customized display tailored to the viewer’s interests or concerns” (Crater,
col. 4, ll. 28-32).
7. The Specification teaches that “interface devices and control
monitoring devices in general store code for executing their functionality”
(Spec. 1 ¶ 0003)
8. The Specification teaches that:
In most situations the code is written as source code,
compiled and stored on the device during initial or
subsequent configuration. Any subsequent changes to the
code generally require either that the code be extracted from
the device for editing and rewriting, followed by
recompiling and restoring, or that separate code be written
and placed on the device replacing the existing code.

(Spec. 1 ¶ 0003).
Appeal 2012-000127
Application 11/147,582

6
Principles of Law
“The protocol of giving claims their broadest reasonable interpretation
during examination does not include giving claims a legally incorrect
interpretation. This protocol is solely an examination expedient, not a rule
of claim construction.” In re Skvorecz, 580 F.3d 1262, 1267 (Fed. Cir.
2009).
Analysis
Appellants contend that “‘code’ refers to, for example, ‘instructions
written in a programming language’” (App. Br. 7). Appellants contend that
“Crater provides for changing certain properties of an object, such as text
color, background color, alarm values . . . None of these properties are
‘editable code’ stored in a ‘property type.’ Values such as text color,
background color, numeric alarm values, are not ‘code,’ e.g., a programming
language” (App. Br. 8).
The Examiner finds that “as far as independent claims 1, 15, 21 and
23 are concerned, the term ‘editable code’ can be broadly interpreted as
‘editable data’ and does not limit to source code only” (Ans. 15). The
Examiner further finds that:
Moreover, in the published application, specifically in the
original claim 15 recites “. . . responding to the query with
editable data from device element . . . for editing the
editable data.” This clearly further provided more evidence
that appellant do not intend the “editable code” to be
automatically equate to be source code only.

(Ans. 15; internal quote redacted).
We find that Appellants have the better position. While we do not
read limitations from the Specification into the claims, we do read the claims
Appeal 2012-000127
Application 11/147,582

7
in light of the Specification. Here, the Specification teaches that the term
“code” results in devices executing their functionality (FF 7), consistent with
Appellants cited dictionary definition of “code” as “instructions written in a
programming language” (App. Br. 7). The Specification further explains the
code mostly is “source code” and that changes require editing of the code
(FF 8). Thus, in light of the Specification, the term “code” is reasonably
interpreted as programming instructions.
The Examiner’s only rebuttal evidence relies upon original claim 15,
which uses the term “editable data” (Ans. 15). However, the Examiner’s
quote ellipses out the phrase “interpretable code” from original claim 15,
where the entire quote reads “responding to the query with editable data
from device element and interpretable code for editing the editable data”
(Spec. 49, original claim 15; emphasis added). When original claim 15 is
read in its entirety, the reasonable interpretation distinguishes the term
“code” from “editable data”.
We conclude that it is unreasonable to interpret something that is
designated as “code” (FF 7-8) as encompassing “data” in order to render the
claim anticipated when that interpretation would conflate “code for
executing [device’s] functionality” (FF 7) with simple “editable data” which
performs no executable function. The Federal Circuit addressed a similar
question in Buszard, and noted “[w]e agree with Buszard that it is not a
reasonable claim interpretation to equate ‘flexible’ with ‘rigid.”’ In re
Buszard, 504 F.3d 1364, 1367 (Fed. Cir. 2007).
Having found that “editable data” is not “editable code”, we further
agree with Appellants that Crater does not teach serving “editable code”, nor
Appeal 2012-000127
Application 11/147,582

8
the use of any “editable code” in a device element (see App. Br. 8). At best,
Crater teaches that the browser being used to access a device may include
“code” in the form of “instructions” (FF 6), but there is no teaching of
“serving the editable code and an editing environment from the interface
device”, where the “interface device” is reasonably interpreted as a
component distinct from the browser.
Conclusion of Law
The evidence of record does not support the Examiner’s conclusion
that Crater teaches “editable code stored in the property type” and “serving
the editable code” as required by claim 1.
B. and C. 35 U.S.C. § 103(a)
These rejections rely upon the underlying anticipation rejection over
Crater. Having reversed the rejection of claim 1, we necessarily reverse
these obviousness rejections further including Solton or Chapman, since
neither Solton nor Chapman are relied upon to teach “editable code stored in
the property type” and “serving the editable code” as required by claim 1.
SUMMARY
In summary, we reverse the rejection of claims 1, 2, 4-7, 9-11, 13-16,
21, and 23 under 35 U.S.C. § 102(b) as anticipated by Crater.
We reverse the rejection of claims 3, 8, 12, and 17 under 35 U.S.C.
§ 103(a) as obvious over Crater and Solton.
We reverse the rejection of claims 18-20 under 35 U.S.C. § 103(a) as
obvious over Crater and Chapman.

REVERSED
lp