IPR 2015-01607 Elia Data - Petition

IPR2015-01607 U.S. Patent No. 7,113,996

DOCKET NO.: 2211726-00121US1 Filed on behalf of Unified Patents Inc. By: David L. Cavanaugh, Reg. No. 36,476 Thomas Anderson, Reg. No. 37,063 Michael Van Handel, Reg. No. 68,292

Wilmer Cutler Pickering Hale and Dorr LLP 1875 Pennsylvania Ave., NW Washington, DC 20006 Tel: (202) 663-6000 Email: [email protected]

Jonathan Stroud, Reg. No. 72,518 Unified Patents Inc. 1875 Connecticut Ave. NW, Floor 10 Washington, D.C., 20009 Tel: (202) 805-8931 Email: [email protected]

UNITED STATES PATENT AND TRADEMARK OFFICE ____________________________________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD

____________________________________________

UNIFIED PATENTS INC. Petitioner

v.

Elia Data of Texas, LLC Patent Owner

IPR2015-01607 Patent 7,113,996

PETITION FOR INTER PARTES REVIEW OF

U.S. PATENT NO. 7,113,996 CHALLENGING CLAIMS 1-3 and 14-16

UNDER 35 U.S.C. 312 AND 37 C.F.R. 42.104

IPR2015-01607 U.S. Patent No. 7,113,996

i

TABLE OF CONTENTS

I. Mandatory Notices ............................................................................................. 1A. Real Party-in-Interest .................................................................................... 1B. Related Matters .............................................................................................. 1C. Counsel .......................................................................................................... 1D. Service Information, Email, Hand Delivery, and Postal ............................... 2

II. Certification of Grounds for Standing ............................................................... 2III. Overview of Challenge and Relief Requested ................................................. 2

A. Prior Art Patents and Printed Publications .................................................... 2B. Grounds for Challenge .................................................................................. 3

IV. Technology Background .................................................................................. 3V. Overview Of the 996 Patent ............................................................................. 4

A. Summary of the Alleged Invention ............................................................... 4B. Level of Ordinary Skill in the Art ................................................................. 6C. Prosecution History ....................................................................................... 6

VI. Claim Construction ........................................................................................... 8A. secure packet .............................................................................................. 8B. secure relay ................................................................................................ 9C. second node successively forwards ......................................................... 10D. retrieval packet ......................................................................................... 10

VII. Specific Grounds for Petition ...................................................................... 11A. Ground I: Claim 1-3 and 14-16 are anticipated by Free Haven. ............... 11

1. Overview of Free Haven .......................................................................... 112. Claim 1 is anticipated by Free Haven. .................................................... 123. Claim 2 is anticipated by Free Haven. .................................................... 174. Claim 3 is anticipated by Free Haven. .................................................... 185. Claim 14 is anticipated by Free Haven. .................................................. 206. Claim 15 is anticipated by Free Haven. .................................................. 247. Claim 16 is anticipated by Free Haven. .................................................. 26

IPR2015-01607 U.S. Patent No. 7,113,996

ii

B. Ground II: Claims 1 is obvious in view of DeSimone and Munger. .......... 271. Overview of DeSimone ............................................................................. 272. Claim 1 is obvious over DeSimone in view of Munger. ........................... 28

C. Claims 2, 3, and 14-16 are Obvious in view of DeSimone, Munger, and ... 401. Overview of DeSimone ............................................................................. 402. Claim 2 is obvious in view of DeSimone, Munger, and Francis ............. 403. Claim 3 is Obvious in view of DeSimone, Munger, and Francis ............. 444. Claim 14 is Obvious in view of DeSimone, Munger, and Francis ........... 485. Claim 15 is obvious in view of DeSimone, Munger, and Francis ........... 566. Claim 16 is Obvious in view of DeSimone, Munger, and Francis ........... 58

VIII. Conclusion ................................................................................................... 60

IPR2015-01607 U.S. Patent No. 7,113,996

1

I. MANDATORY NOTICES

A. Real Party-in-Interest

Pursuant to 37 C.F.R. 42.8(b)(1), Unified Patents Inc. (Unified or

Petitioner) certifies that Unified is the real party-in-interest, and further certifies

that no other party exercised control or could exercise control over Unifieds

participation in this proceeding, the filing of this petition, or the conduct of any

ensuing trial. In this regard, Unified has submitted voluntary discovery. See

EX1015 (Petitioners Voluntary Interrogatory Responses).

B. Related Matters

U.S. Pat. No. 7,113,996 (996 Patent (EX1001)) is owned by Elia Data of

Texas, LLC (Elia Data or Patent Owner).

On May 1, 2015, Elia Data filed lawsuits against Dropbox, Box, SugarSync,

and Google, claiming that certain of these companies products and/or services

infringe the 996 Patent. The cases are in their early stages and no schedule or trial

date has been set. Between April 5, 2012, and June 21, 2013, Elia Data filed

lawsuits against Microsoft, Citrix Systems, International Business Machines (IBM),

Apple, and Amazon. Each of these lawsuits has been dismissed with prejudice.

C. Counsel

David L. Cavanaugh (Reg. No. 36,476) will act as lead counsel; Jonathan

Stroud (Reg. No. 72,518), Thomas Anderson (Reg. No. 37,063), and Michael Van

Handel (Reg. No. 68,292) will act as back-up counsel.

IPR2015-01607 U.S. Patent No. 7,113,996

2

D. Service Information, Email, Hand Delivery, and Postal

Unifed consents to electronic service at [email protected]

and [email protected]. Petitioner can be reached at Wilmer, Cutler,

Pickering, Hale and Dorr, LLP, 1875 Pennsylvania Ave., NW Washington, DC

20006 and (202) 663-6000, Fax: 202-663-6363 and Unified Patents Inc., 1875

Connecticut Ave. NW, Floor 10, Washington, D.C., 20009, (650) 999-0899.

II. CERTIFICATION OF GROUNDS FOR STANDING

Petitioner certifies pursuant to Rule 42.104(a) that the patent for which

review is sought is available for inter partes review and that Petitioner is not

barred or estopped from requesting an inter partes review challenging the patent

claims on the grounds identified in this Petition.

III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)-(2), Petitioner challenges

claims 1-3 and 14-16 of the 996 Patent.

A. Prior Art Patents and Printed Publications

The following references are pertinent to the grounds of unpatentability

explained below: 1

1 The 996 Patent issued from a patent application filed prior to enactment of the

America Invents Act (AIA). Accordingly, pre-AIA statutory framework applies.

IPR2015-01607 U.S. Patent No. 7,113,996

3

1. The Free Haven Project: Design and Deployment of an Anonymous Secure

Data Haven (May 23, 2000) (Free Haven (EX1002)), which is prior art

under 35 U.S.C. 102(a).

2. U.S. Patent No. 6,011,782 (filed on May 8, 1997; published on Jan. 4, 2000)

(DeSimone (EX1003)), which is prior art under 35 U.S.C. 102(a) and

102(e).

3. U.S. Patent No. 7,010,604 (claiming priority to Oct. 30, 1998; filed on Oct.

29, 1999; published on Mar. 7, 2006) (Munger (EX1004)), which is prior

art under 35 U.S.C. 102(e).

4. U.S. Patent No. 5,331,637 (filed on Jul. 30, 1993; published on Jul. 19, 1994)

(Francis (EX1005)), which is prior art under 35 U.S.C. 102(a), 102(b),

and 102(e).

B. Grounds for Challenge

This Petition, supported by the declaration of Justin Douglas Tygar (Tygar

Declaration or Tygar (EX1006)), requests cancellation of challenged claims 1-3

and 14-16 as unpatentable under 35 U.S.C. 102 and/or 103. See 35 U.S.C.

314(a).

IV. TECHNOLOGY BACKGROUND

The Tygar Declaration discusses in explains the technology discussed in this

Petition in greater detail, specifically the concepts of packet-switched networks

IPR2015-01607 U.S. Patent No. 7,113,996

4

(see Tygar 16-19 (EX1006)), packets (see Tygar 20 (EX1006)), relays (see

Tygar 21 (EX1006)), information security (see Tygar 22 (EX1006)), and

distributed storage (see Tygar 23 (EX1006)).

V. OVERVIEW OF THE 996 PATENT

A. Summary of the Alleged Invention

The 996 Patent recognizes that many prior art protocols existed for

transmitting data securely over networks. (996 Patent at 1:43-63 (EX1001)).

The 996 Patent also recognizes that, in transmitting data through a network, the

data is stored. (Id. at 1:64-67 & 2:1-7, 30-33). However, the 996 Patent states

that current security protocols [were] inflexible. (Id. at 1:13-15). The 996 Patent

alleges a need to improve existing security protocols by providing users with a

flexible and convenient way to securely transport and store data. (Id. at 2:15-18).

To address this purported problem, the 996 Patent describes an allegedly

novel secure transport and storage system that makes only slight modifications to

existing protocols. (Id. at 2:45-48). These modifications include modifying IP

