England and Wales High Court (Patents Court) Decisions

IN THE HIGH COURT OF JUSTICE
CHANCERY DIVISION
PATENTS COURT

		Royal Courts of Justice Strand, London, WC2A 2LL
		2nd February 2006

Mr Justice Pumfrey :

Introduction

1. 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.
2. 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.
3. 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.

The Experts

4. 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.
5. 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.
6. 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.
7. 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.'

8. 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.
9. 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.

Technical Background

10. 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.
11. 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.
12. 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.
13. Conventionally, TCP/IP can be viewed as a 'stack' of protocols^[1]. 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.
14. 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.
15. 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:



16. 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 and tags delimit the clickable link, the href attribute is the page that will be fetched if you click on it, and the tag includes the image, with its filename. The alt attribute is what will be displayed if the image is not available:



17. The 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.
18. 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.
19. With the foregoing brief introduction I can turn to the patent.

The patent in suit

20. 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.'

21. 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.
22. 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.'

23. 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.'

24. 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.'

25. [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.
26. [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.'

27. 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.
28. 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.

i) The user 'logs on' to the Proxy-Server ([0063]-[0067]. During this process, data about the user's device (I shall call it the PDA) is made available to the InterBrowser software, which is a full-featured browser that does not display the pages it downloads, but processes them for onward transmission. This so-called signature ([0066] line 40, [0071], [0073] and [0077]) appears to be stored on the Proxy-Server, but in any event it can plainly be transferred at any time before it needs to be used.

ii) The user composes the URL to which he requires access on the PDA using a program called the 'NanoBrowser' ([0046], [0068]). This program is nowhere described, but it may be taken to be a browser like Mosaic or Netscape, but adapted for use with the simpler protocol and 'transposed' data used in communication with the Proxy-Server;

iii) The InterBrowser running on the Proxy-Server interprets the request received from the PDA [0069]. The InterBrowser has all the functionality of a normal browser, but does not display the downloaded pages;

iv) The InterBrowser seeks the requested page. Since pages usually contain at least one image, normally it will download at least two files [0070]. Image files (for example JPEG files) will be converted by the InterBrowser to a bitmap format.

v) Using the information associated with the user's identity logged on, which establishes the resolution of the PDA's display, for example, the bitmap is scaled to the PDA's display [0071].

vi) The page requested, together with included scaled images and so on is assembled by the InterBrowser into a single file in a language called HT-Lite. HT-Lite is nowhere described but it seems to be a little like HTML, in that it permits clickable links and text input fields ([0046]) but includes all images, scaled as I have indicated, in one file. It is referred to as a protocol in [0046] but this seems to be an error, unless 'HT-Lite' is being used to refer both to the file format and to the protocol for its transmission.

vii) The single file is sent to the PDA. The manner in which the data is sent relies upon an open TCP/IP pipe between the Proxy-Server and the PDA which is opened when the original request is transmitted and remains open ([0045]) but no protocol is described.

viii) The NanoBrowser software receives the HT-Lite file and displays it ([0072]).

29. 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.'

30. 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.
31. 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).
32. The structure of the claims is as follows.

i) Claims 1 and 2 are claims to computer systems including both a Proxy-Server and a field computer. They have the same precharacterising portion, and the characterising parts match [0012] and [0013]. It should be noted that claim 2 is not limited to transposing data to match specific size and resolution of the display of the field computer, but to incorporating any information in respect of characteristics of the field computer in transposing data.

ii) Claims 7 and 8 are claims to Proxy-Servers alone. The substance of the claims is identical to claims 1 and 2, and I will not consider them separately. I cannot conceive how these claims could be supposed to survive a successful obviousness attack on claims 1 and 2.

iii) Claim 11 is a method claim, as is claim 12 which is dependent upon it. These claims raise slightly different issues.

iv) Claim 13 is an independent method claim, but seems to me to raise no distinct issues.

33. 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'

34. 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).'

35. The scheme of the amendments is as follows:

i) Amended Claim 1 has the additional requirements that there should be transfer of the information concerning the specific size and resolution of the display of the field computer "upon connection" and that the transposition of data by the proxy server is undertaken "in reliance on such information", which I take to include the specific size and resolution of the field computer's display;

ii) The "A" claims (1A, 2A, 7A, 8A 12A and 13A) can be considered together. They are said to provide the additional feature that the field computer sends a single request in the form of a URL and receives from the proxy server a customised Web page incorporating at least one HTML file and at least one image file in return. In fact, no other method of obtaining a page other than sending a single URL by the field computer is disclosed or suggested. So far as the apparatus ("system") claims are concerned, the amendment must relate to a capability: thus the systems must be capable of transposing both HTML and image files when called upon to do so. This amendment is poorly drafted, and raises a question about what is meant by "transposing an HTML file…into a form designed for display on the field computer" when the claim also requires that the transposition be to "match the specific size and resolution of the [display of the] field computer";

iii) The "B" claims (1B, 2B, 7B, 8B, 12B, 13B) are said also to be capable of being considered together. They provide the additional feature that during transposition by the proxy server HTML and image files are assembled into a single file for transfer to the field computer.

36. 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.
37. 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.
38. (a) The meaning of the following phrases:

(i) "in a TCP/IP format" (claim 1)

(ii) "specific size and resolution of the display" (claim 1)

(iii) "transposes the data to match to the specific size and resolution of the display of the field computer" (claim 1). In particular, whether matching has any precise meaning at all.

