Ex Parte JiangDownload PDFPatent Trial and Appeal BoardJun 13, 201613481273 (P.T.A.B. Jun. 13, 2016) Copy Citation UNITED STA TES p A TENT AND TRADEMARK OFFICE APPLICATION NO. FILING DATE 13/481,273 05/25/2012 77399 7590 06/15/2016 Leydig, Voit & Mayer, Ltd (for Huawei Technologies Co., Ltd) Two Prudential Plaza Suite 4900 180 North Stetson Avenue Chicago, IL 60601 FIRST NAMED INVENTOR Wu JIANG 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. HW710465 9361 EXAMINER P ALIW AL, YOGESH ART UNIT PAPER NUMBER 2435 NOTIFICATION DATE DELIVERY MODE 06/15/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): Chgpatent@leydig.com uspatent@huawei.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte WU JIANG Appeal 2015-001103 Application 13/481,273 Technology Center 2400 Before JAMES R. HUGHES, CATHERINE SHIANG, and LINZY T. McCARTNEY, Administrative Patent Judges. SHIANG, Administrative Patent Judge. DECISION ON APPEAL Appellant appeals under 35 U.S.C. § 134(a) from the Examiner's rejection of claims 1, 3, 4, 7, and 9--11, which are all the claims pending in the application. We have jurisdiction under 35 U.S.C. § 6(b). We affirm. STATEMENT OF THE CASE Introduction The present invention relates to network security technologies. See generally Spec. 1. Claim 1 is exemplary: 1. A method for alerting against unknown malicious codes, compnsmg: detecting, by a network device, characteristics of a packet; Appeal2015-001103 Application 13/481,273 judging, by the network device, whether any suspicious code exists m the packet according to a result of the detection; recording, by the network device, a source address of the suspicious code if the suspicious code exists in the packet, wherein the source address appears in the URL after a get * string; and sending, by the network device, alert information that carries the source address to a monitoring device; wherein the network device detecting the characteristics of the packet comprises at least one of the group consisting of: (a) detecting, by the network device, whether a name of the suspicious code exists in a data stream; and (b) detecting, by the network device, whether a file header of the suspicious code exists in the data stream. References and Rejections Claims 1, 3, 4, 7, and 9-11 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Gupta et al. (US 2003/0009699 Al; publ. Jan. 9, 2003) ("Gupta") and Bates et al. (US 2004/0148281 Al; publ. July 29, 2004) ("Bates"). ANALYSIS On this record, we find the Examiner did not err in rejecting claim 1. We disagree with Appellant's arguments, and adopt the Examiner's findings and conclusions in (i) the Action from which this appeal is taken and (ii) the Answer to the extent they are consistent with our analysis below. Therefore, we provide the following for emphasis. Appellant contends Gupta and Bates do not collectively teach the claimed "source address." See App. Br. 5-11; Reply Br. 2-5. As a result, 2 Appeal2015-001103 Application 13/481,273 Appellant argues the references do not teach "recording ... a source address of the suspicious code ... wherein the source address appears in the URL after a get * string; and sending ... alert information that carries the source address to a monitoring device," as recited in claim 1 (emphases added). See App. Br. 6, 10. In particular, Appellant argues neither reference teaches the claimed "source address" because the Specification's paragraphs 24 and 27 expressly distinguish the term from a text string identifying a file name, and the term must specify a networked source or actual physical source of the suspicious code. See App. Br. 7-11; Reply Br. 2-5. Appellant contends Bates does no teach the sending claim limitation because Bate merely describes sending a URL and does not state the URL specifies a source address. See App. Br. 6, 10. Appellant has not persuaded us of error. It is well established that during examination, claims are given their broadest reasonable interpretation consistent with the specification, but without importing limitations from the specification. See In re Am. Acad. of Sci. Tech Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004); SuperGuide Corp. v. DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004). Therefore, under the broadest reasonable interpretation, the Examiner reasonably interprets the claim element "source address" to encompass Gupta's "/dirl/dir2/dvwssr.dll." See Ans. 3. The Examiner's interpretation is reasonable because "/dirl/dir2/dvwssr.dll" is an address that identifies the source, which is the directory dirl and subdirectory dir2. See Ans. 3. Further, the Examiner's interpretation is consistent with the claim, because the Examiner finds-and Appellant does not dispute- "/ dir 1/ dir2/ dvwssr.dll" appears in the URL after a get* string. See Ans. 3- 3 Appeal2015-001103 Application 13/481,273 4; Gupta ilil 102, 105. As discussed below, the Examiner's interpretation is also consistent with the Specification. Appellant has not shown the Examiner's mapping is unreasonable. Appellant cites paragraphs 24 and 27 of the Specification, which state: [0024] Specifically, at the time of detecting whether the name of the suspicious code is included in the packet, if a string like get * .exe is detected in the packet, it indicates that an executable file is being transmitted, in which * .exe is a suspicious code, and * represents a string of a random length. The executable file may leak information of the terminal user, damage the terminal system, or even let the terminal be controlled by the attacker. Or, if a packet includes strings like get * .dll or get * .ocx, it indicates that an executable file or a string of malicious codes is being transmitted, which may leak information of the terminal user, damage the terminal system, or even let the terminal be controlled by the attacker. Such codes need to be reported. [0027] The source of the susp1c10us code needs to be located after the suspicious code is detected. Specifically, if the suspicious code is detected by checking whether the name of the suspicious code is included in the data stream, the source address generally appears in the URL after get. If the suspicious code is detected by checking whether the file header of the suspicious code is included in the data stream, the source address of the packet may be searched out according to the information in the packet. If both of the detection methods are applied in detecting the suspicious code, the source address generally appears in the URL after get. Spec. i-fi-124, 27 (emphasis added). But Appellant has not provided persuasive explanation to support the assertion that paragraphs 24 and 27 "expressly distinguish[] the claimed 'source address' ... from a text string identifying afile name." App. Br. 7. To the contrary, paragraph 27 states "if the suspicious code is detected by 4 Appeal2015-001103 Application 13/481,273 checking whether the name of the suspicious code is included in the data stream, the source address generally appears in the URL after get" (emphasis added). Therefore, the Examiner's above interpretation is consistent with the Specification. Further, Appellant's assertion that the term must specify a networked source or actual physical source of the suspicious code (App. Br. 11; Reply Br. 4) is not commensurate with the scope of the claim and therefore, unpersuasive. See Ans. 5-6. Finally, because the Examiner relies on the combination of Gupta and Bates to teach the claim, Appellant cannot establish nonobviousness by attacking the references individually. See In re Merck & Co., Inc., 800 F.2d 1091, 1097 (Fed. Cir. 1986). The Examiner relies on Gupta and Bates collectively to teach the sending claim limitation. See Ans. 9. Because Gupta teaches the claimed source address, Bates does not need to teach that term separately. See Ans. 9. Accordingly, we sustain the Examiner's rejection of claim 1, and claims 3--4 for similar reasons. For similar reasons, we sustain the Examiner's rejection of claims 7 and 11, and dependent claims 9-10. Reply Brief To the extent Appellant advances new arguments in the Reply Brief without showing good cause, Appellant has waived such arguments. See 37 C.F.R. § 41.41(b)(2). 5 Appeal2015-001103 Application 13/481,273 DECISION We affirm the Examiner's decision rejecting claims 1, 3--4, 7, and 9-- 1 1. 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 6 Copy with citationCopy as parenthetical citation