packets of a known protocol, such as IPSec packets, to include a retrieval key, and

modifying IP relays to forward packets to a destination when a retrieval condition

has been satisfied. (Id. at 5:66-67; 6:1-13, 29-33). However, these allegedly novel

modifications were already well known in the prior art. (Tygar 25 (EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

5

The 996 Patent describes sending data over an Internet Protocol (IP)

network using Secure Transport protocol packets, which are packets of a known

secure protocol plus a retrieval key. (996 Patent at 4:66-67; 5:1-11; & Fig. 1

(EX1001); Tygar 26 (EX1006)). Figure 4 below illustrates a known IPSec packet,

and Figure 5 illustrates a Secure Transport packet, which includes the same

fields as the IPSec packet plus a retrieval key field. (996 Patent at 4:66-67; 5:1-9;

& Figs. 1-2 (EX1001); Tygar 26 (EX1006)).

(996 Patent at Fig. 4 (EX1001)). (996 Patent at Fig. 5 (EX1001)).

The 996 Patent describes modifying the IP/IPSec protocol stack in network

relays to perform secure transport. (996 Patent at 5:23-25 (EX1001)). These

modifications include adding a table of known secure relays, adding the ability to

randomly choose secure relays to which to forward packets, and adding the ability

to forward packets to a retrieval destination when a retrieval packet is received. (Id.

at 5:23-33 (EX1001)). To send a file through the Secure Transport network, a

file is broken into packets. The packets are given an IP header, encapsulated by an

IPR2015-01607 U.S. Patent No. 7,113,996

6

IPSec header, given a retrieval key, and then forwarded between relays. (996

Patent at 5:7-9, 42-56 & Figs. 4-5 (EX1001)). The relays send the packets to a

client when they receive a retrieval key (otherwise referred to as magnet,

retrieval condition, or retrieval datagram in the 996 Patent) from the client.

(Id. at 4:29-30; 5:27-33, 56-58; 6:34-37); Tygar 27-28 (EX1006)).

As the prior art demonstrates, the purported problem of improving existing

security protocols to provide a convenient way to securely transport and store data

as described in the 996 Patent was well known, and there were many well-known

solutions to that problem prior to the 996 Patent. (Tygar 29 (EX1006)).

B. Level of Ordinary Skill in the Art

A person of ordinary skill in the art (POSA) for the 996 Patent would

have a Masters Degree in electrical engineering, computer science or a related

subject, and at least three years of experience working with distributed computer

networks and network security, or the equivalent. (Tygar 30 (EX1006)).

C. Prosecution History

The 996 Patent issued from U.S. Pat. Appl. No. 09/910,416, which was filed

on July 20, 2001 (File History, Application (07/20/2001) (EX1007)), and claims

priority to July 21, 2000 (996 Patent at 1:7-10 (EX1001)). The Examiner allowed

the claims in view of the limitations forwarding all secure packets associated with

the retrieval condition to the second node if the retrieval condition has been

IPR2015-01607 U.S. Patent No. 7,113,996

7

indicated, forwarding al[l] the secure packets to another secure relay if the

retrieval condition has not been indicated, and wherein said secure packets are in

transition and not discoverable until a retrieval condition has been indicated.2 (See

File History, Allowance at 4-5 (08/19/2005) (EX1008); File History, Supplemental

Allowance at 5-6 (10/05/2005) (EX1009)). However, as described in detail below,

all of these features cited by the Examiner (and indeed the entire claim) were well

known at the time that the 996 Patent was filed. (Tygar 43-215 (EX1006)).

On July 6, 2011, Patent Owner filed a petition to accept the delayed payment

of the 3.5 year maintenance fee for the 996 Patent, and the petition was granted.

(See File History, Petition at 1 (07/06/2011) (EX1010); File History, Grant of

Petition at 1 (07/06/2011) (EX1011)). To date, Patent Owner has not submitted

payment for the 7.5 year maintenance fee for the 996 Patent, which was due on

September 26, 2014. (See 996 Patent USPTO Maint. Fees Window Dates at 1

(EX1012)). Accordingly, as of this time, the 996 Patent is expired. (See PAIR

Application Status at 1 (EX1013)). 2 Petitioner notes that not all of these limitations were included in each of the

independent claims when the application was allowed. (See File History,

Supplemental Response at 3-8 (05/02/2005) (EX1014). For example, the limitation

wherein said secure packets are in transition and not discoverable until a retrieval

condition has been indicated only appeared in dependent claim 7. (Id).

IPR2015-01607 U.S. Patent No. 7,113,996

8

VI. CLAIM CONSTRUCTION

Claim terms of a patent in inter partes review are normally given the

broadest reasonable construction in light of the specification. See 37 C.F.R.

42.100(b); see also In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1279-81

(Fed. Cir. 2015). However, as noted above in V.C, the 996 Patent has expired

due to nonpayment of maintenance fees. Claim terms of an expired patent in inter

partes review are construed in accordance with the claim construction standard set

forth in Phillips v. AWH Corp, 415 F.3d 1303 (Fed. Cir. 2005).

The following discussion proposes constructions and support for those

constructions. Any claim terms not included in the following discussion should be

given their ordinary meaning in light of the specification, as commonly understood

by those of ordinary skill in the art. The broadest reasonable interpretation of a

claim term may be the same as or broader than the construction under the Phillips

standard, but it cannot be narrower. See Facebook, Inc. v. Pramatus AV LLC, 2014

U.S. App. LEXIS 17678, *11 (Fed. Cir. 2014). The constructions proposed below

should be applied regardless of whether the terms are interpreted under the Phillips

standard or the broadest reasonable interpretation standard.

A. secure packet

The term secure packet should be interpreted to mean a unit of data to

which access by an unauthorized user or device is prevented. (Tygar 39

IPR2015-01607 U.S. Patent No. 7,113,996

9

(EX1006)). The 996 Patent does not define the term secure packet. Rather, the

996 Patent suggests many different ways in which security can be added to a

packet, including requiring authentication before providing access to the packet, or

using encryption. (See 996 Patent at 1:48-57; 2:31-33, 37-56; 3:48-61; 4:29-41;

5:42-58; 6:34-43, 46-54; 8:52-63, 65-67; & 9:1-14 (EX1001); see also Tygar 39

(EX1006)). The proposed construction is consistent with the specification and the

ordinary use of the term secure packet. (Tygar 25 (EX1006)).

B. secure relay

The term secure relay should be interpreted to mean a network device

capable of receiving a secure packet, sending the secure packet, and redirecting the

secure packet. (Tygar 40 (EX1006)). The 996 Patent does not define the term

secure relay. Rather, the 996 Patent states that secure transport can utilize a

known protocol with slight modifications to allow re-direction of data. (See 996

Patent at 2:45-56 (EX1001)). For example, the 996 Patent discloses altering a

router, so that packets with a retrieval key are forwarded to a retrieval destination

when a retrieval condition has been set. (See 996 Patent at 5:23-33 (EX1001)).

The proposed construction is consistent with the specification and the ordinary use

of the term secure relay. (Tygar 40 (EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

10

C. second node successively forwards

The term second node successively forwards should be interpreted to mean

a node that causes repeated forwarding. (Tygar 41 (EX1006)). The 996 Patent

does not define second node successively forwards. Rather, the 996 Patent

discloses generating a key that would instruct relays to send any data with a

matching key to a destination. (See 996 Patent at 4:11-16 (EX1001)). As

illustrated in the example networks of Figs. 1 and 2 of the 996 Patent, each of the

nodes (e.g., A, B, C) is directly connected to only one relay. (See 996 Patent at

Figs. 1, 2 (EX1001)). The proposed construction is consistent with the

specification and the ordinary use of the term second node successively

forwards. (Tygar 41 (EX1006)).

D. retrieval packet

The term retrieval packet should be interpreted to mean a unit of data

transmitted to cause retrieval of information. (Tygar 42 (EX1006)). The 996

Patent does not define the term retrieval packet. Rather, the 996 Patent discloses

that a file can be split into units, and that a retrieval condition, retrieval key, or

retrieval datagram, may be used to receive the units. (See 996 Patent at

Abstract; 4:29-30; & 5:30-31, 42-47 (EX1001)). The proposed construction is

consistent with the specification and the ordinary use of the term retrieval

packet. (Tygar 42 (EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

11

VII. SPECIFIC GROUNDS FOR PETITION

Pursuant to Rule 42.104(b)(4)-(5), the following sections (as confirmed in

the Tygar 43-215 (EX1006)) detail the grounds of unpatentability, the

limitations of the challenged claims of the 996 Patent, and how these claims were

therefore anticipated and/or obvious in view of the prior art.

A. Ground I: Claim 1-3 and 14-16 are anticipated by Free Haven. 1. Overview of Free Haven

Free Haven is a printed publication because it was publically available. As

discussed in the Declaration of Professor Michael Freedman, Free Haven was

publicly available on a website as of May 23, 2000. (See Freedman Decl. at 1 (Ex.

1007). Therefore, Free Haven constitutes prior art to the 996 Patent under 35

U.S.C. 102(a). Free Haven, as relied upon here in Exhibit 1002, is the document

available from the website link referenced in the Declaration of Michael Freedman.

Free Haven discloses a distributed publication system, which stores and serves

files. (Free Haven at Abstract; 55 (EX1002)). The system includes a community of

servers (as a whole referred to as a servnet), and each

server hosts data. (Id. at 55). Data moves from one

server to another. (Id.). Figure 5-1 below illustrates the

structure of a Free Haven server. (Tygar 45

(EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

12

(Left: Free Haven at Fig. 5-1, p. 56 (EX1002)).

When an author wants to publish a file, a server breaks the file into shares,

and then for each share negotiates for a server to publish that share on the servnet.

(Free Haven at 56, 57 (EX1002)). When a reader wishes to retrieve a file from the

servnet, the reader requests the file, and a server broadcasts the request to all other

servers. (Id. at 57). The servers that are holding shares for that file then deliver the

shares to the readers location. (Id.). Once the reader has enough shares, the file is

recreated. (Id. at 60); Tygar 46 (EX1006)).

2. Claim 1 is anticipated by Free Haven.

a) [a] secure transport system for transporting secure packets from a first node to a second node

Free Haven discloses a distributed storage system, which serves and stores

documents. (Free Haven at Abstract; p. 55 (EX1002)). When an author wishes to

publish a file, a publishing server breaks the file into shares (packets), and then

sends each share to be stored on a server in a community of servers connected over

the Internet, called a servnet. (Id. at 56, 57, 59 & Fig. 5-1). Thus, the publishing

server is first node. (Tygar 49 (EX1006)). The file may be encrypted before it

is broken into shares. (Free Haven at 59 (EX1002)). Shares are signed with a

public/private key pair (PK,SK). (Id. at 59, 66).

In order to retrieve the file, a client must know the PK of the file. (Id. at 60,

66). A client retrieves the file by using a server (requesting server) to broadcast

IPR2015-01607 U.S. Patent No. 7,113,996

13

the PK to all of the servers it knows about. (Id.). Each server that receives the PK

checks to see if it has any shares that contain the PK, and if it does, encrypts each

share with a PK of the client and sends it to the clients address. (Id.). Thus, the

system transports encrypted shares (secure packets) from a publishing server

(first node) to a requesting server (second node) over a secure communications

system (secure transport system). (Tygar 50 (EX1006)).

b) a first node that creates secure packets, wherein each secure packet contains identical retrieval information

Free Haven discloses that a publishing server (first node) breaks a file into

encrypted shares (secure packets), which are each signed with a PK that can be

used to retrieve the shares (wherein each secure packet contains identical retrieval

information). (Free Haven at 59, 66 (EX1002); Tygar 52 (EX1006)).

c) multiple secure relays that receive secure packets and non secure packets from multiple nodes or other secure relays

Free Haven discloses servnet servers that store shares of files. (Free Haven

at 55-57, 59-60 (EX1002)). The shares may or may not be encrypted at the

discretion of a publisher. (Free Haven at 59 (EX1002)). The shares are moved

from one server in the servnet to another every so often. (Free Haven at 55, 67-69

(EX1002)). Each server has a public key and remailer reply block to provide

secure, authenticated communication with the server. (Free Haven at 55

(EX1002)). Accordingly, the servnet servers are relays in that they move shares

IPR2015-01607 U.S. Patent No. 7,113,996

14

between themselves, and are secure in that they provide for secure

communication. (Tygar 54 (EX1006)).

The servnet servers receive encrypted shares (secure packets) from

publishers that elect to encrypt their files, and unencrypted shares (non secure

packets) from publishers that do not elect to encrypt their files. (Free Haven at 59

(EX1002); Tygar 55 (EX1006)). Moreover, the servnet servers receive shares

from both publishing servers (multiple nodes) and servnet servers (secure

relays). (Free Haven at 55-57, 59-60, 67-69 (EX1002)). Thus, Free Haven

discloses multiple servnet servers (multiple secure relays) that receive encrypted

shares (secure packets) and unencrypted shares (non secure packets) from

multiple publishing servers (nodes) or other servnet servers (other secure

relays). (Tygar 55 (EX1006)).

d) wherein said multiple secure relays are capable of identifying retrieval information in each secure packet

As noted above in VII.A.2.a, servers (multiple secure relays) receive

queries for shares that contain a particular PK, and check to determine whether

they have any shares that contain the particular PK. (Free Haven at 60 (EX1002)).

Thus, the servers (multiple secure relays) are capable of identifying PKs

(retrieval information) in each encrypted share (secure packet). (Tygar 57

(EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

15

e) wherein each of said multiple secure relays forwards secure packets to another of said multiple secure relay and forwards non-secure packets to destination relays

Free Haven discloses that servers (multiple secure relays) trade both

encrypted shares (secure packets) and unencrypted shares (non secure packets)

amongst themselves over the Internet. (Free Haven at 55, 67-69 (EX1002; Tygar

59 (EX1006)). When a PK is received, servers forward shares having the PK to the

requesting server. (Free Haven at 60-61, 66 (EX1002)). Thus, Free Haven

discloses that the servers (multiple secure relays) trade encrypted shares with

other servnet servers (forward secure packets to another of said multiple secure

relay) and forward unencrypted shares that contain the PK to the requesting server

(forwards non-secure packets to destination relays). (Tygar 59 (EX1006)).

f) end3 wherein said multiple secure relays forward secure packets to the second node when a retrieval condition has been indicated

Free Haven discloses that, upon receiving a PK (retrieval condition), each

of the servers checks to see whether it has any shares that contain the PK. (Free

Haven at 60 (EX1002); Tygar 61 (EX1006)). If it does, the server sends the

share(s) to the requesting servers address. (Free Haven at 60 (EX1002)). Thus, the

3 It appears the term and was mistakenly changed to the word end when the

996 Patent issued. (See 996 File History, Supplemental Response at 2 (EX1014)).

Accordingly, the term is treated as being and herein.

IPR2015-01607 U.S. Patent No. 7,113,996

16

servnet servers (multiple secure relays) forward shares of a given PK, including

encrypted shares (secure packets), to the requesting server (second node) when

the requesting server has requested shares having the PK (when a retrieval

condition has been indicated). (Tygar 61 (EX1006).)

g) wherein each of said multiple secure relays forwards secure packets to another of said multiple secure relays when the retrieval condition has not been indicated

Free Haven discloses that servers (secure relays) move shares from server

to server in a process called trading. (Free Haven at 55, 67-69 (EX1002)). Thus, in

situations where a client has not requested the shares, they would still be traded.

(Tygar 63 (EX1006)). Therefore, each of the servers (multiple secure relays)

trades shares, including encrypted shares, to other servers (forwards secure

packets to another of multiple secure relays when the retrieval condition has not

been indicated). (Tygar 63 (EX1006)).

h) a second node that creates a retrieval condition related to said retrieval information in said multiple secure packets and receives the secure packets

Free Haven discloses that a requesting server (second node) broadcasts a

PK of a file requested by a client to all of the servnet servers it knows about. (Free

Haven at 60 (EX1002); Tygar Decl. 65 (EX1006)). Each server that receives the

PK checks to see if it has any shares that contain the PK. (Free Haven at 60

(EX1002)). Thus, the broadcast PK is a retrieval condition that is related to the

PK (retrieval information) with which certain shares, such as encrypted shares

IPR2015-01607 U.S. Patent No. 7,113,996

17

(secure packets), were signed. (Tygar 65 (EX1006)). Because the requesting

server (second node) broadcasts the PK, it creates a retrieval condition. (Id.

65). The requesting server (second node) receives the shares, including the

encrypted shares (secure packets), which include the PK. (Free Haven at 60

(EX1002); Tygar 65 (EX1006)).


a) wherein the second node creates a retrieval condition by generating a unique identifying flag that identifies said multiple secure packets that contain the same retrieval information


PK (creates a retrieval condition by generating a unique identifying flag) of a

requested file. (Free Haven at 60 (EX1002); Tygar Decl. 68 (EX1006)). Each

server receiving the PK checks whether it has any shares, including encrypted

shares (secure packets), that contain the requested PK. (Free Haven at 60

(EX1002)). Thus, the broadcast PK is used to identify shares that contain the PK,

and is a unique identifying flag that identifies said multiple secure packets that

contain the same retrieval information. (Tygar 68 (EX1006)).

b) wherein said second node transmits said identifying flag to said multiple secure relays to initiate transmission of said multiple secure packets to said second node

Free Haven discloses that the requesting server (second node) broadcasts a

PK (identifying flag) to all of the servnet servers (multiple secure relays) it

knows about. (Free Haven at 60 (EX1002); Tygar 70 (EX1006)). Each server

IPR2015-01607 U.S. Patent No. 7,113,996

18

that receives the PK sends any shares, including encrypted shares (secure

packets), it has that contain the PK. (Free Haven at 60 (EX1002)). Thus, the PK is

broadcasted to initiate transmission of said multiple secure packets to said second

node. (Tygar 70 (EX1006)).

c) wherein said first or second nodes may create said retrieval condition