(iv) "Upon connection, the field computer transfers to the Proxy-Server information particular to specific characteristics of the field computer" (amended claim 1, claim 2)

(v) "single file" (claim 1B)

(vi) "during transposition, HTML and image files are assembled into a single file for transfer to the field computer" (claim 1B)

(vii) whether the B claims cover a single file made up of an un-transposed (using specific characteristics of the field computer) html file and a transposed image files.

(viii) "downloading files from the Internet to a Proxy-Server" (claim 11)

(b) 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).

INFRINGEMENT

39. 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.
40. 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.
41. 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.
42. The central issues of fact are

i) How the BlackBerry system, both corporate and Prosumer, treats web pages generally;

ii) How the BlackBerry system treats images contained in web pages;

iii) How the BlackBerry system treats email attachments consisting of images; and

iv) What protocol is used to serve web pages and images to the BlackBerry device.

43. The corporate system is depicted in the System Description thus:



The components shown to the right of the corporate firewall, which itself will consist in general of both hardware and software, are essentially items of software. They may reside on the same or different machines. That does not affect any of the issues. The machines belong to the organisation that has purchased the system.

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

i) The handheld is the BlackBerry device itself. It is a compact computer with an LCD screen, which may be colour or monochrome according to model.

ii) The Relay is a collection of equipment which manages the routing of data from the servers on wire-connected networks to the wireless-connected handhelds. The manner in which data is transmitted from the Relay to the handhelds depends upon the wireless service provider.

iii) The Dispatcher is software that takes data from the MDS-Server (Mobile Data Server) and BES and forwards it to the Relay. The protocol used is called the "Service Relay Protocol".

iv) The MDS-Server receives requests for web pages from handhelds that are configured to have this capability, that is, that have a browsing capability. The MDS-server requests the Web pages from the WWW or from a corporate intranet, as appropriate. The MDS-Server processes the pages received into a form more suitable for the handheld, but removing certain tags from the HTML and by scaling images.

v) The BES (BlackBerry Email Server) is an email redirection server. It uses so-called server push to provide emails more or less as they are received by the corporate email server to the appropriate BlackBerry provided it is switched on and connected to the wireless network. This provides a real-time email delivery facility at the handheld device. As I understand it, the BES is integrated with the entreprise's email servers, either Microsoft Exchange or Lotus Domino.

vi) The attachment server processes the attachments to emails.

45. 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.
46. 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.
47. 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.

Use of the MDS-Server to browse web-pages

48. 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.
49. 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.
50. 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 tag is also removed, because the BlackBerry handheld does not acknowledge font changes.
51. Image content (eg. identified by the 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.
52. 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.
53. 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.
54. 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.
55. 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.
56. 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.

Issues 1(ii) and (iii)—matching the specific size and resolution of the display

57. 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.
58. 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.'

59. 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].
60. 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.'

61. 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.
62. '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'.
63. '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.
64. 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.
65. 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.
66. 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.

Claim 1A

67. 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.

68. 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….'

69. 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.
70. 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?
71. 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.

72. 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 will be 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.
73. 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.

Issue (iv): telling the Proxy-Server about the field computer

74. 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).'

75. 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.'

76. 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.
77. 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.

Issues (v), (vi) and (vii)—single file during transposition

78. 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.'

79. 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.
80. 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.
81. 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.
82. 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'.
83. There is no doubt, I think, that this feature is present in the corporate system—see [55] above.

Issue (i)—how the file gets from the Proxy-Server to the handheld

84. 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.
85. 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".'
86. 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].
[figure redacted] Figure 1: protocols between BlackBerry and the Web
87. 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.
88. 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]

(1) [redacted]

(2) [redacted]

(3) Then TCP/IP, which is used for reliable communication between the MDS-Server and the Relay.

89. [redacted]
90. The reverse path is much the same [redacted].
91. [redacted]
92. [redacted]
[Figure redacted] Figure 2: Protocol overhead on BlackBerry side of Relay
93. 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?
94. 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.
95. 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.
96. 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.
97. 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.
98. 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.
99. 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.
100. 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.

Emails in the corporate system

101. 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).
102. 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.
103. 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.
104. 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.
105. 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.

Conclusions on infringement by the corporate service

106. For the reasons I have given I will not consider any of the 'A' claims further.
107. 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.
108. 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.

The 'Prosumer' service

109. 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

110. 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.

Anticipation and obviousness—law

111. 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.
112. 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

113. "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?'

114. 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^[2]). 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]

115. 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.'

116. 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.'

117. 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.
118. 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.
119. 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".'

120. 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.
121. 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.
122. 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).
123. 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.
124. 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.'

125. 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?
126. 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.
127. 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:

< 8> Q. Right. And if it did not handle sound for hardware reasons or

< 9> software reasons, the proxy would strip out sound.

<10> A. Excuse me, sir, it does not say that in the paper.

<11> Q. No, but you agree it would be obvious to .... There is a law

<12> of obviousness in this country, professor. That is what I am

<13> asking about. You agree it would be obvious to register,

<14> "I cannot handle sound," and having registered that, surely

<15> you agree that the proxy would therefore strip out sound.

<16> That is as obvious, as straightforward, as could be. It

<17> requires no inventive spark whatsoever.

<18> A. I do not agree with you.

128. 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.
129. 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.
130. 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.
131. I turn to the objection of obviousness in the light of GloMop.
132. 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.'

