[Home] [Databases] [World Law] [Multidatabase Search] [Help] [Feedback]
	England and Wales High Court (Patents Court) Decisions
You are here: BAILII >> Databases >> England and Wales High Court (Patents Court) Decisions >> Research In Motion UK Ltd v Motorola Inc [2010] EWHC 118 (Pat) (03 February 2010) URL: http://www.bailii.org/ew/cases/EWHC/Patents/2010/118.html Cite as: [2010] EWHC 118 (Pat)

[New search] [Printable PDF version] [Help]

IN THE HIGH COURT OF JUSTICE
CHANCERY DIVISION
PATENTS COURT

		Royal Courts of Justice Strand, London, WC2A 2LL
		3 February 2010

MR JUSTICE ARNOLD :

Contents

Topic	Para
Introduction	1-2
The expert witnesses	3-6
Technical background	7-35
Networks	8
Protocols	9-15
Gateways	16
Clients and servers	17
Wireless networks	18-22
Paging networks	19-21
Wireless data networks	22
Internetworking wireless networks	23-29
Email systems	30-34
Voicemail	35
Beletic	36-69
Technical field of the invention	37
Background of the invention	38-39
Summary of the invention	40-43
Brief description of the drawings	44
Detailed description of the invention	45-69
Messaging gateway system	50-52
Remote system controller	53
Subscriber device architecture	54
Subscriber notification	55-61
Subscriber-initiated commands to remote units	62-64
Voicemail system interface	65-69
The claim	70
The person skilled in the art	71-72
Common general knowledge	73-92
Construction	93-133
General	95-96
Messaging gateway system	97-99
Remote messaging system	100-101
Transmittable messages	102-111
Portions of the messages	112-114
A set of commands	115-116
Translating a set of commands into a protocol understood by the remote messaging system	117-133
Infringement	134-158
BES	135-149
BIS	150-157
Conclusion	158
Validity	159
The cited prior art	160-179
RadioMail	161-165
MNI	166-167
Pepe	168-179
Novelty	180-195
MNI	183-184
Pepe	185-194
Integer [3]	186-190
Integer [5]	191-194
Conclusion	195
Obviousness	196-221
RadioMail	199-218
Command compression	202-208
Gateway as proxy	209-210
Accessing multiple email systems	211-215
Two-way pagers	216-218
MNI	219
Common general knowledge	220
Conclusion	221
Insufficiency	222
Not a patentable invention	223
Conclusion	224

Introduction

1. The Claimant and the Third Party are part of the Research In Motion group of companies. Research In Motion is the group behind the well-known BlackBerry wireless handheld devices and the infrastructure and software required to operate them. The Claimant is the UK subsidiary and the Third Party, a Canadian company, is the parent company of the group. I shall refer to them collectively as "RIM". The Defendant and the Fourth Party are part of the Motorola group of companies. I shall refer to them collectively as "Motorola".
2. In this action Motorola allege that RIM have infringed four of Motorola's patents. In a related action another subsidiary of the Third Party alleges that Motorola has infringed one of its patents. For procedural reasons that it is unnecessary to go into, this judgment is concerned only with the claim in respect of Motorola's European Patent (UK) No. 0 818 009 entitled "Message Communication System" ("Beletic"). RIM deny infringement and counterclaim for revocation on various grounds. There is no challenge, however, to the claimed priority date of 2 March 1995.

The expert witnesses

3. Motorola's expert witness was Neil Wiffen. From 1979 to 1986 he was a regimental signals instructor in the British army. From 1987 to 1997 he was successively a communications officer, research & development team member and research & development team leader at GCHQ. In 1995 he was in the last of those positions, and was involved in developing telecommunications control software and remote system control and monitoring. From 1997-1999 he was head of technical training services for a government organisation. From 1999-2000 he was a 3G mobile cellular systems instructor for Wray Castle Ltd. Since 2000 he has been a technical consultant in the telecommunications field.
4. RIM's expert witness was Professor Richard Wolff. He graduated from University of California at Berkeley with a BS in Engineering Physics in 1966. In 1969 he obtained a PhD in experimental astrophysics. From 1969 to 1977 he was an assistant professor in the Columbia University Physics department. From 1977 to 2003 he worked for Bell Laboratories, Bellcore and Telecordia Technologies. From January 1991 to September 1994 he was director of personal communications applications research at Bellcore. During that time he led a research programme exploring applications of emerging wireless networks and portable terminals. This work included personalised messaging, cross-media notification and the use of wireless devices to control and direct voice calls and email. Since 2003 he has been Gilhousen Telecommunications Professor in the Electrical and Computer Engineering Department at Montana State University.
5. Both experts were well qualified and both did their best to assist the court. Of the two, I generally found Professor Wolff's evidence more persuasive for three reasons. First, I consider that his expertise and experience as at early 1995 more closely approximated to those of the relevant skilled person. Secondly, I found his explanations to be somewhat more cogent than those of Mr Wiffen. Thirdly, his oral evidence was more consistent with his reports than that of Mr Wiffen.
6. Counsel for Motorola submitted that Professor Wolff had read more into the prior art than it actually disclosed, while counsel for RIM submitted that Mr Wiffen had read more into Beletic than it actually disclosed. I think there is force in both submissions, but particularly so in the case of Mr Wiffen's reading of Beletic for reasons I shall explain below.

Technical background

7. In this section of the judgment I shall attempt to set out the uncontroversial technical background to Beletic. I shall deal with the key area of controversy separately below. For convenience I shall mainly use the present tense, but I am referring to the position as at 2 March 1995.

Networks

8. A network is a group of computers connected together to allow exchange of information. The connection can be wired or wireless. A distinction is often made between a private network and a public network, the latter being accessible to the public at large. A local area network (or LAN) is generally a small private network, an example being the type of system used internally by a company. A wide area network (or WAN) is a larger public network, such as a mobile telephone network. The Internet is also a WAN. It is often referred to as the "network of networks" because it is made up of many networks connected together.

Protocols

9. Protocols are used so that computers can communicate successfully over a network. In simple terms they are the rules and procedures (including relevant syntax and semantics) governing communication. Protocols generally cover all aspects of communication between computers including establishing and maintaining connectivity, formatting content into suitably sized segments, addressing and detecting errors and managing reliability.
10. Most protocols are layered together in "stacks", with the various tasks being performed by different layers in the stack. In the early 1980s the International Standards Organisation (ISO) developed a reference model called the Open Systems Interconnect (OSI) 7-layer model. The OSI 7-layer model is a conceptual template for protocol stacks describing the general responsibilities of each reference layer using increasing levels of abstraction from the physical medium on any link. Functions that are both similar in nature and relevance at the same level of interpretation are grouped into layers which are then processed by peer entities (i.e. entities operating at the same layer) in such a way that a higher layer can request a reliable delivery of information as a service from the layer immediately below it. The layer below provides services to the layer immediately above using processes and procedures that do not need to be understood by the layer above.
11. The OSI model defines 7 layers with the typical responsibilities outlined below:

7	Application	Type of communication: database access, email, file transfer etc.
6	Presentation	Encryption, data conversion.
5	Session	Starts and stops sessions, maintains order.
4	Transport	Ensures delivery of entire file or message.
3	Network	Routes data to different networks.
2	Data Link	Transmits data from node to node.
1	Physical	Transmits bits on a medium (e.g. radio frequency).

12. The process of sending information across a network can be thought of as the provision of that information by the application to the top layer, following which the information travels down the protocol stack to create data at the bottom layer having the physical form necessary to its transfer across that network. Different layers of the stack handle different aspects of the task of transferring the data across the network.
13. It is common to combine several layers of the OSI model into a single layer. For example, File Transfer Protocol (FTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4) and Simple Mail Transfer Protocol (SMTP), which were all widely-used protocols in March 1995, all combine the relevant functionality of layers 7, 6, and 5 of the OSI model into a single upper layer. I shall use the term "the application level" to embrace both the Application layer (layer 7) in the OSI model and combined upper layers of this kind.
14. Different networks frequently use different protocols at various levels of the protocol stack. For example, two networks might use different transport protocols, each using a transport layer protocol optimized for the network in question (wired or wireless). Alternatively, different application layer protocols (email protocols, database protocols, file access protocols etc) could be used on top of the same lower layer protocols. Even in the case of the same type of application, different types of application level protocols may be used depending on the product. For example, SMTP, POP3 and IMAP4 are all application level email protocols (see further below). Each of these relies on Transmission Control Protocol (TCP) as the transport layer protocol.
15. Because many networks were initially developed to operate in isolation from other networks, to begin with there was no need for standardisation of protocols, so inevitably different protocols were used on different networks. With the expansion of the Internet in the 1980s, many networks were connected together. This is known as "internetworking". An issue with internetworking is making the computers on different networks, which may use different protocols at various levels of their protocol stack, understand each other.

Gateways

16. Networks are generally connected together by the use of various networking components such as bridges, gateways, relays and routers. A gateway is a device that interconnects two networks, and whose presence is usually visible to network users (as distinct from a bridge, whose presence is generally not visible). The functions that a gateway may be required to deal with are:

i) change of addressing domain – where the networks have addressing domains managed by separate groups, a gateway may be used to handle address transformations for messages traversing the gateway;

ii) control of charging – where the networks have different approaches to charging (e.g. a local area network that imposes no charges connecting to a wide area network that charges on a per-packet basis) a gateway may be used to handle user authorisation and usage accounting; and

iii) change of protocol – where the networks use different protocols, a gateway may be used to carry out necessary protocol conversion (if practicable) or to intercept attempts by a user on one network to use functions not available on the other and to supply suitable responses.

Clients and servers

17. A server is a device or program which provides services to one or more other devices or programs (the clients). Server software and client software can run on the same computer, on different computers on the same network or on computers on different networks which are internetworked.

Wireless networks

18. Wireless networks allow users to connect to networks when they are not able to connect via a wired connection. Wireless networks use radio links to connect the wireless device to base stations which ultimately connect into wired networks. Two common types of wireless network in the early 1990s were paging networks and wireless data networks.
19. Paging networks. A pager is a small wireless device which receives messages. By the early 1990s, pagers had developed to a point where they could receive short alphanumerical messages. The messages were limited to a short length (100 characters or less was typical). There were various means by which messages could be submitted to paging networks, including by email. Once this had been done, the paging terminal looked up the "cap code" or pager address to locate the pager and sent the message to a transmitter to broadcast the message on a particular frequency. The pager monitored this frequency and would recognise its own cap code or address. When it received an incoming message, the pager would alert the subscriber e.g. by an audible tone.
20. Paging networks used their own paging protocols. These included Simple Network Paging Protocol (SNPP), Telocator Interswitch Paging Protocol (TIPP) and Telocator Network Paging Protocol (TNPP). If a message such as an email was being sent to a pager, it was necessary to translate the message from the email protocol into the appropriate paging protocol. For example, gateways for converting SMTP into SNPP were in use by 1994.
21. As at 2 March 1995, the commercial paging networks were still one-way. They only allowed "downlink" communications (i.e. to the pager). There was no "uplink" from the device. Nevertheless, the concept of a two-way pager network was well known, as was the fact that commercial embodiments were to be launched imminently (in particular by Motorola). The first two-way paging networks were launched commercially in the autumn of 1995.
22. Wireless data networks. In addition to paging networks, there were various commercial, general purpose wireless data networks in use. These included ARDIS (a joint venture between IBM and Motorola), RAM (also known as Mobitex and later taken over by Ericsson) and Cellular Digital Packet Data (CDPD, a joint venture between various US telecoms concerns).

Internetworking wireless networks

23. Wireless networks gave rise to a number of issues when trying to internetwork with wired networks:

i) They had limited bandwidth and higher latencies. This meant that less data could be sent and it took longer to arrive. ARDIS and RAM supported speeds of less than 10Kb/sec, whereas wired LANs such as Ethernet supported speeds of 10Mb/sec.

ii) They had poor reliability, caused by variable signal strengths (fading) which led to errors in the data being sent. Due to fading, loss of packets of data was much greater than on wired networks.

iii) The fact that wireless devices were not fixed meant that wireless networking gave rise to addressing and mobility management issues (i.e. locating the device to which the call or message was intended and routing that message to it).

iv) Wireless networks had limited area coverage. Since a wireless signal gets weaker as it spreads out over a large area, the signal is only usable in the vicinity of a transmitter tower. This meant that wireless networks in March 1995 generally covered only metropolitan areas.