This limitation recites that the first or second nodes may create said retrieval

condition (emphasis added). Thus, the limitation does not require that both the

first and the second nodes be capable of creating the retrieval condition. Free

Haven discloses that an author running her own server could store shares of a file

into the servnet, and then retrieve the shares from the servnet (Free Haven at 59,

60; see also id. at 50 (EX1002)). Thus, the publishing server (first node) or a

separate requesting server (second node) may broadcast the PK for the file

(create said retrieval condition). (Tygar 72 (EX1006)).


a) wherein the second node successively forwards multiple identical retrieval packets to said multiple secure relays, wherein each retrieval packet indicates the retrieval condition for secure packets


message (request, PKfile, PKclient, reply block) to each servnet server it knows

about. (Free Haven at 57, 60, 79, 83 (EX1002)). The broadcast message can be

sent out in bulk, and can be sent perhaps once an hour. (Free Haven at 60

(EX1002)). Thus, the requesting node (second node) sends the messages

IPR2015-01607 U.S. Patent No. 7,113,996

19

(successively forwards . . . retrieval packets) to the servnet nodes (multiple

secure relays). (Tygar 75 (EX1006)). Since each of the messages (retrieval

packets) includes (request, PKfile, PKclient, reply block) (see Free Haven at 60

(EX1002)), the messages are identical, and are multiple identical retrieval