133. 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):

<20> A. Why? Because as I am reading this paper, you are asking me

<21> obviousness in light of reading this paper without having seen

<22> the patent. I read this paper and I am led in a certain

<23> direction. You know, it becomes much more obvious when I read

<24> the patent and I think to myself, "That is a good idea, that

<25> should have been obvious to me, or would have been obvious if

< 2> I had known this." The thing that I have been trying very

< 3> hard to do is to put myself in the position of the skilled man

< 4> that would be reading this paper at the time without having

< 5> seen the patent. I am led in different directions. This

< 6> entire paper teaches me away from that kind of thing. Once

< 7> I read the patent, I can now go back and sort of look at these

< 8> things and pick out words here and there that say, "Yes, that

< 9> would lead me in this direction," and of course it seems

<10> obvious right now but that is because we have all read the

<11> patent and we know what the suggestion is. The inventiveness

<12> does not have to be complicated. It could be the very simple

<13> idea of just understanding that this is a way of going.

<14> Q. It would make no sense, professor, for the proxy to send

<15> a sound file if the remote computer had registered, "I cannot

<16> accept sound." Do you agree that?

<17> A. I do not .... I cannot agree with that. The reason I cannot

<18> agree with it is because there has to be context for the word

<19> "obvious". I have to have a starting point. Of course it is

<20> obvious now. If you are asking me what my opinion is right

<21> now, of course it is obvious. I would not have done that.

<22> That is not, as I understand it, the way in which we are

<23> supposed to read these papers and the way in which I was

<24> supposed to render an opinion to the court.

…

< 7> Q. I am just asking you. You have a set up where the remote

< 8> laptop, whatever it is, is accessing the Internet through

< 9> a proxy. It is registering data types that it is prepared to

<10> accept and it indicates that it cannot accept sound. Is there

<11> any technical reason why the proxy would not take out the

<12> sound?

<13> A. The answer is, in the context of this paper, one would develop

<14> another TSM, assuming that that was something you were

<15> thinking of as they define it, in the context not of this

<16> paper. You would have to write another program for the

<17> Proxy-Server to look at the file and strip the sound files

<18> out.

<19> Q. So there is no technical reason why you would fail to take the

<20> sound file out?

<21> A. Yes, I would .... I mean, I do not know about the technical

<22> reason, but ----

<23> Q. No - technical reason. Do not start giving a different

<24> reason. Is there any technical reason?

<25> A. I am sorry, Mr. Watson. The question, is there no technical

< 2> reason that we could not do it, no. The fail to do it means

< 3> that you are putting a motivation on it and that makes it more

< 4> difficult to answer. If you are asking me from a technical

< 5> point of view, then the word "fail" is a humanistic or a human

< 6> characteristic.

< 7> Q. OK, take "fail" out; it was a bad word, I agree. Do you agree

< 8> that there is no technical reason for the proxy not to take

< 9> into account the fact that the remote cannot receive sound and

<10> as a result not sending sound? There is no technical reason

<11> for not doing that, is there?

<12> A. I agree there is no technical impediment.

<13> Q. Now, the other side of the coin, and I hope very quickly, is

<14> there any technical reason for sending sound when the remote

<15> computer cannot handle it?

<16> A. No.

134. 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.
135. 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.
136. 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.
137. 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.
138. 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.
139. With some doubt, I conclude that the argument of obviousness based on screen size/resolution, and hence matching, fails in relation to GloMop.

Pythia

140. 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.
141. This document does not cross-refer to GloMop in a way that makes it permissible to read them together.
142. The following passages are relevant, first from the overview.

Computing By Proxy: Trading Cycles for Bandwidth

A powerful, well-connected desktop workstation can run a process that acts as a proxy for a mobile

client on the other side of a low-bandwidth connection. The proxy's job is to retrieve documents on

the client's behalf, and transmit them to the client across the slow link in a format that is useful to the

client and can be transmitted fairly quickly on the slow link. For example, a large color GIF might be

transcoded to a thumbnail-sized gray scale image for display on a PDA, along with a clickable

button that causes the original to be retrieved and displayed. This process of distillation can be

applied to other datatypes as well; for example, PostScript can be distilled to plain ASCII text and

video can be distilled by decreasing the image size, color depth, and/or frame rate. We have working

prototypes of both of these examples.

…

Successive Refinement

A distilled representation of a document contains sufficient semantic content for the user to identify

whether the document is valuable enough to request one of several kinds of refinement. For example,

in the ASCII distilled version of a Postscript document, the user could request the transmission of

embedded images from a distilled PostScript document, or the user might like to zoom in on a

portion of a map to see detail for a small geographic area of interest.

…

143. Second, from the technology demo page:

The Demo vs. "Real" GloMop

The demo differs from a real GloMop-aware browser in several ways:

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

"protocol" by which distillation and refinement requests are passed to the proxy. A real

GloMop client accomplishes this using the bona fide layered protocol we have designed.

•    Sizes and color depths of distilled images: A real GloMop client will negotiate a

representation with the proxy, based on the measured quality of your network connection.

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

real GloMop client receives distilled versions of almost any document: Postscript, MIME

email, video/audio, etc.

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

Berkeley NOW) to exploit inherently-parallel distillation tasks.

144. Third, from a page entitled 'How the demo works':

How It Works

All HTTP requests made by your browser are intercepted by the proxy host (a SPARCstation 20),

