Ex Parte Gopalakrishnan

Patent Trial and Appeal Board

Mar 8, 2017

12358439 (P.T.A.B. Mar. 8, 2017)

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.
12/358,439 01/23/2009 Sumathi Gopalakrishnan T9049-19604US01 2515
74739 7590 03/10/2017
MILES & STOCKBRIDGE P.C.
Oracle International Corporation
1751 Pinnacle Drive
Suite 1500
Tysons Corner, VA 22102-3833
EXAMINER
BOURZIK, BRAHIM
ART UNIT PAPER NUMBER
2191
NOTIFICATION DATE DELIVERY MODE
03/10/2017 ELECTRONIC
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.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
Ipdocketing @ Miles S tockbridge. com
bgoldsmith @ miles stockbridge .com
smcvean @ milesstockbridge. com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte SUMATHI GOPALAKRISHNAN
Appeal 2016-007536
Application 12/358,439
Technology Center 2100
Before BRADLEY W. BAUMEISTER, JEREMY J. CURCURI, and
KARA L. SZPONDOWSKI, Administrative Patent Judges.
BAUMEISTER, Administrative Patent Judge.
DECISION ON APPEAL
Appellant appeals under 35 U.S.C. § 134(a) from the Examiner’s
rejections of claims 1, 3, 4, 8, 13, and 17—29. App. Br. 6.1 We have
jurisdiction under 35 U.S.C. § 6(b). We reverse.
1 Rather than repeat the Examiner’s positions and Appellant’s arguments in
their entirety, we refer to the following documents for their respective
details: the Final Action mailed June 19, 2015 (“Final Act.”); the Appeal
Brief filed November 19, 2015 (“App. Br.”); the Examiner’s Answer mailed
June 3, 2016 (“Ans.”); and the Reply Brief filed August 8, 2016 (“Reply
Br.”).
Appeal 2016-007536
Application 12/358,439
STATEMENT OF THE CASE
Appellant describes the present invention as follows:
An embodiment of the present invention is directed to an
optimized [JavaServer Page (JSP)] engine operating under an
optimized JSP lifecycle memory. . . . A JSP page is loaded and
then processed, without generating a .java code file, by parsing
the JSP source code, creating a tree of the parsed JSP source code
at runtime and instantiating a generic servlet to service the
tree. . . . More specifically, JSP Engine 200 maps the parsed JSP
source code to corresponding nodes of an instantiated tree using
tree class definition 300... The parse tree is persisted in memory
and executed on a runtime-basis. . . .
When a subsequent request for the JSP page is received,
JSP engine 200 determines whether reprocessing is necessary
based on, for example, the timestamp of the JSP page. ... If
reprocessing is necessary, the JSP page is loaded and processed
again without generating a .java code file, as described
above. ... If no reprocessing is necessary, the generic servlet
executes the tree in memory at runtime by traversing nodes of
the tree and executing the parsed JSP source code mapped to
each node.... More specifically, the generic servlet traverses the
tree and calls the execute() function of each node at runtime. . .
The result is a JSP engine that operates faster and more
efficiently by obviating the need to recompile Java code.
App. Br. 5 (internal citations omitted).
Independent claim 1, reproduced below with emphasis added, is
illustrative of the appealed claims:
1. A computer-based method for servicing JavaServer Pages
(JSPs), comprising:
receiving a request for a JSP page with JSP source code;
processing the JSP page without generating a .java code
file, including:
parsing the JSP source code for the JSP page,
2
Appeal 2016-007536
Application 12/358,439
creating a tree of parsed JSP source code at runtime
by mapping each portion of the parsed JSP source code to
a corresponding node of the tree using a tree class
definition,
persisting the tree in a memory, and
instantiating a generic servlet;
executing the tree in the memory at runtime, using the
generic servlet, including:
traversing the nodes of the tree, and
executing the portion of the parsed JSP source code
mapped to each node of the tree;
returning the requested JSP page; and
in response to receiving a subsequent request for the JSP
page, executing the tree in the memory at runtime without
processing the JSP page.
Claims 1,8, and 13 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Dulepet (US 7,316,003 Bl; issued Jan. 1, 2008) and
O’Rourke (US 7,117,436 Bl; issued Oct. 3, 2006). Final Act. 13.
Claims 3, 4, 17, 18, and 19—29 stand rejected under 35 U.S.C.
§ 103(a) as being unpatentable over Dulepet, O’Rourke, and Claussen
(US 6,675,354 Bl; issued Jan. 6, 2004). Final Act. 18.
We review the appealed rejections for error based upon the issues
identified by Appellant, and in light of the arguments and evidence produced
thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential).
FINDINGS AND CONTENTIONS
The Examiner finds that Dulepet discloses every limitation of
independent claim 1, except for teaching “in response to receiving a
subsequent request for the JSP page, executing the tree in the memory at run
3
Appeal 2016-007536
Application 12/358,439
[time] without processing the JSP page.” Final Act. 16. The Examiner
further finds that O’Rourke teaches this missing limitation and that
motivation existed to modify Dulepet with O’Rourke’s teachings. Id. 16—17.
In finding that Dulepet teaches the various claim limitations, the
Examiner broadly interprets the claim language “processing the JSP without
generating a .java code file,” to mean that the claimed method for servicing
JavaServer Pages entails initially compiling the JSP page to generate a .java
code file when the first request for a JSP page is received, but that the
claimed method does not entail re-compiling the JSP page subsequent times.
Final Act. 2—6; Ans. 2—6. The Examiner adopts this construction based upon
the conclusion that such an interpretation is consistent with Appellant’s
Specification. See, e.g., Final Act. 5 (reasoning that “[Appellant’s
Specification emphasize[s] that java code is generated and compiled for the
JSP page, but the optimized JSP container can avoid recompilation/re­
generation (fig. 4) of the java code each time the same JSP page is
requested”).
Appellant asserts that the Examiner is misinterpreting Appellant’s
Specification and that the Specification does not disclose compiling the JSP
page. App. Br. 6—7. More particularly, Appellant urges that the first two
sentences of paragraph 16 of the Specification describe how compiling is
undertaken in the prior art—not in the present invention. And in contrast,
Appellant continues, the next two sentences of that paragraph explain how
an optimized JSP engine of the present invention processes a JSP page
without compiling the JSP page (or “without generating a .java code file).”
App. Br. 6. Appellant summarizes
4
Appeal 2016-007536
Application 12/358,439
The reason why the present invention does not generate a
.java file for each JSP page is clearly described in Paragraph
0026 of the Specification: “when JSP engine 200 parses this JSP
code, tree class 300 is used to map the code to nodes of an
instantiated tree.” In other words, the present invention
advantageously avoids traditional compilation of a JSP page into
a .java file because the JSP source code is mapped directly into
an instantiated tree using a tree class definition.
Id. at 7.
Appellant further contends that Dulepet does not teach, inter alia, the
claim requirement of “processing the JSP page without generating a .java
code file” because Dulepet expressly discloses compiling JSP pages. See,
e.g., id. at 7 (citing Dulepet col. 12,11. 26-43).
ANALYSIS
Paragraph 16 of Appellant’s Specification reads, in relevant part, as
follows:
DETAILED DESCRIPTION
[0016] Typically the lifecycle of a JSP page includes
loading the JSP page, parsing the JSP page code, generating a
.java code file, and executing Java .class file. Because of the
dynamic nature of JSP pages, JSP page code must often be
recompiled. An embodiment is directed to an optimized JSP
engine operating under an optimized JSP lifecycle model. In this
embodiment, the JSP page is loaded, the JSP source code is
parsed, and a parse tree of the JSP source code is created. That
parse tree may then be persisted in memory and executed on a
runtime-basis. The result is a JSP engine that operates faster and
more efficiently by obviating the need to recompile Java code.
Spec. ]fl6.
When read in isolation, some ambiguity arguably might exist as to
whether the word “typically” should be interpreted to mean typically in the
5
Appeal 2016-007536
Application 12/358,439
prior art or typically in the present invention. However, reading paragraph
16 within the context of the Specification as a whole, Appellant’s proffered
interpretation of their Specification—and not the Examiner’s—is the only
reasonable interpretation. That is, Appellant’s Specification, read as a
whole, indicates that the prior art entailed generating a .java code file to
compile the Java code. E.g., Spec. 2—7. But in contrast, Appellant’s
invention entails obviating the need to do so. E.g., Spec. 128 (“[As a result
of employing the present invention], tag handlers setter methods need not be
called repeatedly, and no .java file is generated file for each JSP file. By
maintaining in-memory cache objects instead, a tree of tag instances is
created and traversed during page execution at runtime”) (emphasis added);
see also, e.g., id. H 8, 16, 21, and 22.
Moreover, even assuming, solely for the sake of argument, that the
Examiner were correct in concluding that Appellant’s Specification
indicated that the inventive process entails compiling the Java code initially,
such a conclusion would not be a proper basis to re-interpret the claims in a
manner that ignores the express claim language “processing the JSP without
generating a .java code file.” If the Examiner were of the opinion that the
unambiguous claim language differs from what is supported by Appellant’s
written Specification, the appropriate action would be to issue a rejection
under 35 U.S.C. § 112(a) / § 112,11, for the claims lacking sufficient
written description in the Specification.2
Turning to the cited art, we are persuaded that the Examiner has failed
to establish a prima facie case of obviousness. The rejection is not based on
2 We are not suggesting that a written-description rejection would be
appropriate in the present situation.
6
Appeal 2016-007536
Application 12/358,439
the theory that Dulepet processes the JSP page without generating an initial
.java code file. See Ans. 15—19. To the contrary, the Examiner explains that
Dulepet satisfies the disputed claim limitation by virtue of not re-compiling
subsequent requests for the JSP page after the initial generation of the Java
code. Ans. 18—19. In fact, the Examiner cites a passage of Dulepet that
expressly teaches compiling the Java code. See Dulepet col. 12,11. 26—28
(“The JSP container may convert each JSP element in the source code into a
Java servlet, and may compile the servlet before executing it and/or the JSP
element”) (emphasis added), cited in Final Act. 16.
For the foregoing reasons, we will not sustain the obviousness
rejections of claims 1, 3, 4, 8, 13, 17, 18, and 19—29. Each of independent
claims 1, 8, and 13 sets forth the requirement of processing the JSP page
without generating a .java code file. With respect to the remaining rejection
of dependent claims 3, 4, 17, 18, and 19—29, the Examiner’s reliance on
Claussen does not cure the deficiency of the obviousness rejection over
Dulepet and O’Rourke, explained above.
DECISION
The Examiner’s decision rejecting claims 1, 3, 4, 8, 13, and 17—29 is
reversed.
REVERSED
7