`FEDERAL PATENT COURT
`
`Certified Copy
`
`IN THE NAME OF THE PEOPLE
`JUDGMENT
`
`Announced on
`July 12, 2018
`Zindler
`Judicial Employee
`acting as
`Clerk of the Court
`
`2 Ni 26/16 (EP)
`combined with
`2 Ni 46/16 (EP)
`______________
`(File Reference)
`
`1.
`
`2.
`
`In the patent nullification matter
`Hewlett-Packard GmbH, Herrenberger Strasse 140, D-71034 Böblingen,
`legally represented by its Executive Directors Thomas Bässler,
`Marc Fischer, Heiko Meyer and Ernst Reichart, ibid,
`
`Huawei Technologies Deutschland GmbH, Hansaallee 205, D-40549
`Düsseldorf, legally represented by its Chief Executive Officer Bo Peng,
`ibid,
`
`Plaintiff on 1,
`
`Plaintiff on 2,
`
`Plaintiffs in the Proceeding 2 Ni 26/16 (EP),
`
`Attorney for this proceeding of Plaintiffs on 1 and 2: Klunker IP, Patent Attorneys
`PartG mbB, Destouchesstrasse 68, D-80796 Munich
`
`BPatG 253
`05/08
`
`EX 1023 Page 1
`
`
`
`- 2 –
`
`3.
`
`Sandvine GmbH, Fürstenrieder Strasse 263, 81377 D-Munich,
`legally represented by its Chief Executive Officer Richard Arthur Murphy Deggs, ibid,
`Plaintiff on 3,
`
`Plaintiffs in the Proceeding 2 Ni 46/16 (EP),
`
`Attorney for this proceeding: Preu Bohlig & Partner Rechtsanwälte mbB
`Grolmanstrasse 36, D-10623 Berlin,
`
`vs.
`
`Packet Intelligence LLC, 505 East Travis Street, Suite 209, Marshall, Texas 75670
`United States of America
`
`Attorney for this proceeding: MFG Patentanwälte Meyer-Wildhagen Meggle-Fruend Gerhard
`PartG mbB, Amalienstrasse 62, D-80799 Munich
`
`Defendant,
`
`regarding European Patent 1 196 856
`(DE 600 45 552)
`
`the Second Senate (Nullification Senate) of the Federal Patent Court, on the basis of the oral hearing of
`July 12, 2018, with the cooperation of Chief Judge Guth as well as Judge Dipl.-Ing Baumgardt, Judge
`Dipl.-Phys Dr. Thum-Rung, and Judges Dipl.-Phys. Dr. Forkel and Dr. Himmelmann,
`
`has ruled:
`
`I.
`
`European Patent 1 196 856 is declared null and void with effect on the sovereign
`territory of the Federal Republic of Germany.
`
`EX 1023 Page 2
`
`
`
`- 3 –
`
`II.
`
`The Defendant shall bear the costs of the legal proceeding.
`
`III.
`
`The judgment is provisionally enforceable against payment of security in the
`amount of 120% of the enforced amount.
`
`Facts of the Matter
`
`The Defendant is the holder of the Patent EP 1 196 856 B1 applied for on June 30, 2000 and published
`on January 19, 2011 (hereinafter:
`the Patent
`in Suit) which is designated “METHOD AND
`APPARATUS FOR MONITORING TRAFFIC IN A NETWORK” (German: “Verfahren und Gerät
`um den Netzwerkverkehr zu überwachen”), which originates with the international application with
`Publication Number WO 2001/1 272 A1, and is asserted for the priority of U.S. Application 60/141
`903 of June 30, 1999. The Patent in Suit written in the English language is maintained by the German
`Federal Patent and Trademark Office under Number DE 600 45 552.1.
`
`The Plaintiffs each request by their pleadings the nullification in full of the German portion of the
`European Patent.
`
`The Defendant defends its Patent in Suit in full by its Primary Application, and alternatively limits this
`with Alternative Applications 1, 2a-d and 4, each dated January 8, 2018, as well as with Alternative
`Applications 2e, 3 and 5-9 dated May 28, 2018.
`
`The Patent in Suit is comprised of 92 patent claims, with a Primary Application directed to a “Method
`for recognizing one or more communications, for packets passing through a node point in a computer
`network”, and 39 sub-claims referring to it, as well as with a coordinate Claim 41 directed to a “packet
`
`EX 1023 Page 3
`
`
`
`monitor” set up for this purpose, and 51 sub-claims referring to it.
`
`-4-
`
`In the English language proceeding, the granted independent Patent Claims 1 and 41 are worded
`according to the specification of the Patent in Suit EP 1 196 856 B1:
`
`A method of recognizing one or more conversational flows for packets passing through a
`“1.
`connection point (121) on a computer network (102), each packet conforming to at least one protocol,
`wherein at least one said protocol defines one or more conversational flows that each includes a
`plurality of states of the flow including an initial state, and transitions from the initial state to at least
`one of the plurality of states of the flow, the method comprising:
`
`receiving a packet (302) from a packet acquisition device;
`
`performing at least one parsing operation (304) and/or at least one extraction operation (306) on
`the packet to create a parser record comprising a function (312) of selected portions of the
`packet; wherein at least one of the parsing and/or extraction operations depend on one or more
`of the protocols to which the packet conforms; looking up (314) in a flow-entry database (324)
`comprising flow entries for any previously encountered conversational flows, the look up using
`at least some of the selected packet portions and determining (316) if the packet is of an
`existing conversational flow;
`
`if the packet is of an existing conversational flow, classifying the packet as belonging to the
`found existing conversational flow and performing (328, 330) any state operation or operations
`specified in a database (326) for the state of the conversational flow; and
`
`if the packet is of a new conversational flow, storing (322) a new flow-entry for the new
`conversational flow in the flow-entry database, including identifying information for future
`packets to be identified with the new flow-entry, determining the state of the flow (318) using
`the database (326) and
`
`EX 1023 Page 4
`
`
`
`-5-
`
`performing (328, 330) any state operation or operations specified in the database (326) for the
`state of the flow;
`
`includes a plurality of states is recognized by
`wherein each conversational flow that
`transitioning through a plurality of states of the conversational flow, and at each state, carrying
`out one or more state operations specified in the database (326) for the state of the flow.”
`
`“41. A packet monitor (108) for recognizing one or more conversational flows for packets passing
`through a connection point (121) on a computer network (102), each packet conforming to at least one
`protocol, wherein at least one said protocol defines one or more conversational flows that each
`includes a plurality of states of the flow including an initial state, and transitions from the initial state
`to at least one of the plurality of states of the flow, the packet monitor comprising:
`
`a packet acquisition device (1502) for coupling to the connection point and configured to
`receive packets passing through the connection point, including an input buffer memory (1008)
`coupled to and configured to accept a packet;
`
`a parser subsystem (301) coupled to the input buffer memory and including a slicer (1007), the
`parsing subsystem configured to extract selected portions of the received packet and to output a
`parser record containing the selected portions, wherein the operation of the parser subsystem
`depends on one or more of the protocols to which the packet conforms;
`
`a memory (324) for storing a database comprising flow-entries for any previously encountered
`conversational flows, each flow-entry identified by identifying information stored in the flow-
`entry, conversational flows having one or more states;
`
`a lookup engine (1107) coupled to the output of the parser subsystem and to the memory and
`configured to lookup whether the particular packet whose parser record is output by the parser
`subsystem has a matching flow-entry in
`
`EX 1023 Page 5
`
`
`
`-6-
`
`the flow-entry database, the looking up using at least some of the selected packet portions and
`determining if the packet is of an existing conversational flow;
`
`a flow insertion engine (1110) coupled to the memory and to the lookup engine and configured
`to create a flow-entry in the flow-entry database,
`the flow-entry including identifying
`information for future packets to be identified with the new flow-entry;
`
`a database (326, 1109) specifying state operations and patterns for conversational flows; and
`
`a state processor (1108) configured to perform any state operations specified in the database
`(326, 1109) for the state of the flow and to determine the state of the flow if the packet is of a
`new conversational flow;
`
`wherein the lookup engine is configured to classify the packet as belonging to the found
`existing conversational flow if the packet is of an existing conversational flow;
`
`and the flow insertion engine is configured to store a new flow-entry for the new conversational
`flow in the flow-entry database if the packet is of a new conversational flow, the new flow
`entry including identifying information for future packets to be identified with the new flow-
`entry.”
`
`In the wording of the sub-Claims 2 to 40 directly or indirectly traced back to Patent Claim 1, and the
`wording of the sub-Claims 42 to 92 directly or indirectly traced back to Patent Claim 41, reference is
`made to the specification of the Patent in Suit.
`
`EX 1023 Page 6
`
`
`
`- 7 -
`
`Regarding the wording of the respective Patent Claims 1 in the version of Alternative Application 1, 2a
`to 2e and 3 to 9, and in particular regarding the distinctions from Patent Claim 1 in the issued version,
`reference is made to the grounds for the decision and the explanations there.
`
`The Plaintiffs assert grounds for nullification according to Art. II §6 Para. 1 IntPatÜG (Internationale
`Patentübereinkommengesetz [Law on the International Patent Convention]), namely that
`
`1.
`
`2.
`
`3.
`
`the subject of the Patent in Suit is not patentable, Art. II §6 Para. 1 No. 1 IntPatÜG in
`combination with Art. 54 and Art. 56 EPÜ (Europäische Patentübereinkommen, [European
`Patent Convention]),
`
`the Patent in Suit does not disclose the invention clearly and completely in a sufficient manner
`that the person skilled in the art could implement it, Art, II §6 Para. 1 No. 2 IntPatÜG, and that
`
`the subject of the Patent in Suit goes beyond the content of the Application in its originally
`submitted version, Art, II §6 Para. 1 No. 3 IntPatÜG.
`
`In support of their assertions the Plaintiffs name the following publications and documents, among
`others:
`
`Regarding the Patent in Suit
`
`N1
`
`N2
`
`N3
`
`N4
`
`N5
`
`N6
`
`N7
`
`EP 1 196 856 B1 (Specification of the Patent in Suit)
`
`Registry excerpt (File Ref. 600 45 5552.1)
`
`US 60/141.903 (Priority Application)
`
`Overview of legal transfers of Priority Application (USPTO Public PAIR)
`
`Classification of features of Claims 1 and 41 (English language proceeding)
`
`Classification of features of Claims 1 and 41 (German translation)
`
`Assignment of features between Claims 1 and 41
`
`N8 WO 01/01272 A2 (Application version of the Patent in Suit)
`
`EX 1023 Page 7
`
`
`
`- 8 -
`
`N9
`
`Overview of the changes to Claims 1 and 41 in the course of the European test
`procedure
`N10 Applicant’s assignment table
`N11 Reasons for Appeal of the nullification Defendant in the parallel violation proceeding
`(File. Ref. 6 U 186/16)
`Sworn affidavit of Mr. Tamir Zegman dated March 12, 2017
`N12
`N13 RFC 959: File Transfer Protocol (October 1985)
`N14 Comparison of the new Features (2.1) and (3.3) of the (current) Alternative Application
`9, with the original Claims 60 to 63
`Excerpt from “TCP/IP Illustrated” Vol. 1 (1994) – Chapter 29
`Expert opinion of Dr. Rolf Borgeest
`Expert opinion of Dr. Theo Bodewig on the question of the transfer of the patent law
`priority right under Art. 87 EPÜ
`
`N15
`N16
`N17
`
`New document citations
`
`E1
`
`Paxson: “Bro: A System for Detecting Network Intruders in Real-Time”, Proceedings
`of the 7th USENIX Security Symposium, 1998 (further explanations of this E1a, BROa
`– BROe)
`
`E2 WO 92/19054 A1
`E3
`US 5,862,335
`
`E4
`
`E5
`
`US 5,802,320
`
`Musial: “New method for mechanical analysis of the behavior of protocol machines on
`the basis of passive observation”, Dissertation at the TU Berlin, July 20, 1999
`
`E6 WO 00/52869 A2
`E7
`Brownlee et al.: “Traffic Flow Measurement: Architecture”, RFC 2722, May 1999
`
`E8
`
`E8a
`
`E8b
`
`E8c
`
`Check Point FireWall-ITM White Paper (Version 3.0), 1997
`
`Check PointTM VPN-1 / FireWall-1® Administration Guide, Jan. 2000
`
`Check PointTM VPN-1 / FireWall-1® Reference Guide, Jan. 2000
`
`Check PointTM VPN-1 / FireWall-1® User Guide (on CD)
`
`EX 1023 Page 8
`
`
`
`E9
`
`- 9 -
`
`E15
`
`Ptacek et al.: “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion
`Detection”, Secure Networks lnc., 1998
`S 5,430,709
`E10
`E11 Decasper et al.: “Router Plugins - A Software Architecture for Next Generation
`Routers”, ACM SIGCOMM Conference, 1998
`E12 WO 99/53648 A2
`E13 US 5,347,524
`E14 Goncalves et al.: “Check Point Firewall-1 Administration Guide”, Pages 28-35 und
`258-259, McGraw-Hill, 1. Sept. 1999
`Schobert: “Protocol analysis in local networks: Measurement technique and
`interpretation of data transfer protocols in local networks”, Pages 247-249, Expert-
`Verlag, 1994
`E16 WO 01/65343 A1
`E17 Malan et al.:, “An Extensible Probe Architecture for Network Protocol Performance
`Measurement”, ACM SIGCOMM Conference, 1998
`E18 NetFlow Services and Applications Whitepaper, Cisco Systems, 1999
`E19 US 6,006,268
`E20
`EP O 909 073 A2
`E21 DE 196 40 346 C2
`E22
`Claffy et al.: “A Parameterizable Methodology for Internet Traffic Flow Profiling”,
`IEEE Journal on Selected Areas in Communications, 13 (8): P. 1481-1494; 1995
`Che et al.: “Adaptive Resource Management for Flow-based IP/ATM Hybride
`Switching Systems”, IEEE Transactions on Networking, 6 (5): P. 544-557; 1998
`E24 US 5,351,243
`E25 WO 98/28938 A1
`E26 WO 00/31963 A1
`E27 US5,101,402
`E28 WO 00/02114 A2
`E29 Naylor: “The Re-Analysis and Re-Implementation of X.25”, B.Sc. Thesis, University of
`Nottingham, 1997
`
`E23
`
`EX 1023 Page 9
`
`
`
`- 10 -
`
`E30 US 5,793,954
`E31 WO 98/26510 A2
`E32 US 5,892,924
`E33 MeterFlowTM C-Code 5.5, Frequently Asked Questions, 1999
`E33a Sworn affidavit of Mr. Christopher Butler, March 17, 2017
`E33b Website excerpt
`“http://web.archive.org/web/20000301200951/http://www.apptitude.com/products/
`meterflow/htm” (Version of March 1, 2000)
`
`The Plaintiffs are of the view that the supplementation of Patent Claims 1 and 41, as in the Alternative
`Applications 1 and 2a to 2e, by the feature “a conversational flow comprising more than one
`connection”, is impermissible, because the term “connection” also used in the valid version is already
`unclear. Lack of clarity in a granted claim is certainly not grounds for nullification, but amended
`claims must be materially proven again in the nullification proceeding and must satisfy the clarity
`requirement of §34 Para. 3 No. 3 PatG (Patentgesetz [German Patent Act])/Art. 84 EPÜ.
`
`The Plaintiffs assert in particular:
`
`a)
`
`b)
`
`c)
`
`the Patent in Suit does not describe at any point how the “parser records” and their “selected
`portions for Feature (3.1) are to appear or to be selected;
`
`it is also not explained at any point how the new flow entry according to Feature (6.1) and the
`identification information of Feature (6.2) are to appear;
`
`and further that the instructions of Feature Group 7, which read:
`
`EX 1023 Page 10
`
`
`
`- 11 -
`
`“(7) wherein each conversational flow that includes a plurality of states is recognized
`
`(7.1)
`
`by transitioning through a plurality of states of the conversational flow, and
`
`(7.2)
`
`at each state, carrying out one or more state operations specified in the database (326)
`for the state of the flow”
`
`contradict those of Feature Group 4, which read:
`
`“(4)
`looking up (314) in a flow-entry database (324) comprising flow entries for any
`previously encountered conversational flows,
`
`(4.1)
`
`the look up using at least some of the selected packet portions and
`
`(4.2)
`
`determining (316) if the packet is of an existing conversational flow”.
`
`The Plaintiffs are further of the opinion that the Ethernet frame adduced as an example contains the
`MAC addresses, and that these have nothing to do with the recognition of FTP connections. They
`criticize the original disclosure of the feature “wherein at least one said protocol defines one or more
`conversational flows”.
`
`The Plaintiffs also assert that because the Patent in Suit is impermissibly broadened relative to the
`Supplementary Application (N8), it also necessarily goes beyond the Priority Application (N3) and
`therefore cannot claim its priority. Also, that no legally effective transfer of the priority of US
`60/141,903 has taken place.
`
`In addition the Plaintiffs miss the disclosure which “defines at least one protocol of one or more
`conversational flows”. Because, moreover, not all details are included in Feature Group 7, they judge
`Feature Group 7 to be an impermissible generalization. The additional feature of
`
`EX 1023 Page 11
`
`
`
`- 12 -
`
`Alternative Application 3, “in real time”, is unclear according to them, and formulate the invention
`purely in terms of a result to be achieved, because it is not specified how and by what feature the
`desired real-time capability is to be achieved. Moreover they argue that it lacks feasibility and the
`original disclosure. The same deficiencies would exist regarding the feature “the carrying out of the
`state operations furthering the process of identifying the application content of a conversational flow”.
`The Plaintiffs also assert lack of feasibility and lack of disclosure regarding the feature “and the state
`operations comprising building a new signature for future recognition of packets of the next state”.
`
`The Plaintiffs are moreover of the opinion that the person skilled in the art is capable of deducing the
`detailed method of operation of the packet monitor described in Document E1 from the (in their
`publicly accessible) source code, so that E1 anticipates the technical teaching of the Patent in Suit. The
`Plaintiffs also point out
`that Patent Claim 1 of the Patent
`in Suit does not delimit
`the term
`“conversation flow” such that this must encompass several [bilingual:] “connection flows”. And they
`argue that the Primary and Alternative Applications of the patent holder suffer from formal defects,
`namely lack of clarity, impermissible broadening and lack of feasibility.
`
`For the rest, the Plaintiffs consider the submission of Alternative Application 8, involving an entirely
`new subject matter, to be late, and thus request its rejection.
`
`The Plaintiffs apply,
`
`for European Patent 1 196 856 to be declared null and void in full, with effect over the
`sovereign territory of the Federal Republic of Germany.
`
`EX 1023 Page 12
`
`
`
`The Defendant applies,
`
`- 13 -
`
`that the Complaint be denied,
`alternatively,
`that the Complaint being otherwise denied, European Patent 1 196 856 be declared null and
`void in part, in that its patent claims include the version of one of the Alternative Applications
`1, 2a to 2d and 4, dated January 8, 2018,
`further alternatively that it include the version of one of Alternative Applications 2e, 3, 5 to 9
`dated May 28, 2018 in the sequence of their numbering.
`
`The Defendant explains that it views the claims according to the Primary and Alternative Applications
`each as a complete set of claims, each of which it claims in its totality.
`
`The Defendant defends the Patent in Suit in full with the Primary Application and in delimited manner
`with the named Alternative Applications, and opposes the submission of the Plaintiffs in all points. It is
`particularly of the view that it has effectively claimed the priority of US 60/141,903.
`
`In support of its argumentation, it submits the following documents and/or printouts, among others:
`
`MFG1
`
`BGH (Bürgerliches Gerichtshof [Federal Supreme Court]) Decision X ZR (Zivilrecht
`[Civil Law]) 49/12 – Vehicle Window
`
`MFG2/1 to
`MFG2/6
`
`MFG3
`
`MFG4
`
`MFG5
`
`MFG7
`
`Sworn affidavit on transfer of the priority rights, of six of the inventors named on the
`specification of the Patent in Suit
`
`Decision USPTO Patent Trial and Appeals Board regarding Patent US 6,771,646 B1
`
`US 6,771,646 B1
`
`US 6,115,393
`
`the Wayback Machine
`of
`Documentation
`http://www.apptitude.com/pdfs/mflowfaq.pdf
`
`regarding
`
`the
`
`Internet
`
`page
`
`EX 1023 Page 13
`
`
`
`- 14 -
`
`Wikipedia: Connection-oriented communication (12/15/2017)
`
`https://www.lifewire.com/definition-of-protocol-network- 817949?print “Network
`Protocols” (printout of 12/20/2017)
`
`RFC 783: TFTP Protocol Rev. 2 (1981)
`
`Wikipedia: File Transfer Protocol (12/18/2017)
`
`Wikipedia: Transport Layer (30.122017)
`
`RFC 2074: Remote Network Monitoring MIB Protocol Identifiers (1997) – to explain
`the terms “child protocol” and “parent protocol”
`
`Wikipedia: Transmission Control Protocol (06/21/2018)
`
`E-mail correspondence regarding the documentation for “Bro”, 1998
`
`MFG8
`
`MFG9
`
`MFG10
`
`MFG11
`
`MFG12
`
`MFG16
`
`MFG17
`
`MFG18
`
`The Defendant explains that the Patent in Suit discloses the first functional packet monitor which can
`recognize,
`through a progressive recognition process,
`the application layer protocol and/or the
`application, and can recognize that connection flows have a common context and thus can be assigned
`to a conversational flow.
`
`It holds a [bilingual:] “conversational flow” to be a sequence or a flow of packets which belong
`together because they represent a common activity (context) between two or more devices within the
`computer network. The network monitor “Bro” from PAXSON (according to Document E1 and the
`additional explanations) executes a processing of connection flows at the transport layer, but not a state
`processing regarding conversational flows at the application layer. Connections at the fourth OSI layer
`(TCP connections) are not conversational flows, it argues, but rather connection flows in the sense of
`the Patent in Suit. Beyond this, the publication of additional explanations and public accessibility of
`the source codes is contested; in particular, that the person skilled in the art would be able to
`understand these and to directly and clearly derive the details of the claimed teaching.
`
`EX 1023 Page 14
`
`
`
`- 15 -
`
`in Suit carries out a progressive analysis of packets of
`the Patent
`The Defendant asserts that
`conversational flows for identification of an application layer, in that it remembers the “state” of the
`conversational flow from one packet to the next. It says that the difference between the teaching of the
`Patent in Suit and Document E2 is primarily that Document E2 involves “only” dialog recognition at
`lower protocol
`levels (especially TCP), which are, according to the Defendant’s interpretation,
`“connection flows.” On this point the Defendant refers to a decision of the “Patent Trial and Appeal
`Board” of the United States Patent and Trademark Office (USPTO) regarding Patent US 6 771 646 B1,
`which derives from the same advance notification as the Patent in Suit.
`
`The network monitor described in Document E2, which can merely recognize individual TCP
`connections, is still not a packet monitor for recognition of conversational flows in the sense of the
`Patent in Suit, since conversational flows must include such conversational flows as consist of several
`connection flows at the network level, according to the Defendant. It views a TCP connection as only
`to be viewed as a “connection”, and only multiple TCP connections as able to be understood as a
`conversation flow. It maintains that the term “connection” is a defined and fixed term in the Patent in
`Suit and in the field. It calls the connections and connection states resulting from the individual phases
`of a single TCP connection, an individual connection flow under the definition in Paragraph [0010] of
`the Patent in Suit; they do not represent multiple connection flows, however.
`
`The Defendant argues that the Patent in Suit in the version of one of the Alternative Applications
`submitted is at least viable, permissible and patentable, in particular that it solved technical problems
`by technical means, as in the “design of a compiler process” according to Alternative Application 9.
`
`We refer to the content of the file for further details.
`
`EX 1023 Page 15
`
`
`
`- 16 -
`
`Grounds for the Decision
`
`The Complaint which asserts, among others, the grounds for nullification of lack of patentability
`according to Article II §6 Paragraph 1 No. 1 IntPatÜG, Article 138 Para. 1a EPÜ in combination with
`Article 54 Paragraphs 1, 2 and Article 56 EPÜ, is permissible and justified. The Patent in Suit, both in
`the version granted and in the version of Alternative Applications 1, 2a to 2e and 3 to 8, is shown to be
`non-patentable, because the teaching claimed with the independent Patent Claims 1 and 41 was known
`from prior art or (in the cases of Alternative Applications 1 to 8) suggested by it (Art. 54, Art. 56
`EPÜ); with Alternative Application 8 (and also with Alternative Application 9, as the case may be),
`there are additionally features which do not contribute to the solution of a technical problem by
`technical means which need to be considered in testing for an inventive step (cf. BGH GRUR
`[Gewerblicher Rechtsschutz und Urheberrecht (Intellectual Property Rights and Copyright Law)]
`2011, 125 – Transmission of topographic information).
`
`The version of the claims of Alternative Application 9 therefore already leads to no success, because
`the subject of its Patent Claim 1 would broaden the scope of protection of the European patent, Article
`II §6 Paragraph 1 No. 4 IntPatÜG, Article 138 Para. 1d EPÜ.
`
`It may be left open whether other of the nullification grounds asserted by the Plaintiffs also exist
`independently of this (as, in particular, the claimed lack of feasibility and/or inadequate disclosure, or
`going beyond the content of the patent application in its originally submitted version), or whether
`deficient clarity conflicts with reformulated claims in individual Alternative Applications.
`
`EX 1023 Page 16
`
`
`
`- 17 -
`
`I.
`
`1.
`The subject matter of the Patent in Suit is a method and apparatus for analysis, recognition and
`classification of transmitted data packets in data transmission in computer networks (known under the
`English language technical
`terms “network monitor” or “packet monitor”), comprising also a
`classification of the data packets according to an applied protocol and “application” (see below Section
`7.3) – cf. Patent in Suit Para. [0001], [0003], [0013], [0040]).
`
`This is supposed to enable a monitoring of network activity in real time, e.g., for maintenance and
`operation of the network (“maintenance and operation”), to make selected users (administrators) aware
`of problems promptly (see Para. [0003], [0013]), but, e.g., also to enable targeted auditing of certain
`connections (“eavesdropping”, see Paragraph [0086]).
`
`In this process the Patent in Suit assumes known network protocols, especially according to the ISO
`layered network model, see Para. [0075] to [0078]), and investigates the individual data packets at a
`certain point in the network (connection point 121) for recognition patterns derived from specific
`transfer protocols, in order to recognize and classify transfer connections and ultimately to be able to
`make an assignment of the packet to a data connection produced at a higher protocol level (through an
`“application”, a network service) (cf. Para. [0041] to [0045]).
`
`Similar methods for network monitoring were previously known, but according to the assertions in the
`Patent in Suit were either employed in retrospect on the basis of log files, or could merely recognize
`individual connections (“connection flow”) (see para. [0004] to [0012]). It claims that this is not
`adequate, however, to enable an assignment of different individual connections to individual types of
`use or network services during ongoing operation. The peculiarity of the teaching of the Patent in Suit
`was supposed to lie in that a complete “conversational flow” could be recognized, with assignment of
`
`EX 1023 Page 17
`
`
`
`- 18 -
`
`the associated individual connections, in every layer up to the application layer of the OSI model (see
`Para. [0013], [0014], [0015], [0077]).
`
`From this starting point the Patent in Suit, in Paragraph [0041], names various problems,
`2.
`which are supposedly solved by the claimed teaching:
`-
`Recognition and classification of all packets exchanged between a client and a server
`in each of the client / server applications;
`
`-
`
`-
`
`-
`
`-
`
`-
`
`Recognition and classification of “conversational flows” which pass a point
`network in both directions, at all protocol levels;
`
`in a
`
`Analysis of the connection and the (conversational) flow progress between clients and
`servers on the basis of individual packets exchanged via a network;
`
`Contributions to increasing the power of a network depending on the current mixture of
`client/server applications which require network resources;
`
`Maintenance of statistics relevant to the mix of client/server applications which require
`network resources;
`
`Production of reports on the occurrence of certain packet sequences used by certain
`applications for client/server network conversational flows.
`
`In the course of the proceeding the Defendant has placed central emphasis on the point that the claimed
`method and/or the packet monitor are able to recognize one or multiple so-called “conversational
`flows” from packets which pass a connection point in a
`
`EX 1023 Page 18
`
`
`
`- 19 –
`
`computer network, and to be able to classify packets as belonging to a certain conversational flow and
`to analyze the so-called state of a conversational flow from packets (see in this respect the Grounds for
`Opposition, identically worked in both proceedings, of September 16, 2016 and of February 2017
`respectively, Section B. IV, “Problem and Solution”). Thus, the Patent in Suit discloses the first
`functional packet monitor, capable through a progressive recognition process of recognizing the
`application layer protocol and/or the application, and able to recognize that connection flows have a
`common context and thus could be assigned to one conversation flow (Grounds for Opposition, last
`sentence of Section A, “Preliminary Remark”).
`
`The claimed solution essentially consists in analyzing each individual data packet and entering
`3.
`this in a connection flow database in such a way that later data packets belonging to the same
`connection flow or superordinate conversational flow can be recognized again and assigned, with the
`help of a “state machine” (Zusandsautomat”) and a database for state operations, which saves and
`follows the successive states of the transfer flows. One peculiarity (see the Alternative Applications) is
`said to lie in that a recognition pattern can be generated in advance from the analysis of certain
`connections, which pattern in itself identifies a later, different connection as belonging to the first
`connection; i.e., permitting recognition of the superordinate “conversational flow” from unconnected
`(“disjointed”) individual connections.
`
`As the competent person skilled in the art here, the Senate envisages a university graduate in
`4.
`information technology or network technology, with practical knowledge in communications
`technology and digital information processing, in particular regarding OSI and TCP/IP reference
`models and their protocol families, and with the technical capabilities for protocol-dependent
`monitoring of network traffic
`
`EX 1023 Page 19
`
`
`
`- 20 -
`
`using known firewall techniques; such a person is also familiar with the approach of “finite-state
`machines” as well as the corresponding concepts for state modeling of communications processes,
`particularly here in the form of TCP or IP state machines.
`
`The following classification of features was used in the proceeding for Patent Claim 1 of the
`5.1
`Patent in Suit:
`
`(1)
`
`A method of recognizing one or more conversational flows for packets passing through a
`connection point (121) on a computer network (102)
`
`(1.1)
`
`each packet conforming to at least one protocol,
`
`(1.2) wherein at least one said protocol defines one or more conversational flows that each includes a
`plurality of states of the flow including an initial state, and transitions from the initial state to at
`least one of the plurality of states of the flow,
`
`the method comprising:
`
`(2)
`
`(3)
`
`receiving a packet (302) from a packet acquisition device;
`
`performing at least one parsing operation (304) and/or at least one extraction operation (306) on
`the packet
`
`(3.1)
`
`to create a parser record comprising a function (312) of selected portions of the packet;
`
`(3.2) wherein at least one of the parsing and/or extraction operations depend on one or more of the
`protocols to which the packet conforms;
`
`EX 1023 Page 20
`
`
`
`- 21 -
`
`(4)
`
`looking up (314) in a flow-entry database (324) comprising flow entries for any previously
`encountered conversational flows,
`
`(4.1)
`
`the look up using at least some of the selected packet portions and
`
`(4.2)
`
`determining (316) if the packet is of an existing conversational flow;
`
`(5)
`
`if the packet is of an existing conversational flow,
`
`(5.1)
`
`classifying the packet as belonging to the found existing conversational flow and
`
`(5.2)
`
`performing