|[Home] [Databases] [World Law] [Multidatabase Search] [Help] [Feedback]|
England and Wales High Court (Patents Court) Decisions
You are here: BAILII >> Databases >> England and Wales High Court (Patents Court) Decisions >> Sony Communications International AB v SSH Communications Security Corporation  EWHC 2584 (Pat) (10 October 2016)
Cite as:  EWHC 2584 (Pat)
[New search] [Context] [View without highlighting] [Printable RTF version] [Help]
Strand, London, WC2A 2LL
B e f o r e :
SITTING AS A DEPUTY HIGH COURT JUDGE
| SONY COMMUNICATIONS INTERNATIONAL AB
|- and -
|SSH COMMUNICATIONS SECURITY CORPORATION
Iain Purvis QC and Brian Nicholson (instructed by Gowling WLG (UK) LLP) for the Defendant and Part 20 Claimant
Hearing dates: 1st, 4th, 6th and 7th July 2016
Crown Copyright ©
Mr Roger Wyand QC :
Introduction and background
The skilled addressee or team
The expert witnesses
The technical background
 Next we will address the "keepalive" aspect of the invention, i.e. ensuring that the network address translations performed in the network do not change after the translations that occur have been determined. Network address translators cache the information about address mapping, so that they can reverse the mapping for reply packets. If TCP is used, the address translator may look at the FIN bit of the TCP header to determine when it can drop a particular mapping. For UDP, however, there is no explicit termination indication for flows. For this reason, many NATs will time out mappings for UDP quite fast (even as fast as in 30 seconds). Thus, it becomes necessary to force the mapping to be maintained.
 A possible way of ensuring the maintaining of mappings is to send keepalive packets frequently enough that the address translation remains in the cache. When computing the required frequency, one must take into account that packets may be lost in the network, and thus multiple keepalives must be sent within the estimated shortest period in which NATs may forget the mapping. The appropriate frequency depends on both the period the mappings are kept cached and on the packet loss probability of the network; optimal frequency values for various context may be found through experimenting.
 Keepalive packets do not need to contain any meaningful information other than the necessary headers that are equal to the data packet headers to ensure that the keepalive packets will be handled exactly in the same way as the actual data packets. A keepalive packet may contain an indicator that identifies it as a keepalive packet and not a data packet; however it may also be determined that all packets that do not contain meaningful payload information are interpreted to be keepalive packets. In Fig. 3 the transmission of keepalive packets is schematically illustrated by block 306 and the reception and discarding of them is schematically illustrated by block 307. It should be noted that the use of keepalive packets is not needed at all if actual data packets are transmitted frequently enough and/or the connection is to remain valid only for such a short time (e.g. a few seconds) that it is improbable that any intermediate device would delete the mapping information from its cache. Keepalive packets need to be transmitted in one direction only, although they may be transmitted also bidirectionally; the drawback resulting from their bidirectional transmission is the resulting increase in unnecessary network traffic. The invention does not limit the direction(s) in which keepalive packets (if any) are transmitted.
