Ex Parte Gilboa et al

Patent Trial and Appeal Board

Sep 26, 2012

11324155 (P.T.A.B. Sep. 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/324,155 12/29/2005 Yuval Gilboa 2005P00379US01
(S20.037)
6181
52025 7590 09/27/2012
SAP AG c/o BUCKLEY, MASCHOFF & TALWALKAR LLC
50 LOCUST AVENUE
NEW CANAAN, CT 06840
EXAMINER
GUTIERREZ, ANDRES E
ART UNIT PAPER NUMBER
2141
MAIL DATE DELIVERY MODE
09/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 PATENT TRIAL AND APPEAL BOARD
________________

Ex parte YUVAL GILBOA and RINAT GILBOA
________________

Appeal 2010-005326
Application 11/324,155
Technology Center 2100
________________

Before SCOTT R. BOALICK, JEFFREY S. SMITH, and
JENNIFER L. MCKEOWN, Administrative Patent Judges.

MCKEOWN, Administrative Patent Judge.

DECISION ON APPEAL
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 4-9, 11, 14-19, 21, and 22. We have jurisdiction under
35 U.S.C. § 6(b). We affirm-in-part.

STATEMENT OF CASE
Appellants describe the present invention as being directed to a
method and system for facilitating creation of graphical user interfaces
Appeal 2010-005326
Application 11/324,155

2
(GUIs) for different runtime environments. (See Spec. ¶ [0002].) According
to Appellants, the invention provides
[t]echniques for decoupling models created during
design-time from the runtime environment. A declarative and
executable representation for GUIs for applications is provided
that is independent of any particular runtime platform, GUI
framework, device, or programming language and which acts as
an interface between the design environment and the runtime
environment.
(Abstract.)
Independent claim 1 is illustrative and reproduced below with key
disputed limitations emphasized:
1. A method performed by a computer system, the method
comprising:
receiving from a modeling tool information defining a
model representation for an application, the model
representation comprising graphical user interface (GUI)
components and dependencies between GUI components to
define a GUI for the application;
automatically generating a declarative and executable
abstract representation for the GUI based upon the model
representation, including the GUI components and the
dependencies between GUI components, wherein the abstract
representation is independent of a runtime environment
platform for executing the application; and
automatically generating at least a first GUI for a first
runtime environment platform using the abstract representation.

THE REJECTION
The Examiner rejected claims 1, 4-9, 11, 14-19, 21, and 22 under 35
U.S.C. § 102(b) as anticipated by Learning Java (JONATHAN KNUDSEN &
Appeal 2010-005326
Application 11/324,155

3
PATRICK NIEMEYER, LEARNING JAVA ch. 1.2, 13 (O’Reilly & Assoc. 2000).1
(Ans. 3-14.)

CONTENTIONS
The Examiner finds that Learning Java discloses every recited feature
of illustrative claim 1 including automatically generating Java byte code
(i.e., an abstract representation) for a GUI based upon Java Swing source
code (i.e., a model representation). (Ans. 4-5, 14-15.)
Appellants contend that Learning Java does not disclose
“automatically generating a[n] . . . abstract representation for the GUI based
upon the model representation, including the GUI components and the
dependencies between GUI components,” as recited in claim 1. (App. Br.
6.) Appellants distinguish Learning Java because it converts source code
into byte code but does not disclose “the automatic generation of source
code (which can then subsequently be converted into Java bytes) based on
the model representation.” (App. Br. 7.) Additionally, Appellants argue that
Learning Java fails to “disclose receiving from a modeling tool information
defining a model representation for an application (e.g., receiving such
information from Visual ComposerTM or Rational RoseTM)” and then
generating the abstract representation based on the model. (App. Br. 6-7.)
With respect to claim 4, the Examiner finds that Learning Java selects
a first set of mapping rules “based at least in part on a model type associated
with the model representation.” (Ans. 5-6.) In support of this finding, the

1 The Examiner's Answer contained a typographical error when it stated that
claims 2, 3, 10, 12, 13, and 20 were rejected (Ans. 3), as clarified in the
communication mailed on October 28, 2009. Claims 2, 3, 10, 12, 13, and 20
have been cancelled.
Appeal 2010-005326
Application 11/324,155

4
Examiner states that Learning Java “discloses that its source code (model
representation) is compiled into Java byte code (abstract representation).”
(Ans. 5.) The Examiner also notes that Java’s Swing toolkit uses layout
managers that “define a strategy for arranging components instead of
specifying absolute positions.” (Ans. 15 (citing Learning Java p. 7, ¶ 2).)
Appellants reply by contending that Learning Java does not disclose
selecting a set of mapping rules “based at least in part on a model type
associated with the model representation.” (App. Br. 7.)
Finally, regarding claim 22, the Examiner finds that Learning Java
describes a Model/View/Controller framework that can draw different
representations for data, such as a bar graph or pie chart, based on the user
interface component controller. (Ans. 16.)
Appellants in response argue that Learning Java does not disclose that
an abstract representation can be used to rendering a first and second GUI
using different graphical elements. (App. Br. 7-8.)

ISSUES
1. Under § 102, has the Examiner erred in rejecting claim 1 by
finding that Learning Java automatically generates an abstract representation
for the GUI based upon the model representation?
2. Under § 102, has the Examiner erred in rejecting claim 4 by
finding that Learning Java selects a set of mapping rules based at least in
part on a model type associated with the model representation?
3. Under § 102, has the Examiner erred in rejecting claim 22 by
finding that Learning Java discloses at least a portion of a second GUI being
Appeal 2010-005326
Application 11/324,155

5
rendered differently, using a different graphical element, than a
corresponding potion of the first GUI?

ANALYSIS
Claim 1
On this record, we find no error in the Examiner’s anticipation
rejection of claim 1.
Appellants argue that Learning Java does not disclose “automatically
generating a declarative and executable abstract representation for the GUI
based upon the model representation, including the GUI components and the
dependencies between GUI components,” as recited in claim 1. (See App.
Br. 6-7.) In particular, Appellants contend that Learning Java does not
automatically generate an abstract representation based upon a model
representation. (Id.) We disagree.
According to Appellants, the Java byte code of Learning Java is
distinguishable from the claimed abstract representation because the claimed
abstract representation is later converted into Java code or some other type
of code. (See, e.g., App. Br. 6 (“The abstract representation may then be
converted into Java Code . . . or into other types of code . . . .”); App. Br. 7
(“For example, the references [sic] does not disclose the automatic
generation of source code (which can then subsequently be converted into
Java bytes) based on the model representation.”) (emphasis added).) We
find this argument unpersuasive.
While the Specification describes later conversions of the abstract
representations in exemplary embodiments, these features, however, are
absent from the claim. Nowhere does the claim require that the abstract
Appeal 2010-005326
Application 11/324,155

6
representation be in a particular form, such as source code, or that it be
capable of being converted into a particular form at a later point in time.
(See App. Br. 9 (reciting claim 1).) Appellants further fail to provide any
persuasive justification for importing such a limitation into the claim. See,
e.g., SuperGuide Corp. v. DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed.
Cir. 2004) (“Though understanding the claim language may be aided by the
explanations contained in the written description, it is important not to
import into a claim limitations that are not a part of the claim. For example,
a particular embodiment appearing in the written description may not be
read into a claim when the claim language is broader than the
embodiment.”).
Next, Appellants argue that Learning Java does not disclose receiving
information defining a model representation of an application from a
modeling tool and then using the model representation as the basis for
generating an abstract representation. (App. Br. 6-7.) We also find this
argument unavailing and agree with the Examiner that Learning Java teaches
these features. (Ans. 4-5; 14-15.)
Here, the Examiner correctly explains that Java’s user interface
toolkit, Swing, allows a user to build a complex layout for a GUI, including
interface items such as buttons, text areas, etc. (Ans. 4-5, 14-15; see also
Learning Java p. 5, ¶ 1 (describing that Swing includes everything you need
to build a user interface for your application).) Thus, the source code
developed with Swing, including all the necessary features of a GUI, is a
model representation for an application (i.e., the GUI itself). (Ans. 4.) This
source code is then converted into byte code. (Ans. 4; see also App. Br. 6.)
Therefore, the Examiner correctly finds that Learning Java discloses
Appeal 2010-005326
Application 11/324,155

7
information defining a model representation (Swing Java source code) is
received from a modeling tool (Swing) and then used as the basis to generate
an abstract representation (byte code).
Accordingly, we sustain the Examiner’s rejection of independent
claim 1, and independent claims 11 and 21 which recite similar features,
under § 102. Further, we sustain the Examiner’s rejection of claims 5-9 and
15-19, which depend from claims 1 and 11.

Claims 4 and 14
Claim 4 requires, inter alia, selecting a set of mapping rules “based at
least in part on a model type associated with the model representation.”
(App. Br. 7.) Based on the record before us, we conclude the Examiner
erred in finding that Learning Java discloses this limitation.
In the Answer, the Examiner finds that Learning Java discloses that
source code (a model representation) is compiled into Java byte code (an
abstract representation). (Ans. 5.) The Examiner also states that the first set
of mapping rules is the compiled source code, but nowhere does the
Examiner identify how the selection of the mapping rules is based at least in
part on a model type associated with the model representation. (See Ans. 5.)
In response to Appellants’ contentions, the Examiner points to Swing and
how Swing uses layout managers to arrange and modify components.
(Ans. 16.) Notably absent, though, is how Swing or the layout managers of
Swing relate to selecting a set of mapping rules based at least on part of the
model type. Therefore, we conclude the Examiner has not sufficiently
shown that Learning Java discloses selecting a set of mapping rules based at
Appeal 2010-005326
Application 11/324,155

8
least in part on a model type associated with the model representation, as
required by claim 4.
Accordingly, we do not sustain the Examiner’s rejection of claim 4
and claim 14, which recites similar limitations.

Claim 22
On this record, we find no error in the Examiner’s rejection of claim
22.
We disagree with Appellants that Learning Java fails to disclose that
“at least a portion of a second GUI is rendered differently, using a different
graphical element, than a corresponding potion of the first GUI,” as required
by claim 22. (App. Br. 7.) Appellants explain that, for example, an input in
one rendition is a field to be filled in numerically while the input in a second
rendition is a sliding scale to be positioned. (App. Br. 7-8.)
Appellants argue that Learning Java teaches that Swing is
implemented in Java and presents identical graphical elements even when
displayed on different platforms. (App. Br. 8.) However, as explained by
the Examiner, Learning Java also discloses a Model/View/Controller
framework that allows data to be represented differently. (Ans. 16.) For
example, Learning Java describes that data in a spreadsheet can be presented
differently, such as in a bar graph or a pie chart, based upon the user
interface component’s controller. (Id. (citing Learning Java p. 10, ¶ 1).)
Accordingly, we sustain the Examiner’s rejection of claim 22 under
§ 102.

Appeal 2010-005326
Application 11/324,155

9
DECISION
The Examiner’s decision rejecting claims 1, 5-9, 11, 15-19, 21, and 22
is affirmed. The rejection of claims 4 and 14, however, is reversed.
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).

AFFIRMED-IN-PART

babc