24. In addition to the problems caused by the wireless network itself, wireless devices presented their own issues. They were generally basic devices, with limited processing power, small screens, limited memory and short battery life. These features constrained the amount and type of data that could be sent over wireless networks.
25. By 1995 various ways had been devised to deal with, or at least mitigate, these issues. Four such methods were the use of middleware, proxy servers, filtering rules and compression.
26. Middleware is a name given to software designed to hide implementation complexities from applications. Wireless middleware was in wide use in 1995 as an intermediary between the different types of network, enabling applications designed for high-speed wired networks to be used on low-speed wireless networks. The term "agent" was sometimes used to refer to middleware components that acted on behalf of a specific client. Such middleware tended to operate at higher layers of the protocol stack, performing activities on behalf of the application software. In such case the middleware is more akin to a proxy.
27. Proxy servers are closely related to middleware. They are another form of intermediary deployed between an application client and an application server. A proxy server would act on behalf of each, relaying commands between the two. Proxies could be used to translate protocols, and for caching (storage) of information and filtering and compression. They could also carry out computationally heavy work on behalf of a wireless device (a proxy server would be considerably more powerful than the wireless device and have no power constraints).
28. Filtering allowed the minimisation of data transfers on a wireless network. In the case of email clients, filters allowed a user to set up rules that limited the emails sent to the wireless device. Various filtering criteria could be used: sender name, message importance, message size etc.
29. Compression techniques are used to reduce the amount of data that needs to be carried by a wireless network. One common compression technique is to send a short code instead of a longer data string.

Email systems

30. Email has been around since the early 1970s and the technology involved has not changed much since the early 1990s. The two main components of an email system are (i) an email (or mail) server, which includes a "mail transfer agent" (MTA) and an email store, and (ii) an email client, also known as a "mail user agent" (MUA). MTAs are responsible for sending emails towards their destination. Emails are sent in a series of hops from one MTA to another until they reach the MUA. In each hop, the MTA stores the email for a period of time while it attempts to send it to the next MTA en route to the recipient.
31. Different email systems employed different protocols and formats in a number of respects:

i) Transport protocols. There were both standardised and proprietary protocols for delivering emails across networks between MTAs. Standardised protocols included SMTP (defined in RFC 821), Unix-to-Unix Copy Protocol (UUCP) and MHS (Message Handling System). Proprietary protocols included those used internally within proprietary systems such as cc:Mail (Lotus) and MS Mail (Microsoft).

ii) Access protocols. There were both standardised and proprietary protocols for enabling email clients to retrieve emails from email servers and to manipulate emails stored on email servers. The two best-known standardised protocols were POP3 and IMAP4, both of which were used for email retrieval and manipulation across the Internet. IMAP4 was more sophisticated than POP3 in that it allowed for a greater range of operations to be performed on emails stored on the server. Proprietary protocols included Messaging Application Programming Interface (MAPI, from Microsoft) and Vendor Independent Messaging (VIM, from Lotus).

iii) Addressing formats. There were both standardised and proprietary formats for the formatting of email headers and other addressing information. RFC 822 (used with SMTP) and X.400 (used with MHS) were two well-known standards for this.

iv) Storage formats. Even systems that employed standardised protocols for transport and addressing etc stored emails in proprietary formats. These were not standardised as there was no need.

32. Protocols such as POP3 and IMAP4 had a series of standard commands that a client could use to interact with the server. For example:

i) POP3 used STAT to cause the mail server to provide information about all emails waiting (the "maildrop"), including the number of messages and the size of the maildrop. It used RETR msg and DELE msg to allow the client respectively to retrieve or delete a message from the server.

ii) IMAP4 used FETCH to retrieve a single item or list of items and EXAMINE and SELECT to change to a particular mailbox and get information about its contents.

33. Both POP3 and IMAP4 had commands which allowed the client to request parts of messages:

i) POP3 had TOP msg n. This caused the server to return the header and n lines of the message. TOP msg 0 returned just the header of the email.

ii) IMAP4 had PARTIAL. This allowed a client to retrieve a particular part of an email from a server. For example, it could request from octets 1-1024 of a message by the command PARTIAL […] 1 1024 and subsequently request the next 1024 octets by the command PARTIAL […] 1025 1024.

34. Where emails were being sent within the same mail system, it did not matter which protocol was chosen, as all messages would be sent and received using the same protocol. When it was desired to send email to a recipient who used a different protocol on a different system, email gateways were used to translate between different protocols, for example SMTP to UUCP and SMTP to MHS.

Voicemail

35. Voicemail systems are networked systems that record and store voice messages in a central repository (as opposed to answerphones which record and store voice messages locally). Telecom-based voicemail systems became commercially available in the early 1990s. For example, BT's Callminder voicemail service was trialled in 1992. Audio Messaging Interchange Specification (AMIS) is a standard that allows the transmission of voicemail messages between different voicemail systems. There are both analogue and digital versions.

Beletic

36. Somewhat unusually, there is a substantial dispute between the parties as to what Beletic actually discloses. It is therefore necessary to consider the disclosure with some care. At this stage I shall set out the disclosure with the minimum of comment and explanation. For this purpose it is convenient to use the headings and sub-headings of the specification itself. I shall deal with the dispute in the context of construction.

Technical field of the invention

37. This states:

"[0001] This invention relates in general to the field of communications systems and more particularly to an improved two-way paging and messaging system and method of operation."

Background of the invention

38. This section begins with the following general description of the background:

"[0002] One of the most convenient forms of wireless communication involves the use of radio frequency transmission systems which transmit short messages to hand-held subscriber devices referred to as 'pagers'. Advances in data transmission techniques have allowed for the development of paging systems that include the ability to transmit short voice messages to subscriber devices that include a voice playback capability. Accordingly, a user of a paging system now has the ability to receive both alphanumeric messages and voice messages through the conventional paging transmission network.

[0003] Although the user of a communications system now has the ability to receive a variety of types of messages on his subscriber device, there has been very little, if any, attention paid to the systems necessary to gather the new voice messaging traffic or to the possibility of allowing the user to control the messages directed to him or other aspects of the communications system. "

39. After acknowledging an item of prior art, the specification then identifies the objects of the invention in the following terms.

"[0005] Accordingly, a need has arisen for a wireless communications system that provides a user with control over the messaging traffic directed to him and which provides a gateway for messaging traffic to reach such a subscriber.

[0006] Further, said wireless communications system could then provide the user with control over a wide range of electronically-controllable devices using both wireless and wired communication."

It is clear from this that an object of the invention is to enable the user to control messages directed to him.

Summary of the invention

40. Given the dispute between the parties, this section merits quotation in full:

"[0007] In accordance with the teachings of the present invention as defined in the appended claims, a wireless communications system is provided that substantially eliminates or reduces problems associated with prior systems and methods of operation

[0008] According to one embodiment of the present invention, a communications system is provided that comprises a radio frequency transmission system operable to communicate with at least one subscriber device. The radio frequency transmission system is coupled to a messaging gateway system. The messaging gateway system is coupled to remote messaging system. The messaging gateway is operable to receive, for example, voice messages or notification of a voice message deposited in the remote messaging system intended for a user of a subscriber device from the remote messaging system. The messaging gateway is further operable to translate the messages received from the remote messaging system into a protocol which is able to be transmitted to the subscriber device by the radio frequency transmission system.

[0009] According to another embodiment of the present invention, the subscriber device is operable to generate messages that may be returned through the radio frequency transmission system to the messaging gateway system. The messaging gateway system may then either return the message to a remote messaging system in communication with the messaging gateway system or direct the message from the subscriber device to an alternate device through the radio frequency transmission system. Using the return communication pathway, the user of a subscriber device can manipulate a voice mailbox within a remote voice messaging system. In the alternative, the user of a subscriber device can direct messages to other subscriber devices or can direct control signals to systems controlled by remote system controllers."

41. The specification does not contain a conventional consistory clause, but paragraph [0007] does refer specifically to "the invention as defined in the appended claims". I shall discuss claim 1 below, but at this stage I note that this section of the specification goes on to highlight two aspects (referred to as "embodiments") of the invention.
42. Paragraph [0008] is concerned with the transmission of messages from the remote message system via the messaging gateway system and the radio frequency ("RF") transmission system to the subscriber device (i.e. the downlink). It discloses that the messaging gateway system can translate such messages into a protocol "which is able to be transmitted to the subscriber device by the [RF] transmission system".
43. Paragraph [0009] is concerned with the transmission of messages from the subscriber device via the RF transmission system and the messaging gateway system to the remote messaging system or another destination (i.e. the uplink). It discloses that the user of the subscriber device can (i) send a message to the remote messaging system or another device, (ii) manipulate a voice mailbox in the remote messaging system, (iii) direct messages to other subscriber devices or (iv) direct control signals to remote controlled systems. The sending of commands is not expressly mentioned, but the skilled reader would appreciate that what is described, particularly in cases (ii) and (iv), includes the sending of commands. No reference is made to protocol translation in this paragraph.

Brief description of the drawings

44. This section introduces four figures. These are block diagrams of the messaging system as a whole, the messaging gateway system, the remote system controller and the subscriber device respectively. I reproduce Figures 1 and 2 below:


Detailed description of the invention

45. System architecture. This section of the specification describes the overall architecture of the messaging system 10 by reference to Figure 1. The core of the messaging system comprises the remote messaging system 30, paging terminals 22 and 24, messaging gateway system 20, RF transmission system 12 and subscriber device 28. It may also include remote system controller 32 and remote controlled system 34.
46. The specification describes the paging terminals in paragraph [0012]. It states in paragraph [0013] that there may be a plurality of remote messaging systems, which "may comprise a variety of voice mail systems, electronic mail systems, facsimile transmission systems or other messaging facilities". In paragraph [0017] it gives a home alarm system as an example of a remote controlled system.
47. At paragraphs [0013]-[0014] the specification states:

"[0013] … The remote messaging system 30 transmits copies of messages or notifications of messages deposited in the system to the messaging gateway system using a variety of message transfer protocols.

[0014] For example, remote messaging system 30 may communicate with messaging gateway system 20 using the audio messaging interchange specification digital protocol (AMIS-Digital) or other public or proprietary message transfer protocols. The messaging gateway system 20 translates the voice messages received from the remote messaging system 30 into a protocol understood by the RF control system 14. The voice message may then be transferred from the RF control system 14 to the transmitter 16 where it can be transmitted using radio frequency signals to the subscriber device 28…."

This passage discloses translation by the messaging gateway system of messages received from the remote messaging system into a protocol which can be understood by the RF control system and then transmitted to the subscriber device.

48. At [0015] the specification states:

"An important technical advantage of the present invention inheres in the fact that subscriber device 28 also has the capability to transmit signals to RF control system 14 through receiver 18 which can be used to direct the actions of the remote messaging system 30. In this manner, a user of subscriber device 28 can instruct the remote messaging system 30 which, as described previously may comprise, for example, a voicemail system. A user of the subscriber device 28 can instruct the remote messaging system 30 to save messages, reply to messages, redirect messages, send new messages, hold messages, transmit messages that are currently on hold, or to configure restricted delivery of messages. In this manner, the subscriber device 28 is a remote control unit for a voice mailbox associated with the user of the subscriber device 28."

This passage discloses the use of the subscriber device to send instructions to the remote messaging system to save messages, reply to messages, etc. Although it does not use the word "command", the skilled reader would understand that such instructions are commands to control the operation of the remote messaging system.

49. The specification then states at [0016]:

"According to another aspect of the present invention, the subscriber device 28 can transmit signals to the RF control system 14 through the receiver 18 that are intended for a remote system controller 32 shown in FIGURE 1. The remote system controller 32 is coupled to and controls a remote-controlled system 34. The remote system controller 32 comprises circuitry similar to a subscriber device such as subscriber device 28 in that it is able to communicate with the RF control system 14 through the transmitter 16 and receiver 18. The remote system controller 32 receives commands initially generated by the subscriber device 28 from the transmitter 16 and instructs the remote-controlled system 34 responsive to the commands received. The commands are transmitted from the subscriber device 28 to the messaging gateway system 20 which interprets the commands and constructs a message for delivery to the remote system controller 32."

This passage discloses the use of the subscriber device to send commands to the remote controlled system. It says that the messaging gateway system "interprets the commands and constructs a message", but gives no detail of this.

50. Messaging gateway system. This section of the specification describes the messaging gateway system 20 by reference to Figure 2. It states at [0019] that in general the messaging gateway system "may comprise a plurality of software processes operating in a UNIX-based environment". It comprises a number of modules, including a series of protocol converters 40 to 52, interface control module 38, transaction control module 54, message construction module 56, action processor module 58 and database handler module 64.
51. The specification states in paragraphs [0019]-[0020] that the function of the protocol converters is to "convert messages" received from the remote messaging system in a particular protocol. A number of examples of protocols are given, including TIPP, TNPP, AMIS-Digital and so on. As the skilled reader would be aware, these are all application level protocols. The specification does not specify what these protocols are converted into, but the implication appears to be that they are converted into a common protocol used downstream in the messaging gateway system.
52. In paragraph [0021] the specification states:

"Under control of the transaction control module 54, a message construction module 56 operates to parse the messages received from the remote messaging systems 30 and to construct the messages to be transmitted to the RF transmission system 12 for delivery to subscriber device 28. In addition, message construction module 56 functions to receive messages through the RF transmission system 12 from subscriber device 28 or remote-controlled system 34 and to construct appropriate messages for delivery to remote messaging systems or subscriber device through the interface control module and the protocol converter systems 40 though 52."

