PTAB
IPR2014-01528
Amazon.com Inc v. Personalized Media Communications LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2014-01528
- Patent #: 7,783,252
- Filed: September 22, 2014
- Petitioner(s): Amazon.com, Inc. and Amazon Web Services, LLC
- Patent Owner(s): Personalized Media Communications, LLC
- Challenged Claims: 1-3, 5, 9-14, 18-23, 27-32, 36-41, 45-46, 50-52
2. Patent Overview
- Title: Reprogramming Receiver Stations
- Brief Description: The ’252 patent describes methods for remotely reprogramming or controlling receiver stations. The core claimed method involves storing a "specific version" of an operating system, receiving a transmission with a "designated version," determining if the specific version is the same as the designated version, and if so, replacing the old operating system instructions with new ones.
3. Grounds for Unpatentability
Ground 1: Obviousness over Nachbar in view of Schmidt - Claims 1-3, 5, 9-14, 18-23, 27-32, 36-41, 45-46, 50-52 are obvious over Nachbar in view of Schmidt
- Prior Art Relied Upon: Nachbar (a 1986 USENIX conference proceeding on network file systems) and Schmidt (Patent 4,558,413).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Nachbar disclosed a software system called "track" that addressed the problem of maintaining software, including UNIX operating system files, on multiple networked "subscriber" machines from a central "librarian" machine. This system involved storing a local version ("measure of currentness"), receiving a master list ("statfile") from the librarian, comparing the versions, and requesting an update if the local version was older. Petitioner asserted this taught nearly all limitations of claim 1. The primary alleged distinction was that the claim required communicating new instructions when the local and designated versions were equal, whereas Nachbar updated when the local version was older. Schmidt was introduced to teach this specific comparison, as it disclosed a system for updating software objects that involved identifying an earlier version of a file and replacing it with a new version.
- Motivation to Combine: A POSITA would combine Nachbar and Schmidt because both references addressed the same fundamental problem of remote software maintenance. Petitioner contended that the specific comparison logic (updating if older vs. updating if versions match a designated target) was a simple and obvious design choice. A POSITA would have been motivated to implement either method to achieve the known goal of ensuring software currency across a network.
- Expectation of Success: A POSITA would have had a high expectation of success because implementing the comparison logic from Schmidt within Nachbar's framework was a well-understood, routine modification in the field of software distribution.
Ground 2: Obviousness over Tamaru in view of Nachbar and Schmidt - Claims 1-3, 5, 9-14, 18-23, 27-32, 36-41, 45-46, 50-52 are obvious over Tamaru in view of Nachbar and Schmidt
- Prior Art Relied Upon: Tamaru (Patent 4,788,637), Nachbar, and Schmidt.
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Tamaru, as the primary reference, disclosed a method for managing network communication devices. It taught a "version comparator" that determined if a version number in a received data packet was newer than the version of the program stored locally. If the local version was older, the device would request and receive the newer program, overwriting the old one. Petitioner asserted this met most limitations of claim 1. However, Petitioner identified two alleged gaps: (1) Tamaru did not expressly disclose executing the new program after the update, and (2) like Nachbar, Tamaru updated based on a "newer than" comparison, not an "equal to" comparison. Nachbar was added to supply the teaching of executing instructions after a file has been copied to ensure an update takes effect. Schmidt was added for the same reason as in Ground 1: to supply the allegedly obvious design choice of comparing for equality with a designated version.
- Motivation to Combine: A POSITA would combine Tamaru with Nachbar's teaching of post-update execution to ensure that the newly updated program would run and its improved functionality could be used, which is the inherent goal of any software update. The motivation to incorporate Schmidt’s comparison logic was the same as in Ground 1—it represented a known, alternative method for version control to solve the same technical problem addressed by Tamaru.
- Expectation of Success: A POSITA would expect success in combining these elements as they represented standard, modular concepts in software and network management. Executing a program after loading it and choosing a specific version comparison logic were routine tasks for a software engineer at the time.
4. Key Claim Construction Positions
- "Version": Petitioner argued this term should be construed to mean the variation or iteration release of software (e.g., version 1.0, 2.1) and not the "type" of hardware or software (e.g., IBM PC vs. Apple). This position was supported by the specification's examples ("versions 1.0, 1.10, 2.00, etc.") and the prosecution history, where the examiner removed the word "type" from the phrase "type or version" in the claims before allowance.
- "Operating System Instructions": Petitioner argued for a broad interpretation that includes application software instructions, not just instructions for a device's most basic functions. This was based on specification language describing these instructions as containing "all instructions required... to control the operation of said apparatus," which would encompass applications that control portions of the device's operation.
5. Key Technical Contentions (Beyond Claim Construction)
- Priority Date: A central contention was that the ’252 patent was not entitled to its claimed 1981 priority date. Petitioner argued that the 1981 specification lacked written description support for key claim limitations, such as storing a specific version of an operating system, determining if it matches a designated version, and erasing old instructions before storing new ones. Petitioner asserted that the applicants explicitly disclaimed the 1981 priority date during prosecution, stating that the application asserted priority only to a 1987 filing. This later priority date of September 11, 1987, was crucial as it rendered Nachbar (1986) and Tamaru (filed 1986) valid prior art.
6. Relief Requested
- Petitioner requested the institution of an inter partes review and the cancellation of claims 1-3, 5, 9-14, 18-23, 27-32, 36-41, 45-46, and 50-52 of the ’252 patent as unpatentable.
Analysis metadata