NEC EUROPE LTD.

Patent Trials and Appeals Board

Apr 22, 2021

2020002951 (P.T.A.B. Apr. 22, 2021)

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.
14/890,912 11/13/2015 Ghassan Karame 814997 2868
95683 7590 04/22/2021
Leydig, Voit & Mayer, Ltd. (Frankfurt office)
Two Prudential Plaza, Suite 4900
180 North Stetson Avenue
Chicago, IL 60601-6731
EXAMINER
DAVIS, ZACHARY A
ART UNIT PAPER NUMBER
2492
NOTIFICATION DATE DELIVERY MODE
04/22/2021 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):
chgpatent@leydig.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte GHASSAN KARAME and WENTING LI
Appeal 2020-002951
Application 14/890,912
Technology Center 2400
Before ERIC S. FRAHM, JUSTIN BUSCH, and JAMES W. DEJMEK,
Administrative Patent Judges.
BUSCH, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–5, 8–16, 20, and 23–27. Oral
argument was heard on March 3, 2021. A copy of the transcript (“Tr.”) was
entered into the record. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.

1 We use the term Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42(a) (2018). Appellant identifies the real party in interest as NEC
Laboratories Europe GmbH. Appeal Br. 1.
Appeal 2020-002951
Application 14/890,912
2
CLAIMED SUBJECT MATTER
The claimed subject matter relates to a method for performing a
secure boot and remote attestation of a mobile computing system. Spec.
¶¶ 2–4. Claim 1, reproduced below, is illustrative of the claimed subject
matter:
1. A method for performing a secure boot of a mobile device
computing system that includes a smart card that provides secure
storage of a cryptographic private key, the method comprising:
performing, to produce at least one measurement result, a
measurement on each of one or more system specific and/or
application specific files before each file is loaded or launched
by a kernel module or an application loader of the computing
system;
receiving, by a native daemon running in kernel space of
the mobile device computing system, the at least one
measurement result and forwarding, by the native daemon, the at
least one measurement result to the smart card; transmitting a
signature request including the at least one measurement result
to the smart card;
after receiving the signature request including the at least
one measurement result, increasing a value of an increase-only
global counter maintained by the smart card;
executing, by the smart card, a signing process in which
the smart card signs, with the cryptographic private key to
generate a signature, a combination of the at least one
measurement result and the value of the increase-only global
counter; and
storing, at the computing system, the signature generated
by the smart card.
Appeal 2020-002951
Application 14/890,912
3
REFERENCES
The prior art relied upon by the Examiner is:
Name Reference Date
Maheshwari US 7,152,165 B1 Dec. 19, 2006
Audebert US 8,190,899 B1 May 29, 2012
Schmidt US 8,949,997 B2 Feb. 3, 2015
Muthiah US 9,396,330 B2 July 19, 2016
Haga US 2011/0185165 A1 July 28, 2011

REJECTIONS2
Claims 1–5, 8–16, and 23–26 stand rejected under 35 U.S.C. § 112(b)
as being indefinite for failing to particularly point out and distinctly claim
the subject matter which the inventor or a joint inventor regards as the
invention. Final Act. 4–5.
Claims 1–5, 8–16, 20, 23, and 24 stand rejected under 35 U.S.C. § 103
as obvious over Haga, Schmidt, Maheshwari, and Muthiah. Final
Act. 6–10.3
Claims 25–27 stand rejected under 35 U.S.C. § 103 as obvious over
Haga, Schmidt, Maheshwari, Muthiah, and Audebert. Final Act. 10–11.
ANALYSIS
REJECTION UNDER 35 U.S.C. § 112(B)
After the Final Rejection, Appellant attempted to amend claims 1 and
14 in response to the Examiner’s rejection under 35 U.S.C. § 112(b). See
Amdt 2, 4, 7–8 (filed May 22, 2019). The Examiner did not enter the

