Ex Parte Liu

Patent Trial and Appeal Board

Apr 29, 2016

13173490 (P.T.A.B. Apr. 29, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
13/173,490 06/30/2011
7590 04/29/2016
Robert D. Shedd, THOMSON LICENSING LLC
PA TENT OPERA TIO NS
P. 0. BOX 5312
PRINCETON, NJ 08543-5312
FIRST NAMED INVENTOR
HANG LIU
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
ATTORNEY DOCKET NO. CONFIRMATION NO.
PU050252 US DIVl 9225
EXAMINER
SINKANTARAKORN,PAWARIS
ART UNIT PAPER NUMBER
2464
MAILDATE DELIVERY MODE
04/29/2016 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 HANG LIU
Appeal2014-007270
Application 13/173 ,490
Technology Center 2400
Before JEAN R. HOMERE, JOSEPH P. LENTIVECH, and
KARA L. SZPONDOWSKI, Administrative Patent Judges.
LENTIVECH, Administrative Patent Judge.
DECISION ON APPEAL
Appellant 1 seeks our review under 35 U.S.C. § 134(a) of the
Examiner's final rejection of claims 1-34, the only claims pending in the
application on appeal. We have jurisdiction over the pending claims under
35 U.S.C. § 6(b).
We affirm.
1 According to Appellant, the real party in interest is Thomson Licensing.
App. Br. 3.
Appeal2014-007270
Application 13/173,490
STATEMENT OF THE CASE
Appellant's Invention
Appellant's invention generally relates to processing route request
messages in on-demand routing protocols such as, for example, the Ad Hoc
On-demand Distance Vector (AODV) routing protocol. Spec. 1:6-12.
Claim 1, which is representative, reads as follows:
1. A method, said method comprising:
receiving a route reply message responsive to a route
request message from a first intermediate node in a wireless
network, wherein a first intermediate node having a valid route
responds to a route request message based on a condition of a
flag in said route request message, wherein said first
intermediate node resets said flag;
establishing communications between a source node and
a destination node using said valid route;
receiving in unicast a further route reply message from
said destination node, said further route reply message
including a best route selected by said destination node based
on cumulative metrics received in route request messages
received by said destination node;
establishing communications between said source node
and said destination node by replacing said valid route with said
best route.
Rejections
Claims 1-34 stand rejected on the ground of non-statutory
obviousness-type double patenting as being unpatentable over claims 1-38
of Liu (US 8,064,416 B2; Nov. 22, 2011). Final Act. 6.
Claims 1-3, 6-9, and 12-34 stand rejected under 35 U.S.C. § 102(b)
as being anticipated by Rune et al. (US 2004/0167988 Al; Aug. 26, 2004).
Final Act. 7-13.
2
Appeal2014-007270
Application 13/173,490
Claims 4, 5, 10, and 11 stand rejected under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Rune and Zeng et al. (US
2006/0007882 Al; Jan. 12, 2006). Final Act. 14--16.
ANALYSIS 2
Double Patenting Rejection
Appellant states they are willing to file a terminal disclaimer to
overcome the double patenting rejection of claims 1-34 upon the claims
otherwise being in condition for allowance, but Appellant does not otherwise
address the double-patenting rejection, and does not provide argument
regarding either the merits or substance of the double patenting rejection.
App. Br. 6.
In light of the tentative nature of Appellant's offer to file a terminal
disclaimer, and lack of argument by Appellant regarding the merits and
substance of the double-patenting rejection, we summarily sustain the
Examiner's rejection of claims 1-34 for obviousness-type double patenting.
37 C.F.R. § 41.37(c)(l)(iv).
§ 102 Rejection
Issue 1 : Did the Examiner err by finding that Rune discloses
receiving a route reply message responsive to a route
request message from a first intermediate node in a wireless
network, wherein a first intermediate node having a valid route
responds to a route request message based on a condition of a
2 Our decision refers to Appellant's Amended Appeal Brief filed January
14, 2014 ("App. Br."); Appellant's Reply Brief filed June 18, 2014 ("Reply
Br.); the Final Office Action mailed June 2, 2013 ("Final Act."); Examiner's
Answer mailed April 22, 2014 ("Ans."); and original Specification filed
June 30, 2011 ("Spec.").
3
Appeal2014-007270
Application 13/173,490
flag in said route request message, wherein said first
intermediate node resets said flag,
as recited in claim 1?
Appellant contends the Examiner erred in finding Rune discloses the
disputed limitation. App. Br. 9; Reply Br. 2-3. Particularly, Appellant
contends "Rune nowhere teaches or suggests a flag except at paragraph 230
where the flag is locally set by the nodes to indicate that they are to expect
an extra NAP [Non-significant Address Part] beacon." App. Br. 9.
We do not find Appellant's contention persuasive. The Examiner
finds Rune discloses using the Ad Hoc On-demand Distance Vector
(AODV) protocol to broadcast route request (RREQ) messages. Ans. 11
(citing Rune i-fi-120, 22, 24, 84). The Examiner further finds Rune teaches if
an intermediate node already has a route entry for a certain destination node,
the intermediate node may return a route reply (RREP) message upon
receiving a route request. Id. Contrary to Appellant's contention, the
Examiner does not find Rune expressly teaches that the intermediate node
returns the route reply message based upon a condition of a flag included in
the route request message. Instead, the Examiner finds Rune inherently
teaches this limitation. Final Act. 3--4, 7; Ans. 11-13 (citing Perkins et al.,
Ad Hoc On-Demand Distance Vector (AODV) Routing, Network Working
Group, RFC 3561§5.1, ©The Internet Society (2003)). Particularly, the
Examiner finds a route request message, broadcast according to the AODV
protocol, inherently includes a "destination only" flag-a flag indicating
whether only the destination node may respond to the route request
message- and that the flag must be set to "NO" for the intermediate node to
return the route reply message, as disclosed by Rune. Id. Appellant
4
Appeal2014-007270
Application 13/173,490
addresses this finding for the first time in the Reply Brief Reply Br. 2-3.
As these arguments are not responsive to an argument presented for the first
time in the Examiner's Answer, and good cause has not been shown as to
why the arguments were not earlier presented, the arguments will not be
considered for the purposes of this appeal. 3 7 C.F .R. § 41.41 (b )(2 ). As
such, Appellant has failed to persuasively show the Examiner erred in
finding Rune discloses the disputed limitation.
Issue 2: Did the Examiner err by finding Rune discloses
receiving in unicast a further route reply message from
said destination node, said further route reply message
including a best route selected by said destination node based
on cumulative metrics received in route request messages
received by said destination node,
as recited in claim 1?
Appellant contends the Examiner erred in finding Rune discloses the
disputed limitation because "the route request message of the present
invention includes both the hop count and the routing metric and the
destination node selects the best route based on the cumulative metric not as
in Rune based solely on the hop count." App. Br. 9. Appellant further
contends "Rune does not update to use a better route except on hop count
not based on cumulative metrics." App. Br. 10. In other words, Appellant
contends Rune's hop count is a metric, and not cumulative metrics, as
required by claim 1. Reply Br. 3.
We do not find Appellant's contentions persuasive. Rune discloses
that when a receiving node (e.g., the destination node) receives a route
request message and does not have a route entry for the source node, the
5
Appeal2014-007270
Application 13/173,490
receiving node creates a new route entry for the source node. Rune il 97.
Rune discloses that when the destination node receives a subsequent route
request message, the destination node replaces the existing route entry based
on the route identified in the subsequent route request message or keeps the
existing route according to a hop count comparison procedure. Rune i-f 98.
Rune discloses that the hop count comparison procedure includes comparing
a hop count associated with the existing route to a hop count associated with
the route identified in the subsequent route request message. Rune i-f 95.
Rune discloses that the destination node sends a route reply to the source
node using the route entry (either the existing route entry or the new route
entry as determined by the hop count comparison procedure). Rune,
therefore, discloses that the route reply message includes a best route
selected by the destination node based on hop counts received in route
request messages received by the destination node.
Appellant's Specification does not expressly define the term
"cumulative metrics." Appellant's Specification does define a new metric
included in the route request message as "the metric in the RREQ message
plus the link metric between the node from which it received RREQ
message and itself." Spec. 8: 16-1 7. As such, the broadest reasonable
definition consistent with Appellant's Specification of the term "cumulative
metrics" includes a metric that corresponds to the metric in the route request
message plus the metric between the node from which the route request
message was received and the receiving node. Appellant acknowledges that
hop count is a metric. Reply Br. 3. Further, the Examiner finds, and we
agree, Rune discloses that the hop count is updated by each node as the route
request message is forwarded to the destination node. Ans. 14 (citing Rune
6
Appeal2014-007270
Application 13/173,490
ilil 87, 88, 95). As such, Rune's hop count comparison procedure selects the
best route based on cumulative metrics included in route request messages
received by the destination node.
Accordingly, we are not persuaded the Examiner erred in finding
Rune discloses the disputed limitation.
For the foregoing reasons, we are not persuaded the Examiner erred in
rejecting claim 1. Regarding the rejection of claims 2, 3, 6-9, and 12-34,
Appellant relies on the arguments presented for patentability of claim 1. See
App. Br. 11. Accordingly, we are not presented the Examiner erred in
rejecting these claims for the same reasons.
§ 103 Rejection
Regarding the rejection of claims 4, 5, 10, and 11, Appellant relies on
the arguments presented for patentability of claim 1. See App. Br. 11.
Accordingly, we are not presented the Examiner erred in rejecting these
claims for the reasons discussed supra with respect to claim 1.
DECISION
We affirm the Examiner's rejections of claims 1-34.
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
7