packets. (Tygar 75 (EX1006)).

Each of the messages includes the PK that was used to sign the file. (Free

Haven at 60 (EX1002)). Each server receiving the message will check whether it

has shares that contain the PK, and if it does, will send the share(s) to the

requesting server. (Free Haven at 60 (EX1002)). Thus, the PK of the file is a

retrieval condition, and each of the messages indicates the PK of the file

(indicates the retrieval condition for secure packets). (Tygar 76 (EX1006)).

b) wherein each said retrieval packet contains a flag that instructs said multiple secure relays to identify secure packets that contain the same retrieval information

Free Haven discloses that each of the broadcast messages (retrieval

packets) sent to the servers includes the PK (flag) of the file. (Free Haven at 60

(EX1002); Tygar 78 (EX1006)). Each servnet server receiving the message

checks to see if it has any shares that contain the PK, and if it does, sends the

share(s) to the requesting server. (Free Haven at 60 (EX1002)). Thus, the PK

(flag) instructs the servnet servers (multiple secure relays) to identify shares,

IPR2015-01607 U.S. Patent No. 7,113,996

20

including encrypted shares (secure packets), containing the PK (that contain the

same retrieval information). (Tygar 78 (EX1006)).


a) [a] method for maintaining a secure distributed storage system by initiating a transmission of a message from a first node to a second node in a secure manner, wherein the second node may be the first node, comprising the steps, executed in a data processing system

This limitation recites that the second node may be the first node (emphasis

added). The limitation does not require that the second node be the first node.

Free Haven discloses a distributed storage system, which serves and stores

documents. (Free Haven at Abstract, 55 (EX1002)). When an author wishes to

publish a file, the author stores the file on a publishing server, which breaks the file

into shares (packets), and then sends each share to be stored in a community of

servers connected over the Internet, called a servnet. (Free Haven at 56, 57, 59, &

Fig. 5-1 (EX1002); Tygar 82 (EX1006)). Thus, the publishing server is a first

node. (Tygar 82 (EX1006)). The file may be encrypted before it is broken into

shares. (Free Haven at 59 (EX1002)). Shares are signed with a public/private key

pair (PK,SK). (Free Haven at 59, 66 (EX1002)).

In order to retrieve a file, a client must know the PK of the file. (Free Haven

at 60, 66 (EX1002)). A client retrieves the file by using a server to broadcast the

PK to all of the servnet servers it knows about. (Free Haven at 60 (EX1002)). Each

server that receives the PK checks to see if it has any shares that contain the PK,

IPR2015-01607 U.S. Patent No. 7,113,996

21

and if it does, encrypts each share with a PK of the client and sends them to the

clients address. (Free Haven at 60 (EX1002)). Thus, Free Haven discloses that a

distributed storage system (data processing system), where a publishing system

(first node) stores a file in the system (initiat[es] a transmission of a message),

and a requesting server (second node) retrieves the file from the system, over a

secure communications system (in a secure manner). (Tygar 83 (EX1006)).

Free Haven also discloses that an individual can use their own server to

publish the file into the distributed storage system, and can be the same person that

retrieves the file from the distributed storage system. (Free Haven at 60 (EX1002)).

Thus, the publishing server may be the requesting server (the second node may be

the first node). (Tygar 84 (EX1006)).

b) creating a set of secure packets associated with the message, wherein each secure packet contains an identical first retrieval key, wherein the first retrieval key is created by the first node

Free Haven discloses that a publishing server (first node) breaks a file

(message) into encrypted shares (a set of secure packets associated with the

message), which are each signed with a public key PK (wherein each secure

packet contains an identical first retrieval key, wherein the first retrieval key is

created by the first node). (Free Haven at 60; Tygar 86 (EX1006)).

c) forwarding the set of secure packets to multiple secure relays from the first node

IPR2015-01607 U.S. Patent No. 7,113,996

22

Free Haven discloses servers that store shares of files. (Free Haven at 55-57,

59-60 (EX1002)). The shares may be encrypted at the discretion of a publisher.

(Free Haven at 59 (EX1002)). The shares are created by a publishing server, which

then sends them to be stored on servers. (Free Haven at 55, 59-60 (EX1002)). The

shares are then moved from one server in the servnet to another. (Free Haven at 55,

67-69 (EX1002)). Each server has a public key and remailer reply block address to

provide secure, authenticated communication with the server. (Free Haven at 55

(EX1002)). Thus, servnet servers are secure relays, as they provide secure

communication and move shares between themselves. (Tygar 88 (EX1006)).

The servnet servers receive encrypted shares (secure packets) from

publishers electing to encrypt their files. (Free Haven at 59 (EX1002); Tygar 89

(EX1006)). Moreover, the servnet servers receive shares from a publishing server

(a first node). (Free Haven at 55-57, 59-60 (EX1002); Tygar 89 (EX1006)).

Thus, Free Haven discloses a publishing server (first node) that sends shares,

including encrypted shares (set of secure packets), to servnet servers (multiple

secure relays). (Tygar 89 (EX1006)).

d) forwarding the set of secure packets among secure relays so long as a second retrieval key associated with the first retrieval key is not received in the same multiple secure relays

Free Haven discloses that a publishing server breaks a file into encrypted

shares (set of secure packets), sends the shares to be stored on servers (secure

IPR2015-01607 U.S. Patent No. 7,113,996

23

relays), and the servers then move the shares from server to server every so often

in a process called trading. (Free Haven at 55, 59-60, 67-69 (EX1002); Tygar

91 (EX1006)). Free Haven also discloses that the publishing server signs each of

the shares with a PK (first retrieval key), and that requesting servers receive the

shares by broadcasting the PK (second retrieval key) to the servnet servers. (Free

Haven at 59, 60 (EX1002)). Thus, in situations where a client has not requested the

shares, and thus has not sent the PK (second retrieval key associated ) of the

requested file, they would still be traded amongst servnet servers. (Tygar 91

(EX1006)). Therefore, each of the servnet servers forward[s] the set of secure

packets among secure relays so long as a second retrieval key associated with the

first retrieval key is not received in the same multiple secure relays. (Id. 91).

e) wherein said second retrieval key is created by the first or second node

This limitation recites that the second node retrieval key is created by the

first node or second node (emphasis added). As such, this limitation does not

require that the second retrieval key be created by both the first node and the

second node.


PK of a file requested by a client to all of the servers it knows about. (Free Haven

at 60 (EX1002); Tygar 93 (EX1006)). Each server that receives the PK will then

check to see whether it has any shares that contain the PK. (Free Haven at 60

IPR2015-01607 U.S. Patent No. 7,113,996

24

(EX1002)). Thus, the PK is a second retrieval key that is created by the

requesting server (second node). (Tygar 93 (EX1006)). Free Haven also

discloses that an author can use his or her own server to publish the file into the

servnet, and can be the same person that retrieves the file. (Free Haven at 60

(EX1002)). Thus, the broadcast PK (second retrieval key) can also be created by

the same server (first node) that published the file. (Tygar 94 (EX1006)).

f) forwarding the set of secure packets to the second node once the second retrieval key is received in the said multiple secure relays

Free Haven discloses that each server, upon receiving a PK (second

retrieval key), checks to see if it has shares that contain the PK. (Free Haven at 60

(EX1002)). If it does, it sends the share(s) to the requesting servers address. (Id. at

60.) Thus, the servers (multiple secure relays) forward shares of a given PK,

