`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`
`JUNIPER NETWORKS, INC.,
`“Petitioner” or “Juniper”
`
`v.
`
`HUAWEI DIGITAL TECHNOLOGIES (CHENG DU) CO., LIMITED.,
`“Patent Owner” or “Huawei”
`___________
`
`U.S. Patent No. 10,027,693
`
`Issued: July 17, 2018
`
`
`Named Inventor:
`Wu JIANG
`
`
`Title:
`Method, Device and for Alerting Against Unknown Malicious Codes within a
`Network Environment
`___________
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 10,027,693
`
`
`
`
`Mail Stop: PATENT BOARD
`Patent Trial and Appeal Board
`U.S. Patent & Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`10832643
`
`
`
`
`

`

`TABLE OF CONTENTS
`
`Page
`INTRODUCTION ........................................................................................ 1
`
`STATE OF THE ART .................................................................................. 3
`
`I.
`
`II.
`
`III. BACKGROUND AND OVERVIEW OF THE CHALLENGED
`PATENT ....................................................................................................... 5
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`The Specification of the Parent ’206 Patent ....................................... 6
`
`Prosecution History of the Parent ’206 Patent ................................... 8
`
`The Specification of the ’693 Patent ................................................ 11
`
`Prosecution History of the ’693 Patent ............................................ 13
`
`The Challenged Claims of the ’693 Patent ...................................... 15
`
`IV. PRIORITY DATE OF THE CHALLENGED CLAIMS ........................... 16
`
`A.
`
`B.
`
`Legal Standard for Claiming the Benefit of an Earlier Filed
`Application ....................................................................................... 16
`
`Summary of Unsupported Subject Matter Added to the
`Specification of the ’693 Patent ....................................................... 19
`
`i.
`
`ii.
`
`iii.
`
`Huawei Expanded the ’693 Patent to Include New
`Types of File Requests not Supported by the ’206
`Patent ...................................................................................... 19
`
`Huawei Expanded the ’693 Patent to Cover FTP
`Communications .................................................................... 26
`
`The Claimed Network Device is Unsupported by the
`’206 Patent ............................................................................. 30
`
`iv.
`
`Conclusion ............................................................................. 32
`
`V. DISCRETIONARY FACTORS ................................................................. 33
`
`10832643
`
`
`- i -
`
`

`

`Page
`§ 325(d) Does Not Favor Denial ...................................................... 33
`
`§ 314(a) Does Not Favor Denial ...................................................... 37
`
`A.
`
`B.
`
`VI.
`
`IDENTIFICATION OF CHALLENGE AND GROUNDS ....................... 39
`
`VII. LEVEL OF ORDINARY SKILL IN THE ART ........................................ 39
`
`VIII. CLAIM CONSTRUCTION ....................................................................... 40
`
`A.
`
`“detecting the [executable] file” (Claims 1, 3, 5)............................. 40
`
`IX. GROUND 1: THE CHALLENGED CLAIMS ARE OBVIOUS
`OVER THE ’691 PUBLICATION ............................................................ 41
`
`A. Overview of Ground 1 ...................................................................... 41
`
`B.
`
`C.
`
`D.
`
`E.
`
`F.
`
`G.
`
`H.
`
`I.
`
`J.
`
`Claim 1 ............................................................................................. 41
`
`Claim 2 ............................................................................................. 53
`
`Claim 3 ............................................................................................. 54
`
`Claim 4 ............................................................................................. 56
`
`Claim 5 ............................................................................................. 56
`
`Claim 6 ............................................................................................. 59
`
`Claim 7 ............................................................................................. 60
`
`Claim 8 ............................................................................................. 60
`
`Claim 9 ............................................................................................. 61
`
`X.
`
`STATUTORY REQUIREMENTS ............................................................ 61
`
`A. Notice of Real Party-In-Interest (37 C.F.R. § 42.8(b)(1)) ............... 61
`
`B.
`
`Notice of Related Matters (37 C.F.R. § 42.8(b)(2)) ......................... 61
`
`10832643
`
`
`- ii -
`
`

`

`Page
`
`C.
`
`D.
`
`E.
`
`F.
`
`Designation of Lead And Back-Up Counsel (37 C.F.R.
`§ 42.8(b)(3)) ..................................................................................... 62
`
`Service Information (37 C.F.R. § 42.8(b)(4)) .................................. 62
`
`Fees ................................................................................................... 62
`
`Grounds for Standing ....................................................................... 62
`
`XI. CONCLUSION ........................................................................................... 62
`
`
`
`10832643
`
`
`- iii -
`
`

`

`
`
`EXHIBIT LIST
`
`Exhibit Description
`EX1001 U.S. Patent No. 10,027,693 (“the ’693 patent”)
`
`EX1002 File History of the ’693 patent
`
`EX1003 U.S. Patent No. 9,674,206 (“the ’206 patent”)
`
`EX1004 File History of the ’206 patent
`
`Declaration of Dr. Seth Nielson (“Nielson”)
`
`EX1005
`Nielson
`
`EX1006 Redline of changes to specification of the ’206 patent
`
`EX1007-
`EX1020
`
`Reserved
`
`EX1021 Huawei’s Preliminary Infringement Contentions, Huawei
`Technologies Co., Ltd et al. v. Verizon Communications, Inc. et al.,
`Case No. 6:20-CV-00090 (W.D. Tex.) (“Huawei’s Infringement
`Contentions)
`
`EX1022 Exhibit C to Huawei’s Infringement Contentions
`
`EX1023 Robert J. Shimonski et al., The Best Damn Firewall Book Period,
`Syngress Publishing (2003) (the “Best Firewall Book”)
`EX1024 R. Hunt, Internet/Intranet firewall security – policy, architecture and
`transaction services, Computer Communications 21 (1998) 1107-
`1123
`EX1025 Stipulation Regarding Case Schedule and Discovery Limits, May
`13, 2020
`EX1026 Order Governing Proceedings – Patent Case, April 7 2020
`EX1027 US Pub. No. 2012/0233691 (“the ’691 publication”)
`EX1028 US Pub. No. 2003/0009699 (“Gupta”)
`EX1029 RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, June 1999
`
`10832643
`
`
`- iv -
`
`

`

`
`
`EX1030 National Institute of Science and Technology, Special Publication
`800-127: Information Security Continuous Monitoring (ISCM) for
`Federal Information Systems and Organizations (2011), B-9.
`EX1031 National Institute of Science and Technology, Special Publication
`800-82: Guide to Industrial Control Systems (ICS) Security (2015),
`B-18.
`EX1032 Nwokedi Idika and Aditya P. Mathur, A Survey of Malware
`Detection Techniques (2007)
`EX1033 U.S. Patent No. 5,440,723 issued to William C. Arnold, et al.,
`Automatic immune system for computers and computer networks
`(1995).
`EX1034 Wikimedia user Meilani.conley, File: Uniform Resource Locator
`(URL) example.PNG.
`EX1035 Olivier Bonaventure, Computer Networking: Principles, Protocols,
`and Practice (2011)
`James Turnball, Hardening Linux (2005)
`EX1036
`EX1037 RFC 1812
`EX1038 Bobbi Sandberg, Networking: The Complete Reference (2015)
`EX1039 National Institute of Science and Technology, Supplemental
`Information for the Interagency Report on Strategic U.S.
`Government Engagement in International Standardization to
`Achieve U.S. Objectives for Cybersecurity (2015)
`EX1040 Gene Spafford, Director, Computer Operations, Audit, and Security
`Technology (COAST) Project, Purdue University
`EX1041 Elahi, Golnaz and Yu, Eric, “Modeling and Analysis of Security
`Trade-Offs – A Goal Oriented Approach.” Data & Knowledge
`Engineering (2009)
`EX1042 Ho, Yui Chi & Zhao, Qianchuan & Pepyne, David. (2003). “The no
`free lunch theorems: Complexity and security.” Automatic Control,
`IEEE Transactions on. 48. 783 - 793. 10.1109/TAC.2003.811254
`EX1043 Eisenbarth, Thomas, Sandeep Kumar, Christof Paar, Axel
`Poschmann, and Leif Uhsadel. "A survey of lightweight-
`cryptography implementations." IEEE Design & Test of Computers
`24, no. 6 (2007)
`EX1044 Certified Translation of WO 2011/063729 (PCT/CO2010/07895),
`filed on November 22, 2010
`EX1045 Check Point FireWall-1 Guide, September 2002
`
`10832643
`
`
`- v -
`
`

`

