Sony Communications International AB v SSH Communications Security Corporation

This is an action concerning infringement and validity of European Patent EP(UK) 2 254 311 (“the Patent”), owned by SSH. Sony commenced the action, seeking revocation, in response to which, SSH put forward three sets of conditional amendments and counterclaimed for infringement in respect of a number of mobile phones sold by Sony. Sony denies infringement and objects to the amendments.

Although the alleged infringements relate to mobile phones, this is not a mobile phone patent but rather, it relates to an aspect of accessing wide area networks (WANs), such as the internet. The Patent is entitled “Maintaining address translation for data communications”. It is divided out from a filing that covered numerous aspects of setting up and maintaining secure communication connections over the Internet. Specifically, the inventions were concerned with ensuring that the ‘IPsec’ (Internet Protocol Security) protocol suite, then recently standardised by the Internet Engineering Task Force (IETF), could be used reliably and securely through a Network Address Translator (NAT). NATs are intermediate nodes in the network which act as gateways between a private network and a public network, such as the Internet.

The invention that is the subject of this divisional Patent is described in paragraphs [0039] – [0041] as the ‘keepalive’ aspect of the invention which I will deal with below.

A patent specification is addressed to those likely to have a practical interest in the subject matter of the invention, and such persons are those with a practical knowledge and experience of the kind of work in which the invention is intended to be used (Sandvik v Kennametal [2012] RPC 23, [18] (Arnold J)).

Specifically, the skilled person is a person who would act on the directions in the patent for its performance (Osram Lamp Works Ltd v Pope’s Electric Lamp Co (1917) 34 RPC 369 at 391 (Lord Parker)).

In this case both parties agree that means a programmer who would write software that would carry out the method of the method claims. The same software, when loaded, would turn a general purpose device (such as a computer or server) into a device within the device claims. Such a person would be a computer scientist with knowledge of developing applications which run over computer networks. SSH’s expert, Mr Holdrege, described the skilled addressee as an engineer working with packet switched networks, working by him or herself, or as part of a small team of two to four engineers, developing an architecture, a product, a software program etc. and Sony do not challenge that description.

The Claimant’s expert was Professor Leslie, an academic in the Computer Science Department at Cambridge University. At the priority date he was the Robert Sansom Professor of Computer Science, having previously been a university lecturer, and director of studies in Computer Science at Christ’s College. He was involved in the development of the Cambridge Ring intranet system. Counsel for SSH criticise him as not being remotely representative of the skilled person at the priority date. They say that his approach to educating himself as to the position of the skilled addressee was unsatisfactory as, instead of considering textbooks or the content of undergraduate courses, he relied on documents “carefully selected for him” by his instructing solicitors resulting from specifically targeted searches on the Internet.

Whilst Professor Leslie did rely on the results of such searches carried out by his instructing solicitors, this was to show that a particular concept was widely used in the relevant field. There was no suggestion that most of the documents he relied on were, themselves, part of the common general knowledge of the skilled addressee. I reject this criticism of Professor Leslie’s evidence.

Professor Leslie gave his evidence carefully and was not argumentative. I found his evidence balanced and helpful.

SSH’s expert was Mr Holdrege, a network engineer who was employed by Ascend, a leading manufacturer of network access technology, at the priority date of the Patent. He was the co-chair of the Internet Engineering Task Force (IETF) NAT working group at the priority date.

Mr Holdrege was more inclined to argue points rather than giving straightforward answers to questions. Sony suggest that, as a result, his evidence was unsatisfactory. I believe that is overstating the problem. Mr Holdrege was attempting to assist the Court. He was, perhaps, overenthusiastic in his approach to the issue. The major criticism that I believe is justified, is that he appeared to be unfamiliar with the content of various documents that he had exhibited in support of his evidence. Under cross-examination it was pointed out to him that some of them did not support his evidence. He was reluctant to accept the point although it was clearly the case. I will refer to one particular example below in considering common general knowledge. I do not believe that this was a deliberate attempt to mislead the Court but was the result of a somewhat slapdash approach to his evidence. It appeared that he had relied upon the results of searches carried out by his instructing solicitors without checking them.

As a result, where there is a direct conflict between Mr Holdrege’s evidence and that of Professor Leslie, I prefer the evidence of Professor Leslie.

To understand the context of the invention, it is necessary to understand the operation of NAT.

At a very basic level, a computer network consists of a number of computers, or nodes, each connected to every other node by means of a communications connection, or link, such as a wired or wireless connection. In order for nodes to communicate with other nodes, each node must be uniquely addressable on that network.

Networks can be broadly categorized as local area networks (LANs) and wide area networks (WANs).

A LAN is a network where all links are privately owned and maintained within a single building or site. A LAN typically consists of a number of end-nodes interconnected by means of a switch. A switch is a networking device to which nodes physically connect, by way of a link. Switches may also be connected by links to other switches.

In a WAN, some of the links span greater distances and may not be privately owned (e.g. those owned by public telecommunications operators). A WAN is generally connected by a routerto various LANs. A router is required to forward data to another network.

Therefore, a switch sits within a network and connects different segments of that network, switching packets destined for specific nodes on that network. It does not itself send or receive packets from another network. In essence, a switch allows nodes on a network to connect to each other.

By contrast, a router can sit at the edge of a private network and connect it to another network (or networks) and route packets from one network to another according to its routing rules.

In Figure 1 below, both the Ethernet switch and the WiFi access point are link-layer switches:

The Internet Protocol Suite or Internet layer model defines a five-layer network protocol architecture, with each layer representing a set of features and functionality necessary to give effect to communication between two nodes in a network. This set of protocols underpins the Internet:

Layer 5, the 'Application Layer', provides services for an application program to ensure that effective communication with another application program in a network is possible.

Layer 4, the 'Transport Layer', is concerned with the reliability (or lack thereof) of transferring information across a potentially unreliable network. The end points associated with this layer are usually the particular processes or tasks within the respective end nodes, rather than the nodes themselves. Two common transport protocols are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

