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: David.Cavanaugh@wilmerhale.com
Jonathan Stroud, Reg. No. 72,518
Unified Patents Inc.
1875 Connecticut Ave. NW, Floor 10
Washington, D.C., 20009
Tel: (202) 805-8931
Email: jonathan@unifiedpatents.com
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
TABLE OF CONTENTS
I.
Mandatory Notices .............................................................................................1

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

II. Certification of Grounds for Standing ...............................................................2
III. Overview of Challenge and Relief Requested .................................................2
A. Prior Art Patents and Printed Publications ....................................................2
B.
Grounds for Challenge ..................................................................................3
IV. Technology Background ..................................................................................3

V. Overview Of the 996 Patent .............................................................................4
A. Summary of the Alleged Invention ...............................................................4
B.
Level of Ordinary Skill in the Art .................................................................6
C.
Prosecution History .......................................................................................6
VI. Claim Construction ...........................................................................................8

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

VII.
Specific Grounds for Petition ......................................................................11
A. Ground I: Claim 1-3 and 14-16 are anticipated by Free Haven. ...............11
1.
Overview of Free Haven ..........................................................................11
2.
Claim 1 is anticipated by Free Haven. ....................................................12
3.
4.
5.
Claim 14 is anticipated by Free Haven. ..................................................20
6.
7.