The first sentence discloses that on the downlink the message construction module parses the messages received from the remote messaging system (which by this stage have already been through protocol conversion) and "constructs" the messages to be transmitted to the RF transmission and then to the subscriber device. The second sentence discloses that on the uplink the message construction module receives messages from the subscriber device and constructs messages for delivery through the protocol converters to the remote messaging system, but gives no further detail.

53. Remote system controller. This section describes the remote system controller by reference to Figure 3. The detail is immaterial for present purposes.
54. Subscriber device architecture. This section describes the subscriber device by reference to Figure 4. Most of the detail is immaterial for present purposes, save that paragraph [0029] states that the subscriber device has a control panel which may comprise either "a simple set of cursor control keys coupled with an 'execute' key for a menu-driven system" or "a full alphanumeric keyboard or numeric keyboard if subscriber device 28 is a command driven system".
55. Subscriber notification. This section of the specification describes the processing both of messages or notifications of messages to the subscriber and of the subscriber's responses. It begins:

"[0031] As discussed previously, the messaging system of the present invention enables the remote messaging system 30 to deposit copies of messages in the messaging gateway system 20. The messaging gateway system 20 can then construct pages that may be transmitted to the subscriber device 28 using the RF transmission system 12. In this manner, the user of the subscriber device 28 can have the entire message delivered or can be notified that he has a message waiting in the remote messaging system 30, ask that the message be forwarded to his subscriber device 28, and control the entire process by issuing commands from the subscriber device 28 that are relayed to the remote messaging system 30 by the messaging gateway system 20. Subscriber device 28 may also issue commands to messaging gateway system 20."

This passage discloses that the subscriber device can control the delivery of messages by issuing commands which are "relayed" by the messaging gateway system to the remote messaging system, but gives no details of this.

56. Paragraph [0032] explains that the messaging gateway system may deliver either a notification of a message or an entire message as appropriate:

"Due to the large amount of data required to encode the voice messages, the transfer of such messages between systems represents a significant expense. As such, sending only a notification packet eliminates the need to replicate the data of the message itself in the remote messaging system 30 and the messaging gateway system 20. However, under some circumstances, the convenience of foregoing the notification process and transmitting the entire message in the first instance may outweigh this expense."

57. Paragraphs [0033]-[0039] describe the delivery of a notification or an entire message from the remote messaging system via the messaging gateway system to the subscriber device. In paragraph [0036] the specification states that during passage through the messaging gateway system:

"The message construction module 56 creates a notification page that includes response options based on the information obtained from the deposited message or the notification packet and information defined in the subscriber's portfolio database. In the case where an entire message is sent as opposed to a notification, the message construction module 56 will construct a page from the deposited message and add response options based on information obtained from the message and information defined in the subscriber's portfolio database."

58. Paragraphs [0040]-[0050] describe the delivery of commands from the subscriber device to the remote messaging system via the messaging gateway system. Paragraphs [0040]-[0041] say that, once the notification or message has arrived, the subscriber views it and his options on the subscriber device and selects a response from the options listed using the control panel. The subscriber device constructs a response packet which is transmitted via the RF transmission system to the messaging gateway system where it is stored in the database handler module.
59. The processing of the response packet by the messaging gateway system is described in an important passage at paragraphs [0042]-[0043] as follows:

"[0042] The action processor module 58 retrieves and decodes the subscriber response packet and instructs the message construction module 56 to create a command packet instructing remote messaging system 30 to perform the actions requested by the subscriber. Control then passes to the message construction module 56. The message construction module 56 then constructs a command packet responsive to the subscriber's request and notifies the transaction control module 54 that the packet is ready for delivery to the remote messaging system 30. ….

[0043] …. Control then passes to the interface control module 38 which delivers the command packet to the remote messaging system 30 through an appropriate protocol converter 40 through 52."

I note that paragraph [0042] says that the message construction module "constructs a command packet", but says nothing about protocol translation. Paragraph [0043] says that the command packet is delivered "through" the appropriate protocol converter, but no details are given about the protocol conversion.

60. Paragraphs [0044]-[0048] describe the delivery of an acknowledgement once the command has been performed.
61. This section of the specification concludes:

"[0049] As discussed previously, in one typical circumstance, the subscriber will first be notified of one or more messages in the remote messaging system 30 through a notification page. The subscriber will be presented with a menu identifying the existing messages and giving the subscriber options on what to do with each of the messages. At this point, the subscriber has the choice of requesting retrieval of the messages using his subscriber device 28 or retrieving his messages using other means. According to one embodiment of the present invention, the message notification packet includes information as to the size of the message. In this manner, the subscriber can decide whether or not it is economical to utilize the messaging system 10 to retrieve such a message or whether or not resources are adequate to retrieve such a message.

[0050] As discussed previously, any command that could be issued directly to remote messaging system 30 can also be issued using messaging system 10. For example, the subscriber may choose to save, delete, forward, reply, or perform other actions in response to the receipt of a message. Each of these actions is encoded in a command packet which is delivered as described through the messaging gateway system 20 to the remote messaging system 30."

I note that paragraph [0050] says that "any command that could be issued directly to the remote messaging system [emphasis added]" can also be issued by the subscriber using the messaging system i.e. from the subscriber device. Such commands are "encoded in a command packet" which is delivered "through" the messaging gateway system to the remote messaging system. There is no reference in this paragraph to protocol translation unless the skilled reader understands the words "as described" as including reference to passage through the protocol converters.

62. Subscriber-initiated commands to remote units. This section of the specification describes how the subscriber may use the subscriber device to initiate commands to control the remote controlled system and the remote messaging system or to send a message to another subscriber device. The procedure described in paragraphs [0051]-[0073] is similar to that previously described for sending commands to the remote messaging system, but with one extra step. First, the subscriber selects a "portfolio option" on the subscriber device. A request packet is then sent via the RF transmission system to the messaging gateway system. In response a menu is sent to the subscriber device. The subscriber then selects from the options in the menu. Again, a request packet is then sent via the RF transmission system to the messaging gateway system. The messaging gateway system creates a command packet which is delivered to the appropriate destination. Finally, an acknowledgement is sent back to the subscriber.
63. The creation of the command packet by the messaging gateway system is described in paragraphs [0061]-[0062] as follows:

"[0061] … Control is then passed to the action processor module 58 which decodes the response packet and instructs the message construction module to create either a command packet or a page based upon the options selected by the subscriber. Control is then passed to the message construction module 56 that creates a command packet or a page for delivery to at least three types of destinations. The command packet or page may first be intended for use by the remote-controlled system 34 using the remote system controller 32. Secondly, as previously described, the command packet could be intended for delivery to a remote messaging system such as remote messaging system 30. In this case, the command packet would include a command intended to manipulate, for example, a voice mailbox within remote messaging system 30. The third possible destination is another subscriber device. In this manner, the subscriber using subscriber device 28 can create a message or page and transmit it to another subscriber device using RF transmission system 12 and messaging gateway system 20.

[0062] … Transaction control module 54 then passes control to the interface control module 38. The interface control module then delivers the command packet to remote messaging system 30 through the appropriate protocol converter 40 through 52…."

Again the reader is told in [0061] that the message construction module "creates a command packet" (or a page), but nothing is said about protocol conversion. Likewise, the reader is again told in [0062] that the command packet is delivered "through" the appropriate protocol converter, but no details are given about the protocol conversion.

64. This section concludes at paragraph [0074] as follows:

"Utilizing the unique capabilities of messaging gateway system 20, a subscriber can choose from a portfolio of options programmed into messaging gateway system 20 to generate pages to other subscribers, to command remote units which are controlled by system controllers such as remote system controller 32, or to command remote messaging systems such as remote messaging system 30. In this manner, a subscriber device such as subscriber device 28 allows not only for the communication of paging messages to the subscriber but also for the generation of messages and the remote control of a variety of systems."

65. Voicemail system interface. This section of the specification describes the delivery of messages from the remote messaging system to the subscriber device and the control of the remote messaging system using the subscriber device. It is particularly concerned with voice messages, but it is not restricted to voicemail.
66. Paragraph [0076] states:

"As described previously, the messaging gateway system 20 not only accepts copies of voice messages from disparate voicemail systems using industry standard message transfer protocols such as AMIS-Digital or AMIS-Analog or vendor-specific protocols, it also accepts message notification packets received from the remote messaging system such as remote messaging system 30. The message notification packets may include the identification of the originator in either text or voice form, the identification of the message priority, the date and time stamp of the message deposit, the identification of the originating telephone number of the message, the message sequence number, the length of the message in seconds, the size in bytes of the compressed digitized message file, and the identification of the transferring voicemail system. Because other types of messaging systems such as electronic mail or facsimile machines may also communicate with messaging gateway system 20, the message type is also included in the notification packets."

This passage discloses that notification packets "may include" the following information: (i) identity of the originator, (ii) message priority, (iii) date and time, (iv) originating telephone number, (v) message sequence number, (vi) the duration of the message in seconds, (vii) the size of the message in bytes and (viii) the identity of the originating system and (ix) the type of message (voicemail or email etc).

67. The specification goes on to say in paragraph [0077] that, when a new message is received from the remote messaging system, the messaging gateway system may either send the subscriber the message with response options or a notification with response options. In the latter case:

"The notification page includes all or a portion of the previously mentioned information describing the message."

68. The reasons for sending such notifications are explained further at paragraphs [0078]-[0079]:

"[0078] According to one embodiment of the present invention, a subscriber may choose to receive message notifications regarding certain types of messages and the message itself for other types of messages. For example, messages from a particular source or of a particular urgency would not require a message notification packet but would merely be delivered in the first instance. However, messages of normal urgency or messages from non-selected sources would first generate a message notification packet to the subscriber to allow the subscriber the option of retrieving the messages using other means or disregarding the message altogether.

[0079] In addition, a subscriber may choose for economic reasons to always receive a message notification packet when a message is of a particular size. For example, a subscriber could specify that if the size of the digitized message file exceeds a certain parameter, a message notification packet only is to be sent. But, if the message file is smaller than the same parameter or a different parameter, the message itself is to be sent in the first instance. In this manner, a subscriber can maximize the economic utility of the message delivery capabilities of messaging system 10."

69. In paragraph [0080] the specification states:

"As described previously, the messaging gateway system 20 utilizes protocol converters 40 through 52 to accept a variety of message transfer protocols and to translate these protocols into formats associated with the RF transmission system 12. The transmission format may comprise a conventional paging format such as Motorola, Inc.'s InFLEXion™ format for delivery to voice paging devices or ReFLEX™ format for delivery of alphanumeric/data to paging devices. In the alternative, the transmission format could comprise a conventional multimedia format such as the .WAV file format for delivery to multimedia personal computers or personal communicators."

This paragraph discloses that the protocol converters in the messaging gateway system translate message transfer protocols (such as TIPP etc) into "formats associated with" (i.e. protocols suitable for transmission by) the RF transmission system (such as InFLEXion and reFLEX). Once again, however, no detail is given of such translation.

The claim

70. The only claim in issue is claim 1. Broken down into integers, this is as follows:

"[1] A method of operating a messaging gateway system (20)

[2] operable to receive messages from a remote messaging system (30),

[3] and to construct transmittable messages including portions of the messages received from the remote messaging system,

the method characterised by the messaging gateway system (20):

[4] receiving a set of commands from a wireless subscriber device (28) using an RF transmission system;

[5] translating the set of commands into a protocol understood by the remote messaging system; and

[6] transmitting the translated commands to the remote messaging system such that a user of the subscriber device can control the operation of the remote messaging system utilizing commands transmitted to the remote messaging system."

The person skilled in the art

71. A patent specification is addressed to those likely to have a practical interest in the subject matter of the invention, and such persons are those with practical knowledge and experience of the kind of work in which the invention is intended to be used. The addressee comes to a reading of the specification with the common general knowledge of persons skilled in the relevant art, and he (or, once and for all, she) reads it knowing that its purpose is to describe and demarcate an invention. He is unimaginative and has no inventive capacity.
72. By the end of the trial there was not much dispute between the parties as to the identity and attributes of the skilled person to whom Beletic is addressed. He would be a communications network engineer with a degree in electrical engineering or computer science and a few years' experience in industry. He would need to have good understanding of network technologies (both wireless and wired) and how to internetwork between them. He would need a working knowledge of messaging systems such as pagers, email and voicemail and of the common protocols used by them. He would also need some knowledge of software development, in particular the use of common application programming interfaces (APIs), but he would not be a programmer. He would not need to be an expert in radio. Nor would he be involved in the design of protocols.

Common general knowledge