including encrypted shares (secure packets), to the requesting server (second

node) when the requesting server requests shares having the PK (once the second

retrieval key is received in said multiple secure relays). (Tygar 96 (EX1006)).


a) creating a second retrieval key in a second node


PK (second retrieval key) of a file requested by a client to all of the servnet

servers it knows about. (Free Haven at 60 (EX1002); Tygar 99 (EX1006)). Thus,

IPR2015-01607 U.S. Patent No. 7,113,996

25

Free Haven discloses that the requesting server (second node) creates the PK in

the broadcast message (creat[es] a second retrieval key). (Id. 99 (EX1006)).

b) wherein said second retrieval key is associated with destination information for the set of secure packets and information for identification of said first retrieval key

Free Haven discloses that a requesting server broadcasts a message

including a PK (second retrieval key) of a requested file to each of the servnet

servers of which it is aware. (Free Haven at 60 (EX1002); Tygar 101 (EX1006)).

The message includes (request, PKfile, PKclient, reply block). (Free Haven at 60

(EX1002)). Each of the servnet servers that receives the message then checks to

see whether it has any shares that contain the PK (first retrieval key). (Id. at 60);

Tygar 101 (EX1006)). If it does, it forwards the share(s) to the requesting server.

(Free Haven at 60 (EX1002)). That is, Free Haven discloses that each servnet

server compares the broadcast PK with the PKs of shares stored at the servnet

server to determine whether they match. (Id. at 79). Thus, the broadcast PK

(second retrieval key) is associated with information (a public key) for

identifying the PK (first retrieval key) of shares of a file stored by servnet

servers. (Tygar 101 (EX1006)).

Free Haven also discloses that the broadcast message includes both the PK

of the requested file, and a reply block address to use to address the retrieved

shares to the requesting server. (Free Haven at 55, 60 (EX1002)). The shares are

IPR2015-01607 U.S. Patent No. 7,113,996

26

then sent to the requesting server based on the reply block address. (Id.). Thus,

Free Haven discloses that the PK (second retrieval key) of the broadcast

message is associated with the reply block address (destination information) for

the encrypted shares (set of secure packets). (Tygar 102 (EX1006)).

c) transmitting said second retrieval key from the second node to said multiple secure relays

Free Haven discloses that a requesting server (second node) broadcasts

(transmit[s]) a PK (second retrieval key) of a file requested by a client to all of

the servnet servers (secure relays) it knows about. (Free Haven at 60 (EX1002);

Tygar 104 (EX1006).)


a) at the second node, resequencing the set of secure packets to recreate the message based on resequencing information associated with the set of secure packets


PK of a requested file to all of the servnet servers of which it is aware. (Free

Haven at 60 (EX1002); Tygar 107 (EX1006)). Each servnet server that receives

the PK then checks to see whether it has any shares that contain the PK. (Free

Haven at 60 (EX1002)). If it does, it sends the shares to the requesting server. (Id.).

Free Haven discloses that once enough shares arrive at the requesting server,

the requesting server recreates the file. (Free Haven at 60; see also id. at 56-57, 79

(EX1002)). Free Haven also discloses that each share contains a share number for

IPR2015-01607 U.S. Patent No. 7,113,996

27

recreating the file. (Id. at 66 (EX1002); Tygar 108 (EX1006)). Thus, the

requesting server (second node) recreates the file by combining the encrypted

shares (resequencing the set of secure packets to recreate the message) based on

share numbers (based on resequencing information associated with the set of

secure packets). (Tygar 108 (EX1006)).

B. Ground II: Claims 1 is obvious in view of DeSimone and Munger. 1. Overview of DeSimone

As depicted in Figure 1 below, DeSimone discloses a multicast capable

Internet Protocol (IP) data network (e.g., network 102 of Fig. 1). (DeSimone at

3:56-59 (EX1003)).

(DeSimone at Fig. 1 (EX1003)).

Client terminals (e.g., clients 101-1 101-5

of Fig. 1) may communicate with one

another in a multimedia conference by

transmitting and receiving multicast packets.

(DeSimone at Abstract & 3:56-59 (EX1003)). The multicast packets are relayed

through the network using multicast routers (e.g., MRs 103-105 of Fig. 1).

(DeSimone at 3:64-67 & 4:1-8 (EX1003); Tygar 110-111 (EX1006)).

A client joins a conference by receiving a list of ongoing conferences from a

Directory Server (e.g., Directory Server 106), selecting the conference the client

IPR2015-01607 U.S. Patent No. 7,113,996

28

wishes to join, and authenticating to the conference with the Directory Server.

(DeSimone at 5:51-67; 6:1-8; & Fig. 3 (EX1003)). Once authenticated, the

Directory Server provides the client with a multicast socket (e.g., a unique

multicast IP address and port number) to transmit on for each media type (e.g.,

audio or video transmission), and a list of sockets for each media type to receive on

from other clients participating in the conference. (DeSimone at 6:4-8 & Fig. 3

(EX1003)). The client selects sockets for each of the clients from which it wishes

to receive. (DeSimone at 6:8-11 (EX1003)). The selected sockets are then added to

the clients Multicast Receive Address List (MRAL), and the multicast routers are

informed of the socket from which the client wishes to receive packets. (DeSimone

at 4:35-54 (EX1003); Tygar 112 (EX1006)).

When participating in a conference, each multicast packet of a media type

transmitted by a client includes that clients assigned socket. (DeSimone at 3:27-36

(EX1003)). These multicast packets are then only routed to clients requesting the

packets. (DeSimone at Abstract; 3:12-21, 39-40; 4:43-67; & 5:1-11 (EX1003);

Tygar 113 (EX1006)).

2. Claim 1 is obvious over DeSimone in view of Munger. a) [a] secure transport system for transporting secure packets from a first node to a second node

DeSimone discloses a multicast network over which clients can

communicate in a multimedia conference. (DeSimone at Abstract (EX1003)). A

IPR2015-01607 U.S. Patent No. 7,113,996

29

client communicating, and thereby transmitting packets, is a first node. (Tygar

116 (EX1006)). A client listening or viewing the communications, and thereby

receiving packets, is a second node. (Tygar 116 (EX1006)).

Before participating in a conference, and receiving multicast packets from

other conference participants, a user must authenticate. (DeSimone at 5:57-67; 6:1-

8; & Fig. 3 (EX1003)). That is, a client does not receive a list of other participants,

and the sockets on which they transmit, until the clients user has authenticated to

the Directory Server with a User ID and password. (DeSimone at 5:57-67; 6:1-8; &

Fig. 3 (EX1003)). If the user is not authenticated, the user is precluded from

joining the conference. (DeSimone at 6:2-4 & Fig. 3 (EX1003)). Thus, the

conferences of DeSimone are secure, and the multicast conference packets are

secure packets transported over a secure transport system from a transmitting

conference client (first node) to a receiving conference client (second node).

(Tygar 117 (EX1006)).

To the extent a narrow interpretation of the terms secure transport system

and/or secure packets is taken, and to the extent one could argue that DeSimone

does not disclose these terms, these terms were well-known at the time the 996

Patent was filed (see VII.B.2.i below). (Tygar 118 (EX1006)).

b) a first node that creates secure packets, wherein each secure packet contains identical retrieval information

IPR2015-01607 U.S. Patent No. 7,113,996

30

DeSimone discloses multicast routers that relay conference multicast packets

(secure packets) between clients in a multicast capable IP network. (DeSimone at

3:12-21, 39-40, 64-67; 4:1-5, 45-60; 5:8-11 (EX1003); Tygar 120 (EX1006)).

Each conference participants client terminal is assigned a unique socket (port

number and multicast address) on which to transmit each media type, and each

packet transmitted by the client thereafter includes the assigned socket in its

header. (DeSimone at 3:27-36 (EX1003)). Other clients then receive this clients

transmissions by selecting the clients assigned socket from a list. (DeSimone at

6:8-15; see also id. at Abstract; 3:5-21, 34-40; 4:26-67; 5:1-11; 6:4-8 (EX1003)).

Thus, the transmitting conference terminal (first node) creates multicast

conference packets (secure packets) that each contains the assigned socket

(identical retrieval information). (Tygar 120 (EX1006)).

To the extent a narrow interpretation of the term secure packets is taken,

and to the extent one could argue that DeSimone does not disclose this term, this

term was well-known at the time the 996 Patent was filed (see VII.B.2.i below).

(Tygar 121 (EX1006)).

c) multiple secure relays that receive secure packets and non secure packets from multiple nodes or other secure relays

DeSimone discloses multicast routers that relay conference multicast packets

(secure packets) between clients in a multicast capable IP network. (DeSimone at

3:12-21, 39-40, 64-67; 4:1-5, 45-60; 5:8-11 (EX1003); Tygar 123 (EX1006)). If

IPR2015-01607 U.S. Patent No. 7,113,996

31

a user has authenticated to a conference and selects a conference participants