i
B.
IPR2015-01607
Ground II: Claims 1 is obvious in view of DeSimone and Munger. ..........27
1.
Overview of DeSimone .............................................................................27
2.
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...40
1.
Overview of DeSimone .............................................................................40
2.
Claim 2 is obvious in view of DeSimone, Munger, and Francis .............40
3.
Claim 3 is Obvious in view of DeSimone, Munger, and Francis.............44
4.
Claim 14 is Obvious in view of DeSimone, Munger, and Francis...........48
5.
Claim 15 is obvious in view of DeSimone, Munger, and Francis ...........56
6.
Claim 16 is Obvious in view of DeSimone, Munger, and Francis...........58
VIII. Conclusion ...................................................................................................60
ii
IPR2015-01607
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.
1
D.
IPR2015-01607
Service Information, Email, Hand Delivery, and Postal
Unifed consents to electronic service at david.cavanaugh@wilmerhale.com
and jonathan@unifiedpatents.com. 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
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
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
(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
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
5
IPR2015-01607
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
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
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
(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
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)).
10
IPR2015-01607
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
(EX1006)).
11
45
IPR2015-01607
(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
12
IPR2015-01607
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
13
IPR2015-01607
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)).
14
IPR2015-01607
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
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.
15
IPR2015-01607
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)
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
16
IPR2015-01607
(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)).
3.
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
17
IPR2015-01607
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)).
4.
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
18
IPR2015-01607
(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,
19
IPR2015-01607
including encrypted shares (secure packets), containing the PK (that contain the
same retrieval information). (Tygar 78 (EX1006)).
5.
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,
20
IPR2015-01607
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
21
IPR2015-01607
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
22
IPR2015-01607
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
23
IPR2015-01607
(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)).
6.
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,
24
IPR2015-01607
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
25
IPR2015-01607
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).)
7.
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
26
IPR2015-01607
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
27
IPR2015-01607
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
28
IPR2015-01607
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:18; & 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
29
IPR2015-01607
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
30
IPR2015-01607
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
31
IPR2015-01607
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)
another of said multiple secure relay and forwards non-secure packets to
destination relays
32
IPR2015-01607
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:111, 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
33
IPR2015-01607
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)).
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.
34
IPR2015-01607
secure packets is taken, and to the extent one could argue that DeSimone does
g)
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
35
IPR2015-01607
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:521, 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:3567; 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)).
36
IPR2015-01607
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
37
IPR2015-01607
(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,
38
IPR2015-01607
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
39
IPR2015-01607
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
of other clients from which the client elects to receive. (DeSimone at Abstract, 3:521, 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-
40
IPR2015-01607
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, 2740, 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-
41
IPR2015-01607
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 1011 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, 6467; 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
42
IPR2015-01607
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 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)).
43
IPR2015-01607
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
44
IPR2015-01607
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 1012, 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
45
IPR2015-01607
said multiple secure relays, wherein each retrieval packet indicates the retrieval
condition for secure packets). (Id. 169)
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
46
IPR2015-01607
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)).
47
IPR2015-01607
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.
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
48
IPR2015-01607
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
49
IPR2015-01607
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:2667; 5:1-11). Thus, the transmitting client (first node) creates multicast
50
IPR2015-01607
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 186 (EX1006)).
c)
forwarding the set of secure packets to multiple secure relays from the
first node
As noted above in VII.B.2.a, DeSimone discloses multicast routers that
relay conference multicast packets (secure packets) between clients in a
multicast capable IP network. (Tygar 188 (EX1006)). If 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. (Id. at 6:2-4); Tygar 188 (EX1006)).
Accordingly, the multicast routers are secure relays. (Id. 188 (EX1006)). In
order to route conference packets between certain clients (e.g., clients 101-11015), the packets must travel through multiple multicast routers. (DeSimone at Fig. 1
51
IPR2015-01607
(EX1003)). Thus, the multicast routers are multiple secure relays. (Tygar 189
(EX1006)).
secure relays is taken, and to the extent it could be argued that DeSimone does
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
DeSimone discloses that multicast conference packets are routed through
multicast routers in the network 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:43-67; 5:111 (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. (Id. at Fig. 1
(EX1003); Tygar 192 (EX1006)).
If, in the above example, clients 101-3 and 101-4 had not elected to receive
the packets by selecting the socket (second retrieval key), 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 193 (EX1006)). Thus, with the
network configuration disclosed by DeSimone, each of the multicast routers
52
IPR2015-01607
(secure relays) is configured to forward the multicast conference packets
(secure packets) to other multicast routers to service requesting clients, even
when a client on another sub-network has not elected to receive the packets (so
long as a second retrieval key associated with the first retrieval key is not received
in the same multiple secure relays). (Id. 193).
secure relays is taken, and to the extent it could be argued that DeSimone does
e)
wherein said second retrieval key is created by the first or second node
This limitation recites that the second retrieval key is created by the first or
second node (emphasis added). As such, the limitation does require that both the
first and second node be capable of creating the second retrieval key.
of transmitting 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 assigned to the other client. (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 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 196
53
IPR2015-01607
(EX1006)). Thus, DeSimone discloses an electing client (second node) that
selects a socket, and thus creates a socket request (creates said second retrieval
key). (Id. 196).
f)
forwarding the set of secure packets to the second node once the second
retrieval key is received in the said multiple secure relays
As noted in VII.B.2.f, DeSimone discloses that multicast routers (secure
relays) forward multicast conference packets (secure packets) to a client
(second node) when the client elects to receive the packets. (Tygar 198
(EX1006)). As noted above in VII.B.2.b, when a client elects a socket, the socket
is added to the electing clients MRAL, and the multicast routers are informed of
the socket elected by this client. (DeSimone at Abstract; 3:5-21, 27-40, 64-67;
4:28-67; 5:1-11; & 6:4-15 (EX1003); Tygar 198 (EX1006)). For example,
referring to Figure 1, DeSimone provides an example where the users at clients
101-3, 101-4, and 101-5 elect to not receive video signals from clients 101-1 and
101-2. (DeSimone at 5:4-6 & Fig. 1 (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).
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
54
IPR2015-01607
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, 6467; 4:1-5 (EX1003); Tygar 199 (EX1006)). Thus, a POSA would recognize that
DeSimone discloses that the multicast routers (multiple secure relays) forward
the multicast packets containing the socket (forward the set of secure packets to
the second node) to the client after the client sends the request for the socket
(once the second retrieval key is received in the said multiple secure relays). (Id.
199).
that the socket request is conveyed through multiple multicast routers, such a
feature was well-known at the time that the 996 Patent was filed. (Tygar 200
(EX1006)). For example, Francis discloses a system for transmitting multicast
packets to members of a multicast group. (Francis at Abstract (EX1005)). Each of
the multicast packets transmitted to the 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 (second
retrieval key) of the core node, and this packet is transmitted via intermediary
nodes (is received in the said multiple secure relays) until reaching a node that is
part of the multicast tree. (Id. at 5:55-65; Tygar 200 (EX1006)). Each node that
receives the control packet writes the address of the node from which the packet
55
IPR2015-01607
was received in a forwarding table, so that multicast packets may be forwarded to
the joining node. (Francis at 5:65-67 & 6:1-24 (EX1005); Tygar 200 (EX1006)).
to modify the multicast 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 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 201 (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. 201); see also Francis at 5:1328 (EX1005)). Further, use of Francis technique for joining a multicast tree would
have been a combination of old elements in which each element would perform 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 201 (EX1006)).
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 the 996 Patent was
filed (see VII.B.2.i above). (Tygar 202 (EX1006)).
5.
Claim 15 is obvious in view of DeSimone, Munger, and Francis
a)
creating a second retrieval key in a second node
56
IPR2015-01607
of transmitting clients 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.
(DeSimone at Abstract; 3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15
(EX1003)). Thus, in selecting a socket, the client (second node) creat[es] a
second retrieval key. (Tygar 205 (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
DeSimone discloses that a user of a client elects another client from which it
would like to receive packets by selecting a socket assigned to the other client.
(DeSimone at Abstract; 3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15
(EX1003)). This socket is then added to the electing clients MRAL, and the
multicast routers are informed of the elected socket for this client. (DeSimone at
4:35-67; 5:1-11; & 6:4-15 (EX1003); Tygar 207 (EX1006)). Thus, the selected
socket is associated with the client to which will the multicast routers will route the
multicast packets (associated with destination information for the set of secure
packets), and with the socket that was selected (information for identification of
said first retrieval key). (Id. 207). Moreover, as noted above in VII.C.4.f,
Francis also discloses that each intermediary node that receives a control packet
57
IPR2015-01607
writes the address (destination information) of the node from which it was
received in a forwarding table, so that multicast packets can be transmitting to a
joining node that sent the control packet. (Francis at 5:65-67 & 6:1-24 (EX1005);
Tygar 207 (EX1006)).
term was well-known at the time the 996 patent was filed (see VII.B.2.i above).
Tygar 208 (EX1006)).
c)
transmitting said second retrieval key from the second node to said
multiple secure relays
DeSimone discloses that a user of a client elects another client from which it
would like to receive packets by selecting a socket of the other client. (DeSimone
at Abstract; 3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003)). This
socket is then added to the electing clients MRAL, and the multicast routers are
informed of the elected socket for this client. (DeSimone at 4:35-67; 5:1-11; & 6:415 (EX1003); Tygar 210 (EX1006)). Thus, the request for the socket (second
retrieval key) is sent from the requesting client (second node) to the multicast
routers (multiple secure relays). (Id. 210).
6.
a)
at the second node, resequencing the set of secure packets to recreate the
packets
58
IPR2015-01607
DeSimone discloses that conference packets are sent over a multicast
capable Internet Protocol (IP) network. (DeSimone at 3:56-59 (EX1003)).
DeSimone may not disclose resequencing the set of secure packets to recreate the
packets. However, at the time the 996 Patent was filed, it was well known to
resequence IP packets to recreate a message based on resequencing information in
the packets. (Tygar 212 (EX1006)).
For example, the 996 Patent itself provides an excerpt from Request for
Comments (RFC) 815, which covers re-sequencing of fragmented IP datagrams.
(996 Patent at 6:59-8:50 (EX1001)). The 996 Patent discloses that the excerpt is
provided to better understand how the re-sequencing of . . . datagrams would
occur. (Id). The excerpt from RFC 815 states that a flag in the IP header
(resequencing information) indicates when the last fragment has arrived.
(See 996 Patent at 8:2-6 (EX1003); Tygar 213 (EX1006)).
Moreover, Munger discloses these features. (Tygar 214 (EX1006)).
Munger discloses breaking a message into multiple packets, encrypting the
packets, and sending the packets over a secure network. (Munger at 2:64-67; 3:1-6,
42-44; 7:57-67; & 8:1-3 (EX1004)). Munger discloses that, once the packets are
received and decrypted, the data stream can be reconstructed based on window
59
IPR2015-01607
sequence numbers and interleave sequence numbers. (Munger at 3:59-61; 4:8-15;
8:27-31, 66-67; 9:1-10; 13:10-12, 42-55 (EX1004); Tygar 214 (EX1006)).
to modify the multicast IP system of DeSimone to break up a message into packets,
and re-sequence the packets into the message at a receiving client based on
resequencing information in the packets, such as taught by Munger. A POSA
would have been motivated to use Mungers technique of fragmenting messages
and resequencing the fragments at the receiving client, in order to provide greater
security and anonymity for private communications. (Tygar 215 (EX1006); see
also Munger at 7:57-67 & 8:1-3 (EX1004)). Further, use of Mungers technique of
fragmenting and resequencing messages would have been a combination of old
elements in which each element would perform as expected to yield predictable
results of adding security and anonymity to network communications. (Tygar 215
(EX1006)).
VIII. CONCLUSION
Based on the foregoing, the challenged claim of the 996 Patent recites
subject matter that is unpatentable. The Petitioner requests institution of an inter
partes review to cancel these claims.
Respectfully Submitted,
/David L. Cavanaugh/
60
IPR2015-01607
David L. Cavanaugh
Registration No. 36,476
Jonathan Stroud
Thomas E. Anderson
Michael Van Handel
61
IPR2015-01607
Table of Exhibits for U.S. Patent 7,113,996 Petition for Inter Partes Review
Exhibit
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
Description
The Free Haven Project: Design and Development of an
Anonymous Secure Data Haven (Free Haven) (May 23,
2000)
U.S. Patent No. 6,011,782 (DeSimone) (filed on May 8,
1997, published on Jan. 4, 2000)
U.S. Patent No. 7,010,604 (Munger) (claims priority to Oct.
30, 1998, filed on Oct. 29, 1999, published on Mar. 7, 2006)
U.S. Patent No. 5,331,637 (Francis) (filed on Jul. 30, 1993,
published on Jul. 19, 1994)
Declaration of Professor Justin Douglas Tygar
Declaration of Professor Michael Freedman
File History, Allowance (08/19/2005)
File History, Supplemental Allowance (10/05/2005)
File History, Petition (07/06/2011)
File History, Grant of Petition (07/06/2011)
996 Patent USPTO Maint. Fees Window Dates
PAIR Application Status
File History, Supplemental Response (05/02/2005)
Petitioners Voluntary Interrogatory Responses
Screenshot of http://archives.seul.org/freehaven/dev/Jan2000/msg00000.html
Screenshot of http://archives.seul.org/freehaven/dev/Jan2000/msg00002.html
Screenshot of http://archives.seul.org/freehaven/dev/Mar2000/msg00010.html
Screenshot of http://archives.seul.org/freehaven/dev/May2000/msg00003.html
Screenshot of http://freehaven.net/doc/
IPR2015-01607
CERTIFICATE OF SERVICE
I hereby certify that on July 22, 2015, I caused a true and correct copy of the
foregoing materials:
Petition for Inter Partes Review of U.S. Patent No. 7,113,996 Under 35
U.S.C. 312 and 37 C.F.R. 42.104
Exhibits for Petition for Inter Partes Review of U.S. Patent No. 7,113,996
(EX1001-1022)
to be served via Federal Express on the following correspondent of record as listed
on PAIR:
Netarx Inc.
30840 Northwestern Highway
Suite 250
Farmington Hills, MI 48334
/Michael Van Handel/

