Ex Parte Farn

Patent Trial and Appeal Board

Jul 11, 2013

11396781 (P.T.A.B. Jul. 11, 2013)

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/396,781 04/03/2006 Brian Gin Farn CA920050065US1 4714
46320 7590 07/12/2013
CAREY, RODRIGUEZ, GREENBERG & O''''KEEFE, LLP
STEVEN M. GREENBERG
7900 Glades Road
SUITE 520
BOCA RATON, FL 33434
EXAMINER
QUELER, ADAM M
ART UNIT PAPER NUMBER
2177
MAIL DATE DELIVERY MODE
07/12/2013 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 BRIAN GIN FARN
__________

Appeal 2011-003183
Application 11/396,781
Technology Center 2100
__________

Before LORA M. GREEN, JEFFREY N. FREDMAN, and
ULRIKE W. JENKS, Administrative Patent Judges.

FREDMAN, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal
1
under 35 U.S.C. § 134 involving claims to a
method, system, and computer program product for rendering a markup
language document. The Examiner rejected the claims as obvious. We have
jurisdiction under 35 U.S.C. § 6(b). We affirm.

1
Appellant identifies the Real Party in Interest as International
Business Machines Corporation (see App. Br. 2).
Appeal 2011-003183
Application 11/396,781

2
Statement of the Case
Background
“This invention relates generally to the field of markup languages and
user interfaces of computer processing software, and in particular, relates to
a new XML schema that delivers user interface definitions from application
servers to clients across a network” (Spec. 1 ¶ 1).
The Claims
Claims 27-29 are on appeal. The claims have not been argued
separately and therefore stand or fall together with independent claim 27. 37
C.F.R. § 41.37(c)(1)(vii). Claim 27 reads as follows:
27. A method for rendering a markup language document
conforming to a model-view-controller (MVC) language, the
method comprising:
loading a markup language document into memory in a
computer;
determining from the markup language document
whether or not the markup language document conforms to an
MVC schema comprising a view section that describes a user
interface hierarchy, a set of user interface elements, and a set of
user interface layout types, a model section describing data
associated with the user interface elements and a controller
section describing actions to be performed when a user
interface event occurs; and,
responsive to determining from the markup language
document that the markup language document conforms to the
MVC schema, retrieving data from the model section of the
markup language document, arranging a display of the data
according to the view section, linking user interface events for
the display to actions described in the controller section, and
rendering the view in a Web browser executing in the
computer.

Appeal 2011-003183
Application 11/396,781

3
The issue
The Examiner rejected claims 27-29 under 35 U.S.C. § 103(a) as
obvious over Ruggier
2
and Little
3
(Ans. 3-5).
The Examiner finds that Ruggier discloses the steps of claim 27,
except that “Ruggier does not explicitly discloses [sic] validating the
document” (Ans. 5). The Examiner finds that “Little discloses determining
from a markup language document whether or not the markup language
conforms to a schema and responsive to the determination, processing the
document as intended (such as with Ruggier) (para. 63). Inherent in using
the tools would be loading the document” (id.).
The Examiner finds it obvious “to validate according to the teachings
of Little, before processing according to Ruggier because it would have
assured correct input (Little, para. 63)” (id.).
Appellant contends that “Ruggier does not provide a teaching directed
to „the retrieval of data from the model section of the markup language
document‟. Rather, in Ruggier, data is retrieved from tables of a database
separate from the markup language of a Web page” (App. Br. 8). Appellant
contends that “[t]hus, Ruggier sets forth a teaching opposite to that claimed
by Appellants in that data is not retrieved from a model section of the
markup language documents, but from a table of a database” (id.).
The issue with respect to this rejection is: Does the evidence of record
support the Examiner‟s conclusion that Ruggier and Little suggest the

2
Ruggier, M., US 2003/0145305 A1, published Jul. 31, 2003.
3
Little et al., US 2003/0048287 A1, published Mar. 13, 2003.
Appeal 2011-003183
Application 11/396,781

4
retrieval of “data from the model section of the markup language document”
as required by claim 27?
Findings of Fact
1. Ruggier teaches a large scale web user interface “designed and
implemented using the widely accepted Model-View-Controller (MVC)
paradigm, which identifies an Interface application as being composed of
three distinct components, namely Views (screens), Controller (event
handler), and the Model (underlying application)” (Ruggier 1 ¶ 0003).
2. Ruggier teaches, regarding the first component, Views, that a
“view is equivalent to a screen or page. The model offers means to describe
what fields are used in a view, how those fields are used by the view (e.g. to
show their values, or to ask the user to provide values), what messages are to
be exchanged, what presentation design is to be used” (Ruggier 4 ¶ 0093).
3. Ruggier teaches, in more detail, that a “View is composed of a
Doc 11, a PageInfo 12, one or more PageParts 13, and associated Actions
(OnLeave 14, OnArrive 15 specify when these are executed). PageParts 13,
are collections of FieldSets 16 (inside of a Form 20), LinkSets 17, as well as
arbitrary XFI 18 (CrossFormat Information) that can mix any rendering code
(e.g. HTML, JS, CSS)” (Ruggier 4 ¶ 0094).
4. Ruggier teaches user interface elements, specifically an “XML
vocabulary to logically describe the views, the data content and the behavior
of a Web User Interface, i.e. an XML vocabulary to specify a UI [user
interface] Description. The UI Description is what enables the possibility to
automate the management of interdependencies between the three MVC
components” (Ruggier 3 ¶ 0074).
Appeal 2011-003183
Application 11/396,781

5
5. Ruggier also teaches user interface elements with
Automation of the mapping of input field data to
object instances of the Data Model used by the underlying
application, for any data exchanges between the User
Interface and the underlying application. This functionality
provides the mapping of the flat-list world of Web form
fields, and the typically hierarchical Data Models (e.g. a
description of the tables of a database) used by underlying
application.

(Ruggier 9 ¶ 0151.)
6. Ruggier teaches that the “XML Model is an XML vocabulary
to logically describe the elements of a Web User Interface, e.g. screens or
views, data sets used in forms, links and their parameters, actions, including
messages exchanged with the underlying application, procedures that define
sequences of screens, etc.” (Ruggier 4 ¶ 0078.)
7. Ruggier teaches that
building a web user interface from a descriptive model adds
the significant advantage that changes in the descriptive
model are automatically reflected in each of these 3 layers,
in the appropriate way for each layer. For example, if the
data set used in a user interface procedure (a sequence of
dynamic pages) is changed, both the user interface logic
(that must handle this data) and the individual dynamic
pages (that must collect or present this data) will
automatically reflect the change as they both get the
information from exactly the same (and unique) source, i.e.
the description of the data set. Thus the integration of
separately maintained presentation, content and logic is
facilitated.

(Ruggier 4 ¶ 0091; emphasis added.)

Appeal 2011-003183
Application 11/396,781

6
8. Ruggier teaches that:
I. The Controller (a server program) processes input
events (in web applications, these are HTTP requests).
II. The Controller determines, using the input event
data as well as results from messages to the underlying
Application Layer, what the next state of the UI should be
(e.g. what is the next view).
III. The Controller invokes the appropriate view,
which displays the required output (in web applications this
is a web page returned as the HTTP response).

(Ruggier 1 ¶¶ 0021-0023.)
9. Ruggier teaches that the “Runtime is able to identify and
retrieve the XML descriptions for the objects involved in each HTTP
request, i.e. views, forms, links, procedures and actions” (Ruggier 8 ¶ 0136).
10. Ruggier teaches that from “these objects, the UI Runtime can
then freely navigate the rest of the User Interface Description to obtain any
other information that it needs to perform the above-mentioned generic
handling of requests” (Ruggier 8 ¶ 0136).
11. Little teaches that:
A Document Type Definition (DTD) is used to
provide formal description of the structure of the XML CLI
description file in terms of XML tags described in FIG. 1. A
DTD is a file (or several files to be used together), which
contains a formal definition of a particular type of document
(e.g., the XML CLI description document). It sets out a
schema of names that can be used for element types, where
they may occur, and how they all fit together. The format of
the DTD is known to one skilled in the art. In one
embodiment, the DTD is used in this invention to provide
notice of what names and structures to be used for XML CLI
description documents. Using the DTD, XML CLI
description documents are ensured to be constructed and
Appeal 2011-003183
Application 11/396,781

7
named in a conformant manner. The DTD not only defines
the valid XML CLI description files, but it can also be used
by the tools to validate any input file before processing or by
editors to assure that edited files conform to the DTD.

(Little 4 ¶ 0063.)
12. The Specification teaches that the
model section 214 contains data that may be explicitly
defined within the document using elements and attributes,
or the data may be explicitly defined within the document
using an external XML format that is embedded within the
document. Alternatively, the model section 214 may
reference externally defined data. The model section 214
may have any number of dataset 224 child elements that
contains explicitly embedded data elements, or a reference
to an external data source.

(Spec. 20 ¶ 33.)
13. The Specification teaches that the “dataset may either be
located within the document as in step 334 or may be located external to
document. Regardless of where the data is located, it is retrieved and the
document is rendered as in step 360” (Spec. 27 ¶ 36).
Principles of Law
“The combination of familiar elements according to known methods
is likely to be obvious when it does no more than yield predictable results.”
KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007). “If a person of
ordinary skill can implement a predictable variation, § 103 likely bars its
patentability.” Id. at 417.

Appeal 2011-003183
Application 11/396,781

8
Analysis
Claim interpretation is at the heart of patent examination because
before a claim is properly interpreted, its scope cannot be compared to the
prior art. In this case, Appellant challenges the Examiner‟s interpretation of
the phrase “retrieving data from the model section of the markup language
document” as recited in Claim 27, arguing that the “Ruggier does not
provide a teaching directed to „the retrieval of data from the model section of
the markup language document‟. Rather, in Ruggier, data is retrieved from
tables of a database separate from the markup language of a Web page”
(App. Br. 8).
During prosecution, claim terms are given their broadest reasonable
interpretation as they would be understood by persons of ordinary skill in the
art in the light of the Specification. Therefore, we first turn to the
Specification to determine whether the meaning of the phrase “retrieving
data from the model section of the markup language document” can be
discerned.
The Specification teaches that the
model section 214 contains data that may be explicitly
defined within the document using elements and attributes,
or the data may be explicitly defined within the document
using an external XML format that is embedded within the
document. Alternatively, the model section 214 may
reference externally defined data. The model section 214
may have any number of dataset 224 child elements that
contains explicitly embedded data elements, or a reference
to an external data source.

(Spec. 20 ¶ 33; FF 12.) The Specification further teaches that the “dataset
may either be located within the document as in step 334 or may be located
Appeal 2011-003183
Application 11/396,781

9
external to document. Regardless of where the data is located, it is retrieved
and the document is rendered as in step 360” (Spec. 27 ¶ 36; FF 13).
While Appellant contends that the Examiner did not apply “the
ordinary meaning of “model section‟ and markup language document‟”
(App. Br. 10), Appellant did not identify any portion of the Specification
which specifically defines these terms or which describes the data structure
of a “model section” or “markup language document” in a way which
excludes a database. Nor has Appellant provided evidence that the ordinary
meaning of the terms “model section” or “markup language document”
excludes the use of a database.
Indeed, the Specification recognizes that the model section may
“reference externally defined data” (Spec. 20 ¶ 33; FF 12) and that the
model section itself may “have any number of dataset 224 child elements
that contains explicitly embedded data elements, or a reference to an
external data source” (Spec. 20 ¶ 33; FF 12). That is, while the Specification
discusses data retrieval from a model section, the Specification provides no
structural or functional requirements which limit the data structure of the
“model section” or limit the “markup language document” to any specific
data organization distinct from a database (see FF 12-13).
In addition, the Examiner finds that “[r]etrieval of data from a
database does not exclude the possibility of retrieving the data in the model
section” (Ans. 5). The Examiner finds that the
tags (such as field, fieldset, etc.) that are located in the model
section as described in the rejection are themselves data. As
described in the rejection above, the XSLT templates on p. 7
query those nodes for data. Therefore, data is retrieved, for
example, from at least the $fieldNode variable, which is a
Appeal 2011-003183
Application 11/396,781

10
node, which is part of the model (called fields)
section

(id. at 5-6).
We find that the Examiner has the better position. Whether the data
retrieval in claim 27 is broadly interpreted to include data retrieval from
databases which serve as the “markup language document” as expressly
taught by Ruggier (FF 5) or whether the Examiner‟s interpretation of
Ruggier‟s code demonstrates retrieval of data from a model section of a
document (Ans. 5-6), Ruggier expressly teaches that the “Runtime is able to
identify and retrieve the XML descriptions for the objects involved in each
HTTP request, i.e. views, forms, links, procedures and actions” (Ruggier 8 ¶
0136; FF 9). Ruggier is teaching retrieval of XML data from a data source
and Ruggier teaches that such a data source includes an XML model
document (FF 6).
Conclusion of Law
The evidence of record supports the Examiner‟s conclusion that
Ruggier and Little suggest the retrieval of “data from the model section of
the markup language document” as required by claim 27.
SUMMARY
In summary, we affirm the rejection of claim 27 under 35 U.S.C. §
103(a) as obvious over Ruggier and Little. Pursuant to 37 C.F.R. §
41.37(c)(1), we also affirm the rejection of claims 28 and 29, as these claims
were not argued separately.

Appeal 2011-003183
Application 11/396,781

11
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a).

AFFIRMED

cdc