Ex Parte Elkady et al

Patent Trial and Appeal Board

Jul 29, 2013

10733102 (P.T.A.B. Jul. 29, 2013)

UNITED STATES PATENT AND TRADEMARKOFFICE
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.
10/733,102 12/10/2003 Osama Elkady 50277-2319 9183
42425 7590 07/30/2013
HICKMAN PALERMO TRUONG BECKER BINGHAMWONG/ORACLE
1 Almaden Boulevard
Floor 12
SAN JOSE, CA 95113
EXAMINER
MCLEAN, NEIL R
ART UNIT PAPER NUMBER
2671
MAIL DATE DELIVERY MODE
07/30/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 OSAMA ELKADY and TOMOJI ASHITANI1
__________

Appeal 2011-005141
Application 10/733,102
Technology Center 2600
__________

Before DONALD E. ADAMS, ERIC GRIMES, and ULRIKE W. JENKS,
Administrative Patent Judges.

GRIMES, Administrative Patent Judge.

DECISION ON APPEAL
This is an appeal under 35 U.S.C. § 134 involving claims relating to a
merge utility for merging two documents in different formats, which have
been rejected for obviousness. We have jurisdiction under 35 U.S.C. § 6(b).
We reverse.

1 Appellants identify the Real Party in Interest as Oracle International
Corporation (Appeal Br. 1).
Appeal 2011-005141
Application 10/733,102

2
STATEMENT OF THE CASE
The Specification discloses what it describes as “an improved
mechanism for overlaying text onto background templates” (Spec. 3, ¶ 8).
“For example, a merge utility conversion engine may convert an overlay
input data file into a Standard Printing and Imaging Format (SPIF), such as a
Page Description Language (PDL) [or] a file formatted in the Printer Control
Language (PCL)” (id. at 6, ¶ 17). A “format, such as SPIF, that can easily
be handled by a variety of output devices” is referred to as a merge format
(id. at 8, ¶ 23).
Claims 1-29 and 31 are on appeal. Claim 1 is illustrative and reads as
follows (emphasis added):
1. A method comprising:
receiving, at a merge utility executing on a computer system, a
request to merge a first merge document in a merge format with
a second document in an original format;
wherein the second document was created in said original format by a
first document authoring application;
in response to the request, the merge utility causing the second
document to be converted from the original format to the merge
format to create a second merge document;
wherein the second merge document is in the merge format;
wherein the step of converting is performed by either the merge utility
or the first document authoring application;
the merge utility merging the first merge document and the second
merge document to generate a composite merge document; and
after generating the composite merge document, the merge utility
causing said composite merge document to be delivered to an
output device;
wherein the output device is a device that is different from the
computer system;
wherein the original format is a format that is not supported by the
output device, and therefore needs to be converted to another
Appeal 2011-005141
Application 10/733,102

3
format that is supported by the output device in order to be
properly interpreted by the output device; and
wherein the merge format is a format that is supported by the output
device, and therefore does not need to be converted to another
format that is supported by the output device in order to be
properly interpreted by the output device;
wherein the method is performed by one or more computing devices.

The Examiner has rejected all of the claims on appeal under 35 U.S.C.
§ 103(a) as obvious based on Barry2 and Schwier3 (Answer 3). The
Examiner finds that Barry discloses, among other things, “receiving, at a
merge utility (Figure 8: Summing Junction 804) executing on a computer
system (e.g., Workstation), a request to merge (In order to merge the system
must receive a merge command/request from the browser or program code)
a first merge document (802 PDL in) with a second document (New PDL
Info 806)” (id. at 4). The Examiner acknowledges that “Barry does not
disclose expressly a document in an original format . . . [or] in response to
the request, causing the second document to be converted from the original
format to the merge format to create a second merge document” (id. at 5).
The Examiner finds that “Schwier discloses a document in an original
format (Figure 6; Winword document 35) . . . [and] in response to the
request . . . causing the second document to be converted from the original
format to the merge format to create a second merge document (Document
converted to PCL format; Column 8, lines 13-14)” (id.). The Examiner
concludes that “it would have been obvious to a person of ordinary skill in
the art to convert a document from e.g. Word for Windows format to PCL or

2 Barry et al., US 7,099,027 B1, issued Aug. 29, 2006.
3 Schwier et al., US 7,202,972 B1, issued Apr. 10, 2007.
Appeal 2011-005141
Application 10/733,102

4
Postscript prior to merging that document with another PCL or Postscript
formatted document” (id. at 6).
Appellants argue that “Barry’s summing junction box 804 . . . does
not receive a ‘request’ within the meaning of Claim 1. Rather, the alleged
merge utility responds to a request to merge two documents that are already
in a merge format, e.g. Barry at FIG. 8 (showing both inputs to be PDL)”
(Appeal Br. 7). Appellants argue that Schwier does not make up for this
deficiency, because the only requests to merge documents described in
Schwier involve inputs that are both in an original format (id.) and both
inputs to Schwier’s printer are already in a merge format (id.).
We agree with Appellants that the Examiner has not shown that the
cited references disclose or would have made obvious a merge utility that
receives “a request to merge a first merge document in a merge format with
a second document in an original format,” as recited in claim 1. Claim 15,
the only other independent claim on appeal, is directed to a machine-
readable storage medium storing instructions that cause a processor to
“receiv[e], at a merge utility executing on a computer system, a request to
merge a first merge document in a merge format with a second document in
an original format” (Appeal Br. 19 (Claims Appendix)).
The Examiner points to summing junction 804 in Barry’s Figure 8 as
corresponding to the “merge utility” of the claims (Answer 4). Barry’s
Figure 8 is reproduced below:

Appeal 2011-005141
Application 10/733,102

5
Figure 8 shows a block diagram of an embodiment of Barry’s
invention where information is inserted into a PDL print job (Barry, col. 1,
ll. 45-54; col. 2, ll. 17-19). Barry states that the “summing junction 804 is
operable to sum new PDL information or merge new PDL information from
a block 806 with the original PDL input job,” provided in block 802 (id. at
col. 13, ll. 13-16). Thus, Barry’s summing junction 804 does not receive a
request to merge two documents in different formats.
The Examiner points to Schwier’s Figure 6, and the description of it,
as disclosing conversion of a document in original format to merge format in
response to a request (Answer 5). Schwier’s Figure 6 is reproduced below:

Appeal 2011-005141
Application 10/733,102

6
Figure 6 “shows how an auxiliary information can be linked into an
existing document” (Schwier, col. 7, ll. 63-64). Schwier states that a “macro
36 that contains an external data source 37 is linked into the Winword
document 35” at event 38 (id. at col. 7, l. 66 to col. 8, l. 4). “A print data
stream 39 is generated therefrom, whereby the individual pages 39a, 39b and
39c are provided with the respective reference index macro data M1, M2,
M3,” which indicate which graphical data is to be inserted and where (id. at
col. 8, ll. 6-12). Schwier states that:
These information (reference index data M1, M2, M3)
are converted into the PCL language and are sent to the printer
device 7. Simultaneously, the macro information (particularly
graphics data) are converted (insofar as they are not already in
PCL format) and are transmitted into the printer device 7
separated from the series letter information, i.e. separated from
the series print data stream in terms of time and/or in data-
oriented fashion, and are deposited in the main memory 8
thereat.
(Id. at col. 8, ll. 13-21.)
Thus, Schwier describes the separate conversion of the reference
index data and the graphics data to PCL format, and the separate
transmission of those two sets of data to the printer, before the two sets of
data (already in PCL format) are merged to generate a composite merge
document in the printer. We agree with Appellants (Appeal Br. 7) that the
Examiner has not shown that Schwier describes a merge utility that receives
a request to merge two documents in different formats and responds to the
request by causing a document in original format to be converted to a merge
format.
Appeal 2011-005141
Application 10/733,102

7
The Examiner responded that “Applicant appears to be tacitly
acknowledging this limitation in the Barry reference” (Answer 13).
Appellants have made clear, however, that while Barry discloses a “request
to merge,” their argument is that “Barry does not teach or suggest ‘a request
to merge a first merge document in a merge format with a second document
in an original format,’ as recited in Claim 1” (Reply Br. 4).
For the reasons discussed above, we agree with Appellants’ position.
The Examiner has not persuasively shown that this limitation, which is
missing from Barry, would have been obvious based on the combined
disclosures of Barry and Schwier. We therefore reverse the rejection on
appeal.
SUMMARY
We reverse the rejection of claims 1-29 and 31 under 35 U.S.C.
§ 103(a).

REVERSED

dm