73. The law as to what constitutes common general knowledge is set out in the decisions of the Court of Appeal in General Tire & Rubber Co v Firestone Tyre & Rubber Co Ltd [1972] RPC 457 at 482-483 and Beloit Technologies Inc v Valmet Paper Machinery Inc [1997] RPC 489 at 494-495. As Aldous LJ pointed out in Beloit, it can be difficult to distinguish between information that was known to some, and perhaps many, in the field and information that was common general knowledge, but it is important to do so.
74. By the end of the trial there was little, if any, dispute that all the matters I have set out in the technical background section above would have formed part of the skilled person's common general knowledge. There was, however, a major issue between the parties as to whether application level command protocol translation (or conversion) by gateways was common general knowledge, and in particular whether it was common general knowledge in the context of email systems. RIM contend that it was, but Motorola vigorously dispute this.
75. It is necessary first to be clear what is meant by "application level command protocol translation (or conversion)". It means translating (or converting) the commands used in one application level protocol into the command used in another application level protocol, for example translating a RETR msg command in one protocol into a FETCH command in another protocol. It should be noted that Motorola say that there is a distinction between translating commands on the one hand and translating other things, such as message formats, on the other hand. I shall return to that point below.
76. Before attempting to resolve the dispute, it is convenient to identify five matters which are not in dispute. First, it is common ground that it was well known to install multiple client programs on a networked device, each using their own protocol to communicate with respective server programs. RIM say, however, that it was also well known that the alternative was to translate between protocols at whatever level of the stack was necessary.
77. Secondly, Motorola accept that protocol translation at lower layers of the protocol stack by gateways was not merely commonplace but inevitable.
78. Thirdly, I do not understand Motorola to dispute that, in contexts other than messaging, application level command protocol translation was common general knowledge by March 1995. Professor Wolff gave the example of database access software. As he explained, the concept of "federated databases", which included a command translator to manage different database systems, was well established by then. He gave as an instance of a high profile product Oracle's Oracle In Motion product released in September 1994, which used middleware to enable wireless users to access multiple types of databases.
79. Fourthly, Motorola accept that in the email context conversion between application level protocols such as SMTP and MHS was common general knowledge by March 1995. Motorola say, however, that protocol translation of that kind was confined to transport protocols and not command protocols, that is to say, translation of message formats and not actual commands.
80. Fifthly, Motorola accept that RIM have proved one disclosure of application level command protocol translation in the email context dating from before March 1995. Motorola say, however, that this was a very obscure disclosure.
81. Professor Wolff expressed the opinion in his reports that protocol conversion, including application level command protocol translation, was common general knowledge in March 1995 both in general and specifically in the email context. Although pressed on the point in cross-examination, he did not resile from that view. On the contrary, he explained that it was one of two logical and well-known alternatives:

"Q. OK, but in terms of systems around at the time, the absolutely

orthodox approach was for the client to speak the language of

the server. There were not systems that did not speak the

language of the server in other contexts, were there?

A. Well, my Lord, I am not sure how to answer the question.

I mean, on the one hand, if a system did not speak, if

a client did not speak the language of a server, they were not

going to have a conversation. So one has to have a common

language, otherwise communication is not going to happen. You

have two choices. Choice 1 is the client speaks the language

of the server; choice 2 is, you have an intermediary that

translates from one language to the other and both

possibilities were well-known at that time."

82. In his reports Mr Wiffen accepted that two aspects of protocol conversion by gateways were very well known, namely translation of the lower layers and using gateways to change the format of emails at the application level, but he did not agree that command translation was well known. In cross-examination, however, he accepted that command translation was well known subject to one qualification:

Q. And such a person would know that if system A wished to

communicate with system B you would have to convert at

whatever protocol level was incompatible.

A. Yes.

Q. I mean, that is just like night follows day.

A. Yes.

Q. And there was no conception in March 1995 that we protocol

convert up to level 2 but we never convert at application

levels?

A. No. If I can qualify that in terms of depending on the

functionality, where you are trying to convey information from

and to and I also think it is important to appreciate the

difference between the conversion of a protocol as in its

format and its data structures and the conversion of protocol

commands that are influencing a remote system as opposed to

just for delivery to a system.

Q. If, for example, you are moving from an HTTP system to an [FTP],

you have to translate the commands. HTTP get has to change

into an [FTP] -- store? Retrieve?

A. If it was a get, it would be a get actually. So that is not

a great one.

Q. It is retrieve.

A. Retrieve, yes.

Q. So there is nothing magic about not translating commands. If

the commands needed to be translated, they would be

translated.

A. Yes. If there was a requirement to translate at the

application layer as a consequence of there being two

protocols for a different purpose, which is what that would

amount to in that instance, then, yes.

The example under discussion here is file transfer. I will return to Mr Wiffen's qualification below.

83. More generally, Mr Wiffen agreed that it was common general knowledge that there were two basic approaches, namely the dual stack and protocol conversion approaches, and that in the case of the latter approach, one would convert so far as necessary including up to the application level:

Q. It would be common general knowledge to anybody having to deal

with a need to access to heterogeneous protocols that you

either have a dual stack or you do a conversion.

A. A conversion at some point, yes.

Q. If you say, dual stack is clumsy, I am going to convert and

I think you have agreed this, you convert as far as necessary.

A. Yes, as far as was appropriate for the thing that you

are trying to ----

Q. Which may take you right up to the top of the stack.

A. Yes.

84. Professor Wolff exhibited various articles and documents to his reports to support his opinion. First, he exhibited an email dated 19 November 1990 (over four years before the priority date of Beletic) announcing a new release of the IMAP2 (i.e. IMAP version 2) distributed email system which states that it includes "a POP->IMAP gateway to allow you to leverage on your existing POP-based PC clients yet still use IMAPware". As noted above, Motorola accepted that this email disclosed application level command protocol conversion in the email context, but submitted that it was a very obscure document. That may be so (as Professor Wolff explained, he was supplied with the document as part of his instructions), but it is beside the point. As Professor Wolff explained in his report, and as Mr Wiffen accepted in cross-examination, the system in question was developed by a team at the University of Washington who were responsible for the IMAP standards. Thus it was not an obscure system, and it was not suggested to Professor Wolff in cross-examination that it was. Mr Wiffen's evidence was that he could not say whether this system was common general knowledge: it might or might not have been. I am not satisfied that this particular system was common general knowledge, but I am satisfied that it is evidence which supports the proposition that the concept of application level command protocol conversion would have been well known by 1995, including in the email context.
85. Secondly, Professor Wolff exhibited a paper by authors at the US National Bureau of Standards describing an SMTP (RFC 821) to MHS (X.400) gateway. This describes how SMTP headings are mapped to MHS parameters and vice-versa. Professor Wolff's view was that this was an example of the translation of the syntax and semantics of one email protocol into another. He did not see the distinction between this and translating commands. During cross-examination, Mr Wiffen accepted that SMTP to X.400 (i.e. MHS) conversion involved command translation:

Q. So in SMTP to X.400 you are translating commands. I can show you --

A. Yes, that is correct.

Q. So even in email, as at March 95 there was no line in the sand that there

is some golden rule that we do not translate at the application level?

A. No. Again, if I can just qualify that in terms of delivery, yes, I agree.

The qualification referred to is the same one which Mr Wiffen made in the first extract quoted above. This is that there is a distinction between converting formats for the onward transmission of data and converting commands to control a remote system.

86. As I will explain when I come to deal with construction, I accept that there is a distinction; but it is fine one. In both cases there is application level protocol translation of data necessary for the successful implementation of the user's instructions. Moreover, the two types of data are closely related. Thus the paper in question expressly mentions some of the relevant SMTP commands (MAIL and RCPT) when setting out the mapping of the headers. Furthermore, as can be seen from the extracts I have quoted, Mr Wiffen was prepared to accept that both types of operation could be described as command translation. Finally, the distinction breaks down when one comes to consider applications such as database access (see above) and file transfer (see below). Accordingly, I do not accept that the skilled person would have compartmentalised his knowledge about format translation in the way that Motorola suggest.
87. Thirdly, Professor Wolff exhibited an article entitled "The SNATCH Gateway: Translation of Higher Level Protocols" published by authors from the German Aerospace Research Establishment as long ago as 1980. This proposes translating protocols at all levels including the application level. There is no express discussion of command translation, although that falls within the generality of what is proposed. In my view this supports the general proposition that application level protocol translation would have been well known by 1995, but not specifically command translation.
88. Fourthly, Professor Wolff exhibited a paper entitled "Interconnecting Heterogeneous Computer Systems" published by authors from the University of Washington in 1988. This discusses using a single email client to interoperate multiple heterogeneous email systems by means of an intermediary carrying out application level protocol translation. Again, there is no express discussion of command translation, but that falls within the generality of what is proposed. Again, I consider that this supports the general proposition that application level protocol translation would have been well known by 1995, but not specifically command translation.
89. In addition, Professor Wolff pointed to the knowledge that the skilled person would have about middleware and proxies (as to which, see above). This too supports the general proposition, but not the specific.
90. Further documents were produced by RIM for cross-examination of Mr Wiffen. Not all of these were put to Mr Wiffen in the end, but two were. The first is a paper entitled "Transition and Coexistence Strategies for TCP/IP and OSI" published by Marshall Rose, who was the author of the POP3 specification, in 1990. In this paper, Rose discusses "protocol-based" approaches to internetworking between networks based on two different protocol suites. He considers two approaches: the "dual-stack approach" and the "application-gateway approach". The dual-stack approach is "simple in concept: put both protocol suites in all hosts", but "may be unacceptable for both administrative and technical reasons." The application-gateway approach is "a well-known … technology used to achieve interoperability between similar applications from different protocol suites … This strategy joins together two different application protocols and applies some sort of translation between the two." Rose gives as an example use of a gateway to translate between MHS and SMTP. He goes on to discuss in some detail another example, namely file transfer between two computers using different protocols in which a gateway translates between the two. This includes translation of application level commands, e.g. STOR in FTP is translated to F-SELECT, F-OPEN and F-WRITE in FTAM. Thus this article mentions protocol translation between different email protocols and command protocol translation (albeit in the context of file transfer) virtually in the same breath. Moreover, it says that such technology was well known even in 1990. In my view this provides support for Professor Wolff's opinion.
91. The second is a paper entitled "Integrating Heterogeneous Local Mail Systems", again by authors at the University of Washington, published in 1989. This describes an integrated heterogeneous email system which the authors have implemented using clients that communicate with an intermediary server. The client uses a simple set of commands to communicate with the server and the server relays that command on to the relevant mail servers via a series of modules called "mail semantic managers". The paper describes the function of these as follows:

"The abstract interface exported by the mail semantic managers to the system server supports the interconnection of individual mail systems. All mail systems -- no matter how primitive or sophisticated -- provide basic submission, delivery, and retrieval operations. All mail semantic managers export an interface that has a generic version of these three operations:

GetMessages returns the messages stored in repositories managed by the mail semantic manager.

DeleteMessages removes the specified list of messages.

SendMessages delivers a message to the specified recipient list.

Each mail semantic manager implements this abstract interface using the underlying operations of the mail system it manages."

Mr Wiffen's reading of the paper was that the mail semantic manager had to be duplicated on the mail system server, but nevertheless he ultimately accepted that this was describing application level command protocol translation in the context of email systems. Again, therefore, this supports Professor Wolff's opinion.

92. Having considered all the evidence with care, I conclude that RIM have established that application level command protocol translation was common general knowledge, including in the context of emails.

Construction

93. The task for the court when construing a patent claim is to determine what the person skilled in the art would have understood the patentee to have been using the language of the claim to mean: see Kirin Amgen Inc v Hoechst Marion Roussel Ltd [2004] UKHL 46, [2005] RPC 9 at [30]-[35]. In that case the list of principles to be found in the judgment of Jacob LJ in Technip France SA's Patent [2004] EWCA Civ 381, [2004] RPC 46 at [41] was approved subject to one point.
94. As the Court of Appeal has recently held in Virgin Atlantic Airways Ltd v Premium Aircraft Interiors UK Ltd [2009] EWCA Civ 1062, the skilled person is taken to know not merely the purpose of the claim, but also the purpose of, for example, dividing it into a pre-characterising portion and a characterising portion.

General

95. It is common ground that claim 1 covers a method of operating a messaging gateway system where there is only one remote messaging system and one subscriber device.
96. It is also common ground that the skilled person would understand that integers [1]-[3] of the claim were old, whereas integers [4]-[6] were claimed to be new and inventive. This does not particularly assist in interpretation, however, since the specification is not clear as to the prior art upon which the pre-characterising clause is based.

Messaging gateway system

