Ex Parte Rostampour

Patent Trial and Appeal Board

Jun 26, 2014

11259843 (P.T.A.B. Jun. 26, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte ARAD ROSTAMPOUR
____________

Appeal 2011-002355
Application 11/259,843
Technology Center 2100
____________

Before MAHSHID D. SAADAT, JOHN A. EVANS, and
MINN CHUNG, Administrative Patent Judges.

CHUNG, Administrative Patent Judge.

DECISION ON APPEAL
Appellant appeals under 35 U.S.C. § 134(a) from a final rejection of
claims 1-30. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM-IN-PART.

STATEMENT OF THE CASE
Appellant’s invention relates to modifying firmware in a computer
system. (See Spec. 3:27-31.) More specifically, the invention relates to
modifying a firmware implementation underlying a firmware interface
without changing the firmware image stored on a non-volatile memory
device. (See Spec. 3:27–4:22.) Claim 1, which is illustrative, reads as
follows:
Appeal 2011-002355
Application 11/259,843

2
1. A method comprising
during booting, creating a volatile firmware-based image
in memory based on original firmware code in non-volatile
memory;
during runtime, modifying said firmware-based image so
as to alter its appearance to an operating system without
modifying said original firmware code in non-volatile memory;
and
having an operating system interact with the modified
firmware-based image in memory while said original firmware
code in non-volatile memory remains unmodified.

The Examiner relies on the following prior art in rejecting the claims:
Rothman (“Rothman-1”) US 2004/0230963 A1 Nov. 18, 2004
Zimmer US 2005/0076196 A1 Apr. 7, 2005
Rothman (“Rothman-2”) US 7,194,612 B2 Mar. 20, 2007

Claims 1-20 and 22-25 stand rejected under 35 U.S.C. § 103(a) as
being unpatentable over Rothman-1 and Rothman-2. (Ans. 3.)
Claims 21 and 26-30 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Rothman-1, Rothman-2, and Zimmer. (Ans. 14.)

Appeal 2011-002355
Application 11/259,843

3
ISSUES
Independent Claims 1, 13, and 26
Appellant argues on pages RB-19 to RB-31 and RB-34 to RB-36 of
the Reply Brief 1 that the Examiner’s rejection of independent claims 1 and
13 is in error. The dispositive issues presented by these arguments are as
follows:
1-a) Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches modifying a firmware-based image
during runtime without modifying original firmware code in non-
volatile memory?
1-b) Did the Examiner err in finding one skilled in the art would have
combined the teachings of Rothman-1 and Rothman-2?
1-c) Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches an operating system interacting with the
modified firmware-based image in memory?
1-d) Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches modifying a firmware-based image “so
as to alter its appearance to an operating system” as recited by
claims 1 and 13?
Appellant’s arguments directed to independent claim 26 present
similar issues as claim 1.

1 Appellant represents that the Reply Brief filed on August 26, 2010 is “in
the form of a replacement Appeal Brief to provide a single merged
document for review on Appeal.” (Reply Br. RB-1.) Accordingly, the
Appeal Brief filed on March 26, 2010 is not considered for this appeal.
Appeal 2011-002355
Application 11/259,843

4
Claims 3, 6, and 22-25
Appellant argues on pages RB-32 to RB-34 of the Reply Brief that the
Examiner’s rejection of claims 3 and 6 is in error. The dispositive issues
presented by these arguments are as follows:
2-a) Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches changing static table data in a memory
location?
2-b) Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches inserting new runtime instruction
entrypoints into a memory location?
Appellant’s arguments on pages RB-38 to RB-40 of the Reply Brief
directed to independent claim 22 present similar issues as claims 1, 3, and 6.

Claim 20
Appellant argues on pages RB-36 to RB-37 of the Reply Brief that the
Examiner’s rejection of claim 20 is in error. The dispositive issue presented
by these arguments is as follows:
Did the Examiner err in finding the combination of Rothman-1
and Rothman-2 teaches “add[ing] a subordinate runtime service that
describes a device not known to a firmware image on a system but
useable by a particular OS” as recited in claim 20?

ANALYSIS
We have reviewed Appellant’s arguments in the Reply Brief /
replacement Appeal Brief, the Examiner’s rejection, and the Examiner’s
response to the Appellant’s arguments. We disagree with Appellant’s
Appeal 2011-002355
Application 11/259,843

5
conclusion that the Examiner erred in rejecting claims 1-19 and 21-30 but
agree with Appellant’s conclusion that the Examiner erred in rejecting claim
20.