which is well-connected to the rest of the Internet. The proxy forwards each request to the server

specified in the request.

If the server returns a GIF image that exceeds a certain threshold size, the proxy distills the image

and sends the client this (much smaller) drawing in GIF format.

Much HTML hackage is also done, for example to add the R links after each image. These links

work by adding a "key string" onto the end of the HTTP request, to cue the proxy that this is a

request for a refinement of a previously-fetched image, rather than a request for a new image. (Yes,

this is a hack, because it's the only easy way to make this work with today's browsers and the

stateless HTTP protocol. But a true GloMop-aware application would use the GloMop library to

perform such negotiation directly with the proxy. -->

145. The Pythia Registration form is also important. While the material about the effect of registration, name, email address, operating system and connection speed can be passed over, the next section cannot.





146. The disclosure of these pages can, so far as relevant, be summarised as follows:

i) The demo proxy is going to transcode images into a form that will be useful to the client and will transmit relatively quickly across a slow link;

ii) It will do this with GIF and JPEG images in any web page accessed from the web;

iii) The mobile will make its request using HTTP, but replies will be intercepted and images transcoded. When a transcoded image is relayed to the user's computer the GIF's and JPEG's are going to be reduced to thumbnails that are clickable links (in the HTML this will be indicated by an R following them) so that if the link is clicked for refinement (ie to send the full image) the server will know it has already been downloaded.

iv) There is a threshold size for distillation, at least of GIF's.

v) The preferences entered for each user are used as distillation preferences whenever the user connects using the machine for which the preferences were entered, that is, one set of preferences per machine.

vi) Pretty well any file format will be distilled in real GloMop.

147. The debate centred on the significance of the "Preferences" page. The fields appear to be drop down menus for the two colour preferences and user-entry fields for the two size parameters, ie distillation threshold and maximum size of thumbnail. Professor Eisenstein appears to accept this, describing it as cumbersome, and as causing frustration and mistakes to the ordinary user (report [96.12]).
148. The disclosure is clearly that the threshold and colour depth figures for the thumbnails are intended to be entered by the user. I am mystified by the suggestion that they are not supplied to the server upon connection. They are associated with the IP of the user's machine, and 'will automatically be used whenever you connect'. In other words, after registration with the Proxy they are stored with the proxy and used by the proxy for distillation when that particular machine makes a request. This is almost precisely the mechanism suggested for the same purpose in the patent—see [0050], [0056], [0066], [0071] and [0077] of the patent and [77] above. It differs only in that the IP is used (completely automatic) when a connection is made to the proxy.
149. Claim 11 is plainly anticipated by Pythia. There is a subsidiary question on claim 12, since it seems to me that to send a thumbnail whose maximum dimension has been selected by the user to be suitable for his display is plainly sending an image size, not a screen size. The same point arises in relation to 'match' in claim 1. I think the right view is this. If the user looks at his screen, and decides that no image is to be wider than half the screen width, then if that dimension is transmitted to the server the method claims would be infringed. Professsor Handley thought this was the case ([236] and [245]) and he expressed it clearly in cross-examination (transcript 698):

<16> Q. But the skilled man understands what he is reading when he

<17> reads the word "thumbnail", does he not?

<18> A. He means a small image, yes.

<19> Q. So I will put my point again, Prof. Handley. Here you are

<20> suggesting that the skilled man has thrown away the notion of

<21> a thumbnail and he is going to have a PDA negotiating the

<22> maximum size to which images should be scaled.

<23> A. That is exactly what Pythia shows - the maximum dimension of

<24> inlined thumbnail. The term thumbnail, we can argue about the

<25> definition of thumbnail, but these are clearly reduced size

< 2> images. They are small images.

< 3> Q. And the final jump is to say, oh, that size should fit on the

< 4> PDA screen.

< 5> A. I believe it makes sense to, if you are going to choose to

< 6> distill images down, especially if in the context of Pythia,

< 7> we are looking at the user can set these size of images, so

< 8> they can display them appropriately, it makes no sense

< 9> whatever to choose the thumbnail size to be so large that it

<10> does not fit on your screen. I believe you would take that

<11> information into account when you were said that. If you were

<12> using a device that had a very small screen, you would choose

<13> a smaller size of thumbnail. If you were using a device on a

<14> large screen, you would be able to choose a thumbnail that was

<15> a larger size.

<16> Q. Through this slightly weird reverse logic, you will manage to

<17> make the jump to having a size of image that fits the PDA

<18> screen. That is right, is it not?

<19> A. Now we get on to the argument about fits. Fits within,

<20> I think, is reasonable. I am not saying Pythia discloses

<21> anything that directly fits the size of the screen, but

<22> I think it is entirely reasonable to expect that you would

<23> choose the size of the thumbnails based on the size of your

<24> screen.

<25> Q. Well, with the benefit of hindsight.

< 2> A. No, just that it is entirely reasonable.

< 3> Q. Well, Prof. Handley, we are going to suggest that the

< 4> hypothesis that you talk about in paragraph 245 simply would

< 5> not arise.

150. There is a long cross-examination of Professor Eisenstein on this disclosure, which did not help. He failed to recognise, I think, that Pythia was not being offered as a historical document, but as a disclosure of a system having certain characteristics. He eventually became obstructive in his answers. In any event, if you can enter maximum thumbnail size, it is obvious, if it is possible, to do it so as to fill such a proportion of the screen as you think appropriate: that is sufficient for claim 12 and it also satisfies my interpretation of claim 1. I agree with Professor Handley.
151. It follows that Pythia renders claims 1 obvious, 2 anticipated, 7 obvious and 8 and 13 anticipated. Claims 1 and 7 as proposed to be amended are obvious.