Michael Van Handel

IPR 2015-01607 Elia Data - Petition

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IPR 2015-01607 Elia Data - Petition

Încărcat de

Drepturi de autor:

Formate disponibile

IPR2015-01607

U.S. Patent No. 7,113,996

Mandatory Notices .............................................................................................1

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

Grounds for Challenge ..................................................................................3

IV. Technology Background ..................................................................................3

Level of Ordinary Skill in the Art .................................................................6

Prosecution History .......................................................................................6

VI. Claim Construction ...........................................................................................8

secure relay ................................................................................................9

second node successively forwards .........................................................10

D. retrieval packet .........................................................................................10

Specific Grounds for Petition ......................................................................11

Overview of Free Haven ..........................................................................11

Claim 1 is anticipated by Free Haven. ....................................................12

Claim 2 is anticipated by Free Haven. ....................................................17

Claim 3 is anticipated by Free Haven. ....................................................18

Claim 14 is anticipated by Free Haven. ..................................................20

Claim 15 is anticipated by Free Haven. ..................................................24

Claim 16 is anticipated by Free Haven. ..................................................26

Overview of DeSimone .............................................................................27

Claim 1 is obvious over DeSimone in view of Munger. ...........................28

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

Overview of DeSimone .............................................................................40

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

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

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

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

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

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

Texas, LLC (Elia Data or Patent Owner).

and jonathan@unifiedpatents.com. Petitioner can be reached at Wilmer, Cutler,

CERTIFICATION OF GROUNDS FOR STANDING

OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

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

Prior Art Patents and Printed Publications

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

Grounds for Challenge

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

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

OVERVIEW OF THE 996 PATENT

Summary of the Alleged Invention

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

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

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

Level of Ordinary Skill in the Art

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

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

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

second node successively forwards

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

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

Overview of Free Haven

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

Claim 1 is anticipated by Free Haven.

Claim 2 is anticipated by Free Haven.

Claim 3 is anticipated by Free Haven.

Claim 14 is anticipated by Free Haven.

Claim 15 is anticipated by Free Haven.

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

Claim 16 is anticipated by Free Haven.

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

Claim 1 is obvious over DeSimone in view of Munger.