`
`
`CLAIM LISTING
`
`Claim
`Element
`1pre A method for alerting against unknown malicious codes, the method
`comprising:
`
`LIMITATION
`
`1(a)
`
`1(b)
`
`1(c)
`
`1(d)
`
`1(e)
`
`1(f)
`
`2
`
`10832643
`
`
`receiving, by a network device, a request sent by a terminal for
`obtaining a file from a network entity and a data stream carrying the
`file;
`
`recording, by the network device, a source path carried in the
`request, wherein the network entity provides the file on the source
`path;
`
`judging, by the network device, whether the file is an executable file
`according to at least one of: the request and the data stream carrying
`the file;
`
`when the network device judges the file is an executable file,
`sending, by the network device, first alert information that carries
`the source path to a monitoring device;
`
`receiving, by the network device, second alarm information sent by
`the monitoring device after further detecting the file downloaded
`according to the source path by the monitoring device; and
`
`intercepting, by the network device, a) the executable file according
`to the second alarm information comprising a maliciousness of the
`executable file; or b) the executable file and packets transmitted in a
`Botnet according to the second alarm information comprising the
`maliciousness of the executable file and Botnet topology
`information.
`
`The method according to claim 1, wherein the judging, by the
`network device, whether the file is the executable file according to at
`least one of: the request and the data stream carrying the file
`comprises at least one of: detecting, by the network device, whether
`a string which indicates a name of the executable file exists in the
`request; and detecting, by the network device, whether a file header
`
`- vi -
`
`

`

`
`
`of the executable file exists in the data stream-returned by the
`network entity.
`
`3pre A network device comprising computing hardware and a non-
`transitory computer-readable storage medium including computer-
`executable instructions executed by the computing hardware to
`perform, on the network device, operations comprising:
`
`3(a)
`
`3(b)
`
`3(c)
`
`3(d)
`
`3(e)
`
`3(f)
`
`4
`
`receiving a request sent by a terminal for obtaining a file from a
`network entity and receiving a data stream carrying the file;
`
`recording a source path carried in the request, wherein the network
`entity provides the file on the source path;
`
`judging the file is an executable file according to at least one of: the
`request and the data stream carrying the file;
`
`when the network device judges the file is the executable file,
`sending first alert information that carries the source path to a
`monitoring device;
`
`receiving second alarm information sent by the monitoring device
`sent by the monitoring device after further detecting the file
`downloaded according to the source path by the monitoring device,
`wherein the second alarm information includes (a) a maliciousness
`of the executable file or (b) the maliciousness of the executable file
`and Botnet topology information; and
`the
`to one of
`intercepting
`i.
`the executable file according
`maliciousness of the executable file; or ii. the executable file and
`packets transmitted in a Botnet according to the second alarm
`information comprising the maliciousness of the executable file and
`Botnet topology information.
`The network device according to claim 3, wherein the judging
`whether the file is an executable file according to at least one of: the
`request and the data stream carrying the file comprises at least one
`of: detecting whether a string which indicates a name of the
`executable file exists in the request; and detecting whether a file
`header of the executable file exists in the data stream received from
`the network entity.
`
`10832643
`
`
`- vii -
`
`