A method of maintaining communication of datagrams in a communication system where address translation is provided by a network address translator (305) for communication of datagrams between a first device and a second device, characterised by maintaining a determined network address translation for communication of datagrams between the first device and the second device by sending (306) from the first device or the second device at least one keepalive packet before a time out of the determined network address translation.
A method according to claim 1 or any claim dependent on claim 1, comprising 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 network address translator (305).
i) What is meant by 'a keepalive packet'?
ii) What is meant by 'determining a shortest period for the time out' in claim 6?
Common general knowledge
"In the result I would restate the Windsurfing questions thus:
(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) NATs track associations between packets and store information to allow them to translate outgoing packets and reverse that translation for incoming (reply) packets – in other words, NATs cache information about address mappings;
ii) Such mappings were typically dynamic, and would be removed by the NAT if not refreshed by the translation of a packet – in other words, the mappings had a timeout;
iii) Keepalives provide periodic traffic and are frequently sent to refresh timers; and
iv) Such applications would require the consistent use of one IP address and port number in order to operate without error.
8 A. As we defined the skilled addressee, we defined someone who,
9 as you say, would be interested in dealing with NATs whereas
10 what I am saying is that a general application designer, in
11 1999, was not, I believe.
12 Q. But the person you were talking about in your reports, they
13 would know about NATs?
14 A. Yes.
15 Q. And they would know that whatever happened with IPv6, who was
16 right about that, they cannot worry about that. They have to
17 worry about NATs now.
18 A. Right. If they realised that NATs existed and they realised
19 that they were important for the future, then they would have
20 to address it.
21 Q. Yes. I did not quite understand, "If they realised that they
22 were important to the future, then they would have to address
23 it." Whatever their thoughts were on the future, they would
24 have to address it.
25 A. I apologise, yes.
Q. We see that said in the book, if we go back to the second
- option. Port NAT accommodates many to one mapping. Indeed,
- it says it is the only option for PPP connections that
- provides a single valid internet IP address. So, this book
- that you came up with from your search from talking about PPP
- in March 1999 would not support your recollection that a
- skilled person would not know about port NAT and how it
- worked, would it?
- A. To repeat what I said before, if all you are concerned about
- is making the protocol work through a NAT, then you do not
- need to know about port NAT. Port NAT does not require any
- outside help from the protocol. I should be more specific to
- say that. It is all internal to the NAT. As we develop
- protocols and as we use protocols that pass through a NAT, we
- do not need to know or care that port NAT exists; we only know
- that the IP address is changed. So, as an architect, we can
- look and that, yes, port NAT is necessary for the one to many,
- but as an application developer, there is no difference we
- make in the application to account for port NAT. It does not
- mean anything to us. So, again it is the group of people we
- are talking about, that no one cared about it, they said that
- the general public or general application designers do not
- need to know or care anything about port NAT given the set of
- applications of the era.
24 Mr Tappin raised what he said was a point of law about the extent of knowledge of a person skilled in the art. He relied on what Laddie J. said in Raychem Corporation's Patent  RPC 31 at 40, approved on appeal at  R.P.C. 497 at 503:
"The common general knowledge is the technical background to the notional man in the art against which the prior art must be considered. This is not limited to material he has memorised and has at the front of his mind. It includes all that material in the field he is working in which he knows exists, which he would refer to as a matter of course if he cannot remember it and which he understands is generally regarded as sufficiently reliable to use as a foundation for further work or to help understand the pleaded prior art. This does not mean that everything on the shelf which is capable of being referred to without difficulty is common general knowledge nor does it mean that every word in a common text book is either. In the case of standard textbooks, it is likely that all or most of the main text will be common general knowledge. In many cases common general knowledge will include or be reflected in readily available trade literature which a man in the art would be expected to have at his elbow and regard as basic reliable information. In this case, for example, the general technical discussion of conductive polymers in the Cabot technical report was common general knowledge well before the priority date. So too would be the general teaching in the leading articles and textbooks on the subject."
25 Of course material readily and widely to hand can be and may be part of the common general knowledge of the skilled person – stuff he is taken to know in his head and which he will bring to bear on reading or learning of a particular piece of prior art. But there will be other material readily to hand which he will not carry in his head but which he will know he can find if he needs to do so (my emphasis). The whole passage is about material which the skilled man would refer to "as a matter of course." It by no means follows that the material should be taken to be known to the skilled man if he has no particular reason for referring to it.
26 Kitchin J., having reviewed Raychem and other authorities, said this:
" It seems to me that a subtle but potentially significant point of principle emerges from these passages. I can readily accept that, faced with a disclosure which forms part of the state of the art, it may be obvious for the skilled person to seek to acquire further information before he embarks on the problem to which the patent provides a solution. But that does not make all such information part of the common general knowledge. The distinction is a fine one but it may be important. If information is part of the common general knowledge then it forms part of the stock of knowledge which will inform and guide the skilled person's approach to the problem from the outset. It may, for example, affect the steps it will be obvious for him to take, including the nature and extent of any literature search."
27 I agree with that although I personally do not find the point of principle "subtle". It would be wholly subversive of patents and quite unfair to inventors if one could simply say "piece of information A is in the standard literature, so is B (albeit in a different place or context), so an invention consisting of putting A and B together cannot be inventive." The skilled man reads each specific piece of prior art with his common general knowledge. If that makes the invention obvious, then it does. But he does not read a specific citation with another specific citation in mind, unless the first causes him to do so or both are part of the matter taken to be in his head.
28 So, for example, if a particular device depends upon expansion of a metal, say brass, and clearly the coefficient of expansion matters to its operation, one can legitimately say that the skilled person knows there are tables of coefficients of expansion and would go to them to see what other metals or alloys had similar coefficients and would therefore probably work. But not so if it was far from evident that the coefficient of expansion mattered.
- Q. No. The issue that the patent looks at has nothing to do with
- the two ends of the communication, but is concerned with a
- timer in an intervening communication gateway between the two
- ends; correct?
- A. Correct.
- Q. And that timer has been independently established for a reason
- unconnected with the purpose for which the end nodes are
- communicating with each other.
- A. I would agree with that.
- Q. It is right, is it not, that so far as the common general
- knowledge is concerned, you have not been able to identify a
- single instance of an application which sends keepalive
- messages for the purpose of defeating an intermediate timeout
- in such an intermediate node implemented for independent
- A. Not in the ones mentioned in paragraph 137.
- Q. Which are the common general knowledge citations that you have
- given us; right?
- A. That is correct.
- Q. What I am going to suggest to you is that if you had actually
- been the uninventive skilled person at the priority date,
- clothed solely with the common general knowledge, there is
- nothing in that common general knowledge which would point to
- the keepalive solution, as the patent, to deal with a timeout
- of an intermediate node of this kind?
- A. I think the way you have described it, in terms of separating
- them out, it is not something that someone faced with the
- problem would necessarily do. I think the notion that you are
- resetting a timer is common to them all. The distinction
- about where that timer is, whether that is a completely
- different thing or whether the non-inventive person would make
- a distinction between those two I think is pretty arguable.
…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.
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.
Invalidity over the NAT Minutes and Guidelines
i) The Patent is obvious over the Minutes and the Guidelines, ignoring the note of the Questions from the Audience ("the Q&A"). It relies particularly on the passage at paragraph 3.5 of the Guidelines which is also summarised in the Minutes.
ii) The Q&A expressly discloses the invention of the Patent as claimed in claims 1-3, 6, 8-10, 13 and 15.
Other documents which describe Network Address Translation (NAT)
discuss the Terminology and Considerations [Srisuresh1] and Protocol
Issues [Holdrege] or discuss the preceived implications of NAT [Hain]
[Rekhter]. All of those relate to various issues with the NAT
mechanism and its effects on protocols which already exist. It is the
focus of this document to instruct authors of new protocols what to
think about when designing new protocols such that special handling is not required at NAT gateway points.
Application designers should ensure compatability with NAPT, as this
form of NAT is the most widely deployed. This is also the form of NAT
which will likely see the greatest penetration in homes and small offices.
NAT implementations must track which sessions are alive, and flush
old sessions. TCP has clear advantages in this area, since there
are specific beginning and end of session indicators in the
packets (SYN and FIN packets). While UDP works for some types of
applications with NAT, there can be issues when that data is
infrequent. Since there is no clean way to know when an end
station has finished using a UDP session, NAT implementations use
timeouts to guess when a UDP session completes. If an application
doesn't send data for a long period of time, the NAT translation may time out.
o Operational Reliability
* TCP preferred over UDP since NAT can track TCP sessions more
easily and know when sessions end.
* UDP sessions are tracked by timeouts.
ALG's can overcome this problem, but we'd rather design applications to not need this processing.
- Q. Let us look at the middle point. We have spoken this morning
- about whether or not a skilled person would either know or
- would find out that NAT devices timed out, released mappings
- for UDP using timers?
- A. Yes.
- Q. I am not going to go over that. You are to assume that a
- skilled person either knows that or would find that out, so he
- knows that if he is sending, on the UDP transport layer,
- packets through a NAT device, it may time-out after a certain
- period of time; okay? Assume he knows that.
- A. Assuming he knows that there is a timeout, sure.
- Q. If he knows there is a timeout, in some applications, that is
- not going to matter because if it is a continuous stream, it
- will not timeout. If he is concerned, because maybe he has
- got intermittent data, then he knows, does he not, that a way
- of stopping that timeout is to send a packet through to
- prevent the timeout?
- A. Yes.
- Q. The packet does not require to have any actual payload data in
- it. The whole point is that you are sending it when you do
- not have them. If you had payload data, you would not have
- the problem.
- A. Understand the point that there are many mappings possible on
- a NAT device and they are organised by the source destination
- HOLDREGE - LYKIARDOPOULOS
- addressed in the destination address and the ports associated
- with them. So, if I am sending a packet to server A and then
- I send the packet to server B, they are going through
- different NAT mappings, and the packets sent to server B would
- have no effect on the mapping for server A.
- Q. Right, the skilled person knows that, does he not?
- A. Yes.
- Q. Obviously, it goes, I would have thought almost without
- saying, that he needs to send the packet faster or more
- frequently than the lowest, if you like, timeout?
- A. If he knows timeout is one minute, he has to send it before
- that time is up.
- Q. We will know that he has to make the header fields for the
- keepalives (or whatever you call them) the packets, the same
- as the actual data packets to ensure they are treated in the
- same way and do the job?
- A. As I was saying, server A and server B are uniquely
Questions from the Audience:
[Eliot Lear - UDP session management. UDP may make it more
difficult to maintain the mapping]
An application may maintain keep-alives to make this
less of a problem.
[Someone said there are similar issues with SOCKS, and these ideas can
be shared with NAT. Do we have any plan to make a
utility to verify the guidelines? ]
Multiple sessions can work, but are not as reliable, nor
as friendly as single sessions. An analyzer might be created to diagnose traffic in a non-NAT environment.
3.1 Avoid Session Bundles
Independent sessions, such as used by HTTP, are preferred to
protocols which attept to manage a bundle of related sessions,
such as FTP.
In the FTP protocol, port information is passed over one TCP
connection and is used to construct a second TCP connection for
passing the actual data. While using a separate connection to pass
the files being transferred makes determination of the end of data
quite simple, other schemes could be envisioned.
The HTTP protocol, for example, uses a header and content length
approach to passing data. In this model, all data is transferred
over the single TCP connection, with the header portion indicating
the length of the data to follow. HTTP has evolved to allow
multiple objects to be passed on a single connection (thereby
cutting the connection establishment overhead). Clearly a new file
transfer function could be built that would perform most of the
functions of FTP without the need for additional TCP connections.
It is clear that the lesson here is to keep to single connections
where possible. This keeps us from needing to pass addressing
information of any sort across the network. Since addressing
issues are limited to the establishment of the TCP session, standard NAT functionality is sufficient.
3.6. Single Sessions Preferred Over Multiple Sessions
Resource utilization on the NAT gateway should be considered. An
application which opens and closes many TCP connections, for
example, will use up more resources on the NAT router than a
similar application which performs all transfers over a single TCP
connection. HTTP 1.0 opened a connection for each object on a web
page, whereas HTTP 1.1 permits the TCP session to be held open for
additional objects which may need to be transferred. Clearly the
latter imposes a lower overhead on the NAT gateway, as it is only
maintaining state on a single connection instead of multiple connections.
"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."
Claims alleged to be independently valid
Proposed amended claims
i) The actual conversation (i.e. the data representing the sounds they each make) is carried on a data channel (the red line) via a VoIP server.
ii) The call is controlled by way of a control channel shown in blue. Each user exchanges control messages with their own service providers' SIP Server (marked "Server A" and "Server B"); and these two servers communicate with each other.
i) Dynamic SIP OPTIONS messages: Regardless of whether a call is in progress (e.g. when the phone is simply waiting to make or receive a call), SIP OPTIONS are sent at intervals which are dynamically adjusted.
ii) In-call SIP OPTIONS messages: When a call is in progress, a SIP OPTIONS message is sent every 10 seconds.
i) If it does not receive a response to a dynamic SIP OPTIONS message within 5 seconds, the Xperia device considers the connection lost and starts the process of re-registering with the SIP Server.
ii) If it does not receive a response to an in-call SIP OPTIONS message within 5 seconds, the Xperia device stops sending in-call SIP OPTIONS messages.
i) if the keepalive option has been chosen to be 'always send'; or
ii) the 'isBehindNAT' source code parameter is satisfied, whereby the IP address of the device is in the following IPv4 sub-networks:(i) 10.X.X.X;