Mowser

152. Mowser is also concerned with the interposition of a proxy between a mobile unit (called a mobile host or 'MH' in the text) in order to take some account of the shortcomings of the mobile. This proxy is called the mobile support station. Each host is associated with a set of preferences identified by its IP address. The preferences file, which is maintained by the proxy, or by an associated server, includes information about 'the hardware capabilities' of the mobile host and its user preferences. The underlying problem is identified thus:

'Since wireless networks do not have the data transmission speeds of wired networks, downloading large files over wireless networks will consume a longer time. Not only will it take longer to display large files, but it will also consume more battery power, reducing the time the mobile computer can be used. Web servers also have no notion of the resources available at the client's end, and blindly assume that the client is capable of properly displaying the data that it receives. For example, a user may follow a hyperlink to a sound file on an X terminal [i.e. a terminal running an X server] which is not capable of playing sound. As a result, the Web server will consume time and network bandwidth to deliver a sound file that cannot be used by the client. While more and more workstation PCs are becoming multimedia-capable, the same is not true of mobile computers.

To overcome these problems, a smarter Web browsing application is needed. It must take into account the differences between a static and mobile host, and the quality of the network connection between the server and client. The objective is to let the user set his or her own preferences for optimal use.'

153. The scheme as described provides for preferences called Homepage, Color, Video Resolution, TextSize, ImageSize, ReduceImageBy, VideoSize, AudioSize and UnknownSize. Once the preferences are stored at the proxy (mobile support station) all HTTP GET requests from the mobile are handled by the proxy server. If the file requested does not meet the requirements described in the preferences, 'the proxy server can modify the file before sending it' to the mobile.
154. The nature of the modifications contemplated are best set out in the authors' words:

'If a file does not meet the size requirement for its type, the proxy server will not send it to the MH. Files that cannot be properly displayed by the MH will not be sent either. A MH with no sound capabilities will not receive any sound files. If the MH has only monotone [sc. monophonic] sound capability, stereo sound files would be converted to [monophonic], before they are sent. Image files can be compressed by sacrificing quality without sacrificing semantics. In particular, the size of the image, and the number of colors can be reduced, resulting in a smaller image that conveys the same information. Whenever a file is modified by the proxy server, a URL will be provided to retrieve the original unmodified file, if the user so requires.

…

Our current implementation performs conversions on image files if they do not meet the user's preferences. Both GIF and JPEG format files are subject to this conversion. The preferences allow the user to choose between reduction by image size or by number of colors. If the user decides colors are more important than the image size, no color loss will occur during the conversion. The file size is compared to the maximum file size permitted in the preferences, and a scale factor is determined. The image file is then scaled do till it meets the files.' [my emphasis]

