CLientConNECt Ltd v. MyMail Ltd

1. Case Identification

• Case #: IPR2015-00269
• Patent #: 8,275,863
• Filed: November 14, 2014
• Petitioner(s): ClientConnect Ltd., ClientConnect, Inc., Conduit Ltd., and Perion Network Ltd.
• Patent Owner(s): MyMail, Ltd.
• Challenged Claims: 1-2, 4-5, 10-11, 14-17, 20, and 23

2. Patent Overview

• Title: Method and System for Modifying a Toolbar
• Brief Description: The ’863 patent discloses a method for automatically updating a software toolbar on a user's device. The method involves the user device sending a "revision level" to a server, which then determines if an update is necessary and, if so, sends update data back to the device to modify the toolbar.

3. Grounds for Unpatentability

Ground 1: Anticipation of Claims 1-2, 11, 14-17, 20, and 23 by Reilly under 35 U.S.C. §102(e)

• Prior Art Relied Upon: Reilly (Patent 5,740,549).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Reilly, which describes the PointCast Network software, discloses every limitation of the challenged claims. Reilly teaches a graphical user interface with a toolbar for accessing personalized content. The toolbar's configuration is stored in "Data Access Tables," which function as the claimed toolbar-defining databases. In Reilly's update process, the client device automatically sends a revision level (a timestamp in the user profile) to a server during a scheduled connection. The server uses this timestamp to determine if an update is needed and sends back new data. The client device then receives this update data and, without user interaction, updates its local database, including the Data Access Tables, thereby producing an updated toolbar.

Ground 2: Claims 1-2, 4-5, 11, 14-17, 20, and 23 are obvious over Filepp in view of Morten under 35 U.S.C. §103

• Prior Art Relied Upon: Filepp (Patent 5,347,632), Morten (Patent 5,021,949).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that Filepp, which describes the architecture of the Prodigy online service, teaches a system with a toolbar ("command bar") and a method for updating its components ("page element objects"). In Filepp, a client device requests an object from a server by specifying its "version id." The server checks this version for currency and sends a new object if the client's version is stale, which is then used to update the display automatically. This process discloses the core claimed method of updating a toolbar based on a revision level.
  • Motivation to Combine: The network in Filepp was based on IBM's proprietary System Network Architecture (SNA), while the ’863 patent claims an Internet-based system. Morten discloses a method for connecting SNA-based hosts over an IP-based network. Petitioner argued a POSITA would combine Morten's Internet-bridging technology with Filepp's system to adapt it for the burgeoning Internet. This combination would reduce costs, provide users access to vast Internet resources, expand the service's global reach, and increase network speed.
  • Expectation of Success: The combination was argued to be predictable, as Morten was designed specifically to adapt SNA-based systems like Filepp's for communication over IP networks without requiring significant modification to the underlying application.

Ground 3: Claims 1-2, 11, 14-17, 20, and 23 are obvious over Reilly in view of Tuniman under 35 U.S.C. §103

• Prior Art Relied Upon: Reilly (Patent 5,740,549), Tuniman (Patent 5,644,737).

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner again relied on Reilly for its disclosure of an automatic, revision-level-based software update method for a toolbar. Tuniman was cited for its extensive disclosure of software with fully configurable toolbars, providing users with dialog boxes to control properties, add/delete buttons, and modify visual attributes.
  • Motivation to Combine: A POSITA would combine Reilly's automatic update method with Tuniman's configurable toolbars to improve user experience and system efficiency. The combination would automate toolbar updates, making the process faster and more seamless than the manual configuration required in Tuniman. For developers, this would provide a reliable method to distribute the most current version of the toolbar, including new functions and bug fixes, to all users automatically.
  • Expectation of Success: Applying a known automatic software update method (Reilly) to a specific type of software like a configurable toolbar (Tuniman) was presented as a predictable design choice for a POSITA seeking to improve software maintenance and usability.

• Additional Grounds: Petitioner asserted additional challenges, including that claims 1-2, 4-5, 11, 14-17, 20, and 23 are anticipated by Filepp. Further obviousness grounds were asserted for claims 2 and 10 over Filepp in view of Olsen (a PC Magazine article) and over Reilly in view of December (a book on the World Wide Web), primarily to add teachings related to integrating web browsers and opening URLs.

4. Key Claim Construction Positions

• "attribute": Petitioner argued for the construction "defined property of an entity or object." This broad construction was supported by the patent's examples (e.g., button caption, URL) and contemporaneous dictionary definitions. This interpretation is important because it allows data structures in the prior art, like the categories in Reilly's Data Access Tables, to meet the "plurality of attributes" limitation.
• "automatically": Petitioner proposed the construction "independently of user direction or control." This was based on the patent's consistent usage of the term for actions not directly initiated by the user. This construction is central to the argument that the prior art's background update processes, which occur without a specific user command to "check for updates," meet the claims.
• "web browser": For dependent claim 2, Petitioner proposed that "web browser" be construed as a "software application which enables a user to access information via a network." This construction is based on the patent's own references and common understanding and is used to map functionality described in secondary references to the claims.
• "name-value pair": For dependent claim 4, Petitioner proposed construing "name-value pair" as a "unique name that is paired with a value that is set in a database." This interpretation, derived from figures in the ’863 patent, is used to argue that data structures in the prior art meet this specific limitation.

5. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1-2, 4-5, 10-11, 14-17, 20, and 23 of the ’863 patent as unpatentable.