Ex Parte Foster et al

Patent Trial and Appeal Board

Jul 31, 2013

10926255 (P.T.A.B. Jul. 31, 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.
10/926,255 08/25/2004 Derek John Foster 3875.0150001 8265
26111 7590 08/01/2013
STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
1100 NEW YORK AVENUE, N.W.
WASHINGTON, DC 20005
EXAMINER
ZHEN, LI B
ART UNIT PAPER NUMBER
2197
MAIL DATE DELIVERY MODE
08/01/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 DEREK JOHN FOSTER and LORI YOSHIDA
____________________

Appeal 2011-000525
Application 10/926,255
Technology Center 2100
____________________

Before JEAN R. HOMERE, ELENI MANTIS MERCADER, and
TREVOR M. JEFFERSON, Administrative Patent Judges.

JEFFERSON, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2011-000525
Application 10/926,255

2
STATEMENT OF CASE
1

Appellants appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1-22 and 34-44.
2
Claims 23-33 were cancelled. We have jurisdiction
under 35 U.S.C. § 6(b).
We affirm.
Invention
The claims are directed to method and system for an application
framework for a wireless device to manage applications via an application
manager. Specification ¶ [04] Field of Invention. Claim 1, reproduced
below, is illustrative of the claimed subject matter:
1. A method for managing applications within a Man-
Machine Interface (MMI) application framework, the method
comprising:
creating an active application context upon launching a
first application by an application manager;
transitioning said active application context into a
suspended application context upon suspending said first
application by said application manager;
storing said suspended application context in an
application manager context stack; and
acquiring said stored suspended application context from
said application manager context stack upon receipt of an exit
message by said application manager.

1
Throughout the decision, we refer to the Appellants’ Appeal Brief (“App.
Br.,” filed Apr. 23, 2010), and Reply Brief (“Reply Br.,” filed Aug. 31,
2010), and the Examiner’s Answer (“Ans.,” mailed Jul. 6, 210).
2
The Real Party in Interest is Broadcom Corporation. App. Br. 2.
Appeal 2011-000525
Application 10/926,255

3
References
In rejecting the claims on appeal, the Examiner relied upon the
following prior art:
Hamanaga US 7,024,206 B2 Apr. 4, 2006
Nelson US 2002/0010850 A1 Jan. 24, 2002

Rejection
The Examiner rejected claims 1 - 22 and 34 - 44 under 35 U.S.C.
§103(a) as being unpatentable over Hamanaga and Nelson. Ans. 4-7.

ANALYSIS
We have reviewed the Examiner’s rejection in light of Appellants’
arguments that the Examiner has erred. We disagree with Appellants’
conclusions as to all rejections. We adopt as our own (1) the findings and
reasons set forth by the Examiner in the action from which this appeal is
taken and (2) the reasons set forth by the Examiner in the Examiner’s
Answer in response to Appellants’ Appeal Brief (Ans. 7-23). We concur
with the conclusions reached by the Examiner. For emphasis we highlight
Appellants’ arguments seriatim as they are presented in the Appeal Brief,
pages 11-28.
Independent Claim 1
Appellants argue that Hamanaga and Nelson do not teach or suggest
“creating an active application context upon launching a first application by
an application manager” or “suspending said first application by said
application manager” as recited in claim 1. App. Br. 12-13. Specifically,
Appellants argue that Hamanaga does not disclose an application manager
because the mailer P2 is activated directly by the user without using an
Appeal 2011-000525
Application 10/926,255

4
application manager. App. Br. 14. Accordingly, Appellants assert that
Hamanaga cannot teach or suggest any of the steps requiring an application
manager, such as “creating an active application context … by an
application manager” or “suspending said first application by said
application manager” as recited in claim 1. App. Br. 15. Appellants contend
that the ROM in Hamanaga identified as the “application manager” as
claimed, merely provides services in response to a user’s push of a button
and is not an application manager. App. Br. 17-18.
We are not persuaded that the Examiner erred in finding that the
program stored on the ROM that is executed in Hamanaga is equivalent to
the claimed application manager. Ans. 8-9. We note that Appellants do not
argue for any specific definition of “application manager.” We find that
Hamanaga expressly teaches that a program stored in the ROM 208
executes, interrupts and resumes applications via the CPU. Hamanaga, col.
19, ll. 62-65; see Hamanaga, col. 9, l. 25-29 and col. 10, l. 18-58; Ans. 8.
We are not persuaded by Appellants’ arguments that the user’s push of a
button activates programs. App. Br. 14, 17-18; Reply Br. 8-9. Hamanaga
teaches that a user initiates an action, but plainly teaches that the ROM
activates and executes programs in response to the user input such that it
creates an active application context and suspends a first application. See
Hamanaga, col. 10, ll. 18-58, col. 19, ll. 62-65; see Ans. 9-10.
With respect to Nelson and Hamanaga, Appellants argue that Nelson
also fails to teach or suggest an application manager or “creating an active
application context upon launching a first application by an application
manager.” App. Br. 18-20. Specifically, Appellants assert that the
Examiner erred in finding that Nelson’s program names in the call stack are
Appeal 2011-000525
Application 10/926,255

5
created. App. Br. 20. Appellants essentially argue that Nelson’s program
names of active programs (or application parameters) “pre-exist” and are not
created when the program is called or launched. App. Br. 20-21 (citing
Nelson ¶ [0052] and [0058]); Reply Br. 19.
We are not persuaded by Appellants’ arguments and agree with the
Examiner that Nelson teaches that the launch of an application creates record
entries that include the program name, launch parameters and the state of the
calling application. See Nelson ¶[0043], [0045]; Ans. 12-13, 14. We find
that Nelson teaches that the stack in Nelson records information about the
parameters of the called application including the name of the launched
program and other parameters. Nelson ¶[0043], [0045], [0048], [0061]; see
Ans. 14. Specifically, we find that Nelson teaches that “[a]t step 302, the
caller application pushes a program entry record for the called application
launch information onto the stack. The pushed information can then be used
(as indicated in step 218 of FIG. 2) for the launched application to properly
execute.” Nelson ¶ [0061]. We agree with the Examiner that Nelson
teaches creating application context information during the process of
executing a program call. App. Br. 12-13.
We note that Appellants do not dispute the Examiner’s definition of
“application context” (Ans. 21), but argue that information is pre-existing
and fails to meet the creation “upon launching a first application by an
application manager” limitation. See Reply Br. 19. Appellants’ argument is
not commensurate in the scope with the claims. See In re Self, 671 F.2d
1344, 1348 (CCPA 1982). We find that Nelson’s teachings that stack entries
are made in response to a called application reads on the claimed “upon
launching” of an application. See, e.g., Nelson ¶ [0061].
Appeal 2011-000525
Application 10/926,255

6
Appellants also contend that the Examiner erred in finding that the
operating system of Nelson corresponds to the application manager. App.
Br. 22. Appellants argue that the catalog database in Nelson is discussed in
connection with the operating system as the method for collaboration
between the running applications and is not an application manager. App.
Br. 22-23. Appellants also argue that Nelson fails to teach or suggest
“storing said suspended application context in an application manager
context stack; . . . upon receipt of an exit message by said application
manager.” App. Br. 23.
Appellants cannot show nonobviousness by attacking references
individually where rejections are based on combinations of references. In re
Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986). The Examiner’s
rejection relies on Hamanaga for the application manager launching an
application and Nelson for teaching the creation of an application context
upon launching of a first application. Ans. 12. The Examiner also relies on
Hamanaga, not Nelson, to teach the “storing said suspended application
context” and “acquiring said stored suspended application context”
limitations of claim 1. Ans. 20. Regardless, we agree with the Examiner
that Hamanaga teaches the claimed “application context information” in the
history information R17 that contains saved program context data for an
application to resume following interrupt (Ans. 20-22 (citing Hamanaga, col.
12, ll. 14-32; col. 8, l. 45 – col. 9, l. 25)) and that Nelson suggests a catalog
database and the operating systems that collaborate read on application
manager (Ans. 18-19). We also agree with the Examiner that Hamanaga
teaches the storing the history information in application stack and acquiring
the stored history information upon an exit message. Ans. 20 (citing
Appeal 2011-000525
Application 10/926,255

7
Hamanaga, col. 8, ll. 45-65; col . 20, ll. 55-64. Similarly, Nelson teaches
storing and acquiring application context for a suspended application.
Nelson ¶[0059], [0061]. It is the combination of Hamanaga and Nelson that
teaches the “creating an active application context upon launching a first
application by an application manager” and the “storing” and “acquiring”
using an “application manager context stack” limitations of claim 1. See
Ans. 12, 20.
Based on the foregoing, we find that that the Examiner did not err in
finding that Hamanaga and Nelson teach or suggest an “application
manager” that reads on “creating an active application context upon
launching a first application by an application manager” and “suspending
said first application by said application manager” as recited in claim 1.
Because Appellants rely on the arguments presented for independent claim 1
for dependent claims 2-11, 13-22 and 35-44 (App. Br. 24) and dependent
claims 6, 7, 17, 18, 39 and 40 (App. Br. 27), we sustain the Examiner’s
rejection of claims 1, 2-11, 13-22, 35-44 and dependent claims 6, 7, 17, 18,
39 and 40 under 35 U.S.C. § 103(a).

Dependent Claims 2, 13 and 35
Appellants contend that the Examiner erred in finding that Hamanaga
teaches or suggests that the “application manager context stack comprises a
last-in-first-out (LIFO) context stack” as recited in dependent claim 2.
Reply Br. 30-33. Appellants assert that the history information R17
discussed in Hamanaga and relied upon by the Examiner is the actual
display of data resulting from the execution of the processor and not
Appeal 2011-000525
Application 10/926,255

8
“application context” as recited in the claim. App. Br. 25 (citing Hamanaga
col. 8, ll. 45-65).
The Examiner found that Hamanaga teaches history information 17
that is typically retained in LIFO fashion as part of the storing and acquiring
of application context. App. Br. 20-21 (citing Hamanaga col. 8, ll. 45-65).
We agree with the Examiner. Hamanaga teaches that “history
information R17” may be “resume information” but is not limited to display
related data. Hamanaga col. 8, ll. 45-65. As discussed above, Hamanaga
also teaches that the ROM program acting as the application manager,
creates the history information R17 that contains saved program context data
for an application to resume following interrupt (Ans. 21-22 (citing
Hamanaga, col. 12, ll. 14-32; col. 8, l. 45 – col. 9, l. 25)).
We find that the Examiner did not err in finding that Hamanaga
teaches or suggests that the “application manager context stack comprises a
last-in-first-out (LIFO) context stack” as recited in dependent claim 2.
Appellants rely on the arguments presented for claim 2 for dependent claims
3, 14 and 36. App. Br. 26. Accordingly, we sustain the Examiner’s rejection
of claims 2, 3, 14 and 36 under 35 U.S.C. § 103(a).

Dependent Claim 4
Appellants argue that the “application activation section 111 [that]
activates an application” in Hamanaga fails to teach or suggest “restoring
state information associated with the first application” as recited in
dependent claim 4. App. Br. 26 (citing Hamanaga, col. 15, ll. 40-46); Reply
Br. 33-36. Appellants argue that Hamanaga merely teaches activating the
application itself and not the state information. App. Br. 26.
Appeal 2011-000525
Application 10/926,255

9
We are not persuaded that the Examiner erred with respect to
dependent claim 4, and agree with the Examiner’s findings that Hamanaga
teaches interruption information that corresponds to the state information for
resuming applications. Ans. 23 (citing Hamanaga col. 15, lines 40-46). We
find that Hamanaga expressly discusses resumption using the particular
history information R17 to allow a mobile terminal to resume a previous
state before interruption. Hamanaga, col. 18, ll. 21-29; see Ans. 23.
Accordingly, Hamanaga teaches restoring an application based on its stored
or previous state information.
Based on the foregoing, the Examiner did not err in finding that
Hamanaga teaches or suggests “restoring state information associated with
the first application” as recited in dependent claim 4. Because Appellants
argue that claim 4, 15 and 37 together (App. Br. 26), we sustain the
Examiner’s rejection of claims 4, 15, and 37 under 35 U.S.C. § 103(a).

Dependent Claims 8-11, 18-22 and 41-44
With respect to the remaining dependent claims, Appellants made no
separate arguments for claims 8-11 (that depend from independent claim 1),
18-22 (that depend from independent claim 12) and 41-44 (that depend from
independent claim 34). App. Br. 27. These claims stand or fall with their
respective independent claims. We sustain the Examiner’s rejection of
claims 8-11, 18-22 and 41-44 under 35 U.S.C. § 103(a).

Appeal 2011-000525
Application 10/926,255

10
DECISION
For the above reasons, the Examiner’s rejection of claims 1-22 and
34-44 is affirmed.

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

ELD