Ex Parte Hopkins et al

Board of Patent Appeals and Interferences

Jun 5, 2009

10227519 (B.P.A.I. Jun. 5, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte KENNETH MARSHALL HOPKINS,
THOMAS GIRARD LENDACKY, DAVID RAYMOND POSH, and
KURT RUSSELL TAYLOR
____________

Appeal 2009-000775
Application 10/227,5191
Technology Center 2100
____________

Decided: 2 June 5, 2009
____________

Before JOSEPH L. DIXON, ST. JOHN COURTENAY III, and
CAROLYN D. THOMAS, Administrative Patent Judges.

C. THOMAS, Administrative Patent Judge.

DECISION ON APPEAL

1 Application filed August 22, 2002. The real party in interest is
International Business Machines Corporation.
2 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, begins to run from the decided date
shown on this page of the decision. The time period does not run from the
Mail Date (paper delivery) or Notification Date (electronic delivery).

Appeal 2009-000775
Application 10/227,519

2
I. STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from a final rejection
of claims 1, 3-6, 13, and 15-22 mailed October 10, 2006, which are all the
claims remaining in the application, as claims 2, 7-12, and 14 are cancelled.
We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

A. INVENTION
Appellants invented method and computer readable medium for
dynamically generating code within a server computer system to process
contents input into an input field in a form. (Spec. 26, Abstract.)

B. ILLUSTRATIVE CLAIM
The appeal contains claims 1, 3-6, 13, and 15-22. Claims 1, 13, and
19 are independent claims. Claim 1 is illustrative:
1. A method in a data processing system including a server
computer system and a client computer system coupled together, said
method comprising the steps of:
receiving within said client computer system contents
input into an input field that is included within a form, wherein said
form includes a definition of a descriptor variable that defines said
input field, and wherein said descriptor variable is a hidden variable
within said form;
transmitting said form that includes said definition of
said descriptor variable from said client computer to said server
computer system;
dynamically generating software code by said server
computer system utilizing said definition of said descriptor variable to
process said contents, wherein said software code is generated only in
Appeal 2009-000775
Application 10/227,519

3
response to a receipt of said form and is not generated before said
receipt; and
returning a result from said server computer system to
said client computer system after said server computer system
processes said contents.

C. REFERENCES
The references relied upon by the Examiner as evidence in rejecting
the claims on appeal are as follows:
Scholz US 2003/0078949 A1 Apr. 24, 2003

Greyware Automation Products, Inc., Comments Overview, pp. 1-17
(Jun. 21, 2002) available at
http://web.archive.org/web/20020621021815/http://www.greyware.com/soft
ware/comments/index.asp?PrinterFriendly=True (hereafter referred to as
“CommentsSW”).

D. REJECTION
The Examiner entered the following rejection which is before us for
review:
Claims 1, 3-6, 13, and 15-22 are rejected under 35 U.S.C. § 103(a) as
being unpatentable over Scholz in view of CommentsSW.

II. PROSECUTION HISTORY
Appellants appealed from the Final Rejection and filed an Appeal
Brief (App. Br.) on March 11, 2007. The Examiner mailed an Examiner’s
Answer (Ans.) on July 19, 2007. No Reply Brief is found in the record.

Appeal 2009-000775
Application 10/227,519

4
III. FINDINGS OF FACT
The following findings of fact (FF) are supported by a preponderance
of the evidence.

Scholz
1. Scholz discloses that “[u]pon receiving the requests, the server
system 106 processes the requests and returns replies to the clients 102 over
the network(s) 104.” (¶ [0021].)
2. Scholz discloses:
Users are able to input requests to an application via a user
interface that presents one or more forms to the user, each form
having one or more data input fields . . . . For many forms, the
application developer desires to place restrictions on the data
that can be input to the fields of the form. An automatic input
validation technique is used that allows forms with input fields
to be automatically generated to include input validation for one
or more of the input fields. . . . The form itself includes the
validation code and thus performs the validation at the client
(referred to as client-side validation).

(¶ [0092].)
3. Scholz discloses that “[t]his results in the form, with the
automatically generated input validation, being generated prior to
distribution to customers and/or users.” (¶ [0093].)
4. Scholz discloses:
Alternatively, the automatic input validation technique could be
implemented as part of a data input process (e.g., as part of the
presentation layer 212 or the business logic layer 204 of FIG.
2). In this implementation, when a user makes a request for
which the application presents a form for user input, the
Appeal 2009-000775
Application 10/227,519

5
automatic input validation technique may be used to generate a
form “on the fly” for presentation to the user.

(¶ [0093].)
5. Scholz discloses that “[o]nce the user has entered both [name and
password], he or she can actuate the submit button 706 to proceed with the
log on process.” (¶ [0094].)
6. Scholz discloses that “[i]n order to place such restrictions on the
fields 702 and 704, the designer of the form 700 writes a form definition
(also referred to as source code) for the form (e.g., in text markup language)
using a set of custom auto-validation tags.” (¶ [0095].)
7. Scholz discloses that “[t]he built-in validation function is created
automatically based on the tags present in the form, and the properties set for
these tags.” (¶ [0121].)
8. Scholz discloses that “some or all of the client-side executable
code could be replace with code to be executed at a server(s).” (¶ [0174].)

IV. PRINCIPLES OF LAW
“What matters is the objective reach of the claim. If the claim extends
to what is obvious, it is invalid under § 103.” KSR Int’l Co. v. Teleflex, Inc.,
550 U.S. 398, 419 (2007). To be nonobvious, an improvement must be
“more than the predictable use of prior art elements according to their
established functions.” Id. at 417.
Appellants have the burden on appeal to the Board to demonstrate
error in the Examiner’s position. See In re Kahn, 441 F.3d 977, 985-86
(Fed. Cir. 2006) (“On appeal to the Board, an applicant can overcome a
Appeal 2009-000775
Application 10/227,519

6
rejection [under § 103] by showing insufficient evidence of prima facie
obviousness or by rebutting the prima facie case with evidence of secondary
indicia of nonobviousness.”) (quoting In re Rouffet, 149 F.3d 1350, 1355
(Fed. Cir. 1998)). Therefore, we look to Appellants’ Brief to show error in
the proffered prima facie case. Only those arguments actually made by
Appellants have been considered in this decision. Arguments which
Appellants could have made but chose not to make in the Brief has not been
considered and are deemed to be waived. See 37 C.F.R. § 41.37(c)(1)(vii).

V. ANALYSIS
Grouping of Claims
In the Brief, Appellants argue claims 1, 3-6, 13, and 15-22 as a group
(App. Br. 11-18). For claims 3-6, 13, and 15-22, Appellants repeat the same
argument made for claim 1. We will, therefore, treat claims 3-6, 13, and 15-
22 as standing or falling with claim 1. See 37 C.F.R. § 41.37(c)(1)(vii). See
also In re Young, 927 F.2d 588, 590 (Fed. Cir. 1991).

The Obviousness Rejection
We now consider the Examiner’s rejection of the claims under 35
U.S.C. § 103(a).

Appellants contend that “the present invention dynamically generates
code at a server device to process the contents of input fields using
descriptor variable definitions contained within the form, itself. Scholz
instead teaches that validation code is generated at a client device to validate
Appeal 2009-000775
Application 10/227,519

7
user input within restricted input fields by using added execution code.”
(App. Br. 14.) Appellants further contend that “Scholz teaches that the form
is processed at the server device by using pre-written, application-specific
business logic.” (Id. at 14-15.)
The Examiner found that Scholz discloses “automatic form
generation, in the context of paragraph [0093], discussing form generation
‘on the fly’” (Ans. 6).
Issue: Have Appellants shown that the Examiner erred in finding that
Scholz discloses “dynamically generating software code by said server . . . ,
wherein said software code is generated only in response to a receipt of said
form and is not generated before said receipt”?

Scholz discloses that a server receives requests from clients, processes
the requests, and returns replies to the clients based thereon (FF 1). The
requests in Scholz can be in any form, including a form (Scholz, (¶ [0022]).
In Scholz, a server application presents automatically generated forms,
having restricted input fields, to a user whereby the forms themselves
include validation code for validating the input (FF 2). In other words, in
Scholz forms are sent to the user including client-side validation mechanism
in them. Thus, the forms with validation code, in Scholz, are generated at
the server prior to distribution to the customers/users (FF 3-4). The client-
side then executes the validation code to verify the inputs. Once the user has
entered valid content into the input fields of the form, the user can then
submit the form to the server who processes the form (FF 5 and FF 1).
Appeal 2009-000775
Application 10/227,519

8
Claim 1, for example, requires “dynamically generating software code
by said server computer system utilizing said definition of said descriptor
variable to process said contents, wherein said software code is generated
only in response to a receipt of said form and is not generated before said
receipt.” In other words, claim 1 requires that the form is first received from
the client to the server, then the server dynamically generates code to
process the form, using descriptor variable definitions in the form. The
Examiner found that “[p]rocessing the contents of input fields is the primary
function of form processing [and] ‘[d]escriptor variable definitions’ are
merely variables associated with form field entries, and must perforce be
contained within the form itself and processed” (Ans. 15). We agree.
Although, as noted supra, Scholz discloses an embodiment that
creates forms with descriptor variable definitions at the server, contents are
entered into the forms at the client-side (FF 5). Thereafter, the forms are
transmitted back to the server, whereby the forms are processed.
For example, Scholz discloses that form definitions, using a set of
custom auto-validation tags, are included in the form (FF 6). Scholz further
discloses that the validation function (i.e., code) is created based on tags
present in the form and the properties set for the tags (FF 7), and that some
or all of client-side executable code, i.e., the validation function, could be
executed at the server (FF 8). In other words, instead of the client-side,
Scholz discloses the ability of the server to create validation code upon
receiving a form with tags, and hence processing the inputted content. Thus,
Scholz’s server ability to process forms by creating validation code based on
Appeal 2009-000775
Application 10/227,519

9
custom-tags from the client’s form is consistent with Appellants’
dynamically generating code by the server to process the forms.
As for the CommentsSW reference, Appellants merely argue that this
reference also does not teach or suggest “dynamically generating software
code” (App. Br. 17). Given that we have found that Scholz discloses the
disputed feature, we find this argument unpersuasive.
Thus, Appellants have not persuaded us of error in the Examiner’s
conclusion of obviousness for representative claim 1. Therefore, we affirm
the Examiner’s § 103 rejection of independent claim 1 and of claims 3-6, 13,
and 15-22, which fall therewith.

VI. CONCLUSIONS
We conclude that Appellants have not shown that the Examiner erred
in rejecting claims 1, 3-6, 13, and 15-22.
Thus, claims 1, 3-6, 13, and 15-22 are not patentable.

VII. DECISION
In view of the foregoing discussion, we affirm the Examiner’s
rejection of claims 1, 3-6, 13, and 15-22.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv) (2007).

AFFIRMED

Appeal 2009-000775
Application 10/227,519

10

msc

IBM CORP (YA)
C/O YEE & ASSOCIATES PC
P.O. BOX 802333
DALLAS TX 75380