Layer 3, the 'Network Layer', is concerned with transferring packets between nodes anywhere on a network, including how nodes are addressed. The Network Layer in the Internet Protocol Suite is the Internet Protocol (IP).

Layer 2, the 'Data Link Layer', is concerned with establishing and maintaining an actual (as opposed to logical) communication between two directly connected nodes. It is concerned with how data ought to be packaged to enable it to be transmitted over the physical medium defined in layer 1. Media Access Control (MAC) addresses are a type of address used at this layer. A MAC address is 48 bits long and is usually globally unique.

Layer 1, the 'Physical Layer', is concerned with the actual encoding of data onto an electromagnetic signal (e.g. radio wave, optical signal or baseband signal on a copper wire). Protocols at this layer typically specify things such as signal characteristics, modulation schemes and minimum specifications for transmission media.

Therefore, in the Internet Protocol Suite, data to be transmitted is created and formatted by the application layer and is then passed to the TCP/UDP layer which generates appropriate TCP/UDP packets which are then encapsulated into IP packets, for transmission over a network. IP packets are variable in length (up to a maximum of 65,595 bytes). They consist of a payload portion, which contains the data, and a header portion (20 to 60 bytes), which contains addressing information to facilitate delivery of that packet to its intended destination.

The IP packets are then passed to the data link layer. Each IP packet is encapsulated into one or more data link layer packets, often called frames, for actual transmission over a physical interface. One of the benefits of this approach is that the Internet can operate as a logical network over a number of different physical network infrastructures (e.g. cable, optical fibre, cellular, wifi etc.).

Transmission over a physical network infrastructure is left to the data link layer and physical layer.

The IP layer facilitates routing of an IP packet from a source node A to a destination node B. There are two co-existing versions of IP, IPv4 and IPv6. It is normal to refer to the former as IP, whereas the latter is referred to as IPv6 to differentiate it from IPv4. In the interests of clarity, I will use the terms “IPv4” and “IPv6” when referring to IPv4 and IPv6 respectively, and will use the term “IP” when referring to them both collectively.

At the priority date of the Patent, in 1999, IPv4 was used almost exclusively. At that time, IPv6 had been partially standardised. Whilst IPv6 now represents a significant proportion of IP traffic, IPv4 remains the dominant version. IPv4 and IPv6 operate at the network layer and include a means for addressing nodes on a network.

IPv4 addresses are 32 bits long, and are denoted numerically as 4 octets (groups of 8 bits), with each octet taking a value between 0 and 255. IPv4 addresses are written in the format “xxx.xxx.xxx.xxx”. Theoretically, this allows for approximately 4 billion addresses (though the actual number is smaller than this).

IPv6 addresses are 128 bits long, and are denoted in hexadecimal notation as 8 groups of 4 hexadecimal digits, written in the format “xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx”. Each group of 4 hexadecimal digits represents 16 bits. This allows for approximately 34 x 10³⁸ addresses.

Both IPv4 and IPv6 packet headers include fields for a “Destination IP Address”, which is used to route the packet to the destination node, and a “Source IP Address”, which allows the destination to know from where the packet was sent (and hence be able to respond). An important point to note is that the differences between IPv4 and IPv6 all relate to the packet headers – both IPv4 and IPv6 packets can carry the same content (or payload).

IPv4 addresses are generally globally unique over the (public) Internet. However, there are also specific ranges of IPv4 addresses reserved for private networks to use that are not globally unique, and there is nothing to stop a private network owner from “reusing” public addresses internally as long as suitable address translations are performed in any connection to the public Internet. The need to do so may arise because there may well be a demand globally for more than 4 billion addresses (some estimates suggest that the IPv4 address space was exhausted in February 2011). In contrast, it is not envisaged that the IPv6 address space will be exhausted for some considerable time.

An IPv4 address can be split into a network address portion, consisting of a grouping of the most significant bits of the IPv4 address, and a host address portion, consisting of a grouping of the least significant bits of an IPv4 address. For example, the IPv4 address “213.104.143.144” might split into a network address “213.104” and a host address “143.144.”. The network address identifies the network to which a node is attached, and the host address identifies the node within that network. Similarly, an IPv6 address can also be split into a network address portion and a host address portion.

Unless they are directly connected to the destination network, routers only have to look at the network address portion of an IP address to decide where to send a packet. A router has multiple network interfaces and maintains a routing table, which is a mapping of a network interface to a set of one or more network address prefixes. For example, a router receiving a packet with a destination IPv4 address “123.125.78.79” will look in its routing table to find the longest matching prefix stored there. If that prefix is “123.125.0.0/16”, which matches the first sixteen bits, then it will send the IPv4 packet out on the network interface associated with that prefix. If on the other hand it has a longer prefix of say “123.125.78.0/24”, that is a prefix of 24 bits, then it will send the packet out on the network interface associated with that prefix. If no matching prefix is found, the router will send the IPv4 packet out over its default network interface, presuming that eventually the IPv4 packet will reach a router that will have a matching prefix entry.

Similarly, once an IPv4 packet reaches a router directly attached to a network with network address “123.125.x.x”, that router will route the packet using the host address portion of the IPv4 address. IPv6 addresses are routed in a similar manner.

However, a node may have multiple applications or processes connecting to the IP network at the same time – for example, a desktop computer may be using a web browser and an email manager simultaneously. Therefore, IP packets arriving at node B must be directed to the relevant process.

The TCP layer is used to direct IP packets in this way by assigning a destination port number to the IP packet, and this destination port number is included in the TCP header contained within the IP packet. The destination node identifies the application process or task that is needed to process the IP packet by looking at the port number. For example, port 80 is by convention associated with HTTP, so the destination node knows that an IP packet destined for port 80 contains HTTP data, and so needs to be processed by an appropriate application, such as a web server. In addition to well-known ports, such as port 80, there are also a large number of port numbers (49,152 – 65,535) for users to use for their own purposes. For example, a company with its own proprietary service may choose to use port 51,237 for that service. A node belonging to that company receiving an IP packet destined for port 51,237 will know that the data in that IP packet is destined for the proprietary service. An IP address and port number can be written in the format xxx.xxx.xxx.xxx : yy (‘x’ being the IP address, and ‘y’ the port number).