socket, the users client informs the multicast routers that the client wishes to

receive packets including the socket. (DeSimone at 4:43-60 (EX1003)). Users who

have not authenticated with the Directory Server for a conference are precluded

from joining the conference and receiving the conference packets. (DeSimone at

6:2-4 (EX1003); Tygar 123 (EX1006)). Accordingly, the multicast routers are

secure relays. (Tygar 123 (EX1006)).

DeSimone also discloses that potential conference participants contact the

Directory Server by sending a packetized request. (DeSimone at 5:51-57

(EX1003)). This occurs before the potential conference participant authenticates

with the Directory Server. (DeSimone at 5:57-67; 6:1-11; & Fig. 3 (EX1003)).

Similarly, a conference originator sends a packetized request to the Directory

Server to create a conference before authenticating with the Directory Server.

(DeSimone at 5:12-33 (EX1003)). These packetized requests sent from potential

conferees and originators are not conference packets and are thus non secure

packets. (Tygar 124 (EX1006)).

In order to route conference packets between certain clients (e.g., clients

101-1 101-5), and to route non conference packets between clients and the

Directory Server, the packets travel through multiple multicast routers. (DeSimone

at Fig. 1 (EX1003); Tygar 125 (EX1006)). Thus, the multicast routers are

IPR2015-01607 U.S. Patent No. 7,113,996

32

multiple secure relays that receive secure packets and non secure packets from

multiple nodes or other secure relays. (Tygar 125 (EX1006)).

To the extent a narrow interpretation of the terms secure relays, secure

packets, and/or non secure packets is taken, and to the extent one could argue

that DeSimone does not disclose these terms, these terms were well-known at the

time the 996 Patent was filed (see VII.B.2.i below). (Tygar 126 (EX1006)).

d) wherein said multiple secure relays are capable of identifying retrieval information in each secure packet

DeSimone discloses that multicast routers only forward multicast packets

with a specific socket to sub-networks of clients that have selected the socket.

(DeSimone at 4:32-60; see also id. at Abstract; 3:5-21, 27-40; 4:61-67; 5:1-11

(EX1003)). Thus, the multicast routers (secure relays) are capable of identifying

a socket (retrieval information) in each multicast packet (secure packet).

(Tygar 128 (EX1006)).

To the extent a narrow interpretation of the terms secure relays and/or

secure packets was taken, and to the extent one could argue that DeSimone does

not disclose these terms, these terms were well-known at the time the 996 Patent

was filed (see VII.B.2.i below). (Tygar 129 (EX1006)).

e) wherein each of said multiple secure relays forwards secure packets to another of said multiple secure relay and forwards non-secure packets to destination relays

IPR2015-01607 U.S. Patent No. 7,113,996

33

As noted above in VII.B.2.c., DeSimone discloses multicast conference

packets (secure packets) and packetized requests (non secure packets) from

unauthenticated clients. (Tygar 131 (EX1006)). Multicast conference packets are

routed through multicast routers to each of the clients that has elected to receive

them. (DeSimone at 3:64-67; see also id. at Abstract 3:12-21, 34-40; 4:45-67; 5:1-

11, 43-46 (EX1006)). Thus, as shown in Figure 1 of DeSimone, if client 101-1

were transmitting multicast packets, and clients 101-2, 101-3, and 101-5 had

elected to receive them, the packets would have to be sent through multicast

routers 103, 104, and 105 for the clients to receive the packets. (DeSimone at Fig. 1

(EX1003); Tygar 131 (EX1006)). Accordingly, each of the multicast routers

(secure relays) forwards multicast packets (secure packets) to another of the

multicast routers (another of said secure relay). (Tygar 131 (EX1006)).

By contrast, the Directory Server does not need to operate in a multicast

fashion, and can be connected to the network through a router which is not

multicast capable. (DeSimone at 4:5-8 (EX1003)). Thus, packetized requests to the

Directory Server, and responses from the Directory Server, are not multicast

packets. (Id. at 4:5-8; 5:12-67; 6:1-8; Figs. 2-3); Tygar 132 (EX1006)). Instead,

these requests are routed directly to the Directory Server, and the Directory

Servers responses are routed directly to the client with which it is communicating.

(Tygar 132 (EX1006)). Thus, the router (e.g., R of Fig. 1) connected to the

IPR2015-01607 U.S. Patent No. 7,113,996

34

Directory Server, and the multicast router connected to the client with which it is

communicating, are destination relays. (Tygar 132 (EX1006)). As illustrated in

Figure 1, multicast routers disposed between these routers may relay messages

through the network. (Id. at 132). These multicast routers are secure relays that

forward non-secure packets to destination relays. (Id. at. 132).

To the extent a narrow interpretation of the terms secure relays, secure

packets, non-secure packets, and/or destination relays is taken, and to the

extent one could argue that DeSimone does not disclose these terms, these terms

were well-known at the time the 996 Patent was filed (see VII.B.2.i below).

(Tygar 133 (EX1006)).

f) end4 wherein said multiple secure relays forward secure packets to the second node when a retrieval condition has been indicated

DeSimone discloses that multicast routers (secure relays) forward

multicast conference packets (secure packets) to a client (second node) when

the client has elected to receive the packets (when a retrieval condition has been

indicated). (DeSimone at Abstract; 3:5-21, 27-40; 4:35-67; 5:1-11; 6:4-15

(EX1003); Tygar 135 (EX1006)).

4 It appears the term and was mistakenly changed to the word end when the

996 Patent issued. (See File History, Suppl. Response at 2 (EX1014)).

Accordingly, the term is treated as being and herein.

IPR2015-01607 U.S. Patent No. 7,113,996

35


secure packets is taken, and to the extent one could argue that DeSimone does



g) wherein each of said multiple secure relays forwards secure packets to another of said multiple secure relays when the retrieval condition has not been indicated

DeSimone discloses that multicast conference packets are routed through

multicast routers in the network to each of the clients that has elected to receive the

packets. (DeSimone at 3:64-67; see also id. at Abstract; 3:12-21, 34-40; 4:43-67;

5:1-11 (EX1006)). Thus, as shown in Figure 1, if client 101-1 were transmitting

multicast conference packets, and client 101-5 had elected to receive those packets,

the packets would be routed through multicast routers 103 and 105. (DeSimone at

Fig. 1; Tygar 138 (EX1006)).

If in the above example clients 101-3 and 101-4 had not elected to receive

the packets, the packets would not be routed through multicast router 104.

(DeSimone at 4:43-67; 5:1-11; see also id. at Abstract; 3:12-21, 34-40 (EX1006);

Tygar 139 (EX1006)). This example illustrates that, with the network

configuration disclosed by DeSimone, each of the multicast routers (secure

relays) is configured to forward the multicast conference packets (secure

packets) to another multicast router (another of said multiple secure relays) to

IPR2015-01607 U.S. Patent No. 7,113,996

36

service requesting clients, even when a client on another sub-network has not

elected to receive the packets (when the retrieval condition has not been

indicated). (Id. 139).


secure packets is taken, then to the extent one could argue that DeSimone does



h) a second node that creates a retrieval condition related to said retrieval information in said multiple secure packets and receives the secure packets

DeSimone discloses that a client only receives multicast conference packets

of other clients from which the client elects to receive. (DeSimone at Abstract, 3:5-

21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003)). The client makes this

election by selecting a socket of the other client whose packets it wishes to receive.

(Id. at Abstract, 3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15). This socket is

then added to the electing clients Multicast Routing Address List (MRAL), and

the multicast routers are informed of the socket elected for this client. (Id. at 4:35-

67; 5:1-11; & 6:4-15); Tygar 142 (EX1006)). Thus, DeSimone discloses an

electing client (second node) that selects a socket (creates a retrieval condition

related to said retrieval information in said multiple secure packets) and then

receives the multicast packets including the socket (receives the secure packets).

(Tygar 142 (EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

37

To the extent a narrow interpretation of the term secure packets was taken,

and to the extent one could argue that DeSimone does not disclose this element,

this element was well-known at the time the 996 Patent was filed (see VII.B.2.i

below). (Tygar 143 (EX1006)).

i) secure transport system, secure packet, secure relay, non secure packet, and/or secure distributed storage system

As described in VII.B.2a-h above, DeSimone discloses all of the elements

of claim 1. However, if a narrow interpretation of the terms secure and/or non

secure is taken, and to the extent one could argue that DeSimone does not disclose

elements containing these terms, such as a secure transport system, a secure

packet, a secure relay, a non

secure packet, and/or a secure

distributed storage system, those

elements were well known at the time

the 996 Patent was filed. (Tygar 144

(EX1006)). For example, Munger

discloses a secure system (secure

transport system or secure

distributed storage system) for communicating over a public network and that can

be used for multicast communications. (Munger at 2:64-67; 3:1; & 24:32-34

IPR2015-01607 U.S. Patent No. 7,113,996

38

(EX1004); Tygar 145 (EX1006)). Figure 2 (above) illustrates an example of the

secure system. (Munger at 5:66-67 (EX1004); Tygar 145 (EX1006)).

(Munger at Fig. 2 (EX1004)).

As illustrated in Figure 2, the network of Munger includes regular IP routers

(e.g., IP routers 128-132) and special IP routers, called Tunneled Agile Routing

Protocol (TARP) routers (e.g., TARP routers 122-127) (secure relays). (Munger

at 2:64-67; 6:59-64; & Fig. 2 (EX1004); Tygar 146 (EX1006)). Munger discloses

encrypting packets (secure packets) transmitted between TARP routers. (Munger

at 2:1-67; 3:1-6 (EX1004); Tygar 146 (EX1006)).

TARP packets look like normal IP packets, and TARP routers use normal IP

protocol to send messages. (Munger at 6:59-67; 7:1 (EX1004)). However, TARP

packets are encrypted, and their true destinations are concealed except to TARP

routers and servers. (Id. at 2:67; 3:1-6). That is, while a normal IP packet (non

secure packet) has a header indicating a final destination for the packet, TARP

packets (secure packets) have IP headers that point to a next-hop in a series of

TARP router hops until reaching the final destination. (Munger at 3:9-16; 6:65-67;

7:1-5 (EX1004); Tygar 147 (EX1006)). As illustrated in Figure 2 above, because

they look the same, regular IP routers and TARP routers can relay both regular IP

packets and TARP packets. (Munger at Fig. 2; see also id. at 2:67; 3:1-16; 4:12-14,

IPR2015-01607 U.S. Patent No. 7,113,996

39

56-67; 6:59-67; 7:1-10; 8:64-65; & 10:5-7, 19-27, 46-57 (EX1004); Tygar 147

(EX1006)).

In the system of Munger, messages are broken into multiple pieces, and

encrypted into TARP packets. (Munger at 3:42-44, 56-61, 66-67; 4:1-22

(EX1004)). Each TARP packet is then sent through a minimum number of hops.

(Munger at 3:29-31 (EX1004)). The hops may be chosen at random, and each

packet may take an independent route to reach its destination. (Munger at 3:29-42

(EX1004); Tygar 148 (EX1006)).

In sum, Munger discloses a secure communications system (secure transport

system or secure distributed storage system) that sends TARP packets (secure

packets) and regular IP packets (non-secure packets) through TARP routers

(secure relays) and regular IP routers. (Tygar 149 (EX1006)). TARP packets

have hidden destination addresses and are forwarded through TARP routers a

certain number of times (forward[ed] . . . to another of said multiple secure

relay), while regular IP packets (non-secure packets) have the destination

addresses in their header and routed directly to their destination (forward[ed] . . .

to destination relays). (Id. 149).

To a POSA at the time the 996 Patent was filed, it would have been obvious

to modify the multicast capable Internet network of DeSimone to encrypt the

multicast conference packets, and to transmit the packets through secure routers

IPR2015-01607 U.S. Patent No. 7,113,996

40

that are capable of handling both encrypted packets and non-encrypted packets,

such as taught by Munger. (Tygar 150 (EX1006)). A POSA would have been

motivated to use Mungers encryption and TARP routing techniques to encrypt and

route multicast IP packets in the multicast IP network of DeSimone, so as to add

greater security to private conference transmissions and greater anonymity to

conference participants. (Munger at 1:13-15, 21-23 & 7:5-10 (EX1004); Tygar

150 (EX1006)). Further, use of Mungers encrypted packets and TARP routers

would have been a combination of old elements in which each element would

perform as expected to yield the predictable results of adding increased security

and anonymity to network communications. (Id. 150).

C. Claims 2, 3, and 14-16 are Obvious in view of DeSimone, Munger, and Francis

1. Overview of DeSimone

An overview of DeSimone is provided in VII.B.1.

2. Claim 2 is obvious in view of DeSimone, Munger, and Francis

a) wherein the second node creates a retrieval condition by generating a unique identifying flag that identifies said multiple secure packets that contain the same retrieval information

DeSimone discloses that a client only receives multicast conference packets

of other clients from which the client elects to receive. (DeSimone at Abstract, 3:5-

21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003)). The client makes this

election by selecting a socket of another client. (Id. at Abstract, 3:5-21, 27-40, 64-

IPR2015-01607 U.S. Patent No. 7,113,996

41

67; 4:28-67; 5:1-11; & 6:4-15). This socket is then added to the electing clients

MRAL, and the electing client informs the multicast routers of the election by

positively responding to a query from a multicast router. (Id. at 4:35-67; 5:1-11; &

6:4015); Tygar 154 (EX1006)). Thus, DeSimone discloses an electing client

(second node) that selects a socket to receive multicast packets including the

socket (creates a retrieval condition by generating a unique identifying flag that

identifies said multiple secure packets that contain the same retrieval information).

(Id. 154).



term was well-known at the time the 996 Patent was filed (see VII.B.2.i above)

(Tygar 155 (EX1006)).

b) wherein said second node transmits said identifying flag to said multiple secure relays to initiate transmission of said multiple secure packets to said second node

DeSimone discloses that when a client elects a socket of another client whose

packets it wishes to receive, the socket is added to the electing clients MRAL, and

the electing client informs the multicast routers of the elected socket by positively

responding to a query from a multicast router. (DeSimone at Abstract, 3:5-21, 27-

40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003); Tygar 157 (EX1006)). Referring

to Figure 1, DeSimone provides an example where the users at clients 101-3, 101-

IPR2015-01607 U.S. Patent No. 7,113,996

42

4, and 101-5 elect to not receive video signals from clients 101-1 and 101-2.

(DeSimone at 5:4-6 (EX1003)). Multicast video packets transmitted by clients 101-

1 and 101-2 are thus not routed by multicast router 103, and remain only within the

sub-network common to clients 101-1 and 101-2. (Id. at 5:8-11); Tygar 157

(EX1006)).

A POSA would recognize that, if client 101-5 later elects to receive video

signals from clients 101-1 or 101-2, the requested socket would have to be

conveyed through multicast router 105 to multicast router 103, so that multicast

router 103 can route the packets through multicast router 105 to client 101-5.

(DeSimone at 4:35-67; 5:1-11; Fig. 1; see also id. at Abstract, 3:5-21, 27-40, 64-

67; 4:1-5 (EX1003); Tygar 158 (EX1006)). Thus, a POSA would recognize that

DeSimone discloses that the electing node (second node) transmits the requested

socket (identifying flag) to multiple multicast routers (multiple secure relays)

to receive multicast packets including the socket (to initiate transmission of said

multiple secure packets to said second node). (Tygar 158 (EX1006)).

However, to the extent it could be argued that DeSimone does not disclose

that the requested socket is conveyed through multiple multicast routers, such a

feature was well-known at the time the 996 Patent was filed. (Id. 159). For

example, Francis discloses a system and method for transmitting multicast packets

to members of a multicast group. (Francis at Abstract (EX1005)). Each of the

IPR2015-01607 U.S. Patent No. 7,113,996

43

multicast packets transmitted to a multicast group includes a multicast address of a

core node. (Id. at 6:25-30). If a node wishes to join the multicast group, it transmits

a control packet including a join request message and the multicast address

(identifying flag) of the core node, and this packet is transmitted via

intermediary nodes (to said multiple secure relays) until reaching a node that is

part of the multicast tree. (Id. at 6:55-65); Tygar 159 (EX1006)).

To a POSA at the time the 996 Patent was filed, it would have been obvious

to modify the multicast Internet network of DeSimone so that, when a client wishes

to join a multicast group, rather than having a multicast router query the client, the

client sends a packet including the requested socket through intermediary multicast

routers until the packet reaches a multicast router that is part of the multicast tree,

such as that taught by Francis. (Tygar 160 (EX1006)). A POSA would have been

motivated to use Francis techniques for joining a multicast tree, to reduce the

amount of resources required to manage multicast trees. (Id. 160); see also

Francis at 5:13-28 (EX1005)). Further, use of Francis technique for joining a

multicast tree would have been a combination of old elements in which each

element performed as expected to yield the predictable results of reducing the

amount of information that needs to be stored in multicast routers in a network.

(Tygar 160 (EX1006)).

IPR2015-01607 U.S. Patent No. 7,113,996

44




above) (Tygar 161 (EX1006)).

c) wherein said first or second nodes may create said retrieval condition

This limitation recites that the first or second nodes may create said retrieval

condition (emphasis added). Thus, this limitation does not require that both the

first and the second nodes be capable of creating the retrieval condition.

As noted above in VII.C.2.a, DeSimone discloses that a client (second

node) wishing to receive multicast packets of another client selects the socket

(creates the retrieval condition) of the other client. (DeSimone at 3:5-21, 27-40,

64-67; 4:28-6; 5:1-11; & 6:4-15; Tygar 164 (EX1006)).

3. Claim 3 is Obvious in view of DeSimone, Munger, and Francis

