UNeutral Citation Number: [2014] EWHC 3924 (Pat)
[HC 12 D 03895 (old case number)]
Royal Courts of Justice Strand, London, WC2A 2LL
Before :
MR JUSTICE BIRSS Between:
|
|
VRINGO INFRASTRUCTURE INC. - and - |
Claimant
|
ZTE (UK) LIMITED |
Defendant |
- - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
Henry Carr QC ,Tom Hinchliffe and Ben Longstaff (instructed by Powell Gilbert) for the Claimant
Daniel Alexander QC and Isabel Jamal (instructed by Olswang) for the Defendant
Hearing dates: 28th, 29th, 30th, 31st October, 3rd and 4th November 2014
- - - - - - - - - - - - - - - - - - - - -
Judgment
Mr Justice Birss:
Contents |
Paragraph |
Introduction and the issues |
1 |
The irrelevant prejudice |
4 |
The technical background |
7 |
The prior art, the relevant standards and the invention |
39 |
The witnesses |
57 |
The skilled person and the common general knowledge |
68 |
The patent specification |
71 |
Claim construction |
78 |
Novelty |
93 |
Obviousness |
105 |
Infringement |
148 |
Conclusion |
157 |
Introduction
This is a patent action brought by Vringo. They are the owners of EP (UK) 1 212 919 (“Relocation in a Communication System”). The priority date of the Patent is 14 September 1999. The patent is declared essential to the following 3GPP standards: TS 36.413, TS 36.331, TS 25.413, TS 25.331, TS 25.401 and TS 25.301.
The defendants are ZTE. ZTE do not admit infringement and contend that the patent is invalid having regard to the prior art. The three prior art documents relied on are: TS 25.413 V1.0.2 draft RANAP specification; A61 Tdoc; and TSGR3 3(99)359. In this case they are called 413, A61 and 359 respectively. There was a generalised allegation of lack of sufficiency but that was dropped. Vringo do not seek to defend the validity of claim 1 as granted. They seek to amend to bring claim 6 (as granted) into claim 1. In its opening skeleton [p.35] Vringo contended that claims 1, 8 and 13 were independently valid. Claims 8 and 13 were dropped in Vringo’s closing Skeleton [§84, p.28].
This trial is the first of a series of patent trials scheduled to be heard in the Patents Court between these parties in the next year or so.
The irrelevant prejudice
Although they never say so bluntly, ZTE contend that Vringo are “patent trolls”. They contend that Vringo have conducted themselves in various inappropriate ways around the world against ZTE. However ZTE have not alleged or pleaded that any of this conduct amounts to a defence relevant to the issues I have to decide at this trial. For example no defence in competition law is relied on. Vringo do not accept that ZTE’s allegations are correct. Whether ZTE are right or wrong about this is irrelevant and I will ignore these allegations.
The 919 patent was obtained by Nokia. It was declared to be essential to the relevant telecommunications standards. It is clear that Nokia participated closely in the setting of the particular aspect of the standard to which this patent is said to be essential. There was a hint at one stage that perhaps Nokia misbehaved in some way by persuading the relevant standards setting group to adopt the expedient claimed in the 919 patent or at least proposing the expedient as an option. However part of the standard setting framework recognises that patents may be essential to a standard. That is why participants in standard setting declare their essential patents as such. ZTE has not alleged or pleaded that anything amounting to a defence arises from Nokia’s involvement in this aspect of the standard setting process.
The questions before me are concerned only with the validity and infringement of the 919 patent.
Technical background
The first generation of cellular mobile phones were analogue devices. By September 1999 the second generation (2G) systems were well established globally: since 1990 there had been a finalised GSM standard and in 1992 GSM networks had been introduced in Europe. The GSM system is digital and GSM could handle voice calls and SMS (texting) and it could handle some data services. The architecture of the GSM network can be represented as follows:
(The SIM, GMSC, HLR and GGSN are irrelevant.)
Running from the left the Mobile Station (MS) is a mobile phone. Its contents do not matter. There is a radio connection between the MS and a BTS (Base Transceiver Station). In effect a BTS can be thought of as a mobile phone mast and associated equipment. By definition each cell has one BTS. A number of BTSs are controlled by a single controller called a BSC (Base Station Controller). The BSC and the BTSs it controls are together called a BSS (Base Station Sub-System).
In the original GSM system the BSCs connected to a unit called the MSC or Mobile Switching Centre. The MSC switched calls to the correct destination. It allows a call to be connected to other mobiles in the same network but also connects to the PSTN (Public Switched Telephone Network). A call from one mobile to another mobile in the same network still has to pass up to the MSC but no further. After the original GSM system was introduced a refinement called GPRS (General Packet Radio Service) was introduced to facilitate data transmission. Using GPRS the BSC connects to a Serving GPRS Support Node or SGSN. That is why the internet connection is drawn in the way it is in the diagram. The MSC and SGSN (and other elements shown) are called the Network Sub-System.
A particular aspect of cellular networks is handover between cells. If a phone is to move between cells in GSM it must stop communicating with the BTS in one cell and start communicating with the BTS in the next cell. Handover in the GSM system is called hard handover because the phone only communicates with one BTS at a time. If the hand over is between two BTSs controlled by the same BSC then it is called inter-BSC handover. But the adjacent BTSs may be controlled by different BSCs.
This involves “external handover” and is shown below:
In the handover depicted above the phone is moving from the cell of BTS #2 controlled by BSC #1 into a cell controlled by BTS #4 controlled by BSC #2. It is obvious that this external handover is more complicated than inter-BSC handover simply because more units on the land side of the network are involved. Somehow information has to pass from BSC #1 to BSC #2. The only route is via the MSC.
By 1999 both kinds of handover in GSM were well understood and the GSM standard had procedures for each of them.
By 1999 the next step to the third generation (3G) system was under very active discussion. It was anticipated that it would provide significantly higher data rates to enable multimedia services.
While GSM had been developed in Europe, the development of 3G was carried out by a global group called 3GPP. The developing 3G system was called UMTS (Universal Mobile Telecommunication System). The first UMTS standard was completed in March 2000, the first trial of UMTS was in Japan in 2001 and eventually UMTS was launched in Europe in 2003. The reason the work was done by standardisation was so that once the standards were settled, competition was preserved because different manufacturers could make equipment for the system. The inter-operability of the different equipment would be assured as long as it complied with the standards.
By September 1999 the overall architecture of the proposed UMTS system was clear. There would be units corresponding to the MSC, BSC and BTS. In UMTS the equivalent of the BSC would be a unit called the RNC (Radio Network Controller) and the equivalent of the BTS was to be called a “Node B”. The RNC and NodeBs together were called a Radio Network Subsystem (RNS). The whole network of RNCs and Node Bs in a system was called the UTRAN (UMTS Terrestrial Radio Access Network).
An important difference in UMTS was that a phone (User Equipment or UE) would be able to communicate with more than one cell simultaneously, i.e. more than one Node B. The state of a phone communicating with more than one Node B at the same time was referred to as macro-diversity or soft handover. These Node Bs could be controlled by the same RNC (intra RNC handover) or by different RNCs (inter RNS soft handover).
The case is concerned with a process called SRNS relocation which can be represented by four diagrams (from Mr Townend’s report) which are in Annex 1 to this judgment (figures 1 to 4). In the figures a cell is a hexagon, a Node B is shown as an aerial. The process is as follows:
In figure 1 the phone is connected to one Node B controlled by RNC #1. That RNC is called the sRNC or serving RNC. The messages between the phone and the MSC pass from RNC #1 to the MSC (thicker, red line).
In figure 2 the phone has moved so as to be within range of two cells and a simultaneous connection with a new Node B has been formed. That new Node B is controlled by RNC #2. This situation is inter-RNS soft handover. The signals to and from the phone now follow two paths. Running from the phone one path passes to the original Node B, up to the sRNC. The other path passes to the new Node B and up to a new RNC referred to in this context as the drift RNC or dRNC. The signals from that phone are then passed by the dRNC directly to the sRNC. Note the direct connection between the two RNCs. In the GSM system there was no equivalent direct connection between two BSCs. The sRNC is then able to combine all the signals from phone and it still maintains the connection with the MSC. As far as the MSC is concerned, the RNC which relates to the phone is the sRNC.
In figure 3 the phone has now moved closer to the new Node B. The radio link with the old Node B has been dropped. The phone only communicates with one Node B. But nothing much has changed as far as the RNCs are concerned. The old sRNC and dRNC are still performing those roles. The MSC still looks to the sRNC as the link to the phone. This arrangement is possible but does not make much sense in the long term. The sRNC is managing a user who is not connected to any of its Node Bs. It would make sense to change things so that the dRNC becomes the sRNC for the phone. This process of change is SRNS relocation.
Figure 4 depicts the result of SRNS relocation. The RNC which was the dRNC has now become the sRNC. The old sRNC no longer has anything to do with the phone. The connection with the MSC is now between the new sRNC and the MSC.
Sometimes the RNC identified as the dRNC in this process is called the target RNC or tRNC. Strictly it is only called a tRNC when the process of relocation to it has begun.
Protocols, layers and planes
A protocol is a set of rules which allows two devices to communicate. It typically defines the semantics, syntax and sequencing of messages passing between the two end points.
A very familiar idea in 1999 was a protocol layer stack. This allows different types of protocols to be used concurrently yet independently. Consider a message passing between a phone and the BSC in GSM. This message has to pass over at least two totally different physical kinds of connection: a radio link over the air and perhaps a fibre optic cable between the BTS and the BSC. These different media will have different characteristics. So different physical layer protocols will define the physical connection over the air between the phone and the BTS and the physical connection between the BTS and the BSC. But since the message is intended to pass from the phone to the BSC, the protocol relating to that message has nothing to do with the details of the two physical connections.
The idea of a protocol stack in this simple context is that one higher layer protocol defines the communication between the phone and the BSC while lower layer protocol(s) define the detailed signalling on the physical interfaces. The protocols on different layers are concurrent but independent. A message for the BSC is formatted in the phone in accordance with the higher phone-BSC protocol. The protocol termination points of the higher layer protocol are the phone and the BSC.
The formatted data (called a PDU or Protocol Data Unit) is passed down from the higher protocol to the lower one. The lower protocols are not concerned with the contents of the PDU. Strictly once formatted in a lower layer protocol the PDU is referred to as an SDU but there is no need to be concerned with that in this case. The term PDU will be used on its own.
In the simple example being considered, the first physical layer protocol is the one on the air link between the phone and the BTS. The protocol termination points of the first physical layer protocol are the phone and the BTS. The phone formats the PDU into a series of messages in accordance with the first physical layer protocol so as to send the messages to the BTS over the air link. Once the messages have been received at the BTS they are translated out of the first physical layer format. However since the BTS is not concerned with the contents of the higher layer PDU, that data is simply converted into messages to be passed to the BSC using the second physical layer protocol relating to the fibre optic cable in between the two units. The protocol termination points of the second physical layer protocol are the BTS and the BSC.
In this way a message is sent from the phone to the BSC in a language they each understand using appropriate relaying methods in the lower physical layer which neither the sender nor the recipient need to be concerned with.
In practice the number of layers in a stack may be much greater than two. An early well known example of a layered protocol stack was the 1984 Open System Interconnection (OSI) 7 layer model as follows:
Application layer protocol |
Presentation layer protocol |
Session layer protocol |
Transport layer protocol |
Network layer protocol |
Data link layer protocol |
Physical layer protocol |
The GSM did and the UMTS system was going to use a layered protocol stack method.
In the context of protocols and layers another idea is of “planes”. There are usually at least two planes – a user plane and a control plane. One imagines two independent but parallel protocol layer stacks governing the relationship between two entities, one plane for user data (e.g. the phone call itself) and another plane for control signalling. This case is concerned with the control plane.
Protocols and interfaces
When entities in a network are defined, it is often convenient to refer to and define the interfaces between them and the protocols governing their communication.
In UMTS the relevant interface between the RNC and the MSC was proposed to be (and is) known as the Iu interface and the relevant protocol governing communications between RNC and MSC was (and is) the RANAP protocol. In GSM the equivalent to the RANAP protocol was the BSSMAP protocol. BSSMAP governed control signalling between the BSC and MSC.
In UMTS the relevant interface between the UTRAN and the UE (mobile phone) was proposed to be (and is) known as the Uu interface and the relevant protocol governing communications between RNC and UE was (and is) the RRC protocol. In GSM the equivalent to the RRC protocol in UMTS was the RR protocol.
In the proposed UMTS system there was to be a direct interface between RNCs (shown in figures 2 and 3 of annex 1). This was to be the Iur interface and the relevant protocol was the RNSAP protocol. There was no equivalent in GSM.
Information elements, field elements and messages
Part of the way a telecommunication standard defines a protocol is by defining the messages which may be sent and what steps the recipient has to perform. A message will need to send some information (if only a code identifying the kind of message). The usual way of defining a message is by using a table setting out the fields making up the message. For example in the 413 prior art document a message known as “RELOCATION REQUIRED” is defined at paragraph 9.1.1.16 as follows:
The message as defined here has three fields known as information elements. In a complete standard each information element will then be defined as well. An information element may itself consist of multiple fields. The definition will specify whether the element is mandatory (M) or optional (O) (this can also be seen above) and will specify other information such as the type of data such as “integer”, “bit string” and “octet string”. An octet is 8 bits.
Protocol transparency and network transparency
The term “transparent” is a term of art. It is used in this case in different senses. Its meaning is an important issue. The word appears in the RELOCATION REQUIRED message shown above.
The usage is based on the metaphor of light passing through a transparent medium like glass. In normal English glass is transparent to light. The usage and the grammar in telecommunications can be confusing, no doubt in part because work of GSM and UMTS standardisation has been a mammoth undertaking with engineers from all over the world communicating about highly technical issues, generally in second language English.
One concept is “network transparency”. This is the idea that some data is passed through an entity in a network without being altered or acted upon in any way by that entity. The information element or message is said to be transparent to the network. As a matter of language it is a bit like saying light is transparent to glass but those skilled in the art know what is meant.
Another concept is “protocol transparency”. An example of this idea occurs when a higher layer protocol passes a PDU down to a lower layer protocol in the protocol stack. The PDU is said to be transparent for those lower protocols. The lower protocols cannot change the contents of the PDU or even understand them.
Examples of the use of the protocol transparency concept clearly existed but I was not shown any example of the use of that term before the priority date to describe the concept. There were examples of the use of word transparent in the context of network transparency before the priority date.
The prior art, the relevant standards and the invention
Before going any further, in order to see this case overall, it is worth explaining how the prior art, the relevant standards and the 919 patent relate to each other. This explanation involves events both before and after the priority date but it helps to understand what is going on. Of course one needs to guard against letting knowledge of what happened later influence an assessment of what happened before.
The three items of prior art are documents which played a part in the 3GPP standard setting process which led up to the standard. The documents relate to a group called WG3 which was a committee working on an aspect of the UMTS standard. WG3 was the group responsible for developing specifications for the UTRAN architecture and interfaces.
At that time (1999) the workload of the working groups like WG3 was very high. Meetings were held every month after the first meeting in February 1999. The meetings had around 50 delegates including delegates from the leading telecommunications companies at the time (e.g. Nokia, Ericsson and Motorola). By September 1999 the meetings had expanded to include more attendees. The work also involved reviewing written contributions. The number of written contributions was about 100-200 per month, growing over the period.
One aspect of WG3’s work was the RANAP protocol and the issue of SRNS relocation.
The earliest prior art document in time is 359. It dates from April 1999. It is a proposal from the company NEC to the WG3 group. The point of the document is to propose the RANAP message parameters with regard to the SRNS relocation. It is a short four page document consisting of a two page memorandum and two page annex which consists of text which could be incorporated into a specification. It contemplates that some RRC information of some kind will need to be sent from the serving RNC to the target RNC using the RANAP protocol.
The next cited prior art document in chronological order is 413. It dates from June 1999. 413 is the first draft of the technical specification TS 25.413. It is for discussion by the WG3 group. When complete it will specify the “UTRAN Iu interface RANAP signalling”. The complete version of the 413 specification is one of the specifications to which the 919 patent is declared essential. Many of the sections of 413 are empty. For example the section on “Functions of RANAP” contains nothing but an editor’s note stating “This chapter should describe functions of RANAP protocol”. 413 includes references to relocation and they are the focus of the validity case. This document contemplates that some information will need to be sent from the serving RNC to the target RNC using the RANAP protocol. The proposed definition of the RELOCATION REQUIRED message is set out above. It includes an information element called Source RNC to Target RNC transparent field.
The latest prior art document in time is A61. It arose from the WG3 meeting on 2327 August 1999 and is dated August 1999. It is a two page paper prepared by Nokia as a draft letter to be sent by the WG3 committee to other committees including WG2. WG2 was responsible for the RRC protocol. Since part of the thinking of WG3 at that stage was that some RRC information would have to be sent from the source RNC to the target RNC over the RANAP protocol, it makes sense to interact with WG2. The letter states various working assumptions about this which WG3 have made, makes some comments and asks questions. One question is what and how much information will need to be transmitted from the source RNC to target RNC in the proposed Source RNC to Target RNC transparent field during the relocation.
Vringo contend that the question, and these documents as a whole, all came from the same perspective. That was that all the information which had to be sent to the target RNC from the source RNC was going to be defined in the RANAP protocol specification. So the RRC parameters which the tRNC was going to need to set up a new RRC protocol termination point would be defined in the RANAP protocol specification. It is clear that those in WG3 at the time intended to define some of the information in RANAP but I am not convinced they had turned their mind to the issue with any care before the priority date.
The next meeting was due on 20-24 September 1999. However in the meantime on 14th September 1999 Nokia filed the priority application for the 919 patent. The invention as defined in proposed claim 1 was disclosed.
In a nutshell the invention as applied in this context is that instead of defining all the information to be transferred in the RANAP protocol itself as RANAP information elements, a new special PDU should be defined in the RRC protocol. This new PDU
will include all the information needed to start the RRC in the target RNC. The PDU will be inserted into a container in the RANAP protocol. Although it will be carried by a message defined in RANAP, the contents of the special PDU will not be defined in the RANAP specification at all. In the patent this special PDU is called a “Protocol Initialisation Unit” or PIU. The PIU will be transparent for the RANAP protocol.
Using this approach the team in charge of the RANAP protocol (i.e. committee WG3) do not in fact have to worry about what RRC parameters need to be transferred between RNCs during relocation. The team in charge of the RRC protocol (i.e. committee WG2) can worry about what RRC parameters need to be transferred.
Nokia’s idea was proposed to WG3 at the meeting on 20-24 September 1999 in a document reference TSRGR3#7(99)C23. This document proposes three possible ways forward. Options 1 and 2 involve defining the information to be transferred in the RANAP protocol specification itself, either (1) as RANAP information elements or (2) as a set of elements defined elsewhere. Option (3) is the invention.
The outcome of the WG3 September meeting was a note to WG2 suggesting using either options (2) or (3).
The next meeting was 25-29 October 1999. At the WG3 meeting it was clear there was no support for writing all the RRC parameters out in RANAP (option (1)). WG3 were going to ask WG2 which of options (2) or (3) they preferred. At the WG2 meeting, WG2 decided it was happy to adopt option (3) (i.e. the invention). WG2 also responded to document A61 (the question about what and how much RRC information had to be transferred) by saying they would postpone answering that question. Although the documents do not explain why, I infer that this followed from the fact that they liked option (3) and that option meant that what was to be transferred was a matter for WG2 themselves and not WG3.
The finalised UMTS standard adopted the Nokia proposal. The definition of the RANAP protocol contains an information element called Source RNC to Target RNC Transparent Container (see paragraph 9.2.1.28 of standard 3GPP TS 25.413, the part of the standard which defines RANAP signalling). That information element is produced by the source RNC and sent to the target RNC during relocation. The information element is transparent to the core network. The definition of Source RNC to Target RNC Transparent Container contains a number of information elements. Many are defined in the RANAP specification itself (such as Number of Iu instances, which is an integer) but one information element is RRC Container. As far as the RANAP specification is concerned this is simply a string of octets.
The definition of RRC Container is in the RRC Protocol specification (3GPP TS 25.331). It starts at paragraph 14.12.1. The SRNS Information is defined in paragraph 14.12.4.2. It runs to several pages of the standard, with many information elements. RRC Container is transparent for the RANAP protocol.
Vringo contend that proposed claim 1 is valid and would be infringed by equipment which operates in accordance with these standards.
ZTE contend that the invention lacks novelty over 359 and/or A61 and is obvious over all three of 359, 413 and A61.
The witnesses
Vringo relied on Richard Townend. He has a Masters in Electrical and Electronic Engineering with Management from Imperial College, London. Mr Townend joined BT in September 1997 and in 1998 started work on research and development activities related to UMTS, specialising in particular in handover including, subsequently, SRNS relocation. Starting in May 1998 Mr Townend acted as BT’s delegate to WG3. Mr Townend was technical secretary of WG3 from March 1999 until November 1999 and attended all of the group’s meetings. In September 2000 he joined BT Cellnet as principal radio design engineer. His involvement with GSM, GPRS and UMTS continued since then. Cellnet became O2. Mr Townend left O2 in 2003 and has worked as a consultant in the telecommunications industry since then.
ZTE submitted that although Mr Townend attempted to give his evidence fairly and honestly, at times when faced with an obvious option he searched for problems, looking for reasons why a skilled person would not take the obvious route. ZTE also submitted that he was at times unable to distinguish irrelevant factors from the relevant technical ones (such as in his reference to debates inside WG3). I reject both criticisms. In my judgment Mr Townend was a careful witness seeking to make sure he answered the questions posed correctly and fairly.
ZTE relied on Alastair Brydon. Dr Brydon is an electronics engineer who worked for BT Laboratories between 1989 and 1995, for Cellnet/O2 from 1995 to 1997, for Nokia from 1997 to 2001 and since 2001 as a telecommunications consultant. He has worked on GSM, DECT, TFTS and UMTS. He has given evidence in telecoms patent cases before.
Vringo mounted a sustained attack on the position Dr Brydon had been placed into in this case. First they submitted that although he had done some work relating to UMTS, he had not been involved in UMTS standardisation (or GSM standardisation) and so had no personal knowledge of what approach the skilled person would take or what industry attitude to the problems in this case was. I reject that submission. Dr Brydon’s role required him to keep up with developments in UMTS standards. His technical expertise means he was able to give evidence so as to put the court into the position of viewing the issues from the perspective of the skilled person.
Second Vringo submitted that the manner in which Dr Brydon had been instructed, involving presenting him with a statement of case called Particulars of Principles of Common General Knowledge, meant his evidence was tainted with hindsight. They submitted that the common general knowledge he had been provided with guided and directed his discussion of the patent. I reject that criticism. The premise of the submission is that Dr Brydon was presented with this document early in the process. He was not. It is clear that he discussed the technical background and common general knowledge with the legal team well in advance of ever seeing the document. The later presentation of the document to him does not show he was “led by the nose”, as Mr Carr put it.
Third, Vringo referred to the fact that Dr Brydon was given paragraphs 2 to 7 of the patent to consider first, rather than being asked to consider SRNS relocation in general. Since Dr Brydon’s view was that what is said there was all part of the common general knowledge, I do not accept this as a criticism of the position into
which the witness was placed. A different question is whether all these matters were indeed part of the common general knowledge but that is a point on the merits which I will consider below, not a point about Dr Brydon’s position as a witness.
Fourth, Vringo submitted that an unfavourable contrast could be drawn between the stance taken by Dr Brydon in relation to a document setting out the common general knowledge in an earlier case (HTC v Apple) and the lack of any similar comment by him in this case. However whatever the status of the document was in HTC v Apple, in this case the only role played by the document at trial that I was aware of was when Vringo raised it in cross-examination with Dr Brydon. I do not accept there is any ground for criticising Dr Brydon about this.
Similarly Vringo criticised Dr Brydon for expressing the view in cross-examination that the invention was obvious over common general knowledge alone but not mentioning it in his report. However ZTE was not advancing a distinct case of obviousness over common general knowledge alone. Their opening skeleton makes clear they will not address it separately. The only reason Dr Brydon expressed the view in cross-examination is because counsel asked him to. I can see no basis for criticising Dr Brydon for doing that.
Fifth, a point was taken that when Dr Brydon was given the prior art he was not invited to think about common general knowledge. It was suggested this was an acontextual approach which leads to “obvious flaws”. I do not accept there is anything in this point. I did not find Vringo’s attempt to try and delve into Dr Brydon’s recollection for the details of how he was instructed to be a useful exercise.
Finally Vringo submitted that his first report showed obvious evidence of hindsight because in it Dr Brydon had interpreted the references in the cited prior art to “transparent” as references to protocol transparency when in fact they are not. It is clear that Dr Brydon did indeed interpret the prior art that way in his first report and he subsequently changed his view. However while he changed his view Dr Brydon maintained that the invention was obvious and gave ostensibly cogent reasons for that latter view, which I will consider below.
Overall as a witness at trial Dr Brydon understood his role and sought to fulfil it properly and helpfully. As I said he explained his views and gave reasons for his opinions. In my judgment he prepared his reports on the same basis, mindful of his role and seeking to help the court. He was prepared to adjust his views to take into account points made by Mr Townend. That is the mark of an expert fulfilling his duty to the court. Dr Brydon’s evidence was tested in cross-examination. This case turns on the consideration and weighing up of Dr Brydon’s views and reasons for them as against the corresponding evidence from Mr Townend. It does not turn on the manner in which Dr Brydon was instructed.
The person skilled in the art and the common general knowledge
The person skilled in the art in this case will be a system architect employed by a mobile telecommunications manufacturer or network operator. They would have an electronics engineering or computer science degree. Their work will take place in the wider context of an interdisciplinary team with even wider experience but nothing material turns on that.
As regards common general knowledge, I accept that the development of UMTS was moving rapidly at the priority date but I do not accept Vringo’s submission that the matters described in the technical background section about UMTS had not crystallised sufficiently to be part of the common general knowledge. They were well known to all involved and were regarded as a sufficiently firm basis on which to move forward. That includes in particular SRNS relocation. I find that the common general knowledge of that person will include all the matters described above in the technical background section.
A point arose about the skilled person’s relationship with standards. I will return to that below.
The patent specification
Although the generality of the patent is wider than SRNS relocation in UMTS, the preferred embodiments and many dependent claims are limited to that. The background section of the patent runs from paragraphs 2 to 7. Paragraphs 2 to 6 provide a very brief description of telecommunications standards, protocol termination points, cells, handover and relocation. Soft handover is described (paragraph 5). The document is here referring to UMTS although it does not say so. The problem of relocation of the controller (the RNC) in this context is described (paragraphs 5 and 6).
Paragraph 7 explains that the state of the protocol termination point is something which will need to be relocated (col 2 line 22-26). Then the patent states at col 2 ln 28-32 that “At present the parameters which need to be transferred have to be defined also in the protocols which are used to convey the information from the old termination point to the new termination point.” ZTE submitted this was not correct as a statement of the position at the priority date, because no such decision had been made for the relevant case (RRC in RANAP). I find that at the priority date WG3 had not positively made the decision to do this and so to that extent ZTE is correct. Nevertheless on any view taking the approach described was a method very familiar to the skilled person and part of the common general knowledge.
The patent then states that taking this approach for RRC (amongst others) in RNSAP would mean “a lot of ‘external’ parameters would have to be defined in RNSAP”. Two points emerge from this. First the reference to RNSAP. RNSAP could be used in SRNS relocation instead of or as well as RANAP. For present purposes nothing turns on the difference between RNSAP and RANAP. Second the number of parameters. ZTE contended that this indicated that the skilled person would know that this was the case at the priority date. Vringo did not agree. They contended that at the priority date the skilled reader would not know as a matter of common general knowledge how many parameters had to be transferred. The issue is not one of significance to the interpretation of the patent, it only matters for obviousness and I will consider it there.
Finally (col 2 ln 39-44) paragraph 7 of the patent states that this (defining in RNSAP given the number of parameters) would increase the complexity of RNSAP and make independent evolution of the two protocols difficult. Again this is a matter of no significance to the interpretation of the patent but bears on obviousness and I will consider it there.
Consistory clauses are set out in a “summary of the invention” section in paragraphs 8 to 18, paragraph 19 refers to the advantages mentioned already and the preferred embodiments and drawings are described in paragraphs 20 to 46. Figures 1, 2 and 3 depict various well known aspects of the network. Figure 4 is a flow chart. The invention is used in steps 34, 36 and 38.
Some of the terms used in the patent e.g. sRNC, dRNC and Iu, are clearly taken from the draft UMTS standard. Other terms, such as BTS, come from the GSM standard. As Vringo submitted, this reflects the fact that the patent was filed during a period of rapid development in UMTS technology, when the standard had not been finalised.
The specific embodiments describe the essential idea of using a special PDU or PIU defined in the RRC protocol to define the information which needs to be transferred from the sRNC to the tRNC during SRNS relocation and sending it across in a RANAP or RNSAP message. The patent acknowledges (paragraph 37) that the encapsulation of a PDU transparently into another protocol is a known technique. It is referring to the use of PDUs in the protocol layer stack context. Claim construction
Proposed claim 1 consists of claims 1 and 6 as granted. Broken down into suitable integers, it is in this form:
A method in a communication system for relocating a protocol termination point, characterised in the steps of:
using a first protocol to define a protocol initialization unit (20) at a first termination point of a first protocol (34), said protocol initialization unit containing predefined information pertaining to initialization of a second termination point (36) of said first protocol;
transferring the protocol initialization unit from the first termination point to a second termination point by a second protocol; and
initializing the second termination point based on the protocol initialization unit (38);
wherein the protocol initialization unit (20) is transparent for the second protocol.
The claim is to a method used in a communication system for relocating a protocol termination point. An example would be the relocation of the RRC termination point from the sRNC to the tRNC during SRNS relocation in UMTS.
According to feature (b) a PIU containing the information which will be needed to initialise the second protocol termination point (i.e. the one in the tRNC) is defined in a first protocol. When applied to UMTS the first protocol can be RRC.
Feature (c) provides that the PIU is transferred from the first to the second termination point by a second protocol. So an example in UMTS of this second protocol would be RANAP.
Feature (d) simply requires the initialisation of the new protocol termination point in its new location using the information in the PIU.
Feature (e) is taken from old claim 6. It refers to protocol transparency. The meaning of protocol transparency was not in dispute.
The only point on claim construction is one which I was responsible for and arose at trial. Feature (b) refers to defining a PIU in a protocol. It seemed to me that this feature might be seen as an attribute of a standard rather than an attribute of a system. Indeed the patent is consistent with this since it refers to an advantage of the invention as being the independent evolution of the protocols. ZTE submitted this was right but Vringo did not agree. I suspect part of Vringo’s concern was that it might be thought that this meant the invention had some kind of non-technical character or only had an advantage which was administrative in nature. Perhaps the invention makes the process of standard setting easier but does not make for a better mobile phone network as such.
Vringo submitted that feature (b) did not refer to the definition of the PIU as part of the protocol definition at all but rather was a reference to the step by the computer of creating a PIU using the rules of the first protocol. They submitted that read otherwise the claim would have three steps in which the first was about the act of drafting a protocol specification and the other two were steps taken by a network computer equipment in its normal operation. I agree that the latter point is true but despite it I do not accept Vringo’s construction for two reasons. First it is just not what the words say. Second, the words used in feature (b) make sense to the skilled reader because the main advantage of the invention, mentioned in the patent more than once, is an advantage which flows from the drafting of the protocol specification. A critical part of the invention relates to the place and manner in which the PIU is defined within the various protocols making up a whole system definition. The advantage flows from the fact that the definition of the PIU is part of the first protocol. Of course the computer in the sRNC when using this method will use those rules to format an appropriate PIU but that does not alter the fact that the advantage flows from the location of the definition.
Vringo referred to claims 16 and 22 (claims 17 and 23 as granted). They refer to a control means which forms a PIU. This does not help. It is plain that something like a control means does have to form the PIU in practice. There was no focus on the details of these claims in argument. They do not use the word “define” but I note they refer to “information of the first protocol” which might be thought to refer to information defined in the first protocol.
Vringo also submitted that both experts were clear that some modification to hardware and/or software would be needed if protocol transparency was introduced. That was not established. Mr Townend’s evidence was that as a result of details of the way in which signals and data in the two particular protocols RANAP and RRC are defined, data defined in RRC is in a different format from data defined in RANAP and will need a different decoder. So a system sending a PIU of RRC data in RANAP
will be different from a system sending the same information as data all defined in RANAP. However the claim is not limited to RRC and RANAP and Mr Townend was clear that this just happened to be so because of the specifics of RRC and RANAP. He did not say it followed generally. Dr Brydon’s view was the definition was not really about implementation at all. Although he thought an implementer would write special software routines for this, his view was that one could not necessarily say that just because something was written in one document rather than another the software would be different.
ZTE did not argue that this point gave rise to a non-infringement argument nor did they raise any point on software patenting or the like.
Notably Vringo’s infringement case for feature (b) of the claim, set out in Mr Townend’s report, includes references to the manner in which the relevant information container is defined in the specification of the relevant protocol in the standard.
It seems to me this appreciation of the true nature of the invention does not mean the invention does not have a concrete technical character. Protocol definitions are not merely administrative documents, they are specifications which define how a system has to perform. They are highly technical in nature. The benefits of the invention are tangible. A telecommunications system which implements the invention is a better system because it is more flexible and easier to maintain.
This point also sheds light on the inventive concept, which matters for consideration of obviousness. As ZTE submitted, this patent is not one that attempts to solve any problems at the systems or implementation level. It is addressed to those working on the definition of protocols, i.e. those working on standards. If one is not thinking about the structure of standards then the precise way in which protocols define the information to be transferred will not be of great interest. The patent does not require the skilled person to delve into things at the level of the subroutines put to Dr Brydon or the decoders mentioned by Mr Townend.
I conclude first that feature (b) is referring to the definition of a protocol. That could be in a standard. Second, necessarily therefore the skilled person is someone concerned with protocol definitions. They are not simply an implementer concerned with building network equipment, they are a person concerned with creating the protocols which define a telecommunications system as a whole, i.e. defining standards.
Novelty
To deprive a claim of novelty the prior art must both disclose and enable the invention ( Synthon [2006] RPC 10). To disclose the invention there must be clear and unmistakable directions to do something which falls within the claim.
Document 359 proposes a RELOCATION REQUIRED message defined in the RANAP protocol to go from the sRNC to the Core Network (CN) and then on from the CN to the tRNC. The message has an information element called RRC Information. The text states of RRC Information that “this parameter is transparent field” (sic). Vringo’s case is that this refers to and would be understood to refer to network transparency, in other words that the information element would be transparent for the core network (CN). ZTE’s argument is that this discloses an information element which would exhibit protocol transparency or at least is ambiguous about whether it is referring to protocol transparency or network transparency. As a reference to protocol transparency it would necessarily imply that the contents of the information element RRC Information would be defined in the RRC protocol and passed through the RANAP protocol like a PDU.
Dr Brydon read 359 initially as referring to protocol transparency but he accepted it could be read as a reference to network transparency. In cross-examination he maintained it was ambiguous. Mr Townend’s view was that it would be understood to mean network transparency.
Some of Vringo’s case involved looking at other contemporaneous documents from WG3 which showed that the writer of 359 must have intended to refer to network transparency. I am not persuaded that this is relevant since the question is: What would a skilled reader think the author meant? not What did the writer intend? If the skilled reader did think the document was ambiguous in this respect then I accept they might go and look at other contemporaneous WG3 documents since they were available, and might well then draw the inference proposed by Vringo but (see below) in my judgment the 359 document is not ambiguous.
It was also suggested that the notional skilled person would in fact be a member of WG3 because the whole industry was involved in the UMTS project and so the skilled person would know what the writer of 359 meant. That goes too far. If it was right then all or at least a significant element of the content of all the discussions of WG3 would be part of the common general knowledge. That was not established.
Turning to 359 itself, in my judgment the skilled person would understand 359 to be referring to network transparency. It is not ambiguous. In context it is discussing a message being passed to the CN with information not directed to the CN but for the tRNC. That is enough to show the skilled person that it is talking about network transparency. The message is not for the CN and it makes sense for it to be transparent for the CN. The idea of using network transparency in this context would be a familiar one.
The text also mentions some information to be included in RRC Information, i.e. Cipher key, Cipher Algorithm and UE Capability for RAN. The fact these fields inside RRC Information are defined supports Vringo’s case but I would reach the same conclusion even if they were not mentioned.
ZTE also relied on document A61. This refers to usage of a field called Source RNC to Target RNC Transparent Field. The document explains that the existing sRNC will need to provide all the necessary information regarding the UTRAN-UE connection that is required by the target RNC to start working as a new serving RNC. It states that the information will be passed in the Source RNC to Target RNC Transparent Field which is to be carried over the Iu interfaces in RANAP messages.
The RANAP messages will be RELOCATION REQUIRED and RELOCATION
REQUEST. Although A61 does not say so in terms, the reader would understand these two messages as follows. RELOCATION REQUIRED is the message to come from the sRNC to the CN when the sRNC wishes to initiate SRNS relocation. RELOCATION REQUEST is the message the CN then sends to the target RNC to ask if it is able to accommodate this SRNS relocation. A61 does not explain this in detail but a skilled reader would infer it or at most would consult the draft standard, i.e. the 413 document, which was available. 413 would make this clear.
Although the text in A61 differs from the text in 359 in my judgment the conclusion is the same. The skilled reader would not regard this reference to transparency as ambiguous. They would regard it as a disclosure of the idea of network transparency. It makes sense to specify that the proposed field is transparent to the CN because it is information travelling from one RNC to the other RNC via the CN. It is not a message aimed at the CN.
I am not persuaded that references in A61 to the GSM system and BSSMAP make any difference to the novelty issue. They have a role to play in inventive step and I will address that below.
I reject ZTE’s case based on lack of novelty.
Obviousness
The structured approach to the assessment of obviousness was set out by the Court of Appeal in Pozzoli v BDMO [2007] EWCA Civ 588, [2007] FSR 37. It is:
(1)(a) Identify the notional person skilled in the art;
Identify the relevant common general knowledge of that person;
Identify the inventive concept of the claim in question or if that cannot readily be done, construe it;
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;
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?
In Conor v Angiotech [2008] UKHL 49, [2008] RPC 28 the House of Lords considered the issue of obviousness. There Lord Hoffmann (with whom the others of their Lordships agreed) approved the following statement of Kitchin J made in Generics v Lundbeck [2007] RPC 32:
"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."
In Medimmune v Novartis [2012] EWCA Civ 1234 the Court of Appeal emphasised that the nature of the court’s task was ultimately to answer a single question of fact; see Kitchin LJ paragraph 93 and Lewison LJ paragraph 117 - 186.
I have identified the skilled person and the common general knowledge above. I have also construed claim 1. In terms of inventive concept, two points are worth making. First the key idea in proposed claim 1 is the use of protocol transparency. Second protocol transparency is a feature of a protocol, it is not really a feature of a system.
In closing ZTE argued obviousness starting from A61 first. I will do the same.
A61 discloses the idea of transferring all necessary information regarding the UTRAN-UE connection from the sRNC to the tRNC so that the tRNC can start operating as the sRNC. The skilled reader would understand this to be a disclosure of relocating one or more protocol termination points from the sRNC to the tRNC by transferring predefined information pertaining to the initialisation of the second termination point from the first termination point to the second termination point. Document A61 never mentions the RRC protocol but in my judgment the skilled person would understand that the RRC protocol termination point in the sRNC would be one of the termination points which was being contemplated as being transferred and that information normally defined in the RRC protocol would be one of the kinds of information which needed to be transferred. Although Mr Townend generally accepted that it was obvious that RRC information would have to be transferred during SRNS relocation, he did point out that A61 did not mention the RRC. He is right about the words used in A61 but I find that the skilled person reading A61 would understand that RRC information was one of, probably the paradigm case of, information which had to be transferred in the manner described.
Document A61 states that the information to be transferred will be sent in messages defined in the RANAP protocol in the information element called Source RNC to Target RNC Transparent Field. As I have held for novelty, this would be understood to be a reference to network transparency. At times Vringo appeared to argue that network transparency and protocol transparency were opposites in some way so that the fact any of the prior art referred to network transparency meant they were ruling out protocol transparency. I do not accept that. Network and protocol transparency are different ideas, not antitheses. I find that the references to transparency in A61 say nothing about whether protocol transparency is to be used or not.
To compare A61 with proposed claim 1, the first protocol is the RRC protocol and the second protocol is the RANAP protocol. The real difference between A61 and proposed claim 1 is the requirement for protocol transparency being added into the claim from old claim 6. It might be said that A61 also does not disclose defining a PIU in the RRC protocol as per granted claim 1. However there is in substance only one difference because it is clear that if the skilled person decided to use protocol transparency for SRNS relocation then they would necessarily define a PIU in the RRC protocol.
ZTE contended it would be obvious for a skilled person to implement SRNS relocation by using protocol transparency. Protocol transparency itself was a well known idea both generally, in the context of PDUs in the protocol layer stack, and in particular, in a closely related circumstance in the GSM system of external handover between two BSCs. Moreover it had an obvious benefit in keeping the two protocols (RANAP and RRC) separate and allowing them to evolve independently. Although the skilled person would not, at the priority date, know how much RRC information had to be transferred from one RNC to the other, they would know they needed to know and they would find out. The answer is that a large amount of RRC information needs to be transferred (as can be seen from the UMTS standard today). Protocol transparency would be an obvious solution to the problem created by this large amount of information. ZTE’s case was supported by Dr Brydon.
Vringo denied the claim was obvious. They contended that the two known examples of protocol transparency when properly understood indicated inventiveness not obviousness. Neither example is like the invention. The benefit of allowing the protocols to develop independently was not obvious, it is an advantage of the invention. This approach had not been taken before. At the priority date the skilled person would not know how much RRC information had to be transferred. That information only emerged after the priority date and therefore cannot help ZTE. Even if the skilled person did find out how much needed to be transferred, it would not make protocol transparency obvious. The skilled person acting without inventive activity would simply define all the information to be transferred by RANAP in RANAP, as they had always done. If a lot of information had to be transferred and therefore defined, so be it. Vringo’s case was supported by Mr Townend.
The first question is whether a skilled person would do anything at all given A61 at the priority date. Part of Vringo’s case involved a submission that the draft UMTS standard was in such an ill-defined form that a person whose job it was to design and develop network equipment would not do so. They would wait until the standard was clearer. I think Vringo are correct that it would be premature for a skilled person to embark on designing UMTS network equipment at that stage but the point is irrelevant. The task of the skilled person at the priority date would be (and would obviously be) to settle the design of the overall architecture of the system itself, i.e. to settle the messaging, information elements, protocols and so on. In other words the skilled person would be setting out to complete the exercise which was being carried out by the 3GPP working groups. The particular task at hand is to complete the specification of SRNS relocation. It was obviously a task to be undertaken. The fact it is also a process of standardisation does not mean it is not a systems design exercise. Once designed there would be no invention involved in putting it into practice.
One possibility mentioned by Mr Townend was for WG3 to put off settling SRNS relocation until a later date. Putting it off was an option available but it was also obvious to work on SRNS relocation at the priority date.
In my judgment the skilled person given A61 would take as a starting point the idea that the information which needed to be sent to the tRNC would be sent in a RANAP message passed from the sRNC to the CN and then on to the tRNC. The information would be transparent to the CN. It would be obvious that the information required to be sent would include information defined in the RRC protocol. That is because the
sRNC communicates with the UE using the RRC and so it was obvious that a new RRC had to be set up in the tRNC using the information held at the sRNC.
The natural thing to do would be to define all the information to be transferred in RANAP in the RANAP specification itself. Document A61 does not expressly specify that that is the way forward but I find that the skilled person would make that assumption initially.
PDUs and the protocol layer stack
ZTE relied on the use of PDUs in the protocol layer stack as making the use of protocol transparency an obvious expedient over A61. The layer stack and the use of PDUs were common general knowledge but I am not satisfied the skilled person would see any reason to apply that thinking in this context. There is no trigger to cause the skilled person to do so in A61 itself and no reason from the common general knowledge to link the two. RRC does not send messages via RANAP. RANAP is not a protocol at a lower layer than RRC. The two do not relate to each other in that sense at all. RRC governs communications between the RNC and the phone whereas RANAP governs communications between the RNC and the CN.
Once the idea has been explained, the analogy with PDUs in the layer stack is an obvious one, but that is a different matter.
An analogy with GSM external handover and BSSMAP
An important part of ZTE’s case relates to the approach to external handover taken in GSM. Recall that in external handover, a connection between the phone and a first BSS is broken and replaced by a new connection between the phone and a new second BSS. ZTE contended that this was part of the common general knowledge of the skilled person and that it would make it obvious to use a similar, protocol transparent, approach in the analogous situation in UMTS. Moreover ZTE also submitted that A61 itself expressly points the reader to think about the analogy. The document specifically states that “The assumed Iu RANAP procedures are similar to those of GSM A interface BSSMAP used for external handover.” ZTE argued, supported by Dr Brydon, that this would prompt the skilled person to use protocol transparency just as it is used in GSM external handover.
In order to deal with this it is necessary to explain GSM external handover in more detail. The message flow was explained by Dr Brydon using this figure:
In the diagram the MS is the phone and the same MS appears on both sides. BSS-A is the BSS (i.e. BSC + BTS) which the phone is connected to initially and BSS-B is the BSS to which the phone is going to become connected. GSM external handover involves messages passing between the MSC and BSS. These messages are governed by the BSSMAP protocol.
The process starts with a message from BSS-A to the MSC (MSC-A) which indicates that a handover is required. The MSC then asks new BSS-B if it can accommodate the phone. These two messages are HANDOVER REQUIRED and HANDOVER REQUEST. They are BSSMAP messages and are defined in the BSSMAP protocol. They contain an information element called Old BSS to New BSS Information. It is a container for information to be passed between the BSSs via the MSC. This is an example of network transparency but not protocol transparency. The contents of Old BSS to New BSS Information are defined in BSSMAP.
The BSSMAP protocol includes two further messages called HANDOVER REQUEST ACK and HANDOVER COMMAND. The message HANDOVER
REQUEST ACK is sent by the target BSS-B to the MSC to indicate that BSS-B can support handover. The message includes information which will tell the phone which radio channel to tune to (etc.) so that it can communicate with the target BSS. Since BSS-B has no extant radio link with the phone (because in GSM a phone can only link to one BTS at a time) the only way the information can be sent to the phone is by passing it up to the MSC and down to BSS-A so that it can go to the phone on the existing radio link. The information is first sent by BSS-B to the MSC in HANDOVER REQUEST ACK and then from the MSC to BSS-A in the HANDOVER COMMAND message. The information can then be sent to the phone, telling it how to tune its radio to talk to the new target BSS.
The information for the phone is defined in a protocol transparent manner. The messages HANDOVER REQUEST ACK and HANDOVER COMMAND are
BSSMAP messages and are defined in the part of the standard dealing with the BSSMAP protocol (e.g. GSM 08.08 TS 100 590 paragraph 3.2.1.10). One information element in these messages is Layer 3 Information. In the BSSMAP protocol definition Layer 3 Information is defined simply as a string of octets. The BSSMAP definition (GSM 08.08 paragraph 3.2.2.14) also explains that it is an unchanged octet of a radio interface layer 3 message as defined in the RR protocol (i.e. GSM 04.08). Therefore this is a clear example of protocol transparency.
Once the HANDOVER COMMAND message is received at BSS-A, the phone is given the information needed to connect to BSS-B. This is shown in the diagram by a message called RI-HO-COMMAND from BSS-A to MS on the left and then the MS connects to BSS-B on the right-hand side of the diagram using the message RI-HOACCESS. The remaining messages complete the handover and tell the other parts of the system it has occurred.
Mr Townend did not accept that this reasoning made the use of protocol transparency from SRNS relocation obvious. His view was that the reference to GSM external handover in A61 would simply be understood as a reference to the overall sequence of messages (shown above) and not to the detailed contents of these messages. I agree. In my judgment it is an exercise in hindsight to see the reference in A61 as having anything to do with the protocol transparent definition of the information element Layer 3 Information in the relevant BSSMAP messages.
Nevertheless the A61 document does point the skilled person to the idea of considering GSM external handover procedures in this context. Moreover even without the prompt in A61, a skilled person would consider GSM external handover. It is sufficiently analogous to SRNS relocation for it to be obvious to take it into account.
Mr Townend also made two further points. First he emphasised that the issue under consideration over A61 is to send information from the serving RNC to the target RNC. In GSM this is like the Old BSS to New BSS Information sent by BSS-A to BSS-B. That information is not sent using protocol transparency, it is all defined in BSSMAP. The example of protocol transparency relied on by ZTE relates to a different situation, in which information is being sent from the target BSC back to the serving BSC. I accept Mr Townend’s point. The particular context in which protocol transparency is used in GSM here is not the same as the one under consideration for UMTS.
Second Mr Townend focussed on the RR message sent from BSS-B to the MS which is relayed through the MSC and BSS-A. It is protocol transparent but importantly for Mr Townend it is a normal RR message being used in its usual way – for communications between the BSS and MS. The reason the message is routed via the MSC and BSS-A is because BSS-B is not in communication with the MS at this stage. I accept Mr Townend’s point here.
As part of this second point Mr Townend also explained that although of course the message starts at one BSS and does get to another BSS, it is really aimed at the MS. It is not really an example of one BSS communicating with another BSS. Mr Townend used the term asymmetric to characterise the point that in GSM the message is ultimately from one kind of entity to a different kind (BSS to MS) whereas he characterised the communication in SRNS relocation as symmetric (one RNC to another RNC). I accept this too.
The skilled person given A61 would consider GSM external handover. However I am not satisfied they would extract from it the idea of using protocol transparency in order to send RRC information from the sRNC to the tRNC via RANAP. The way protocol transparency is used in GSM external handover is in a different context from the problem being considered by the skilled person. Moreover, as Mr Townend explained, in GSM there is no need to define a new message. This is a key distinction. In GSM the message sent via BSSMAP is a normal RR message. There is no such existing message in RRC in UMTS. The invention requires the skilled person to define in RRC an entirely new message which is not used in RRC at all.
There was at least one other example of the use of protocol transparency (or at least partial transparency) in GSM (GPRS Suspend Information) but it was further away from the invention than this BSSMAP example and cannot assist ZTE.
The number of RRC parameters needed
ZTE argued that the large number and uncertain nature of the RRC parameters which had to be transferred in RANAP would lead the skilled person to think of defining them in RRC and not RANAP. This would allow the protocols to develop independently and Dr Brydon explained that that advantage would be common sense.
One answer from Vringo was that WG3 did not know at the priority date how many and what RRC parameters had to be transferred and so the skilled person would not know either and would not be concerned by this. I do not accept that reasoning. It is true that WG3 did not know but it was entirely obvious to a skilled person that they would need to know what parameters had to be transferred. No invention at all is involved in finding out.
However I do not accept a point which may be implicit in ZTE’s reasoning that the skilled person would think they needed to know the answer to this question before deciding whether to employ protocol transparency or just define the information in RANAP itself. On the contrary, I find that the skilled person would at this stage be assuming the information to be transferred would all be defined in RANAP. The skilled person, without hindsight, would not have any reason to think that a decision about whether to use protocol transparency had anything to do with the answer to the question: what needs to be transferred? They would know they needed to know what had to be transferred but their working assumption would be simply that they would acquire this information so as to put appropriate definitions in RANAP.
In some cases a skilled person knows they need to find something out, perhaps in a chemical case by conducting an experiment testing possible candidate active agents and knows before they do the test that they need to know the answer before deciding how to move forward. That is not this case. In this case there is no a priori link between the decision and the answer to the question.
However ZTE also contended that even if the skilled person had not thought about it before, once they were told just how much RRC information had to be transferred, and also told (at the priority date) that the relevant team WG2 was not sure exactly what information had to be transferred, the invention was obvious. Dr Brydon thought it would be common sense to use protocol transparency in that context and allow the standards to evolve independently.
ZTE contended that Mr Townend accepted in cross-examination first that once the RRC information was known to the skilled person, writing out all these parameters in RANAP would result in unnecessary inter-dependence and second that it was well understood that unnecessary dependence between protocols should be avoided. Mr Townend did indeed accept both points, however I am not convinced that they are enough to make the invention obvious. They establish that the skilled person would see that cross-defining in RRC and RANAP all the information which had to be transferred would cause a problem but that does not mean they would see the invention as an obvious solution to that problem. For the invention to be obvious a skilled person faced with this problem has to see the idea of using a protocol transparent PIU as an obvious solution to it.
The protocol transparency used in GSM external handover is not being used to solve this kind of problem. It is used simply as a way of relaying a message from its normal sender (a BSS) to its normal recipient (a phone) via the only available route. The message to be relayed already exists. The issue is not about the number or uncertain identity of parameters to be sent.
Protocol transparency is also used in the context of the protocol layer stack and PDUs. It is true that a fundamental advantage of the layered protocol approach is to keep the protocols independent of each other but it seems to me to involve inventive insight to extract a solution to the RRC/RANAP problem from this other context. Protocol independence is maintained in the layer stack regardless of the number of parameters to be sent.
Dr Brydon called the idea of maintaining the independence of the protocols a common sense rationale. It is common sense to use it once you have had the idea but I am not convinced the idea was obvious. Mr Townend explained that having the same information appearing in different parts of the standard and different protocols is a frequent occurrence. I think an uninventive skilled person faced with the very long list of RRC parameters would simply go ahead and define them in RANAP.
Contemporaneous documents
ZTE pointed out that the three options proposed by Nokia to WG3 in document C23 for the 20-24 September meeting exhausted all three possible ways forward (including the invention as option (3)). I do not think this adds significantly to ZTE’s case. It was produced after Nokia had already made the invention. It does not show the invention was obvious.
Vringo relied on evidence about the reaction inside WG3 to Nokia’s proposal. To consider the weight to be attributed to the actual reactions inside WG3 may involve having to distinguish between reactions to the technical merit of an idea as opposed to reactions driven by other irrelevant factors. I prefer to decide this case focussed on the merits of the technical issues.
Inventive step overall
Standing back, I was not persuaded by ZTE’s case that the invention was obvious. To be obvious the idea of using a protocol transparent PIU has to come from somewhere. ZTE identified a number of sources from which the idea might have come or which
might have provided what is sometimes called a hint to the skilled person. I was not persuaded by any of them individually or collectively. In my judgment the obviousness case here is an argument tainted with hindsight.
Obviousness over 413, 359 and common general knowledge alone
If ZTE’s case over A61 does not succeed, it will not succeed over either of the other two documents or over common general knowledge alone.
Infringement
ZTE accepted that on the claim construction advanced by Vringo in this jurisdiction there was no separate point on infringement. ZTE emphasised that if different interpretations of the claim are advanced elsewhere then different considerations may arise. They also formally do not admit infringement.
Vringo’s infringement case is supported by Mr Townend in his confidential annex to his first report. In that report Mr Townend dealt with the definitions in the UMTS standards and explained why products defined in the pleadings as “ZTE UMTS controllers” infringe in two different ways during SRNS relocation. First is the process of relocation of the RRC termination point. That covers the familiar ground discussed above. Second is the relocation of the RANAP protocol termination point. In this context RANAP is the first protocol. It defines a PIU to be sent to the tRNC from the sRNC. The PIU is carried by the RNSAP protocol and so RNSAP is the second protocol called for by the claim. I accept Mr Townend’s opinion on the relocation of both protocol termination points. It follows that the use of ZTE UMTS controllers in a UMTS system infringes the 919 patent.
Mr Townend also considered a completely different network system, the LTE network. LTE (Long Term Evolution) is the 4G system. Just as the 3G UMTS network consists of a core network (CN), a radio access network (the UTRAN) and a mobile device (the UE) so the LTE network consists of a core network (now called the Evolved Packet Core (EPC)) a radio access network (now called the Evolved UTRAN (E-UTRAN)) and the User Equipment (UE).
Whereas the UMTS radio access network (UTRAN) had two kinds of entity: Node B base stations and controller devices called RNCs, a key difference between the UMTS UTRAN and the LTE E-UTRAN is that the E-UTRAN consists of only one type of device – a base station called an eNodeB. The LTE radio access network does not feature a separate controller device and so has a flatter hierarchical structure. In an LTE radio network, the eNodeB includes the control functions that were located in the RNC in UMTS. The overall architecture of the land side of the LTE system can be seen as follows:
The diagram shows the two kinds of interface in this part of the LTE system. In effect and for the purposes of this case the S1 interface in LTE corresponds to the Iu interface in UMTS while the X2 interface in LTE corresponds to the Iur interface.
Both the S1 and the X2 interfaces consist of user planes and control planes. Responsibility for handling user data and signalling messages in the EPC is separated so that the S-GW handles the user plane and the MME deals with control plane. The signalling protocol used over the S1 interface that extends to the MME is called the S1 Application Protocol (S1AP). This is equivalent to RANAP in UMTS. The signalling protocol used over the X2 interface is called the X2 Application Protocol (X2AP). This is equivalent to RNSAP in UMTS.
Like UMTS, LTE also features a signalling protocol called RRC which connects the UE to an eNodeB. It also features a handover procedure. When appropriate the RRC protocol termination point will be relocated from a source eNodeB to a target eNodeB. There are two ways of doing this, one using the S1AP protocol over the S1 interface and an alternative using the X2AP protocol over the X2 interface.
For LTE the relevant products were defined in the pleadings as ZTE LTE products. Mr Townend’s opinion was that in both cases the relevant definitions appear in the standards and the claim was satisfied by the operation of the ZTE LTE products. I accept his opinion. It follows that the use of ZTE LTE products infringes the 919 patent.
Furthermore, for both the UMTS and LTE cases, it follows from Mr Townend’s evidence which I have accepted that all the products are means relating to an essential element of the invention for putting it into effect. There is no issue concerning knowledge relevant to s60(2) of the 1977 Act and so supply of these items in the UK by the defendant would infringe the 919 patent.
Conclusion
EP (UK) 1 212 919 is valid as amended and is infringed by ZTE.
Annex 1
SRNS relocation
Figure 1: Figure 2:
Figure 3:
Figure 4: