throbber
Claim chart comparing claims 1, 8, and 11 of Riddle to the specification of
`provisional application number 60/066,864
`
`1. A method for
`automatically classifying
`traffic in a packet
`communications network,
`said network having any
`number of flows, including
`zero, comprising the steps
`of:
`
`6,412,000 Claim Elements Citations to Support Provisional Application
`No. 60/066,864
`“According to the invention, in a packet
`communication environment, a method is
`provided for automatically classifying packet
`flows for use in allocating bandwidth resources
`by a rule of assignment of a service level. The
`method comprises applying individual instances
`of traffic classification paradigms to packet
`network flows based on selectable information
`obtained from a plurality of layers of a multi-
`layered communication protocol in order to
`define a characteristic class, then mapping the
`flow to the defined traffic class. It is useful to
`note that the automatic classification is
`sufficiently robust to classify a complete
`enumeration of the possible traffic.” Prov. at
`5:29-6:3.
`
`“The present invention provides techniques to
`automatically classify a plurality of
`heterogeneous packets in a packet
`telecommunications system for management of
`network bandwidth in systems such as a private
`area network, a wide area network or an
`internetwork. Systems according to the present
`invention enable network managers to:
`automatically define traffic classes, for which
`policies may then be created for specifying
`service levels for the traffic classes and
`isolating bandwidth resources associated with
`certain traffic classes. Inbound as well as
`outbound traffic may be managed.” Prov. at
`7:7-14.
`“The present invention provides techniques to
`automatically classify a plurality of
`heterogeneous packets in a packet
`
`EX1038, 1
`
`parsing a packet into a first
`flow specification, wherein
`said first flow specification
`
`