`

`5pre2
`
`
`
`5pre1 A system for alerting against unknown malicious codes comprising a
`network device and a monitoring device:
`the network device comprising a first computing hardware and a first
`non-transitory computer-readable storage medium including a first
`set of computer-executable instructions executed by the first
`computing hardware to perform, on the network device, operations
`comprising:
`a) receiving a request sent by a terminal for obtaining a file from a
`network entity and receiving a data stream carrying the file;
`
`5(a)
`
`5(b)
`
`5(c)
`
`5(d)
`
`5(e)
`
`5(f)
`
`5(g)
`
`5(g1)
`
`5(g2)
`
`5(g3)
`
`10832643
`
`
`b) recording a source path carried in the request, wherein the
`network entity provides the file on the source path;
`
`c) determining the file is an executable file according to at least one
`of (a) the received request and (b) the data stream carrying the file;
`
`d) sending first alert information that carries the source path to a
`monitoring device when the network device determines the file is an
`executable file;
`
`e) receiving second alarm information sent by the monitoring device
`after detecting the executable file downloaded according to the
`source path; and
`the
`to one of
`the executable file according
`intercepting
`i.
`maliciousness of the executable file; or ii. the executable file and
`packets transmitted in a Botnet according to the second alarm
`information comprising the maliciousness of the executable file and
`Botnet topology information; and
`the monitoring device comprising a second computing hardware and
`a second non-transitory computer-readable storage medium
`including a second set of computer-executable instructions executed
`by the second computing hardware to perform, on the monitoring
`device, operations comprising:
`a) receiving the first alert information from the network device;
`
`b) downloading an executable file according to the source path;
`
`c) detecting the executable file to confirm maliciousness of the
`executable file; and
`
`- viii -
`
`

`

`5(g4)
`
`6
`
`7
`
`
`
`d) sending the second alarm information to the network device,
`wherein the second alarm information comprises one of:
`maliciousness of the executable file, and both the maliciousness of
`the executable file and Botnet topology information.
`The system for alerting against unknown malicious codes according
`to claim 5, wherein the operations performed on the monitoring
`device further comprise at least one of: detecting maliciousness of
`the executable file by characteristics detection; and detecting
`maliciousness of the executable file by sandbox test.
`The system for alerting against unknown malicious codes according
`to claim 5, wherein determining the file is an executable file
`according to at least one of: the request sent by the terminal and the
`data stream carrying the file, and determining the file is an
`executable file includes at least one of: a) detecting whether a string
`which indicates a name of the executable file exists in the request;
`and b) detecting whether a file header of the executable file exists in
`the data stream received from the network entity.
`8pre A non-transitory computer readable medium storing instructions for
`execution by a processor, the instructions causing the processor to be
`configured to provide the following:
`receive a request sent by a terminal for obtaining a file from a
`network entity and receive a data stream carrying the file;
`record a source path carried in the request, wherein the network
`entity provides the file on the source path;
`determine whether the file is an executable file according to (a) the
`request or (b) the data stream carrying the file;
`send first alert information that carries the source path to a
`monitoring device, if the network device judges the file is the
`executable file;
`receive second alarm information that includes (a) a maliciousness
`of the executable file or (b) the maliciousness of the executable file
`and Botnet topology information; and
`intercepting a) the executable file according to one of the
`maliciousness of the executable file; or b) the executable file and
`packets transmitted in a Botnet according to the second alarm
`information comprising the maliciousness of the executable file and
`Botnet topology information.
`The network device according to claim 8, wherein determining the
`file is an executable file according to the request or the data stream
`carrying the file comprises: detecting whether a string which
`
`8(a)
`
`8(b)
`
`8(c)
`
`8(d)
`
`8(e)
`
`8(f)
`
`9
`
`10832643
`
`
`- ix -
`
`

`