97. The messaging gateway system is the gateway between the wired networks, and thus the remote messaging system and the paging terminals, on the one hand, and the wireless networks, and thus the subscriber device and the remote controlled system, on the other hand. The main functions of the messaging gateway system are those specified in the claim, viz. (i) receiving messages from the remote messaging system, (ii) constructing transmittable messages including portions of messages (for delivery to the subscriber device), (iii) receiving commands from the subscriber device, (iv) translating the commands into a protocol understood by the remote messaging system and (v) transmitting the translated commands to the remote messaging system (via the RF transmission system).
98. In Figure 2 all the components of the messaging gateway system are shown on a common communications bus 36. This suggests that the messaging gateway system in the specific embodiment is a single computer. The claim refers generally to a "system", however. RIM accept that there is no technical reason apparent from the specification for limiting the system to a single computer, and thus that the system can extend to a distributed system comprising a plurality of computers on the same LAN. RIM contend, however, that the system does not extend to computers spread over different networks, separated by firewalls and under different administrative control. I do not accept this. Although Beletic does not disclose a distributed system of that kind, I can see nothing in the specification that would suggest to the skilled reader that the patentee intended to exclude such a system.
99. RIM also point out that the key function of the messaging gateway system, having regard to the characterising portion of the claim, is command protocol translation. This is particularly so if that part of the claim is construed as Motorola contend (as to which, see below). Accordingly, RIM contend that a unit which does not carry out any command protocol translation, but is merely connected to a gateway which does perform such translation, is not part of the messaging gateway system. In my view this may or may not be correct depending on what the unit does and its relationship with the gateway. If the unit is quite distinct from the gateway, then it may well be correct. If the unit performs some functions required of the messaging gateway system, the gateway performs other functions and the two cooperate, then it may well not be.

Remote messaging system

100. There is nothing in the specification to indicate what is meant by "remote". Nor did either party suggest that it was a term of art with a clearly defined meaning. It is common ground that, in order to be "remote", the messaging system must be both logically and physically separate from the messaging gateway system. It is also common ground that they may be geographically remote. Motorola contend that "remote" embraces messaging systems which are on the same LAN as the messaging gateway system, whereas RIM contend that they must be geographically remote i.e. connected by a WAN rather than a LAN. I have to say that I incline to the view that "remote" means remote from the subscriber device, and refers to the fact that there is a wireless link between the subscriber device and both the remote messaging system and the remote controlled system. Putting that on one side, I can see nothing in the specification that would suggest to the skilled reader that the patentee intended to exclude a messaging system connected to the messaging gateway system by a LAN.
101. A point which I did not understand to be disputed is that the remote messaging system is not necessarily an email system. It is clear from e.g. paragraphs [0013] and [0015] of the specification that it may be a voicemail system.

Transmittable messages

102. Three interpretations of this expression have been advanced:

i) RIM contend that it means messages in a form which can be transmitted by the RF transmission system to the subscriber device i.e. immediately prior to RF modulation.

ii) Mr Wiffen suggested during the course of cross-examination that it meant messages in a form in which they can be received by the entry point to the wireless network.

iii) Motorola contend that it means messages which are in a suitable format for communication to the subscriber device, that is to say, expressed in the right application level protocol.

103. The specification does not use the expression "transmittable messages". Interpreted literally, it means "messages that can be transmitted". That invites the question "transmitted by what?" The obvious answer is "by the RF transmission system". This interpretation is supported by paragraphs [0008] ("to translate the messages received from the remote messaging system into a protocol which is able to be transmitted to the subscriber device by the radio frequency transmission system") and [0021] ("to construct the messages to be transmitted to the RF transmission system 12 for delivery to subscriber device") of the specification, and to lesser extent paragraphs [0014] ("translates the voice messages received from the remote messaging system 30 into a protocol understood by the RF control system 14. The voice message may then be … transmitted using radio frequency signals to the subscriber device") and [0080] ("to translate these protocols into formats associated with the RF transmission system").
104. It is also supported by the way in which the specific embodiment functions. In short, the transmittable messages are constructed by the message construction module in the messaging gateway system and then passed to the RF transmission system for transmission to the subscriber device. There is no suggestion that the RF transmission system undertakes further protocol conversion on the transmittable messages. On the contrary, paragraph [0080] clearly indicates that messages are translated by the messaging gateway system into a format suitable for RF transmission.
105. More generally, it is supported by considering the technical purpose of integer [3] of the claim. The fundamental role of the messaging gateway system, which is reflected in this integer, is to act as a gateway between the wired network and the wireless network. Furthermore, it is clear from the specification that a key aspect of the operation of the messaging gateway system is that it can send notifications to the subscriber device instead of complete messages where this is more economical: see paragraphs [0032] and [0076]-[0079]. Thus the messaging gateway system is also a generator of messages. Either way, it is the function of the messaging gateway system to put the messages into a form which can be transmitted across the wireless network to the subscriber device.
106. Motorola submit that this interpretation is inconsistent with Figure 1. I disagree. There is nothing in Figure 1 to suggest that the messages must undergo further (lower layer) protocol conversion within the RF system. Nor does the specification suggest this.
107. Motorola also submit that on this interpretation a message in .wav format would not be a transmittable message. Again, I disagree. First, the evidence does not establish a .wav file is not without more suitable for RF transmission. Secondly, even if that were the case, the natural reading of paragraph [0080] is that the messaging gateway system carries out any necessary additional (lower layer) protocol conversion.
108. Finally, Motorola submit that this interpretation is inconsistent with the fact that the specification says that the message or notification may be delivered to the RF transmission system either directly or via the paging terminal 22: see e.g. paragraph [0037]. Once again, I disagree. There is nothing in the specification to suggest that in such circumstances the paging terminal will convert the message into a different protocol. On the contrary, the implication is the reverse: it can be sent via the paging terminal because it is already in a format suitable for RF transmission such as those mentioned in paragraph [0080].
109. In my judgment Motorola's interpretation robs the word "transmittable" of meaning and effect: it amounts to saying nothing more than that the message can be understood by the subscriber device. But if that were not the case it would not be a message at all.
110. Mr Wiffen's interpretation is preferable to Motorola's in that it gives the expression some meaning and effect. In my view it is simply not one which finds any support in the specification, however.
111. For all these reasons, I prefer RIM's interpretation.

Portions of the messages

112. There are two disputes about this feature of the claim.
113. First, does it include entire messages? RIM contend that it does, Motorola contend that it does not. In my judgment it is clear from the specification that the claimed method involves the transmission of portions of messages where appropriate. A method does not fall outside the claim merely because entire messages are constructed and transmitted when that is considered appropriate. But the method must involve sending portions of messages at least some of the time.
114. Second, what counts as a "portion" of a message? The specification does not use the expression "portions of messages". Motorola contend that it requires the presence of part of the content of the message. RIM submits that information such as the source and size of the message count as a portion. Both sides rely upon paragraphs [0076]-[0077] of the specification as supporting their respective interpretations. As a matter of language, this passage lends some support to Motorola's interpretation since paragraph [0077] refers to "a portion of the previously mentioned information describing the message [emphasis added]". In my judgment, however, to interpret "portions of messages" in contradiction to this wording would be to elevate fine linguistic distinctions above the technical purpose of this feature of the claim. As the specification makes clear, the purposes of being able to construct "portions of messages" and send them to the subscriber device instead of entire messages are (i) to give the user more control and (ii) for reasons of economy having regard to the limited bandwith of the wireless network and the restricted capabilities of the subscriber device. For these purposes, it is clear from the specification that information about the source and/or size of the message is precisely the kind of information that the messaging gateway system should be capable of sending. I do not see any difficulty in interpreting the expression "portions of messages" as including the source of the message or its size, and for the reasons I have explained I consider that the skilled reader would think that the patentee intended to include such information within the expression.

A set of commands

115. It is common ground that a "set" of commands means at least two. There is dispute, however, as to what constitutes a "command". Motorola contend that a command is an instruction to (in the words of integer [6] of the claim) "control the operation of the remote messaging system", that is to say, an instruction of the kind referred to in paragraphs [0015] and [0050] of the specification, namely save, delete, forward, reply etc. RIM contend that the word "command" should be more broadly interpreted, and embraces e.g. instructions for the onward transmission of an email contained in its headers.
116. It is clear from Mr Wiffen's evidence quoted above that the word "command" is capable of embracing instructions of the latter kind. Nevertheless, there is a distinction between instructions that affect the onward transmission of an email and instructions to control the operation of a remote server. This is a distinction which is reflected, for example, in the difference between SMTP and MHS on the one hand and POP3 and IMAP4 on the other hand. In the context of the claim, I consider that the word should be interpreted as Motorola contend. The claim virtually provides its own definition in this respect, and that definition is supported by the teaching of the specification.

Translating a set of commands into a protocol understood by the remote messaging system