Rather than generate IP packets itself and manage reassembly of those packets in order, the application layer passes sequences of bytes to the TCP layer, which in turn arranges those bytes into segments and adds its own TCP header to each segment, containing information that will allow the TCP layer and the receiving node end to reassemble the data sequence from the TCP segments. The TCP segments are passed to the IP layer, which encapsulates them into IP packets, adding its own IP header.

Before substantive transmission of a sequence begins, TCP sends an initial message containing header information that requires the receiving node to acknowledge it has received that message. On receiving this acknowledgement, the sending node TCP layer will commence substantive transmission of the data sequence, and in that same header will acknowledge that it received the receiving node’s acknowledgement of the last TCP segment. This is known as a three-way handshake. On completion of the three-way handshake, a session is established between the sending and receiving nodes. The receiving node acknowledges reception of TCP segments to enable the further transmission of TCP segments. Missing acknowledgements expected by the sender cause retransmission. Flow control results by allowing the receiver to restrict how far ahead in the data stream the sender can go, relative to the last acknowledged segment.

As a result: (i) an association is maintained between IP packets relating to a TCP stream; and (ii) a communication connection, defined by port numbers, is maintained between the sending node and the receiving node for a specific stream, until there is an explicit termination of the TCP connection or a time-out (thus ending the session). For this reason, TCP is considered to be a connection-oriented protocol.

A particular TCP connection is identified and distinguished by four attributes, which are included in the TCP header: the source IP address, the source port number, the destination IP address and the destination port number.

TCP provides for reliable, ordered delivery of information so that a sequence of bytes can be reconstructed at the receiver despite occasional packet loss at the IP layer. TCP provides both re-transmission in the face of packet loss and flow control to ensure that the transmitter does not send information at a rate greater than the receiver can receive and process it.

In TCP, the receiving node acknowledges receipt of information by transmitting ACK messages. Each ACK message includes a reference to a point in the transmitted information sequence that it is acknowledging receipt of. Usually, depending on options selected, this will acknowledge all data up to that point in the sequence. The transmitting node will then send the next part of the information sequence in a packet, and so on.

TCP allows a transmitter to send a certain amount of information, for example many packets worth beyond the point in the sequence that has been acknowledged by the receiver. This amount of information is called a window. Indeed when sending an acknowledgement, the receiver also adjusts the size of the window (for example, the receiver may set the window size to zero to pause the transmitter). This process is known as flow control.

Once a sending node has finished transmitting all of the packets it intends to send, it sends a FIN message to the receiving node, which must then reply with an ACK message, acknowledging receipt of the FIN message, and also with its own FIN message, which the transmitting mode must then acknowledge with an ACK message. The TCP connection between the transmitting and receiving node is closed when the receiving node receives this last ACK message from the transmitting node, thus also ending the session.

Unlike TCP, UDP is a connectionless protocol. It does not specify any flow control or retransmission mechanisms like TCP, and therefore does not guarantee delivery of packets nor does it maintain sessions. Instead, UDP relies on the characteristics and performance of the underlying IP network to deliver packets on a best-effort basis to the receiving node without maintaining any state information. UDP also operates with port numbers in the same way as TCP.

UDP is a very simple layer 4 protocol that permits the encapsulation of IP packets into UDP datagrams. The packet header includes a checksum field, so that the integrity of the encapsulated payload can be verified by the receiving node, and fields for the source port and destination port, allowing for host-to-host communication.

The 'lightweight' nature of UDP makes it particularly well suited to real-time applications (by virtue of not having mandated flow control and retransmission, and so avoiding potential latency). UDP can be used to transport other protocols. For example, UDP datagrams are used to transmit messages in the Domain Name System (DNS) protocol. UDP datagrams are also used to carry Real Time Protocol (RTP) messages, which are typically used for real-time applications such as real-time media streaming and video conferencing.

One consequence of the connectionless nature of UDP is that it does not, in itself, provide support for sessions. It does not specify a mechanism for signalling when a UDP transmission begins (other than by transmitting the first UDP datagram) and/or for when a UDP transmission ends (unlike TCP, which specifies the FIN message). It also does not, by itself, provide mechanisms to address packet loss (since, as mentioned, it does not guarantee the delivery of packets).

There are two versions of NATs, both of which are relevant to the Patent but, for present purposes, I shall only deal with the fuller version of NAT that existed at the priority date, namely NAPT (‘Network Address and Port Translation’), however, for convenience I shall refer to them as NATs.

The point of NAT was to deal with the proliferation of computers and other devices connecting with the Internet. The Internet Protocol in use at the priority date (and the one primarily still used today), IPv4, has a finite number of possible IP addresses. IPv6 had addressed this problem by extending the IP address from 32 bits to 128 bits, and hence increasing the number of addresses available, but it had yet to be implemented and there was an ever-increasing demand for IPv4 addresses. If every separate device accessing the Internet did so from its own dedicated and unique IP address (as originally conceived), the number of possible addresses would eventually be used up. This is believed to have happened in 2011.

NAT solves the IPv4 addressing problem by permitting devices within a private network (such as at a single company) to have private addresses known only within the network, and which may be the same as internal addresses of other networks (the most common private address range is 192.168.x.x). Devices on a private network access the public network (i.e. the Internet) through a NAT device (now usually incorporated into the network router), which maps the private internal address of the device sending the message (and its port number) into an external public address (and port number). It stores the mapping so that when a responsive packet of data is received, addressed to that external address and port number, it can forward it to the right device. The use of port numbers in the mapping process means that the NAT can operate using even a single public IP address to support hundreds of private IP addresses. The way this is done is illustrated in the figure below, which shows how a mapping table in the NAT is used to allow a device with a private Internet address to send messages to/from public devices on the Internet:

