Microsoft Corp v Motorola Mobility LLC [2012] EWHC 3677 (Pat) (21 December 2012)

Neutral Citation Number: [2012] EWHC 3677 (Pat) Case No: HC11C04536 IN THE HIGH COURT OF JUSTICE CHANCERY DIVISION PATENTS COURT Royal Courts of Justice, Rolls Building Fetter Lane, London EC4A 1NL 21 December 2012 B e f o r e : THE HON MR JUSTICE ARNOLD ____________________ Between: MICROSOFT CORPORATION Claimant - and - MOTOROLA MOBILITY LLC Defendant ____________________ Richard Meade QC and James Abrahams instructed by Bird & Bird LLP for Microsoft Daniel Alexander QC instructed by, Tim Powell of and Christopher Hall instructed by Powell Gilbert LLP for Motorola Hearing dates: 3-5, 10 December 2012 ____________________ HTML VERSION OF JUDGMENT ____________________ Crown Copyright © MR JUSTICE ARNOLD : Contents Topic Paragraphs Introduction The witnesses 2-11 Technical background 12-22 Networks Protocols Clients and servers Wireless networks 16-19 Paging networks 17-18 Wireless data networks Email systems 20-22 The Patent 23-34 The claims 35-40 The person skilled in the art 41-45 Common general knowledge 46-52 Common general knowledge of the paging engineer 48-51 Common general knowledge of the email engineer Construction 53-75 Transceiver 55-56 Message Status 58-60 Responsive to/in response to 61-75 The prior art 76-97 Gutman 77-82 PCMAIL 83-88 IMAP4 89-97 Novelty 98-104 The law Gutman 99-103 PCMAIL and IMAP4 Obviousness 105-138 The law 105-108 Skilled person, common general knowledge and inventive concept Common general knowledge regarding pagers 110-121 Gutman 122-125 PCMAIL 126-131 IMAP4 132-138 Infringement 139-154 Exchange ActiveSync 141-142 SYNC 143-149 PING 150-153 Live Messenger Google Licence 155-162 Summary of conclusions Introduction In these proceedings the Part 20 Claimants ("Motorola") claim that the Part 20 Defendants ("Microsoft") have infringed European Patent (UK) No. 0 847 654 entitled "Multiple pager status synchronization system and method" ("the Patent"). Microsoft deny infringement and claim that the Patent should be revoked on the grounds of lack of novelty alternatively obviousness. There is no challenge, however, to the claimed priority date of 31 August 1995. The witnesses Motorola's expert witness was Larry Bruce Deer. Having gained a degree in Electrical Engineering from Mississippi State University in 1979, he joined Lockheed Aerospace in 1980 as a systems engineer. He worked at Lockheed Aerospace until 1994 in a number of roles. During this period he obtained an M. S. in Electrical Engineering from Southern Methodist University in Dallas, Texas in 1984. In 1994 he joined the paging infrastructure company Mobile Telecommunications Technologies, Inc., which operated under the name SkyTel. There he was responsible for developing the software aspects of the paging system infrastructure for the rollout of the first two-way paging communication system in the US, which employed Motorola's ReFlex protocol. He was also involved in the development of enhanced message handling functionality over the two-way messaging platform, including fax message forwarding functionality and a wireless email system. In 1996 he was promoted to Vice-President and Chief Technical Officer. From 2001 to 2004 he was Senior Vice-President and Chief Operations Officer of SkyTel and the Broadband Solutions division of MCI, directing the development of wireless broadband systems. In 2004 he was promoted to President and Chief Executive Officer. In 2007 he retired from SkyTel and became an independent consultant. He is also President and CEO of a start-up company developing wireless communication technologies for vehicle tracking and traffic congestion management. For the reasons explained below, Microsoft called two experts, one to represent someone skilled in the field of paging in 1995 and one to represent someone skilled in the field of email in 1995. The former was Dr Simon Saunders. Between 1984 and 1988 he obtained an Electrical & Electronic Engineering degree from Brunel University as part of a sandwich course while working at Pye Telecommunications. Pye later became Philips Telecom, and from 1988 to 1991 Dr Saunders was sponsored by Philips to obtain a PhD in radio wave propagation from Brunel. From 1992 to 1995 he was employed by Philips as a senior engineer. From 1994 he led a team responsible for the design of a new two-way paging protocol called Radio Access Mail Protocol (RAMP), which was adopted as the basis of the reverse link of European Telecommunication Standards Institute's ERMES protocol. In 1996 Dr Saunders was employed by Motorola as senior staff engineer. From 1996 to 2003 he was successively lecturer, senior lecturer and reader in Mobile Communications at the University of Surrey. Since 2003 he has been Visiting Professor at the same institution. From 1999 to 2004 he was Chief Technology Officer and in 2005 Chief Executive Officer of Cellular Design Services Ltd. From 2005 to 2006 he was CTO of Red-M Group Ltd. Since 2006 he has acted as a consultant and chaired the Femto (now Small Cell) Forum. He is the author of two books and over 150 papers. He is a named inventor on a number of patents. Microsoft's second expert was Tony Redmond. From 1977 to 1983 he was employed by the Bank of Ireland in its computer centre as Operations and VAX System Manager. In 1983 he joined Digital Equipment Corporation as an Office Systems Specialist. From 1986 to 1989 he worked as a Consultant at Digital's European Technical Centre supporting the development and launch of European versions of Digital's ALL-IN-1 software package and subsequently on standards for email interoperability. From 1989 to 1993 he was an Engineering Manager in Digital's European Software Engineering Group. From 1993 to 1996 he was a Principal Consultant at the European Office Application Engineering Centre, managing various projects associated with Digital's office software products. From 1996 to 1998 he was Technical Director for Digital's Email and Collaboration Practice. He kept this role when Digital was taken over by Compaq in 1998. From 2000 to 2002 he was CTO and Vice-President of Compaq. When Compaq was acquired by Hewlett Packard in 2002 he kept the same role in HP Consulting Services until 2007. From 2008 to 2010 he was Vice President for Research and Innovation for HP Services. In 2010 he retired and set up his own consultancy. He is the author of a number of books. All three experts were well qualified and did their best to assist the court in their oral evidence. As counsel for Microsoft pointed out, however, Mr Deer did not defend everything contained in his reports. Furthermore, while he was an expert in pager technology, his expertise on other topics was not as extensive. In particular, he had no experience with WLANs until well after 1995. Furthermore, he was less knowledgeable than Mr Redmond about email systems in 1995. Counsel for Motorola submitted that Dr Saunders' evidence as to what would be obvious over common general knowledge had to be approached with some caution for two reasons, first because he was inventive and secondly because of his knowledge of Philips' proprietary protocols at the time. I accept the second point, and have made allowance for this. I do not accept the first point for the reasons given by Jacob LJ in Technip France SA's Patent [2004] RPC 46 at [11]-[15]. Counsel for Motorola also submitted that Mr Redmond's reading of PCMAIL and IMAP4 had been coloured by his experience of proprietary email systems. I do not accept this. In addition to the expert witnesses, Microsoft called Juan Balducci as a witness of fact to verify Microsoft's Exchange ActiveSync product and process description. He was a very careful and precise witness. Technical background In this section of the judgment I shall endeavour to set out the uncontroversial technical background to the Patent. Networks 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. Protocols 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. Clients and servers 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. Wireless networks 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. 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 pager address 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 address. When it received an incoming message, the pager would alert the subscriber e.g. by an audible tone. A message could be sent to more than one address simultaneously. As at 31 August 1995, most 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 in the process of being launched (in particular by Motorola and SkyTel in the USA and Philips in Europe). The main advantages of two-way pagers were that they enabled users both to acknowledge the receipt of messages (enabling the messages to be re-sent if not properly received) and to reply to messages. In addition, two-way paging enabled the pager to indicate its location, so that messages only needed to be transmitted from transmitters covering that location, rather than having to be transmitted by all transmitters in the network. 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). Email systems 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 and (ii) an email (or mail) client. In the standard client/server approach used in August 1995, the client sends requests to the server, and the server then sends responses to the client. Different email systems employ different protocols and formats in a number of respects. There are both proprietary and standardised email protocols for both delivery of and access to emails. Standardised access protocols included POP3 and IMAP4, both of which were used for email retrieval and manipulation across the internet. Most emails sent in August 1995 were relatively short, simple, text-only messages. The Patent The specification begins at [0001] by saying, under the heading "field of the invention", that the invention "relates generally to the field of two-way communication devices and, in particular, to information managed therein". The specification goes on, under the heading "background of the invention", at [0002]: "As the acceptance of selective call communications devices, or pagers, including two-way pagers, continues to grow, and as their affordability continues to improve, some users are acquiring pagers which have a same selective call address. … For example, a neon coloured belt worn pager is used for a day at the beach, and a black and gold pen pager with a business suit is used for an evening business meeting." The problem to which this gives rise, which the invention seeks to solve, is stated at [0004]: "However, a problem arises when the user has multiple pagers which are left continuously on. For example, messages received by a pager carried by a user are also received by the user's other pagers which are not carried at that time. Disadvantageously, with known pagers, message status changes made by the user on the carried pager are not made on the user's other pagers. If a user reads, deletes, or protects a message on the carried pager, the message remains as an unread message on the user's other pagers. Thus, when the user changes attire and corresponding pagers, the user is faced with a different pager having messages with an unread status, which are identical to messages previously read, deleted or protected on another pager. Thus, the user must again read and decide the status of each message received on the other pager. This additional tedious task required after each change of a pager poses an inconvenience to the user that could deter a user from acquiring a number of pagers in different form factors and colors. Thus, what is needed is a way to have message status changes made on any one of the user's pagers automatically made on the user's other pagers." The specification goes on at [0005] to note that a similar problem arises when the user has multiple pagers and the user changes configuration information stored in one of the pagers. Examples given of this are the time of a daily alarm or the type of alert produced when a message arrives from a certain user or having certain content, such as changes in the value of a financial instrument or a key word indicative of a news item. Accordingly, the specification states at [0007]: "… what is needed is a way to have status changes to a pager configuration made on any one of a plurality of the user's pagers automatically made on the other one or ones of the plurality of the user's pagers." After three consistory paragraphs corresponding to claims 1, 3 and 7 respectively and a brief description of the drawings, the preferred embodiments are described at [0012] onwards. The embodiment corresponding to claim 1 is shown schematically in Fig. 1, which I reproduce below. In this embodiment the wireless messaging infrastructure 110 sends a first message 205 to the user's pagers 130 and 150 in step 200. On receipt, the pagers assign the status "unread" to the first message in steps 210 and 215. The user reads the first message on pager 130 in step 220, which causes the status of the first message to change from "unread" to "read". After a delay to allow for other inputs which change the status of the first message (for example, an instruction by the user to delete the message) at step 230, pager 130 transmits a second message 240 to the infrastructure indicating the change in status of the first message at step 235. The second message is received by the infrastructure in step 245, whereon the infrastructure sends a third message 255 to the pagers indicating the change in status of the first message at step 250. On receipt of the third message at step 265, pager 150 changes the status of the first message in step 275. As the specification states at [0021]: "Thus the status of messages received by pagers 130 and by all pagers 150 will be identical after execution of step 275. Thus if a user reads and deletes a message on pager 130, it will also be identified as being read and deleted on pager 150. Consequently, when the user changes from pager 130 to 150 in response to changing attire, or otherwise, the status of messages in both pagers will be substantially identical. This has the advantage of alleviating the inconvenience of changing the status of unread messages in pager 150." The embodiment corresponding to claim 3 is shown schematically in Fig. 5, which I reproduce below: In this embodiment the sequence starts with the user changing the status of the pager in some manner in step 620. The specification explains what is meant by the "status" of the pager at [0025] as follows: "… A status change includes a change in operating mode or information content of the pager. Changes in operating mode include changes in alert mode, such as changing a time of day alarm, changing from silent to audio alert mode, or selecting a different alert melody. Changes in operating mode also include changes in the status of a message, such as 'unread', 'read', 'protect' and 'delete status' of a message. Changes in operating mode also include changes in alert threshold information such as high or low values of a financial instrument information, sports scores, or other information received via an information paging service. Changes in operating mode also include changes in information content such as edits to received or stored information, additional information such as additions to Rolodex TM type information or calendar appointments. Changes in operating mode also include changes in key word search algorithms …" Thereafter this embodiment proceeds in essentially the same manner as the first embodiment. As the specification notes at [0031], the result is that the status of both pagers will be substantially identical. The specification states in [0012] that the invention preferably operates with the Motorola ReFlex two-way wireless paging system infrastructure and protocol, but that "other two-way communication systems are also contemplated". There are a couple of further references to ReFlex, and to pagers compatible with it, in [0013] and [0015]. Otherwise, the description of the embodiments contained in the specification is at a similar level of abstraction to that in the illustrations reproduced above. The specification concludes as follows: "[0038] Thus, it should be apparent by now that the present invention provides a method of synchronizing the state of message information among a plurality of selective call transceivers, or pagers. In particular, the method advantageously provides a method of communicating changes in status category of message information, from among a multiplicity of status categories, in a first transceiver to a second transceiver. When a first status in a transceiver is changed to a subsequent status as a result of a subsequent input to the first transceiver, the invention provides a method of automatically changing the first status in a second transceiver to the subsequent status. [0039] While a detailed description of a preferred embodiment of the invention has been given, it should be appreciated that many variations can be made thereto without departing from the scope of the invention as set forth in the appended claims. Further, the invention is not limited to selective call transceivers, or two-way pagers, but can be used with other types of two-way communication devices, both fixed and portable, both wireless and wireline." The claims Claim 1, broken down into integers and with reference numerals omitted, is as follows: "[A] A method of synchronizing message information among a plurality of transceivers comprising the steps of: [B] transmitting by a wireless messaging infrastructure a first message having a first status; [C] in one transceiver of the plurality of transceivers, changing the first status of the first message to a second status responsive to an input to the one transceiver, and [D] transmitting a second message indicative of the second status; [E] in the wireless messaging infrastructure, receiving the second message; and characterised in that the method includes the steps of [F] in the wireless messaging infrastructure, responsive to receiving the second message, transmitting a third message indicative of the second status; and [G] in at least one other transceiver of the plurality of transceivers, receiving the third message, and [H] responsive to receiving the third message, changing the first status of the first message to the second status." Claim 3 provides: "[A] A method of synchronizing a status of a plurality of transceivers comprising the steps of: [B] in a first transceiver, changing the status of the first transceiver from a first status to a second status as a result of an input from a user, and [C] transmitting a first message indicative of the second status; [D] in a wireless messaging infrastructure, receiving the first message characterised in that the method includes the steps of, [E] in the wireless messaging infrastructure, transmitting a second message indicative of the second status; and [F] in a second transceiver, receiving the second message, and [G] changing a status of the second transceiver to the second status in response thereto." Claims 2 and 6 are claims dependent on claims 1 and 3 respectively directed to methods in which the transmission of the second message is delayed by a predetermined time period after changing the status of the first message on the first transceiver and transmitting any subsequent status change made within that period as the second status. Claim 4, which is dependent on claim 3, is directed to a method in which the first transceiver receives and decodes the second message without further changing the status of the first transceiver. Claim 5, which is dependent on claims 3 or 4, is directed to methods in which the first transceiver and the second transceiver have a multiplicity of status categories each of which has a state and the first message is a signal indicating that a state of a category has changed. Claim 7 provides: "[A] A system for synchronizing a status category of a plurality of communication devices communicating with an infrastructure, [B] each of the plurality of communication devices having at least one status category, [C] each of the at least one status category having a plurality of states, characterised by: [D] means in at least one communication device of the plurality of communication devices for changing a status category of the at least one communication device of the plurality of communication devices to produce a current state of the status category; [E] means in the least one communication device of the plurality of communication devices to produce a synchronizing signal for signaling [sic] to the infrastructure the current state of the status category; [F] means in the infrastructure to produce a current state signal for signaling [sic] to an other communication device of the plurality of communication devices the current state of the status category of the at least one communication device of the plurality of communication devices in response to the synchronizing signal; and [G] means in the other communication device of the plurality of communication devices for changing the current state of the at least one status category of the other communication device to the plurality of communication devices to the current state of the at least one communication device of the plurality of communication devices responsive to the current state signal." The person skilled in the art 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. There is a minor dispute as to the skilled person to whom the Patent is addressed. Motorola say that it is directed to a systems and software engineer with experience of working in the field of wireless communications. Microsoft say that the Patent is directed to an engineer with expertise in paging (represented by Dr Saunders), but that if the word "transceiver" in the claims of the Patent is to be construed as Motorola contend, then it follows that the Patent is also directed to an engineer with expertise in email systems (represented by Mr Redmond). In support of this approach, counsel for Microsoft cited the judgment of Laddie J in Inhale Therapeutic Systems Inc v Quadrant Healthcare plc [2002] RPC 21 at [42]: "… In some cases a patent claim may cover a wide field so that some parts of it will be obvious to the notional skilled person in one field and other parts will be obvious to the notional skilled person in another. That is not unfair to the patentee … but simply a reflection of the fact that the scope of the protection sought is wide. I accept, of course, that in some cases there will be invention in marrying together concepts from two unrelated arts, but that is not what Mr Carr is arguing for here. He says that the notional skilled worker in the art, whether he comes from the freeze-drying field or the spray-drying field, would find it obvious to work within the wide limits of the claim. When considering what would be obvious to the notional uninventive but skilled spray-dryer one must have in mind what would be common general knowledge in that field. Likewise when one is considering what is obvious to the notional uninventive but skilled freeze-dryer. …" In Schlumberger Holdings Ltd v Electromagnetic Geoservices AS [2010] EWCA Civ 819 , [2010] RPC 33 at [53], Jacob LJ explained this passage thus: "… What Laddie J was saying was that where an invention involves the use of more than one skill, if it is obvious to a person skilled in the art of any one of those skills, then the invention is obvious. And rightly so, for it would otherwise impede a class of person who found it obvious. So here, if the invention was obvious to a CSEM expert alone or to a geophysicist alone, then the Patent is invalid. …" As will appear, I accept Motorola's construction of the word "transceiver". I agree with Microsoft that it follows that the Patent is directed both to a paging engineer and an email engineer. Common general knowledge I reviewed the law as to common general knowledge in KCI Licensing Inc v Smith & Nephew plc [2010] EWHC 1487 (Pat) , [2010] FSR 31 at [105]-[115]. That statement of the law was approved by the Court of Appeal [2010] EWCA Civ 1260 , [2011] FSR 8 at [6]. There is no dispute that the skilled person would know all the information I have set out under the heading "technical background" as part of his common general knowledge. In addition he would know the matters indicated below. Common general knowledge of the paging engineer . A common scenario in which one-way pagers were employed as at 31 August 1995 was where an organisation needed to send an urgent message to a group of people. An example of this would be a hospital sending a message to a group of doctors requesting that one of them attend an emergency. Once that message had been received and acknowledged by one doctor, a further message would be sent in order to inform the other doctors that they no longer needed to attend. I do not understand there to be any dispute that this use of one-way pagers was common general knowledge, but in any event the evidence clearly establishes that it was. In this situation, each pager typically had its own unique address. The principal dispute between the parties is whether the use of a plurality of pagers, whether one-way or two-way, with the same address was common general knowledge as at 31 August 1995. Microsoft contend that it was. Motorola accept that this was known, but dispute that it was common general knowledge. Dr Saunders thought that it was, based on his experience at Philips. On the other hand, Mr Deer gave evidence that SkyTel did not offer such a service at that time and he was not aware of any of their competitors offering such a service. He described it as "very rare". Counsel for Microsoft submitted that Dr Saunders' experience was more representative of the skilled addressee of the Patent in this respect. I am unable to accept that submission. Counsel for Microsoft also submitted that the statements in the specification at [0002] quoted above indicated that such use was common general knowledge. As counsel for Motorola pointed out, however, those statements do not necessarily mean that the situation described was common general knowledge. In any event, it is open to a patentee to prove that statements in his patent concerning the prior art are erroneous: see Gerber Garment Technology Inc v Lectra Systems Ltd [1995] FSR 492. Considering the evidence as a whole, I am not satisfied that Microsoft have established that the use of a multiplicity of pagers with the same address was common general knowledge. Common general knowledge of the email engineer . There was some disagreement between Mr Redmond and Mr Deer as to the state of the skilled person's capabilities with regard to wireless email systems, but this narrowed during cross-examination. Mr Redmond was clear that it was well within the capabilities of the skilled person to make email applications operate over different types of network, including wireless networks, typically using the TCP/IP protocol which enables network-independent communication. Not only did he have personal experience of implementing systems with full email functionality over WLANs, but also the documentary evidence confirms that WLAN devices such as PCMCIA cards for laptop computers were available which offered data rates of around 2 Mb/s, which was ample for sending simple emails. Mr Deer accepted that protocols such as PCMAIL and IMAP4 could be made to work over wireless communications, but thought this would be something of a challenge. I attribute this to his lack of experience with WLANs at the relevant date. To the extent that there was a conflict between them, I have no hesitation in preferring Mr Redmond's evidence. Construction In Virgin Atlantic Airways Ltd v Premium Aircraft Interiors UK Ltd [2009] EWCA Civ 1062 , [2010] RPC 8 at [5] the Court of Appeal summarised the general principles applicable to the construction of patent claims as follows: "One might have thought there was nothing more to say on this topic after Kirin-Amgen Inc v Hoechst Marion Roussel Ltd [2005] RPC 9 . The judge accurately set out the position, save that he used the old language of Art.69 EPC rather than that of the EPC 2000, a Convention now in force. The new language omits 'the terms of' from Art.69. No one suggested the amendment changes the meaning. We set out what the judge said, but using the language of the EPC 2000: [182] The task for the court 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. The principles were summarised by Jacob LJ in Mayne Pharma Pty Ltd v Pharmacia Italia SpA [2005] EWCA Civ 137 and refined by Pumfrey J in Halliburton Energy Services Inc v Smith International (North Sea) Ltd [2005] EWHC 1623 (Pat) following their general approval by the House of Lords in Kirin-Amgen Inc v Hoechst Marion Roussel Ltd [2005] RPC 9 . An abbreviated version of them is as follows: (i) The first overarching principle is that contained in Article 69 of the European Patent Convention. (ii) Article 69 says that the extent of protection is determined by the claims. It goes on to say that the description and drawings shall be used to interpret the claims. In short the claims are to be construed in context. (iii) It follows that the claims are to be construed purposively - the inventor's purpose being ascertained from the description and drawings. (iv) It further follows that the claims must not be construed as if they stood alone - the drawings and description only being used to resolve any ambiguity. Purpose is vital to the construction of claims. (v) When ascertaining the inventor's purpose, it must be remembered that he may have several purposes depending on the level of generality of his invention. Typically, for instance, an inventor may have one, generally more than one, specific embodiment as well as a generalised concept. But there is no presumption that the patentee necessarily intended the widest possible meaning consistent with his purpose be given to the words that he used: purpose and meaning are different. (vi) Thus purpose is not the be-all and end-all. One is still at the end of the day concerned with the meaning of the language used. Hence the other extreme of the Protocol - a mere guideline - is also ruled out by Article 69 itself. It is the terms of the claims which delineate the patentee's territory. (vii) It follows that if the patentee has included what is obviously a deliberate limitation in his claims, it must have a meaning. One cannot disregard obviously intentional elements. (viii) It also follows that where a patentee has used a word or phrase which, acontextually, might have a particular meaning (narrow or wide) it does not necessarily have that meaning in context. (ix) It further follows that there is no general 'doctrine of equivalents.' (x) On the other hand purposive construction can lead to the conclusion that a technically trivial or minor difference between an element of a claim and the corresponding element of the alleged infringement nonetheless falls within the meaning of the element when read purposively. This is not because there is a doctrine of equivalents: it is because that is the fair way to read the claim in context. (xi) Finally purposive construction leads one to eschew the kind of meticulous verbal analysis which lawyers are too often tempted by their training to indulge." As is often the case in patent actions, many of the issues on validity and infringement turn on the construction of the claims. Furthermore, as is not infrequently the case, Microsoft contend that there is a squeeze between validity and infringement when it comes to construction: if the claims are broadly construed then they may be infringed, but are invalid (or, on Microsoft's case, even more clearly invalid); whereas if the claims are narrowly construed they may be valid (or, on Microsoft's case, less clearly invalid), but are not infringed. Transceiver Motorola contend that "transceiver" means something that can transmit and receive. Microsoft accept that that is the acontextual meaning of the word, but contend that in the context of the Patent "transceiver" means "pager". In support of this Microsoft rely on the general thrust of the Patent, on the references to ReFlex in the description of the preferred embodiments and in particular on three passages in the specification. The first is at [0013] where the specification states that the operation of the wireless messaging infrastructure 110 "is well known to those skilled in the art". The second is at [0015] where it is said the operation of a paging transceiver "is well known in the art". Microsoft say that these passages indicate that "the art" is that of paging. The third passage is at [0038] (quoted in paragraph 34 above), which Microsoft say treats "transceivers" and "pagers" as synonyms. I am not persuaded by this argument. I accept that the preferred embodiments employ paging technology, but in my judgment the passages at [0012] and [0039] quoted above make it clear that the invention is not confined to pagers. Consistently with this, claim 7 is not limited to wireless systems. Message There is no dispute that "message" is an ordinary English word rather than a technical term. In the context of the claims, it is clear that there are two different types of message. The "first message" of claim 1 is a message having some information content of interest to a user. The "second message" and "third message" in claim 1 are what might be termed control messages or messages about messages. These messages are not intended to be seen by users and need not be in a user-readable format. Status Again, there is no dispute that "status" is an ordinary English word rather than a technical term. It is important to note that the word "status" is used both in claim 1 and claim 3, but in different ways. In claim 1, it is used to refer to the message, while in claim 3 it is used to refer to the transceiver. In the context of claim 1, it is clear both from the wording of the claim and from various passages in the specification, in particular at [0004], [0007], [0016], [00017], [0022] and [0025], that "status" refers to the condition or standing of the message. For example, the status of the message may be "unread", "read", "delete" or "protect". In the context of claim 3, it is clear both from the wording of the claim and from various passages in the specification, in particular at [0005], [0025] and [0032], that "status" refers to the condition or standing of the transceiver, and in particular the operating mode or information content of the transceiver. Responsive to/in response to The main dispute on construction concerns the meaning of "responsive to" in integer [F] of claim 1 and "in response to" in integer [F] of claim 7. Before proceeding further, it should be noted that this wording does not feature in claim 3. Since both parties concentrated on claim 1 in argument, and neither contended that claim 7 should be construed differently in this respect, I shall only consider claim 1. Motorola contend that "responsive to" means that the wireless messaging infrastructure transmits the third message to the second transceiver as a result of the receipt of the second message from the first transceiver. In other words, claim 1 contemplates systems in which the infrastructure initiates the sending of the third message. The point of this interpretation is to exclude methods of synchronising the status of messages in which the second transceiver requests updates from the infrastructure. As discussed below, however, Motorola accept that the receipt of the second message need not be the sole cause of the third message being transmitted by the infrastructure. Apart from the words of the claim, the only passage of the specification relied upon by Motorola in support of their construction is the statement at [0004] that message status changes are made "automatically" on the user's other pager(s). Microsoft dispute this interpretation. Microsoft contend that integer [F] of claim 1 covers methods in which the second transceiver requests updates from the infrastructure both as a matter of its plain language and having regard to its technical purpose. So far as the language of integer [F] is concerned, Microsoft say that the transmission of the third message by the infrastructure is equally "responsive to" the receipt of the second message whether the third message is sent on the initiative of the infrastructure or only after the second transceiver has requested an update (and in the latter case whether this is done periodically or only when specifically commanded by the user). As to the technical purpose, Microsoft say that the Patent is clear that the object of the invention of claim 1 is to avoid the "tedious task" described at [0004] and that this is equally avoided whether the status of messages on the second pager is updated without any request from the second pager or as a result of periodic requests for updates from the second pager (generally referred to as "polling") or a result of a specific request for updates. Either way, the result described at [0021] is obtained. Furthermore, Microsoft argue that the use of the word "automatically" in the specification at [0004] does not help Motorola for a number of reasons. First, that word does not appear in claim 1. Secondly, the word "automatically" is equally applicable to methods involving requests for updates, and in particular the case in which the second pager periodically polls the infrastructure for updates. Thirdly, the same word is used in [0007] and [0038], but claim 3 does not include the words "responsive to". Yet further, Microsoft point out that the Patent does not identify any problem with synchronisation methods which involve polling or a manual request by the user, still less does it purport to solve any such problem. Indeed, it does not refer to such methods at all. Before expressing my conclusion on these arguments, I must refer to the construction which has been placed on claim 1 by a German court. There are parallel proceedings between both Motorola and Microsoft and Motorola and Apple Sales International ("Apple") in Germany. In a judgment of the Landgericht Mannheim (Mannheim Regional Court) dated 3 February 2012 the Court (Judges Voß, Tochtermann and Schmidt) held that Apple had infringed claim 1 of the German counterpart of the Patent. The Mannheim Court construed claim 1 as meaning that (quoting from the agreed translation) "the second message need neither be the sole circumstance that triggers the transmission of the third message through the wireless infrastructure to the other transceiver, nor that the third message must be transmitted without chronological delay as soon as the second message has been received in the wireless messaging infrastructure" (B. II.3.(a).(bb)). There are two aspects to this construction. The first is that the claim does not require a chronologically immediate transmission of the third message upon receipt of the second message. This was common ground before me, and is plainly correct, as can be seen from e.g. claim 2. The second aspect was elaborated by the Mannheim Court as follows: "… the person skilled in the art will recognize that the teaching of the patent in suit in this respect would not be limited to a mono-causal connection between the receipt of the second message in the wireless messaging infrastructure and the transmission of the third message, since he would otherwise interpret the patent according to its wording. In the technical-functional transmission, the person skilled in the art will thus recognize that the third message is transmitted in response to (original wording 'responsive to') the receipt of the second message even if the transmission of the third message is promoted only as a concurrent cause of the receipt of the second message, but that at the same time other events that trigger the transmission or a chronological delay occur. …" Both counsel for Microsoft and counsel for Motorola submitted that the Mannheim Court's construction of "responsive to" was consistent with their respective interpretations. In my judgment, it is more consistent with Microsoft's interpretation than with Motorola's, since the Mannheim Court explicitly recognises that the receipt of the second message need not be the sole cause of the transmission of the third message by the infrastructure and that there may be other causes. That allows for the possibility that the other causes include requests for updates received from the second transceiver. When I put this to counsel for Motorola, he advanced three submissions in response. First, he submitted that the other causes contemplated by the Mannheim Court were limited to the setting up of communications between the infrastructure and the second transceiver. I see nothing in the Mannheim Court's construction which limits the additional causes in that way, however. Still less is there anything in the wording of claim 1 or the specification to support such a construction. Secondly, he pointed out that the Mannheim Court went on to say that it would be clear to the skilled person from [0004] that "not every method that achieves this performance outcome is protected by the patent". As counsel for Microsoft pointed out, however, that is not inconsistent with Microsoft's interpretation of claim 1. An obvious example of a method which is not covered on any view is peer-to-peer synchronisation between transceivers. Thirdly, counsel for Motorola pointed out that the Mannheim Court also held (at C.1.(aa)-(bb)) that PCMAIL did not deprive claim 1 of novelty. As counsel for Microsoft pointed out, however, the Mannheim Court's primary reason for this conclusion, which is clearly correct, is that PCMAIL does not disclose a wireless infrastructure. Although the Court also said that PCMAIL does not disclose that a third message is sent in response to the receipt of the second message, that statement was made in the context of a finding that the Court, as a non-technical court, was not persuaded that a finding of obviousness was highly probable. In my judgment, Microsoft's construction of "responsive to" is the correct one for the reasons they give which I have summarised above. The prior art Microsoft rely upon three items of prior art in support of their attack on the validity of the Patent as well as common general knowledge. Gutman . US Patent No 5,221,838 ("Gutman"), assigned to Motorola, Inc, was published on 22 June 1993. The aim of Gutman is to facilitate financial transactions by removing the need for a user to carry multiple financial cards, a cheque book and cash and by making it easier for a user to keep track of their account balance (col. 1 l. 15 to col. 3 l. 2). As Gutman points out (at col. 3 ll. 3-12), keeping track of the account balance is particularly problematic where two or more individuals (such as husband and wife or business partners) concurrently use multiple financial cards or cheque books for the same account. The invention has two aspects which are accurately summarised in the abstract as follows: "An electronic wallet includes memory for storing at least a balance corresponding to an account in a financial institution, and a selective call receiver for receiving a wireless message transmitted from a remote transmitter, the wireless message including financial information relating to the balance for confirming a financial transaction with the financial institution. A controller, coupled to the memory and to the receiver, can update the balance in the memory in response to the wireless message. [A] communication system enters financial transactions into the communication system from one of a plurality of associated portable data devices, and updates the financial transactions from the communication system to the one and to at least a second of the plurality of associated portable data devices via wireless message communication from at least one remote transmitter." In the description of the preferred embodiments, the communication system is a paging system 300. As shown schematically in Fig. 3, a financial institution computer system 306 communicates either directly or indirectly via a public switched telephone network (PSTN) or private branch exchange (PBX) 308 with the paging system 300 which in turn communicates with a selective call receiver 200 of an electronic wallet 100. The receiver 200 may encode and transmit a message to the financial institution computer 206 via paging transceivers 312 or 314 forming part of paging system 300. Figs. 5A to 5E show a number of exemplary transactions for the communication system 300. Microsoft particularly focus on Fig. 5E, which I reproduce below: In this example two electronic wallets 540 and 546 share an account with a financial institution 544. Wallet 1 enters into a transaction, such as a purchase, with a third party establishment 542. The numbered arrows show the sequence of messages transmitted via the communication system 300. Wallet 1 sends a purchase request (message 1) to the establishment. The establishment sends an authorisation request (message 2) to the financial institution. The financial institution sends an authorisation (message 3) to the establishment. The financial institution then sends a confirmation of the transaction and/or an updated account balance both to wallet 1 (message 4) and wallet 2 (message 5). Gutman goes on (at col. 16 ll. 12-32): "Moreover, a first wallet may be capable of updating financial information for a second wallet (i.e., similar to the cash transaction discussed above) to update an account limit or other transaction information for the second wallet via the financial institution and the communication system . Additionally, a security transaction (i.e., a lost electronic wallet requiring a user access control message to be sent by the communication system 300) may be updated to all electronic wallets ( and ) that share the account. Consequently, at least one electronic wallet may be secured accordingly, and other member electronic wallets ( ) may be updated with the security transaction information, as may be necessary for security procedures by the electronic wallets ( and ) in the communication system . Lastly the first wallet may be capable of monitoring transaction activity (e.g., financial transaction activity such as purchasing or other expenses) for the second wallet , including a balance summary for transactions initiated by the second wallet ." PCMAIL . This is a protocol for a distributed email system for personal computers. It is described in RFC ("Request for Comments") 1056 dated June 1988 credited to M. Lambert of MIT published by the Internet Engineering Task Force ("IETF"). A PCMAIL server or repository maintains the definitive copy of the user's email mailbox (the "global mail state"). The client software maintains a local copy of that mailbox state (the "local mail state") and periodically synchronises that copy with the global mail state. Multiple clients can access the same user mailbox on the server. PCMAIL is intended to work in two modes: with clients having a continuous connection to the server, and with clients connected only transiently. These are "interactive mode", where the client is continuously connected to the network, and "batch mode", where the user's email operations are stored locally and "batched" for later communication to the server when a connection is made. For present purposes, it is the interactive mode that is relevant. PCMAIL describes how the clients download the email messages received at the server by issuing a "fetch message" command. In response the server provides the message(s) requested. PCMAIL supports a number of flags for each email message e.g. flag #1 indicates whether the message has been "seen" (i.e. read by a user). When an email message is read by a user using a PCMAIL client, the client will change the value of flag #1 for that message, and then send a "set-message-flag" command to the server to inform it of the change. The server will then update the global mail state. Clients synchronise changes in message statuses by issuing a "fetch-changed-descriptors" command, in response to which the server will send a descriptor list which informs that client of the message flags which have changed since the last descriptor list was sent. PCMAIL explains at the end of section 6 that either the user must execute a synchronize command every so often or the client will synchronize for him automatically every so often. It is common ground that the latter is an express disclosure of polling. Section 7 of PCMAIL describes a current implementation of PCMAIL. Paragraph 7.2 of PCMAIL includes the following passage: "There is no provision for automatic synchronization whenever new mail arrives or old mail is changed by another client. Instead, users must get any new mail explicitly. A simple 'notification' program runs in the background and wakes up every minute to check for new mail; when mail arrives, the user executes a command to get the new mail, synchronizing the mailbox at the same time." IMAP4 . Internet Message Access Protocol version 4 or IMAP4 is an internet standards track protocol described in RFC 1730 dated December 1994 credited to M. Crispin of the University of Washington published by the IETF. As with PCMAIL, in IMAP4 the definitive copy of each mailbox is stored on the server, with a local version being stored on the client side. IMAP4 clients use the SELECT command to discover whether new email messages exist at the server. After the server informs them of the existence of new messages, clients use the FETCH command actually to retrieve their emails from the server. Email messages have flags including a "seen" flag, just as in PCMAIL. When a user reads an email, the client changes the value of the seen flag and then informs the server of that change with a STORE+FLAGS command. The server will then update its master copy of the mailbox. When a second client is connected to the same mailbox, the server will inform the second client of the change in the "seen" flag by sending a FETCH response. Thus far, IMAP4 is little different from PCMAIL. IMAP4 has certain additional features of relevance to this case, however. First, it is common ground that the server can unilaterally send what is called an "untagged response" consisting of "untagged data", that is to say, data which has not been specifically requested by the command to which the server is responding. It follows that, if the server has a message or message status update waiting to be sent to a client, it can "piggy back" the sending of that message or message status update onto a response to some other command sent by the client. For at least this reason, IMAP4 states at paragraph 2.2.2: "A client MUST be prepared to accept any server response at all times. This includes server data that it may not have requested." This point is repeated in paragraph 7. Secondly, IMAP4 includes a NOOP (pronounced NO-OP) command. The operation of this is described at paragraph 6.1.2 as follows: "The NOOP command always succeeds. It does nothing. Since any command can return a status update as untagged data, the NOOP command can be used as a periodic poll for new messages or message status updates during a period of inactivity." It is common ground that, read in context, this expressly discloses synchronisation of message statuses through polling by clients. There is a dispute between the parties as to whether IMAP4 also discloses a third feature in paragraph 5.3. At this stage, I shall simply set out the relevant passages. These include paragraph 5.2 as well as paragraph 5.3: "5.2 Mailbox Size and Message Status Updates At any time, a server can send data that the client did not request. Sometimes, such behaviour is required. For example, agents other than the server may add messages to the mailbox (e.g. new mail delivery), change the flags of message in the mailbox (e.g. simultaneous access to the same mailbox by multiple agents), or even remove messages from the mailbox. A server MUST send mailbox size updates automatically, if a mailbox size change is observed during the processing of a command. A server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly. Special rules exist for server notification of a client about the removal of messages to prevent the synchronization errors; see the description of the EXPUNGE response for more details. Regardless of what implementation decisions a client may take on remembering data from the server, a client implementation MUST record mailbox size updates. It MUST NOT assume that any command after initial mailbox selection will return the size of the mailbox. 5.3 Response when no Command in Progress Server implementations are permitted to send an untagged response (except for EXPUNGE) while there is no command in progress. Server implementations that send such responses MUST deal with flow control considerations. Specifically, they must either (1) verify that the size of the data does not exceed the underlying transport's available window size, or (2) use non-blocking writes." IMAP4 explains the EXPUNGE command at paragraph 6.4.3 as follows: "The EXPUNGE command permanently removes from the currently selected mailbox all messages that have the \Deleted flag set. Before returning an OK to the client, an untagged EXPUNGE response is sent for each message that is removed." It explains the EXPUNGE response at paragraph 7.3.3 as follows: "The EXPUNGE response reports that the specified message sequence number has been permanently removed from the mailbox. The message sequence number for each successive message in the mailbox is immediately decremented by 1, and this decrement is reflected in message sequence numbers in subsequent responses (including other untagged EXPUNGE responses)." Novelty The law 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. Gutman Microsoft contend that the example described with reference to Fig. 5E in Gutman anticipates claims 1, 3, 5 and 7. The simplest case is on claim 3, and so I shall start with that. There is no dispute that wallets 1 and 2 are a plurality of transceivers or that communication system 300 is a wireless messaging infrastructure. Microsoft submit that the account balance and other financial information clearly fall within the "status" of the transceivers as described in the Patent at [0025]. Changes in that status are notified by wallet 1 to the infrastructure and then the infrastructure updates the balance or other information stored in wallet 2. These are respectively the first and second messages of claim 3. Motorola submit that message 1 in Fig. 5E of Gutman is not a message indicative of a second status as required by the first message of claim 3 because it requires the approval or confirmation by the financial institution which only occurs after the latter has received message 2 from the establishment. Motorola's argument focuses upon the precise example shown in Fig. 5E itself. It is not necessary to decide whether that anticipates claim 3, because in my judgment the variants described at col. 16 ll. 12-32 (quoted in paragraph 82 above) clearly do. It is sufficient to consider the first variant, involving the account limit. Gutman states that wallet 1 can update this "via the financial institution 544 and the communication system 300". It does not mention the establishment 542 in connection with this variant. That makes perfect sense, since one would expect a request for, say, an increase in the account limit from £1000 to £2000 to be sent directly to the financial institution and not to the establishment. The entry of the requested limit by the user amounts to changing the status of wallet 1 from a first status to a second status. The request for the increased limit sent by wallet 1 to the financial institution via the infrastructure is the first message indicative of that second status. The approved request with the increased limit sent by the financial institution to wallet 2 via the infrastructure is the second message indicative of that second status. When the second message is received by wallet 2, the status of wallet 2 is changed to the requested limit. It is immaterial that the request for the increased limit must be approved by the financial institution, for two reasons. First, as Dr Saunders pointed out, in paging systems the infrastructure is always in control of what messages are passed on. In that sense the financial institution is just an extension of the infrastructure. Secondly, the characterising portion of claim 3 states that the method "includes" steps [E]-[G] and it may therefore include other steps. It follows that claim 5 is also anticipated. So is claim 7 subject to the question of whether the current state signal is sent "in response to" the synchronising. In my view this feature is anticipated if "in response to" is construed as Microsoft contend and I have accepted; but not if those words are construed as Motorola contend, since Gutman does not clearly disclose that the infrastructure initiates the sending of the current state signal. Turning to claim 1, Microsoft argue that this is also anticipated because there will be a continuous cycle of financial information being sent to and from each wallet. Thus a message received by wallet 1 as a result of one transaction will then form the basis for the next sequence of messages. I am not convinced by this argument. In my judgment Gutman does not clearly disclose changing the status of messages within the sense of claim 1 and then synchronising those changes. PCMAIL and IMAP4 Microsoft contend that both PCMAIL and IMAP4 anticipate claim 7 of the Patent. Motorola does not dispute this if claim 7 is construed as Microsoft contend and I have accepted. Equally, Microsoft does not dispute that claim 7 would be novel over PCMAIL and IMAP4 if it were to be construed as Motorola contend. Obviousness The law 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?" 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 (as he then was) 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." In assessing whether a claimed invention is obvious, it is always important, although difficult, to avoid hindsight. The fact that, after the event, it is easy to see how the invention could be arrived at by starting from an item of prior art and taking a series of apparently simple steps does not necessarily show that it was obvious at the time: British Westinghouse Electric & Manufacturing Co Ltd v Braulik (1910) 27 RPC 209 at 230 (Fletcher Moulton LJ), Non-Drip Measure Co Ltd v Strangers Ltd (1943) 60 RPC 135 at 142 (Lord Russell) and Technograph Printed Circuits Ltd v Mills & Rockley (Electronics) Ltd [1972] RPC 346 at 362 (Lord Diplock). Particular care needs to be taken with allegations that a claimed invention is obvious in the light of common general knowledge alone: Ratiopharm GmbH v Napp Pharmaceutical Holdings Ltd [2008] EWHC 3070 (Pat) at [159] (Floyd J). Skilled person, common general knowledge and inventive concept I have identified the skilled person and the common general knowledge above. This is not a case in which it is particularly helpful to consider the inventive concepts of the claims. Common general knowledge regarding pagers Microsoft contend that all the claims of the Patent are obvious in the light of the common general knowledge regarding pagers. Microsoft's case consists of three propositions: i) It was obvious to seek to synchronise messages on two-way pagers. ii) The message flow of the Patent is the only solution to that problem. iii) Propagating the updates without waiting for a request was the natural way to do it. Microsoft rely upon two starting points for this argument. The first is the proposition that the use of a plurality of pagers having the same call address was common general knowledge. Since I have not been satisfied that that was common general knowledge, it is unnecessary to consider it further. The second starting point is the sending of messages to groups of users as in the hospital scenario described in paragraph 48 above. I shall consider the way in which Microsoft elaborate the three propositions set out above in that context. First, with one-way pagers, the only way in which the first doctor could acknowledge receipt of the initial message was by telephone. Microsoft argue that, with the advent of two-way pagers, the obvious way for the first doctor to acknowledge receipt of the initial message was by sending a message back via the paging network. Furthermore, it was equally obvious to arrange for that acknowledgement to be communicated to the other doctors' pagers. Secondly, it was not practicable to arrange for pagers in a paging network to communicate peer-to-peer. Microsoft argue that it follows that the obvious, and indeed only, solution to the problem was for the first pager, once the user had received and read the first message, to send a second message indicating that fact to the paging terminal and for the paging terminal then to send a third message to all the pagers in the group indicating that the first message had been read. Thirdly, Microsoft argue that, in the context of paging, the natural way to achieve this was to arrange for the third message to be sent by the paging terminal immediately upon receipt of the second message (rather than waiting for a request from the pager). As counsel for Microsoft submitted, each of the propositions discussed above was supported by Dr Saunders' evidence and the evidence of Mr Deer in cross-examination. Counsel for Motorola nevertheless advanced a number of arguments against this case which I must consider. First, he suggested that the natural way to deal with the hospital scenario was for the first doctor to push a button on his pager to send a message saying that he was responding to the emergency. This does not help Motorola, however, since a message meaning "first message responded to" is just as much a message about the changed status of the first message as one meaning "first message read". Secondly, he submitted invention could lie in identifying a problem and considering it worth solving. In the present case, however, the problem and the potential solution only arose with the advent of two-way pagers. As at 31 August 1995, these were not even commercially available. Thirdly, he submitted that it was important to preserve pager battery life and thus counter-intuitive to deplete the battery life by multiple automatic transmissions. I do not accept this. As the Patent points out at [0003], battery life was not a significant concern with pagers by the priority date. Furthermore, even if it was, that would make it all the more desirable to arrange for the infrastructure to send message status updates without the pager having to request them. Fourthly, he submitted that Microsoft's case involved hindsight. I acknowledge the need to be wary of hindsight, and all the more so when dealing with an argument based on common general knowledge alone. Nevertheless, I find Microsoft's case compelling. Fifthly, he submitted that there was secondary evidence of non-obviousness in the form of a Philips RAMP protocol paging code specification dated 15 January 1996. As Dr Saunders accepted, this does not disclose the method of claim 1. Counsel argued that, if the method had been so obvious, it would have been included. I am not persuaded by this argument. RAMP was a general protocol for two-way paging, and there are other reasons why it may not have explicitly discussed synchronisation of message statuses. For what it is worth, Dr Saunders' evidence was that he for one had thought of the idea. Accordingly, I conclude that claim 1 is obvious even if "responsive to" is construed as Motorola contend. Claims 3 and 7 are also obvious for similar reasons. Claims 4 and 5 add nothing inventive in my view, but I do not consider that Microsoft have established that claims 2 and 6 are obvious on this basis. Gutman Given my previous conclusions on novelty, the issue is whether claims 1, 2 and 6 are obvious over Gutman. Counsel for Motorola submitted that the invention could not be obvious over Gutman since the skilled person would not have come across it during the ordinary course of his research. That is legally irrelevant. It is trite law that the skilled person is deemed to have found Gutman, and to have read it with care and in that sense with interest. While evidence may show that the skilled person would not have regarded a particular piece of prior art as relevant to the problem at hand, that is not the case with Gutman. Gutman is in the same field of technology as the Patent, namely paging technology. Given that it is a US patent assigned to Motorola, a leader in that field in 1995, the skilled person would take it seriously. The difference between claim 1 and Gutman is that Gutman does not disclose synchronisation of message statuses as opposed to transceiver statuses. Dr Saunders' evidence was that it would be obvious to the skilled person reading Gutman that the method of synchronising two paging devices disclosed in col. 16 could be applied more generally as a means of synchronising message statuses on pagers. He maintained this in cross-examination. Mr Deer essentially accepted this: "Q. I am trying to look at matters more substantively and to discuss with you the message flow in Gutman. A. Okay. Q. With that in mind, would you agree that Gutman gives a method of synchronising multiple pager clients which could be used more extensively than just in its own context, and in particular could be used for synchronising ordinary consumer pages? A. Yes, with that in mind, that you are sending messages and you are updating to get to a common status." Having regard to this evidence, I conclude that claim 1 is obvious in the light of Gutman. As for claims 2 and 6, Dr Saunders' evidence was that it was well known in paging to delay the sending of a control message for the purpose of reducing the number of transmissions. In the light of that evidence, I conclude that claims 2 and 6 are obvious over Gutman. PCMAIL On Microsoft's construction of claim 1, which I have accepted, the only difference between PCMAIL and claim 1 is that, as noted above, PCMAIL does not disclose implementation over a wireless network. Motorola did not seriously dispute that that would be technically obvious, however, and on the evidence I have no doubt that it was. On Motorola's construction of claim 1, there is an additional difference, which is that PCMAIL does not disclose infrastructure-initiated sending of the third message to the second transceiver in response to receipt of the second message. Microsoft contend that, even on that basis, claim 1 is obvious in the light of paragraph 7.2 of PCMAIL, which explicitly draws attention to the fact PCMAIL does not provide such functionality. Mr Redmond's evidence was it would have been obvious to a skilled person reading paragraph 7.2 in 1995 to provide for server-initiated synchronization "in a system based on PCMAIL". This evidence was not directly challenged in cross-examination. Instead it was put to him that it would not be obvious "to completely redesign PCMAIL" to provide that functionality. That is beside the point, because re-designing a standardised protocol such as PCMAIL is difficult for reasons that have nothing to do with whether the change is technically obvious or not. In any event, as Mr Redmond explained, it would have been technically straightforward to design a vendor extension to PCMAIL to provide this feature. Mr Deer accepted that a skilled person thinking of designing an email protocol who read paragraph 7.2 in 1995 would appreciate that what was being described was a limitation of PCMAIL and that it would be obvious to think about improving that by providing for automatic synchronisation (meaning the server sending out updates without waiting for requests from the client). Counsel for Motorola relied on the facts that PCMAIL was seven years old in 1995 and had been largely superseded by protocols like IMAP4. I am unimpressed by those points. There is nothing to suggest that PCMAIL would have been regarded as technically obsolescent in 1995, and the skilled person was entitled to do anything that was obvious in the light of PCMAIL without fear of infringing a patent. In the light of the evidence, I conclude that claim 1 is obvious over PCMAIL even on Motorola's construction. The same must go for claim 3. In my judgment there is nothing inventive in any of claims 2, 4, 5 or 6. So far as claims 2 and 6 are concerned, PCMAIL discloses requesting updates periodically. It would be obvious to send updates from the server after a delay rather than immediately in order to save network resources. IMAP4 Before addressing Microsoft's case on obviousness, I must resolve the dispute between the parties as to what paragraph 5.3 of IMAP4 discloses. Microsoft contend that it discloses the possibility of the server sending updates to the client without any request to do so. Motorola deny this. Microsoft argue that, whereas paragraph 5.2 is concerned with the mode of operation I have described in paragraph 93 above, paragraph 5.3 is describing something different. In support of this argument, Microsoft particularly rely upon the fact that paragraph 5.2 talks about sending updates "during the processing of a command", whereas paragraph 5.3 talks about sending untagged responses "while there is no command in progress" and upon the fact that the language of paragraph 5.3 is mirrored in paragraph 7.3.3. Microsoft also say it makes technical sense for EXPUNGE responses to be excepted, because otherwise message sequence numbers could easily get out of kilter. Motorola argue that paragraph 5.3 is addressing the same situation as paragraph 5.2, and is merely drawing attention to the need for flow control to be considered in that situation. They say that the words "while there is no command in progress" mean "while no command is being specifically responded to". Microsoft's interpretation was supported to the hilt by Mr Redmond, who said during the course of cross-examination that paragraph 5.3 was "black and white on the point". Mr Deer's evidence is encapsulated in the following exchange: "Q. I think you agree that on its face, it does appear to say that servers are allowed to send a truly unilateral response when there is no command in progress? A. Yes, on its face it does say that, but when you take the document as a whole that is not how I interpreted it --". In addition to IMAP4 itself, and Mr Deer's evidence, Motorola relied upon (i) the fact that no such functionality is mentioned in books containing descriptions of IMAP4 and (ii) such functionality was explicitly included in Push-IMAP in March 2006. I do not find either of these points persuasive. So far as point (i) is concerned, as Mr Redmond pointed out, the passages in question are relatively brief general descriptions. They do not condescend to the kind of detail contained in paragraph 5.3. As for point (ii), the fact that a more elaborate version of the same thing was made a prominent feature of IMAP in 2006 does not demonstrate that it was not disclosed as a possibility in paragraph 5.3 of IMAP4. In my judgment Microsoft's interpretation of paragraph 5.3 is persuasive, and I accept it. On that basis, it follows that the only difference between IMAP4 and claim 1 is that IMAP4 does not explicitly disclose implementation over a wireless network. As with PCMAIL, Motorola did not seriously dispute that that would be obvious, however, and on the evidence I have no doubt that it was. Again, the same goes for claim 3. Again, I see nothing inventive in claims 2, 4, 5 or 6. Even if paragraph 5.3 is to be interpreted as Motorola contend, in the light of the evidence of Mr Redmond and Mr Deer I conclude that claim 1 was obvious over IMAP4 for similar reasons as in relation to PCMAIL. Infringement Motorola alleges that Microsoft have infringed claims 1, 3, 5 and 7 of the Patent by acts committed in relation to two classes of Microsoft software products, namely Exchange ActiveSync ("EAS") and Live Messenger. An allegation of infringement in relation to a third class of products, Lync, was abandoned in Motorola's closing submissions. Both EAS and Live Messenger are designed to work with a wide range of hardware and software, including a range of hardware and software produced by third parties. Pursuant to an order of Floyd J dated 23 July 2012, Microsoft have served Product and Process Descriptions ("PPDs") for three exemplary systems (two EAS and one Live Messenger). In the case of EAS, Motorola contend, in effect, that the PPD is inconsistent with documents relating to EAS published by Microsoft, or at least incomplete. This gives rise to a factual issue which I will consider below. Microsoft do not dispute that, if claim 1 of the Patent (save for the term "transceiver") is construed in the manner contended for by Microsoft, as I have held, then it follows in the case of both EAS and Live Messenger that Microsoft have committed infringing acts by supplying "means essential" within section 60(2) of the Patents Act 1977. In case I am wrong about that, however, I shall consider whether Microsoft have committed infringing acts if claim 1 is construed as contended for by Motorola. Exchange ActiveSync . EAS is a protocol published by Microsoft to enable third parties to write client software that will enable clients to communicate and synchronise mailbox and other information with Microsoft Exchange servers (such as are used by many companies). The infringement case revolves around the way that clients use the commands of the EAS protocol to synchronise email message status updates. The key protocol document is the "ActiveSync Command Reference Protocol Specification" (also known as "[MS-ASCMD]"). The EAS PPD describes two actual systems which implement EAS. While EAS provides for many commands, the two that matter for this case are SYNC and PING. I will consider these in turn. SYNC . The SYNC command is a command used by an EAS client to synchronise its local state of an email folder (e.g. the Inbox) with the folders held on the Exchange server. The SYNC request specifies the folder(s) with which the client wishes to synchronise (e.g. "Inbox"). The server response informs the client of the relevant changes – both new items and changes to (including deletion of) existing items in that folder. Thus it will include changes in the status of email messages. The format of the SYNC request includes an optional argument called HeartbeatInterval. This is a specified period of time (from 60 to 3540 seconds) which the server is asked to wait before responding. Motorola use the term "hanging SYNC" to describe such a SYNC request which includes a HeartbeatInterval, and that terminology was adopted by Microsoft for the purposes of the trial. When a hanging SYNC request is issued by a client, if there are no changes waiting in the folder at the time the request is received, and no changes occur during the HeartbeatInterval, the server will respond at the end of the specified period indicating no changes. If a new email is added to the relevant folder (e.g. a new email arrives in the Inbox), the server interrupts the HeartbeatInterval and immediately sends a response containing all changes. There is no dispute about the matters in the foregoing paragraph. There is a dispute, however, in relation to what happens when the status of an existing email is changed (e.g. from "unread" to "read"). Microsoft say that in such a case the server will continue to wait, until either a new item is received or the HeartbeatInterval expires, before sending the status change to the client. Motorola dispute this. So far as this issue is concerned, the position appears to be as follows. First, there are actual implementations of EAS which operate in the manner contended for by Microsoft. These are described in the EAS PPD and illustrated in Figures 5 and 6 thereof. Secondly, EAS permits implementations in which the server interrupts the HeartbeatInterval to send a SYNC response whenever there is any change in the relevant folder, including a status change. Thirdly, there is no evidence of any actual implementation of that kind. Accordingly, I will confine consideration to the implementations described in the EAS PPD. Motorola contend that, upon Motorola's construction of claim 1, such implementations infringe. Motorola argue that, when the client issues a hanging SYNC command, it is saying "Please leave this channel open for a period". During that period, the server is able to send information to the client, including in some instances status updates, as soon as it arrives at the server. I do not accept this argument for two reasons. First, I do not accept that claim 1 embraces such an arrangement even on Motorola's construction. This is because such an arrangement still involves a request for updates from the client rather than purely server-initiated transmission of updates. Secondly, if claim 1 does cover such an arrangement, then it also covers the NOOP command in IMAP4. That would mean that, even if paragraph 5.3 of IMAP4 is to be interpreted as Motorola contend, the only distinction between IMAP4 and claim 1 would be that IMAP4 does not disclose implementation over a wireless network. For the reasons given above, that would be obvious. In short, the consequence of Motorola's infringement argument, if accepted, would be to make it even clearer that claim 1 was invalid. PING . The PING command is similar to the SYNC command, except that the response merely indicates that changes to the relevant folder(s) have occurred (e.g. the arrival of a new email in the Inbox or that an existing email in the Inbox has been read). It does not indicate what those changes are. To find out what those changes are, the client has to make a SYNC request, the response to which will contain the actual update information. A PING request also specifies a HeartbeatInterval. The behaviour in such a case is the same as for SYNC as described above (subject to the point that the PING response does not contain any actual update information, just the fact that an update is available). As with SYNC, there is a dispute about what happens when the status of an existing email is changed. My conclusion is the same. On that basis, my conclusion with regard to the infringement issue is also the same. Live Messenger . Live Messenger is an instant messaging ("IM") system. As is common in IM systems, users have a status (called "presence state") which other users can see, such as "Available" or "Busy". The way in which a user can manually change their presence state in Messenger from "Available" to "Busy" is described in the Messenger PPD. The process is similar to what happens with a hanging SYNC in EAS: the device issues a long poll request containing a "lifespan" that is akin to a HeartbeatInterval. Accordingly, my conclusion in relation to the infringement is the same as for the hanging SYNC. Google Licence The Patent was originally owned by Motorola, Inc. On 4 January 2011 the business of Motorola, Inc was split into two parts, which were acquired by Motorola Mobility Inc ("MMI") and Motorola Solutions Inc respectively. As part of this, the Patent was assigned to MMI. On 22 May 2012 MMI was acquired by Google, Inc. Subsequently MMI changed its name to Motorola Mobility LLC. It is common ground that, as a result of the acquisition of MMI by Google, the Patent became subject to a pre-existing cross-licence between Microsoft Corporation and Google dated 5 January 2009 ("the Google Licence"). Microsoft contend that, even if the Patent is valid and would otherwise be infringed by EAS, Microsoft have a licence under the Google Licence which covers EAS. Motorola dispute this. Who is right depends on the correct interpretation of the Google Licence. The relevant terms of the Google Licence are as follows: "1. Definitions . Capitalized terms used in this Agreement are defined in this Section 1 or elsewhere in this Agreement. 1.1 ' Active Mailbox ' means a Mailbox that has successfully synched any PIM information using the Protocol with at least one EAS Client at least once during the applicable Royalty Period. 1.2 ' EAS Client ' means a client that connects to the Internet to synchronize PIM information using the Protocol. … 1.6 ' Mailbox ' means an account maintained by a Service that is capable of storage or synchronization of any PIM information using the Protocol at some point between the Service and an EAS Client. … … 1.8 ' Necessary Claims ' means the claims of a patent or patent application that a Party or any of its Subsidiaries owns or has the right to sublicense without a fee and that are necessarily infringed by implementing the Protocol in accordance with the Technical Documentation in order to interoperate with EAS Clients. Necessary Claims do not include any claims to any underlying or enabling technology that may be used or made available in connection with the Protocol or an Implementation, or to any implementation of technical documentation, specifications or technologies that are merely referred to in the body of the Technical Documentation. 1.9 ' PIM information ' means any personal information management (PIM) information, including, without limitation, email, calendar, contacts, or tasks. 1.10 ' Protocol ' means the Microsoft Exchange ActiveSync ('EAS') protocol, as described in the Technical Documentation. … 1.14 ' Service(s) ' means Google's hosted services that … provide PIM information to EAS Clients … … 1.16 ' Technical Documentation ' means the technical documentation described in Section 2.5 below. … 2.1 Microsoft License . Microsoft hereby, limited to the Term and subject to Google's compliance with Sections 2.2, 2.3 and 3, grants Google a worldwide, non-exclusive, non-sublicensable license under Microsoft's Necessary Claims to make and use implementations for the sole purpose of allowing the Service to interoperate with EAS Clients. … 2.4 Google License . Google hereby, limited to the Term and subject to Microsoft's compliance with Section 2.5(b), grants Microsoft a worldwide, non-exclusive, royalty-free, non-sublicensable license under Google's Necessary Claims to make, use, sell, offer to sell, import or otherwise make available those portions of any software program that implement the Protocol in accordance with the Technical Documentation to interoperate with EAS Clients. 2.5 Technical Documentation . (a) Initial Documentation . Microsoft has provided and Google has received the Microsoft Exchange ActiveSync Client Protocol Document Version 2.0.16 ('Initial Documentation'). (b) Updates . Microsoft will provide Google with any updates to or additional technical documentation for the Protocol that are made available by Microsoft to other licensees of the Protocol during the Term, including any such updates corresponding to Implementations of the Exchange ActiveSync protocol in any version of Microsoft Exchange Server that is released during the Term ('Updates'). Microsoft will provide Updates to Google through a publicly available website." Although the Google Licence is subject to New York law, neither side has adduced any evidence of New York law. Accordingly, it is common ground that that it should be interpreted in accordance with the principles of contractual interpretation stated by Lord Hoffmann in Investors Compensation Scheme Ltd v West Bromwich Building Society [1998] 1 WLR 896 at 912-913. As Lord Hoffmann summarised it in the later cases of Bank of Credit and Commerce International SA v Ali [2001] UKHL 8 , [2002] 1 AC 251 at [37] and Chartbrook Ltd v Persimmon Homes Ltd [2009] UKHL 38 , [2009] 1 AC 1011 at [14], the correct approach is to ask what a reasonable person having all the background knowledge which would have been available to the parties at the time would have understood them to be using the language of the contract to mean. The issue is quite a narrow one: does "implementing the Protocol in accordance with the Technical Documentation in order to interoperate with EAS Clients" "necessarily infringe" the Patent within clause 1.8 of the Google Licence? Motorola contend that this does not necessarily infringe, because the Protocol does not require the use of a plurality of transceivers, whereas the Patent claims do. Microsoft disputes this, for three main reasons. First, because Microsoft are being sued under section 60(2) for supplying "means essential" for putting the invention into effect, in particular its Exchange server software and EAS clients on Windows mobile devices. On Motorola's case, supplying such software necessarily infringes the Patent because people will use multiple mobile devices with their Exchange server, and Microsoft cannot help but know this: see Grimme Maschinenfabrik GmbH & Co KG v Scott [2010] EWCA Civ 1110 , [2011] FSR 7 and KCI Licensing Inc v Smith & Nephew plc [2010] EWCA Civ 1260 , [2011] FSR 8 . Thus it is impossible actually to implement any software in accordance with the EAS protocol which does not infringe the Patent on this basis. Accordingly, the claims are "necessarily infringed" by doing so. Secondly, because the Protocol specifically provides support for multiple clients. The SYNC command has specific functionality to enable a client to synchronise the status of messages in its local state with the status of those messages on the server. This assumes such statuses may be different (e.g. on the server a message is marked "read" but at the client it is "unread"). This happens when the same messages are accessed by multiple clients. Further, there is functionality for resolving conflicts which arise due to multiple clients. Indeed, the Google Licence itself specifically envisages that under the licence, multiple clients will be accessing a single mailbox – see the reference to "at least one EAS Client" in clause 1.1. Thirdly, because any other interpretation of clause 2.4 of the Google Licence would, by parity of reasoning, deprive Google of the benefit of clause 2.1 of the Google Licence, which cannot have been the intention of the parties. In my judgment these arguments are convincing, and in particular the first one. Accordingly, I conclude that Microsoft can claim the benefit of the Google Licence in relation to EAS. Summary of conclusions For the reasons given above, I conclude that: i) claims 3, 5 and 7 lack novelty over Gutman; ii) claim 7 lacks novelty over PCMAIL and IMAP4; iii) claims 1, 3-5 and 7 are obvious over the common general knowledge of paging, specifically the hospital scenario; iv) claims 1, 2 and 6 are obvious over Gutman; v) claims 1-6 are obvious over PCMAIL; vi) claims 1-6 are obvious over IMAP4; vii) if the Patent is valid, contrary to the conclusions summarised above, Microsoft have infringed it by the supply of both EAS and Live Messenger, subject in the case of EAS to the Google Licence; viii) Microsoft can claim the benefit of the Google Licence in relation to EAS. BAILII: Copyright Policy | Disclaimers | Privacy Policy | Feedback | Donate to BAILII