2 The Examiner includes claim 7 in the rejections, but claim 7 was canceled
prior to the most recent office action. Therefore, claim 7 is not before us.
3 The Examiner does not include claim 16 in the statement of rejection, but
the Examiner rejects claim 16 in the body of the rejection. Final Act. 6, 10.
Appeal 2020-002951
Application 14/890,912
4
proposed amendments. See Adv. Act. 1 (mailed June 4, 2019). Appellant
notes the attempted amendment to the claims, see Reply Br. 2, but Appellant
does not argue the merits of the indefiniteness rejection with respect to the
claims as currently pending. Therefore, we summarily sustain the rejection.
REJECTIONS UNDER 35 U.S.C. § 103
The Examiner rejects claims 1–5, 8–16, 20, 23, and 24 as obvious
over Haga, Schmidt, Maheshwari, and Muthiah. Final Act. 6–9. The
Examiner rejects claims 25–27 as obvious over Haga, Schmidt, Maheshwari,
Muthiah, and Audebert. Final Act. 10–11. Appellant argues all claims
except claims 23–27 as a group. See Appeal Br. 11–14; Reply Br. 2–7, 17.
Appellant does not separately argue the rejection of claims 25–27 with
particularity. See generally Appeal Br. 8–17 (not addressing claims 25–27);
Reply Br. 16 (with respect to claims 25–27, arguing only that Audebert does
not cure the deficiencies asserted with respect to the rejection of the
independent claims).
The Examiner finds Haga and Schmidt teach the majority of the
limitations recited in independent claim 1. Final Act. 6–7. Specifically, the
Examiner finds the combination of Haga and Schmidt teaches or suggests
performing a secure boot using an IC (integrated circuit) card, such as a
smart card, to measure files before they are launched, increase a counter, and
generate a signature using a cryptographic key to sign a combination of the
counter and the measurement result. Final Act. 6–7 (citing Haga ¶¶ 91, 156,
160, 180, 181, 223, 244; Schmidt 4:21–60, 9:57–10:19, 61:8–11). The
Examiner finds the combination does not disclose “an increase-only global
counter or signing a combination of the measurement results and the value
Appeal 2020-002951
Application 14/890,912
5
of the increase-only global counter” or “using a native daemon to perform
th[e] receiving and forwarding” steps. Final Act. 6–8.
However, the Examiner finds Maheshwari “discloses a method that
includes performing a measurement on files . . .[,] increasing a value of the
increase-only counter[,] and executing a signing process that generates a
signature on a combination of the measurement result and the value of the
increase-only counter and storing the signature.” Final Act. 7 (citing
Maheshwari 8:6–25, 9:6–16). The Examiner further finds Muthiah
“discloses that daemon services are programs that handle periodic service
requests and forward the requests as appropriate and can run in the kernel.”
Final Act. 8 (citing Muthiah 24:52–63). The Examiner concludes it would
have been obvious to (1) modify the combined teachings of Haga and
Schmidt with Maheshwari’s teachings of increasing an increase-only counter
“to thwart replay attacks” and (2) further modify this combination with
Muthiah’s teaching to use a daemon running in a kernel to receive and
forward requests “to allow the processes to run unattended in the
background.” Final Act. 7 (citing Maheshwari 8:23–25), 8 (citing Muthiah
24:52–63).
Appellant argues (1) Haga and Schmidt use a trusted platform module
(TPM) chip to perform the relevant functions, and neither Haga nor Schmidt
teaches using a smart card or that a smart card is interchangeable with a
TPM chip; (2) the Examiner’s reason for combining Maheshwari’s teachings
with Haga and Schmidt is unsupported by a rational underpinning; and
(3) Muthiah is not analogous art. Appeal Br. 11–14; Reply Br. 2–7, 11–12.
We address each of these arguments, in order, below.
Appellant asserts Haga and Schmidt both require TPM chips to
perform the functions described in their respective systems. Appeal
Appeal 2020-002951
Application 14/890,912
6
Br. 11–12. Appellant argues Haga’s disclosed integrated circuit (IC) card is
not a smart card. Appeal Br. 11. Appellant also contends “Haga does not in
any way indicate or suggest that the secure module 20 can be embodied as a
smart card that lacks the cryptoprocessing functionality of a TPM” and Haga
fails to suggest “that a smart card is capable of performing the functionality
(i.e. cryptoprocessing functionality) required for the secure boot process.”
Reply Br. 5. Similarly, Appellant argues Schmidt discloses using a TPM
extend operation and TPM platform configuration registers (PCRs) generate
and store measurement values. Appeal Br. 11 (citing Schmidt 4:39–42,
9:38–56). Thus, Appellant contends “[n]either Schmidt nor Haga provides
any teaching or suggestion that a TPM performs the same functions as, or is
interchangeable with, a smart card or SIM card.” Appeal Br. 12; see Reply
Br. 5 (arguing Schmidt’s disclosure that a smart card “may serve as a secure
environment in a WTRU [(wireless transmit-receive unit)] does not amount
to a teaching or suggestion that those components are interchangeable and
capable of performing the same functions.”). Appellant further contends
that using a SIM card or smart card in place of the TPM chips in Haga and
Schmidt would render the devices unsuitable to perform an extend operation,
which is required to achieve a secure boot. Appeal Br. 12; Reply Br. 5
(asserting that Haga and Schmidt “require the cryptoprocessing functionality
of a TPM”).
The Examiner finds Haga and Schmidt disclose using a smart card to
implement the described system and secure environment, respectively. Final
Act. 6–7 (citing Haga ¶¶ 91, 156, 160, 180, 181, 223, 244; Schmidt 4:21–32,
9:57–10:19, 61:8–11); Ans. 5 (finding Haga discloses using an IC card that
is detachable from devices (citing Haga ¶ 244)). The Examiner finds that, to
the extent Haga does not explicitly disclose using a smart card or IC card,
Appeal 2020-002951
Application 14/890,912
7
Schmidt expressly discloses using a smart card to implement its secure
environment and Schmidt further discloses storing measurement values in a
register within the secure environment. Ans. 5–6 (citing Schmidt 4:18–49,
9:38–56, 61:7–11).
Haga discloses “an information processing device for performing a
secure boot by booting a plurality of programs in a predetermined order
while verifying integrity of each program.” Haga ¶ 11. Although Haga
generally describes features being implemented on a TPM chip according to
Trusted Computing Group (“TCG”) standards,4 Haga repeatedly suggests
that using a TPM chip to implement the functions and components the
Examiner relies on as teaching the recited elements is merely one possibility.
See, e.g., Haga ¶¶ 41 (describing four separate units: an accumulation unit to
generate and store information every time a program is booted; a storage
unit to store protected data, “including boot data that is used by a specific
program during booting and an expected value of the cumulative value
stored by the accumulation unit immediately before [and after] the specific
program is booted”; and both protection removal and reprotection units that
provide the disclosed unseal and seal functions), 122 (“If the secure module
is provided with TPM functions, this structure may be implemented via the
protected storage function of the TCG.” (emphases added)), 132 (“Note that
if the secure module 20 is implemented by a TPM or MTM specified by the
TCG, the sealing command is implemented as TPM_Seal.” (emphases
added)), 135 (“Note that if the secure module 20 is implemented by a TPM
or MTM specified by the TCG, the unsealing command is implemented as

4 See, e.g., Haga ¶ 3 (describing prior art that uses “the seal function of the
Trusted Platform Module (TPM) detailed by the Trusted Computing Group
(TCG)”).
Appeal 2020-002951
Application 14/890,912
8
TPM Unseal.” (emphases added)), 231 (“The secure module 20 may be
implemented by hardware or by software. More specifically, the secure
module 20 may be the TPM or MTM detailed by the TCG[.] In this case, the
environment information registers 271 and 272 are Platform Configuration
Registers (PCR).” (emphases added)), 232 (disclosing that sealing may be
performed outside the secure module).
Haga discloses that an extend operation is when integrity is
maintained by cumulatively storing hash values for a “booted program in an
environment information register within a provided secure module.” Haga
¶ 68. Although the environment information register may be implemented
by platform configuration registers when employing a TPM chip, Haga does
not so limit the registers. See Haga ¶ 231. “When integrity is maintained,
the information processing terminal 10 cumulatively stores a hash value for
the booted program in an environment information register within a
provided secure module (this process hereinafter being referred to as an
extend operation).” Haga ¶ 68. Although, as mentioned, Haga describes
many of the functions being implemented by a TPM chip, Haga explicitly
discloses that various modifications are envisaged. See Haga ¶¶ 220–250.
In particular, Haga discloses that the “secure module 20 may be
implemented by hardware or by software” and “[p]art or all of the
components comprising each of the above devices may be assembled as an
IC card detachable from each device.” Haga ¶¶ 231, 244. Such an IC card
“may be tamper resistant.” Haga ¶ 244.
Schmidt relates to systems and methods “for generating verification
data that may be used for validation of a wireless transmit-receive unit”
(WTRU). Schmidt, Abstract. “The WTRU may have one or more
components and a secure environment with a number of secure registers”
Appeal 2020-002951
Application 14/890,912
9
and “the secure environment may be a trusted platform module (TPM), a
smart card[,] a Universal Integrated Circuit Card (UICC), or any
combination thereof.” Schmidt 4:21–28 (emphasis added). Similar to Haga,
Schmidt discloses generating a value based on a measurement and storing
the values in a secure register of the secure environment. Schmidt 4:33–42.
Also similar to Haga, Schmidt generally describes performing certain
functions using TPM features and components. See, e.g., Schmidt 9:26–45.
However, Schmidt explicitly discloses that “TCG-nomenclature and some
concepts are used and described [t]herein, but the embodiments described
[t]herein are not restricted to platforms and secure hardware elements
adhering to TCG standards, such as TPMs, SMLs, and systems designed
according to the PC Client specification for example.” Schmidt 27:20–25.
A reference is prior art for all that it teaches. Beckman Instruments,
Inc. v. LKB Produkter AB, 892 F.2d 1547, 1551 (Fed. Cir. 1989). Prior art
must be evaluated for what the reference would have fairly suggested to one
of ordinary skill in the art at the time of the invention. Merck & Co. v.
Biocraft Labs., Inc., 874 F.2d 804, 807–08 (Fed. Cir. 1989); In re
Fracalossi, 681 F.2d 792, 794 n.1 (CCPA 1982) (A prior art reference’s
disclosure is not limited to its examples.); In re Boe, 355 F.2d 961, 965
(CCPA 1966) (All of the disclosures in a prior art reference “must be
evaluated for what they fairly teach one of ordinary skill in the art.”). See
also Manual of Patent Examining Procedure (“MPEP”) § 2123 (9th ed., Rev.
10.2019, June 2020). Moreover, “a non-enabling reference may qualify as
prior art for the purpose of determining obviousness under § 103.” Symbol
Techs., Inc. v. Opticon, Inc., 935 F.2d 1569, 1578 (Fed. Cir. 1991).
We agree with the Examiner that both Haga and Schmidt at least
suggest using a smart card (e.g., an IC card) to implement the secure module
Appeal 2020-002951
Application 14/890,912
10
and secure environment, respectively, which perform various functions to
ensure a secure boot, including cryptographic and secure storage functions.
See Haga ¶¶ 68, 91, 156, 160, 180, 181, 223, 231, 244, 250; Schmidt
4:21–60, 9:26–10:19; accord Final Act. 6–7; Ans. 5–7 (citing Haga ¶ 244;
Schmidt 4:21–32).
Appellant further argues the Examiner’s rationale for modifying Haga
and Schmidt with Maheshwari’s teachings—i.e., “to thwart replay
attacks”—does not sufficiently explain how adding Maheshwari’s teaching
of preventing replay attacks would have improved the proposed Haga-
Schmidt secure boot process or why a person of ordinary skill in the art
would have modified the secure boot process to prevent replay attacks.
Appeal Br. 12–13; Reply Br. 6; see also Reply Br. 11–12 (presenting similar
arguments regarding the rationale for modifying Haga and Schmidt with
Maheshwari’s teachings as applied to dependent claim 23). Appellant
asserts that Maheshwari merely stores “a transaction count in a tamper-
resistant store . . . to prevent ‘replay attacks,’” but “thwarting replay attacks
is not relevant to performing a secure boot of a terminal device such as
cellular phones (as is described by Haga).” Appeal Br. 13 (citing
Maheshwari 8:23–25, 14:13–15).
The Examiner relies on Maheshwari for the limited purpose of
teaching or suggesting signing a combination of a value of an increase-only
counter and a measurement result (e.g., a hash value). Final Act. 7 (citing
Maheshwari 8:6–25, 9:6–16). The Examiner finds Maheshwari’s disclosure
that signing the identified combination of values prevents replay attacks
would have motivated a person of ordinary skill in the art to add
Maheshwari’s teachings to the Haga-Schmidt secure boot system and
process. Final Act. 7 (citing Maheshwari 8:23–25). The Examiner explains
Appeal 2020-002951
Application 14/890,912
11
that a replay attack occurs when an unauthorized third party (e.g., “an
attacker”) obtains old transaction data and attempts to reuse that data to
initiate a new transaction. Ans. 7. The Examiner additionally finds
Maheshwari discloses that its signing process prevents such replay attacks
and deletion of transactions. Ans. 7 (citing Maheshwari 14:13–17). The
Examiner further finds preventing replay attacks is relevant to a secure and
authenticated boot because replay attacks are one way an attacker may
attempt to “corrupt, delete, and/or modify measurement logs.” Ans. 8.
Maheshwari discloses methods and systems “for providing a trusted
database system” and “securing electronic data for storage in potentially
untrusted environments.” Maheshwari, Abstract, 1:25–27. “The trusted
database system leverages a trusted processing environment and a small
amount of trusted storage to provide tamper-detection and secrecy to a bulk
of untrusted storage.” Maheshwari 20:33–36. Certain embodiments offer
trusted bulk storage by providing “tamper-detection and secrecy for bulk
data,” which “includes resistance to replay attacks.” Maheshwari 20:54–58.
In some embodiments, Maheshwari includes a “tamper-resistant store
. . . provided by a locally-attached device such as a smart card.”
Maheshwari 8:6–11; see also Maheshwari 6:18–42 (describing that a
protected processing environment might be provided by “an integrated
circuit housed in a tamper-resistant hardware package” but that the system
does not require “a strongly-protected processing environment”). However,
in place of a tamper-resistant store, the system may sign a value from a
tamper-resistant increase-only counter and a hash of content in the database.
Maheshwari 8:20–25. More specifically, an exemplary disclosed method for
providing this trusted bulk storage includes storing a hash of data added to a
log and signing the hash by encrypting the data with a key in combination
Appeal 2020-002951
Application 14/890,912
12
with the value of an increment-only counter. Maheshwari 14:4–15. This
process prevents insertion of arbitrary transactions into the log because “the
attack will be unable to create an appropriately signed commit chunk” and
thwarts replay attacks. Maheshwari 14:10–15. By storing the value of the
increase-only counter in a tamper-resistant store, the process also prevents
attacks that attempt to delete transactions at the end of the log. Maheshwari
14:15–17.
Given these disclosures, a person of ordinary skill in the art would
have understood Maheshwari as teaching signing a hash value in
combination with a value from an increase-only counter in order to secure
data storage. Furthermore, Maheshwari discloses that this implementation is
an alternative to using a tamper-resistant store, such as a store that might be
part of a TPM chip. In other words, Maheshwari generally teaches that a
benefit of its invention is providing “trusted bulk storage” such that the
trusted database using a signed hash value in combination with the value of
an increase-only counter “includes resistance to replay attacks and attacks on
meta-data” by “provid[ing] tamper-detection and secrecy for bulk data.”
Maheshwari 20:56–58.
The Examiner finds that adding Maheshwari’s teachings prevents
replay attacks on the protected storage. Final Act. 7. The Examiner further
explains that Maheshwari’s teachings, which prevent replay attacks, is
relevant to performing a secure boot because replay attacks are one way in
which data could otherwise be compromised and, therefore, result in an
insecure boot. Ans. 7–8. Thus, the Examiner’s reason to combine
Maheshwari’s teachings with the proposed Haga-Schmidt secure boot
process is supported by a rational underpinning.
Appeal 2020-002951
Application 14/890,912
13
Haga and Schmidt relate to performing a secure boot including
verifying the integrity of programs by matching calculated hash values for
associated files to expected values and storing verified values in a database.
See Haga ¶¶ 2, 61, 63, 68, 71, 89; Schmidt 1:30–33, 1:46–57, 4:18–60.
Because Maheshwari provides an alternate way of securing data that does
not require using a large trusted storage and thwarting replay attacks would
further secure the Haga-Schmidt boot process, we agree with the Examiner
that a person of ordinary skill in the art would have modified the Haga-
Schmidt secure boot process with Maheshwari’s cited teachings. See KSR
Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007) (substituting one element
for another known in the field or combining known elements yields no more
than a predictable result supports a conclusion of obviousness).
Appellant also asserts that Muthiah is not analogous art to the
invention because Muthiah is neither from the same field of endeavor as nor
reasonably pertinent to Appellant’s invention. Appeal Br. 13–14. More
specifically, Appellant asserts Appellant’s field of endeavor is “securely
boot[ing] and remotely attesting a mobile device computing system[],”
whereas Muthiah’s field of endeavor relates to “reducing denial of service
(DoS) attacks against dynamically generated next secure (NSEC) domain
name system (DNS) records.” Appeal Br. 14 (citing Spec. ¶¶ 2–4; Muthiah
1:8–12). Appellant further contends the problem addressed by the invention
is securely booting and remotely attesting a mobile device without using
TPM chips. Appeal Br. 14 (citing Spec. ¶¶ 12, 23–25). Appellant argues
Muthiah is not reasonably pertinent to this problem because Muthiah’s
purpose “is to reduce the capability of a malicious attacker to execute denial
of service attacks by utilizing a name server that may prevent spoofed IP
addresses by forcing clients to transmit DNS queries via a reliable or
Appeal 2020-002951
Application 14/890,912
14
connection-oriented protocol, such as transmission control protocol (TCP).”
Appeal Br. 14 (citing Muthiah 2:44–48).
The Examiner finds the combination of Haga, Schmidt, and
Maheshwari already discloses (1) generally receiving a measurement result
and forwarding it to a smart card and (2) implementing a service in a kernel.
Final Act. 8 (citing Haga ¶¶ 91, 156, 223; Schmidt 4:21–32, 10:35–39;
Maheshwari 8:6–25, 9:6–16). Thus, the Examiner relies on Muthiah only to
teach that a native daemon performs the receiving and forwarding functions
recited in the claims. Final Act. 8 (citing Muthiah 24:52–63); see Ans. 8
(“Muthiah is relied upon for a more general teaching of a service (i.e. a
daemon) that runs in the kernel and handles and forwards service requests.”).
The Examiner finds Muthiah “discloses that daemon services are
programs that handle periodic service requests and forward the requests as
appropriate and can run in the kernel.” Final Act. 8 (citing Muthiah 24:52–
63). The Examiner finds the invention recognizes “the desirability of
running a service in kernel space due to its increased security.” Ans. 8–9
(citing Spec. ¶ 22). Thus, the Examiner determines that a person of ordinary
skill in the art would have considered Muthiah because it is reasonably
pertinent to addressing a problem Appellant identifies—increasing security
by running a service in kernel space. See Final Act. 8; Ans. 8–9.
A reference is analogous art to the claimed invention if the reference
is either (1) from the same field of endeavor as the claimed invention (even
if it addresses a different problem) or (2) reasonably pertinent to the problem
faced by the inventor (even if it is not in the same field of endeavor as the
claimed invention). In re Bigio, 381 F.3d 1320, 1325 (Fed. Cir. 2004). As
Appellant notes, prior art is “reasonably pertinent” if it “logically would
have commended itself to an inventor’s attention in considering” the
Appeal 2020-002951
Application 14/890,912
15
problem the inventor faced. In re ICON Health & Fitness, Inc., 496 F.3d
1374, 1379–80 (Fed. Cir. 2007) (citing In re Clay, 966 F.2d 656, 658–59
(Fed. Cir. 1992)); see Appeal Br. 13–14 (citing MPEP § 2141.01(a)).
“Although the dividing line between reasonable pertinence and less-than-
reasonable pertinence is context dependent, it ultimately rests on the extent
to which the reference of interest and the claimed invention relate to a
similar problem or purpose.” Donner Tech., LLC v. Pro Stage Gear, LLC,
979 F.3d 1353, 1359 (Fed. Cir. 2020).
For purposes of this decision, we assume Muthiah is not in the same
field of endeavor as Appellant’s invention. Appellant notes that using a
daemon running in a kernel allows forwarding results in a secure manner
using a background process. See Tr. 11:15–21. A problem addressed by
this feature of Appellant’s invention, therefore, was securely forwarding
messages in a background process. See Spec. ¶ 22.
Muthiah discloses that “[d]aemon services 218 are programs that run
continuously or in the background and handle periodic service requests
received by appliance 200.” Muthiah 24:52–54. Muthiah further discloses
that the daemon may forward requests and that daemon services may run
unattended in kernel space. Muthiah 24:54–62. Like Appellant’s
Specification, Muthiah discloses that running services in a kernel isolates
those processes from user space. See Muthiah 20:44–67 (“Kernel operation
means that these components or processes . . . run in the core address space”
which “improves encryption performance by . . . reducing the number of
transitions between the memory space or a kernel thread in kernel mode and
the memory space or a thread in user mode” eliminating the need to pass
data structures outside the kernel space to the user space); Spec. ¶ 22
Appeal 2020-002951
Application 14/890,912
16
(“Preferably, the service runs in kernel space, and is therefore isolated from
user-space applications, which strengthens its security against attacks.”).
As mentioned above, the Examiner relies on Muthiah for the limited
purpose of teaching using a daemon running in a kernel to forward
messages. Final Act. 8 (citing Muthiah 24:52–62); Ans. 8. Muthiah is
reasonably pertinent to a problem addressed by the inventor because both
Muthiah and Appellant’s invention address securely forwarding information
using a background process running in a kernel. Accordingly, we are
persuaded Muthiah is analogous art because it is reasonably pertinent to at
least one problem addressed by the inventor.
For the reasons discussed above, we sustain the rejection of
independent claim 1 as obvious over Haga, Schmidt, Maheshwari, and
Muthiah. As mentioned above, Appellant argues the rejection of claims 1–5,
8–16, and 20 as a group. Therefore, for the same reason, we also sustain the
rejection of claims 2–5, 8–16, and 20 as obvious over Haga, Schmidt,
Maheshwari, and Muthiah.
Claim 23 depends from claim 1 and further recites that “the smart card
is a subscriber identity module (SIM) that does not support restricted
operations on platform configuration registers (PCRs) and can be cloned.”
Claim 24 depends from claim 1 and further recites that “the smart card is not
a trusted platform module (TPM) chip.” With respect to these claims,
Appellant essentially reiterates the assertions presented with respect to claim
1—namely, that (1) Haga and Schmidt teach using a TPM chip and,
therefore, the combination fails to teach or suggest a smart card that is a SIM
card and is not a TPM chip, as recited in claims 23 and 24, respectively and
(2) a person of ordinary skill in the art would not have combined
Maheshwari with Haga and Schmidt. Appeal Br. 15–16; Reply Br. 7–16.
Appeal 2020-002951
Application 14/890,912
17
For the same reasons as discussed above, we find Haga and Schmidt
teach using a smart card to perform the recited functions. Because we agree
with and adopt the Examiner’s findings that a person of ordinary skill in the
art would understand that such smart cards or integrated circuit cards (ICCs)
include SIM cards and do not necessarily include TPM chips, see Ans. 9–11,
we find that the combination of Haga and Schmidt at least suggests both that
the smart card may be a SIM card and that the smart card is not a TPM chip.
Accordingly, we also sustain the rejection of claims 23 and 24 as obvious
over Haga, Schmidt, Maheshwari, and Muthiah.
As mentioned above, Appellant does not separately argue the rejection
of claims 25–27 with particularly. Instead, Appellant argues only that the
additionally recited reference, Audebert, fails to cure the deficiencies
identified with respect to the rejection of the independent claims. Because
we find no deficiency with respect to the rejection of the independent claims
for the reasons discussed above, we also sustain the rejection of claims
25–27 as obvious over Haga, Schmidt, Maheshwari, Muthiah, and Audebert.
CONCLUSION
The Examiner’s rejections are AFFIRMED.

Appeal 2020-002951
Application 14/890,912
18
DECISION SUMMARY
Claim(s)
Rejected
35 U.S.C. § Reference(s)/Basis Affirmed Reversed
1–5, 8–16,
23–26
112(b) Indefiniteness 1–5, 8–16,
23–26

1–5, 8–16,
20, 23, 24
103 Haga, Schmidt,
Maheshwari,
Muthiah
1–5, 8–16,
20, 23, 24

25–27 103 Haga, Schmidt,
Maheshwari,
Muthiah, Audebert
25–27
Overall
Outcome
1–5, 8–16,
20, 23–27

RESPONSE
No time period for taking any subsequent action in connection with
this appeal may be extended. 37 C.F.R. § 1.136(a)(1)(iv).
AFFIRMED