Ex Parte Liu

Patent Trial and Appeal BoardApr 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