117. The most important issue on construction concerns integer [5] of the claim. Motorola contend that this requires translation of the commands at the application level. RIM contend that it embraces translation of the commands at any level of the stack.
118. It is this issue of construction which gives rise to the dispute as to the disclosure of Beletic which I mentioned above. There is a fundamental disagreement between the parties as to what invention is disclosed by Beletic. RIM contend that, although the words of the claim are broad enough to cover application level command protocol translation, Beletic does not actually disclose this at all, still less that it is central to the invention. RIM say that it follows that the skilled person would not interpret the claim as being restricted to application level command protocol translation. Motorola contend that application level command protocol translation is disclosed in Beletic, and moreover represents the key inventive advance. Accordingly, Motorola say that the claim should be interpreted as requiring such translation.
119. In considering Motorola's contentions, it is important to bear in mind that it is Motorola's case that, not only was application level command protocol translation not common general knowledge, but on the contrary it represented a "new way of thinking" (to quote Motorola's opening skeleton) for the skilled person. Since I have found that application level command protocol translation was common general knowledge, it follows that I do not accept that that is the case. Nevertheless, I agree with RIM that, if that were the case, one would expect application level command protocol translation clearly to be disclosed by Beletic. On any view, it is not.
120. It is worth elaborating on this point slightly. Motorola say that the advantage of the claimed method is that one can have a single client program on the subscriber device which offers the user a generic list of commands (read, send, forward, reply, etc) and then translates them into a variety of command protocols used by differing remote messaging systems. This in turn is said to have a number of benefits. But nowhere does the specification say that the method does this.
121. It is for the court, once properly instructed as to the common general knowledge of the skilled reader, to interpret the disclosure of a patent. Nevertheless, the evidence of the rival experts is instructive.
122. Professor Wolff approached Beletic on the basis that application level command protocol translation was common general knowledge. Reading Beletic in that light, he agreed that the system disclosed might perform application level command protocol translation, but considered that the specification did not make this clear, let alone that it was required or what the benefit of doing so was. His view was that two possibilities would be obvious to the skilled reader considering how to implement Beletic. One was for the subscriber device to send the actual commands used by the remote messaging system. This would still require protocol translation, but at lower layers than the application level. The other was for the subscriber device to send a command which would require some degree of translation by the messaging gateway system to be recognised by the remote messaging system, for example translating a numeral or other abbreviation into a full command. This would require application level command protocol translation. There would be advantages and disadvantages to either option. This evidence was not challenged in cross-examination. Furthermore, although counsel for Motorola submitted that Professor Wolff's reading of Beletic had changed between his first and second reports, that was not put to him in cross-examination.
123. Mr Wiffen approached Beletic on the basis that application level command protocol translation was not common general knowledge. Despite reading Beletic in that light, he nevertheless considered that it disclosed application level command protocol translation. In his first report he mainly relied upon paragraphs [0016], [0042]-[0044] and [0061] in support of this interpretation. He did not mention any paragraph after [0061]. Nor did he refer to any additional paragraphs in his second report. In cross-examination he was taken sequentially through the specification. He accepted that there was nothing in the specification up to paragraph [0051] which taught application level command translation. His evidence was that this was first suggested by paragraph [0061] when read together with paragraph [0051], but he accepted that the teaching of those paragraphs could be carried out without application level command protocol translation. He also relied on paragraphs [0077], [0078] and [0081] read together with [0033], but was unable to point to anything in those paragraphs which specifically disclosed application level command protocol translation. He agreed that he had read Beletic a considerable number of times. He accepted that the exercise he had engaged in amounted to detective work, because there was no clear description. He also accepted that it was possible that he was influenced by hindsight.
124. In relation to the prior art, counsel for Motorola relied on what Pumfrey J (as he then was) said in Hewlett Packard GmbH v Waters Corp [2002] IP&T 5 at [32]:

"Mr Wyand submitted that it is the task of the court to determine what Saito clearly and distinctly taught the skilled person at the priority date, not what can be read out of Saito by the application of hermeneutical stress. This admirable phrase concisely describes the process of squeezing a document to extract every last drop of meaning. The submission is correct: to anticipate, a document must contain a clear description of, or clear and unmistakable directions to do or make, something within the claim …. When considering obviousness, on the other hand, ambiguities in the disclosure of the document may be obviously capable of resolution in a particular way without the exercise of ingenuity: but it is not legitimate to try to resolve obscurity by an exercise in imaginative reconstruction to ascertain what it was that the [prior] patentee must have been trying to describe."

It is not appropriate to apply imaginative reconstruction to interpret the patent in suit either.

125. In order to ascertain what invention Beletic discloses, a good starting point is the section of the specification headed "Summary of the invention", since the skilled reader is entitled to assume that it summarises the invention. Other than by means of the cross-reference to the claims, this does not mention command translation at all, let alone application level command protocol translation. On the contrary, what is presented as being the invention is essentially the architecture of the system. Even when the reader comes to paragraph [0015], which discloses "an important technical advantage of the present invention", there is no mention of command translation at all, let alone application level command protocol translation
126. When pressed as to where Beletic disclosed application level command protocol translation, counsel for Motorola relied most strongly on the claim. He reminded me that it was the function of the claim to "define the matter for which protection is sought" in the words of Article 84 of the European Patent Convention, which of course I entirely accept. As noted above, it is common ground that the words of the claim are broad enough to cover application level command protocol translation. It does not follow that the claim discloses it: see A.C. Edwards Ltd v Acme Signs & Displays Ltd [1992] RPC 131. In my judgment the claim does not disclose it. The claim is entirely unspecific as to the level at which the command protocol translation occurs.
127. Next, counsel for Motorola relied upon the use of the word "interprets" in the last sentence of paragraph [0016]. This involves placing a weight upon a single word that it cannot possibly bear. There is nothing to suggest to the skilled reader than this involves application level command protocol translation, particularly if that concept is new to him as Motorola contend. (Matters are not assisted by the fact that, while the specification generally uses the words "message" and "command" in contradistinction, the sentence in question uses the word "message" when it probably means "command".)
128. Next, counsel for Motorola relied on paragraph [0042]. As noted above, however, that paragraph simply says that the message construction module constructs a command packet. It says nothing about protocol translation at all, let alone at what level of the stack. Furthermore, paragraph [0043] says that the command packet is delivered to the remote messaging system via a protocol converter. That discloses protocol translation, but does not disclose application level command protocol translation. On the contrary, Professor Wolff gave unchallenged evidence that the protocol converters shown in Figure 2 and described at paragraphs [0019]-[0020] would not be suitable for application level command protocol translation of the kind contended for by Motorola e.g. none of them would enable retrieval of emails from a mail server. Thus, if anything, this suggests that protocol translation is only occurring at lower layers.
129. This point is highlighted by the response of counsel for Motorola when I asked him where in the messaging gateway system described in the specification the protocol translation required by the claim was carried out. His answer was that it was carried out by the message construction module, not by the protocol converters. Thus Motorola's construction involves ascribing to the message construction module a function which the specification nowhere suggests that it has, and ignoring the functionality of other parts of the messaging gateway system that is expressly disclosed in the following paragraph.
130. Next, counsel for Motorola relied on paragraph [0050]. Again, however, this says nothing about command translation, let alone application level command translation. If anything, the word "directly" suggests that commands are not translated at the application level. The same suggestion is conveyed by the word "relayed" in paragraph [0031] and, to a lesser extent, by the statement in paragraph [0036] that the "response options" are "based on information obtained from the message".
131. Finally, counsel for Motorola relied on paragraph [0061]. This gets Motorola no further than paragraph [0042]. Again, there is no mention of command translation, let alone at the application level. Again, protocol translation is discussed in paragraph [0062].
132. I conclude that Beletic does not disclose application level command protocol translation at all, and certainly not as an essential feature of the invention. This is so even if it is read on the basis that application level command protocol translation was common general knowledge. It is still more so if it is read on the basis that such translation was a "new way of thinking".
133. Turning to integer [5] of the claim, I construe this as contended for RIM, that is, as meaning translation of the commands into a protocol understood by the remote messaging system at any layer of the protocol stack. The words naturally cover this, and the skilled person would not understand from the specification that the patentee intended to exclude translation of some layers, but not others.

Infringement

134. Two systems operated by RIM are alleged to infringe. These are referred to as the BlackBerry Enterprise Solution ("BES") and the BlackBerry Internet Solution ("BIS"). A third system, referred to as the BlackBerry Professional Software, is no longer alleged to infringe.

BES

135. This is a system which enables email from a company's corporate mail server to be forwarded to the relevant employees' BlackBerry devices. It involves a dedicated server at the company's premises (the BES Server) which retrieves email from the corporate mail server and (providing it meets any filter rules set) sends it to a component called the Relay. The Relay identifies the correct mobile phone network to send the data to. Internet Protocol (IP) packets are then transmitted to the user's mobile phone provider (via a Gateway CGRS Support Node or GGSN) for onward routing by the wireless network to the handheld device (including any protocol translation or encapsulation necessary within the wireless network). A schematic diagram taken from RIM's product description is shown below:

136. Although the diagram shows a single BES Server, in reality there are a multiplicity of them in the UK, but only one Relay.
137. The diagram shows the BES Server as separate from the corporate email server, as it usually is. Motorola accept that, if the two servers are installed on the same machine, there is no infringement because there is no "remote" messaging system.
138. The BES Server retrieves messages from the mail server with which it interacts by polling them using the relevant protocol for that server. So, for a Microsoft Exchange server, MAPI is used. For a Lotus Notes or Novell GroupWise server, different protocols are used. Each BES Server is dedicated to a particular type of mail server. It is not possible for a BES Server to interact with more than one type of mail server.
139. For those messages that pass the BES Server's filter criteria for the user in question, the message is translated into a RIM proprietary email protocol called CMIME. These CMIME messages are compressed and encrypted into packets called GME datagrams and have various lower level protocols applied. These are then sent over the Internet to the Relay. The GME datagrams are given a GME header that contains routing information which is used by the Relay to route the datagrams to the correct wireless network for delivery to the user. Although the Relay undertakes some protocol conversion, it does not translate the datagrams into wireless protocols: this takes place within the wireless network. Although not shown in the diagram above, the Relay is protected by firewalls.
140. So far as commands sent from the handheld device to the corporate server are concerned, these are expressed in CMIME and not translated at the application level by the Relay, although it does carry out lower layer protocol conversion. The commands are translated into a different application level command protocol, such as MAPI, by the BES Server.
141. RIM deny that BES performs the method of the claim. This raises a number of issues.
142. First, what is the messaging gateway system? Motorola's case on this changed during the course of the trial. In opening, Motorola contended that the BES Server was the messaging gateway system of Beletic, and accepted that the Relay was "a completely standard gateway". In closing, Motorola's primary case was that the combination of the BES Server and the Relay constituted the messaging gateway system. In the alternative, Motorola maintained that the BES Server on its own was the messaging gateway system. One reason for this change of position is that it is more difficult for Motorola to say that the messaging gateway system constructs transmittable messages if it comprises the BES Server alone than if it comprises the BES Server in combination with the Relay. Another reason is because it affects the infringement case on the BIS system.
143. As I understand it, RIM do not dispute that the BES Server can be regarded as a messaging gateway system (subject to the two points discussed below), but they do dispute that the Relay forms part of the messaging gateway system.
144. In support of the latter contention RIM rely on three cumulative points: (i) the fact that the Relay is firewalled, separate from the BES Server and under different administrative control; (ii) the fact that the Relay routes messages from numerous BES Servers; and (iii) the fact that the Relay does not operate at the application level: although it undertakes lower layer protocol conversion, at the application level it simply passes the messages and commands through.
145. On its own, the first point does not strike me as significant for the reasons given above in relation to construction. Nor is the second point particularly significant on its own. The third point is more significant, however, particularly when considered in combination with the first and second points.
146. If one construes integer [5] of the claim as Motorola contend, that is to say as requiring application level command protocol translation, then I think Motorola were right the first time round. There are two separate gateways, the BES Server and the Relay. The Relay is a conventional gateway. The gateway which performs the key function for the purposes of the claim is the BES Server. I do not think the skilled reader of Beletic would think that the claim extended to an arrangement in which there are two distinct messaging gateway systems, one of which operates conventionally and (subject to the point about "transmittable messages" considered below) carries out the functions of the pre-characterising portion and the other of which carries out the functions of the characterising portion.
147. If, on the other hand, one construes integer [5] as RIM contend, then it seems to me that the Relay itself qualifies as a messaging gateway system (again, subject to the point about "transmittable messages") and one can disregard the second gateway comprised by the BES Server.
148. The second issue is whether there is a remote messaging system. On the construction I have adopted of "remote", there is.
149. The third issue is whether the messaging gateway system is operable to construct transmittable messages. On the construction of "transmittable messages" which I have adopted, neither the BES Server nor the Relay does this. This is because neither the messages sent by the BES Server nor those sent by the Relay are in a protocol which is suitable for RF transmission.

BIS

150. The BIS system is for individuals who do not have a corporate mail server, but who want to have wireless access to their email on their BlackBerry. As this is for users without a corporate mail server, rather than having their own dedicated BES server, a server maintained by RIM (the BIS Server) periodically polls for new email from the user's private email server (such as those hosted by Internet providers such as Yahoo or Google Mail) by standard email protocols such as POP3 or IMAP4. As such, a difference between the BIS Server and the BES Server is that the BIS Server is able to implement multiple email messaging protocols simultaneously. Another difference is that the BIS Server is in Canada. Thereafter, as with the BES system, if those emails meet the user's criteria for forwarding to the handheld, they are sent to the Relay for onward transmission to the GGSN of the relevant mobile phone system and ultimately the user's BlackBerry. Again, a schematic diagram taken from RIM's product description is shown below:

151. RIM accept that in the case of the BIS system, there is at least one remote messaging system, so that issue does not arise. So far as the messaging gateway system and transmittable messages are concerned, the same issues arise as with the BES system, and my answers are the same.
152. An additional issue potentially arises out of the fact that the BIS Server is in Canada. RIM contend that it follows that it did not offer the claimed method for use in the UK within section 60(1)(b) of the Patents Act 1977, nor does it supply means relating to an essential element of the invention when those means are suitable for putting, and are intended to put, the invention into effect in the UK. For the reasons given above, this issue only arises on Motorola's construction of the claim, which means that the BIS Server is the messaging gateway system. Nevertheless, I shall deal with it.
153. On that basis, then I consider that RIM are correct. So far as section 60(1)(b) is concerned, if the messaging gateway system is the BIS Server, the method of operating the messaging gateway system is offered for use by RIM in Canada, not in the UK.
154. As for section 60(2), Motorola rely upon the decision of the Court of Appeal in Menashe Business Mercantile Ltd v William Hill Organisation Ltd [2002] EWCA Civ 1702, [2003] RPC 31. In that case, the claim was a product claim. As Aldous LJ noted at [2]:

"Claim 1, so far as relevant, claims: 'a gaming system for playing an interactive casino game comprising a host computer, at least one terminal computer forming a player station, communication means for connecting the terminal computer to the host computer and the program means for operating the terminal computer, the host computer and the communication means … characterised in that the terminal computer is situated at a location remote from the host computer …'"

155. The alleged infringing act was the supply of software by the defendant to a punter for running on his computer. The software effectively turned the punter's computer into the terminal of the claim. The punter was able to connect his computer to the host computer, which was located outside the UK. Thus, the punter was able to use the claimed system in the UK by reason of the supply of the software and it did not matter that the host computer was not in the UK. The use of the system in the UK by the punter was sufficient for the invention to be put into effect in the UK for the purposes of section 60(2). As Aldous LJ said at [33]:

"If the host computer is situated in Antigua and the terminal computer is in the United Kingdom, it is pertinent to ask who uses the claimed gaming system. The answer must be the punter. Where does he use it? There can be no doubt that he uses his terminal in the United Kingdom and it is not a misuse of language to say that he uses the host computer in the United Kingdom. It is the input to and output of the host computer that is important to the punter and in a real sense the punter uses the host computer in the United Kingdom even though it is situated in Antigua and operates in Antigua. In those circumstances it is not straining the word 'use' to conclude that the United Kingdom punter will use the claimed gaming system in the United Kingdom, even if the host computer is situated in, say, Antigua. Thus the supply of the CD in the United Kingdom to the United Kingdom punter will be intended to put the invention into effect in the United Kingdom."

156. I agree with RIM that asking and answering Aldous LJ's questions in this case leads to a different answer. Who uses the method of operating a messaging gateway system that has the claimed features? The answer is RIM. Where do they operate it? The answer is in Canada.
157. Accordingly, if the claim were to be construed as Motorola contend, there would be no infringement by RIM with regard to the BIS system.

Conclusion

158. On the construction of claim 1 that I have adopted, it is not infringed by either the BES or BIS systems.

Validity

159. It is common ground that, if integer [5] of the claim is to be construed as RIM contend and I have held, Beletic is invalid. RIM contend, however, that Beletic is invalid even if it is construed as Motorola contend. Accordingly, I shall consider the issues on validity upon the assumption that Motorola's construction of integer [5] is correct, that is to say, that the claim requires application level command protocol translation.

The cited prior art

160. RIM rely upon three items of prior art:

i) Paragraph 15.3.3.2 of a book entitled The Wireless Data Handbook by James F. DeRose (Quantum Publishing, 1994) about the gateway in a system called RadioMail ("RadioMail");

ii) An article by Steve Polilli headed "Motorola envisions connecting wireless technologies to LANs" published in InfoWorld on 22 November 1993 ("MNI"');

iii) European Patent Application No. 0 782 805 entitled "Personal Communication Interworking" ("Pepe").

RadioMail

161. Although RadioMail was an operational system before 2 March 1995, RIM do not rely on the system by way of prior use but, only on the description of it in the book. This is quite brief. It begins by describing RadioMail as a gateway which "permits wireless e-mail to be sent to paging systems and to be sent/received from either RAM or ARDIS". It goes on:

