Ex Parte Cheng et al

Patent Trial and Appeal Board

Jul 27, 2017

14122994 (P.T.A.B. Jul. 27, 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.
14/122,994 11/27/2013 Shiow-Wen Cheng 20002/P54699US 1069
75343 7590 07/31/2017
Hanley, Flight & Zimmerman, LLC (Intel)
150 S. Wacker Dr. Suite 2200
Chicago, IL 60606
EXAMINER
AHMED, ZUBAIR
ART UNIT PAPER NUMBER
2132
NOTIFICATION DATE DELIVERY MODE
07/31/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):
j flight @ hfzlaw. com
docketing@hfzlaw.com
inteldocs_docketing @ cpaglobal. com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte SHIOW-WEN CHENG and ROBERT JOSEPH WOODRUFF
Appeal 2017-004590
Application 14/122,994
Technology Center 2100
Before JOHN A. JEFFERY, DENISE M. POTHIER, and STEVEN M.
AMUNDSON, Administrative Patent Judges.
POTHIER, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1, 2, 4—7, 9, 10, 12—16, 19, 20, and 22—28. Claims 3, 8,
11, 17, 18, and 21 have been canceled. See App. Br. 2.1 We have
jurisdiction under 35 U.S.C. § 6(b). We affirm-in-part.
1 Throughout this opinion, we refer to (1) the Final Action (Final Act.)
mailed June 24, 2016, (2) the Appeal Brief (App. Br.) filed October 17,
2016, (3) the Examiner’s Answer (Ans.) mailed December 1, 2016, and (4)
the Reply Brief (Reply Br.) filed January 23, 2017.
Appeal 2017-004590
Application 14/122,994
The Invention
Appellants’ invention relates to a “method[] and apparatus to manage
cache memory in multi-cache environments.” Spec. 11.
Claim 1 is reproduced below with emphasis:
1. An apparatus to manage cache memory, comprising:
a remote cache manager to detect an authorization code
sent by a remote cache client;
a delegation manager to constrain a remote cache
memory associated with the remote cache client to share data
with a host cache memory via a bus in response to the detection
of the authorization code; and
a lock manager to initialize the host cache memory and
the remote cache memory to a common lock state, at least one
of the delegation manager or the lock manage implemented via
hardware.
The Examiner relies on the following as evidence of unpatentability:
The Rejections
Claims 1, 2, 4—7, 9, 10, 12—16, 19, 20, and 22—25 are rejected under
35 U.S.C. § 103(a) as unpatentable over Boucher and Cudak. Final Act.
Claims 26—28 are rejected under 35 U.S.C. § 103(a) as unpatentable
over Boucher, Cudak, and Whitehouse. Final Act. 8—10.
Boucher
Whitehouse
Cudak
US 6,226,680 B1 May 1,2001
US 2012/0158683 A1 June 21, 2012
US 2014/0164549 A1 June 12, 2014
3-8.
2
Appeal 2017-004590
Application 14/122,994
OBVIOUSNESS REJECTION OVER BOUCHER AND CUDAK
Claims 1, 2, 4, and 5
Regarding independent claim 1, the Examiner finds that Boucher
teaches the “remote cache manager” and “delegation manager” as recited.
Final Act. 2-A (citing Boucher 7:6—14, 7:63—8:9, Fig. 4C); Ans. 4—5, 7—8
(citing Boucher 6:33-39, 7:63-8:9, 12:12-21, 12:51-55, 13:24—27, Fig. 4C)
Appellants argue Boucher does not teach “a remote cache manager to
detect an authorization code sent by a remote cache client.” App. Br. 10—12
Focusing on Boucher’s CCB (communication control block), Appellants
contend the CCB is not “an authorization code” used “to determine if the
packet is a candidate for fast-path processing” because packets have already
been selected for fast-path processing. Id. at 10. Additionally, Appellants
assert that the CCB is not sent by a remote cache client as recited but rather
calculated at the host. Id. at 11; Reply Br. 2—3. In Appellants’ view,
Boucher’s protocol of the packet header that is used to select packets for
fast-path processing is also not an authorization code and is not sent by a
remote cache client as recited. App. Br. 11.
Appellants further contend Boucher does not teach the recited
“delegation manager” because comparing the CCB to a hash of packet
information does not “constrain a remote cache memory associated with the
remote cache client to share data with a host cache memory via a bus” in
response to the detection of the authorization code as recited. App. Br. 12;
id. at 12—13.
3
Appeal 2017-004590
Application 14/122,994
ISSUES
Under § 103, has the Examiner erred in rejecting claim 1 by finding
Boucher and Cudak collectively would have taught or suggested:
(1) a remote cache manager to detect an authorization code sent by a
remote cache client and
(2) a delegation manager to constrain a remote cache memory
associated with the remote cache client to share data with a host cache
memory via a bus in response to the detection of the authorization code?
ANALYSIS
Based on the record before us, we find no error in the Examiner’s
rejection of independent claim 1.
(\)a remote cache manager to detect an authorization code sent by a
remote cache client
Appellants first contend that Boucher fails to teach the recited “remote
cache manager.” App. Br. 10. Boucher teaches a message packet is
received from the network by the CPD (communication processing device)
at step 47 and validated by a hardware assist. Boucher 6:33—34, cited in
Ans. 4; see also Boucher, Fig. 3. Boucher’s validation process includes
determining the protocol types of the various layers and validating packet
headers by receive logic 32 (e.g., a remote cache manager). Boucher 6:35—
36, 7:63—66, both cited in Ans. 4; see also Boucher, Fig. 4C, cited in Final
Act. 4. Additionally, Boucher teaches the message packets are sent from
remote host 22. See Boucher 7:21—23, 63—66, Figs. 4A, 4C. Boucher thus
teaches a remote cache manager (e.g., receive logic 32) receiving a packet,
including its headers, sent by a remote host.
4
Appeal 2017-004590
Application 14/122,994
Appellants state that “[tjhere is no mention in Boucher of a remote
cache client.” App. Br. 11. Identity of terminology between Boucher and
the claim language is not required to teach the limitations in claims. See In
re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990). As the Examiner indicates (see
Ans. 6 (citing Spec. 121)), the term “remote cache client” does not have a
particular meaning in the disclosure and includes a node (e.g., 222) remote
from a host (e.g., 202). See Spec. 121, Fig. 2. We thus are not persuaded
by Appellants’ argument that Boucher’s remote host 22 shown in Figures 4A
and 4C cannot correspond to the recited “remote cache client” of claim 1.
Turning to the issue of whether Boucher teaches a remote cache
manager “to detect an authorization code,” Appellants assert that the CCB is
not an authorization code because it “is not used to determine if the packet
is a candidate for a fast-path.” App. Br. 11. However, nothing in claim 1
limits the recited “authorization code” to a code that determines if a packet is
a candidate for fast-path. Id. at 19 (Claims App’x). Additionally, the
disclosure does not define the recited phrase “authorization code” with
reasonable clarity that the phrase has this argued meaning. Rather, the
disclosure discusses an example of “an authorized response code”
authorizing employment of coherency model communication procedures but
does not limit the meaning of “authorization code.” Spec. 121.
Even so, Boucher teaches selecting fast-path candidates (e.g., packets
or frames eligible for a fast-path connection) at step 59 based on whether the
host may benefit from such a connection being handled by the CPD,
including determining whether the packet has header bytes denoting
particular protocols, such as TCP/IP (Transmission Control Protocol/Intemet
Protocol) or SPX/IPX (Sequenced Packet Exchange/Intemet Packet
5
Appeal 2017-004590
Application 14/122,994
Exchange). Boucher 6:39-44, Fig. 3; see also Reply Br. 5 (reproducing this
passage in Boucher). Boucher further teaches those frames or packets that
are not fast-path candidates are sent for slow-path processing at step 61.
Boucher 6:44-46, Fig. 3. As such, Boucher teaches detecting header bytes
within a packet and determining whether the bytes denote particular
protocols in deciding whether the packet or frame is a fast-path candidate
(e.g., part of authorizing a fast-path connection). See id. at 6:39-46, Fig. 3.
Appellants contend “the protocol of the packet header” is not an
authorization code. App. Br. 11. Although we agree that the protocol itself
may not be an authorization code, the packet header bytes contain
information denoting particular protocols (e.g., code) and, as discussed
above, are used in the process of determining (e.g., authorizing) whether the
packet should be sent through a fast-path connection. See Boucher 6:56—64,
Fig. 3. Thus, the packet header bytes in Boucher reasonably correspond to
claim 1 ’s “authorization code” as broadly as recited. Accordingly, we need
not determine (1) whether or not the CCB or a hash in Boucher can
correspond to the recited “authorization code” or (2) whether Cudak cures
any purported deficiency as argued. App. Br. 10-12; Reply Br. 2-4.
(2) a delegation manager to constrain a remote cache memory
associated with the remote cache client to share data with a host cache
memory via a bus in response to the detection of the authorization code
Appellants further argue that Boucher does not teach the recited
“delegation manager.” App. Br. 12—13. Focusing on Boucher’s comparing
the CCB to a hash of the packet header information, Appellants contend this
teaching does not disclose “a delegation manager” that constrains the remote
cache memory to share data with a host cache memory in response to
6
Appeal 2017-004590
Application 14/122,994
detecting the authorization code or based on an authorization code. App. Br.
12—13; Reply Br. 4. We disagree.
To be sure, Boucher teaches processor 55 (e.g., a delegation manager)
checks for a match between the hash and each CCB stored in cache 62 at
step 53, and when finding a match, sending data 70 through a fast-path to
storage 35 over connection 72 at step 69. Boucher 8:3—8, Figs. 3, 4C. Yet,
as discussed above, Boucher’s Figure 3 also determines fast-path candidates
at step 59 (e.g., detects an authorization code) prior to the matching at step
53 and sending a packet or frame over a fast-path connection (e.g., 72) at
step 69. Boucher 6:37-44, 7:62—66, Fig. 3. Granted, processor 55 (e.g.,
delegation manager) does not constrain sharing of data through a bus in
direct response to detecting specific packet header bytes or information (e.g.,
an authorization code as explained above). Even so, claim 1 does not
require a direct correlation between detecting an authorization code and
constraining memories to share data. As such, Boucher teaches the recited
“delegation manager” constrains sharing data over connection 72 (e.g., a
bus) “in response to detection of the authorization code” as broadly recited
in claim 1.
For the foregoing reasons, Appellants have not persuaded us of error
in the rejection of independent claim 1 and dependent claims 2, 4, and 5 not
separately argued.
Claims 9, 10, 12—14, 19, 20, 22, and 23
Regarding claims 9 and 19,2 Appellants contend the rejection must be
reversed “for at least the reasons explained above.” App. Br. 14. Dependent
2 Unlike claims 1 and 9, claim 19 does not recite the detected authorization
code is sent by a remote cache client or memory. Appellants’ arguments
7
Appeal 2017-004590
Application 14/122,994
claims 10, 12—14, 20, 22, and 23 are not separately argued. See id. We
select independent claims 9 and 19 as representative. 37 C.F.R.
§ 41.37(c)(l)(iv). We are not persuaded the Examiner erred in rejecting
independent claims 9 and 19 for the reasons previously set forth.
Accordingly, Appellants have not persuaded us of error in the
rejection of independent claims 9 and 19 and dependent claims 10, 12—14,
20, 22, and 23, which are not separately argued.
Claims 6, 7, 15, 16, 24, and 25
Claim 6 indirectly depends from claim 1 and further recites “the lock
manager is to prevent release of the read lock for a time-to-live duration in
response to a release by the first request node.” App. Br. 19 (Claims
App ’x). The Examiner determines Boucher does not teach the above
recitation, turning to Cudak. Final Act. 7 (citing Cudak 138); see also
Ans. 9. In the Response to Arguments section, the Examiner explains the
wait time taught by Cudak is “consistent with the time-to-live duration of the
claimed invention” and that the claim language does not recite “a
predetermined or preset time-to-live duration.” Ans. 9 (emphasis omitted).
Appellants argue Boucher and Cudak do not teach claim 6’s
limitations. App. Br. 14. In particular, Appellants assert Cudak’s cited
teaching does not “mention a ‘time-to-live’ duration or ‘live’” and does not
prevent “release of a read lock for a time-to-live duration in response to a
release by the first request node.’ [sic].” Id. at 15 (citing Cudak 138).
Appellants argue the Examiner construes the term “time-to-live”
unreasonably broad, and the recited “‘time-to-live duration’ as set forth in
related in this regard (App. Br. 9—12; Reply Br. 2—6) are not commensurate
with the scope of claim 19.
8
Appeal 2017-004590
Application 14/122,994
claim 6 indicates a predetermined or preset time.” Reply Br. 7 (citing Spec.
131).
The phrase “time-to-live duration” is not defined in the disclosure
with clarity or precision. See generally Spec. The Specification discusses
an “illustrated example of FIG. 7B” and an “example remote cache manager
308 and/or the example host cache manager 306” that determine whether to
transition the lock to the AVAIL state when three conditions occur,
including when “a time-to-live (TTL) threshold or timer” expires. Spec.
131, Figs. 3, 7B. Although this informs our construction of the recited
phrase, we decline to import such an embodiment into claim 1.
As such, we construe the phrase “time-to-live duration” with its
ordinary and customary meaning to one of ordinary skill in the art. See In re
Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Turning to
several dictionaries, Microsoft Computer Dictionary defines “time to live”
or TTL as “[a] header field for a packet sent over the Internet indicating how
long the packet should be held.” Microsoft Computer Dictionary 521
(5th ed. 2002). Wiley Electrical & Electronics Engineering Dictionary
defines “time to live” (TTL) as “[a] value in a header which indicates
whether a given packet has exceeded the time or number of hops it is
permitted for travel within a network .... When the value reaches zero, the
packet is discarded ....” Steven M. Kaplan, Wiley Electrical &
Electronics Engineering Dictionary 792 (2004). Finally, Newton’s
Telecom Dictionary defines “time to live” (TTL) as “[a] timer value
included in packets sent over TCP/IP-based networks that tells the recipients
how long to hold or use the packet or any of its included data before expiring
9
Appeal 2017-004590
Application 14/122,994
and discarding the packet or data.” Harry Newton, Newton’s Telecom
Dictionary 914 (22d ed. 2006).
Each of these definitions indicates that the meaning of “time to live”
includes an established or designated length or a value to hold a packet or
data. Two of the definitions also include the concept of a timer value that
expires before packets or data are discarded. Given these customary
meanings to one of ordinary skill in the art, we construe the phrase “time-to-
live duration” in the context of claim 6 to mean an established length of time
or duration, and that the recited “lock manager” is to hold or prevent release
of the read lock for this established duration until expiry. As such, the
Examiner’s understanding of “a time-to-live duration” in claim 6 is too
broad when considering how the ordinarily skilled artisan would have
construed this phrase. See Ans. 9 (stating a time-to-live duration is not
predetermined).
We agree with Appellants that Cudak’s paragraph 38 does not teach
the recited “lock manager” of claim 6 that prevents release of the read lock
for the recited “time-to-live duration.” App. Br. 13—14. Cudak teaches three
servers 214, 216, and 218 and a file stored in cache 220 of server 214 may
be locked from access by servers 216 and 218 to maintain coherency.
Cudak 138. If server 216 attempts to access the file of server 214, Cudak
discloses that server 216 may have to wait for server 214 to release a lock on
the file. Cudak 138. Although Cudak’s “wait time” is a duration that the
server’s request is held before releasing the file lock (see Ans. 9), this wait
time is not an established or timed length or duration. See Cudak 138.
Rather, Cudak discloses a nondescript wait time and does not teach or
suggest how the other server (e.g., 214) determines to release the lock on the
10
Appeal 2017-004590
Application 14/122,994
file. See id. Nor does Cudak teach the concept of preventing releasing of
the lock for an established or timed length/duration until expiry. See id.
Additionally, Cudak further states the delay in accessing the file is not
experienced when storing it in cache 204. Id.
Cudak therefore fails to teach or suggest “the lock manager is to
prevent release of the read lock for a time-to-live duration in response to a
release by the first request node” as recited in claim 6.
For the foregoing reasons, Appellants have persuaded us of error in
the rejection of (1) claim 6, (2) claims 15 and 24, which recite
commensurate limitations, and (3) dependent claims 7, 16, and 253 for
similar reasons.
THE REMAINING OBVIOUSNESS REJECTION
Claims 26—28 are rejected under 35 U.S.C. § 103 based on Boucher,
Cudak, and Whitehouse. Final Act. 8—10. Claim 26 depends from claim 1;
claim 27 depends from claim 9; claim 28 depends from claim 24. App. Br.
22 (Claims App’x). The claims are not separately argued. See App. Br.
9—17. We sustain the rejection of claims 26 and 27 and refer to the above
discussion of independent claims 1 and 9 for details. We reverse the
rejection of claim 28 due to its dependency on claim 24.
3 Appellants refer to claims 15, 16, 24, and 25 as “independent claims.”
App. Br. 15, 17. We presume this is a typographical error, intending to
describe these claims as “dependent” given that they depend indirectly from
independent claims 9 or 19. App. Br. 20-22 (Claims App’x).
11
Appeal 2017-004590
Application 14/122,994
DECISION
We affirm the Examiner’s rejections of claims 1, 2, 4, 5, 9, 10, 12—14,
19, 20, 22, 23, 26, and 27 under § 103.
We reverse the Examiner’s rejections of claims 6, 7, 15, 16, 24, 25,
and 28 under § 103.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l)(iv).
AFFIRMED-IN-PART
12