`

`contains at least one
`instance of any one of the
`following:
`a protocol family
`designation,
`a direction of packet flow
`designation,
`a protocol type
`designation,
`a pair of hosts,
`a pair of ports, in HTTP
`protocol packets,
`a pointer to a MIME type
`
`telecommunications system for management of
`network bandwidth in systems such as a private
`area network, a wide area network or an
`internetwork. Systems according to the present
`invention enable network managers to:
`automatically define traffic classes, for which
`policies may then be created for specifying
`service levels for the traffic classes and
`isolating bandwidth resources associated with
`certain traffic classes. Inbound as well as
`outbound traffic may be managed.” Prov. at
`7:7-14.
`
`"The hardware configurations are in general
`standard and will be described only briefly. In
`accordance with known practice, server 20
`includes one or more processors 30 which
`communicate with a number of peripheral
`devices via a bus subsystem 32. These
`peripheral devices typically include a storage
`subsystem 35, comprised of a memory
`subsystem 35a and a file storage subsystem 35b
`holding computer programs (e.g., code or
`instructions) and data, a set of user interface
`input and output devices 37, and an interface to
`outside networks, which may employ Ethernet,
`Token Ring, ATM, IEEE 802.3, ITU X.25,
`Serial Link Internet Protocol (SLIP) or the
`public switched telephone network. This
`interface is shown schematically as a "Network
`Interface" block 40. It is coupled to
`corresponding interface devices in client
`computers via a network connection 45." Prov.
`at 10:24-11:2.
`
`"Fig. 1B is a functional diagram of a computer
`system such as that of Fig. 1A. Fig. 1B depicts
`a server 20, and a representative client 25 of a
`plurality of clients which may interact with the
`
`EX1038, 2
`
`

`

`server 20 via the Internet 45 or any other
`communications method. Blocks to the right of
`the server are indicative of the processing steps
`and functions which occur in the server's
`program and data storage indicated by blocks
`35a and 35b in Fig. 1A." Prov. at 11:21-26.
`
`"Fig. 1C is illustrative of the internetworking of
`a plurality of clients such as client 25 of Figs.
`1A and 1B and a plurality of servers such as
`server 20 of Figs. 1A and 1B as described
`herein above. In Fig. 1C, network 70 is an
`example of a Token Ring or frame oriented
`network. Network 70 links host 71, such as an
`IBM RS6000 RISC workstation, which may be
`running the AIX operating system, to host 72,
`which is a personal computer, which may be
`running Windows 95, IBM OS/2 or a DOS
`operating system, and host 73, which may be an
`IBM AS/400 computer, which may be running
`the OS/400 operating system. Network 70 is
`internetworked to network 60 via a system
`gateway which is depicted here as router 75,
`but which may also be a gateway having a
`firewall or a network bridge. Network 60 is an
`example of an Ethernet network that
`interconnects host 61, which is a SPARC
`workstation, which may be running SUNOS
`operating system with host 62, which may be a
`Digital Equipment VAX6000 computer which
`may be running the VMS oper ating system.
`Router 75 is a network access point (NAP) of
`network 70 and network 60. Router 75 employs
`a Token Ring adapter and Ethernet adapter.
`This enables router 75 to interface with the two
`heterogeneous networks. Router 75 is also
`aware of the Inter-network Protocols, such as
`ICMP ARP and RIP, which are described
`
`EX1038, 3
`
`

`

`herein below." Prov. at 12:14-30; See Fig. 1A,
`1B, 1C, 1D.
`
`“The present invention provides a method for
`classifying traffic according to a definable set
`of classification attributes selectable by the
`manager, including selecting a subset of traffic
`of interest to be classified. The invention
`provides the ability to classify and search traffic
`based upon multiple orthogonal classification
`attributes. Traffic class membership may be
`hierarchical. Thus, a flow may be classified by
`a series of steps through a traffic class tree, with
`the last step (i.e., at the leaves on the
`classification tree) mapping the flow to a
`policy. The policy is a rule of assignment for
`flows. For example, the first step in
`classification may be to classify a flow as web
`traffic, the next may further classify this flow as
`belonging to server X, and the final
`classification may be a policy for URI “*.avi”.”
`Prov. at 16:8-17.
`
`“Network traffic is automatically classified
`under existing classes, beginning with the
`broadest classes, an inbound traffic class and an
`outbound traffic class, in protocol layer
`independent categories. For example, a
`particular instance of traffic may be classified
`according to its transport layer characteristics,
`e.g., Internet Protocol port number, as well as
`its application layer information, e.g., SMTP.
`Characteristics such as MIME types may also
`be automatically identified. Standard protocols,
`such as, IPX, SNA, and services, such as,
`SMTP and FTP are recognized for automatic
`classification. Classification is performed to
`the most specific level determinable. For
`example, in select embodiments, non-IP traffic,
`such as SNA, may be classified only by
`
`EX1038, 4
`
`

`

`protocol, whereas Internet Protocol traffic may
`be classified to the /etc/services level.
`Classification beyond a terminal classification
`level is detected and prevented. For example,
`in a select embodiment, a class matching “ipx”
`or “nntp” will not be further automatically
`classified.” Prov. at 18:24-19:2.
`“A service aggregate is provided for certain
`applications that use more than one connection
`in a particular conversation between a client
`and a server. For example, an FTP client in
`conversation with an FTP server employs a
`command channel and a transfer channel,
`which are distinct TCP sessions on two
`different ports. In cases where two or three
`TCP or UDP sessions exist for each
`conversation between one client and one server,
`it is useful to provide a common traffic class
`i.e., the service aggregate, containing the
`separate conversations. In practice, these types
`of conversations are between the same two
`hosts, but use different ports. According to the
`invention, a class is created with a plurality of
`traffic specifications, each matching various
`component conversations.” Prov. at 19:5-14.
`See also Prov. at 19:15-21:15.
`“Fig. 4A depicts a flowchart 401 of processing
`steps for automatically classifying traffic. In a
`step 402, a flow specification is parsed from the
`flow being classified. Then in a step 404, the
`flow specification parsed from the flow in step
`402 is compared with the traffic specifications
`in each node of the classification tree. Rules
`are checked starting from most specific to least
`specific. In a decisional step 406, a
`determination is made if traffic matches the
`class being classified, but no class more
`
`EX1038, 5
`
`

`

`specific, i.e., reaches the match_all node 310 in
`Fig. 3. If this is so, then in a step 408, an entry
`is made in a list of identifying characteristics,
`such as protocol type (SAP), IP protocol
`number, server port, traffic type if known,
`MIME type, a time of occurrence of the traffic.
`In an optional step 410, duplicate instances
`having the same identifying characteristics are
`suppressed, in favor of keeping a count of the
`duplicates and a most recent time traffic with
`these identifying characteristics was
`encountered. In an optional step 412, a byte
`count of traffic of this type has been detected is
`included. If, in decisional step 406, it is
`determined that traffic specification did not
`match the flow specification for the class being
`classified, then, in a step 414, processing
`backtracks up the classification tree to a parent
`node, and in a decisional step 416, a
`determination is made if there are any more
`parent nodes, or if processing has reached the
`root node of the tree. If there is a valid parent
`node, then processing continues with step 404
`comparing the flow specification with the
`traffic specification of the parent node.
`Otherwise, the automatic classification has
`failed to determine a class and processing
`returns.” Prov. at 21:16-.22:22.
`
`Figs. 4A, 4B
`“The present invention provides a method for
`classifying traffic according to a definable set
`of classification attributes selectable by the
`manager, including selecting a subset of traffic
`of interest to be classified. The invention
`provides the ability to classify and search traffic
`based upon multiple orthogonal classification
`attributes. Traffic class membership may be
`hierarchical. Thus, a flow may be classified by
`a series of steps through a traffic class tree, with
`
`EX1038, 6
`
`thereupon, matching the
`first flow specification of
`the parsing step to a
`plurality of classes
`represented by a plurality
`nodes of a classification
`tree type, each said
`classification tree type
`node having a traffic
`specification
`
`

`

`the last step (i.e., at the leaves on the
`classification tree) mapping the flow to a
`policy. The policy is a rule of assignment for
`flows. For example, the first step in
`classification may be to classify a flow as web
`traffic, the next may further classify this flow as
`belonging to server X, and the final
`classification may be a policy for URI “*.avi”.”
`Prov. at 16:8-17.
`
`“A classification tree is a data structure
`representing the hierarchical aspect of traffic
`class relationships. Each node of the
`classification tree represents a class, and has a
`traffic specification, i.e., a set of attributes or
`characteristics describing the traffic, and a
`mask associated with it. Leaf nodes of the
`classification tree may contain policies.
`According to a particular embodiment, the
`classification process checks at each level if the
`flow being classified matches the attributes of a
`given traffic class. If it does, processing
`continues down to the links associated with that
`node in the tree. If it does not, the class at the
`level that matches determines the policy for the
`flow being classified. If no policy specific
`match is found, the flow is assigned the default
`policy.” Prov. at 16:18-26.
`
`“In a preferable embodiment, the classification
`tree is an N-ary tree with its nodes ordered by
`specificity. For example, in classifying a
`particular flow in a classification tree ordered
`first by organizational departments, the
`attributes of the flow are compared with the
`traffic specification in each successive
`department node and if no match is found, then
`processing proceeds to the next subsequent
`department node. If no match is found, then the
`
`EX1038, 7
`
`

`

`final compare is a default “match all” category.
`If, however, a match is found, then
`classification moves to the children of this
`department node. The child nodes may be
`ordered by an orthogonal paradigm such as, for
`example, “service type.” Matching proceeds
`according to the order of specificity in the child
`nodes. Processing proceeds in this manner,
`traversing downward and from left to right in
`Figs. 2A and 2B, which describe a
`classification tree, searching the plurality of
`orthogonal paradigms. Key to implementing
`this a hierarchy is that the nodes are arranged in
`decreasing order of specificity. This permits
`search to find the most specific class for the
`traffic before more general.” Prov. at 16:27-
`17:7.
`“Network traffic is automatically classified
`under existing classes, beginning with the
`broadest classes, an inbound traffic class and an
`outbound traffic class, in protocol layer
`independent categories. For example, a
`particular instance of traffic may be classified
`according to its transport layer characteristics,
`e.g., Internet Protocol port number, as well as
`its application layer information, e.g., SMTP.
`Characteristics such as MIME types may also
`be automatically identified. Standard protocols,
`such as, IPX, SNA, and services, such as,
`SMTP and FTP are recognized for automatic
`classification. Classification is performed to
`the most specific level determinable. For
`example, in select embodiments, non-IP traffic,
`such as SNA, may be classified only by
`protocol, whereas Internet Protocol traffic may
`be classified to the /etc/services level.
`Classification beyond a terminal classification
`level is detected and prevented. For example,
`in a select embodiment, a class matching “ipx”
`
`EX1038, 8
`
`

`

`or “nntp” will not be further automatically
`classified.” Prov. at 18:24-19:2.
`“A service aggregate is provided for certain
`applications that use more than one connection
`in a particular conversation between a client
`and a server. For example, an FTP client in
`conversation with an FTP server employs a
`command channel and a transfer channel,
`which are distinct TCP sessions on two
`different ports. In cases where two or three
`TCP or UDP sessions exist for each
`conversation between one client and one server,
`it is useful to provide a common traffic class
`i.e., the service aggregate, containing the
`separate conversations. In practice, these types
`of conversations are between the same two
`hosts, but use different ports. According to the
`invention, a class is created with a plurality of
`traffic specifications, each matching various
`component conversations.” Prov. at 19:5-14.
`“Fig. 4A depicts a flowchart 401 of processing
`steps for automatically classifying traffic. In a
`step 402, a flow specification is parsed from the
`flow being classified. Then in a step 404, the
`flow specification parsed from the flow in step
`402 is compared with the traffic specifications
`in each node of the classification tree. Rules
`are checked starting from most specific to least
`specific. In a decisional step 406, a
`determination is made if traffic matches the
`class being classified, but no class more
`specific, i.e., reaches the match_all node 310 in
`Fig. 3. If this is so, then in a step 408, an entry
`is made in a list of identifying characteristics,
`such as protocol type (SAP), IP protocol
`number, server port, traffic type if known,
`MIME type, a time of occurrence of the traffic.
`In an optional step 410, duplicate instances
`
`EX1038, 9
`
`

`

`having the same identifying characteristics are
`suppressed, in favor of keeping a count of the
`duplicates and a most recent time traffic with
`these identifying characteristics was
`encountered. In an optional step 412, a byte
`count of traffic of this type has been detected is
`included. If, in decisional step 406, it is
`determined that traffic specification did not
`match the flow specification for the class being
`classified, then, in a step 414, processing
`backtracks up the classification tree to a parent
`node, and in a decisional step 416, a
`determination is made if there are any more
`parent nodes, or if processing has reached the
`root node of the tree. If there is a valid parent
`node, then processing continues with step 404
`comparing the flow specification with the
`traffic specification of the parent node.
`Otherwise, the automatic classification has
`failed to determine a class and processing
`returns.” Prov. at 21:16-.22:22.
`
`Figs. 4A, 4B
`Figs. 4A, 4B
`
`“Fig. 4B depicts a flowchart 403 of the
`processing steps for integrating traffic classes
`into a classification tree in an alternative
`embodiment. Processing steps of flowchart 403
`periodically at a defined interval of seconds,
`having a value of 30 in the preferable
`embodiment, incorporate newly classified
`traffic into the classification tree. In a step 420,
`an instance of saved traffic is retrieved from the
`saved traffic list 308. Next in a decisional step
`422, the instance of saved traffic is examined to
`determine whether it is well-known (e.g.
`registered SAP, protocol type, assigned port
`number) and a name representing its type
`exists. If this is so then processing continues
`
`EX1038, 10
`
`thereupon, if a matching
`classification tree type
`node was not found in the
`matching step, associating
`said first flow specification
`with one or more newly-
`created classification tree
`type nodes
`
`

`

`with the new traffic class in step 425.
`Otherwise, in a step 423 the instance of saved
`traffic is examined to determine whether it
`appears to be a server connection port of an
`unregistered IP port (or a port that has not been
`configured). If this is not so then, processing
`continues with the next traffic class in the saved
`list in step 420. Otherwise, in a step 425, a
`traffic class is created to match the instance of
`saved traffic. The class may be flat or
`hierarchical. Next, in a decisional step 426, the
`instance of saved traffic is examined to
`determine whether it belongs to a service
`aggregate. For example, an FTP session has
`one flow that is used to exchange commands
`and responses and a second flow that is used to
`transport data files. If the traffic does belong to
`a service aggregate, then in a step 428, a traffic
`class is created which will match all
`components of the service aggregate.” Prov. at
`23:5-22.
`“Traffic classes are created for any combination
`of the above mentioned categories. A flag is
`added to all traffic classes so created in order to
`indicate that it is the product of the auto
`classifier.” Prov. at 24:9-11.
`
`“Fig. 4B depicts a flowchart 403 of the
`processing steps for integrating traffic classes
`into a classification tree in an alternative
`embodiment. Processing steps of flowchart 403
`periodically at a defined interval of seconds,
`having a value of 30 in the preferable
`embodiment, incorporate newly classified
`traffic into the classification tree. In a step 420,
`an instance of saved traffic is retrieved from the
`saved traffic list 308. Next in a decisional step
`422, the instance of saved traffic is examined to
`determine whether it is well-known (e.g.
`
`EX1038, 11
`
`thereupon, incorporating
`said newly-created
`classification tree type
`nodes into said plurality of
`classification tree type
`nodes
`
`

`

`registered SAP, protocol type, assigned port
`number) and a name representing its type
`exists. If this is so then processing continues
`with the new traffic class in step 425.
`Otherwise, in a step 423 the instance of saved
`traffic is examined to determine whether it
`appears to be a server connection port of an
`unregistered IP port (or a port that has not been
`configured). If this is not so then, processing
`continues with the next traffic class in the saved
`list in step 420. Otherwise, in a step 425, a
`traffic class is created to match the instance of
`saved traffic. The class may be flat or
`hierarchical. Next, in a decisional step 426, the
`instance of saved traffic is examined to
`determine whether it belongs to a service
`aggregate. For example, an FTP session has
`one flow that is used to exchange commands
`and responses and a second flow that is used to
`transport data files. If the traffic does belong to
`a service aggregate, then in a step 428, a traffic
`class is created which will match all
`components of the service aggregate.” Prov. at
`23:5-22.
`“Traffic classes are created for any combination
`of the above mentioned categories. A flag is
`added to all traffic classes so created in order to
`indicate that it is the product of the auto
`classifier.” Prov. at 24:9-11.
`Figs. 4A, 4B
`“According to the invention, in a packet
`communication environment, a method is
`provided for automatically classifying packet
`flows for use in allocating bandwidth resources
`by a rule of assignment of a service level. The
`method comprises applying individual instances
`of traffic classification paradigms to packet
`network flows based on selectable information
`
`EX1038, 12
`
`8. A system for
`automatically classifying
`traffic in a packet
`telecommunications
`network, said network
`having any number of
`flows, including zero,
`comprising:
`
`

`

`obtained from a plurality of layers of a multi-
`layered communication protocol in order to
`define a characteristic class, then mapping the
`flow to the defined traffic class. It is useful to
`note that the automatic classification is
`sufficiently robust to classify a complete
`enumeration of the possible traffic.” Prov. at
`5:29-6:3.
`
`“The present invention provides techniques to
`automatically classify a plurality of
`heterogeneous packets in a packet
`telecommunications system for management of
`network bandwidth in systems such as a private
`area network, a wide area network or an
`internetwork. Systems according to the present
`invention enable network managers to:
`automatically define traffic classes, for which
`policies may then be created for specifying
`service levels for the traffic classes and
`isolating bandwidth resources associated with
`certain traffic classes. Inbound as well as
`outbound traffic may be managed.” Prov. at
`7:7-14.
`"Fig. 1C is illustrative of the internetworking of
`a plurality of clients such as client 25 of Figs.
`1A and 1B and a plurality of servers such as
`server 20 of Figs. 1A and 1B as described
`herein above. In Fig. 1C, network 70 is an
`example of a Token Ring or frame oriented
`network. Network 70 links host 71, such as an
`IBM RS6000 RISC workstation, which may be
`running the AIX operating system, to host 72,
`which is a personal computer, which may be
`running Windows 95, IBM OS/2 or a DOS
`operating system, and host 73, which may be an
`IBM AS/400 computer, which may be running
`the OS/400 operating system. Network 70 is
`internetworked to network 60 via a system
`gateway which is depicted here as router 75,
`
`EX1038, 13
`
`a plurality of network links
`upon which said traffic is
`carried; a network routing
`means; and,
`
`

`

`but which may also be a gateway having a
`firewall or a network bridge. Network 60 is an
`example of an Ethernet network that
`interconnects host 61, which is a SPARC
`workstation, which may be running SUNOS
`operating system with host 62, which may be a
`Digital Equipment VAX6000 computer which
`may be running the VMS oper ating system.
`Router 75 is a network access point (NAP) of
`network 70 and network 60. Router 75 employs
`a Token Ring adapter and Ethernet adapter.
`This enables router 75 to interface with the two
`heterogeneous networks. Router 75 is also
`aware of the Inter-network Protocols, such as
`ICMP ARP and RIP, which are described
`herein below." Prov. at 12:14-30; See Fig. 1A,
`1B, 1C, 1D.
`“The present invention provides techniques to
`automatically classify a plurality of
`heterogeneous packets in a packet
`telecommunications system for management of
`network bandwidth in systems such as a private
`area network, a wide area network or an
`internetwork. Systems according to the present
`invention enable network managers to:
`automatically define traffic classes, for which
`policies may then be created for specifying
`service levels for the traffic classes and
`isolating bandwidth resources associated with
`certain traffic classes. Inbound as well as
`outbound traffic may be managed.” Prov. at
`7:7-14.
`
`"The hardware configurations are in general
`standard and will be described only briefly. In
`accordance with known practice, server 20
`includes one or more processors 30 which
`communicate with a number of peripheral
`devices via a bus subsystem 32. These
`peripheral devices typically include a storage
`
`EX1038, 14
`
`a processor means
`operative to: parse a packet
`into a first flow
`specification, wherein said
`first flow specification
`contains at least one
`instance of any one of the
`following:
`a protocol family
`designation,
`a direction of packet flow
`designation,
`a protocol type
`designation,
`a pair of hosts,
`a pair of ports,
`in HTTP protocol packets,
`a pointer to a MIME type;
`
`

`

`subsystem 35, comprised of a memory
`subsystem 35a and a file storage subsystem 35b
`holding computer programs (e.g., code or
`instructions) and data, a set of user interface
`input and output devices 37, and an interface to
`outside networks, which may employ Ethernet,
`Token Ring, ATM, IEEE 802.3, ITU X.25,
`Serial Link Internet Protocol (SLIP) or the
`public switched telephone network. This
`interface is shown schematically as a "Network
`Interface" block 40. It is coupled to
`corresponding interface devices in client
`computers via a network connection 45." Prov.
`at 10:24-11:2.
`
`"Fig. 1B is a functional diagram of a computer
`system such as that of Fig. 1A. Fig. 1B depicts
`a server 20, and a representative client 25 of a
`plurality of clients which may interact with the
`server 20 via the Internet 45 or any other
`communications method. Blocks to the right of
`the server are indicative of the processing steps
`and functions which occur in the server's
`program and data storage indicated by blocks
`35a and 35b in Fig. 1A." Prov. at 11:21-26.
`
`"Fig. 1C is illustrative of the internetworking of
`a plurality of clients such as client 25 of Figs.
`1A and 1B and a plurality of servers such as
`server 20 of Figs. 1A and 1B as described
`herein above. In Fig. 1C, network 70 is an
`example of a Token Ring or frame oriented
`network. Network 70 links host 71, such as an
`IBM RS6000 RISC workstation, which may be
`running the AIX operating system, to host 72,
`which is a personal computer, which may be
`running Windows 95, IBM OS/2 or a DOS
`operating system, and host 73, which may be an
`IBM AS/400 computer, which may be running
`
`EX1038, 15
`
`

`

`the OS/400 operating system. Network 70 is
`internetworked to network 60 via a system
`gateway which is depicted here as router 75,
`but which may also be a gateway having a
`firewall or a network bridge. Network 60 is an
`example of an Ethernet network that
`interconnects host 61, which is a SPARC
`workstation, which may be running SUNOS
`operating system with host 62, which may be a
`Digital Equipment VAX6000 computer which
`may be running the VMS oper ating system.
`Router 75 is a network access point (NAP) of
`network 70 and network 60. Router 75 employs
`a Token Ring adapter and Ethernet adapter.
`This enables router 75 to interface with the two
`heterogeneous networks. Router 75 is also
`aware of the Inter-network Protocols, such as
`ICMP ARP and RIP, which are described
`herein below." Prov. at 12:14-30; See Fig. 1A,
`1B, 1C, 1D.
`
`“The present invention provides a method for
`classifying traffic according to a definable set
`of classification attributes selectable by the
`manager, including selecting a subset of traffic
`of interest to be classified. The invention
`provides the ability to classify and search traffic
`based upon multiple orthogonal classification
`attributes. Traffic class membership may be
`hierarchical. Thus, a flow may be classified by
`a series of steps through a traffic class tree, with
`the last step (i.e., at the leaves on the
`classification tree) mapping the flow to a
`policy. The policy is a rule of assignment for
`flows. For example, the first step in
`classification may be to classify a flow as web
`traffic, the next may further classify this flow as
`belonging to server X, and the final
`classification may be a policy for URI “*.avi”.”
`Prov. at 16:8-17.
`
`EX1038, 16
`
`

`

`“Network traffic is automatically classified
`under existing classes, beginning with the
`broadest classes, an inbound traffic class and an
`outbound traffic class, in protocol layer
`independent categories. For example, a
`particular instance of traffic may be classified
`according to its transport layer characteristics,
`e.g., Internet Protocol port number, as well as
`its application layer information, e.g., SMTP.
`Characteristics such as MIME types may also
`be automatically identified. Standard protocols,
`such as, IPX, SNA, and services, such as,
`SMTP and FTP are recognized for automatic
`classification. Classification is performed to
`the most specific level determinable. For
`example, in select embodiments, non-IP traffic,
`such as SNA, may be classified only by
`protocol, whereas Internet Protocol traffic may
`be classified to the /etc/services level.
`Classification beyond a terminal classification
`level is detected and prevented. For example,
`in a select embodiment, a class matching “ipx”
`or “nntp” will not be further automatically
`classified.” Prov. at 18:24-19:2.
`“A service aggregate is provided for certain
`applications that use more than one connection
`in a particular conversation between a client
`and a server. For example, an FTP client in
`conversation with an FTP server employs a
`command channel and a transfer channel,
`which are distinct TCP sessions on two
`different ports. In cases where two or three
`TCP or UDP sessions exist for each
`conversation between one client and one server,
`it is useful to provide a common traffic class
`i.e., the service aggregate, containing the
`separate conversations. In practice, these types
`of conversations are between the same two
`
`EX1038, 17
`
`

`

`hosts, but use different ports. According to the
`invention, a class is created with a plurality of
`traffic specifications, each matching various
`component conversations.” Prov. at 19:5-14.
`See also Prov. at 19:15-21:15.
`“Fig. 4A depicts a flowchart 401 of processing
`steps for automatically classifying traffic. In a
`step 402, a flow specification is parsed from the
`flow being classified. Then in a step 404, the
`flow specification parsed from the flow in step
`402 is compared with the traffic specifications
`in each node of the classification tree. Rules
`are checked starting from most specific to least
`specific. In a decisional step 406, a
`determination is made if traffic matches the
`class being classified, but no class more
`specific, i.e., reaches the match_all node 310 in
`Fig. 3. If this is so, then in a step 408, an entry
`is made in a list of identifying characteristics,
`such as protocol type (SAP), IP protocol
`number, server port, traffic type if known,
`MIME type, a time of occurrence of the traffic.
`In an optional step 410, duplicate instances
`having the same identifying characteristics are
`suppressed, in favor of keeping a count of the
`duplicates and a most recent time traffic with
`these identifying characteristics was
`encountered. In an optional step 412, a byte
`count of traffic of this type has been detected is
`included. If, in decisional step 406, it is
`determined that traffic specification did not
`match the flow specification for the class being
`classified, then, in a step 414, processing
`backtracks up the classification tree to a parent
`node, and in a decisional step 416, a
`determination is made if there are any more
`parent nodes, or if processing has reached the
`root node of the tree. If there is a valid parent
`
`EX1038, 18
`
`

`

`thereupon, match the first
`flow specification of the
`parsing step to a plurality
`of classes represented by a
`plurality of said
`classification tree type
`nodes, each said
`classification tree type
`node having a traffic
`specification and a mask,
`according to the mask;
`
`node, then processing continues with step 404
`comparing the flow specification with the
`traffic specification of the parent node.
`Otherwise, the automatic classification has
`failed to determine a class and processing
`returns.” Prov. at 21:16-.22:22.
`
`Figs. 4A, 4B
`“The present invention provides a method for
`classifying traffic according to a definable set
`of classification attributes selectable by the
`manager, including selecting a subset of traffic
`of interest to be classified. The invention
`provides the ability to classify a

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket