Research In Motion UK Ltd. v Inpro Licensing SARL

This is an action for revocation of EP (UK) 0 892 947, which belongs to the defendant Inpro Licensing SARL, a Luxemburg company. The Claimant is the United Kingdom subsidiary of the Canadian company commonly referred to as RIM, which is responsible for the well-known ‘BlackBerry’ device. There is a counterclaim for infringement against RIM and against the mobile telephone service provider T-Mobile, which supplies BlackBerry devices in the United Kingdom.

The action has not had an entirely satisfactory procedural history. The claim form was issued on 20 May 2005, and on 16 June 2005 Laddie J made an order for a trial according to the streamlined procedure, including a counterclaim and application to amend, to be heard over two days with one day’s pre-reading. The matter was ultimately mentioned to me as the trial judge in August 2005, when I increased the estimate for the length of the trial to five days with two days’ pre-reading. The trial started with an application by RIM for security for costs of the counterclaim, which took up time, and the estimate turned out to be barely sufficient to hear the evidence, and speeches had to be heard two weeks later. This gave the parties an opportunity that they did not resist to produce very substantial written arguments.

This is one of those cases where the subject matter is apparently simple. Now that I have read the documents and heard the evidence, I am sure that it was not appropriate for the streamlined procedure. I cannot say that on the material available to Laddie J the decision to use the streamlined procedure was wrong, but I must disagree with his proposition that once a party to an action proposes the use of the streamlined procedure that procedure will be used in the absence of a convincing objection from the other. The decision to use the streamlined procedure is an objective one to be arrived at on all the material. There are no presumptions. It is not unusual in patent actions for one or (sometimes) both parties to consider that their case is both straightforward and easy to try. They are often wrong: and in any event, the dissentient must be allowed a proper opportunity proportionate to the matters at stake fairly to put its case, and that may preclude use of the streamlined procedure. Speed is highly desirable in all cases, but not at the expense of fairness. One relevant factor is the commercial importance of the patent. This patent, which is said to be infringed when any BlackBerry device downloads a webpage including images using the BlackBerry service, is commercially important to the present form of that service.

Professor Handley, who gave evidence on behalf of RIM, was a careful witness. He had been involved in the art at the relevant time and was deeply involved in the process for the establishment of technical standards in the internet world. His evidence was criticised on the basis that it was too standards orientated. I found him intelligent and helpful. From time to time he did obviously think quickly, but the area in which this was most apparent (the knowledge to be attributed to the skilled man of something called MIME and its prescribed file formats) is not something that ultimately I have found it necessary to decide. His evidence was cogent and helpful.

This action has been unusual, at least in my experience, for the very strong attack made on the qualifications and abilities of Professor Eisenstein, for Inpro. Mr Watson QC ultimately submitted that no weight could be attached to his evidence. Professor Eisenstein has a very distinguished list of qualifications and he has been president of the IEEE, the Institution of Electrical and Electronics Engineers, which is the principal professional body in the field in the United States and probably in the world. He has taught graduate and undergraduate courses in telecommunications technology, digital signal processing and circuit design. On the face of it, he was an ideal expert, and I was surprised when his cross-examination started with an examination of his qualifications. The fuller picture is as follows. He is an electrical engineer. He is not a computer scientist, his area of research interest being digital signal processing. He has not taught or researched computer science, despite having suggested in an interlocutory witness statement that he had. He has published three papers since 1991. He was not familiar with the engineering aspects of the internet, and he was, it seems, unaware of the standards promulgated in the form of RFC’s, of which more later. This action is in part concerned with browser programs for the World Wide Web. Although he accepted that anyone writing browser programs would have to be familiar with the relevant RFC’s he had never read them. He was an experienced witness, having given evidence in at least fifty sets of proceedings with diverse subject matter, ranging from RF-controlled garage doors to the siting of cellular communications towers. It was put to him directly on the basis of his website that he was, in effect, a professional expert. The words ‘hired gun’ were not used, but that was plainly the flavour of the accusation.

None of these matters is in itself an objection to a witness, with the exception of the suggestion that he had taught computer science. A witness who lacks expertise in the particular area with which a patent is concerned can read himself in to the state of the art at the priority date and can be of great assistance even if he lacks contemporary experience, his general knowledge providing a framework for his analysis. Such an expert must, like all experts, carefully preserve his independence from those employing him and must do his best objectively to assist the court.

There are a number of minor points in which it is clear that he did not research the position properly. More important to me was that he made a number of exaggerated statements, one of which in particular stood out when I first read his statement. This concerns the state of the art in late 1995. My reading of paragraph 35 of his report is that he was suggesting that the World Wide Web and its protocols were not part of the common general knowledge in late 1995–early 1996. He suggested that from October 1995

‘The "Web" has gone from a term requiring explication when used among university computer researchers to a household word understood by children.’

The whole of his cross-examination on this topic (transcript 347-9) should be read. It is very unsatisfactory. So too was his general behaviour under cross-examination. This has nothing to do with his demeanour. It is a complaint about the way he answered questions. He was a remarkably obstructive witness, and repeatedly quibbled. I was persuaded on at least two occasions to intervene not for the purpose of elucidating answers or to obtain information, but to attempt to break into a refusal to answer a question. Transcript 457-459 and 516-520 are examples. He commented on counsel’s reasons for asking questions from the point of view of the case being advanced, and appeared to be conscious on many occasions of the potential impact of his answers. On one or two occasions he answered comparatively detailed questions with what can only be described as speeches: see 443-444. He was occasionally hyperbolic: one of the cited documents, Bartlett, ‘approached in an open-minded way, from my opinion, would teach me nothing’. This was not a sensible statement. Occasionally it was clear that he was familiar neither with the documents under discussion nor his own evidence.

Mr Watson multiplies examples in Annex A to his skeleton argument, but for my purposes what is set out above is enough. I am afraid that Professor Eisenstein was simply an unsatisfactory expert. I will not entirely ignore his evidence, because it was so uniformly favourable to Inpro that it represents the highest at which Inpro’s case might be put, and because not all his answers struck me as unsatisfactory. In the end, I came to regret his lack of objectivity, because it deprived me of a reasonable view based on a thorough knowledge of the case that was contrary to that being advanced by Professor Handley. Mr Mellor did a great deal by way of a very well constructed cross-examination and well-judged submissions to fill this gap, but it is still there, and I have endeavoured to make allowances for it.

The title of the patent is “A Proxy-Server System For Enhancing Functionality Of Computers Accessing Servers On The Internet”. Its priority date is 1996. It is principally concerned with the manner in which web pages are accessed by a user surfing the web. It proposes a number of ways of ‘pretreating’ web pages before they are downloaded to machines of modest processing capacity so as to save time and, if the modest machine is battery-powered, to give longer battery life.

There was a substantial dispute as to the common general knowledge of the skilled person at the priority date. The experts were agreed that the addressee of the specification would have qualifications equivalent to a master’s degree in computer science, but in a small number of important respects they differed as to his state of knowledge. I shall return to this in its place, but what follows is intended to represent a barebones summary of the relevant technology.

First, the internet. The World Wide Web, with which the patent is primarily concerned, depends for its operation upon the internet. The internet is a network connecting a vast number of computers, all of which may be thought to have a unique identifying address consisting of four bytes. The connections between these computers differ widely in kind, but things are arranged so that from the point of view of an applications programmer the machines all communicate using a single set of protocols. The basic protocol, called the internet protocol, or IP, defines the address structure of each machine as four bytes, usually written in the form 212.137.36.113 (this is the IP address currently corresponding to www.hmcourts-service.gov.uk). There are two so-called transport protocols, the transport control protocol or TCP, and the user datagram protocol or UDP, which ‘sit on top of’ IP and provide the programmer with a means of sending a packet of data from a source to a destination. TCP/IP provides a so-called reliable service, in which the recipient can require packets to be retransmitted, and can reassemble the received message in the order in which the packets were transmitted. UDP is an unreliable protocol, adding little to IP, and does not provide for the sender to know whether or not a transmitted packet was received. If UDP is used, the sender’s basic approach is to wait for a period of time, and, if no response is received, retransmit the packet. The reason that there is a difference between reliable and unreliable communication, and why it matters, is not immediately easy to grasp. The basic idea is that the internet was designed as a connectionless network so that if a physical part of it failed the packet would still arrive at its destination. There are a large number of potential routes between two computers connected to the internet, and any packet may, in principle, follow any of those routes. The time taken will differ widely from route to route, and thus packets may be lost or may arrive in a different order from that in which they were transmitted. TCP/IP provides a connection-oriented or reliable method of sending a message from source to destination over the internet (i.e., over the IP protocol) and in doing so uses a substantial amount of overhead, both in opening a path to the destination and in keeping the packets in order. UDP has much less overhead, and if one can guarantee that a message will fit in a single packet, and it doesn’t matter if it is lost, then it has substantial advantages. One application of UDP with which all users of the internet will have come into contact is the Domain Name Service or DNS. This is the service that takes an internet address in human readable form (the domain name) and returns the current IP address in numerical form. This service is used every time a link in a web page is clicked, or an email is sent to a human readable address.

Conventionally, TCP/IP can be viewed as a ‘stack’ of protocols (Footnote: ¹). The sending application has data which it wants to have sent to a particular computer. The transport layer breaks the data into segments. These segments have headers the contents of which depend on the transport protocol to be used. The network layer assembles the segments into IP datagrams or packets, the essential feature of which for present purposes is that they contain the source and destination address. So the transport protocol segments are wrapped up in IP datagram(s). The IP datagrams are then passed to the underlying datalink and physical link layers, represented by the Ethernet in RFC 1180. In the case of a personal computer, at least the first stage in such a communication will be an Ethernet connection, or perhaps a wireless protocol connection to a modem, which may perhaps use PPPoE or PPPoA for its entry into the public telephone network. The IP header will be used to control the routing of the packet over the network to its destination. But the various protocols and networks involved are not the concern of TCP/IP.

The top layer of the protocol stack is the realm of applications. Applications, particularly client-server applications, will have their own high-level protocols for communication, while leaving the task of making sure that each communication reaches its intended destination to TCP/IP. An application-level protocol with which this action is concerned is HTTP, the Hypertext Transfer Protocol, which prescribes how the transactions between a browser and a web-server are constructed and processed.

Second, the Web. By 1996, the internet was old, established technology. The basic protocols, including IP, TCP and UDP and the other protocols on which it depends had been defined since 1981. Two developments together made it what is now in effect a consumer product. The first in time was graphical display. Graphical display, which is associated with windows-menu-pointer user interfaces, made a great improvement in the usability of computers. The second is the invention of the World Wide Web. The Web consists of a network of computers connected by means of the internet and communicating by means of the applications layer protocol, HTTP. Broadly speaking, the computers are either servers, which make ‘web pages’ available, or client computers, which call for them. The web pages are written in a language called HTML (Hypertext Markup Language). The browser is software on the client that interprets the web pages and displays their contents. HTML permits so-called links to other material such as images to be included in the text of a web page. Such links may be permanent, or clickable. When the browser software encounters a permanent link in the page that it is interpreting, it sends a request for the file specified by the link. If the link is clickable it does so when the link is clicked. The link may point to any item accessible from the internet, so I could include a link to the Mars Explorer photographs in the HTML version of the judgment, if I thought it might help. These links, so-called hypertext links, are central to the success of the Web. At the priority date, I am satisfied that all these aspects of the Web would be known to any programmer wishing to write software for displaying web pages. HTTP is an application-layer protocol and, as I have said, runs on top of TCP. The client opens a connection to the server and requests a page. HTTP is used to transmit the request to the appropriate server, which sends an appropriate response:

HTML consists essentially of so-called tags and text. Tags are enclosed between angle brackets < > and may for example indicate the inclusion of an image or a clickable link. The following is the code used on the United Kingdom Parliament website to include a clickable image of the portcullis. The <a…> and </a> tags delimit the clickable link, the href attribute is the page that will be fetched if you click on it, and the <img…> tag includes the image, with its filename. The alt attribute is what will be displayed if the image is not available:

<a href="http://www.parliament.uk/"><img src="/epic/portcullis_black.gif" width="61" height="68" alt="Portcullis image and link to site home page" border="0"></a>

The <img…> tag itself is a non-clickable hyperlink: the requested image may reside on any machine and may be any file that can be identified by a URL.

It is an oversimplification, but not one that matters, to say that the Web has three essential components: TCP/IP, HTTP and HTML, respectively the transport protocol, the hypertext protocol for transmitting hypertext requests and the hypertext markup language for the pages themselves.

With the foregoing brief introduction I can turn to the patent.

Professor Handley expressed the view, which I accept, that the patent has to be approached with caution for a number of reasons, that he expressed as follows:

‘I personally doubt very much whether the author of the specification had even considered a number of the issues arising and I am concerned that, in the context of these legal proceedings, it is easy to read into the Patent subtleties that were simply not in the author’s mind. The difficulties in interpretation are compounded by the absence of any implementation details which might shed light on what some of the terms used mean.’

At the same time, it must be remembered that there is no plea of insufficiency of description. My task is to interpret the specification and claims in context, and to find out what the specification discloses. The claims must be interpreted in their context to find out what the scope of the protected invention is.

The first part of the specification is labelled ‘Description’ and from [0001] to [0010] it sets out general considerations relating to the trade-off between computing power and battery size in portable computers. It is said ([0008]) that

‘…sophisticated operations for small, portable computers, such as World Wide Web (WWW) browsing on the internet, are not, until the time of the present invention, very practical.’

The problem to be solved using the invention is concisely stated in [0010]:

‘What is clearly needed is apparatus and methods whereby sophisticated operations like Web browsing and the like may be accomplished with small, battery-powered portable computers, such as hand-held computers, while also accomplishing a life-between-charges of a week or more, without requiring especially heavy batteries.’

Nowhere in the remainder of the specification is any more information given in respect of life-between-charges apart from a promise of a two-thousand times improvement in [0051], but the objective, which is to cut down the amount of processing carried out by a portable computer and to accommodate the low bandwidth of the connection, is clear. After acknowledging the prior art known as “GloMop”, which is pleaded and to which I shall return, but which forms the basis of the description of the current invention:

‘[0011] In “GloMop…” there is disclosed a computing system comprising a field computer comprising a display having a specific size and resolution; and a Proxy-Server connected to the field computer by a data link, the Proxy Server having an internet port; wherein the Proxy-Server is adapted to access Internet servers through the Internet port directed by commands and data received from the field computer, to download data from the Internet servers thus accessed, to transpose the downloaded data by reducing information density, and to transfer the transposed data to the field computer (13) via the data link in a TCP/IP format.

[0012] The invention is characterised in that the Proxy-Server downloads data comprising WEB pages and transposes the data to match the specific size and resolution of the field computer.

[0013] The invention is alternatively characterised in that upon connection, the field computer transfers to the Proxy-Server information particular to specific characteristics of the field computer, and wherein the Proxy-Server incorporates the information in transposing data for transfer to the field computer.’

[0011] provides the precharacterising portion of claims 1 and 2 before amendment, [0012] providing the characterising portion of claim 1 and [0013] the characterising portion of claim 2. It may be noted that [0011] is not Web-specific: it refers to internet servers generally, and it is only in the treatment of Web pages that the invention is characterised.

[0015] to [0019] do not call for separate comment, but paragraph [0020] indicates that the invention is to be implemented in software, as one would expect. [0021] provides a little more information as to what the inventor is interested in:

‘[0021] In practising the invention, one's adapted personal computer is coupled to a Proxy-Server over a data link such as a telephone modem, and may, according to an aspect of the invention, transfer specific information. such as the type, size, and resolution of the personal computer's display, to the Proxy-Server. The Proxy-Server may then browse the World Wide Web according to instructions received from the personal computer, transpose files downloaded from the Web into a form quickly and easily usable by the personal computer, and transmit the transposed data to the personal computer for display. Very large files may become fewer files, and much smaller files in the transposition.’

This passage describes the ‘transposition’ of data intended for display to a form more quickly and easily usable by the personal computer. Here, as elsewhere, the user’s computer is described as a personal computer, and the invention is said in [0034] and [0035] to be applicable to personal computers of all types, while having particular applicability to small battery powered devices such as PDA’s.

It is therefore clear that the Proxy-Server, or more accurately the software that it runs, is of central importance. It is described in [0036]-[0039]. [0043]-[0046] and Figures 1 and 2 describe the system, with some repetition in [0047]-[0049]. A long, and not entirely consistent, transcript of a session is described in paragraphs [0059]-[0074] by reference to Figures 3 and 4. Professor Handley sets out a long, unchallenged, description in clear language of how the system works. What follows is my summary.

One of the difficulties with the description of the invention is working out the nature of the processing carried out by the InterBrowser software in the Proxy-Server. Paragraph [0050] is one of the few parts of the specification which gives any indication of the kind of processing contemplated:

‘[0050] An ID match when connecting a hand-held unit to the Proxy-Server provides the Proxy-Server with information about the handheld unit, such as CPU type and power, screen size, type and resolution, presence of a pointer device, and sound capability. The Proxy-Server then uses this specific information to translate HTML and other files from the Internet to a form readily usable without extensive additional processing by the hand-held unit. For a small monochrome LCD display a 60k/70k JPEG file becomes a 2k/4k bitmap, for example. Also, multi-file pages are recombined into single file pages. This translation also minimizes bandwidth requirement for link 15, and speeds transmission of data.’

While it is reasonably clear what is contemplated for images, it is not so easy to see what is contemplated for HTML files. What is supposed to be done to an HTML file without included images? How does one reduce its information density? The specification is completely silent. There is just no description at all of modifying or transcoding HTML ‘to a form readily usable without extensive additional processing by the handheld unit’. Professor Handley suggests such things as removing colour information or font information from HTML-encoded text, and I accept this.

The remainder of the specification does not call for detailed comment, and it is possible to turn to the claims. The position is considerably confused by the fact that a number of amendments have been proposed to claims 1, 2, 7 together with the addition of claims 1A, 1B, 2A, 2B, 7A and 7B, 8A and 8B, 12A and 12B, and 13A and 13B. It is agreed that I should consider the issues as to allowability raised by the amendments, together with the validity of the amended claims (claims 1, 2, 7, 8, 11, 12 & 13 as granted (and the equivalent claims as proposed to be amended) are in issue).

The structure of the claims is as follows.

Claims 1 (as proposed to be amended), 1A and 1B are as follows:

‘1.— An Internet Proxy-Server (19) comprising:

a first data port (37) adapted for accessing other Internet servers; and

a second data port (35) adapted for connecting to a field computer (13);

wherein the Proxy-Server (19) is adapted to access the other Internet servers (23) through the first data port (37), directed by commands and data received through the second data port (35) from the field computer (13), to download data from the Internet servers (23) thus accessed,

To transpose the downloaded data by reducing information density, and

to transfer the transposed data via the first data link in a TCP/IP format

characterised in that

upon connection, the field computer (13) transfers to the Proxy-Server (19) information particular to specific characteristics of the field computer (13) including information identifying the specific size and resolution of the display of the field computer (13),

and wherein the Proxy-Server (19) downloads data comprising WEB pages and transposes the data in reliance on such information to match the specific size and resolution of the field computer (13).

1A.—A computing system as claimed in claim 1, wherein the Proxy-Server (19) is adapted to access the said Internet servers (23) in order to download a Web page upon receiving a request represented by a URL for that page from the field computer (13), to download two or more files comprising the Web page in response to said request, including at least one HTML file and at least one image file, to transpose the HTML file and image files into a form designed for display on the field computer (13), and transfer to transposed data to the field computer (13).

1B.—A computing system as claimed in claim 1 or 1A, wherein during transposition, HTML and image files are assembled into a single file for transfer to the field computer’

Claim 2 has the same pre-characterising part as claim 1, and the characterising portion is as follows:

‘characterised in that

upon connection the field computer (13) transfers to the Proxy-Server (19) information particular to specific characteristics of the field computer (13) , and wherein the Proxy-Server (19) incorporates the information in transposing data for transfer to the field computer (13).’

The scheme of the amendments is as follows:

Consideration of the prior art (particularly the acknowledged “GloMop” document which forms the basis of the precharacterising part of the claim) and the alleged infringement enables a substantial number of difficulties and obscurities of interpretation to be identified.

Most questions that arise in considering infringement and validity of patents are really of the form “does the word or phrase X cover Y” even if they may be expressed in the form “what does X mean” and it is sometimes more helpful to deal with such questions as they arise. This course has its own dangers, the task of interpretation being a task which must be carried out once and for all as of the priority date. The recent decision of the House of Lords in Kirin-Amgen Inc v Hoechst Marion Roussel Ltd [2004] UKHL 46, [2005] RPC 9 (page 169) confirming the earlier decision in Catnic Components Ltd v Hill & Smith Ltd [1982] RPC 183 sets out the proper approach to the question of construction to ensure compliance with Art 69 of the European Patent Convention, which is the governing provision. RIM identify nine such problems, and I shall list them here, postponing any consideration of them until the need arises.

(a) The meaning of the following phrases:

Whether the requirement in claim 1 (and claim 1 as proposed to be amended) that “the Proxy-Server downloads data comprising WEB pages and transposes the data to match the specific size and resolution of the display of the field computer” requires that all elements of the web page (e.g. HTML and images) are matched to the specific size and resolution of the display (as RIM say) or whether matching of any part of the web pages (e.g. just a single image) suffices (as Inpro suggest).

During the preparation of the case and after it became clear when the hearing date would be, it became apparent that the allegation of infringement had expanded beyond what I shall call the BlackBerry system to include browsing over other types of connection available from 2G mobile telephony service providers, particularly WAP (Wireless Application Protocol) internet browsing. When this action was started by RIM it was not contemplated that there should be an allegation of infringement in respect of this capability of the BlackBerry devices and I ordered it to be tried later, having regard to the urgency which Laddie J had identified in disposing of the allegations of invalidity.

Both the BlackBerry system and the support for WAP browsing are described in a Confidential System Description. This document went through a number of drafts, but it was in the end used for the purposes of cross-examination by both sides. The disclosure of this document is rather more comprehensive than the BlackBerry Browser Development Guide relied on by Professor Eisenstein for his analysis of the infringement issues, but it must be consulted for information relating to the protocols used between the BlackBerry Browser and its proxy server and for information relating to the treatment of email attachments.

Two basic services are to be considered in this action. These are the corporate service, which will be used by people that want to access emails on their corporate email servers, which enables them to use a single corporate email address wherever they may be. The corporate system also permits browsing of any corporate intranet and of the internet, and a WAP browsing ability that I will not consider. The second service is the so-called “Prosumer” service. This provides the user with access to BlackBerry email account(s) (“BIS-email”), an internet browsing service (“BIS-browsing”) and a WAP browsing service that again I will not consider.

The central issues of fact are

The corporate system is depicted in the System Description thus:

Reading from left to right in the diagram, the respective functions of the various components of the system are as follows.

I shall try and restrict the use of the abbreviation “BES” to the email redirection server. The whole system (MDS and BES) is referred to as the BlackBerry Enterprise Server software, which is confusing when abbreviated.

The “prosumer” product is generally for users who do not need, or do not want, access to email on corporate servers or access to corporate internets. In this case, the BlackBerry service is rather like that provided by an ISP. BlackBerry host email servers on which the user may maintain one or more email accounts. This is called BlackBerry Internet Service email or BIS-email. Second, a WWW browsing service is provided through proxy servers maintained and hosted by RIM.

The foregoing services are all independent, so a particular handheld may have access to all or some of them. The services available on a particular handheld are recorded by so-called Service Books, which appear as icons on the screen of the handheld. The services available to each handheld are prescribed by the service provider (T-Mobile) and they are downloaded to the handheld when it first registers with the Relay, which may happen either when it is activated by a new user, or when the device moves from the area of one network carrier to that of another. The registration process uses both a PIN and the device’s network ID and provides the handheld with a “routing table” which gives it a list of IP addresses that have to be used for the purpose of accessing the internet.

Provided the handheld has received the appropriate service book, it can access the Web using the MDS. The handheld sends a request to the MDS-Server using the protocol called RIM-HTTP. This protocol is a modification of the usual HTTP, but normal operation is as follows. The handheld sends an HTTP ‘GET’ request for a particular URL. That request contains two HTTP “headers”. The first, “User-Agent”, is a standard HTTP header and is used to identify the handheld model and version. A second, non-standard, header is “Profile”, which includes the URL of a public website - maintained, as I understand it, by RIM - that serves a page in another markup language, XML, listing all the attributes of the particular brand and model of handheld, including BitsperPixel (ie colour depth), PixelAspectRatio and ScreenSize. The last is stated as x × y in pixels.

The MDS-Server downloads the web-page in the same way as a browser would, by the use of HTTP. Web pages are assumed to be written in HTML. The MDS-Server software “cleans up” the HTML. Web pages are frequently written in ill-formed HTML, and part of the job of a browser is to make a guess as to what was intended based on many considerations. This function is carried out in the MDS-Server.

Tags are also abbreviated. Instead of the mnemonic forms that are prescribed for HTML (LINK, IMG and so on) single bytes are used. This translated language is called RIM-HTML. Some standard HTML tags are stripped out altogether, such as comments (<!...-->), which are not displayed by standard browsers but can be seen if the source of the page is viewed, something most browsers permit. They cannot be viewed at all on BlackBerry handhelds. The <FONT…> tag is also removed, because the BlackBerry handheld does not acknowledge font changes.

Image content (eg. identified by the <IMG…> tag) is downloaded from the Web by the MDS server using the HTTP protocol. Since the Web is provided over the internet, it uses TCP as the transport protocol over IP.

Image content is further processed by the MDS-Server. Two things are done. As I understand the evidence, all images regardless of format are translated into either JPEG or PNG format. Second, the MDS-Server maintains a database of User-Agent Profiles ([48] above) appropriate to the particular handhelds with which it is dealing. Using the ScreenSize parameter, it decides whether each image is either wider or higher than the screen. Those images that are either wider than the screen or more than twice the height of the screen are scaled so that the width of the image is equal to that of the screen or the height is twice that of the screen, respectively. The scaling operations preserve the ‘aspect ratio’ of the image so that it remains the same shape, and in this process it is assumed that each pixel on the display of a handheld is approximately square.

Third, all JPEG images are reduced in quality to 65%, something that is possible with JPEG encoding. Then a further User-Agent Profile parameter, “ColorCapable” is consulted, and if the device is incapable of displaying colour the colour palette is reduced to black-and-white and the image further altered to obtain grey-scale effects. If the device is capable of displaying colour images, this indicates that it is capable of displaying so-called 16-bit colour, and the image is further processed to display advantageously on a system so limited. Different file formats are used, depending on the size of the resulting image: the smallest will be used.

Web pages are not just composed of HTML. Transmitted with the page may be XML (eXtended Markup Language), Javascript (a programming language widely used to enable processing at the browser to validate user input, produce dialogue boxes and the like), CSS (Cascading Style Sheets), WML (Wireless Markup Language, like HTML but designed for WAP browsing), WMLscript (like Javascript for WML), and other material, particularly executable code, all of which is transcoded by the MDS-Server into more compact formats.

The assembly process is as follows. The MDS-Server first obtains the HTML page requested and processes it in the way I have described, cleaning it up, and removing certain of the tags. It marks the position of all IMG tags. It then obtains all of the images contained within the page and processes them in the way I have described. It inserts the first ten images in line in the processed HTML. When the tenth image has been included, the page is sent to the handheld, immediately followed by the remaining (processed) images.

The point of the issues of construction I have labelled 1(ii)-(vi) and (viii) and issue 2, can now be seen more clearly. I will deal with the question of protocols 1(i) separately. Issue 1(viii) only relates to the prior art.

This question arises because although the claim refers to matching to size and resolution, the specification does not say what it means by matching, at least in any clear way. Nor, RIM maintain, does it explain why it needs both size and resolution, and what is meant, in context, by the word ‘specific’. I shall take the latter point first.

The context for this phrase where it first appears in [00012] is provided by the acknowledgment of the document known as “GloMop”. While this document is acknowledged as disclosing a system that ‘transpose[s] the downloaded data [for transmission to the field computer] by reducing information density’ in the case of images it plainly and obviously performs this feat by sending not the image itself but a ‘thumbnail’ of the image:

‘Example: Graphic image. We can reduce the area or the color palette or both for a large full-color graphic. For example, we reduced an 8-bit-color, full-screen (VGA) GIF image to a thumbnail-sized 4-gray image for display on a Sony MagicLink PDA. In so doing, we reduced the image's size from 503 Kbytes to 560 bytes, and the transmission time (including real-time distillation) from 2000 seconds to 13 seconds at 1200 baud. Furthermore, because our image processing included optimal quantization to the PDA's (static) graymap, the resulting image was much sharper on the PDA screen (and therefore more useful to the human viewer) than the dithered original, so we actually increased the perceived image quality while reducing the size a thousand fold.’

It should also be noted that so far as HTML is concerned a browser has and had considerable freedom in laying out a page. The patent clearly contemplates that the ‘NanoBrowser’ will be capable of laying out a page wider and longer than the display and of providing means for navigating within the page: see [0074].

What is said to distinguish the invention of claim 1 (but not that of claim 2) from this disclosure is precisely the characterising portion of unamended claim 1, as set out in [00012]:

‘…the Proxy-Server downloads data comprising WEB pages and transposes the data to match the specific size and resolution of the display of the field computer.’

The word ‘specific’ is there for a purpose. It is not that one matches the data to the screen merely knowing that the screen is small, and suitable only for thumbnails, since that at least is what GloMop discloses. The patentee makes it quite clear that this feature distinguishes GloMop and the context strongly suggests that he is aiming for a better match than the thumbnail, a match that takes into account the actual display characteristics of the screen, not merely its relative smallness.

‘Size and resolution’ is perhaps an unhappy phrase to have used, but it seems to me it is quite clear in context. What the programmer needs to know is the width and height of the screen in pixels. That interests him because it tells him how small to make the image. If the width and height of the screen is expressed in inches, and the resolution in pixels per inch, which was conventional, the two together yield the size in pixels, which is what is wanted. If the size is expressed in pixels the resolution is not required, unless the programmer is also worried about visibility of the image, of which there is no mention anywhere. I interpret the phrase as meaning ‘screen size expressed in pixels’.

‘Match’ is rather more difficult, since it is intended to put blue water between claim 1 and GloMop. The phrase has no particular meaning of the art, in contradistinction to (for example) ‘scale to’, which is given in [0071] as an example of the treatment of an image. ‘Thumbnails don’t match, what is claimed does match’ is the antithesis that the claim appears to be intended to suggest to the skilled man. In context, no such antithesis is implied when it comes for the textual part of the page because, as I have pointed out, the specification suggests that the resulting page may even be bigger than the display (see [0074]). Nonetheless, the claim does not in terms distinguish image data from other data going to make up a displayed page.

Unsurprisingly Mr Watson QC argued on behalf of RIM that because the claim indicated its indifference to what was to be matched to ‘size and resolution’ by employing the word ‘data’ it was hopelessly obscure and indeterminate, to the extent that it was not possible to assess the issue of infringement by the process for the treatment of HTML and images that I have described above. I do not think this is right. I think that given the context derived from the disclosure of GloMop, and the importance of this feature as providing a differentiation from the disclosure of that document, I have come to the conclusion that it is concerned with image data. Some negative support for this view can be gained from the specification, which is thin in its disclosure in respect of the transcoding of image data but is completely silent as to any change that might be made to the HTML in its translation to ‘HT-Lite’ to reflect any qualities of the display, as opposed to any other qualities such as low computational power, or restricted capabilities such as a single font.

I think that the requirement that the Proxy-Server ‘transposes the data [comprising WEB pages] to match the specific size and resolution of the display of the field computer’ is met if the computing system of the claim is equipped with software or hardware that is capable of scaling image data associated with that page to fit the display or at least to produce a good match to the display. No alteration to the HTML content of a web page is called for. ‘Match’ itself is not an absolute term. Like ‘vertical’ in Catnic, it takes its colour from its context. It is legitimate, I think, to talk in this context of a good match, or a reasonable match, or a bad match. The claim is talking, in my judgment, about a match between screen and image substantially better than would be achieved without transposition arrived at by employing the display size and not just as a shot in the dark, or a safe minimum.

It follows from the description that I have given above of the operation of the BlackBerry browsing system satisfies this feature of the claim unless it can be said that the scaling feature does not ‘match’ the image to the display. In my judgment, it does. Indeed, positive steps are taken to scale to the size of the screen, although the end result may be still be larger than the display and require scrolling by use of the thumbwheel.

The point I have just discussed is central to the proper interpretation of proposed claim 1A and to the question whether that claim represents added matter. The claim is as follows:

‘A computing system as claimed in claim 1, wherein the Proxy-Server (19) is adapted to access the said Internet servers (23) in order to download a Web page upon receiving a request represented by a URL for that page from the field computer (13) to download two or more files comprising said Web page in response to said request, including at least one HTML file and at least one image file, to transpose the HTML and image files into a form designed for display on the field computer (13) and transfer the transposed data to the field computer (13).’

This proposed claim is dependent on claim 1 and so incorporates all the features of that claim. It is therefore a claim to apparatus consisting of hardware and software. The words ‘is adapted to’ just indicate a capability. If they did not, infringement would depend upon whether the object located by the URL had any image content, or was a single file. The system of claim 1 (whether amended or not) has this capability and no other way of accessing ‘internet servers’ is described. Down to the words ‘to transpose’, therefore, the claim is merely repetitive.

The phrase ‘to transpose the HTML and image files into a form designed for display on the field computer’ has no support in the specification. There is no description of any transposition of HTML into such a form. What the specification does disclose is in [0050] and [0051] (I repeat [0050] for convenience):

‘[0050] An ID match when connecting a hand-held unit to the Proxy-Server provides the Proxy-Server with information about the handheld unit, such as CPU type and power, screen size, type and resolution, presence of a pointer device, and sound capability. The Proxy-Server then uses this specific information to translate HTML and other files from the Internet to a form readily usable without extensive additional processing by the hand-held unit. For a small monochrome LCD display a 60k/70k JPEG file becomes a 2k/4k bitmap, for example. Also, multi-file pages are recombined into single file pages. This translation also minimizes bandwidth requirement for link 15, and speeds transmission of data.

[0051] It is in this ability of the Proxy-Server to do the heavy computing, of which the translation of HTML files is a single example, that is responsible for a unique ability of hand-held devices in practicing embodiments of the present invention to accomplish functions that they could not otherwise accomplish, and to do so without inordinate usage of stored energy….’

There is here no description of the nature of the transposition of HTML that is contemplated, save that the result is intended to avoid extensive additional processing in the handheld. I think that such a disclosure cannot support a claim that uses the phrase ‘a form designed for display on the field computer’ in which the emphasis is obviously not on the processing of the page but on the characteristics of the display. It cannot merely mean ‘suitable for’ or ‘capable of’ display on the field computer, because this feature would be satisfied by the system of claim 1, which already requires the image data to be transposed to match the specific size and resolution of the field computer. One might indeed wonder what the draftsman of claim 1A had in view when he introduced a superadded requirement that the image file be ‘designed for display’ on that computer.

I cannot find a clear meaning supported by the specification for claim 1A. The claim therefore offends against Section 14(5) of the Patents Act 1977. Section 14(5) must be read so as only to require that the specification should not contain claims that are not as clear to the skilled person and as concise as the difficulty and complexity of the subject matter permit. There is no one standard, and the requirement expressed by the section is closely connected with the requirement for sufficiency of description. Not only is a claim requiring the HTML to be transposed in response to some characteristic of the display of a computer (i.e. to be suitable for display on that computer) not supported by the description, but it follows that the invention set out in that claim runs the risk that it is not disclosed clearly enough and completely enough for it to be performed—what is the nature of the treatment of the HTML that is contemplated?

Section 76(3) of the 1977 Act prohibits amendments sought to be made to patent specifications after grant either in the context of infringement or revocation proceedings (section 75) or in the context of an application made for that purpose (section 27) if the amendment—

(a)

results in the specification disclosing additional matter, or

(b)

extends the protection conferred by the patent.

In determining whether an amendment to an application carried out before or after grant results in the specification disclosing additional matter, a convenient test is that of Bonzel v Intervention (No 3) [1991] RPC 553. The enquiry has three steps: (1) to ascertain through the eyes of he skilled addressee what is disclosed, explicitly and impliedly in the original application; (2) to do the same thing in respect of the application as amended; and (3) to compare the two disclosures and decide whether any subject-matter related to the invention has been added, whether by deletion or addition, this comparison being strict in the sense that subject-matter willbe added unless such matter is clearly and unambiguously disclosed in the application prior to amendment. The difficulties in applying this test nearly always arise from the difficulty in deciding whether particular features are disclosed as free standing aspects of the invention or only when in combination with other features. Claim 1A does not give rise to this problem.

Section 130(3) provides that ‘matter shall be taken to have been disclosed…in the specification of a patent if it was either claimed or disclosed (otherwise than by way of disclaimer or acknowledgement of prior art) in that…specification’, a provision emphasising that the function of the claims is to tell the skilled reader what the invention is. In the absence of a disclosure elsewhere in the specification of HTML being transcoded to a result that is designed for display on the field computer, this amendment would result in the specification disclosing additional matter. So it cannot be made. The same conclusion applies to all the ‘A’ series of proposed claims, and I shall not consider them further. This set of amendments must be refused.

It is inherent in claim 1 in its unamended form that the Proxy-Server ‘knows’ about the display characteristics of the field computer. Without that information, it would scarcely be able to match the specific size and resolution in transposing the data. An amendment is sought to make explicit the manner in which the Proxy-Server obtains this information. The Statement of Grounds for Amendment is not explicit, but it seems to me that the principal purpose of the amendment is to introduce a further distinction from ‘GloMop’. It raises an infringement issue. The words which the patentee wants to insert in claim 1 are underlined in this quoted passage from the claim:

‘characterised in that

upon connection, the field computer (13) transfers to the Proxy-Server (19) information particular to specific characteristics of the field computer (13) including information identifying the specific size and resolution of the field computer (13),

and wherein the Proxy-Server (19) downloads data comprising WEB pages and transposes the data in reliance on such information to match the specific size and resolution of the display of the field computer (13).’

This is not a matter on which the specification is silent. Material is to be found in [0021]:

‘In practicing the invention, one’s adapted personal computer is coupled to a Proxy-Server over a data link such as a telephone modem, and may, according to an aspect of the invention, transfer specific information, such as the type, size, and resolution of the personal computer’s display, to the Proxy-Server….’

In [0051]:

‘An ID match when connecting a hand-held unit to the Proxy-Server provides the Proxy-Server with information about the hand-held unit, such as CPU type and power, screen size, type and resolution, presence of a pointer device, and sound capability.’

In [0056]:

‘Connection to the Proxy-Server provides the Proxy-Server with information as to the subscriber and the subscriber’s equipment. These operations proceed in a manner well-known in the art for such log-on and security transactions.’

In [0066]:

‘At step 61 the user logs on by entering a user name and password and the field unit identifies itself with its ID. At step 63 the Proxy-Server compares the entered password and ID with stored records and derives a signature for the unit.’

In [0071]:

‘At step 101 the Proxy-Server converts all the .jpg files to a dithered bitmap format according to information associated with the user ID received from the hand-held at logon. This ID establishes the size and resolution of the hand-held’s display, for example, and the bitmap created from the .jpg files is scaled to the hand-held’s display.’

In [0073]:

‘…information relating to the field unit used by each subscriber is recorded at the Proxy-Server (or available to the Proxy-Server), and, upon connection, the Proxy-Server accesses this information, and uses it in transposing files for a particular unit.’

In [0077]:

‘…subscribers to a Proxy-Server system according to the present invention will provide[d] characteristics of their particular field units to the Proxy-Server, and the Proxy-Server will use the information in transposing files.’

Obviously there is support for the amendment in these passages, but it is suggested that on a proper construction the first underlined phrase does not cover a system in which (for example) the user enters the data directly at the field computer before using the Proxy-Server, even if the data is transmitted by the field computer to the Proxy-Server. In my view, this is wrong. In the preferred embodiment, no data relating to the field computer is transmitted to the Proxy-Server directly. Instead, a computer ID is transmitted by the NanoBrowser software, together with a password entered by the user. Characteristically the specification is not clear as to whether the ID is generated in some way by the software or whether it is entered by the user, the latter possibility being reasonably clear in Figure 3. The ID is used to obtain the characteristics of the field computer which are accessible to the Proxy-Server.

On the other hand, it seems to me that [0077], quoted above, is a general statement in respect of the invention, not the preferred embodiment, and makes it clear that the invention is indifferent as to how the Proxy-Server gets the relevant information, provided it gets it before it has to do any transposing.

In [0021], part of the general description of the invention, the following is said after the passage I have already quoted ([75] above):

‘The Proxy-Server may then browse the World Wide Web according to instructions received from the personal computer, transpose files downloaded from the Web into a form quickly and easily usable by the personal computer, and transmit the transposed data to the personal computer for display. Very large files may become fewer files, and much smaller files in the transposition.’

This passage does not suggest that one of the principal objects of the invention is to reduce a page to a single file, but a reduction in the number of files will involve running the information from at least two of them into one. The only other possibility is distribution of the contents of one file among more than one, but nobody suggested this as a realistic possibility, so I ignore it. [0050] refers to the combination of multi-file pages into a single file, in a context which, on consideration, I do not think is necessarily restricted to the preferred embodiment. It is not easy to tell. [0051] is certainly not restricted to the preferred embodiment, while [0049] certainly is.

It follows that the combination of two files into one is disclosed as a general feature of the invention, outside the context of the embodiment described with reference to Figures 3 and 4, in which the single file is disclosed as an ‘HT-Lite’ file. RIM suggested that the ‘B’ claims were an example of so-called intermediate generalisation, that is, products of the process by which a feature disclosed only in a specific combination with other features in the specification is lifted out of that combination and turned by the draftsman’s pen into an independent feature of the invention. Speaking generally, to limit a claim by reference to such a feature adds to the disclosure of the specification, for the reasons discussed in Bonzel v Intervention (above), and the problem of identifying such cases is the problem to which I refer in the discussion of that case.

Claim 1B is not on the face of it restricted to a single ‘single file’ for each page. I can see no reason to interpret it in this sense. I think that being a system claim all it requires is that the system be capable of combining image data, duly transcoded in accordance with claim 1, with HTML or some transcoded version of HTML in a single file. This adds nothing to what is already disclosed in [0021] and [0050]. I conclude the amendment is permissible.

It is clear that the specification uses the word ‘transpose’ and its derivatives loosely to encompass both the changing of the information content of a file and the stringing of files together for transmission to the field computer. There is no requirement for simultaneity. The words ‘during transposition’ are used in the sense ‘as one part of the process of transposition’.

There is no doubt, I think, that this feature is present in the corporate system—see [55] above.

Claim 1 requires the transposed data to be transferred to the field computer ‘in a TCP/IP format.’. The issue is whether this phrase means that the transport protocol between the Proxy-Server should be TCP running over IP, as RIM contend, or something else, since it is common ground that between the MDS-Server and the BlackBerry the transport protocol is not TCP.

RFC 1180 is the tutorial on TCP/IP to which I have already referred. In the words of RFC 1180, ‘The generic term “TCP/IP” usually means anything and everything related to the specific protocols of TCP and IP. It can include other protocols, applications, and even the network medium. A sample of these protocols are: UDP, ARP, and ICMP. A sample of these applications are: TELNET, FTP, and rcp. A more accurate term is “internet technology”. A network that uses internet technology is called an “internet”.’

It is common ground that between the MDS-Server and the BlackBerry handheld one element of the protocol stacks employed is UDP and IP. It is convenient at this point to describe how an HTTP response, which may include HTML or an image file is passed from a Web server somewhere on the internet to a BlackBerry handheld. The protocol stacks employed are depicted in the following diagram, in which horizontal lines denote packet headers that are unchanged by the apparatus identified at the top. Each stack denotes the process carried out in that apparatus. [redacted].

The story starts at the top-right-hand corner. The server program assembles an HTTP response, and causes a TCP connection to be opened to transmit the response to the MDS-Server. The TCP software layer breaks the HTTP response into segments, and packages each with the appropriate TCP header. Each segment is packaged into an IP datagram which passes over the internet to the waiting MDS-Server, identified by an address in the IP header. It passes up the right-hand-side of the MDS-Server stack: the segments of the response are extracted in the right order, having been retransmitted as required by the TCP layer, and passed to the client application software, where the data comprising the HTTP response is extracted. This is exactly what would happen in the browser if one were browsing the internet, but in this case, instead of processing the received HTML and images and displaying them, they are passed to the content transcoding software, where the HTML is ‘cleaned up’ and the images are scaled down in the way I have already described.

The data included in the response has now been transcoded and the application provides it with the appropriate topping and tailing for a response in a modified version of HTTP used by the BlackBerry browser software. [redacted]

[redacted]

The reverse path is much the same [redacted].

[redacted]

[redacted]

On the footing that the MDS-Server is the Proxy-Server for the purposes of the claim of the patent, the question is whether this amounts to transferring ‘the transposed data to the field computer via the data link in a TCP/IP format’. This phrase must be construed in context. In summary: from MDS-Server to Relay is TCP/IP: from Relay to BlackBerry is MDP/UDP/IP, the MDP layer providing reliability. Would the skilled man recognise this as a ‘TCP/IP format?

There are two transport protocols in TCP/IP: TCP and UDP. UDP adds very little, just four items (two port numbers, the packet length and a checksum), to basic IP. The port numbers are used for multiplexing transmissions to a single IP address, and the length and checksum are self-explanatory. It therefore does not offer flow control or retransmission upon receipt of a bad segment. But if the application software did for some reason offer those features, it would still be UDP/IP, but the result would work a little like TCP/IP. In other words, to provide flow control and error control and retransmission by some other technique does not prevent the transport protocol from being UDP/IP.

I have already said that I consider that the an important element of the context for interpretation of the claims is provided by the acknowledgment of, and description of, the ‘GloMop’ system in [0011] of the patent. There can be no doubt, as Professor Handley says, that GloMop does use TCP/IP for transferring data from the proxy to the handheld, but there is no easy way to see why this fact should limit the ambit of the phrase ‘a TCP/IP format’ if the skilled person would otherwise recognise it as having some wider import.

The reasoning appears to be as follows. GloMop is said to transfer ‘in a TCP/IP format’. It in fact transfers using TCP/IP. Therefore ‘in a TCP/IP format’ means using TCP. This is a bit like the red-headed man who was not a Scotsman: the major and minor premises have been transposed. There is a number of considerations to weigh up. First, as Professor Eisenstein was at pains to point out, and as is confirmed by paragraph 2 of RFC 1180 quoted above ([85]) ‘TCP/IP’ can be used compendiously to refer to the whole suite of protocols on which internetworks are based. The second is the rather odd use of the phrase ‘a TCP/IP format’ rather than something like ‘using TCP/IP’. If the inventor had shown that he really understood the details of the internet and its protocols, the web, and file manipulation, and if the specification had been written in clear technical language, I would give this consideration some weight but in this document one cannot draw inferences of this sort from what may be merely gratuitous pomposity in the use of language. Even the word ‘format’ is not quite right.

In the section of the specification relating to the preferred embodiments, there are a number of references to TCP/IP, in which reference is made to ‘pipes’ ([0030], [0045], [0094]) which certainly suggest that what is being talked about it is TCP, since the other transport protocol, UDP, does not establish an end-to-end connection. It is suggested in [0065] that an IP connection is made which ‘opens a port and establishes the connection’. This again is TCP–like behaviour. There can be no suggestion that the specification limits the sense of the term deliberately: it just does not contemplate the possibility of using the connectionless protocol UDP as the transport layer, because it could not be so used.

On the other hand, how is one to classify MDP? It is not an application level protocol: and as I read the diagram showing the protocol layers through the whole system (Figure 1) the IP addresses are changed when the IP address corresponding to a particular handheld is obtained not at the Relay but on entry to the particular carrier’s network at the appropriate Network Interface Adaptor, making MDP the only part of the protocol which actually records the information necessary to maintain a connection. But there is no doubt that MDP is not an application protocol: it is part of the transport protocol, although it is over UDP/IP.

RIM’s case is that although it employs a transport protocol which is in part a TCP/IP protocol, that is not the whole story. The skilled man would recognise this. Professor Eisenstein’s view, that UDP is enough, is based on a misconception. One must look at the transport protocol as a whole and, as he recognised, that is not part of the TCP/IP suite. Professor Handley also pointed out that it has features (such as the holding of datagrams at the Relay if the handheld is not within a carrier’s coverage) which do not have any counterpart in TCP. The division of TCP’s functions between IPPP and MDP I have already referred to.

I have found this a difficult problem, and my opinion has wavered. In the end, there are some additional matters that weigh with me. The first is that the specification only discusses any other form of connection than a connection to an ISP or directly to an internet gateway in the vaguest way: ‘cordless connections of various types’ in [0018], or ‘satellite link or cable modem’ in [0035]. Second, there is no indication in the patent that the inventor really considered the question of protocol between proxy and field unit in general, being concerned only with the ‘pipe’ TCP/IP connection in the description of the preferred embodiment. Third, why TCP/IP at all? There are other complete protocols, and the transcoding process removes all previous protocols—this one can be private. These factors do not encourage me to attribute to this feature anything more than as small a significance as it can reasonably bear: I see no reason to construe it restrictively. With some doubt, therefore, I think that the employment of UDP/IP between Relay and BlackBerry is enough, notwithstanding the use of MDP as an essential element in the transport protocol.

What follows is a summary of the product description. When an email is received at the corporate email server, the BES requests the email message body from the third-party email server in a plaintext format. The Microsoft Exchange server handles the conversion to a plain text message and this is requested by the BES from the Exchange Server via the standard MAPI interface irrespective of whether the email was received at the email server in a non-plaintext format such as HTML or Rich Text Format (RTF).

URL’s are represented using the same character set as plain text and do not require special formatting to be included in a plain text message. The Handheld software (not the BES) performs heuristic checks on the plain-text message to identify useful items such as URLs, phone numbers, and email addresses. These items are flagged by the Handheld software, thereby allowing the user to select the item and perform a predefined action with the selected item. If a URL is identified in the plain-text message, the user is given the option of invoking the Handheld Browser and using the URL to retrieve the web page.

Email bodies are not transposed. The system downloads emails more or less in real time, as I have indicated, without included images, whether apparently in line or as attachments. Images are requested from the email server as required. Certain other attachments (Microsoft Office files and PDF’s) in downloaded emails are maintained on the so-called attachments server. The downloaded emails contain tags which, if clicked, will cause transcoded versions of attached images or other documents to be sent to the handheld. These files are not combined with each other or with the email text itself. PDF’s and Office files are converted to a format called UCS (for Universal Content Stream) and sent to the handheld in 3kB chunks when requested by selecting a displayed tag. Images are converted to jpeg form and encapsulated in a UCS file, the whole of which will be downloaded.

The BES reduces images using the x and y dimensions of the handheld’s screen sent to it as part of the request for the image sent by the Attachment Viewer software. It seems that the algorithm for reducing the images is slightly different: either the horizontal dimension or the vertical dimension is scaled to the horizontal or vertical dimension of the screen, whichever scale factor is the greater, and the other dimension scaled by the same factor: the result is that the scaled image is never larger than the screen.

Finally, if the attachment is an HTML file containing images, the attachment server will return a plaintext version of the HTML without the images. These will be replaced by a URL link, and downloaded only if the link is selected. The images are handled by the MDS-Server.

For the reasons I have given I will not consider any of the ‘A’ claims further.

The web-browsing capability means that the system infringes claims 1 and 1B, 2 and 2B. The MDS would infringe claims 7 and 7B, 8 and 8B if located within the jurisdiction. These conclusions extend to the amended versions of claims 1 and 7. The method claim 11 is infringed. Claim 12 is infringed since, although information relating to resolution is not transmitted, I interpret this feature in the way I describe in [65]. Claim 13 may be infringed, depending on whether browsing commands entered into the BlackBerry are ‘used’ to browse the web by the MDS. But the claim is hopelessly invalid for reasons I will explain, and I will not consider this issue further.

So far as the email service is concerned, claims 1 to 7B are all concerned with web pages and have no application to email. None of the claims referring to combination of separate files into a single file is infringed. This leaves claim 8, which is infringed, as is claim 11. Claim 12 is also infringed, for the reason already given. Claim 13 is not infringed, being concerned with browsing.

It is accepted that such variants as there are between the details of the implementation of the BIS-Browsing, and I believe also the BIS-Email, systems and the corporate system are immaterial to the questions of infringement, and so the conclusions are the same.

Validity is challenged on the grounds of anticipation or obviousness in the light of three publications referred to as ‘GloMop’, ‘Pythia’ and ‘Mowser’, and obviousness in the light of a fourth publication called ‘Bartlett.’ Insufficiency is pleaded in respect of the phrase ‘reducing information density’ or ‘accomplishing information density reduction’, which it is said is vague and uncertain. Finally, it is pleaded that the patent discloses no technical means for accomplishing either information density reduction or transposition either in general or in accordance with characteristics of the display. From this it is said to follow that the invention is said to be inherently unpatentable because it is incapable of industrial application, and to consist of a computer program as such and a method of displaying information, which are subject matter excluded from patentability. The objection of incapability of industrial application is not persisted in, but the objection to the subject matter of the claims is said to lie in excluded matters.

A claim lacks novelty if it covers something that formed part of the state of the art at the priority date. A claim is obvious if it covers something obvious in the light of any matter forming part of the state of art at that date. The distinction between novelty and obviousness is clearly described in General Tire v Firestone [1972] RPC 457 at 485 line 24–486 line 15. There are two aspects to an allegation of anticipation: for a prior documentary disclosure to anticipate, it must both disclose the invention and enable the skilled man to perform it. In cases of anticipation by inevitable result, the prior art discloses those things which, if the skilled man does them, will fall within the claim. But enablement must be of something inevitably within the claim. If the skilled person is given a target, in the shape of a disclosure of the invention, the law of enablement permits reasonable experimentation, error correction and so on while yet holding that the prior disclosure is enabling. If the only target the skilled man is given is a course of action, then following that course of action must inevitably result in something within the claim, and there is no space for experimentation except in getting what is disclosed to work on the prior document’s own terms. In the classic case, Flour Oxidising v Carr (1908) 25 RPC 428, the question of anticipation depended upon the type of electrical discharge in a region of certain apparatus where flour was bleached. No doubt the skilled man was allowed to experiment so as to produce an electrical discharge in accordance with the teaching of the prior document, but the effect of any electrical discharge would have had to fall within the claim. The most recent case on the topic, Synthon v SKB [2005] UKHL 59, is a case in which a disclosure of incorrectly characterised crystalline material was held to anticipate on evidence that in fact there was one crystalline form and the skilled person would be enabled to crystallise the material, because the anticipating disclosure was the disclosure of the crystalline material.

The teaching of the specification, once construed, is a pure question of fact, as is what the skilled man would do with that teaching without the exercise of inventive ingenuity. Obviousness can be approached by the application of the analysis in Windsurfing v Tabur Marine [1985] 59 at 73 line 45–74 line 5, which does not require further exposition here and which I shall apply.

“GloMop’, as its first page says, is an acronym for Global Mobile Computing by Proxy. The paper was published on 13 September 1995, seven months before the priority date of the patent, 10 April 1996. In its opening section it states the problem with which it is concerned:

‘Mobile computing and the Internet are two of the most rapidly growing areas of the computer industry. However, unlike desktop workstations in a conventional wired WAN environment, today's mobile devices are typically limited to kilobits-per-second connectivity using conventional (wired) or cellular modems and, in some cases, satellite relays. Existing bandwidths are inadequate for Internet surfing, and will be inadequate for generalised multimedia information retrieval applications. Network bandwidth, especially for wireless networks, is simply not pacing advances in processor speed.

How can applications deal with the bandwidth, memory, computational, and power constraints of a mobile computing device?’

This is a statement of much the same problem as that with which the patent is concerned. I say ‘much the same’ because the patent does not emphasise bandwidth constraints to the same extent. Indeed, GloMop proceeds on the footing that the main problem affecting mobile computing, at least so far as the ‘subnotebooks’ then available are concerned, is not lack of computational power but low bandwidth network connections. With smaller devices, of course, the problem is computing power, and the perception of the problem is very similar to that of the patent:

‘We can make mobile devices of all kinds useful to a much wider audience by isolating the devices from poor networks. In current usage, a mobile device connects directly to a resource of interest (web page, mail inbox, etc.) using a low-level stream protocol (typically, TCP/IP running over Ethernet or over a modem using SLIP or PPP (Footnote: ²)). These protocols were designed without specific regard for bandwidth, for example, every HTTP request results in a setup and teardown of a new TCP stream, which fails to amortize TCP'S considerable overhead, and documents requested by HTTP are transmitted in source form, even though the requesting machine may not have the resources to render the source document (lack of memory, lack of computing power, or a small screen). As a result, Web surfing is extremely painful at 14.4Kbits/sec.’ [author’s emphasis]

The solution proposed is to interpose a proxy between the mobile unit and the web and to communicate with the proxy using a protocol different from HTTP.

‘Under the GloMop model, however; the client connects not to a particular service, but to a proxy process running at a well-known location. The proxy is running on a server or is distributed among servers that are well connected to the desired data, either because the data is at the site or because the site is well-connected (i.e. an order of magnitude better than the client-proxy connection) into the Internet. For UC Berkeley, most data is reachable at 8 Mbps, which is more than 200 times better than a 28.8 modem connection. Although the connection to the proxy is made on a reliable stream such as TCP, the requests and data transmitted on that stream are quite different from what would be transmitted using (e.g.) HTTP directly.’

This is the introduction of what the patent calls transcoding. The second idea introduced by GloMop has a dual aspect: the distillation and selective refinement of requested documents. Distillation is described in these terms:

‘Simply put, distillation can be thought of as lossy compression that preserves enough semantic information to make a document useful while making the document drastically smaller and easier to render on the mobile client, and possibly exploiting the document's semantic structure. Illustration by example is best:

Example: Graphic image. We can reduce the area or the color palette or both for a large full-color graphic. For example, we reduced an 8-bit-color, fall-screen (VGA) GIF image to a thumbnail-sized 4-gray image for display on a Sony MagicLink PDA. In so doing, we reduced the image's size from 503 Kbytes to 560 bytes, and the transmission time (including real-time distillation) from 2,000 seconds to 13 seconds at 1200 baud. Furthermore, because our image processing included optimal quantization to the PDA's (static) graymap, the resulting image was much sharper on the PDA screen (and therefore more useful to the human viewer) than the dithered original, so we actually increased the perceived image quality while reducing the size a thousand fold.

…

In summary, distillation exploits large amounts of computing power on the proxy side to maximize the client’s limited computing and network resources, by performing intelligent semantic compression in a datatype-dependent way.’

There was a considerable debate about the significance of the phrase ‘smaller and easier to render on the mobile client’. ‘Render’ in this context means ‘display’. RIM’s case, supported by Professor Handley, is that these words reveal a concern with the hardware on which the image is to be displayed. After all, they say, what is suitable for display on a Sony MagicLink is not necessarily suitable for display on all machines, particularly using a 4-level grayscale. Professor Eisenstein did not accept this contention.

The last sentence merely says that different types of data—PostScript pages and images are two of the examples—are dealt with according to their nature.

The manner in which GloMop goes about this took up a considerable amount of time at the trial. The way it goes about it is to provide a collection of services for writers of application software. As the writers of GloMop say, they want to make the task of people writing applications for mobile clients easier and the way they do it is to provide an API, or Application Programming Interface. The way in which a client application uses the defined interface is described in part 3.3 of the paper:

‘When the client connects to the proxy, it registers a list of data types it is prepared to accept. Note that since the datatype specific modules reside in the GloMop client layer and not in the individual applications, this single list can apply to all requests regardless of the originating application.

To request a document, the client passes the proxy a document locator, specifying how the source document may be retrieved, and a set of QOS parameters, specifying which constraints are most important to the client. The proxy retrieves the source document, determines its type, and locates a type-specific module (TSM) consistent with the registered type list to handle the request. The TSM negotiates with the network management layer (NM) to determine how to distil the document for this client given the QOS parameters, which may encode a constraint such as "Deliver the best representation possible while keeping the transmission time under 30 seconds" or "…while keeping the Mission cost under $5.00".’

The sorts of properties of the connections which it is contemplated that the client software may wish to implement are set out in section 3.1 where it is explained that it should be possible for the client application to delegate management of any property to the network software. The example it gives is important. It suggests that ‘in the case of changes in bandwidth, the client application might choose to let the network software decide how to perform distillation to utilize bandwidth most efficiently, rather than making explicit distillation decisions for each document accessed remotely.’ I understand this to disclose a system in which distillation, i.e. lossy compression, decisions are made not on a document by document basis but on the basis of the type of document alone.

The system is ‘document centric’ in that the client requests documents (section 3.3) and the proxy includes software modules (the TSM’s referred to in the quotation above) to process different types of documents requested (section 3.2), which are abstracted as type-specific ‘pipes’: a jpeg file is poured into one end of a ‘pipe’, and a distillation appropriate to the various properties of the connection is carried out. It was suggested that GloMop does not take account of Web pages, and that its application to the web is an unjustified extension of its teaching. This is surprising, first because one of the things which interests the authors is the undesirability of using one TCP connection per HTTP request (see section 3.2, where reference [13] is to a paper referred to at trial as Padmanabhan). Second, a stated purpose for the application-level API proposed in GloMop is to shield applications from having to replicate common functions, such as HTTP functionality in browsers (paragraph 1.4 section 1) written for different platforms. Third, the clear implication from the text below table 1 quoted above in [114] above is the web surfing is to be made less painful at 14.4 Kb/s.

Finally, the sort of properties that will determine the type of distillation to be carried out are those listed in section 3.2, the determination being performed either by the application software or automatically by the network software. These properties are mainly network-orientated: the authors are not worried so much about the size of the mobile screen as by the time taken to load documents over the network and the expense of doing so. The result, of course, is the same: in both cases one shrinks an image, because a smaller image takes less time to transmit. They also recognise that the client machine may have its own constraints, at least to the extent that they recognise that the client has both limited computing resources and limited network resources (section 1.3, quoted above).

As Professor Handley accepted under cross-examination, the degree of distillation will be affected by the quality of the network (transcript 303 line 20 – 306 line 24). But, as the example from section 1.3 quoted above shows, this is not the whole story. Part of the distillation process contemplated for images includes conversion from colour to grayscale in an appropriate case. Obviously a reduction in size and colour has a dramatic effect on file size: this meets bandwidth constraints.

Finally, GloMop clearly discloses the supply of information concerning the mobile computer to the proxy-server in the first paragraph of the passage quoted at [119] above. Furthermore, it negotiates suitable treatment for a particular document as required. In drawing a contrast with another system, called Odyssey, GloMop says this in section 1.8:

‘The difference between Odyssey and GloMop is best characterized as static vs. dynamic. In Odyssey, the server must explicitly store multiple representations of a document, and deliver a specific version requested by the client. In GloMop, the server can retrieve a source document from anywhere on the Internet, negotiate an appropriate representation with the client, and perform the required distillation, all in real time.’

It is this passage, taken with what Professor Handley says is a clear concern with the hardware characteristics of the mobile, that forms the basis of the attack of obviousness based on this document. If one is to negotiate an appropriate representation with the client, and if a relevant characteristic of the client is its screen size, then is it not obvious, the argument goes, to provide screen size to the server and negotiate accordingly?

Finally I should turn to a specific aspect of the GloMop disclosure. Consider a client that has no sound capability. It will register a list of datatypes that it is prepared to accept (section 3.3), and this list will not include sound. Now suppose that the client passes a document locator to the proxy that identifies a sound file. While there is no explicit description in GloMop of simply ignoring a file altogether in the process of distillation, RIM say that it is either intrinsic to the system described in GloMop, or very obvious that no Type Specific Module will be lined up to handle the request, because that is the point of telling the proxy that the mobile computer cannot handle sound. So no sound file will be sent.

I am satisfied that there is no explicit description in GloMop of any matching to screen size. Claim 1 and the claims dependent upon it are not anticipated. Claim 2 merely requires information density to be reduced in accordance with specific characteristics of the field computer. The sound example ([126] above) is very close to anticipation of claim 2. Perhaps it is saved by the failure of GloMop explicitly to say that the purpose of registering datatypes was so that data not on the list would not be distilled and sent to the mobile. This was certainly the view of Professor Eisenstein, who appeared to consider that not to send files to computers which had previously announced that they had no use for them was not obvious:

I do not think that Professor Eisenstein’s approach is an acceptable approach to the document. As ever, the question is what is explicitly disclosed and what also is necessarily implicit in the teaching. The skilled man must be taken to read documents in an intelligent way, seeking to find what is disclosed as a matter of substance. In GloMop, there must be a purpose to registering those datatypes that the mobile is prepared to handle: it is to avoid data of the other types being sent, and so reduce network overhead in sending data which must be discarded by the recipient. I think that this is implicit in the process of registration of datatypes: datatypes are registered so that data of the specified type will be distilled by the Type Specific Module.

If therefore the mobile does not register images or sound as acceptable datatypes, it should not receive them. That is plainly the purpose of registration of datatypes, so plainly that it does not need to be stated. I consider that this disclosure anticipates claim 2. Claims 8 (to the server), 11 (the method of adapting files) and 13 (Web browsing method) are equally clearly anticipated.

Finally, it is not in dispute that GloMop is very concerned with the ability of its mobiles to exploit the limited network between them and the server to their best advantage. It discloses variable optimum distillation for a given mobile, having regard to considerations such as ‘keep the transmission under 30 seconds’ or ‘keep transmission cost below $5’. For this purpose, network characteristics are collected by the proxy (section 3.2) and used to predict the cost of retrieving a given document in both minutes and dollars. Network costs, and the possibility of reducing bandwidth to reduce power, are services that are proposed for the API (section 3.1). A great deal of Professor Eisenstein’s evidence was given on the footing that these so-called quality of service (QOS) parameters were the only thing which passed from mobile to proxy, but I believe I have demonstrated that this is incorrect.

I turn to the objection of obviousness in the light of GloMop.

The inventive concept of the patent in suit is on the face of it what is specified by the claims, freed from any prolixity, obscurity and meaningless characterisation of the kind described by Laddie J in Raychem’s Patents [1998] RPC 31. In the present case, there is a degree of prolixity and repetition, but it seems to me that the heart of the underlying inventive concept lies in the method defined in claims 11 and 12. It is common ground that the skilled person would have no difficulty in constructing apparatus and in writing programs to perform these methods. Once the skilled person knows what needs to be done, he has no difficulty in doing it, and so the natural place to look is at the method claims. The apparatus features of the claims do not, in themselves, add much to the discussion. These are the method claims:

‘11. A method for adapting Internet files for a field computer (13), comprising steps of:

(a)

downloading files from the Internet to a Proxy-Server (19);

(b)

transposing the files by accomplishing information density reduction;

(c)

transferring the transposed files to the field computer (13) over a data link (15) connecting the field computer (13) to the Proxy-Server (19);

characterised in that

in step (b), information specific to the connected field computer (13) transferred to the Proxy-Server (19) from the field computer over the data link connecting the field computer to the Proxy-Server is used in transpoing the files.

12.

A method for adapting Internet files for a field computer (13) as claimed in claim 11, wherein the information specific to the field computer (13) comprises display type, size and resolution.’

If I am wrong about anticipation by the disclosure of GloMop’s ‘acceptable datatypes’ feature because rejection of unacceptable datatypes, and so reduction of information density, is not explicitly disclosed, then it seems to me to be clearly obvious. Although I have not discussed it in the section devoted to novelty in the light of this disclosure, it seems to me that refusal to send requested files which are useless to the handheld, or which it simply does not wish to receive, is plainly a reduction in information density. The evidence for non-obviousness given by Professor Eisenstein appears in this exchange, which follows directly from the one above (transcript 481-2):

It was never explained what would lead the skilled person away from a system in which files unacceptable to the recipient were not sent. There is no technical impediment, as the Professor ultimately accepted. I think that the ‘teaching away’ argument depended largely upon the perception that GloMop’s solution was a solution to problems of the underlying network. The weight of the evidence was that it was a system for data manipulation to take best advantage of the underlying network, having regard to the qualities (at least acceptable data types) of the mobiles. Professor Eisenstein’s comment about GloMop in [96.6], that GloMop does not hint at ‘how to customise data for the specific devices in a multi-device network’ is wrong.

I conclude that the inventive concept of claim 11 differs from GloMop (if at all) only in a possible failure fully to disclose what is to be done with files the data type of which is not registered on connection with the proxy. It is plainly obvious not to send them. So claim 11 is obvious over GloMop.

The obviousness argument went further. Professor Handley saw in the ‘thumbnail’ sent to the Sony MagicLink PDA and in the registration process a clear indication that distillation included accommodation of at least the colour characteristics of the screen, which would have to be conveyed to the proxy during the registration process ([201] of his first report), or at least that it was obvious to do so having regard to the result that is said to have been achieved. He said that this could only be done if the server knew about the colour-rendering abilities of the mobile. The GloMop designers may well have taken a decision always to reduce their images to the same size and colour palette, relying upon the refinement ability of the system, which is not really described, to enable the user to obtain a better version of anything he wanted.

The difference between the inventive concept of claim 12 of the patent and the disclosure of GloMop therefore lies not in conveying information about the receiving machine to the server on connection, but in the information that is sent. If GloMop discloses the general idea of conveying to the server the classes of file that the mobile cannot deal with at all, does it make the idea of telling the server how well it can deal with images obvious, given that an example is given of an image in fact matched in colour palette to the screen of a particular PDA? Intrinsic to this question is the matter of matching to size: there is no point in conveying size information if it is not to be used.

I have found it difficult to make up my mind on this. I have not been assisted by Professor Handley’s carefully expressed reasons for saying it was obvious on the one hand and Professor Eisenstein’s argumentativeness and occasional truculence (both displayed in the quotation from the transcript above) on the other. I find Professor Handley’s suggestion that it is a natural progression from the ‘one size fits all’ nature of a fixed size thumbnail to provide something which allowed different users better to exploit the variety of display devices that are listed in GloMop very attractive, the more so since a very efficient, complex and sophisticated display system very widely used in universities in 1995, the X Window system, accommodated many different displays by being told their size, in pixels, their colour depth and so on. In structure, though, X is very different from what is being talked about here. The essential difference lies in this: programs written for X do not care about the display. They communicate with a program, of which there is effectively one per screen, called the Xserver. The Xserver uses the information given to it about the screen to which it is connected to produce the best display of the output of the program, regardless (within reason) of the qualities of the display. I am satisfied on the evidence that X Windows was sufficiently widely used at the priority date for at least this sort of knowledge to be common general knowledge. But I do not think it is relevant. There are parallels but not of the sort that can affect a conclusion on obviousness.

With some doubt, I conclude that the argument of obviousness based on screen size/resolution, and hence matching, fails in relation to GloMop.

Pythia is a series of documents that reproduce a small website, or part of a website. The first two pages introduce what is stated to be a GloMop technology demo. Under the heading ‘Try a GloMop Technology Demo!’ the user is invited to use a conventional browser (ie using HTTP) to see the demonstration. The second division of this page, immediately above this heading, is ‘Index: Overview | Demo | Software | Papers | People | Local Info’ which appears to be a row of links. We have the section labelled ‘Overview’ at page 3, that labelled ‘Demo’ at page 5, and a section labelled ‘Pythia/GloMop HTTP Proxy Registration’ at page 10. Pythia appears to be the name of the demonstration Proxy server, I suspect because she answers the questions posed by the user’s browser.

This document does not cross-refer to GloMop in a way that makes it permissible to read them together.

The following passages are relevant, first from the overview.

Protocol negotiation: We used a hack based on munging HTTP addresses to implement the

Sizes and color depths of distilled images: Areal GloMop client will negotiate a

Types of documents that are distilled: In this demo, only GIFsand JPEGS are affected, but a

Proxy host: A real GloMop proxy can be hosted on a network of workstations (such asthe