Independent Claims 1, 13, and 26
In rejecting claims 1 and 13 over the combination of Rothman-1 and
Rothman-2, the Examiner finds that Rothman-1 discloses all of the claimed
features except for the feature of not modifying original firmware code in
non-volatile memory, for which the Examiner relies upon Rothman-2. (See
Ans. 3-4.)
Issue 1-a
Appellant contends that neither Rothman-1 nor Rothman-2 discloses
modifying a volatile firmware-based image during runtime. (Reply Br. RB-
20, ¶ 14.) In particular, Appellant asserts that paragraph 24 of Rothman-1
cited by the Examiner teaches modifying environmental variables but does
not teach that the environmental variables are part of a firmware-based
image. (Reply Br. RB-24, ¶ 16.03.) We are not persuaded by Appellant’s
arguments and agree with the Examiner’s finding that paragraph 24 of
Rothman-1 describing the EFI Variable Services teaches modifying a
firmware-based image during runtime. (See Ans. 3.) We note that
Rothman-1 provides further description of the EFI Variable Services and
modifying a firmware-based image in memory during runtime by utilizing
the Variable Services. (See, e.g., Rothman-1 ¶¶ 40-44, Figs. 3, 4 (describing
Appeal 2011-002355
Application 11/259,843

6
modifying a firmware-based image (e.g., constructing an “update image”) in
memory buffer during runtime via the Variable Services).) 2
As noted above, the Examiner relies upon Rothman-2 for teaching the
feature of not modifying original firmware code in non-volatile memory.
(See Ans. 4, 24.) In particular, the Examiner finds that Rothman-2 teaches
modifying the appearance of a firmware-based image without modifying the
original firmware code in non-volatile memory. (See Ans. 24, citing
Rothman-2 col. 2, ll. 44-56; col. 3, l. 59–col. 4, l. 27.) Appellant does not
dispute the Examiner’s findings or contend that the cited passages of
Rothman-2 do not teach the disputed features. Instead, Appellant argues that
the passages cited by the Examiner do not address the issue of whether the
firmware code is modified because Rothman-2 “does not preclude
modification of a firmware code.” (See Reply Br. RB-26, ¶ 18; see also
Reply Br. RB-28–29, ¶¶ 18.03, 19.) Appellant’s arguments are unpersuasive
as they do not refute the Examiner’s findings and do not address the question
of whether Rothman-2 teaches the disputed features. We agree with the
Examiner that the cited passages of Rothman-2 teach the feature of not
modifying original firmware code in non-volatile memory.

2 We also observe that Appellant’s Specification describes the same EFI
Variable Services as a mechanism to modify a firmware-based image during
runtime. (See Spec. 6:31–7:9 (“As the reader will appreciate the [EFI]
entrypoints are the access mechanism to associated boot and/or runtime
services, e.g., GetVariable and/or SetVariable. According to various
embodiments, the program instructions can execute to patch the EFI tables
and/or filter the EFI entrypoints 244.”) (emphases added); see also Spec.
9:16-19 (“[T]hese program instructions are executed to patch a table in a
particular interface (e.g., EFI, SAL, PAL, ACPI interface, etc.) in order to
modify the firmware implementation underlying the interface.”) (emphasis
added).)
Appeal 2011-002355
Application 11/259,843

7
With respect to Appellant’s argument that Rothman-2 fails to teach
“during runtime, modifying [a] firmware-based image” (Reply Br. RB-27, ¶
18.01), for which the Examiner relies upon Rothman-1, we agree with the
Examiner’s reliance on In re Keller, 642 F.2d 413 (CCPA 1981) and In re
Merck & Co. Inc., 800 F.2d 1091 (Fed. Cir. 1986) (Ans. 23-24) and further
note that nonobviousness cannot be established by attacking the references
individually when the rejection is predicated upon a combination of prior art
disclosures. See Merck, 800 F.2d at 1097.

Issue 1-b
Appellant further contends that the purpose of Rothman-1 is to update
firmware image code in non-volatile memory and that a skilled artisan
therefore would not be motivated to modify Rothman-1 (by combining with
Rothman-2) to achieve the feature of not modifying original firmware code
in non-volatile memory since such a result would “defeat Rothman-1’s
purpose of updating firmware image code [in non-volatile memory].” (See
Reply Br. RB-19, ¶ 13; see also Reply Br. RB-22, 25, ¶¶ 16, 17.) In
response, the Examiner explains that the purpose considered by Rothman-1
is to update firmware during operating system runtime operations. (Ans. 22,
citing Rothman-1 ¶ 5.) Rothman-1 describes a two-phase update process
where during the first, runtime phase an update firmware image is
constructed in memory buffer (see Rothman-1 ¶¶ 40-44), and during the
second phase following system restart the firmware code in non-volatile
memory is updated by writing the update firmware image to the non-volatile
Appeal 2011-002355
Application 11/259,843