`
`
`indicates the name of the executable file exists in the request; and/or
`detecting whether a file header of the executable file exists in the
`data, which is transmitted by the data stream returned by the network
`entity.
`
`
`
`
`
`
`
`
`
`10832643
`
`
`- x -
`
`

`

`
`
`I.
`
`INTRODUCTION
`Huawei’s prosecution of US 9,674,206 (“the ’206 patent) was lengthy and
`
`contentious. After five years and a failed appeal, Huawei agreed to significantly limit
`
`the claims of the ’206 patent to get an allowance. Apparently unhappy with that
`
`result, Huawei decided to file another application seeking broader protection for its
`
`invention. However, rather than file a continuation with broader claims, as typically
`
`would be the case, Huawei decided to file the application with broader claims and
`
`with a broader disclosure. That application, filed as a continuation-in-part (CIP) of
`
`the ’206 patent, issued as the US 10,027,693 (“the ’693 patent”).
`
`The claims of the ’693 patent include limitations that are based on and indeed
`
`incorporate features from the newly-broadened disclosure. As a result, the claims
`
`of the ’693 patent are not entitled to claim an earlier priority date as they contain
`
`subject matter not supported under 35 U.S.C 112 by the parent ’206 patent (or by
`
`the disclosures of the earlier priority documents). While filing CIPs is a well-
`
`established practice, here Huawei waited entirely too long to expand its invention in
`
`delaying filing the ’693 patent for almost 4 years after the parent ’206 patent had
`
`published as U.S. Publication No. 2012/0233691 (“the ’691 publication). That delay
`
`is fatal to the ’693 patent. By expanding its invention beyond what was originally
`
`disclosed, thereby introducing new and unsupported subject matter to the disclosure
`
`10832643
`
`
`- 1 -
`
`

`

`U.S. Patent No. 10,225,378
`
`and to the claims of the ’693 patent, the ’691 publication is now prior art to the ’693
`
`patent under 35 U.S.C. 102(a)(1).
`
`The written description requirement was designed to protect the public against
`
`this very situation. Specifically, Section 112 “ensur[es] that the scope of the right to
`
`exclude, as set forth in the claims, does not overreach the scope of the inventor’s
`
`contribution to the field of art as described in the patent specification.” Univ. of
`
`Rochester v. G.D. Searle & Co., 358 F.3d 916, 920 (Fed. Cir. 2004) (quoting Reiffin
`
`v. Microsoft Corp., 214 F.3d 1342, 1345 (Fed. Cir. 2000)) (internal citations and
`
`punctuation omitted). Here, Huawei overreached its original contribution to art by
`
`disclosing and claiming an invention in the ’693 patent that is significantly broader
`
`than anything it had previously demonstrated was in its possession. Huawei now
`
`seeks to capitalize on its overreaching by asserting the ’693 patent (but not the
`
`narrower parent ’206 patent) in a litigation in which it has taken the positon that the
`
`’693 patent is entitled to the very earliest possible priority date—a date which is over
`
`6 years before Huawei finally filed an application in which it could demonstrate
`
`possession of the invention of the ’693 patent.1
`
`Because Huawei should not be permitted to expand its right to exclude by
`
`manipulating the CIP practice to obtain a significantly broadened patent, while
`
`
`1 See EX1021 (Huawei’s Preliminary Infringement Contentions) at 14.
`
`10832643
`
`
`- 2 -
`
`

`

`U.S. Patent No. 10,225,378
`
`professing the same early invention date, Juniper requests inter partes review of ’693
`
`patent and cancelation of its claims as being obvious in view of the publication of
`
`the parent ’206 patent.
`
`II.
`
`STATE OF THE ART
`Computer networks provide immense benefits, but they also represent a direct
`
`path by which nefarious actors can gain access to personal data. ‘Malicious code’ or
`
`‘malware’ refers to a set of computer instructions that carry out one or more
`
`computer operations in an unauthorized manner or by an unauthorized party. See
`
`EX1005 (Nielson) at ¶¶15-16. For example, malicious code can be used to gain
`
`access to a computer system or network to steal or destroy information stored
`
`therein.
`
`Given the proliferation of malware, well before the ’683 patent computer
`
`security practitioners had been inserting security components into network
`
`components. See id. at ¶¶21-25. For example, it was realized early on that
`
`gateways—a computing device that connects different networks—were natural
`
`choke points for data going in or out. A gateway that determines whether data is
`
`permitted to enter or leave a given network is called a “firewall.” See id. at ¶25, 52.
`
`While the earliest firewalls simply examined packet metadata, such as source and
`
`destination addresses, by the late 1990’s firewalls included scanners that examined
`
`10832643
`
`
`- 3 -
`
`

`

`U.S. Patent No. 10,225,378
`
`the contents of packets to determine if the packets represented some kind of threat
`
`or otherwise unauthorized activity. See id. at ¶25, 55.
`
`One of the earliest scanners were “antivirus scanners,” which would scan
`
`computer programs to determine if the program had been infected by a ‘virus.’ See
`
`id. at ¶26, 55-56. A virus is a type of malicious code designed to write itself into
`
`existing programs, most often to carry out some unauthorized activity. See id. at
`
`¶¶16, 26. While the first antivirus scanners were largely run on individual computers,
`
`this antivirus functionality was soon introduced at the gateway level (i.e., in a
`
`firewall) such that malicious code could be intercepted before ever reaching a user’s
`
`computer. See id. at ¶¶26-27.
`
`Just as scanners expanded from protecting individual computers to residing
`
`on firewalls to protect networks, so too did they expand from the gateway level to
`
`more centralized locations, often referred to as the “cloud.” See id. at ¶¶27-28. With
`
`cloud-based scanners, malware identification updates were much quicker and
`
`efficient because an attack on one party could result in defenses for many. See id.
`
`Meanwhile, just as the network architecture for antivirus scanners was
`
`expanding, so were the methods used to detect viruses. See id. at ¶30. By 2009,
`
`antivirus scanners could identified malware based on signature or behavior. See id.
`
`at ¶¶26, 31-32, 56. For example, well before 2009 there were firewall-based
`
`antivirus scanners that, in addition to looking at the malicious code directly, used
`
`10832643
`
`
`- 4 -
`
`