"Usually pictured with scores of lines entering its cloud from AT&T EasyLink, CompuServe, MCI Mail, and others, RadioMail often uses the 'network of networks', Internet, for its connections and transport. Similarly, it uses a single feed from Comtex to obtain multiple news services, weather and a financial data for its AgentSee/NewsFactory offering, and National Dispatch Center to connect with 220 one-way (paging) services. But the number and types of connections are so rich that they must be grouped in some logical manner as shown in Figure 15-6."

162. I reproduce Figure 15-6 below:

163. As can be seen from the Figure, the RadioMail gateway enabled internetworking between various wired ("wireline") and wireless networks. On the left hand side of the diagram, there are wired networks, including email systems (such as cc:Mail, CompuServe and MCI Mail) shown connected by double headed arrows indicating two-way communications. On the right hand side, there are wireless networks, including one-way paging networks (NDC, Skytel, Pactel) and two-way data networks (such as RAM and ARDIS). The RadioMail Remote is shown connected to both the data networks, allowing the sending and receiving of email.
164. The middle box shows the functionality of the RadioMail gateway. It could do the following:

i) "Store and Forward" i.e. send emails to and (if the wireless network allowed it) from the wireless device, storing the message in the process of doing so if necessary.

ii) "Process: receive msg, strip extra characters/ selects: header/ hdr & txt/ text only/ forwards to: paging/ 2 way/ wireline". This makes it clear that the gateway receives messages, processes them to strip redundant or irrelevant characters from the message and then, presumably according to user preferences, send either the whole message, just the header or just the text to the wireless device.

165. The text of the book goes on to state that "Seemingly trivial tasks such as 'strip extra characters' are, in fact, functions critical to the success of a packet switched gateway". It then discusses a print-out, reproduced in Appendix J to the book, from an enquiry that found an email waiting at the CompuServe server, commenting that a large number of characters were exchanged even though the text of the email was only 50 characters long. The author goes on to set out advice given by the RadioMail users group, including:

"Get one e-mail address:

a. Use the 'autoforward' option available on many systems (MCI Mail).

b. Use rules and routing filters on other systems.

c. Accept the fact that some systems offer no relief."

MNI

166. This is a short article reporting a presentation of a pre-release version of Motorola's Mobile Networks Integration technology at the Comdex exhibition. It states:

"At the heart of emerging MNI architecture is an MNI hub that will link LAN resources to several wireless syndication systems -- including Ardis, RAM Mobile Data's Mobitex, and Cellular Digital Packet Data systems. It will also link pagers to LAN resources ...

The MNI hub consists of protocol-conversion software running on a Tandem fault-tolerant computer. It will also have links to content services including on-line databases.

The hub will be programmed to strip off extraneous data from wireless transmissions and converts the protocol for LAN-based use. The message will be sent to a software gateway, where agents directly link remote users to LAN applications such as databases, file servers, mail systems, and others.

The approach will let users download only a directory of message headers and then request the most vital ones. Currently, when remote users want to check their electronic mail, they have to retrieve the entire text of a message."

167. The article includes this illustration:


Pepe

168. Pepe has a priority date before that of Beletic, but was not published until after Beletic. It is therefore a novelty-only reference. Pepe is a long application that explores in some detail a number of aspects of internetworking various communications systems. Its central feature is a network component which it refers to as the PCI. The PCI is an intermediary between various wired and wireless networks.
169. Pepe begins by stating at page 1 lines 5-8:

"The present invention is directed to an Internet work for personal communications and, more particularly, to a network which allows a mobile communications subscriber to remove you control personal indications delivery options."

170. The objects of the invention are set out at page 5 line 20 to page 6 line 22 as follows:

"The user may need to send or receive messages from any or all of the messaging options described above at a visiting location. That is, the user may want to receive or receive notification of e-mail, faxes, phone calls, or voice mail at a visiting location or to send e-mail or faxes from a wireless terminal. The need to integrate these various types of messaging options and to interconnect the many service providers has, until now, been largely unaddressed.

It is also desirable for the mobile employee to be able to limit the messages sent to the wireless messaging equipment, so that only urgent messages are received when away from the office and for unwanted in-coming calls are avoided. The mobile employee may also wish to route certain incoming wireless messages and phone calls to other destinations, such as an office fax machine or a colleague's telephone.

Therefore, it is an object of the present invention to provide a mobile service subscriber the ability to control and integrate a plurality of messaging options.

It is another object of the present invention to provide a mobile service subscriber with the ability to remotely control the addressability, routing, accessibility, and delivery of messaging options.

It is yet a further object of the present invention to provide an internetwork which interconnects messaging services with both wireless and wireline networks.

It is yet a further object of the present invention to provide a subscriber with real-time control of voice calls while using a wireless data terminal or PDA.

It is yet a further object of the invention to provide a control over the messages routed to wireless messaging options."

171. The summary of the invention at page 7 lines 2-11 explains how these objects are to be obtained:

"These objects are obtained by a personal communications internetwork providing a network subscriber with the ability to remotely control the receipt and delivery of wireless and wireline voice and text messages. The network operates as an interfaces [sic] between various wireless and wireline networks, and also performs media translation, where necessary. The subscriber's message receipt and delivery options are maintained in a database which the subscriber may access by wireless or wireline communications to update the options programmed in the database. The subscriber may be provided with CallCommand service which provides real-time control of voice calls while using a wireless data terminal or PDA."

172. The position of the PCI as a gateway between wired ("wireline") and wireless networks is illustrated in Fig.1, which I reproduce below:

173. The function of the PCI is described in general terms at page 12 lines 9-19 as follows:

"A Personal Communications Internetworking ('PCI') 40 according to the present invention is connected between the wireless 39 and wireline networks 29. The PCI 40 permits the mobile communications subscriber to send and receive messages between disparate networks and messaging systems and a variety of service providers. The mobile communications subscriber can receive e-mail, fax, pages, and voice messages under a single phone number while using either a wireless or wireline network. The subscriber may also select the media format and serving network used to receive messages. The subscriber may also select cross-media notification of incoming messages, (i.e., the subscriber may receive notification from a pager message that a voice mail message was received)."

174. The PCI includes a PCI server 48 and a PCI database 44. The functions of the PCI server are listed at page 18 lines 11-24. The PCI server:

"is an X.400 Gateway;

routes messages using the X.400 messaging protocol;

connects proprietary messaging protocols into X.400 protocol;

interfaces with wireless data networks;

interfaces with messaging systems;

interfaces with the PCI database to access subscriber profiles information;

processes messages as specified by the user in the service profile;

provides media conversion such as text to fax or fax to text;

provides access to an X.500 directory to determine addressing schemes for packet data;

supports signalling between wireless data networks for management functions such as registration;

and maintains a service profile cache."

175. At page 25 lines 17-24 Pepe states:

"The PCI server 48 may be based, for example, on either an X.400 MTA or an SMTP router and can convert between both protocols. The PCI server 48 may receive text messages from a variety of different text messaging systems such as Internet mail, third party messaging systems, or proprietary messaging systems. In the example where PCI routes messages using an X.400 MTA, these messages must be converted to conform with X.400 protocol before they can be routed. Thus, an exemplary messaging gateway is an X.400 gateway, which can be designed and built by a person of ordinary skill in the art."

176. At page 42 lines 11-13 Pepe states:

"Sending and receiving e-mail wireless messages involves two types of message flows: sending messages from the PDA 30 to the PCI server 48 and from the PCI server 48 to the PDA 30."

It goes on to describe an illustrative message flow sending an email from the PDA to the PCI server by reference to Fig. 15.

177. The key passage in Pepe for present purposes is at page 42 line 12 – page 46 line 3. This passage begins at page 43 lines 13-24:

"Retrieving E-mail involves two types of message flows: retrieving undelivered E-mail addressed to the PDA 30 and retrieving E-mail delivered a messaging system, such as a wireline e-mail system. When a subscriber is out of radio coverage or is not registered with PCI, the PCI sends E-mails addressed to be delivered to the PDA (PDA-bound E-mail) to an external mail storage system. The PCI server will also send certain E-mail directly to an external mail storage system (MS-bound E-mail), such as the subscriber's wireline E-mail connected to his or her personal computer, according to the subscriber profile stored in the PCI database 44. A registered subscriber can retrieve PDA 30 bound E-mail at any time by starting 'FETCH' operation. The PCI will send the PDA bound mail from the external mail storage and will also summarize MS bound E-mail."

It goes on to describe an illustrative message flow between the PDA and the PCI server for retrieving undelivered PDA bound email by reference to Figs. 16A and 16B.

178. If there are no MS-bound messages, Pepe states at page 44 lines 6-15:

"The PDA 30 sends a fetch request to the PCI server 48 (line 324) and starts a timer, which waits for an acknowledgement. If no acknowledgement is received within a predetermined time, for example twelve seconds, the PDA 30 assumes to is out of radio coverage and informs the subscriber to try again later. In response to the request, the PCI server 48 logs into an external mail storage system specified in the subscriber's profile. If any PDA- bound E-mail is stored in the external storage system, the PCI server 48 will (a) move the PDA bound E-mail from the external mail storage system into a pending area in the PCI server; (b) send an acknowledgement to the PDA indicating the number of PDA bound E-mail now residing in the pending area; and (c) initiate delivery of these PDA bound E-mail from the pending area to the PDA (line 326)."

179. If there are MS-bound messages, Pepe states at page 44 line 17 to page 45 line 3:

"The PDA sends a fetch request (line 328) and starts a timer. Whenever the PCI server sends a summary message, it starts a timer. If the PCI server 48 does not receive an acknowledgement within a certain predetermined time, for example ten seconds, it will assume that the PDA 30 is out of radio coverage, abort the send operation and discard the summary information. In response to the request, the PCI server 48 will (a) send an acknowledgement to the PDA indicating the number of MS-bound Email present; (b) extract summary information from those messages; and (c) send the summary to the subscriber's PDA (line 332). When the PDA receives an acknowledgement from the PCI server, it informs the subscriber based on the contents."

Novelty

180. As was explained in Synthon BV v SmithKline Beecham plc [2005] UKHL 59, [2006] RPC 10, in order for an item of prior art to deprive a patent claim of novelty, two requirements must be satisfied. First, the prior art must disclose subject matter which, if performed, would necessarily infringe that claim. As it was put by the Court of Appeal in General Tire and Rubber Co v Firestone Tyre and Rubber Co Ltd [1972] RPC 457 at 486, "[t]he prior inventor must be shown to have planted his flag at the precise destination before the patentee". Secondly, the prior art must disclose that subject matter sufficiently to enable the skilled addressee to perform it. In the present case the dispute is over the first requirement rather than the second.
181. The disclosure need not be explicit, it may be implicit. As Jacob J (as he then was) said in Hoechst Celanese Corp v BP Chemicals Ltd [1998] FSR 586 at 601:

"....it must be right to read the prior document with the eyes of the skilled man. So if he would find a teaching implicit, it is indeed taught. The prior document is novelty-destroying if it explicitly teaches something within the claim, or as a practical matter, that is what the skilled man would see it is teaching him."

Counsel for Motorola did not take issue with this statement of law, but emphasised that for anticipation (as opposed to obviousness) it is not enough that the skilled reader would probably (but not inevitably) implement the prior art in one particular way.

182. Although RIM formally contend that Beletic is anticipated by all three items of prior art, the attack was not pressed with respect to RadioMail.

MNI

183. Motorola accept that MNI discloses all the features of claim 1 of Beletic except for integer [5] as they construe it, namely application level command protocol translation. RIM's case is that application level command protocol translation is implicitly disclosed by two aspects of MNI: first, the disclosure of the use of "agents" as part of the gateway; and secondly, the disclosure that the application will allow users to download a directory of message headers and only request the most vital messages.
184. Mr Wiffen accepted that these passages suggested that MNI carried out protocol conversion, but not that they disclosed application level command protocol translation. Upon analysis, Professor Wolff's evidence does not show that this is implicitly disclosed by, as opposed to obvious in the light of, MNI. In my judgment MNI does not disclose application level command protocol translation.

Pepe