Whilst solving the IP address shortages in IPv4, the introduction of NAT brought with it other problems. For the first time, the fundamental principle of the Internet, whereby each device had a unique identification and could therefore be contacted by any other device, was now broken.

The mapping table is maintained in the NAT device so as to enable the device to route messages to and from the individual nodes of the private network. The Patent explains that after a certain period of inactivity, the mapping will no longer be maintained to avoid the internal memory of the NAT being filled with mapping data that is no longer required. If no data is sent during a set period of time (the timeout period), the NAT mapping will time out. This will cause problems where there is an application still running although it has not sent any data within the timeout period. This is the problem addressed by the invention the subject of the Patent. It is a problem that will occur most often with UDP but may also occur with TCP.

As I have already said, the Patent is a divisional and the specification is primarily concerned with the invention the subject of the parent patent addressing the problems with ensuring that the ‘IPsec’ protocol suite could be used reliably and securely through a NAT node. The invention, the subject of the Patent, is described in three paragraphs of the specification:

The claims are in two sets. Claims 1-7 are method claims and claims 8-14 are device claims, generally mirroring the features of the method claims. The evidence tends to address the claims as matched pairs. The pairs that are in issue are claims 1/8, 3/10, 5/12, 6/13 and 7/14. The key claims (alleged by SSH to be both independently valid and infringed) are claims 1/8 and 6/13.

Claim 1 is to:

Claim 6 is to:

There are two significant issues on construction:

It is common ground that the phrase ‘keepalive packet’ or simply the word ‘keepalive’ is not a term of art with an established meaning.

The word thus needs to be construed in its technical context and with its technical purpose as described in the Patent in mind. The Patent distinguishes between a ‘keepalive packet’ and the ‘actual data packets’. The purpose of the keepalive packets is to ensure that the timeout of the NAT is not reached so as to lose the address and port mapping which it has determined for the connection in question. It is the IP address and port mapping at the NAT that is ‘kept alive’. SSH submits that the proper construction is a repeatedly transmitted packet, not required to be repeatedly transmitted as part of the ordinary operation of the application in which it is used, save for the purpose of maintaining the IP address and port mapping at the NAT. Sony argue for a narrower construction, namely, a packet which does not include meaningful data. Sony’s definition excludes the re-sending of some previous data or the sending of some non-urgent data that would not otherwise be sent. I cannot accept such a narrow definition as suggested by Sony in the light of paragraph 41 of the Patent which states that “keepalive packets do not need to contain any meaningful information other than the necessary headers”. The corollary of that is that they may contain meaningful information. I accept SSH’s definition.

As for ‘determining a shortest period for the time out’, this arises in the context of a non-infringement argument on claim 6 and will be addressed again in that context. The purpose of this feature is to ensure that the device adopts a repetition rate for the keepalive packets that prevents the time out being triggered at any NAT. SSH submits that any way of arriving at a periodicity that is known to be shorter than a shortest timeout period will satisfy this requirement. Thus, it is not necessary for the device to ‘know’ the actual periodicity of a time out, provided that it has been established that the periodicity is ‘greater than X’, so that anything less than X can be used as the periodicity of the keepalives. Sony say that it means “exactly what it says on the tin”. The claim requires the time out period to be determined. This, it says, is done by the application programmer before they write the software to implement this method. Sony goes on to say that if the claim requires the system to determine the period in some way, the patent is insufficient in that it would not be known how to achieve this.

However, this depends on the accuracy with which the period must be determined. Sony is probably right if the period must be accurately determined but I believe that SSH is right that, on a purposive construction, it is not necessary for an accurate determination of the time out period for the invention to be implemented. The purpose of the determination is for the periodicity of the time out packets to be such that they will keep the mapping alive. This can be done by making a rough determination by sending keepalives of varying periodicity until the object has been achieved, thus determining a period that is shorter than the timeout period. Thus the determining can be done either by the programmer in advance or by the system using trial and error. It is not important for the determination to be more than an approximation.

There are 3 sets of conditional amendments, each of which includes the conditional amendments within the preceding set. The Comptroller has been notified and has responded, making no comments and indicating he does not wish to be represented. Sony contends that the amendments do not cure invalidity.

The first set limits the claims to methods of communication of data under UDP and devices for communicating data under UDP. This corresponds with the specific embodiment that is described in the Patent.

Save for their general objection of invalidity, the only specific point taken on this amendment by Sony is that the amended claim states that the keepalive packet ‘comprises’ a UDP datagram, which it says would cover a packet which included some data sent using UDP and some data sent using a different protocol. They say that the use of two different protocols in the same keepalive packet was not previously disclosed.

I agree with SSH that the amended claim does not ‘disclose’ such a keepalive any more or less than it was disclosed before (i.e. not at all). This is the confusion between ‘disclosure’ and ‘coverage’ dismissed by the Courts in AC Edwards v Acme [1992] RPC 391 and AP Racing v Alcon Components [2014] EWCA Civ 40 amongst other cases.

The second set of claims is the same as the first save that it introduces into claim 3 the requirement that the keepalive packet does not contain any ‘meaningful information’ save that the header should be the same as that used for transmitting data. There is no separate objection to this claim set.

The third set of claims is the same as the second save that it adds to claim 6 the requirement that ‘multiple keepalive packets are sent through the network address translator within a 30 second period’ (and the equivalent amendment to claim 13).

There is a separate objection to the third set of claims. Sony say that although the specification teaches (i) that multiple keepalives must be sent within the estimated shortest period in which “the NATs may forget the mapping” ([0040] lines 27-28); and (ii) that NATs may time out mappings ‘even as fast as in 30 seconds’ ([0039] lines 19-20), there is no teaching that more than one keepalive should be sent within a 30 second period. SSH submit that this is an entirely unrealistic submission. The disclosure of the specification includes what the skilled person would implicitly understand. SSH says that the skilled person would derive from the teaching in the specification as filed that the invention could be implemented by sending more than one keepalive within a 30 second period. I agree.