`

`U.S. Patent No. 10,225,378
`
`“URL filtering” to preemptively prevent malware infections. See id. A URL
`
`(Uniform Resource Locator) represents a network location that network protocols,
`
`such as HTTP (Hyper-Text Transfer Protocol), use to direct network traffic. See id.
`
`at ¶31. HTTP is a protocol used by web browsers to access data on websites. When
`
`a web browser requests a resource (a file) using HTTP, the request includes a URL
`
`that describes the location of the resource (file), and is used to route the request to
`
`the correct server. The HTTP response will include the resource (file) associated
`
`with the requested path. See id. at ¶¶31-32.
`
`For computers behind a firewall, both the HTTP request and response would
`
`pass through the firewall, where they could undergo scanning. This could include
`
`scanning the resource (file) to see if it contains a virus or other malware, as well as
`
`scanning the request to see if it corresponds to a path or file known to be bad. See
`
`id. at ¶¶25, 29, 55-56. In either case, firewall would block the exchange either at the
`
`requesting stage or at the response stage based on the scanner’s findings. See id. at
`
`¶56.
`
`III. BACKGROUND AND OVERVIEW OF THE CHALLENGED
`PATENT
`The ’693 patent was filed on March 25, 2016 as a CIP of the ’206 patent filed
`
`on May 25, 2012, which in turn was filed as a by-pass continuation of PCT
`
`application no. PCT/CN2010/078951, filed on November 22, 2010, which claims
`
`the benefit of CN 200910247172.8, filed November 26, 2009. See EX1002 (’693
`
`10832643
`
`
`- 5 -
`
`

`

`U.S. Patent No. 10,225,378
`
`File History) at 265-266. For the reasons set forth in Section IV, the claims of the
`
`’693 patent are not entitled to a priority date any earlier than the filing date of the
`
`’693 patent.
`
`A. The Specification of the Parent ’206 Patent
`
`The parent ’206 patent relates to a network device that detects characteristics
`
`of a packet and judges whether any suspicious code exists in the packet. See e.g.,
`
`EX1003 (’206 patent), 1:60-65. Fig. 1, reproduced below, describes “a method for
`
`alerting against unknown malicious codes according to an embodiment of the
`
`present invention.” Id. at 3:5-7.
`
`
`
`10832643
`
`
`- 6 -
`
`

`

`U.S. Patent No. 10,225,378
`
`
`The method of Fig. 1 is performed by a “network device.” See id. at 3:16-17.
`
`After detecting characteristics of a packet at step 105, the network device “Judge[s]
`
`whether any suspicious code exists in the packet . . .,” “Record[s] a source address
`
`of the suspicious code . . . ,” and “Send[s] alert information that carries the source
`
`address to a monitoring device.” Id. at 3:9-15.
`
`Fig. 2 of the ’206 patent describes “an embodiment of the present invention”
`
`which includes the above steps of Fig. 1, but further adds that the network device
`
`“Receive[s] alarm information sent by the monitoring device,” where the “alarm
`
`information includes maliciousness of the suspicious code, or includes both the
`
`maliciousness of the suspicious code and the Botnet topology information.” Id. at
`
`4:24-27.
`
`After receiving the alarm information, the network device either “Intercept[s]
`
`suspicious codes that are malicious according to [the] maliciousness of the
`
`suspicious codes,” or “Intercept[s] the suspicious codes that are malicious and the
`
`
`
`10832643
`
`
`- 7 -
`
`

`

`U.S. Patent No. 10,225,378
`
`packets in the Botnet corresponding to the Botnet topology information according
`
`to [the] maliciousness of the suspicious codes and the Botnet topology information.”
`
`Id. at 5:19-24.
`
`B.
`
`Prosecution History of the Parent ’206 Patent
`
`The parent ’206 patent was filed on May 25, 2012 as application no.
`
`13/481,273 (“the ’273 application”). The ’206 patent published on September 13,
`
`2012 as U.S. Pub. No., 2012/0233691 (“the ’691 publication”) (EX1027).
`
`The ’273 application was filed as a ‘bypass’ continuation of the PCT
`
`application instead of as a national stage application under 37 U.S.C. § 371. See
`
`MPEP 1895. In response to a first office action rejecting the originally-filed claims,
`
`the applicant amended the claims of the ’273 application to additionally recite,
`
`among other things, that a “source address” of suspicious code “appears in the URL
`
`after a get * string . . . .” EX1004 (’206 File History) at 227. A subsequent final
`
`office action again rejected the claims, this time relying on Gupta et al. (US
`
`2003/0009699) (EX1028) for most of the claim limitations, including the
`
`10832643
`
`
`- 8 -
`
`

`

`U.S. Patent No. 10,225,378
`
`previously-added feature of the suspicious code’s “source address appear[ing] in the
`
`URL after a get* string.”2 EX1004 (’206 File History) at 207.
`
`In response to the final office action, the applicant took the position that Gupta
`
`does not disclose the above “source address” limitation, but “merely identifies
`
`generic ‘Parameters’ after a GET * string.” EX1004 (’206 File History) at 195.
`
`While the applicant acknowledged that Gupta “describes identifying an attack based,
`
`in part, upon an analysis of parameters specified after a GET request and specified
`
`file,” the applicant attempted to distinguish Gupta by arguing that there was “no
`
`description of any ‘source address’ in the set of parameters following the GET
`
`request identifying the file ‘/dirl/dir2/dvwssr.dll’,” as disclosed in Gupta. Id. at 197.
`
`The examiner disagreed clarifying that “the address ‘/dir1/dir2/dvwssr.dll’ is what
`
`examiner is interpreting as the ‘source address’ because it appears after GET and
`
`also because it identifies the directory and the subdirectory of the code ‘dvwssr.dll’.”
`
`EX1004 (’206 File History) at 188. The actual GET request disclosed in Gupta is
`
`as follows:
`
`
`2 Each of the independent claims was rejected under 35 U.S.C. § 103 as
`
`being obvious over Gupta et al. (US 2003/0009699) (EX1028) in view of Bates et
`
`al. (US 2004/0148281).
`
`10832643
`
`
`- 9 -
`
`

`

`U.S. Patent No. 10,225,378
`
`
`EX1028 (Gupta) at [0102].
`
`
`
`Ultimately, the applicant appealed the rejection of the claims, primarily
`
`focusing on the argument that Gupta’s “directory/file name does not, and cannot,
`
`identify a network source of identified malicious code,” and therefore is not the
`
`claimed “source address.” EX1004 (’206 File History) at 143, 144-145.
`
`In its Decision on Appeal, the Board affirmed the examiner’s rejection,
`
`finding
`
`that
`
`the
`
`“Examiner’s
`
`interpretation
`
`is
`
`reasonable
`
`because
`
`‘/dir1/dir2/dvwssr.dll’ is an address that identifies the source, which is the directory
`
`dir1 and subdirectory dir2.” EX1004 (’206 File History) at 105 (internal citations
`
`omitted). The Board further found “Appellant’s assertion that the term must specify
`
`a networked source or actual physical source of the suspicious code is not
`
`commensurate with the scope of the claim and therefore, unpersuasive.” Id. at 107
`
`(internal citations omitted).
`
`In a Request for Rehearing, the applicant doubled down on the notion that
`
`“the term ‘source address’ [] specifies a physical server – as opposed to a file name
`
`contained in a directory tree,”3 and that this interpretation is supported by the
`
`
`3 Emphasis added unless otherwise indicated.
`
`10832643
`
`
`- 10 -
`
`

`

`U.S. Patent No. 10,225,378
`
`specification. EX1004 (’206 File History) at 89; see also id. at 91 (“The claimed
`
`source address is used to identify a networked source (e.g. a server) of suspicious
`
`code.”); 93 (“a ‘source address’ that identifies an address of a file’s source (network
`
`location of a server) ….”). Huawei further argued that “Gupta’s directory path
`
`("/dirl/dir2") merely specifies a location of the file within a directory tree of a file
`
`source at some unspecified location much like the specification of a floor/room in
`
`an unidentified home.” Id. at 94-95 (original emphasis included).
`
`The Board maintained the rejection, after which the applicant filed a Request
`
`for Continuing Examination to amend the claims to include a series of additional
`
`limitations not previously at issue during prosecution (see id. at 67-77), which led to
`
`a Notice of Allowance. See id. at 29-35.
`
`C. The Specification of the ’693 Patent
`
`The disclosure of the ’693 patent is similar in many respects to the ’206 patent,
`
`but also differs in important respects, as detailed below in Section IV.B.
`
`While the parent ’206 patent focused on a network device that detects
`
`characteristics of a packet in order to judge whether any suspicious code exists in
`
`the packet, the ’693 patent instead focuses on that network device receiving a
`
`“request” sent by a terminal for obtaining a file from a “network entity” over a
`
`“source path.” (Step 101 of FIG. 1). See e.g., EX1001 (’693 patent) at 4:63-65. The
`
`“network entity” is described as being a server, such as a Web server or an FTP
`
`10832643
`
`
`- 11 -
`
`

`

`U.S. Patent No. 10,225,378
`
`server, and the “request” is “an HTTP get request or an FTP request ….” Id. at 3:51-
`
`58.
`
`
`
`The source path, whi