Trials@uspto.gov
`Tel: 571-272-7822
`
`
`
`
`
`
`
`
`
`
`
`
` Paper 8
`
`
`
`Entered: December 4, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`FACEBOOK, INC. and WHATSAPP INC.,
`Petitioner,
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG S.A.,
`Patent Owner.
`____________
`
`Case IPR2017-01427
`Patent 8,995,433 B2
`____________
`
`
`
`Before MIRIAM L. QUINN, KERRY BEGLEY, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`QUINN, Administrative Patent Judge.
`
`
`
`
`DECISION and ORDER
`Institution of Inter Partes Review and Conduct of the Proceeding
`37 C.F.R. § 42.108, § 42.5(a)
`
`
`
`
`
`Tel: 571-272-7822
`
`
`
`
`
`
`
`
`
`
`
`
` Paper 8
`
`
`
`Entered: December 4, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`FACEBOOK, INC. and WHATSAPP INC.,
`Petitioner,
`
`v.
`
`UNILOC USA, INC. and UNILOC LUXEMBOURG S.A.,
`Patent Owner.
`____________
`
`Case IPR2017-01427
`Patent 8,995,433 B2
`____________
`
`
`
`Before MIRIAM L. QUINN, KERRY BEGLEY, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`QUINN, Administrative Patent Judge.
`
`
`
`
`DECISION and ORDER
`Institution of Inter Partes Review and Conduct of the Proceeding
`37 C.F.R. § 42.108, § 42.5(a)
`
`
`
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`INTRODUCTION
`I.
`The above-captioned Petitioner (Facebook, Inc. and WhatsApp Inc.)
`filed a Petition requesting inter partes review of claims 1−8 of U.S. Patent
`No. 8,995,433 B2 (Ex. 1001, “the ’433 patent”). Paper 2 (“Pet.”). Uniloc
`USA, Inc. and Uniloc Luxembourg S.A. (“Patent Owner”) filed a
`Preliminary Response. Paper 7 (“Prelim. Resp.”).
`We have jurisdiction under 35 U.S.C. § 314. Upon considering the
`record developed thus far, for reasons discussed below, we institute inter
`partes review of claims 1−8 of the ’433 patent.
`
`A. Related Matters
`The parties indicate that the ’433 patent is involved in Uniloc USA,
`Inc. v. Facebook, Inc. and Uniloc USA, Inc. v. WhatsApp Inc., Case Nos.
`2-16-cv-00728-JRG (E.D. Tex.) and 2:16-cv-00645-JRG (E.D. Tex.).
`Pet. 1−2. The ’433 patent also is the subject of Case IPR2017-00225 (filed
`by Apple Inc.), in which we instituted inter partes review on May 25, 2016.
`Pet. 75–77; Paper 6. Petitioner additionally filed a Petition and Motion
`seeking joinder with IPR2017-00225, both which were granted, and, thus,
`Petitioner has been joined with Apple in IPR2017-00225. See Case
`IPR2017-01634, Paper 10 (PTAB Oct. 3, 2017).
`We note that the deadline for issuing the Final Written Decision in
`IPR2017-00225 is May 25, 2018. Because Petitioner here is joined as a
`petitioner in IPR2017-00225 (concerning claims 1−6 and 8 of the
`’433 patent), Petitioner’s involvement in both inter partes reviews would
`raise the issue of estoppel under 35 U.S.C. § 315(e)(1), which states that
`“petitioner in an inter partes review of a claim in a patent under this chapter
`
`2
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`that results in a final written decision under section 318(a) . . . may not
`request or maintain a proceeding before the Office with respect to that claim
`on any ground that the petitioner raised or reasonably could have raised
`during that inter partes review.” To ascertain the impact, if any, of
`§ 315(e)(1) to the instant proceeding, the parties to this proceeding shall
`brief the issue with simultaneous briefing, of no more than 5 pages, due on
`DUE DATE 6 of IPR2017-00225, currently set for January 25, 2018. This
`briefing is necessary to determine the proper course of conduct in this
`proceeding. 37 C.F.R. § 42.5(a).
`
`B. The ’433 Patent
`The ’433 patent relates to Internet telephony, and more particularly, to
`instant voice over IP (“VoIP”) messaging over an IP network, such as the
`Internet. Ex. 1001, 1:19−23. The ’433 patent acknowledges that “instant
`text messaging is [] known” in the VoIP and public switched telephone
`network (“PSTN”) environments, with its server presenting the user a “list
`of persons who are currently ‘online’ and ready to receive text messages on
`their own client terminals.” Id. at 2:35−42. In one embodiment, such as
`depicted in Figure 2 (reproduced below), the system of the ’433 patent
`involves an instant voice message (“IVM”) server and IVM clients. Id. at
`7:21−22.
`
`3
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`
`Figure 2 illustrates IVM client 206 interconnected via network 204 to
`local IVM server 202, where IVM client 206 is a VoIP telephone, and where
`legacy telephone 110 is connected to legacy switch 112 and further to media
`gateway 114. Id. at 7:27−49. The media gateway converts the PSTN audio
`signal to packets for transmission over a packet-switched IP network, such
`as local network 204. Id. at 7:49−53. In one embodiment, when in “record
`mode,” the user of an IVM client selects one or more IVM recipients from a
`list. Id. at 8:2−5. The IVM client listens to the input audio device and
`records the user’s speech into a digitized audio file at the IVM client. Id. at
`
`4
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`8:12−15. “Once the recording of the user’s speech is finalized, IVM client
`208 generates a send signal indicating that the digitized audio file 210
`(instant voice message) is ready to be sent to the selected recipients.” Id. at
`8:19−22. The IVM client transmits the digitized audio file to the local IVM
`server, which, thereafter, delivers that transmitted instant voice message to
`the selected recipients via the local IP network. Id. at 8:25−26. Only the
`available IVM recipients, currently connected to the IVM server, will
`receive the instant voice message. Id. at 8:36−38. If a recipient “is not
`currently connected to the local IVM server 202,” the IVM server
`temporarily saves the instant voice message and delivers it to the IVM client
`when the IVM client connects to the local IVM server (i.e., is available). Id.
`at 8:38−43.
`The ’433 patent also describes an “intercom mode” of voice
`messaging. Id. at 11:34−37. The specification states that the “intercom
`mode” represents real-time instant voice messaging. Id. at 11:37−38. In this
`mode, instead of creating an audio file, one or more buffers of a
`predetermined size are generated in the IVM clients or local IVM servers.
`Id. at 11:38−41. Successive portions of the instant voice message are
`written to the one or more buffers, which as they fill, automatically transmit
`their content to the IVM server for transmission to the one or more IVM
`recipients. Id. at 11:41−46. Buffering is repeated until the entire instant
`voice message has been transmitted to the IVM server. Id. at 11:46−59.
`
`5
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`C. Independent Claims
`Of the challenged claims, claim 1 and 6 are independent and are
`reproduced below. Each of claims 2−5, 7, and 8 depends directly or
`indirectly from claim 1.
`
`
`A system comprising:
`1.
`an instant voice messaging application including a client
`platform system for generating an instant voice message and a
`messaging system for transmitting the instant voice message
`over a packet-switched network via a network interface;
`wherein the instant voice messaging application displays
`a list of one or more potential recipients for the instant voice
`message;
`wherein the instant voice messaging application includes
`a message database storing the instant voice message, wherein
`the instant voice message is represented by a database record
`including a unique identifier; and
`wherein the instant voice messaging application includes
`a file manager system performing at least one of storing, deleting
`and retrieving the instant voice messages from the message
`database in response to a user request.
`
`A system comprising:
`6.
`an instant voice messaging application including a client
`platform system for generating an instant voice message and a
`messaging system for transmitting the instant voice message
`over a packet-switched network via a network interface;
`wherein the instant voice messaging application displays
`a list of one or more potential recipients for the instant voice
`message;
`wherein the instant voice messaging application includes
`a file manager system performing at least one of storing, deleting
`
`
`
`
`
`6
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`and retrieving the instant voice messages from a message
`database in response to a user request; and
`wherein the instant voice messaging application includes
`a compression/decompression system for compressing the
`instant voice messages
`to be
`transmitted over
`the
`packet-switched network and decompressing the instant voice
`messages received over the packet-switched network.
`Ex. 1001, 23:65−24:15, 24:33−51.
`
`D. Asserted Prior Art and Grounds of Unpatentability
`This proceeding relies on the following prior art references:
`
`a) Zydney: PCT App. Pub. No. WO 01/11824 A2, published Feb. 15,
`2001, filed in the record as Exhibit 1003 (with line numbers added
`by Petitioner);
`
`b) Appelman: U.S. Patent No. US 6,750,881 B1, issued June 15,
`2004, filed in the record as Exhibit 1004; and
`
`c) Clark: U.S. Patent No. US 6,725,228 B1, issued Apr. 20, 2004,
`filed in the record as Exhibit 1008.
`
`Petitioner asserts two grounds of unpatentability (Pet. 4):
`
`Challenged
`Claim(s)
`1−6, 8
`
`Basis
`
`References
`
`§ 103(a)
`
`Zydney and Clark
`
`7
`
`§ 103(a)
`
`Zydney, Clark, and Appelman
`
`Petitioner also relies on a Declaration of Tal Lavian, Ph.D., filed as
`Exhibit 1002.
`
`7
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`II. DISCUSSION
`A. Claim Construction
`In an inter partes review, claim terms in an unexpired patent are given
`their broadest reasonable construction in light of the specification of the
`patent in which they appear. 37 C.F.R. § 42.100(b); Cuozzo Speed Techs.,
`LLC v. Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the
`broadest reasonable interpretation standard as the claim interpretation
`standard to be applied in inter partes reviews). Under the broadest
`reasonable interpretation standard, claim terms generally are given their
`ordinary and customary meaning, as would be understood by one of ordinary
`skill in the art in the context of the entire disclosure. See In re Translogic
`Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). We note that only those
`claim terms that are in controversy need to be construed, and only to the
`extent necessary to resolve the controversy. See Nidec Motor Corp. v.
`Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017);
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir.
`1999).
`Petitioner proposes constructions for the terms “instant voice
`messaging application” and “client platform system.” Pet. 9−15. Patent
`Owner points out alleged deficiencies in Petitioner’s proposed constructions,
`but argues that “neither term requires any contrived construction.” Prelim.
`Resp. 6−11. For purposes of determining whether to institute review, we
`need not construe expressly any term at this time.
`
`8
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`B. Overview of Asserted Prior Art
`We discuss more fully certain disclosures in the asserted references in
`
`our analysis below. A discussion of those references follows.
`
`1. Zydney
`Zydney, titled “Method and System for Voice Exchange and Voice
`Distribution,” relates to packet communication systems that provide for
`voice exchange and voice distribution between users of computer networks.
`Ex. 1003, [54], [57], 1:4–5. While acknowledging that e-mail and instant
`messaging systems were well-known text-based communication systems
`utilized by users of on-line services and that it was possible to attach files for
`the transfer of non-text formats via those systems, Zydney states that the
`latter technique “lack[ed] a method for convenient recording, storing,
`exchanging, responding and listening to voices between one or more parties,
`independent of whether or not they are logged in to their network.” Id. at
`1:7–17. Zydney thus describes a method in which “voice containers”—i.e.,
`“container object[s] that . . . contain[] voice data or voice data and voice data
`properties”—can be “stored, transcoded and routed to the appropriate
`recipients instantaneously or stored for later delivery.” Id. at 1:19–22; 12:6–
`8. Figure 1 of Zydney is reproduced below.
`
`9
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`Figure 1, above, illustrates a high level functional block diagram of
`Zydney’s system for voice exchange and voice distribution. Id. at 10:19–20.
`Referring to Figure 1, system 20 allows software agent 22, with a user
`interface, in conjunction with central server 24 to send messages using voice
`containers illustrated by transmission line 26 to another software agent 28,
`as well as to receive and store such messages, in a “pack and send” mode of
`operation. Id. at 10:20–11:1. Zydney explains that a pack and send mode of
`operation “is one in which the message is first acquired, compressed and
`then stored in a voice container 26 which is then sent to its destination(s).”
`Id. at 11:1–3. The system has the ability to store messages both locally and
`centrally at server 24 whenever the recipient is not available for a prescribed
`period of time. Id. at 11:3–6.
`
`10
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`In the use of Zydney’s system and method, the message originator
`selects one or more intended recipients from a list of names that have been
`previously entered into the software agent. Id. at 14:17–19. The agent
`permits distinct modes of communication based on the status of the
`recipient, including the “core states” of whether the recipient is online or
`offline and “related status information” such as whether the recipient does
`not want to be disturbed. Id. at 14:19–15:1. Considering the core states, the
`software agent offers the originator alternative ways to communicate with
`the recipient, the choice of which can be either dictated by the originator or
`automatically selected by the software agent, according to stored rules. Id.
`at 15:3–6. If the recipient is online, the originator can either begin a
`real-time “intercom” call, which simulates a telephone call, or a voice instant
`messaging session, which allows for an interruptible conversation. Id. at
`15:8–10. If the recipient is offline, the originator can either begin a voice
`mail conversation that will be delivered the next time the recipient logs in or
`can be delivered to the recipient’s e-mail as a digitally encoded
`Multipurpose Internet Mail Extension (“MIME”) attachment. Id. at 15:15–
`17. Zydney explains that the choice of the online modes “depends on the
`activities of both parties, the intended length of conversation and the quality
`of the communication path between the two individuals, which is generally
`not controlled by either party,” and that the choice of the offline delivery
`options “is based on the interests of both parties and whether the recipient is
`sufficiently mobile that access to the registered computer is not always
`available.” Id. at 15:10–14, 15:17–19.
`Once the delivery mode has been selected, the originator digitally
`records messages for one or more recipients using a microphone-equipped
`
`11
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`device and the software agent. Id. at 16:1–3. The software agent
`compresses the voice and stores the file temporarily on the PC if the voice
`will be delivered as an entire message. Id. at 16:3–4. If the real-time
`“intercom” mode has been invoked, a small portion of the digitized voice is
`stored to account for the requirements of the Internet protocols for
`retransmission and then transmitted before the entire conversation has been
`completed. Id. at 16:4–7. Based on status information received from the
`central server, the agent then decides on whether to transport the voice
`containers to a central file system and/or sends it directly to another software
`agent using the IP address previously stored in the software agent. Id. at
`16:7–10. If the intended recipient has a compatible active software agent on
`line after log on, the central server downloads the voice recording almost
`immediately to the recipient. Id. at 16:10–12. The voice is uncompressed
`and the recipient can hear the recording through the speakers or headset
`attached to its computer. Id. at 16:12–14. The recipient can reply in a
`complementary way, allowing for near real-time communications. Id. at
`16:14–15. If the recipient’s software agent is not on line, the voice
`recording is stored in the central server until the recipient’s software agent is
`active. Id. at 16:15–17. In both cases, the user is automatically notified of
`available messages once the voice recordings have been downloaded to
`storage on their computer. Id. at 16:17–19. The central server coordinates
`with software agents on all computers continuously, updating addresses,
`uploading and downloading files, and selectively retaining voice recordings
`in central storage. Id. at 16:19–21.
`Zydney discloses that the voice container also has the ability to have
`other data types attached to it. Id. at 19:6–7. Formatting the container using
`
`12
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`MIME format, for example, “allows non-textual messages and multipart
`message bodies attachments [sic] to be specified in the message headers.”
`Id. at 19:7–10.
`Figure 3 of Zydney is reproduced below.
`
`
`Figure 3, above, illustrates an exemplary embodiment of Zydney’s voice
`container structure, including voice data and voice data properties
`components. Id. at 2:19, 23:1–2. Referring to Figure 3, voice container
`components include:
`[O]riginator’s code 302 (which is a unique identifier), one or
`more recipient’s code 304, originating time 306, delivery
`time(s) 308, number of “plays” 310, voice container source 312
`which may be a PC, telephone agent, non-PC based appliance, or
`other, voice container reuse restrictions 314 which may include
`one
`time and destroy 316, no forward 318, password
`
`13
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`retrieval 320, delivery priority 322, session values 324, session
`number 326, sequence number for partitioned sequences[] 328,
`repeating information 330, no automatic repeat 332, repeat
`times 334, and a repeat schedule 336.
`Id. at 23:2–10.
`
`2. Appelman
`Appelman, titled “User Definable On-line Co-user Lists,” describes a
`real-time notification system that enables a user to define “buddy lists” to
`track co-users of an online or network system. Ex. 1004, [54], [57]. The
`system tracks for the user the log-on status of the co-users and displays that
`information in real time to the tracking user in a graphical interface. Id. at
`[57]. When the user logs on to a system, the user’s set of buddy lists is
`presented to a buddy list system, which attempts to match co-users currently
`logged into the system with the entries on the user’s buddy list, and any
`matches are displayed to the user. Id. As co-users log on and log off, the
`user’s buddy list is updated to reflect the changes. Id.
`Figure 2a of Appelman is reproduced below.
`
`14
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`Figure 2a, above, illustrates “a set of symbolic data records showing the
`basic types of data used by one embodiment of [Appelman’s] invention for a
`buddy list[] and the conceptual relationship of data elements.” Id. at 2:15–
`18. With reference to Figure 2a, Group Name table 30 stores user-defined
`group names for buddy lists. Id. at 3:36–37. Each user may define multiple
`buddy lists by group names. Id. at 3:38. Two buddy lists, “Home List” and
`“Work List,” are shown in Group Name table 30. Id. at 3:39. Each group
`name in Group Name table 30 has an associated Buddy List table 32,
`comprising multiple records that each correspond to a co-user (or “buddy”)
`that the user wishes to track. Id. at 3:39–43. Each record may include data
`elements for the screen name (or address, such as an Internet address) of a
`particular co-user to be tracked, and the logon status of that user (e.g., codes
`for “In” or “Out”). Id. at 3:43–47.
`Figure 11 of Appelman is reproduced below.
`
`15
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`Figure 11, above, is a flowchart showing an implementation of Appelman’s
`invention. Id. at 2:41–42. In the illustrated implementation, a user logs into
`a Logon System (Step 200), which notifies the Buddy List System about the
`User (i.e., passes the User’s ID, address, or screen name to the Buddy List
`System) (Step 202). Id. at 6:53–58. The Buddy List System accesses the
`user’s buddy lists from a database, which may be, for example, on the user’s
`own station (Step 204). Id. at 6:58–60. The entries in the user’s buddy lists
`then are compared to the records of the Logon System (Step 206). Id. at
`6:60–62. Appelman explains that this step is shown in dotted outline to
`indicate that the comparison can be done by passing records from the Logon
`System to the Buddy List System, or vice versa, or could be done by a
`separate system. Id. at 6:62–65. The Buddy List System then displays a
`buddy list window showing the status (i.e., logged in or not) of the co-users
`
`16
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`on the user’s buddy lists with any of various indicator markings (Step 208).
`Id. at 6:66–7:2. Thereafter, while the user’s buddy list window is open,
`the Logon System notifies the Buddy List System about new logons/logoffs
`of co-users (Step 210), causing a new compare of the user’s buddy list
`entries to the Logon System records (Step 206). Id. at 7:3–7. Appelman
`explains that the Logon System may, for example, maintain a copy of a
`user’s buddy lists and notify the Buddy List System only upon a logon status
`change for a co-user on the user’s buddy lists. Id. at 7:8–11. The Buddy
`List System then updates the indicated status of the displayed co-users
`(Step 208). Id. at 7:11–12.
`
`3. Clark
`Clark, titled “System for Managing and Organizing Stored Electronic
`
`Messages,” is directed to systems for managing and organizing electronic
`messages. Ex. 1008, [54], 1:8−9. According to Clark,
`A computer-based system catalogs and retrieves electronic
`messages saved in a message store. The system automatically
`organizes each saved message into multiple folders based on the
`contents and attributes of the message, and implements improved
`methods for manually organizing messages.
`Id. at [57]. A particularly relevant embodiment in Clark is shown in
`Figure 4A, reproduced below.
`
`17
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`
`Figure 4A illustrates system 40A with client computer 18 implementing
`catalog server 29 and catalog database 28, and also including message
`client 27, message store 23, and message store server 24. Id. at 10:29−33.
`Each message store 23 comprises a memory, file, or database structure that
`provides temporary or permanent storage for the contained messages. Id. at
`9:13−16. Clark describes the invention as providing catalog database 28
`(and preferably catalog server 29) to organize the contents of one or more
`message stores 23. Id. at 9:54−57. Catalog database 28 and message
`store 23 may be separate from one another or may be integrated in a single
`integrated message store. Id. at 11:1−3. In the embodiment where they are
`separate from each other, illustrated in Figure 5A (reproduced below),
`catalog database 28 may be linked to a separate external message store 23.
`Id. at 11:3−7.
`
`18
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`
`Figure 5A depicts the linking between catalog database 28 and external
`message store 23, where StoreLink table 51 contains rows, each with a
`StoreID pointing to a linked message store 23, and catalog database 28
`includes MessageSummary table 52, which contains StoreMessageId 52A of
`messages in message store 23. Id. at 11:25−33. The Figure 5A embodiment
`
`19
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`also shows that messages 22 are stored in Message table 54 in message store
`23 and that attachments are stored in Attachment table 55 in message store
`23. Id. at 35−37.
`
`C. Analysis of Petitioner’s Contentions
`Petitioner points to Zydney as disclosing all the claim 1 limitations,
`except that it relies on Clark’s disclosure of a message store as disclosing the
`claimed message database and file manager system. Pet. 28−55. Claim 6 is
`similar in scope to claim 1 but, unlike claim 1, does not recite that the
`“instant voice message is represented by a database record including a
`unique identifier.”
`
`1. Claim 1
`Petitioner maps the “instant voice messaging application” to the
`software agent running on a client computer of the sending user. Pet. 29.
`For the “client platform system” and “messaging system,” Petitioner relies
`on Zydney’s disclosure of the software agent function of recording a voice
`container and transport process. Id. at 30−34. For the “display [of] a list of
`one or more potential recipients,” Petitioner points to Zydney’s disclosure,
`in Figure 7, of the originator selecting “one or more recipients from a list
`maintained by the originator and presented visually by the agent.” Id. at 39
`(emphases in Petition omitted).
`Claim 1 recites, in part, “wherein the instant voice messaging
`application includes a message database storing the instant voice message,
`wherein the instant voice message is represented by a database record
`including a unique identifier.” Ex. 1001, 24:7−10 (emphases added).
`Petitioner points to Zydney as disclosing a message database because it
`
`20
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`describes “saving, deleting or resending recorded containers from the
`recipient’s computer” and storing messages locally. Pet. 40−42. Petitioner
`argues that “Zydney does not use the term ‘message database’ to describe
`storage of instant voice messages on the client system, but the storage in
`Zydney meets the claim under its broadest reasonable construction.” Id. at
`42 (emphasis in original omitted). We do not agree with these contentions.
`The claim recites the “message database” as being included in an “instant
`voice messaging application.” Thus, we look for Zydney’s disclosure of a
`database included in the software agent of a sender (the alleged “instant
`voice message application, see id. at 29). None of the “storing” disclosures
`identified by Petitioner disclose a database, much less one that is included in
`the software agent. Accordingly, we are not persuaded by Petitioner’s
`argument that Zydney alone would disclose the recited “message database.”
`In the alternative, Petitioner argues that the limitation would have
`been obvious in view of Clark. Id. at 42. Petitioner argues that Clark’s
`message store 23 discloses a message database and that Clark’s
`StorageMessageId is the recited “unique identifier.” Id. at 43. Petitioner
`points out that the unique identifier represents the “underlying stored
`message and can be used to retrieve it,” relying on the following disclosure
`of Clark: “Using the StoreMessageId 52A and the related StoreId 51A,
`catalog server 29 can make requests to the message store server 24 to read
`messages from message store 23.” Id. at 49 (citing Ex. 1008, 11:38−40).
`Patent Owner challenges Petitioner’s assertions as failing to show “that a
`single database record in Clark includes both a unique identifier and an
`instant voice message,” because Clark discloses that the MessageSummary
`table and the Message table are in separate data stores. Prelim. Resp. 14.
`
`21
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`Patent Owner also argues that although the catalog database and message
`store may be combined, as shown in Figure 5B of Clark, none of the tables
`shown in Figure 5B of Clark includes the StoreMessageID, which Petitioner
`maps to the unique identifier. Id. at 14−15. Further, based on Clark’s
`disclosures that the message is stored in a message store while the
`StoreMessageID is stored at the catalog, Patent Owner argues that Clark
`teaches away from including the message data in the same database record
`as the unique identifier. Id. at 16−17.
`Patent Owner’s arguments are not persuasive at this time to rebut
`Petitioner’s showing. Patent Owner’s arguments are premised on an
`interpretation of the claim language requiring that: (1) the instant voice
`message is stored in the recited database record; and (2) the message
`database includes the database record. Neither requirement is expressly
`recited in the claim language. And the record at this juncture is devoid of
`briefing of the parties’ claim construction positions for this phrase, such that
`we could determine, even preliminarily, that the scope of claim 1 includes
`these two alleged requirements. Accordingly, guided by the plain reading of
`the claim language, we do not agree with Patent Owner that Petitioner has
`failed to proffer institution-sufficient evidence that Clark discloses the
`recited “message database” and the “database record including a unique
`identifier.”
`With regard to the motivation to combine, Patent Owner argues that
`Petitioner’s proposed combination would result in inoperability and teaching
`away from the claimed invention. Id. at 18−19. In particular, Patent Owner
`argues that because Zydney teaches deleting the sent instant voice message
`from the client’s temporary storage, any combination with Clark would
`
`22
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`result in Clark deleting the messages from the client, thereby running
`counter to Clark’s stated goal of cataloging electronic messages. Id. We are
`not persuaded by this argument on the present record. We understand the
`Petition to combine the teachings of Clark’s message store for the purpose
`that Clark gives for such use: to catalog and retrieve messages saved in a
`message store. Ex. 1008, [57]. Although Zydney deletes the sent message
`from the temporary storage, Patent Owner does not show any disclosure in
`Zydney that would teach away from seeking and achieving the use and
`purpose of Clark’s message store. The disclosure in Zydney of a “reserved
`temporary storage” does not teach away from using a different storage
`altogether (a message store) or from the purposes disclosed in Clark for
`storing and cataloging messages on a more persistent basis.
`Claim 1 further requires that the instant voice message application
`includes a “file manager system performing at least one of storing, deleting
`and retrieving the instant voice message from the message database in
`response to a user request.” Ex. 1001, 24:11−15. For this limitation,
`Petitioner relies on various disclosures of Zydney and Clark as disclosing the
`limitation. Pet. 50−55. More particularly, Petitioner argues that Clark
`discloses a “message database system for storing and organizing both sent
`and received messages, which can be instant voice messages.” Id. at 52.
`Petitioner cites Clark: “Message client 27 will typically generate requests in
`response to user input such as requests to message store sever 24 to add,
`change or delete a message.” Id. (citing Ex. 1008, 18:25−29). This citation
`pertains to the embodiment shown in Figure 2 of Clark, reproduced below.
`
`23
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`
`
`Figure 2 of Clark depicts system 20 comprising several software
`components which operate in a computer system. Ex. 1008, 9:7−10. Clark
`states that “[e]ach message store 23 comprises a memory, file or database
`structure that provides temporary or permanent storage for the contained
`messages 22.” Id. at 9:13−15. Further, “[a] message store server 24
`manages the messages 22 in message store 23.” Id. at 9:15−16. Concerning
`the implementation of the database, Clark states it uses shortcuts and folders
`to handle the stored messages. Id. at 8:57−9:5 (cited substantially in the
`Petition at pages 52−53). Dr. Lavian opines that a person of ordinary skill in
`the art would have understood that when a user selects and views a message
`stored in the database, the system is retrieving the message from message
`store 23. See Pet. 53 (citing Ex. 1002 ¶ 227). Petitioner proffers various
`
`24
`
`
`
`IPR2017-01427
`Patent 8,995,433 B2
`
`reasons for combining the relevant teachings of Zydney and Clark.
`Pet. 44−48, 54−55.
`Patent Owner challenges Petitioner’s assertions regarding the “file
`manager system” because Petitioner relies on certain operations that Zydney
`performs at the receiving device, not the sending device. Prelim.
`Resp. 21−22. And regarding Petitioner’s reliance on Zydney’s “sending”
`operations, Patent Owner contends those operations are described to take
`place in a temporary storage, not a database. Id. at 22−23. These arguments
`are not persuasive because we have focused our institution determination on
`the Petition’s arguments regarding Clark, not Zydney, for this limitation.
`As for Petitioner’s reliance on Clark’s disclosures, Patent Owner
`argues that Clark describes requests being passed from
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