There is also an objection of lack of clarity in the case of the third set of claims. Sony say that “on one reading of the claim, all that is required by the method is that multiple keepalive packets are sent through the NAT within a 30 second period”. SSH says the claim is clear – the 30 second period is a further condition added to what is already in the claim. The keepalives must be sent frequently enough to maintain the determined translation, but at least two every 30 seconds. I agree.

The Patent is alleged to be invalid for obviousness over the common general knowledge per se, and over two prior art documents which, it is accepted for the purposes of this action, can be read together.

In assessing the obviousness I shall apply the well known Pozzoliquestions adapted by Jacob LJ from the Windsurfer Questions in Pozzoli v BDMO [2007] EWCA Civ 588:

“In the result I would restate the Windsurfing questions thus:

(1)

(a)

Identify the notional "person skilled in the art"

(b)

Identify the relevant common general knowledge of that person;

(2)

Identify the inventive concept of the claim in question or if that cannot readily be done, construe it;

(3)

Identify what, if any, differences exist between the matter cited as forming part of the "state of the art" and the inventive concept of the claim or the claim as construed;

(4)

Viewed without any knowledge of the alleged invention as claimed, do those differences constitute steps which would have been obvious to the person skilled in the art or do they require any degree of invention?”

I referred earlier to an unsatisfactory aspect of Mr Holdrege’s evidence. An example of this arose in respect of whether NAT and NAPT were part of the CGK. In his report Mr Holdrege had stated: “the functionality of network address translation (and, in particular, network address port translation) and the issues and solutions arising out of the use of NATs were still being understood, identified and resolved by experts”. He then stated: “I have asked Gowling WLG to conduct a search using the Google ‘Books’ search tool, to try to identify the earliest references to “Network Address Translation”, “NAT”, “Network Address Port Translation” and “NAPT”. He produced a chronological list of the references as an exhibit to his report. This showed a number of publications referring to “Network Address Translation” or “NAT” from 1996 but the earliest reference to “Network Address Port Translation” or “NAPT” as being in a publication in 2000.

Mr Holdrege was cross-examined on the documents in the list, particularly documents pre-2000 which were said to refer to NAT but not to NAPT. It was clear that several of these publications, pre-2000, did refer to NAPT, contrary to the indication in his exhibit. Mr Holdrege was reluctant to accept that these references did not support his evidence.

In respect of the attack based on common general knowledge alone, Sony identified four propositions that they say are common general knowledge and that underlie the attack, namely:

Proposition i) is accepted as common general knowledge by SSH. Mr Holdrege accepted this during cross-examination:

Indeed SSH say that this is all that you would expect the average skilled person to know about NATs at the priority date. SSH rely on Mr Holdrege’s repeated assertions to this effect. For example:

Thus, in respect of proposition ii), SSH does not accept this to be part of the common general knowledge of the relevant skilled addressee. Professor Leslie gave evidence that the skilled person would know that NATs used timeouts to clear mappings. In the case of UDP connections the timeout would be the principal method of terminating a mapping but, even with a TCP connection, there would be a longstop timeout in case a session had not been properly closed down.

In his expert report, Mr Holdrege said that the timer function was not part of the CGK because there were no text books or RFCs to explain the NAT timer function. Various publications were put to Mr Holdrege which referred to sessions being terminated after a period of inactivity. He rejected these publications as not being the sort of publications that the skilled person would have looked at. For instance, the textbook “Designing Addressing Architectures for Routing and Switching”, Berkowitz, (1999) he said was “targeted towards LAN managers and people who are interested in LAN management. I do not believe out of the thousands of books and IT communication that existed at the time this would have drawn the attention of an application designer because they would have been more focussed on application development books.”

SSH submit that this is information which might be capable of being found if the skilled person embarked on a search to find it but that does not mean that it is part of the CGK. SSH relies on the judgment of Kitchen J in Generics v Daichi which was approved by the Court of Appeal at [2009] RPC 23 at 25. I set out below a longer passage from the judgment of the Court of Appeal:

On the basis of Mr Holdrege’s evidence, I do not believe that Sony have established that the documents relied on to establish knowledge of NAT timeout are the type of documents that the relevant skilled person would have referred to as a matter of course. Sony counterED by submitting that the skilled person would certainly find the documents if doing basic research on NATs. This will depend on the task that the skilled person is undertaking. I shall deal with this when I come to the fourth proposition alleged by Sony to form part of the CGK.

So far as the third proposition is concerned, SSH point to the fact that “keepalive” is not a term of art. Professor Leslie produced a series of documents (said by SSH to have been carefully selected by Sony’s solicitors) from before the priority date, which showed the use of “keepalives”. It was said against Professor Leslie that these documents were, on the whole, not part of the CGK. Professor Leslie accepted that. His point was that the documents indicated that people in the art were using keepalives in a range of applications, indicating that the use of keepalives was CGK even though the documents themselves were not part of the CGK. I believe that to be a valid point. The documents do show that the use of keepalives of the kind shown in the documents were in general use and formed part of the CGK.

A more telling point made by SSH is that all the keepalives referred to in Professor Leslie’s report fell into one of two categories: (i) ‘Hello’ messages sent from one end point in a network to another end point saying ‘I am alive’; and, (ii) ‘probe’ messages asking for an acknowledgment that the other end point was still alive. SSH say that they are all conveying information from one node in a network to another, at the application layer, and, insofar as they are keeping anything alive, it is a resource within the receiving end node. They rely on the following passage of the cross-examination of Professor Leslie:

Professor Leslie went on to say:

I do not think that this a high enough level of certainty to establish that the skilled addressee would regard the keepalives in the CGK in their particular context as being of the same character as the keepalives of the Patent.

