Ex Parte HANDownload PDFPatent Trial and Appeal BoardSep 29, 201612689385 (P.T.A.B. Sep. 29, 2016) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE 12/689,385 01119/2010 68103 7590 10/03/2016 Jefferson IP Law, LLP 1130 Connecticut Ave., NW, Suite 420 Washington, DC 20036 FIRST NAMED INVENTOR Kyung-Wan HAN 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. 0202-0333 5746 EXAMINER HOPKINS, MATTHEW A ART UNIT PAPER NUMBER 2463 NOTIFICATION DATE DELIVERY MODE 10/03/2016 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): usdocketing@jeffersonip.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte KYUNG-WAN HAN Appeal2015-002473 Application 12/689,385 Technology Center 2400 Before CARLA M. KRIVAK, JASON V. MORGAN, and BRUCE R. WINSOR, Administrative Patent Judges. WINSOR, Administrative Patent Judge. DECISION ON APPEAL Appellant1 appeals under 35 U.S.C. § 134(a) from the final rejection of claims 1-20, which constitute all the claims pending in this application. We have jurisdiction under 35 U.S.C. § 6(b). We REVERSE. STATEMENT OF THE CASE Appellant's disclosed invention "relates to ... transmitting a control packet in a broadband Wide Area Network (WAN). More particularly, the ... invention relates to ... preventing a link from failing due to a loss of a 1 The real party in interest identified by Appellant is Samsung Electronics Co., Ltd. App. Br. 2. Appeal2015-002473 Application 12/689,385 control packet in a broadband WAN." Spec. if 2. Claim 1, which is illustrative, reads as follows: 1. A method for transmitting a control signal for determining a keep alive status of a counterpart node in a broadband communication network, the method comprising: when a period for determining a keep alive status of the counterpart node to which a data link is connected arrives, determining whether traffic is received from the counterpart node; if it is determined that the traffic is received from the counterpart node, determining the keep alive status of the counterpart node using the traffic received from the counterpart node; and if it is determined that the traffic is not received from the counterpart node, transmitting a request signal for determining the keep alive status of the counterpart node to the counterpart node, wherein when the keep alive status of the counterpart node is determined using the traffic, the request signal is not transmitted to the counterpart node. Claims 1-20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Payyappilly et al. (US 2009/0003208 Al; Jan 1, 2009) (hereinafter "Payyappilly") and Duggirala et al. (US 2006/0182141 Al; Aug. 17, 2006) (hereinafter "Duggirala"). See Final Act. 5-16. Rather than repeat the arguments here, we refer to the Briefs ("App. Br." filed May 21, 2014; "Reply Br." filed Dec. 23, 2014) and the Specification ("Spec." filed Jan. 19, 2010) for the positions of Appellant and the Final Office Action ("Final Act." mailed May 7, 2013), Advisory Action ("Adv. Act." mailed Aug. 1, 2013), and Examiner's Answer ("Ans." mailed Oct. 24, 2014) for the reasoning, findings, and conclusions of the Examiner. 2 Appeal2015-002473 Application 12/689,385 ISSUE The dispositive issue presented by Appellant's contentions is whether the Examiner errs in finding the combination of Payyappilly and Duggirala teaches or suggests: when a period for determining a keep alive status of the counterpart node to which a data link is connected arrives, it is determined whether traffic is received from the counterpart node; if it is determined that the traffic is received from the counterpart node, the keep alive status of the counterpart node is determined using the traffic received from the counterpart node. App. Br. 4 (discussing claims 1 and 11 ). ANALYSIS Appellant contends Payyappilly teaches changing the area over which a Link Control Protocol (LCP) Echo Request Packet, i.e., a keep alive request signal, is transmitted based on a location of an access terminal determined at the time the LCP Request Echo Packet is to be sent. App. Br. 5 (citing Payyappilly i-f 50). Appellant further contends Duggirala teaches monitoring the number of clients and average number of requests per client to adjust the keep alive request specification. (App. Br. 5 (referring without citation to Duggirala i-f 41 ). Appellant explains as follows: Appellant submits that Payyappilly does not disclose that traffic is regularly monitored, and that [Duggirala] does not indicate the time of monitoring the current operating conditions. In this regard, even if combined, the Examiner's combination of Payyappilly and [Duggirala] would not have taught or suggested determining whether traffic is received from the counterpart node when a period for determining a keep-alive status arrives, as claimed. In addition, [Duggirala] controls the keep-alive status by monitoring the current operating conditions based on the total 3 Appeal2015-002473 Application 12/689,385 number of clients and the average number of requests per client. This differs from the present claims, wherein the keep-alive status of the counterpart node is determined based on whether traffic is received from the counterpart node. Moreover, [Duggirala] enables or disables dynamic keep-alive by controlling the keep-alive specification, whereas the present claims do not refer to transmitting a request signal to determine the keep-alive status to the counterpart node when traffic is received from the node. [Duggirala] does not describe disabling keep-alive when traffic is received, accordingly, [Duggirala] does not disclose the claimed reference to, when traffic is received from the node, a keep-alive status is determined using the received traffic, and a request signal to determine the keep- alive status is not transmitted to the counterpart node. Reply Br. 2. We agree with Appellant for the reasons stated by Appellant. The Examiner finds that although Payyappilly teaches adjusting aspects of a keep-alive request signal based on a determination made at the time the request signal is to be sent, Payyappilly does not teach not transmitting the request signal to a counterpart node if it is determined traffic is received from the counterpart node. Ans. 7 (citing Payyappilly i-fi-f l 0, 50, 54 ). We agree. The Examiner then explains Duggirala remedies this deficiency as follows: Duggirala remedies this deficiency by monitoring the traffic for specific nodes in determining the number of requests and average number of requests per node (i-f 41 ). By monitoring individual traffic to a node, Duggirala can determine a keep alive mode to enable echo requests during periods where the data traffic activity falls. (i-f 31-i-f 32). [Duggirala] discloses a 10 millisecond time period to monitor data traffic in order to ascertain whether keep alive messages may be enabled. (See i139). If the data traffic between two nodes meets certain thresholds, [Duggirala]] discloses adjusting the keep-alive specifications to optimize the network transmission. 4 Appeal2015-002473 Application 12/689,385 (See if 40). [Duggirala]discloses using the traffic between nodes (using traffic received from counterpart) to determine that the keep alive messages should be sent or not sent (disabled) (See ir 36, ir 41-42). Ans. 7-8. Even accepting, arguendo, the Examiner's characterization of Duggirala, the Examiner has not demonstrated the combination of Payyappilly and Duggirala teaches or suggests the invention of claim 1. In particular, Duggirala teaches "the keep-alive autonomic adjustment mechanism 124 may autonomically enable and disable the keep-alive mechanism 126 in addition to autonomically adjusting the keep-alive specification 127. In this manner keep-alives may be disabled if the current operating conditions so warrant." Duggirala if 31 (bold-facing omitted, italics added). Duggirala further teaches the following: In the case of few clients and few requests per client in row 510 of PIG. 5, the load on the server is very light, so any performance enhancement provided by enabling keep-alives would be minimal. As a result, the keep-alive autonomic adjustment mechanism 124 could disable keep-alives, as shown in row 510 of PIG. 5. Id. if 36 (bold-facing of numbers omitted, italics added); see also id. if 38. Thus, although Duggirala does teach disabling the sending of keep- alive request signals (i.e., "the request signal is not transmitted to the counterpart node," as recited in claim 1 ), it teaches doing so in response to determining that server load is low, not in response to "determining whether traffic is received from the counterpart node [when a period for determining a keep alive status of the counterpart node to which a data link is connected arrives]" as recited in claim 1. The Examiner does not articulate any 5 Appeal2015-002473 Application 12/689,385 rationale that fills the gaps in the combined teachings of Payyappilly and Duggirala (i.e., the determination of whether traffic is received as recited). We conclude the Examiner has failed to establish a prima facie case of obviousness of claim 1. Accordingly, constrained by the record before us, we are unable to sustain the rejections of (1) claim 1; (2) independent claim 11, which was rejected on a similar basis as claim 1 (compare Final Act. 11- 12 with id. at 5-7) and was argued together with claim 1 (App. Br. 4--5); and (3) claims 2-10 and 12-20 which depend, directly or indirectly, from claims 1 and 11 respectively, see In re Fine, 837 F.2d 1071, 1076 (Fed. Cir. 1988) ("Dependent claims are nonobvious under section 103 if the independent claims from which they depend are nonobvious. "). DECISION The decision of the Examiner to reject claims 1-20 is reversed. REVERSED 6 Copy with citationCopy as parenthetical citation