185. Motorola do not dispute that Pepe discloses integers [1], [2], [4] and [6], but deny that it discloses either integer [3] or integer [5].
186. Integer [3]. The first question is whether Pepe discloses that the messaging gateway system constructs "portions of the messages". It does disclose that, if there are MS-bound messages, the PCI server will "extract summary information from those messages" and send the summary to the wireless device. Motorola contend that this does not inevitably mean that the PCI server will extract and send part of the message itself, although that would be an obvious option. In my judgment, the evidence of the experts does not show that extracting and sending part of the message is implicitly disclosed, as opposed to information such as the sender, the subject line and/or the size of the email. Nevertheless, information of that kind does amount to "portions of the messages" as I have construed that expression.
187. The second question is whether Pepe discloses that the messaging gateway system constructs portions of messages "received from the remote messaging system". Motorola contend that Pepe is unclear as to whether the PCI server extracts summary information from MS-bound emails when they first pass through the PCI on the way to the external mail storage system or at a later stage after retrieving them from the MS. RIM rely upon (i) the express statement at page 43 lines 18-19 that the PCI server sends MS-bound email "directly" to the external mail storage system and (ii) the absence of any statement that summary information is extracted at that stage as excluding the first reading. Accordingly, RIM submit, read in that light, the passage at page 44 lines 17 to page 45 line 3 implicitly discloses the second reading. RIM accept that it would be obvious to the skilled reader that the summary information could be extracted during the first pass, but say that that is not what is actually disclosed.
188. Professor Wolff accepted that Pepe was not very clear as to what was happening, and it is fair to say that he wavered on this point in cross-examination. Nevertheless, when his attention was directed to page 43 lines 18-19 in re-examination, he re-affirmed his opinion that that sentence told him that no summary was extracted during the first pass through.
189. Mr Wiffen maintained that Pepe was unclear on this point, but he accepted during cross-examination that there was no disclosure of any registers or tables in the PCI server that could hold summary information extracted from emails during the first pass.
190. Having considered Pepe with care in the light of this evidence, I conclude that RIM are correct. Not only is there no suggestion in the passage at page 43 lines 13-24 that a summary is prepared during the first pass, and no disclosure of appropriate registers or tables for storing such a summary, the language at page 43 lines 18-19 says the opposite. Reading the passage at page 44 line 17 to page 45 line 3 in that light, the skilled reader would read Pepe as teaching him that the summary is prepared by the PCI after retrieving the MS-bound email from the external mail storage system. Moreover, that reading is supported by consideration of the sequence of events described in the latter passage and shown in Figure 16B and the language used to describe it. The sequence of events is that (1) the PDA sends a fetch request (EM_FETCH in Fig 16B i.e. email fetch) to the PCI server, (2) the PCI server sends an acknowledgement (EM_ACK) to the PDA and (3) the PCI server sends a summary (EM_SUMMARY). At page 44 lines 22-24 Pepe says that "In response to the [fetch] request, the PCI server will … extract summary information from [the MS-bound messages]". This says that it is only at that stage in the process that the summary is prepared, which in turn clearly implies that the summary is extracted from emails fetched by the PCI server from the mail storage system.
191. Integer [5]. Motorola contend that there is no disclosure in Pepe about precisely what is sent from the PCI to the external mail storage system, and hence no disclosure that there is command translation. RIM contend that this is implicitly disclosed.
192. RIM's argument proceeds as follows: (i) there is no disclosure in Pepe that the external mail storage system is custom-designed, accordingly the skilled reader would understand it to be a known type; (ii) Pepe teaches the skilled reader to use a specific command protocol (EM_FETCH, EM_RETRIEVE) between the PDA and the PCI server; accordingly (iii) it follows that there must be translation of those commands into whatever command protocol is used by the external mail storage system.
193. In my view this argument breaks down at step (ii). Pepe does not disclose that EM_FETCH etc are the actual application layer commands which are to be programmed into the PDA. The natural reading of the specification is that these are schematic indications of command types.
194. In this regard, I note that Professor Wolff's evidence in his first report at paragraph 266 was as follows (emphasis added):

"For instance, the PCI server would need to be able to speak to both the MS system and the PDA. This would have necessitated an understanding or protocol between the PCI and each of the MS in question and the PDA as to how to communicate. For example, different MSs might use different protocols and/or the PDA mail client might not use the same protocol as the MS. The PCI in the middle mediates between the two."

Professor Wolff's evidence in cross-examination was to similar effect. As Motorola rightly submit, this is a long way from evidence of anticipation.

Conclusion

195. On Motorola's construction, claim 1 of Beletic is novel over both MNI and Pepe.

Obviousness

196. A patent will be invalid for lack of inventive step if the invention claimed in it was obvious to a person skilled in the art having regard to the state of the art at the priority date. The familiar structured approach to the assessment of allegations of obviousness first articulated by the Court of Appeal in Windsurfing International Inc v Tabur Marine (Great Britain) Ltd [1985] RPC 59 was re-stated by Jacob LJ in Pozzoli v BDMO SA [2007] EWCA Civ 588, [2007] FSR 37 at [23] as follows:

"(1) (a) Identify the notional 'person skilled in the art';

(b) Identify the relevant common general knowledge of that person;

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

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

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

197. In both H. Lundbeck A/S v Generics (UK) Ltd [2008] EWCA Civ 311, [2008] RPC 19 at [24] and Conor Medsystems Inc v Angiotech Pharmaceuticals Inc [2008] UKHL 49, [2008] RPC 28 at [42] Lord Hoffmann approved without qualification the following statement of principle by Kitchin J at first instance in the former case:

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

198. I have already identified the person skilled in the art and his common general knowledge above.

RadioMail

199. By the end of the trial, it was common ground between the parties that the RadioMail gateway carried out all the integers of claim 1 except integer [5].
200. Mr Wiffen and Professor Wolff agreed that the example of email retrieval from CompuServe contained in Appendix J did not disclose application level command protocol translation. On the contrary, what it shows is that the wireless device uses the same application level commands as the remote server. Despite this, Professor Wolff appeared to suggest during cross-examination that the skilled reader would understand that the RadioMail gateway carried out application level command protocol translation. RIM rightly did not advance that contention in their closing submissions. I think that Professor Wolff lost sight of the distinction between what RadioMail actually discloses and what in his opinion was obvious in the light of that disclosure. Thus the difference between RadioMail and claim 1 of Beletic is that RadioMail does not disclose application level command protocol translation.
201. RIM put their case on obviousness in no less than four ways. I shall consider these in turn.
202. Command compression. The first was that, if one assumes that the RadioMail gateway is being used with one wireless device and one email server, it would be obvious to compress commands into a code for transmission from the wireless device to the gateway, e.g. to compress DELE msg to D msg, in order to save bandwith. Unsurprisingly, Mr Wiffen accepted as a general proposition that this would have been obvious:

"Q. Yes, but when you are coming to my Lord to say what you think

is clever, you are not coming to my Lord to say, 'What I am

coming to say is clever is is when I have a very simple

system, one e-mail server, a gateway and PDA'. You are not

saying it would be clever in the course of the necessary data

compression to sometimes have shorthand commands which are

interpreted in the gateway?

A. That is correct.

Q. Because you would be struggling to defend that as being clever

in 1995, would you not?

A. Yes, as a consequence of what we have just said, that is

correct."

203. As Mr Wiffen also accepted, if this were done, it would be necessary to de-compress the commands at the gateway. Thus the commands would be translated at the application level by the messaging gateway system into a protocol that was understood by the remote messaging system.
204. RIM add that not only was this generally an obvious step to take, but also it was particularly obvious given the emphasis in RadioMail on the importance of stripping unnecessary characters.
205. Motorola had four answers to this case. The first was that this could not have been an obvious step to take because Professor Wolff did not mention it in his reports. This is factually inaccurate. Although Professor Wolff did not mention it in his first report, he did mention it in his second report at paragraphs 29-30. I have summarised this evidence above. Moreover, even in his first report, Professor Wolff's opinion was that application level command protocol translation was not merely obvious, but common general knowledge.
206. The second answer relied on earlier answer given by Mr Wiffen to those quoted above, but that was overtaken by the subsequent cross-examination.
207. The third answer was that de-compressing commands did not amount to command translation within the meaning of the claim. This is contrary to the evidence of both experts. In any event, I do not accept it. I can see no reason why converting a command such as D msg, which would not be understood by the remote messaging system, into a command such as DELE msg, which would be understood, would not be regarded by the skilled person as command translation.
208. Finally, Motorola say that the skilled person would wish to minimise the complexity of the wireless device. This is not persuasive. Adding command compression would not involve much complexity, and would help to save scarce bandwith.
209. Gateway as proxy. The second way RIM put their case is based on using the RadioMail as a proxy in order to cut down on unnecessary traffic over the wireless network. Mr Wiffen accepted that it would be technically obvious to the skilled person that, instead of the various exchanges required to send an email from the wireless device using SMTP, one could arrange for a single SEND command to be sent from the wireless device to the gateway, which the gateway would then interpret. He also accepted that the same would apply to email retrieval using POP3:

"Q. Then could you perhaps look at the POP3 example. I anticipate

your answer must be the same. The third page is what you have

to do in POP3 to get all messages that are on the server.

MR. JUSTICE ARNOLD: And as I understand it, in this example we

have three messages.

MR. WATSON: Yes. As my Lord appreciates, it will just go on and

on if you have got 10 messages.

THE WITNESS: Yes.

Q. Equally, it is the same answer that if it was obvious to have

just a curt SEND MESSAGE, it would equally be obvious for the

radio device to send GET ALL MAIL and then let the gateway

acting as a proxy do all the hard work?

A. Again, from a perspective of technically would it be an

option, yes.

Q. Actually that option, GET ALL MAIL, would have the big

advantage that it would be protocol agnostic…….You could use

for IMAP, POP3, VIM. Is there one called VIM? There is.

A. Yes."

210. Motorola's answers to this case are similar to those given to RIM's first case. They are equally unpersuasive in this context.
211. Accessing multiple email systems. The third way in which RIM put their case is that it would be obvious to want the RadioMail remote to be able to access more than one email system, and for that purpose it would be obvious to send generic commands (such as GET ALL MAIL) to the gateway for the gateway to convert into the correct command protocol for the email server. Mr Wiffen substantially accepted this in cross-examination, and Professor Wolff was certainly of that opinion.
212. Motorola submitted that, if that had been an obvious step to take, RadioMail would have taken it or Mr DeRose would have suggested it or the RadioMail users group would have suggested it. Not only did neither Mr DeRose nor the user group suggest it, but the users group suggested using the autoforward function instead. So far as RadioMail itself is concerned, I am unimpressed with this. The fact that it adopted one obvious solution does not begin to show that the other solution was not obvious. The point about Mr DeRose and the RadioMail users group has more force, but I am unpersuaded by it. Both Mr DeRose and the users group focussed on what the user could do, not on recommending changes to the system itself.
213. More generally, Motorola contend that to make this change would have required a radical departure from the conventional approach to client-server architecture. This contention depends on application level command protocol translation not having been part of the command general knowledge. I have found, however, that it was.
214. Motorola also rely upon the fact that application level command protocol translation is not disclosed by MNI or Pepe or by some of the other prior art discussed by Professor Wolff in his reports. All this shows is that the devisers of those systems decided to adopt the other well-known alternative choice.
215. In my judgment using generic commands to access multiple email systems would have been an obvious change to make to RadioMail.
216. Two-way pagers. The fourth way in which RIM put their case is that it would be obvious to want to use the forthcoming two-way pagers with RadioMail, and for that purpose it would be obvious to provide the pager with short commands that the gateway could translate into the appropriate command protocol. Again, Mr Wiffen substantially accepted this, and Professor Wolff was certainly of that opinion.
217. Motorola accept that the concept of two-way paging was known, but contend that it is pure hindsight to suggest that it would have been obvious to use the pager to control the remote messaging system as opposed to simply sending a short reply. In support of this contention, Motorola say that no-one had conceived of the possibility of using a paging device to control a remote email server in the manner contemplated by claim 1 of Beletic. The flaw in that submission is that, as pointed out above, claim 1 is not limited to the case where the remote messaging system is an email server. It may be a voicemail system. In my view it was entirely obvious to want to use a two-way pager to send commands such as save, delete or replay to the voicemail system.
218. Given that application level command protocol translation was common general knowledge, I consider that one obvious way to achieve this was to translate commands at the gateway e.g. by converting abbreviated commands into full ones.

MNI

219. I can deal with this very briefly. The difference between MNI and claim 1 of Beletic is the same as the difference between RadioMail and claim 1. In my judgment the claim is obvious over MNI for most of the same reasons as it is obvious over RadioMail. MNI adds nothing of substance to RIM's case, however.

Common general knowledge

220. RIM contend for good measure that claim 1 is obvious over common general knowledge on its own. I do not consider that this adds anything to its case based on RadioMail. Nevertheless, I agree that the reasons which have led me to accept that the claim is obvious over RadioMail also lead to the conclusion that it is obvious over common general knowledge.

Conclusion

221. Claim 1 of Beletic is obvious in the light of RadioMail, MNI and common general knowledge alone.

Insufficiency

222. Insufficiency was advanced by RIM as a squeeze on construction. Given the construction of the claim I have adopted, it is not necessary to say any more about it.

Not a patentable invention

223. RIM contend that the claimed invention falls within the exclusion from patentability contained in section 1(2)(c) of the Patents Act 1977. It was common ground between counsel that it was only necessary to consider this objection if the claim was novel and inventive. I do not think any useful purpose would be served by attempting to consider the applicability of section 1(2)(c) upon an assumption that the claim is novel and inventive contrary to my previous conclusions.

Conclusion

224. On the construction of claim 1 that I have adopted, Beletic is not infringed by either RIM's BES system or RIM's BIS system and is invalid anyway. On Motorola's construction of claim 1, Beletic would still be invalid. Subject to that, it would be infringed by the BES system, but not by the BIS system.