So far as the fourth proposition is concerned, SSH have a number of criticisms to make. The fundamental criticism that they make is that it starts with “such applications” and nowhere is an example of such an application given. The evidence established that the UDP protocol was particularly useful for ‘real time’ applications, but no evidence was given about any real time application being used at the priority date. Sony’s evidence was that, at the priority date, there was “a flood of interest in the delivery of multimedia services” and that “the number of (such) applications is increasing”. However, this fallS short of identifying any such application in which the problem of a time out occurring would arise, or had arisen.

This is important for two related reasons: (i) it does not provide a starting point for the assessment of obviousness; and, (ii) without the starting point there is no way of assessing whether the skilled person would be given any incentive to locate the information under proposition two above which, while not being in the CGK, would be attainable by the skilled person given a reason to look for it.

The lack of a starting point for the assessment of obviousness is a particular problem with obviousness over the CGK. See the well-known warning of Floyd LJ in Ratiopharm v Napp [2009] RPC 11 AT 158:

…allegations of obviousness in the light of common general knowledge alone need to be treated with a certain amount of care. They can be favoured by parties attacking the patent because the starting point is not obviously encumbered with inconvenient details of the kind found in documentary disclosures, such as misleading directions or distracting context. It is vitally important to make sure that the whole picture presented by the common general knowledge is considered, and not a partial one.

Once a starting point is identified, questions can properly be asked about how the invention could have been arrived at, taking into account the specifics of that starting point and whether it suggested the invention or even lent itself to the invention. This enables the kind of investigation summarised by Kitchin J in Generics v Lundbeck [2007] RPC 32 at 74 (approved by the House of Lords in Conor v Angiotech [2008] UKHL 49) to be undertaken:

The question of obviousness must be considered on the facts of each case. The court must consider the weight to be attached to any particular factor in the light of all the relevant circumstances. These may include such matters as the motive to find a solution to the problem the patent addresses, the number and extent of the possible avenues of research, the effort involved in pursuing them and the expectation of success.

Without any idea of the application that existed at the priority date that is said to be a starting point for making the invention, one cannot properly consider ‘motive’, ‘number of alternative approaches’ or the kinds of problems that might have been caused by seeking to apply the invention. It is not possible to apply the Pozzoli questions, particularly the third question which involves identifying the difference between the prior art and the invention of the Patent, without first identifying a starting point. I accept that the Pozzoli approach may not be suitable for all cases but, in this case, the fact that there is no identifiable starting point is indicative of a fatal flaw in the attack based solely on CGK.

Originally Sony pleaded six items of prior art but they have limited themselves to two. The first of these is a document entitled “nat-minutes-98dec.txt” which is the minutes of the meeting of the 43^rd IETF NAT Working Group in Orlando, Florida, of 9 December 1998 (“the Minutes”). They do not rely on any publication in the context of the meeting itself. I note that SSH’s expert, Mr Holdrege, was present and was one of the chairs of this meeting but he does not claim to have any particular memory of the details of the meeting and so is not in a special position as far as construing the disclosure of the document is concerned.

The Minutes appear to have been published as a .txt document on the website of the IETF.

The document sets out the Agenda of the meeting on page 2. This comprises a numbered list of items, the first of which is ‘NAT Friendly Application Design Guidelines’ by Daniel Senie. The legend on page 1 indicates that this was the title of the ‘Presentation/Discussion Topic’ at the meeting. Underneath it says ‘<draft-ietf-nat-app-guide-00.txt>’. From the legend, this falls into the category of ‘any other remarks by minutes taker or editors’. The Minutes contain notes relating to the presentation under various headings with the final one being a note of “Questions from the Audience”.

The second item of prior art relied upon by Sony is a document prepared by Daniel Senie under the title ‘NAT Friendly Application Design Guidelines’ (“the Guidelines”). This is a copy of the paper presented at the meeting, the subject of the Minutes referred to above. It describes itself as an ‘Internet-Draft’, which is a ‘working document of the Internet Engineering Taskforce (IETF)’. It is said to be ‘inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”’. I do not think that this makes any difference to the approach to be taken to this document and any disclosure therein.

It is accepted that, for the purposes of this action the Guidelines and the Minutes can be read together since the Guidelines are cross-referenced in the Minutes and a person seeking to understand the Minutes of Mr Senie’s part of the meeting would be likely to consult the document which Mr Senie appears to have been presenting or summarising at the meeting.

Sony puts its case in two ways. It says that:

The Guidelines are specifically addressed to authors of new protocols:

In paragraph 2 it discusses the proliferation of NATs and the problems of passing addressing data between stations. It also refers to the two forms of NATs which it calls basic NAT and NAPT. It goes on to state:

Paragraph 3.5 is headed “TCP preferred over UDP” and states:

The relevant entry in the Minutes is:

Sony say that this is a clear disclosure that NATs use timers for UDP mappings and may time out a UDP session if the application does not send data for a long period of time. They say that if that is a problem, then to state the problem is to state the solution: do not allow a long period of time to go by without sending data.

Sony rely on the cross-examination of Mr Holdrege where he was asked to assume that the skilled person either knows or would find out that UDP transmissions through a NAT device may time out:

Although Sony consider the Q&A separately, SSH consider it together with the rest of the Minutes and the Guidelines. I believe that this is a more sensible approach since the Q&A is a part of the Minutes. It is artificial to seek to separate the Q&A from the context of the Minutes. The relevant part of the Q&A is:

SSH points to other parts of the guidelines, in particular the following:

Mr Holdrege thought that the effect of this was that what was being suggested in the Guidelines and in the Minutes was the use of an HTTP “keepalive”. He thought that Mr Senie was speculating about how a client and server could communicate over a UDP connection in such a way that a single ‘session’ could be indicated, maintained and managed. By suggesting the same approach as was taken in HTTP 1.0 with its ‘Keep-Alive’ tokens, Mr Senie was indicating that parties to a UDP connection would be able to tell each other that they were commencing a ‘session’ which would be kept open long enough for a fixed number of bits to be sent. The receiving server would recognise both the start of a ‘session’ and its end. There would be no chance of either party thereafter seeking to transmit over the same connection, perhaps after the translation had been torn down by the NAT. This would be a primitive form of ‘session management’ in UDP. Mr Holdrege explained that the use of something like an HTTP ‘keepalive’ in this sense was a way of maintaining a persistent connection, and therefore would solve the problem of maintaining, mapping and session management.