155. It seems that in the 'current implementation', therefore, the primary restraint on the size of an image is the size of the corresponding file. Reduction of the file size is carried out either by reducing colour or by reducing image size, until the file size criterion in met. This is not the same thing as reducing to match the screen size although a quick check on the preferences will show that they include screen size.
156. One particular point on the disclosure of Mowser appears to have given some difficulty. The reference to 'Video Resolution' on page 3 is ordinary usage in the art and is quite plainly a reference to screen size. The three values given (640×480, 800×600 and 1024×768) are standard display sizes in pixels for 4:3 aspect ratio screens and have nothing to do with the display of video files, an equally standard usage in the art, as was rather faintly suggested to Professor Handley at transcript pages 724–5. As he said, these 'Video Resolutions' are very obviously nothing to do with video files. A feeble attempt was made to relate the example video file size (8Kb on page 4) to the video resolution and suggest that in this rendered the figures meaningless. This was plainly wrong.
157. Professor Eisenstein made two observations on the disclosure of Mowser which were surprising. In the first, in [107], he suggested that the user would have to re-enter his preferences every time he used the system. This is incorrect. As described, Mowser plainly discloses a system in which preferences may be revisited if there is a change in 'availability of different resources during different sessions'. I put this down to an oversight, although I think the Professor might have asked himself why, if preferences were transient, they were stored on a separate preferences server. It may, however, be associated with his other point, which is that in a University setting it is common for individual machines to have fixed IP addresses, this is not now so common generally: ISP's allocate IP addresses to a user on a session by session basis. Thus, to store preferences by IP address will not be much use. This point has nothing to do with anticipation. I will discuss its impact on obviousness below.
158. The second of Professor Eisenstein's points is that the preferences file consisted only of user preferences. This is wrong. Mowser says 'The preferences file contains information about the hardware capabilities of the MH, and its user preferences.'
159. Professor Handley was willing to see in Mowser use of the Video Resolution preference (i.e. screen size) to reduce image image files. He based himself on the passage quoted above at [154]. He was adamant that Mowser was clearly contemplating image size reduction based on screen size in his cross-examination at transcript 719-722. The crucial point is that Mowser's general description (section 2) is more general than the implementation (section 3) and that the passage bridging the columns (italicised in [154]) plainly related to a principle, as he put it, 'not to send stuff that would not fit within that'.
160. I do not think that size reduction based on display size is disclosed as a matter of language. Nor do I think it falls within the category of necessary inferences. It follows that claims 1 and 7 are not anticipated. Claims 2, 8, 11 and 13 on the other hand, are anticipated, because the sound example, express this time, is substantially identical to that of GloMop.
161. I turn to the question of obviousness. If the paper immediately suggests to the skilled person that he can use size reduction to meet the display size then it renders claims 1 and 7 bad for obviousness. In my judgment, Professor Handley's view on this is well thought out and convincing. I conclude that it does. I reject Professor Eisenstein's objections because they are not cogent or are irrelevant. The first ([110.1]—preferences may be changed) is irrelevant. The second ([110.2–3]—Mowser as described will only work with fixed IP's) is irrelevant to the claims as I have construed them. In any event the change from IP to UserID as an index into a preferences file is trivial, although it requires a separate logon to the proxy server. The third ([110.4]—NanoBrowser not disclosed) is irrelevant since the NanoBrowser is not a feature of the claims. The fourth ([110.5]—sophisticated users only) is irrelevant since it is not a feature of the claims of the patent in suit that information about the mobile be transferred automatically. The scheme of the patent is the same as Mowser: register once, and the data is stored at the server, or is accessible to it.
162. Professor Eisenstein's final objection deserves separate comment.

'110.7 Any designer relying on the Mowser document as a starting point would be faced with the difficulty of determining how the Mowser system actually works. The document describes a complex system in six pages. It is a high level overview that does not provide examples of the screen displays, forms, server routines, communication protocols, or even a clear description of what the proxy, preferences and caching servers do. Before improving on Mowser, a designer would have to figure out exactly what it is, which is by no means an easy task.'

163. I think one is entitled to enquire where all this material is to be found in the patent in suit. Had the patent in suit contained any information at all as to server routines, communication protocols or a description of what the proxy sever actually does, its interpretation would have been greatly simplified. It is prolix, but it is not detailed. Mowser must be read by the same skilled man as reads the patent, and they can both make shift with descriptions of this kind.
164. The insubstantiality of Professor Eisenstein's evidence on the question of the patent's obviousness in the light of Mowser confirms me in my view of that document's signficance as a starting point of any argument of obviousness. There is no difference in inventive concept once it is accepted that the document immediately suggests adjusting image size to fit, having told the proxy what the size to fit is.
165. It follows, in my judgment, that claims 1 and 7 are equally invalid.

Bartlett

166. The final citation is called Bartlett, and its title is 'Experience with a Wireless World Wide Web client'. It was published in March 1995, as a preprint of a paper delivered at an IEEE Conference at which it was delivered. The work it reported was carried out at the DEC Western Research Laboratory.
167. The paper describes a client running on a PDA, the Apple Newton, and a proxy of some description running on a DEC workstation running the operating system called ULTRIX.

'Early experiments suggested that the PDA should do as little as possible and that wireless bandwidth be conserved. This resulted in the client being split between the PDA and an ULTRIX workstation, with the bulk of the application residing in the workstation.

The PDA acts as a video-text client, displaying screens representing a portion of a hypertext document. Each screen is identified with a tag that contains the document's Universal Resource Location (URL) and an offset within the document. In the simplest PDA-based client, when a hypertext link or scroll arrow is tapped by the user, the tag associated with the interactor is sent in a request to the workstation. The workstation obtains the document from the Web, parses it (caching the result for later requests), formats the desired screen for the PDA, and then replies to the PDA's request.

The reply is a screen description composed of simple screen drawing commands that were designed for efficient decoding in the PDA. Each line of text is specified by its x,y coordinates and a text string. Each hypertext link is represented by its x,y coordinates, the link width, and the tag. New commands for handling images, line drawings, and forms could be easily added to the protocol.

In order to improve performance and allow operation without communications, a simple cache was added to the PDA-based client. Each time a screen description is received by the PDA, it is added to the cache. Before the PDA makes a request to the workstation for a screen, it checks to see if it is in the cache.

The final performance improvement was to add prefetching to the PDA-based client. After a screen is displayed, the PDA checks to see if the next sequential screen of the document is in the cache. If it isn't, then the screen is requested from the workstation.'

168. It is clear that in the system as described, the ULTRIX workstation, to which the PDA is connected over an analogue wireless cellphone network, acts as a proxy, fetching HTML pages identified by URL's entered at the PDA. The HTML pages are simplified by removal of images and preprocessed for display as videotext, which indicates a page-based display. The simple browser used allows for links, which are inserted in the videotext page in the manner described, but does not permit either forms or images.
169. Obviously this is another proxy proposal. There is a dispute whether the paper discloses that details of the Newton's display are hardwired into the proxy server, or whether this appears in Figure 1, which is not otherwise described. Figure 1 appears to disclose a system in which the function of a browser client is split between the Newton and the proxy. The Newton's part handles Page Presentation, the Cache and Communications, all of which are described in the text as functions of the Newton. The proxy handles page formatting, that is, the interpretation of HTML, using the CERN library, which is the HTTP and HTML library supplied by CERN for this purpose. Page formatting too is described in the text as a function of the proxy. What Figure 1 appears to show, which is not mentioned in the text, is the supply by the Newton to the proxy of particulars of the Font, the Screen Size, the UserID , the URL and the line, and the supply by the proxy to the Newton of Actual Line (which I had thought to be the line on the HTML page, which is split into videotext pages), something called Next, Previous, IsIndex? and, obviously, the title. The data relating to the page is precisely what is described in the text, that is, lines of text with the coordinates of their starting point (x, y, text) and links, which are sent as coordinates, width of the link, and the associated URL (x, y, width, URL).
170. Professor Eisenstein took the view that the document was incomprehensible in [123]. I do not think his view could be sustained, as his cross-examination, and in particular a series of answers too long to set out here, between pages 554 and 558, was unsatisfactory and tended to confuse a rather simple issue concerning the positioning of strings of characters on the page, which is already described in the text.
171. Generally I accept Professor Handley's views of what the document discloses. A clear statement of Professor Eisenstein's views was put to him over a long passage in cross-examination at 733-770. His response is coherent and in my view convincing. What worries me is whether this disclosure has, so to speak, been squeezed out of the document, not necessarily with hindsight but with too much effort.
172. In Bartlett's system the treatment of HTML web pages is very drastic. All that survives are the selectable links. Everything else is stripped out, including images and forms, and the HTML text is formatted to fit on one or more pages, through which the Newton scrolls. The proxy must compose the pages, line by line, because that is what the description says.
173. There was a substantial, and uninformative, discussion about the way in which the proxy knew what the line-breaking algorithm of the Newton was. It seems to me that if one takes the disclosure at face value, that is good enough. The proxy uses its own line-breaking algorithm. This means it needs to know how wide, in characters, the display is, and must be capable of dealing somehow with the proportional fonts used for display on the Newton. Figure 2 of the article shows a Newton displaying using a proportional font.
174. There is no disclosure of the protocol used for transmission between the proxy and the Newton over the cellular telephone link. Professor Handley thought it was unlikely to be TCP/IP although that was an obvious possible choice. There is no discussion of how to keep images within bounds from the Newton's point of view. There is no reason to doubt that the Newton's programmers' toolkit permits such things as mixed text and image display to be incorporated in the browser (it has a graphics screen, 320×240 pixels—see page 4) or to doubt Bartlett's statement that 'New commands for handling images, line drawing, and forms could easily be added to the protocol'.
175. It is a striking thing that Bartlett chose a WWW browser as a 'proof of concept' application for a wireless world wide web application. His interest appears from the article to be split at least evenly between the practicality of using the analogue cellphone network for data communications and the software on the Newton, with the former perhaps slightly ahead. His basic principle is the same as the others, and apart from his basic principle of giving the mobile unit as little to do as possible to save on batteries and to avoid delay, he clearly demonstrates the processing of HTML into a form designed for display on the Newton's screen.
176. Professor Handley proposes in [172] of his report an addition to the protocol between Newton and proxy that would accommodate images, and it would be up to the browser in the Newton to understand this command and up to the server software in the proxy to generate the command from the image and HTML. He says that fixing on the size of the image by reference to the size of the Newton screen is obvious, the more so because he thinks that this is part of the information provided by the Newton to the proxy in Figure 1.
177. As I have construed the words 'specific size and resolution', Bartlett renders claims 1, 7 and 13 obvious, this time because it is the proxy that does nearly all the rendering of HTML to fit the screen. Claim 11 is equally obvious, because in my judgment a fair reading of Bartlett does require it to be accepted that the screen size of the Newton is transmitted to the proxy. This being so, claim 12 falls.
178. I am conscious that this decision on Bartlett may be thought surprising, given the brevity of the document, and the omission from the system actually described of any reference to images. But the centrepiece of Bartlett is the transposition of HTML by the proxy so that the result fits on the Newton screen. If that transposition takes place in response to the supply of the screen size to the proxy, then the core of the inventive concept is there, and if it is obvious to the skilled man to follow Bartlett's invitation to extend the technique to images, then the inventive concept is disclosed.

'Single File'

179. I have left this topic until last. It forms the subject matter of the 'B' line of proposed claims to be added by amendment. The B line of claims add to the inventive concept that the results of more than one HTTP GET request from the proxy are incorporated into a single file by the proxy before being sent on to the field computer, the specific types of files called for by the claim being HTML for the page and image files for the other component.
180. TCP/IP is a protocol which will, in principle, support the transfer of any number of files over a single open TCP/IP connection, providing the application layer protocol permits it. HTTP does not permit it, and a GET request results in the opening and closing of a TCP/IP connection. This is the nature of HTTP as a protocol: it is stateless, which means that its history cannot effect the way it responds to a particular command. This, in turn, results in substantial overhead.
181. Obviously all the systems described in the citation use HTTP between the proxy and the Web. Two of the systems (Bartlett and GloMop) do not use HTTP between proxy and mobile. Pythia and Mowser do, as the disclosure that ordinary browsers can be used for their purpose attests. It is common ground, I think, that none of the documents refers to the possibility of sending mixed content files from proxy to mobile. They all propose treatment of images at the proxy. As Professor Handley says, the non-HTTP systems then have a choice. Either the mobile's browser uses a protocol that requires the proxy to send images separately from the transposed HTML, or it uses a protocol which permits mixed files to be sent in answer to a request for a webpage. All the relevant files are now stored on the proxy, and so which expedient is adopted depends for present purposes upon the obviousness of sending a single file with a mixture of datatypes (specifically, transposed HTML and image(s)) in a single file. He suggests that two possible types of files were well-known at the date: archive files in (for example) the tar format or in MIME multipart related format, a format used for email. Both of these, Professor Handley insisted, were file types that would be known to the skilled person. He says the task is trivial.
182. So far as the non-HTTP systems are concerned, I see no reason why as Professor Handley says it would be anything other than trivial to write a protocol in which a 'GET' command expected a single file response including all included images. This is the task that the patent sets the reader, and if the disclosure of the patent is sufficient, the skilled person is capable of performing the task. If the response was in modified HTML with place holders for the included files, then the tar format includes a table of contents to indicate to the browser where in the single file the included image file is to be found. Professor Eisenstein's only objection to the use of the tar format was that its use would require a modification of HTTP. These two systems do not have that problem, and so Professor Eisenstein's objection falls away.
183. There was a lengthy consideration of whether MIME formed part of the skilled addressee's common general knowledge, and, if so, whether the particular MIME multipart formats were defined and common general knowledge at the priority date. I do not propose to burden this overlong judgment with an examination of that interesting question. I am firmly of the view that the use of a single file, and the appropriate changes to the protocol between mobile and proxy, is entirely trivial. It saves on TCP/IP connections and is obvious to use for that reason. GloMop already contemplates the use of a single open connection, so the only task is to assemble everything into a single file whose characteristics are very well known indeed to the skilled addressee. The same goes for Bartlett.

Patentability

184. The claims of the patent are all concerned with how to transmit data between a field computer and a proxy server to enable a field computer, inadequate in processing and display power, to browse the web and produce a result substantially better than its modest abilities would indicate. The objection taken is that the invention lies in matter excluded from the realm of patentability by section 1(2) of the 1977 Act, the effect of which is the same as Article 52 of the European Patent Convention. Because the law on this issue is supposed to be uniform among the Contracting States, and because for no apparent reason the provisions of the 1977 Act are not quite identical to those of the Convention, I prefer to use the text of the Convention itself:

Article 52

Patentable inventions

(1) European patents shall be granted for any inventions which are susceptible of industrial application, which are new and which involve an inventive step.

(2) The following in particular shall not be regarded as inventions within the meaning of paragraph 1:

(a) discoveries, scientific theories and mathematical methods;

(b) aesthetic creations;

(c) schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers;

(d) presentations of information

…

(3) The provisions of paragraph 2 shall exclude patentability of the subject-matter or activities referred to in that provision only to the extent to which a European patent application or European patent relates to such subject-matter or activities as such.

185. There has been a flurry of cases on this provision recently, all of which have been concerned with the exclusions relating to methods of performing mental acts or doing business, playing games and programs for computers: Fujitsu's Application [1997] RPC 608, Halliburton v Smith [2005] EWHC 1623 (Pat), Crawford v Jones [2005] EWHC 2417 (Pat), CFPH LLC's Application [2005] EWHC 1589 (Pat) and Shoppalotto's Application [2005] EWHC 2416 (Pat). If nothing else, the wide range of topics (design of inorganic crystalline materials, drill bit design, display systems for buses, betting and online games) demonstrate the importance of the exclusions.
186. It is now settled, at least at this level, that the right approach to the exclusions can be stated as follows. Taking the claims correctly construed, what does the claimed invention contribute to the art outside excluded subject matter? The test is a case-by-case test, and little or no benefit is to be gained by drawing analogies with other cases decided on different facts in relation to different inventions. RIM says that the point does not require elaboration. It contends that all that is claimed, as a matter of substance, is a collection of programs for computers. I think this is wrong. What the claims give is a technical effect: computers running faster and transmitting information more efficiently, albeit ultimately for the purpose of displaying part of that information.
187. I am anxious that these exclusions are not given too wide a scope. All modern industry depends upon programmed computers, and one must be astute not to defeat patents on the ground that the subject matter is excluded under Article 52 unless the invention lies in excluded subject matter as such. The test proposed by RIM in this case (is a computer program accused of infringement) proves too much. An offer of computer program may be an offer of a process for use in the United Kingdom (section 60(1)(b)) or it may itself be 'means relating to an essential element of the invention…' within section 60(2) even when the invention cannot be accused of residing in excluded subject matter: it depends on the facts. Perhaps one can say that the invention does not lie in excluded subject matter, even though it may be expressed in a computer program.
188. I agree with RIM, therefore, that the question does not call for elaboration, but disagree that invention lies in excluded subject matter. This objection fails.
189. Although there is a pleaded objection to the industrial applicability of the invention, I did not understand it to be pursued. It fails. The definition of this term in section 4 of the Act and Article 52(4) of the Convention, 'it can be made or used in any kind of industry, including agriculture' is so wide that it is not easy to see how this invention is incapable of industrial application. That is why we have the exclusions, all of which cover subject matter plainly capable of industrial application.

Conclusions

190. In the result, the A series of amendments are disallowed. The B series would be allowed, but all the claims are invalid on the grounds of anticipation or obviousness as detailed above in respect of the citations. The objections to patentability fail. The relevant claims would have been infringed to the extent I have indicated had any of them been valid. The action succeeds and the counterclaim is dismissed.

Note 1   Professor Eisenstein describes this in terms of what is called the OSI model in paragraphs 35ff of his first report. I have relied as well on the description from MJH 25, which is RFC 1180 ‘A TCP/IP tutorial’ (1991), to which he also refers, and avoided mention of the OSI presentation and session layers altogether, since they have no parallels in TCP/IP.    [Back]

Note 2   Serial Line Internet protocol and Point to Point protocol. These are data link layer protocols over which IP runs, and are designed for dial-up connections to ISP’s.    [Back]