a) wherein the second node successively forwards multiple identical retrieval packets to said multiple secure relays, wherein each retrieval packet indicates the retrieval condition for secure packets

DeSimone discloses that, when a client elects a socket of another client

whose packets it wishes to receive, the socket is added to the electing clients

MRAL, and the electing client informs the multicast routers of the elected socket

by positively responding to a query from a multicast router. (DeSimone at Abstract,

3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003); Tygar 167

(EX1006)). For example, a POSA would recognize that, in the example provided

IPR2015-01607 U.S. Patent No. 7,113,996

45

in VII.C.2.b, if client 101-5 is not receiving video multicast packets from clients

101-1 or 101-2, but later elects to receive video signals from clients 101-1 or 101-

2, the socket request (retrieval packet) would have to be conveyed through

multicast router 105 to multicast router 103, so that multicast router 103 can route

the packets through multicast router 105 to client 101-5. (DeSimone at 4:35-67;

5:1-11; Fig. 1; see also id. at Abstract; 3:5-21, 27-40, 64-67; 4:1-5 (EX1003);

Tygar 167 (EX1006)).

Moreover, DeSimone discloses that, at any time during a conference, a client

may choose to receive or not receive multicast packets from another client.

(DeSimone at 4:35-54 (EX1003)). A POSA would recognize that, for each time a

client elects to receive multicast packets from a client, it would send a positive

response to the multicast query for that socket. (Tygar 168 (EX1006)). Thus, a

POSA would recognize that, if a client were to choose to receive packets from a

particular client, then were to choose not to receive those packets, and then were to

again choose to receive the packets, the client would successively respond

positively to the multicast query regarding the multicast socket. (Id. 168

(EX1006).

Thus, a POSA would recognize DeSimone as disclosing that the electing

node (second node) causes the positive response to be conveyed to multiple

multicast routers (successively forwards multiple identical retrieval packets to

IPR2015-01607 U.S. Patent No. 7,113,996

46

said multiple secure relays, wherein each retrieval packet indicates the retrieval

condition for secure packets). (Id. 169)

However, to the extent it could be argued that DeSimone does not disclose

that the requested socket is conveyed through multiple multicast routers, or that

DeSimone does not disclose that the multiple identical retrieval packets are

forwarded to the multicast routers, such a feature was well-known at the time the

996 Patent was filed. (Id. 170).

For example, Francis discloses a system and method for transmitting

multicast packets to members of a multicast group. (Francis at Abstract

(EX1005)). Each of the multicast packets transmitted to a multicast group includes

a multicast address of a core node. (Id. at 6:25-30). If a node wishes to join the

multicast group, it transmits a control packet including a join request message and

the multicast address of the core node, and this packet is re-transmitted via

intermediary nodes until reaching a node that is part of the multicast tree. (Id. at

6:55-65); Tygar 171 (EX1006)). A POSA would recognize that, each time a node

requests to join the multicast tree, it would have to send this control packet, and

would thus, successively forward[] multiple identical control packets (multiple

retrieval packets) via intermediary nodes (to said multiple secure relays), where

each control packet (retrieval packet). (Id. 171). Moreover, a POSA would

recognize that each control packet indicates a request for multicast packets (a

IPR2015-01607 U.S. Patent No. 7,113,996

47

retrieval condition) and that each control packet includes a multicast address

(flag) that instructs the intermediary nodes to identify the multicast packets that

contain the multicast address (identify packets that contain the same retrieval

information). (Id. 171).

To a POSA at the time that the 996 Patent was filed, it would have been

obvious to modify the multicast Internet network of DeSimone so that, when a

client wishes to join a multicast group, rather than having a multicast router query

the client, the client sends a packet including the requested socket through

intermediary multicast routers until the packet reaches a multicast router that is

part of the multicast tree, such as that taught by Francis. A POSA would have been

motivated to use Francis techniques for joining a multicast tree, to reduce the

amount of resources required to manage multicast trees. (Id. 172); see also

Francis at 5:13-28 (EX1005)). Further, use of Francis technique for joining a

multicast tree would have been a combination of old elements in which each

element performed as expected to yield the predictable results of reducing the

amount of information that needs to be stored in multicast routers in a network.

(Tygar 172 (EX1006)).



IPR2015-01607 U.S. Patent No. 7,113,996

48


above). (Tygar 173 (EX1006)).

b) wherein each said retrieval packet contains a flag that instructs said multiple secure relays to identify secure packets that contain the same retrieval information

As noted above in VII.C.3.a, DeSimone discloses that a positive response

for a socket is conveyed to the multicast routers. (Tygar 175 (EX1006)). The

response informs the multicast routers to forward multicast packets including the

socket to the requesting client. (DeSimone at 4:43-67; 5:1-11; see also id. at

Abstract; 3:5-21, 34-40, 64-67; 4:26-42 (EX1003); Tygar 175 (EX1006)). Thus,

each response contains a socket (flag) instructing the multicast routers (multiple

secure relays) to identify multicast packets (secure packets) containing the

socket (that contain the same retrieval information). (Id. 175).

To the extent a narrow interpretation of the terms secure packets and/or

secure relays is taken, and to the extent one could argue that DeSimone does not

disclose these terms, these terms were well-known at the time that the 996 Patent

was filed (see VII.B.2.i above). (Tygar 176 (EX1006)).

4. Claim 14 is Obvious in view of DeSimone, Munger, and Francis

a) [a] method for maintaining a secure distributed storage system by initiating a transmission of a message from a first node to a second node in a secure manner, wherein the second node may be the first node, comprising the steps, executed in a data processing system

IPR2015-01607 U.S. Patent No. 7,113,996

49

This limitation recites that the second node may be the first node (emphasis

added). As such, the limitation does not require that the second node be the first

node.

DeSimone discloses a multicast network, over which clients can

communicate audio and video (messages) in a multimedia conference.

(DeSimone at Abstract; 4:61-67; & 5:1-11 (EX1003)). Multicast conference

packets are routed to clients in the multicast network through multicast routers

(e.g., MRs 103-105). (DeSimone at 3:12-21, 39-40,, 64-67; 4:1-5, 45-60; 5:8-11

(EX1003); Tygar 180 (EX1006)). Similar to the 996 Patent (see 996 Patent at

2:28-33; 3:44-50), multicast packets of DeSimone are stored as they are routed

through the distributed network. (DeSimone at 3:56-67; 4:1-5; & Fig. 1 (EX1003);

Tygar 180 (EX1006)). Thus, DeSimone discloses a distributed storage system.

(Tygar 180 (EX1006)).

A client communicating in a conference, and thereby transmitting packets, is

a first node. (Tygar 181 (EX1006)). A client listening in the conference, and

thereby receiving packets, is a second node. (Tygar 181 (EX1006)).

As noted in VII.C.2.a, a user must authenticate before being able to receive

multicast packets from other conference participants. (DeSimone at 5:57-67; 6:1-8;

& Fig. 3 (EX1003)). If the user is not authenticated, the user is precluded from

joining the conference. (DeSimone at 6:2-4 & Fig. 3 (EX1003)). Thus, the

IPR2015-01607 U.S. Patent No. 7,113,996

50

conference packets of DeSimone are transmitted in a secure manner, and the

distributed storage system is secure. (Tygar 182 (EX1006)). Moreover, the

processes of DeSimone are carried out in a system (data processing system) that

includes a multicast capable IP network, client terminals, and a Directory Server.

(DeSimone at 3:56-67; 4:1-8; & Figs. 1-3 (EX1003); Tygar 182 (EX1006)).

To the extent a narrow interpretation of the terms secure distributed storage

system and/or transmitting . . . a message . . . in a secure manner is taken, and to

the extent one could argue that DeSimone does not disclose these terms, these

terms were well-known at the time the 996 Patent was filed (see VII.B.2.i

above). (Tygar 183 (EX1006)).

b) creating a set of secure packets associated with the message, wherein each secure packet contains an identical first retrieval key, wherein the first retrieval key is created by the first node

As noted in VII.C.2.a, DeSimone discloses multicast routers that relay

multicast packets (secure packets) between clients in a network. (Tygar 185

(EX1006)). Each conference participants client is assigned a unique socket on

which to transmit each media type, and each packet transmitted by the terminal

thereafter includes the assigned socket in its header. (DeSimone at 3:27-36

(EX1003)). Other clients then receive this clients transmissions by selecting the

clients assigned socket. (id. at 6:8-15; see also id. at Abstract; 3:5-21, 34-40; 4:26-

67; 5:1-11). Thus, the transmitting client (first node) creates multicast

IPR2015-01607 U.S. Patent No. 7,113,996

51

conference packets (a set of secure packets) associated with an media

transmission (a message), where each of the multicast conference packets

contains the assigned socket (contains an identical first retrieval key, wherein the

first retrieval key is created by the first node). (Tygar 185 (EX1006)).



term was well-known at the time the 996 Patent was filed (see VII.B.2.i above).

(Tygar

Documents

IPR 2015-01607 Elia Data - Petition