8
memory during the pre-boot operation (see Rothman-1 ¶¶ 50, 55).3 In
rejecting claims 1 and 13, the Examiner relies largely upon the teachings of
the runtime operation of Rothman-1. (See Ans. 3-4, 9, 19-27, 30.) Hence,
with agree with the Examiner that the purpose considered by the cited
passages of Rothman-1 is to update firmware during operating system
runtime operations. Appellant’s argument is not persuasive as it ignores the
teachings of the runtime embodiment of Rothman-1 which are relied upon
by the Examiner.
Appellant also asserts that Rothman-2 provides no motivation for the
proposed combination with Rothman-1 because Rothman-2 does not teach
any advantage of not modifying the original firmware code in non-volatile
memory or any disadvantage in modifying the firmware. (See Reply Br.
RB-26, 28, ¶¶ 18, 18.03, 19.) In response, the Examiner explains that an
advantage of the method of Rothman-2 is to “provide a means by which one
may be able to provide access to firmware data in the OS runtime” and
Rothman-2’s contemplated purpose is to provide masked firmware services
(i.e., modified firmware implementation) without modifying firmware in
non-volatile memory. (See Ans. 23, citing Rothman-2, col. 2, ll. 15-55.)
Hence, one of ordinary skill in the art would have appreciated that, by

3 Claims 1 and 13 recite “during runtime, modifying said firmware-based
image . . . without modifying said original firmware code in non-volatile
memory.” We observe that the original firmware code in non-volatile
memory remains unmodified during the runtime phase of Rothman-1 when a
firmware-based image in memory (e.g., an update image) is modified. Only
during the pre-boot phase following system restart the firmware code in non-
volatile memory is modified. Hence, the runtime operation of Rothman-1,
similar to Rothman-2, also discloses the feature required by claims 1 and 13
of not modifying the original firmware code in non-volatile memory during
runtime.
Appeal 2011-002355
Application 11/259,843

9
combining the teachings of Rothman-1 and Rothman-2, a modified firmware
image in memory may be utilized (to provide a modified firmware
implementation) during runtime without having to modify the original
firmware image in non-volatile memory. In reply, Appellant acknowledges
that “one skilled in the art might be motivated to modify Rothman-1 to
provide applications access to firmware data,” and reverts to the argument
regarding the “purpose” of Rothman-1: “[such] modification would not
involve modifying Rothman-l’s teachings regarding updating firmware code
in non-volatile memory.” (Reply Br. RB-28, ¶ 18.03.) As discussed above,
we are not persuaded by this argument.
Issue 1-c
With respect to the feature of operating system interacting with the
modified firmware-based image in memory, Appellant’s argument is
predicated upon the previously rejected argument that Rothman-l does not
disclose modifying a firmware-based image, that is, “since Rothman-l does
not disclose modifying a firmware-based image, Rothman-1’s EFI cannot be
interacting with ‘the modified firmware-based image’.” (See Reply Br. RB-
30, ¶ 22.01.) Hence, this argument is unpersuasive for the same reasons
discussed above with respect to issue 1-a.
Issue 1-d
Appellant asserts that the passages of Rothman-1 cited by the
Examiner (paragraph 24 and Figure 2) do not teach altering the appearance
of a firmware-based image but does not explain the basis for the assertion.
(See Reply Br. RB-35–36, ¶¶ 43, 43.01.) We agree with the Examiner that
the cited passages of Rothman-1 teach modifying a firmware-based image
“so as to alter its appearance to an operating system.” (Ans. 30.)
Appeal 2011-002355
Application 11/259,843

10
Accordingly, we are not persuaded that the Examiner has erred in
rejecting independent claims 1 and 13, and therefore sustain the Examiner’s
rejection of these claims.
Appellant’s arguments directed to independent claim 26 present
essentially the same issues as claim 1. (See Reply Br. RB-42–43, ¶¶ 72-
72.02.) Hence, we sustain the Examiner’s rejection of claim 26 for the same
reasons discussed above with respect to claim 1.

Claims 2, 4, 5, 7-12, 14-19, 21, and 27-30
Appellant has not separately argued any of the rejections of the
following dependent claims: claims 2, 4, 5, and 7-12, which depend from
independent claim 1; claims 14-19 and 21, which depend from independent
claim 13; and claims 27-30, which depend from independent claim 26. We,
therefore, sustain the Examiner’s rejection of these dependent claims for the
same reasons discussed above with respect to independent claims 1, 13, and
26.

Claims 3 and 6
Claim 3 depends from claim 1 and further requires “executing
instructions to patch the table in the interface . . . includes executing
instructions to change static table data.” Appellant contends that neither
Rothman-1 nor Rothman-2 discloses patching a table. (Reply Br. RB-32, ¶¶
29-30.) In response, the Examiner proposes to interpret the claim limitation
of “to change static table data” as “changing ‘static table data in an EFI,
SAL, PAL, ACPI interface, etc.’” and finds that, under the proposed
interpretation, paragraph 41 and figures 2 and 3 of Rothman-1 teach the
Appeal 2011-002355
Application 11/259,843

11
claim limitation. (Ans. 27.) Appellant does not dispute the Examiner’s
claim interpretation or challenge the Examiner’s findings but instead argues
that the Examiner’s reading of Rothman-1 is “weak at best.” (See Reply Br.
RB-32, ¶ 30.01.) Appellant’s argument lacks sufficient specificity and
therefore does not overcome the Examiner’s rejection. We find the
Examiner’s proposed claim interpretation to be reasonable and agree with
the Examiner’s finding under the interpretation that the cited passages teach
changing static table data. Accordingly, we sustain the Examiner’s rejection
of claim 3.
Claim 6 depends from claim 1 and further requires “insert[ing] . . .
new runtime instruction entrypoints” into a memory location. The Examiner
interprets “runtime instruction entrypoints” as the location used to access
executable software. (Ans. 28.) The Examiner finds that, under the
proposed interpretation, paragraph 41 and page 7, right column, lines 4-8 of
Rothman-1 teach the claim limitation. (See Ans. 29.) Appellant does not
dispute the Examiner’s claim interpretation but argues that writing data to
the Variable Services of the Runtime Services described in paragraph 41
does not teach changing an entrypoint to the Runtime Services. (See Reply
Br. RB-33–34, ¶¶ 35-36.01.) However, Appellant does not refute the
Examiner’s finding regarding page 7, right column, lines 4-8 of Rothman-1.
(See id.) We agree with the Examiner’s proposed claim interpretation and
the Examiner’s findings under the interpretation that the cited passages teach
inserting new runtime instruction entrypoints into a memory location.
Accordingly, we sustain the Examiner’s rejection of claim 6.

Appeal 2011-002355
Application 11/259,843

12
Claims 22 through 25
The Examiner’s rejection of claim 22 is based on grounds similar to
the rejection of claims 1, 3, and 6. (See Ans. 32-33.) The Examiner and
Appellant agree that claim 22 raises similar issues as claims 1 and 3. (See
Ans. 32; Reply Br. RB-38, ¶¶ 55-55.01.) Appellant contends, however, the
Examiner’s rationale for rejecting claim 6 does not apply to claim 22
because “patch[ing] runtime service entrypoints” recited by claim 22 is not
the same as “insert[ing] . . . new runtime instruction entrypoints into [a]
memory location” recited by claim 6. (See Reply Br. RB-39, ¶ 58.02.) We
are not persuaded by Appellant’s argument and agree with the Examiner that
the two claim limitations are similar because inserting entrypoints into a
memory location is functionally equivalent to patching. (Ans. 33.) Hence,
we sustain the Examiner’s rejection of claim 22 for the same reasons
discussed above with respect to claims 1, 3, and 6.
Appellant’s arguments advanced in pages RB-38 and RB-39,
paragraphs 58 and 58.01 of the Reply Brief are directed to the individual
disclosures of Rothman-1 and Rothman-2. As discussed above, the
Examiner’s rejection is based on the combination of Rothman-1 and
Rothman-2. As noted above, nonobviousness cannot be established by
attacking the references individually when the rejection is predicated upon a
combination of prior art disclosures. See Merck, 800 F.2d at 1097.
Appellant does not present separate arguments for claims 23 through
25, which depend from claim 22. Hence, we sustain the Examiner’s
rejection of claims 23-25 for the same reasons discussed above with respect
to claim 22.

Appeal 2011-002355
Application 11/259,843

13
Claim 20
We agree with Appellant that the passages cited by the Examiner (see
Ans. 31, citing Rothman-2 col. 4, ll. 1-61) do not teach “add[ing] a
subordinate runtime service that describes a device not known to a firmware
image on a system but useable by a particular OS” as recited in claim 20.
(See Reply Br. RB-36–37, ¶¶ 48-49.) Accordingly, we do not sustain the
Examiner’s rejection of claim 20.

DECISION
The decision of the Examiner to reject claims 1 through 30 is
affirmed-in-part.
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

rwk