I prefer Professor Leslie’s understanding of the Guidelines and Minutes. There can be no doubt that the documents disclose the fact that NATs use timeouts to clear their memory of unused mappings and that this can cause problems with UDP connections. I accept Professor Leslie’s evidence that the skilled person reading the documents would understand the relevant Q&A to indicate that the problem could be cured by the use of keepalives and that, although that is not a term of art, they would understand the concept of a keepalive to be the sending of a packet at intervals sufficiently short to prevent the timeout affecting the connection. As SSH argued in relation to Professor Leslie’s collection of documents referring to the use of keepalives, the term is descriptive. I accept Sony’s submission that one only has to state the problem of timeouts to state the solution, particularly when the word keepalive is used as the suggested solution.

The explanation put forward by Mr Holdrege is complicated and would require the use of an HTTP Keep-Alive to be CGK, as to which there is no evidence. Furthermore, Mr Holdrege states in his second report, in referring to the HTTP ‘solution’:

“This, of course, does not pose an obvious solution to the question of renewing the timeout of the network address translation. This is because not all applications know the amount of data which they are sending and, in any event, as the signaling is at the application layer, the NAT would not be able to read it.”

It was put to Professor Leslie that the use of a keepalive, in the sense that he suggested and as claimed in the Patent, would be a complete solution to the problem whereas the Q&A is recorded as saying that it would make this “less of a problem”. I do not believe that one can read too much into this. To make the keepalive system work, one has to make the keepalives sufficiently frequent to beat the timeout in a particular NAT device. One solution may not fit all, in that different devices may have different timeout periods, so that some work will be required to establish the optimum for any given system. I do not accept that the use of “less” will deter the skilled person from thinking that this is referring to a timeout of the type claimed in the Patent.

Mr Holdrege also suggested that the subsequent comment about SOCKS in the Q&A teaches away from the construction put on the answer to the previous question by Professor Leslie. I do not accept that to be the case. I prefer Professor Leslie’s explanation that there may be a similar problem with Socks since, although the connection is set up over TCP it opens a UDP connection which may be timed out.

On the basis of Professor Leslie’s evidence as to the meaning of the Minutes and the Guidelines, as they would be understood by the skilled person, I find that Claims 1 and 2 are anticipated by the disclosure which clearly teaches the use of keepalive packets to maintain a NAT mapping for the communication of datagrams by sending a keepalive packet before a timeout of the mapping by the NAT device.

If I am wrong about the teaching being clear then applying the Pozzoli questions, I have already identified the person skilled in the art and the CGK. The inventive concept of claims 1 and 2 is the use of keepalive packets, sent between two devices communicating with each other through a NAT device, to maintain the mapping in the NAT device, by sending at least on keepalive packet before a timeout of the mapping.

The difference, if any, between the prior art Minutes and Guidelines and the inventive concept is that the prior art arguably does not specify that the keepalive packets must be sent between the two communicating devices and that they must be sent sufficiently frequently that the timeout does not remove the mapping prematurely.

On the evidence, these differences would be obvious steps to the skilled addressee who would have no difficulty in implementing the teaching of the prior art and, in doing so, would achieve a method within claims 1 and 2 (and so claims 8 and 9) of the Patent.

SSH claims independent validity in respect of claims 3, 5, 6, 7 (all being method claims) and their equivalent device claims, 10, 12, 13 and 14.

Claim 3 requires that at least one keepalive packet comprises a header that equals with the headers of the datagrams. The significance of this, they say, is that the packet is addressed to the same end point and in the same way as the ordinary data being sent over the connection. This is not disclosed in the Minutes or Guidelines. Professor Leslie gave evidence in his first report that keepalives are sent on the communication path of a normal message. This was accepted by Mr Holdrege in cross examination when he explained that a packet sent to server A would have no effect on the NAT mappings of server B. It is clear that the skilled addressee would know that the keepalive would have to go through the NAT device and not be directed to the NAT device. Thus, to be effective it would have to comprise a header that equals with the headers of the datagrams. In answer to the fourth question of Pozzoli, that would be obvious to the skilled addressee. Claim 3 is obvious.

Claim 5 requires that a packet is interpreted as a keepalive packet if it does not contain any meaningful payload. SSH suggest that this requires an understanding about speciality keepalive messages which has not been shown to be part of the CGK. Professor Leslie’s evidence was that this would be obvious from the very nature of a keepalive and I accept this. Again, applying Pozzoli, claim 5 is obvious.

Claim 6 requires that the method comprises determining a shortest period for the time out and, based on the determination, sending the at least one keepalive packet frequently enough to maintain the determined address translation in the NAT. This is the very essence of a keepalive and would be obvious to the skilled addressee. Again, applying Pozzoli, claim 6 is obvious.

Claim 7 requires the method to comprise taking the possibility of packet loss into account in determining the frequency of sending the at least one keepalive packet. Mr Holdrege accepted that if one was sending keepalives one would send more than one per timeout period to account for the risk of packet loss. Again, applying Pozzoli, claim 7 is obvious.

The product claims all mirror the method claims with the exception of claim 13, which is equivalent to claim 6 except that it does not require any determination of the shortest period of a timeout. The product claims are all obvious for the same reasons as the equivalent method claims.

The first set of conditional amendments restrict the claims to UDP and NAPT. These amendments do not cure the invalidity of the claims and are not allowed.

The second set of conditional amendments include the amendments of the first set but also excludes keepalive packets sent direct to the NAT from claim 3. Again, this does not cure the invalidity and is not allowed.

The third set of condition amendments adds the further requirement to claims 6 and 7 that multiple keepalive packets are sent within a 30 second period. This does not cure the invalidity of the claims and is not allowed.

Sony raise four grounds of insufficiency. These were effectively squeeze arguments and, in the light of my findings above and the construction I have put on the claims, it is not necessary for me to deal with them.

This objection was not pursued by Sony.

Although I have found all the claims of the Patent to be invalid, in case I am wrong, I shall deal with the question of infringement.

SSH alleges that Sony’s Xperia devices use the method of claims 1, 3 and 6 (and are therefore devices with claims 8, 10 and 13) as granted and in the first conditional amendment, and claims 1 and 6 (and are devices within claims 8 and 13) in respect of the second and third conditional amendments. The method claims are alleged to be infringed by the Xperia devices when performing SIP Internet Calling. This is an implementation of the SIP protocol, which is an Internet standard.

To make and receive Internet Calls, a user must first form a connection (a “registration”) with a SIP Server.

Figure 2 of the PPD provides an overview of Internet Calling:

This shows two users (assumed to be using Xperia devices) conversing by Internet Calling. Internet Calling involves two channels of communication:

The control messages sent on the control channel are called SIP messages. Each SIP message is contained in a UDP datagram.

One of these SIP messages is the SIP OPTIONS message. This message queries the server as to its capabilities, and the server is required to respond with a list. The Xperia devices send SIP OPTIONS to the SIP Server on two schedules:

In each case, the Xperia device expects to receive the usual response to a SIP OPTIONS message specified in the SIP protocol:

The first issue is whether the SIP OPTIONS messages are keepalives. SSH submit that they are. They saythat there is no doubt that the Xperia devices have been deliberately designed to ensure that keepalive packets are sent to maintain the mapping at the NAT behind which the device is situated. The user interface for SIP Internet calling includes the optional ability to set ‘keep-alives’ as ‘automatic’ or ‘always send’. When the device is registered with the SIP provider, an ‘AutoRegistrationProcess’ commences, linking the device with the SIP server and the relevant SIP account. The PPD explains that the AutoRegistrationProcess causes the ‘KeepAliveProcess’ to be initiated in one of two situations:

The significance of (ii) is that the device always uses the ‘KeepAliveProcess’ if it is behind a NAT – which it establishes by working out whether it has one of the specially reserved IPv4 ‘private’ IP addresses.

The keepalive mechanism used by the Xperia devices is repeatedly to send additional SIP OPTIONS messages to the SIP server. The requested information is not actually needed by the Xperia device and is not used. Provided that such repeated messages are sent more frequently than the timeout of the NAT, this will ensure that the address and port mapping of the device in relation to the connection to the SIP server is kept constant in any NAT between the Xperia device and the SIP server.

The Xperia device establishes the periodicity with which the keepalives need to be sent by using the processes referred to as ‘startPortMappingLifetimeMeasurement’ and ‘IntervalMeasurementProcess'.

The process commences by establishing that the Xperia device is behind a NAT. It then operates an algorithm on a control channel to work out a shortest periodicity that does not cause the SIP server to respond with a different port number. In summary, it starts by trying a period of 65 seconds. If that is unsuccessful (i.e. the port number changes), then a period of 37.5 seconds is tried, then 23.75 etc., gradually reducing to a minimum of 10 unless a stage is reached where the port numbers do not change. At that point, the interval is repeatedly used, and, if it succeeds 10 times running, it is adopted to keep the control channel alive. During a call, in addition to sending SIP OPTIONS messages according to the established periodicity, they are also sent every 10 seconds.

SIP OPTIONS is a message which forms part of the SIP Protocol defined by RFC 3261, and which can therefore be guaranteed to be understood by any SIP server. As Mr Holdrege says in his First Report, an initial SIP OPTIONS message has the function of interrogating the capability of the SIP server. However, there is no purpose at all in doing so more than once. Indeed, with respect to the dynamic SIP OPTIONS, the Xperia device will only request the information if it ‘isBehindNAT’ or if the detection is overridden using the ‘always send’ option and does not use the returned information. The SIP OPTIONS messages are therefore sent solely for the purpose of renewing the time out of the NAT. This is of course why they are referred to as ‘keepalives’ in the Xperia devices’ user interface. This seems to be common ground between the parties, since Professor Leslie does not take issue with Mr Holdrege’s evidence on this point in his Reply Report, rather agreeing that “SIP OPTIONS described in RFCs 2543 and 3261 (which describe SIP) were not designated as having a keepalive function. However, in Android they have been repurposed to provide keepalive functionality.”

I think it is clear that the SIP OPTIONS messages are keepalives within the meaning of the claim. If I am wrong as to the correct construction to be put on the term keepalive in the claim, nevertheless, on a purposive construction of the claim the SIP OPTIONS are keepalives within the narrower construction put forward by Sony. Their sole purpose is to perform the function of a keepalive.

If the SIP OPTIONS are keepalives, then claims 1, 3, 8 and 10 are infringed by the Xperia devices.

So far as the other claims are concerned, the issues on infringement are as follows:

The point here turns on the construction of “determining a shortest period for the timeout”. The Xperia device determines a transmission period, iteratively, starting with a period of 65 seconds, gradually reducing it by stepping down in increasingly shorter periods until a period is reached which prevents the time out. It is Sony’s case that this does not infringe the claim because the actual period of the timeout is never actually determined. Again, on the construction of this term, I have decided that it does not require an accurate determination of the period to be made. If the actual period can be discovered, for instance by seeing the period that has been programmed into the NAT device, then that is clearly determining the period of the timeout. However, an approximate determination would also be a determination within the meaning of the term in the claim. There is nothing in the Patent to dictate the accuracy to be achieved. Provided that it is determined to be greater than the figure adopted, that will satisfy the claim. Claim 6 is infringed.

Claim 13 does not require the determination of a shortest period for the timeout. Claim 13 is infringed.

I find that all the claims of the Patent are invalid. The Sony Xperia devices would infringe claims 1, 3, 6, 8, 10 and 13 if they were valid in their unamended form and in their proposed amended forms were they to be allowed.