-
IPR2015-01607 U.S. Patent No. 7,113,996
DOCKET NO.: 2211726-00121US1 Filed on behalf of Unified Patents
Inc. By: David L. Cavanaugh, Reg. No. 36,476 Thomas Anderson, Reg.
No. 37,063 Michael Van Handel, Reg. No. 68,292
Wilmer Cutler Pickering Hale and Dorr LLP 1875 Pennsylvania
Ave., NW Washington, DC 20006 Tel: (202) 663-6000 Email:
[email protected]
Jonathan Stroud, Reg. No. 72,518 Unified Patents Inc. 1875
Connecticut Ave. NW, Floor 10 Washington, D.C., 20009 Tel: (202)
805-8931 Email: [email protected]
UNITED STATES PATENT AND TRADEMARK OFFICE
____________________________________________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________________________________
UNIFIED PATENTS INC. Petitioner
v.
Elia Data of Texas, LLC Patent Owner
IPR2015-01607 Patent 7,113,996
PETITION FOR INTER PARTES REVIEW OF
U.S. PATENT NO. 7,113,996 CHALLENGING CLAIMS 1-3 and 14-16
UNDER 35 U.S.C. 312 AND 37 C.F.R. 42.104
-
IPR2015-01607 U.S. Patent No. 7,113,996
i
TABLE OF CONTENTS
I. Mandatory Notices
.............................................................................................
1A. Real Party-in-Interest
....................................................................................
1B. Related Matters
..............................................................................................
1C. Counsel
..........................................................................................................
1D. Service Information, Email, Hand Delivery, and Postal
............................... 2
II. Certification of Grounds for Standing
...............................................................
2III. Overview of Challenge and Relief Requested
................................................. 2
A. Prior Art Patents and Printed Publications
.................................................... 2B. Grounds
for Challenge
..................................................................................
3
IV. Technology Background
..................................................................................
3V. Overview Of the 996 Patent
.............................................................................
4
A. Summary of the Alleged Invention
............................................................... 4B.
Level of Ordinary Skill in the Art
.................................................................
6C. Prosecution History
.......................................................................................
6
VI. Claim Construction
...........................................................................................
8A. secure packet
..............................................................................................
8B. secure relay
................................................................................................
9C. second node successively forwards
......................................................... 10D.
retrieval packet
.........................................................................................
10
VII. Specific Grounds for Petition
......................................................................
11A. Ground I: Claim 1-3 and 14-16 are anticipated by Free Haven.
............... 11
1. Overview of Free Haven
..........................................................................
112. Claim 1 is anticipated by Free Haven.
.................................................... 123. Claim 2
is anticipated by Free Haven.
.................................................... 174. Claim 3
is anticipated by Free Haven.
.................................................... 185. Claim 14
is anticipated by Free Haven.
.................................................. 206. Claim 15 is
anticipated by Free Haven.
.................................................. 247. Claim 16 is
anticipated by Free Haven.
.................................................. 26
-
IPR2015-01607 U.S. Patent No. 7,113,996
ii
B. Ground II: Claims 1 is obvious in view of DeSimone and
Munger. .......... 271. Overview of DeSimone
.............................................................................
272. Claim 1 is obvious over DeSimone in view of Munger.
........................... 28
C. Claims 2, 3, and 14-16 are Obvious in view of DeSimone,
Munger, and ... 401. Overview of DeSimone
.............................................................................
402. Claim 2 is obvious in view of DeSimone, Munger, and Francis
............. 403. Claim 3 is Obvious in view of DeSimone, Munger,
and Francis ............. 444. Claim 14 is Obvious in view of
DeSimone, Munger, and Francis ........... 485. Claim 15 is obvious
in view of DeSimone, Munger, and Francis ........... 566. Claim 16
is Obvious in view of DeSimone, Munger, and Francis ...........
58
VIII. Conclusion
...................................................................................................
60
-
IPR2015-01607 U.S. Patent No. 7,113,996
1
I. MANDATORY NOTICES
A. Real Party-in-Interest
Pursuant to 37 C.F.R. 42.8(b)(1), Unified Patents Inc. (Unified
or
Petitioner) certifies that Unified is the real
party-in-interest, and further certifies
that no other party exercised control or could exercise control
over Unifieds
participation in this proceeding, the filing of this petition,
or the conduct of any
ensuing trial. In this regard, Unified has submitted voluntary
discovery. See
EX1015 (Petitioners Voluntary Interrogatory Responses).
B. Related Matters
U.S. Pat. No. 7,113,996 (996 Patent (EX1001)) is owned by Elia
Data of
Texas, LLC (Elia Data or Patent Owner).
On May 1, 2015, Elia Data filed lawsuits against Dropbox, Box,
SugarSync,
and Google, claiming that certain of these companies products
and/or services
infringe the 996 Patent. The cases are in their early stages and
no schedule or trial
date has been set. Between April 5, 2012, and June 21, 2013,
Elia Data filed
lawsuits against Microsoft, Citrix Systems, International
Business Machines (IBM),
Apple, and Amazon. Each of these lawsuits has been dismissed
with prejudice.
C. Counsel
David L. Cavanaugh (Reg. No. 36,476) will act as lead counsel;
Jonathan
Stroud (Reg. No. 72,518), Thomas Anderson (Reg. No. 37,063), and
Michael Van
Handel (Reg. No. 68,292) will act as back-up counsel.
-
IPR2015-01607 U.S. Patent No. 7,113,996
2
D. Service Information, Email, Hand Delivery, and Postal
Unifed consents to electronic service at
[email protected]
and [email protected]. Petitioner can be reached at
Wilmer, Cutler,
Pickering, Hale and Dorr, LLP, 1875 Pennsylvania Ave., NW
Washington, DC
20006 and (202) 663-6000, Fax: 202-663-6363 and Unified Patents
Inc., 1875
Connecticut Ave. NW, Floor 10, Washington, D.C., 20009, (650)
999-0899.
II. CERTIFICATION OF GROUNDS FOR STANDING
Petitioner certifies pursuant to Rule 42.104(a) that the patent
for which
review is sought is available for inter partes review and that
Petitioner is not
barred or estopped from requesting an inter partes review
challenging the patent
claims on the grounds identified in this Petition.
III. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED
Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)-(2), Petitioner
challenges
claims 1-3 and 14-16 of the 996 Patent.
A. Prior Art Patents and Printed Publications
The following references are pertinent to the grounds of
unpatentability
explained below: 1
1 The 996 Patent issued from a patent application filed prior to
enactment of the
America Invents Act (AIA). Accordingly, pre-AIA statutory
framework applies.
-
IPR2015-01607 U.S. Patent No. 7,113,996
3
1. The Free Haven Project: Design and Deployment of an Anonymous
Secure
Data Haven (May 23, 2000) (Free Haven (EX1002)), which is prior
art
under 35 U.S.C. 102(a).
2. U.S. Patent No. 6,011,782 (filed on May 8, 1997; published on
Jan. 4, 2000)
(DeSimone (EX1003)), which is prior art under 35 U.S.C. 102(a)
and
102(e).
3. U.S. Patent No. 7,010,604 (claiming priority to Oct. 30,
1998; filed on Oct.
29, 1999; published on Mar. 7, 2006) (Munger (EX1004)), which is
prior
art under 35 U.S.C. 102(e).
4. U.S. Patent No. 5,331,637 (filed on Jul. 30, 1993; published
on Jul. 19, 1994)
(Francis (EX1005)), which is prior art under 35 U.S.C. 102(a),
102(b),
and 102(e).
B. Grounds for Challenge
This Petition, supported by the declaration of Justin Douglas
Tygar (Tygar
Declaration or Tygar (EX1006)), requests cancellation of
challenged claims 1-3
and 14-16 as unpatentable under 35 U.S.C. 102 and/or 103. See 35
U.S.C.
314(a).
IV. TECHNOLOGY BACKGROUND
The Tygar Declaration discusses in explains the technology
discussed in this
Petition in greater detail, specifically the concepts of
packet-switched networks
-
IPR2015-01607 U.S. Patent No. 7,113,996
4
(see Tygar 16-19 (EX1006)), packets (see Tygar 20 (EX1006)),
relays (see
Tygar 21 (EX1006)), information security (see Tygar 22
(EX1006)), and
distributed storage (see Tygar 23 (EX1006)).
V. OVERVIEW OF THE 996 PATENT
A. Summary of the Alleged Invention
The 996 Patent recognizes that many prior art protocols existed
for
transmitting data securely over networks. (996 Patent at 1:43-63
(EX1001)).
The 996 Patent also recognizes that, in transmitting data
through a network, the
data is stored. (Id. at 1:64-67 & 2:1-7, 30-33). However,
the 996 Patent states
that current security protocols [were] inflexible. (Id. at
1:13-15). The 996 Patent
alleges a need to improve existing security protocols by
providing users with a
flexible and convenient way to securely transport and store
data. (Id. at 2:15-18).
To address this purported problem, the 996 Patent describes an
allegedly
novel secure transport and storage system that makes only slight
modifications to
existing protocols. (Id. at 2:45-48). These modifications
include modifying IP
packets of a known protocol, such as IPSec packets, to include a
retrieval key, and
modifying IP relays to forward packets to a destination when a
retrieval condition
has been satisfied. (Id. at 5:66-67; 6:1-13, 29-33). However,
these allegedly novel
modifications were already well known in the prior art. (Tygar
25 (EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
5
The 996 Patent describes sending data over an Internet Protocol
(IP)
network using Secure Transport protocol packets, which are
packets of a known
secure protocol plus a retrieval key. (996 Patent at 4:66-67;
5:1-11; & Fig. 1
(EX1001); Tygar 26 (EX1006)). Figure 4 below illustrates a known
IPSec packet,
and Figure 5 illustrates a Secure Transport packet, which
includes the same
fields as the IPSec packet plus a retrieval key field. (996
Patent at 4:66-67; 5:1-9;
& Figs. 1-2 (EX1001); Tygar 26 (EX1006)).
(996 Patent at Fig. 4 (EX1001)). (996 Patent at Fig. 5
(EX1001)).
The 996 Patent describes modifying the IP/IPSec protocol stack
in network
relays to perform secure transport. (996 Patent at 5:23-25
(EX1001)). These
modifications include adding a table of known secure relays,
adding the ability to
randomly choose secure relays to which to forward packets, and
adding the ability
to forward packets to a retrieval destination when a retrieval
packet is received. (Id.
at 5:23-33 (EX1001)). To send a file through the Secure
Transport network, a
file is broken into packets. The packets are given an IP header,
encapsulated by an
-
IPR2015-01607 U.S. Patent No. 7,113,996
6
IPSec header, given a retrieval key, and then forwarded between
relays. (996
Patent at 5:7-9, 42-56 & Figs. 4-5 (EX1001)). The relays
send the packets to a
client when they receive a retrieval key (otherwise referred to
as magnet,
retrieval condition, or retrieval datagram in the 996 Patent)
from the client.
(Id. at 4:29-30; 5:27-33, 56-58; 6:34-37); Tygar 27-28
(EX1006)).
As the prior art demonstrates, the purported problem of
improving existing
security protocols to provide a convenient way to securely
transport and store data
as described in the 996 Patent was well known, and there were
many well-known
solutions to that problem prior to the 996 Patent. (Tygar 29
(EX1006)).
B. Level of Ordinary Skill in the Art
A person of ordinary skill in the art (POSA) for the 996 Patent
would
have a Masters Degree in electrical engineering, computer
science or a related
subject, and at least three years of experience working with
distributed computer
networks and network security, or the equivalent. (Tygar 30
(EX1006)).
C. Prosecution History
The 996 Patent issued from U.S. Pat. Appl. No. 09/910,416, which
was filed
on July 20, 2001 (File History, Application (07/20/2001)
(EX1007)), and claims
priority to July 21, 2000 (996 Patent at 1:7-10 (EX1001)). The
Examiner allowed
the claims in view of the limitations forwarding all secure
packets associated with
the retrieval condition to the second node if the retrieval
condition has been
-
IPR2015-01607 U.S. Patent No. 7,113,996
7
indicated, forwarding al[l] the secure packets to another secure
relay if the
retrieval condition has not been indicated, and wherein said
secure packets are in
transition and not discoverable until a retrieval condition has
been indicated.2 (See
File History, Allowance at 4-5 (08/19/2005) (EX1008); File
History, Supplemental
Allowance at 5-6 (10/05/2005) (EX1009)). However, as described
in detail below,
all of these features cited by the Examiner (and indeed the
entire claim) were well
known at the time that the 996 Patent was filed. (Tygar 43-215
(EX1006)).
On July 6, 2011, Patent Owner filed a petition to accept the
delayed payment
of the 3.5 year maintenance fee for the 996 Patent, and the
petition was granted.
(See File History, Petition at 1 (07/06/2011) (EX1010); File
History, Grant of
Petition at 1 (07/06/2011) (EX1011)). To date, Patent Owner has
not submitted
payment for the 7.5 year maintenance fee for the 996 Patent,
which was due on
September 26, 2014. (See 996 Patent USPTO Maint. Fees Window
Dates at 1
(EX1012)). Accordingly, as of this time, the 996 Patent is
expired. (See PAIR
Application Status at 1 (EX1013)). 2 Petitioner notes that not
all of these limitations were included in each of the
independent claims when the application was allowed. (See File
History,
Supplemental Response at 3-8 (05/02/2005) (EX1014). For example,
the limitation
wherein said secure packets are in transition and not
discoverable until a retrieval
condition has been indicated only appeared in dependent claim 7.
(Id).
-
IPR2015-01607 U.S. Patent No. 7,113,996
8
VI. CLAIM CONSTRUCTION
Claim terms of a patent in inter partes review are normally
given the
broadest reasonable construction in light of the specification.
See 37 C.F.R.
42.100(b); see also In re Cuozzo Speed Techs., LLC, 778 F.3d
1271, 1279-81
(Fed. Cir. 2015). However, as noted above in V.C, the 996 Patent
has expired
due to nonpayment of maintenance fees. Claim terms of an expired
patent in inter
partes review are construed in accordance with the claim
construction standard set
forth in Phillips v. AWH Corp, 415 F.3d 1303 (Fed. Cir.
2005).
The following discussion proposes constructions and support for
those
constructions. Any claim terms not included in the following
discussion should be
given their ordinary meaning in light of the specification, as
commonly understood
by those of ordinary skill in the art. The broadest reasonable
interpretation of a
claim term may be the same as or broader than the construction
under the Phillips
standard, but it cannot be narrower. See Facebook, Inc. v.
Pramatus AV LLC, 2014
U.S. App. LEXIS 17678, *11 (Fed. Cir. 2014). The constructions
proposed below
should be applied regardless of whether the terms are
interpreted under the Phillips
standard or the broadest reasonable interpretation standard.
A. secure packet
The term secure packet should be interpreted to mean a unit of
data to
which access by an unauthorized user or device is prevented.
(Tygar 39
-
IPR2015-01607 U.S. Patent No. 7,113,996
9
(EX1006)). The 996 Patent does not define the term secure
packet. Rather, the
996 Patent suggests many different ways in which security can be
added to a
packet, including requiring authentication before providing
access to the packet, or
using encryption. (See 996 Patent at 1:48-57; 2:31-33, 37-56;
3:48-61; 4:29-41;
5:42-58; 6:34-43, 46-54; 8:52-63, 65-67; & 9:1-14 (EX1001);
see also Tygar 39
(EX1006)). The proposed construction is consistent with the
specification and the
ordinary use of the term secure packet. (Tygar 25 (EX1006)).
B. secure relay
The term secure relay should be interpreted to mean a network
device
capable of receiving a secure packet, sending the secure packet,
and redirecting the
secure packet. (Tygar 40 (EX1006)). The 996 Patent does not
define the term
secure relay. Rather, the 996 Patent states that secure
transport can utilize a
known protocol with slight modifications to allow re-direction
of data. (See 996
Patent at 2:45-56 (EX1001)). For example, the 996 Patent
discloses altering a
router, so that packets with a retrieval key are forwarded to a
retrieval destination
when a retrieval condition has been set. (See 996 Patent at
5:23-33 (EX1001)).
The proposed construction is consistent with the specification
and the ordinary use
of the term secure relay. (Tygar 40 (EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
10
C. second node successively forwards
The term second node successively forwards should be interpreted
to mean
a node that causes repeated forwarding. (Tygar 41 (EX1006)). The
996 Patent
does not define second node successively forwards. Rather, the
996 Patent
discloses generating a key that would instruct relays to send
any data with a
matching key to a destination. (See 996 Patent at 4:11-16
(EX1001)). As
illustrated in the example networks of Figs. 1 and 2 of the 996
Patent, each of the
nodes (e.g., A, B, C) is directly connected to only one relay.
(See 996 Patent at
Figs. 1, 2 (EX1001)). The proposed construction is consistent
with the
specification and the ordinary use of the term second node
successively
forwards. (Tygar 41 (EX1006)).
D. retrieval packet
The term retrieval packet should be interpreted to mean a unit
of data
transmitted to cause retrieval of information. (Tygar 42
(EX1006)). The 996
Patent does not define the term retrieval packet. Rather, the
996 Patent discloses
that a file can be split into units, and that a retrieval
condition, retrieval key, or
retrieval datagram, may be used to receive the units. (See 996
Patent at
Abstract; 4:29-30; & 5:30-31, 42-47 (EX1001)). The proposed
construction is
consistent with the specification and the ordinary use of the
term retrieval
packet. (Tygar 42 (EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
11
VII. SPECIFIC GROUNDS FOR PETITION
Pursuant to Rule 42.104(b)(4)-(5), the following sections (as
confirmed in
the Tygar 43-215 (EX1006)) detail the grounds of
unpatentability, the
limitations of the challenged claims of the 996 Patent, and how
these claims were
therefore anticipated and/or obvious in view of the prior
art.
A. Ground I: Claim 1-3 and 14-16 are anticipated by Free Haven.
1. Overview of Free Haven
Free Haven is a printed publication because it was publically
available. As
discussed in the Declaration of Professor Michael Freedman, Free
Haven was
publicly available on a website as of May 23, 2000. (See
Freedman Decl. at 1 (Ex.
1007). Therefore, Free Haven constitutes prior art to the 996
Patent under 35
U.S.C. 102(a). Free Haven, as relied upon here in Exhibit 1002,
is the document
available from the website link referenced in the Declaration of
Michael Freedman.
Free Haven discloses a distributed publication system, which
stores and serves
files. (Free Haven at Abstract; 55 (EX1002)). The system
includes a community of
servers (as a whole referred to as a servnet), and each
server hosts data. (Id. at 55). Data moves from one
server to another. (Id.). Figure 5-1 below illustrates the
structure of a Free Haven server. (Tygar 45
(EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
12
(Left: Free Haven at Fig. 5-1, p. 56 (EX1002)).
When an author wants to publish a file, a server breaks the file
into shares,
and then for each share negotiates for a server to publish that
share on the servnet.
(Free Haven at 56, 57 (EX1002)). When a reader wishes to
retrieve a file from the
servnet, the reader requests the file, and a server broadcasts
the request to all other
servers. (Id. at 57). The servers that are holding shares for
that file then deliver the
shares to the readers location. (Id.). Once the reader has
enough shares, the file is
recreated. (Id. at 60); Tygar 46 (EX1006)).
2. Claim 1 is anticipated by Free Haven.
a) [a] secure transport system for transporting secure packets
from a first node to a second node
Free Haven discloses a distributed storage system, which serves
and stores
documents. (Free Haven at Abstract; p. 55 (EX1002)). When an
author wishes to
publish a file, a publishing server breaks the file into shares
(packets), and then
sends each share to be stored on a server in a community of
servers connected over
the Internet, called a servnet. (Id. at 56, 57, 59 & Fig.
5-1). Thus, the publishing
server is first node. (Tygar 49 (EX1006)). The file may be
encrypted before it
is broken into shares. (Free Haven at 59 (EX1002)). Shares are
signed with a
public/private key pair (PK,SK). (Id. at 59, 66).
In order to retrieve the file, a client must know the PK of the
file. (Id. at 60,
66). A client retrieves the file by using a server (requesting
server) to broadcast
-
IPR2015-01607 U.S. Patent No. 7,113,996
13
the PK to all of the servers it knows about. (Id.). Each server
that receives the PK
checks to see if it has any shares that contain the PK, and if
it does, encrypts each
share with a PK of the client and sends it to the clients
address. (Id.). Thus, the
system transports encrypted shares (secure packets) from a
publishing server
(first node) to a requesting server (second node) over a secure
communications
system (secure transport system). (Tygar 50 (EX1006)).
b) a first node that creates secure packets, wherein each secure
packet contains identical retrieval information
Free Haven discloses that a publishing server (first node)
breaks a file into
encrypted shares (secure packets), which are each signed with a
PK that can be
used to retrieve the shares (wherein each secure packet contains
identical retrieval
information). (Free Haven at 59, 66 (EX1002); Tygar 52
(EX1006)).
c) multiple secure relays that receive secure packets and non
secure packets from multiple nodes or other secure relays
Free Haven discloses servnet servers that store shares of files.
(Free Haven
at 55-57, 59-60 (EX1002)). The shares may or may not be
encrypted at the
discretion of a publisher. (Free Haven at 59 (EX1002)). The
shares are moved
from one server in the servnet to another every so often. (Free
Haven at 55, 67-69
(EX1002)). Each server has a public key and remailer reply block
to provide
secure, authenticated communication with the server. (Free Haven
at 55
(EX1002)). Accordingly, the servnet servers are relays in that
they move shares
-
IPR2015-01607 U.S. Patent No. 7,113,996
14
between themselves, and are secure in that they provide for
secure
communication. (Tygar 54 (EX1006)).
The servnet servers receive encrypted shares (secure packets)
from
publishers that elect to encrypt their files, and unencrypted
shares (non secure
packets) from publishers that do not elect to encrypt their
files. (Free Haven at 59
(EX1002); Tygar 55 (EX1006)). Moreover, the servnet servers
receive shares
from both publishing servers (multiple nodes) and servnet
servers (secure
relays). (Free Haven at 55-57, 59-60, 67-69 (EX1002)). Thus,
Free Haven
discloses multiple servnet servers (multiple secure relays) that
receive encrypted
shares (secure packets) and unencrypted shares (non secure
packets) from
multiple publishing servers (nodes) or other servnet servers
(other secure
relays). (Tygar 55 (EX1006)).
d) wherein said multiple secure relays are capable of
identifying retrieval information in each secure packet
As noted above in VII.A.2.a, servers (multiple secure relays)
receive
queries for shares that contain a particular PK, and check to
determine whether
they have any shares that contain the particular PK. (Free Haven
at 60 (EX1002)).
Thus, the servers (multiple secure relays) are capable of
identifying PKs
(retrieval information) in each encrypted share (secure packet).
(Tygar 57
(EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
15
e) wherein each of said multiple secure relays forwards secure
packets to another of said multiple secure relay and forwards
non-secure packets to destination relays
Free Haven discloses that servers (multiple secure relays) trade
both
encrypted shares (secure packets) and unencrypted shares (non
secure packets)
amongst themselves over the Internet. (Free Haven at 55, 67-69
(EX1002; Tygar
59 (EX1006)). When a PK is received, servers forward shares
having the PK to the
requesting server. (Free Haven at 60-61, 66 (EX1002)). Thus,
Free Haven
discloses that the servers (multiple secure relays) trade
encrypted shares with
other servnet servers (forward secure packets to another of said
multiple secure
relay) and forward unencrypted shares that contain the PK to the
requesting server
(forwards non-secure packets to destination relays). (Tygar 59
(EX1006)).
f) end3 wherein said multiple secure relays forward secure
packets to the second node when a retrieval condition has been
indicated
Free Haven discloses that, upon receiving a PK (retrieval
condition), each
of the servers checks to see whether it has any shares that
contain the PK. (Free
Haven at 60 (EX1002); Tygar 61 (EX1006)). If it does, the server
sends the
share(s) to the requesting servers address. (Free Haven at 60
(EX1002)). Thus, the
3 It appears the term and was mistakenly changed to the word end
when the
996 Patent issued. (See 996 File History, Supplemental Response
at 2 (EX1014)).
Accordingly, the term is treated as being and herein.
-
IPR2015-01607 U.S. Patent No. 7,113,996
16
servnet servers (multiple secure relays) forward shares of a
given PK, including
encrypted shares (secure packets), to the requesting server
(second node) when
the requesting server has requested shares having the PK (when a
retrieval
condition has been indicated). (Tygar 61 (EX1006).)
g) wherein each of said multiple secure relays forwards secure
packets to another of said multiple secure relays when the
retrieval condition has not been indicated
Free Haven discloses that servers (secure relays) move shares
from server
to server in a process called trading. (Free Haven at 55, 67-69
(EX1002)). Thus, in
situations where a client has not requested the shares, they
would still be traded.
(Tygar 63 (EX1006)). Therefore, each of the servers (multiple
secure relays)
trades shares, including encrypted shares, to other servers
(forwards secure
packets to another of multiple secure relays when the retrieval
condition has not
been indicated). (Tygar 63 (EX1006)).
h) a second node that creates a retrieval condition related to
said retrieval information in said multiple secure packets and
receives the secure packets
Free Haven discloses that a requesting server (second node)
broadcasts a
PK of a file requested by a client to all of the servnet servers
it knows about. (Free
Haven at 60 (EX1002); Tygar Decl. 65 (EX1006)). Each server that
receives the
PK checks to see if it has any shares that contain the PK. (Free
Haven at 60
(EX1002)). Thus, the broadcast PK is a retrieval condition that
is related to the
PK (retrieval information) with which certain shares, such as
encrypted shares
-
IPR2015-01607 U.S. Patent No. 7,113,996
17
(secure packets), were signed. (Tygar 65 (EX1006)). Because the
requesting
server (second node) broadcasts the PK, it creates a retrieval
condition. (Id.
65). The requesting server (second node) receives the shares,
including the
encrypted shares (secure packets), which include the PK. (Free
Haven at 60
(EX1002); Tygar 65 (EX1006)).
3. Claim 2 is anticipated by Free Haven.
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
Free Haven discloses that a requesting server (second node)
broadcasts a
PK (creates a retrieval condition by generating a unique
identifying flag) of a
requested file. (Free Haven at 60 (EX1002); Tygar Decl. 68
(EX1006)). Each
server receiving the PK checks whether it has any shares,
including encrypted
shares (secure packets), that contain the requested PK. (Free
Haven at 60
(EX1002)). Thus, the broadcast PK is used to identify shares
that contain the PK,
and is a unique identifying flag that identifies said multiple
secure packets that
contain the same retrieval information. (Tygar 68 (EX1006)).
b) wherein said second node transmits said identifying flag to
said multiple secure relays to initiate transmission of said
multiple secure packets to said second node
Free Haven discloses that the requesting server (second node)
broadcasts a
PK (identifying flag) to all of the servnet servers (multiple
secure relays) it
knows about. (Free Haven at 60 (EX1002); Tygar 70 (EX1006)).
Each server
-
IPR2015-01607 U.S. Patent No. 7,113,996
18
that receives the PK sends any shares, including encrypted
shares (secure
packets), it has that contain the PK. (Free Haven at 60
(EX1002)). Thus, the PK is
broadcasted to initiate transmission of said multiple secure
packets to said second
node. (Tygar 70 (EX1006)).
c) wherein said first or second nodes may create said retrieval
condition
This limitation recites that the first or second nodes may
create said retrieval
condition (emphasis added). Thus, the limitation does not
require that both the
first and the second nodes be capable of creating the retrieval
condition. Free
Haven discloses that an author running her own server could
store shares of a file
into the servnet, and then retrieve the shares from the servnet
(Free Haven at 59,
60; see also id. at 50 (EX1002)). Thus, the publishing server
(first node) or a
separate requesting server (second node) may broadcast the PK
for the file
(create said retrieval condition). (Tygar 72 (EX1006)).
4. Claim 3 is anticipated by Free Haven.
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
Free Haven discloses that a requesting server (second node)
broadcasts a
message (request, PKfile, PKclient, reply block) to each servnet
server it knows
about. (Free Haven at 57, 60, 79, 83 (EX1002)). The broadcast
message can be
sent out in bulk, and can be sent perhaps once an hour. (Free
Haven at 60
(EX1002)). Thus, the requesting node (second node) sends the
messages
-
IPR2015-01607 U.S. Patent No. 7,113,996
19
(successively forwards . . . retrieval packets) to the servnet
nodes (multiple
secure relays). (Tygar 75 (EX1006)). Since each of the messages
(retrieval
packets) includes (request, PKfile, PKclient, reply block) (see
Free Haven at 60
(EX1002)), the messages are identical, and are multiple
identical retrieval
packets. (Tygar 75 (EX1006)).
Each of the messages includes the PK that was used to sign the
file. (Free
Haven at 60 (EX1002)). Each server receiving the message will
check whether it
has shares that contain the PK, and if it does, will send the
share(s) to the
requesting server. (Free Haven at 60 (EX1002)). Thus, the PK of
the file is a
retrieval condition, and each of the messages indicates the PK
of the file
(indicates the retrieval condition for secure packets). (Tygar
76 (EX1006)).
b) wherein each said retrieval packet contains a flag that
instructs said multiple secure relays to identify secure packets
that contain the same retrieval information
Free Haven discloses that each of the broadcast messages
(retrieval
packets) sent to the servers includes the PK (flag) of the file.
(Free Haven at 60
(EX1002); Tygar 78 (EX1006)). Each servnet server receiving the
message
checks to see if it has any shares that contain the PK, and if
it does, sends the
share(s) to the requesting server. (Free Haven at 60 (EX1002)).
Thus, the PK
(flag) instructs the servnet servers (multiple secure relays) to
identify shares,
-
IPR2015-01607 U.S. Patent No. 7,113,996
20
including encrypted shares (secure packets), containing the PK
(that contain the
same retrieval information). (Tygar 78 (EX1006)).
5. Claim 14 is anticipated by Free Haven.
a) [a] method for maintaining a secure distributed storage
system by initiating a transmission of a message from a first node
to a second node in a secure manner, wherein the second node may be
the first node, comprising the steps, executed in a data processing
system
This limitation recites that the second node may be the first
node (emphasis
added). The limitation does not require that the second node be
the first node.
Free Haven discloses a distributed storage system, which serves
and stores
documents. (Free Haven at Abstract, 55 (EX1002)). When an author
wishes to
publish a file, the author stores the file on a publishing
server, which breaks the file
into shares (packets), and then sends each share to be stored in
a community of
servers connected over the Internet, called a servnet. (Free
Haven at 56, 57, 59, &
Fig. 5-1 (EX1002); Tygar 82 (EX1006)). Thus, the publishing
server is a first
node. (Tygar 82 (EX1006)). The file may be encrypted before it
is broken into
shares. (Free Haven at 59 (EX1002)). Shares are signed with a
public/private key
pair (PK,SK). (Free Haven at 59, 66 (EX1002)).
In order to retrieve a file, a client must know the PK of the
file. (Free Haven
at 60, 66 (EX1002)). A client retrieves the file by using a
server to broadcast the
PK to all of the servnet servers it knows about. (Free Haven at
60 (EX1002)). Each
server that receives the PK checks to see if it has any shares
that contain the PK,
-
IPR2015-01607 U.S. Patent No. 7,113,996
21
and if it does, encrypts each share with a PK of the client and
sends them to the
clients address. (Free Haven at 60 (EX1002)). Thus, Free Haven
discloses that a
distributed storage system (data processing system), where a
publishing system
(first node) stores a file in the system (initiat[es] a
transmission of a message),
and a requesting server (second node) retrieves the file from
the system, over a
secure communications system (in a secure manner). (Tygar 83
(EX1006)).
Free Haven also discloses that an individual can use their own
server to
publish the file into the distributed storage system, and can be
the same person that
retrieves the file from the distributed storage system. (Free
Haven at 60 (EX1002)).
Thus, the publishing server may be the requesting server (the
second node may be
the first node). (Tygar 84 (EX1006)).
b) creating a set of secure packets associated with the message,
wherein each secure packet contains an identical first retrieval
key, wherein the first retrieval key is created by the first
node
Free Haven discloses that a publishing server (first node)
breaks a file
(message) into encrypted shares (a set of secure packets
associated with the
message), which are each signed with a public key PK (wherein
each secure
packet contains an identical first retrieval key, wherein the
first retrieval key is
created by the first node). (Free Haven at 60; Tygar 86
(EX1006)).
c) forwarding the set of secure packets to multiple secure
relays from the first node
-
IPR2015-01607 U.S. Patent No. 7,113,996
22
Free Haven discloses servers that store shares of files. (Free
Haven at 55-57,
59-60 (EX1002)). The shares may be encrypted at the discretion
of a publisher.
(Free Haven at 59 (EX1002)). The shares are created by a
publishing server, which
then sends them to be stored on servers. (Free Haven at 55,
59-60 (EX1002)). The
shares are then moved from one server in the servnet to another.
(Free Haven at 55,
67-69 (EX1002)). Each server has a public key and remailer reply
block address to
provide secure, authenticated communication with the server.
(Free Haven at 55
(EX1002)). Thus, servnet servers are secure relays, as they
provide secure
communication and move shares between themselves. (Tygar 88
(EX1006)).
The servnet servers receive encrypted shares (secure packets)
from
publishers electing to encrypt their files. (Free Haven at 59
(EX1002); Tygar 89
(EX1006)). Moreover, the servnet servers receive shares from a
publishing server
(a first node). (Free Haven at 55-57, 59-60 (EX1002); Tygar 89
(EX1006)).
Thus, Free Haven discloses a publishing server (first node) that
sends shares,
including encrypted shares (set of secure packets), to servnet
servers (multiple
secure relays). (Tygar 89 (EX1006)).
d) forwarding the set of secure packets among secure relays so
long as a second retrieval key associated with the first retrieval
key is not received in the same multiple secure relays
Free Haven discloses that a publishing server breaks a file into
encrypted
shares (set of secure packets), sends the shares to be stored on
servers (secure
-
IPR2015-01607 U.S. Patent No. 7,113,996
23
relays), and the servers then move the shares from server to
server every so often
in a process called trading. (Free Haven at 55, 59-60, 67-69
(EX1002); Tygar
91 (EX1006)). Free Haven also discloses that the publishing
server signs each of
the shares with a PK (first retrieval key), and that requesting
servers receive the
shares by broadcasting the PK (second retrieval key) to the
servnet servers. (Free
Haven at 59, 60 (EX1002)). Thus, in situations where a client
has not requested the
shares, and thus has not sent the PK (second retrieval key
associated ) of the
requested file, they would still be traded amongst servnet
servers. (Tygar 91
(EX1006)). Therefore, each of the servnet servers forward[s] the
set of secure
packets among secure relays so long as a second retrieval key
associated with the
first retrieval key is not received in the same multiple secure
relays. (Id. 91).
e) wherein said second retrieval key is created by the first or
second node
This limitation recites that the second node retrieval key is
created by the
first node or second node (emphasis added). As such, this
limitation does not
require that the second retrieval key be created by both the
first node and the
second node.
Free Haven discloses that a requesting server (second node)
broadcasts a
PK of a file requested by a client to all of the servers it
knows about. (Free Haven
at 60 (EX1002); Tygar 93 (EX1006)). Each server that receives
the PK will then
check to see whether it has any shares that contain the PK.
(Free Haven at 60
-
IPR2015-01607 U.S. Patent No. 7,113,996
24
(EX1002)). Thus, the PK is a second retrieval key that is
created by the
requesting server (second node). (Tygar 93 (EX1006)). Free Haven
also
discloses that an author can use his or her own server to
publish the file into the
servnet, and can be the same person that retrieves the file.
(Free Haven at 60
(EX1002)). Thus, the broadcast PK (second retrieval key) can
also be created by
the same server (first node) that published the file. (Tygar 94
(EX1006)).
f) forwarding the set of secure packets to the second node once
the second retrieval key is received in the said multiple secure
relays
Free Haven discloses that each server, upon receiving a PK
(second
retrieval key), checks to see if it has shares that contain the
PK. (Free Haven at 60
(EX1002)). If it does, it sends the share(s) to the requesting
servers address. (Id. at
60.) Thus, the servers (multiple secure relays) forward shares
of a given PK,
including encrypted shares (secure packets), to the requesting
server (second
node) when the requesting server requests shares having the PK
(once the second
retrieval key is received in said multiple secure relays).
(Tygar 96 (EX1006)).
6. Claim 15 is anticipated by Free Haven.
a) creating a second retrieval key in a second node
Free Haven discloses that a requesting server (second node)
broadcasts a
PK (second retrieval key) of a file requested by a client to all
of the servnet
servers it knows about. (Free Haven at 60 (EX1002); Tygar 99
(EX1006)). Thus,
-
IPR2015-01607 U.S. Patent No. 7,113,996
25
Free Haven discloses that the requesting server (second node)
creates the PK in
the broadcast message (creat[es] a second retrieval key). (Id.
99 (EX1006)).
b) wherein said second retrieval key is associated with
destination information for the set of secure packets and
information for identification of said first retrieval key
Free Haven discloses that a requesting server broadcasts a
message
including a PK (second retrieval key) of a requested file to
each of the servnet
servers of which it is aware. (Free Haven at 60 (EX1002); Tygar
101 (EX1006)).
The message includes (request, PKfile, PKclient, reply block).
(Free Haven at 60
(EX1002)). Each of the servnet servers that receives the message
then checks to
see whether it has any shares that contain the PK (first
retrieval key). (Id. at 60);
Tygar 101 (EX1006)). If it does, it forwards the share(s) to the
requesting server.
(Free Haven at 60 (EX1002)). That is, Free Haven discloses that
each servnet
server compares the broadcast PK with the PKs of shares stored
at the servnet
server to determine whether they match. (Id. at 79). Thus, the
broadcast PK
(second retrieval key) is associated with information (a public
key) for
identifying the PK (first retrieval key) of shares of a file
stored by servnet
servers. (Tygar 101 (EX1006)).
Free Haven also discloses that the broadcast message includes
both the PK
of the requested file, and a reply block address to use to
address the retrieved
shares to the requesting server. (Free Haven at 55, 60
(EX1002)). The shares are
-
IPR2015-01607 U.S. Patent No. 7,113,996
26
then sent to the requesting server based on the reply block
address. (Id.). Thus,
Free Haven discloses that the PK (second retrieval key) of the
broadcast
message is associated with the reply block address (destination
information) for
the encrypted shares (set of secure packets). (Tygar 102
(EX1006)).
c) transmitting said second retrieval key from the second node
to said multiple secure relays
Free Haven discloses that a requesting server (second node)
broadcasts
(transmit[s]) a PK (second retrieval key) of a file requested by
a client to all of
the servnet servers (secure relays) it knows about. (Free Haven
at 60 (EX1002);
Tygar 104 (EX1006).)
7. Claim 16 is anticipated by Free Haven.
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
Free Haven discloses that a requesting server (second node)
broadcasts a
PK of a requested file to all of the servnet servers of which it
is aware. (Free
Haven at 60 (EX1002); Tygar 107 (EX1006)). Each servnet server
that receives
the PK then checks to see whether it has any shares that contain
the PK. (Free
Haven at 60 (EX1002)). If it does, it sends the shares to the
requesting server. (Id.).
Free Haven discloses that once enough shares arrive at the
requesting server,
the requesting server recreates the file. (Free Haven at 60; see
also id. at 56-57, 79
(EX1002)). Free Haven also discloses that each share contains a
share number for
-
IPR2015-01607 U.S. Patent No. 7,113,996
27
recreating the file. (Id. at 66 (EX1002); Tygar 108 (EX1006)).
Thus, the
requesting server (second node) recreates the file by combining
the encrypted
shares (resequencing the set of secure packets to recreate the
message) based on
share numbers (based on resequencing information associated with
the set of
secure packets). (Tygar 108 (EX1006)).
B. Ground II: Claims 1 is obvious in view of DeSimone and
Munger. 1. Overview of DeSimone
As depicted in Figure 1 below, DeSimone discloses a multicast
capable
Internet Protocol (IP) data network (e.g., network 102 of Fig.
1). (DeSimone at
3:56-59 (EX1003)).
(DeSimone at Fig. 1 (EX1003)).
Client terminals (e.g., clients 101-1 101-5
of Fig. 1) may communicate with one
another in a multimedia conference by
transmitting and receiving multicast packets.
(DeSimone at Abstract & 3:56-59 (EX1003)). The multicast
packets are relayed
through the network using multicast routers (e.g., MRs 103-105
of Fig. 1).
(DeSimone at 3:64-67 & 4:1-8 (EX1003); Tygar 110-111
(EX1006)).
A client joins a conference by receiving a list of ongoing
conferences from a
Directory Server (e.g., Directory Server 106), selecting the
conference the client
-
IPR2015-01607 U.S. Patent No. 7,113,996
28
wishes to join, and authenticating to the conference with the
Directory Server.
(DeSimone at 5:51-67; 6:1-8; & Fig. 3 (EX1003)). Once
authenticated, the
Directory Server provides the client with a multicast socket
(e.g., a unique
multicast IP address and port number) to transmit on for each
media type (e.g.,
audio or video transmission), and a list of sockets for each
media type to receive on
from other clients participating in the conference. (DeSimone at
6:4-8 & Fig. 3
(EX1003)). The client selects sockets for each of the clients
from which it wishes
to receive. (DeSimone at 6:8-11 (EX1003)). The selected sockets
are then added to
the clients Multicast Receive Address List (MRAL), and the
multicast routers are
informed of the socket from which the client wishes to receive
packets. (DeSimone
at 4:35-54 (EX1003); Tygar 112 (EX1006)).
When participating in a conference, each multicast packet of a
media type
transmitted by a client includes that clients assigned socket.
(DeSimone at 3:27-36
(EX1003)). These multicast packets are then only routed to
clients requesting the
packets. (DeSimone at Abstract; 3:12-21, 39-40; 4:43-67; &
5:1-11 (EX1003);
Tygar 113 (EX1006)).
2. Claim 1 is obvious over DeSimone in view of Munger. a) [a]
secure transport system for transporting secure packets from a
first node to a second node
DeSimone discloses a multicast network over which clients
can
communicate in a multimedia conference. (DeSimone at Abstract
(EX1003)). A
-
IPR2015-01607 U.S. Patent No. 7,113,996
29
client communicating, and thereby transmitting packets, is a
first node. (Tygar
116 (EX1006)). A client listening or viewing the communications,
and thereby
receiving packets, is a second node. (Tygar 116 (EX1006)).
Before participating in a conference, and receiving multicast
packets from
other conference participants, a user must authenticate.
(DeSimone at 5:57-67; 6:1-
8; & Fig. 3 (EX1003)). That is, a client does not receive a
list of other participants,
and the sockets on which they transmit, until the clients user
has authenticated to
the Directory Server with a User ID and password. (DeSimone at
5:57-67; 6:1-8; &
Fig. 3 (EX1003)). If the user is not authenticated, the user is
precluded from
joining the conference. (DeSimone at 6:2-4 & Fig. 3
(EX1003)). Thus, the
conferences of DeSimone are secure, and the multicast conference
packets are
secure packets transported over a secure transport system from a
transmitting
conference client (first node) to a receiving conference client
(second node).
(Tygar 117 (EX1006)).
To the extent a narrow interpretation of the terms secure
transport system
and/or secure packets is taken, and to the extent one could
argue that DeSimone
does not disclose these terms, these terms were well-known at
the time the 996
Patent was filed (see VII.B.2.i below). (Tygar 118
(EX1006)).
b) a first node that creates secure packets, wherein each secure
packet contains identical retrieval information
-
IPR2015-01607 U.S. Patent No. 7,113,996
30
DeSimone discloses multicast routers that relay conference
multicast packets
(secure packets) between clients in a multicast capable IP
network. (DeSimone at
3:12-21, 39-40, 64-67; 4:1-5, 45-60; 5:8-11 (EX1003); Tygar 120
(EX1006)).
Each conference participants client terminal is assigned a
unique socket (port
number and multicast address) on which to transmit each media
type, and each
packet transmitted by the client thereafter includes the
assigned socket in its
header. (DeSimone at 3:27-36 (EX1003)). Other clients then
receive this clients
transmissions by selecting the clients assigned socket from a
list. (DeSimone at
6:8-15; see also id. at Abstract; 3:5-21, 34-40; 4:26-67;
5:1-11; 6:4-8 (EX1003)).
Thus, the transmitting conference terminal (first node) creates
multicast
conference packets (secure packets) that each contains the
assigned socket
(identical retrieval information). (Tygar 120 (EX1006)).
To the extent a narrow interpretation of the term secure packets
is taken,
and to the extent one could argue that DeSimone does not
disclose this term, this
term was well-known at the time the 996 Patent was filed (see
VII.B.2.i below).
(Tygar 121 (EX1006)).
c) multiple secure relays that receive secure packets and non
secure packets from multiple nodes or other secure relays
DeSimone discloses multicast routers that relay conference
multicast packets
(secure packets) between clients in a multicast capable IP
network. (DeSimone at
3:12-21, 39-40, 64-67; 4:1-5, 45-60; 5:8-11 (EX1003); Tygar 123
(EX1006)). If
-
IPR2015-01607 U.S. Patent No. 7,113,996
31
a user has authenticated to a conference and selects a
conference participants
socket, the users client informs the multicast routers that the
client wishes to
receive packets including the socket. (DeSimone at 4:43-60
(EX1003)). Users who
have not authenticated with the Directory Server for a
conference are precluded
from joining the conference and receiving the conference
packets. (DeSimone at
6:2-4 (EX1003); Tygar 123 (EX1006)). Accordingly, the multicast
routers are
secure relays. (Tygar 123 (EX1006)).
DeSimone also discloses that potential conference participants
contact the
Directory Server by sending a packetized request. (DeSimone at
5:51-57
(EX1003)). This occurs before the potential conference
participant authenticates
with the Directory Server. (DeSimone at 5:57-67; 6:1-11; &
Fig. 3 (EX1003)).
Similarly, a conference originator sends a packetized request to
the Directory
Server to create a conference before authenticating with the
Directory Server.
(DeSimone at 5:12-33 (EX1003)). These packetized requests sent
from potential
conferees and originators are not conference packets and are
thus non secure
packets. (Tygar 124 (EX1006)).
In order to route conference packets between certain clients
(e.g., clients
101-1 101-5), and to route non conference packets between
clients and the
Directory Server, the packets travel through multiple multicast
routers. (DeSimone
at Fig. 1 (EX1003); Tygar 125 (EX1006)). Thus, the multicast
routers are
-
IPR2015-01607 U.S. Patent No. 7,113,996
32
multiple secure relays that receive secure packets and non
secure packets from
multiple nodes or other secure relays. (Tygar 125 (EX1006)).
To the extent a narrow interpretation of the terms secure
relays, secure
packets, and/or non secure packets is taken, and to the extent
one could argue
that DeSimone does not disclose these terms, these terms were
well-known at the
time the 996 Patent was filed (see VII.B.2.i below). (Tygar 126
(EX1006)).
d) wherein said multiple secure relays are capable of
identifying retrieval information in each secure packet
DeSimone discloses that multicast routers only forward multicast
packets
with a specific socket to sub-networks of clients that have
selected the socket.
(DeSimone at 4:32-60; see also id. at Abstract; 3:5-21, 27-40;
4:61-67; 5:1-11
(EX1003)). Thus, the multicast routers (secure relays) are
capable of identifying
a socket (retrieval information) in each multicast packet
(secure packet).
(Tygar 128 (EX1006)).
To the extent a narrow interpretation of the terms secure relays
and/or
secure packets was taken, and to the extent one could argue that
DeSimone does
not disclose these terms, these terms were well-known at the
time the 996 Patent
was filed (see VII.B.2.i below). (Tygar 129 (EX1006)).
e) wherein each of said multiple secure relays forwards secure
packets to another of said multiple secure relay and forwards
non-secure packets to destination relays
-
IPR2015-01607 U.S. Patent No. 7,113,996
33
As noted above in VII.B.2.c., DeSimone discloses multicast
conference
packets (secure packets) and packetized requests (non secure
packets) from
unauthenticated clients. (Tygar 131 (EX1006)). Multicast
conference packets are
routed through multicast routers to each of the clients that has
elected to receive
them. (DeSimone at 3:64-67; see also id. at Abstract 3:12-21,
34-40; 4:45-67; 5:1-
11, 43-46 (EX1006)). Thus, as shown in Figure 1 of DeSimone, if
client 101-1
were transmitting multicast packets, and clients 101-2, 101-3,
and 101-5 had
elected to receive them, the packets would have to be sent
through multicast
routers 103, 104, and 105 for the clients to receive the
packets. (DeSimone at Fig. 1
(EX1003); Tygar 131 (EX1006)). Accordingly, each of the
multicast routers
(secure relays) forwards multicast packets (secure packets) to
another of the
multicast routers (another of said secure relay). (Tygar 131
(EX1006)).
By contrast, the Directory Server does not need to operate in a
multicast
fashion, and can be connected to the network through a router
which is not
multicast capable. (DeSimone at 4:5-8 (EX1003)). Thus,
packetized requests to the
Directory Server, and responses from the Directory Server, are
not multicast
packets. (Id. at 4:5-8; 5:12-67; 6:1-8; Figs. 2-3); Tygar 132
(EX1006)). Instead,
these requests are routed directly to the Directory Server, and
the Directory
Servers responses are routed directly to the client with which
it is communicating.
(Tygar 132 (EX1006)). Thus, the router (e.g., R of Fig. 1)
connected to the
-
IPR2015-01607 U.S. Patent No. 7,113,996
34
Directory Server, and the multicast router connected to the
client with which it is
communicating, are destination relays. (Tygar 132 (EX1006)). As
illustrated in
Figure 1, multicast routers disposed between these routers may
relay messages
through the network. (Id. at 132). These multicast routers are
secure relays that
forward non-secure packets to destination relays. (Id. at.
132).
To the extent a narrow interpretation of the terms secure
relays, secure
packets, non-secure packets, and/or destination relays is taken,
and to the
extent one could argue that DeSimone does not disclose these
terms, these terms
were well-known at the time the 996 Patent was filed (see
VII.B.2.i below).
(Tygar 133 (EX1006)).
f) end4 wherein said multiple secure relays forward secure
packets to the second node when a retrieval condition has been
indicated
DeSimone discloses that multicast routers (secure relays)
forward
multicast conference packets (secure packets) to a client
(second node) when
the client has elected to receive the packets (when a retrieval
condition has been
indicated). (DeSimone at Abstract; 3:5-21, 27-40; 4:35-67;
5:1-11; 6:4-15
(EX1003); Tygar 135 (EX1006)).
4 It appears the term and was mistakenly changed to the word end
when the
996 Patent issued. (See File History, Suppl. Response at 2
(EX1014)).
Accordingly, the term is treated as being and herein.
-
IPR2015-01607 U.S. Patent No. 7,113,996
35
To the extent a narrow interpretation of the terms secure relays
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 136 (EX1006)).
g) wherein each of said multiple secure relays forwards secure
packets to another of said multiple secure relays when the
retrieval condition has not been indicated
DeSimone discloses that multicast conference packets are routed
through
multicast routers in the network to each of the clients that has
elected to receive the
packets. (DeSimone at 3:64-67; see also id. at Abstract;
3:12-21, 34-40; 4:43-67;
5:1-11 (EX1006)). Thus, as shown in Figure 1, if client 101-1
were transmitting
multicast conference packets, and client 101-5 had elected to
receive those packets,
the packets would be routed through multicast routers 103 and
105. (DeSimone at
Fig. 1; Tygar 138 (EX1006)).
If in the above example clients 101-3 and 101-4 had not elected
to receive
the packets, the packets would not be routed through multicast
router 104.
(DeSimone at 4:43-67; 5:1-11; see also id. at Abstract; 3:12-21,
34-40 (EX1006);
Tygar 139 (EX1006)). This example illustrates that, with the
network
configuration disclosed by DeSimone, each of the multicast
routers (secure
relays) is configured to forward the multicast conference
packets (secure
packets) to another multicast router (another of said multiple
secure relays) to
-
IPR2015-01607 U.S. Patent No. 7,113,996
36
service requesting clients, even when a client on another
sub-network has not
elected to receive the packets (when the retrieval condition has
not been
indicated). (Id. 139).
To the extent a narrow interpretation of the terms secure relays
and/or
secure packets is taken, then 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 140 (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
DeSimone discloses that a client only receives multicast
conference packets
of other clients from which the client elects to receive.
(DeSimone at Abstract, 3:5-
21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003)). The
client makes this
election by selecting a socket of the other client whose packets
it wishes to receive.
(Id. at Abstract, 3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; &
6:4-15). This socket is
then added to the electing clients Multicast Routing Address
List (MRAL), and
the multicast routers are informed of the socket elected for
this client. (Id. at 4:35-
67; 5:1-11; & 6:4-15); Tygar 142 (EX1006)). Thus, DeSimone
discloses an
electing client (second node) that selects a socket (creates a
retrieval condition
related to said retrieval information in said multiple secure
packets) and then
receives the multicast packets including the socket (receives
the secure packets).
(Tygar 142 (EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
37
To the extent a narrow interpretation of the term secure packets
was taken,
and to the extent one could argue that DeSimone does not
disclose this element,
this element was well-known at the time the 996 Patent was filed
(see VII.B.2.i
below). (Tygar 143 (EX1006)).
i) secure transport system, secure packet, secure relay, non
secure packet, and/or secure distributed storage system
As described in VII.B.2a-h above, DeSimone discloses all of the
elements
of claim 1. However, if a narrow interpretation of the terms
secure and/or non
secure is taken, and to the extent one could argue that DeSimone
does not disclose
elements containing these terms, such as a secure transport
system, a secure
packet, a secure relay, a non
secure packet, and/or a secure
distributed storage system, those
elements were well known at the time
the 996 Patent was filed. (Tygar 144
(EX1006)). For example, Munger
discloses a secure system (secure
transport system or secure
distributed storage system) for communicating over a public
network and that can
be used for multicast communications. (Munger at 2:64-67; 3:1;
& 24:32-34
-
IPR2015-01607 U.S. Patent No. 7,113,996
38
(EX1004); Tygar 145 (EX1006)). Figure 2 (above) illustrates an
example of the
secure system. (Munger at 5:66-67 (EX1004); Tygar 145
(EX1006)).
(Munger at Fig. 2 (EX1004)).
As illustrated in Figure 2, the network of Munger includes
regular IP routers
(e.g., IP routers 128-132) and special IP routers, called
Tunneled Agile Routing
Protocol (TARP) routers (e.g., TARP routers 122-127) (secure
relays). (Munger
at 2:64-67; 6:59-64; & Fig. 2 (EX1004); Tygar 146 (EX1006)).
Munger discloses
encrypting packets (secure packets) transmitted between TARP
routers. (Munger
at 2:1-67; 3:1-6 (EX1004); Tygar 146 (EX1006)).
TARP packets look like normal IP packets, and TARP routers use
normal IP
protocol to send messages. (Munger at 6:59-67; 7:1 (EX1004)).
However, TARP
packets are encrypted, and their true destinations are concealed
except to TARP
routers and servers. (Id. at 2:67; 3:1-6). That is, while a
normal IP packet (non
secure packet) has a header indicating a final destination for
the packet, TARP
packets (secure packets) have IP headers that point to a
next-hop in a series of
TARP router hops until reaching the final destination. (Munger
at 3:9-16; 6:65-67;
7:1-5 (EX1004); Tygar 147 (EX1006)). As illustrated in Figure 2
above, because
they look the same, regular IP routers and TARP routers can
relay both regular IP
packets and TARP packets. (Munger at Fig. 2; see also id. at
2:67; 3:1-16; 4:12-14,
-
IPR2015-01607 U.S. Patent No. 7,113,996
39
56-67; 6:59-67; 7:1-10; 8:64-65; & 10:5-7, 19-27, 46-57
(EX1004); Tygar 147
(EX1006)).
In the system of Munger, messages are broken into multiple
pieces, and
encrypted into TARP packets. (Munger at 3:42-44, 56-61, 66-67;
4:1-22
(EX1004)). Each TARP packet is then sent through a minimum
number of hops.
(Munger at 3:29-31 (EX1004)). The hops may be chosen at random,
and each
packet may take an independent route to reach its destination.
(Munger at 3:29-42
(EX1004); Tygar 148 (EX1006)).
In sum, Munger discloses a secure communications system (secure
transport
system or secure distributed storage system) that sends TARP
packets (secure
packets) and regular IP packets (non-secure packets) through
TARP routers
(secure relays) and regular IP routers. (Tygar 149 (EX1006)).
TARP packets
have hidden destination addresses and are forwarded through TARP
routers a
certain number of times (forward[ed] . . . to another of said
multiple secure
relay), while regular IP packets (non-secure packets) have the
destination
addresses in their header and routed directly to their
destination (forward[ed] . . .
to destination relays). (Id. 149).
To a POSA at the time the 996 Patent was filed, it would have
been obvious
to modify the multicast capable Internet network of DeSimone to
encrypt the
multicast conference packets, and to transmit the packets
through secure routers
-
IPR2015-01607 U.S. Patent No. 7,113,996
40
that are capable of handling both encrypted packets and
non-encrypted packets,
such as taught by Munger. (Tygar 150 (EX1006)). A POSA would
have been
motivated to use Mungers encryption and TARP routing techniques
to encrypt and
route multicast IP packets in the multicast IP network of
DeSimone, so as to add
greater security to private conference transmissions and greater
anonymity to
conference participants. (Munger at 1:13-15, 21-23 & 7:5-10
(EX1004); Tygar
150 (EX1006)). Further, use of Mungers encrypted packets and
TARP routers
would have been a combination of old elements in which each
element would
perform as expected to yield the predictable results of adding
increased security
and anonymity to network communications. (Id. 150).
C. Claims 2, 3, and 14-16 are Obvious in view of DeSimone,
Munger, and Francis
1. Overview of DeSimone
An overview of DeSimone is provided in VII.B.1.
2. Claim 2 is obvious in view of DeSimone, Munger, and
Francis
a) wherein the second node creates a retrieval condition by
generating a unique identifying flag that identifies said multiple
secure packets that contain the same retrieval information
DeSimone discloses that a client only receives multicast
conference packets
of other clients from which the client elects to receive.
(DeSimone at Abstract, 3:5-
21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003)). The
client makes this
election by selecting a socket of another client. (Id. at
Abstract, 3:5-21, 27-40, 64-
-
IPR2015-01607 U.S. Patent No. 7,113,996
41
67; 4:28-67; 5:1-11; & 6:4-15). This socket is then added to
the electing clients
MRAL, and the electing client informs the multicast routers of
the election by
positively responding to a query from a multicast router. (Id.
at 4:35-67; 5:1-11; &
6:4015); Tygar 154 (EX1006)). Thus, DeSimone discloses an
electing client
(second node) that selects a socket to receive multicast packets
including the
socket (creates a retrieval condition by generating a unique
identifying flag that
identifies said multiple secure packets that contain the same
retrieval information).
(Id. 154).
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 above)
(Tygar 155 (EX1006)).
b) wherein said second node transmits said identifying flag to
said multiple secure relays to initiate transmission of said
multiple secure packets to said second node
DeSimone discloses that when a client elects a socket of another
client whose
packets it wishes to receive, the socket is added to the
electing clients MRAL, and
the electing client informs the multicast routers of the elected
socket by positively
responding to a query from a multicast router. (DeSimone at
Abstract, 3:5-21, 27-
40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003); Tygar 157
(EX1006)). Referring
to Figure 1, DeSimone provides an example where the users at
clients 101-3, 101-
-
IPR2015-01607 U.S. Patent No. 7,113,996
42
4, and 101-5 elect to not receive video signals from clients
101-1 and 101-2.
(DeSimone at 5:4-6 (EX1003)). Multicast video packets
transmitted by clients 101-
1 and 101-2 are thus not routed by multicast router 103, and
remain only within the
sub-network common to clients 101-1 and 101-2. (Id. at 5:8-11);
Tygar 157
(EX1006)).
A POSA would recognize that, if client 101-5 later elects to
receive video
signals from clients 101-1 or 101-2, the requested socket would
have to be
conveyed through multicast router 105 to multicast router 103,
so that multicast
router 103 can route the packets through multicast router 105 to
client 101-5.
(DeSimone at 4:35-67; 5:1-11; Fig. 1; see also id. at Abstract,
3:5-21, 27-40, 64-
67; 4:1-5 (EX1003); Tygar 158 (EX1006)). Thus, a POSA would
recognize that
DeSimone discloses that the electing node (second node)
transmits the requested
socket (identifying flag) to multiple multicast routers
(multiple secure relays)
to receive multicast packets including the socket (to initiate
transmission of said
multiple secure packets to said second node). (Tygar 158
(EX1006)).
However, to the extent it could be argued that DeSimone does not
disclose
that the requested socket is conveyed through multiple multicast
routers, such a
feature was well-known at the time the 996 Patent was filed.
(Id. 159). For
example, Francis discloses a system and method for transmitting
multicast packets
to members of a multicast group. (Francis at Abstract (EX1005)).
Each of the
-
IPR2015-01607 U.S. Patent No. 7,113,996
43
multicast packets transmitted to a multicast group includes a
multicast address of a
core node. (Id. at 6:25-30). If a node wishes to join the
multicast group, it transmits
a control packet including a join request message and the
multicast address
(identifying flag) of the core node, and this packet is
transmitted via
intermediary nodes (to said multiple secure relays) until
reaching a node that is
part of the multicast tree. (Id. at 6:55-65); Tygar 159
(EX1006)).
To a POSA at the time the 996 Patent was filed, it would have
been obvious
to modify the multicast Internet network of DeSimone so that,
when a client wishes
to join a multicast group, rather than having a multicast router
query the client, the
client sends a packet including the requested socket through
intermediary multicast
routers until the packet reaches a multicast router that is part
of the multicast tree,
such as that taught by Francis. (Tygar 160 (EX1006)). A POSA
would have been
motivated to use Francis techniques for joining a multicast
tree, to reduce the
amount of resources required to manage multicast trees. (Id.
160); see also
Francis at 5:13-28 (EX1005)). Further, use of Francis technique
for joining a
multicast tree would have been a combination of old elements in
which each
element performed as expected to yield the predictable results
of reducing the
amount of information that needs to be stored in multicast
routers in a network.
(Tygar 160 (EX1006)).
-
IPR2015-01607 U.S. Patent No. 7,113,996
44
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 element,
this element was well-known at the time the 996 Patent was filed
(see VII.B.2.i
above) (Tygar 161 (EX1006)).
c) wherein said first or second nodes may create said retrieval
condition
This limitation recites that the first or second nodes may
create said retrieval
condition (emphasis added). Thus, this limitation does not
require that both the
first and the second nodes be capable of creating the retrieval
condition.
As noted above in VII.C.2.a, DeSimone discloses that a client
(second
node) wishing to receive multicast packets of another client
selects the socket
(creates the retrieval condition) of the other client. (DeSimone
at 3:5-21, 27-40,
64-67; 4:28-6; 5:1-11; & 6:4-15; Tygar 164 (EX1006)).
3. Claim 3 is Obvious in view of DeSimone, Munger, and
Francis
a) wherein the second node successively forwards multiple
identical retrieval packets to said multiple secure relays, wherein
each retrieval packet indicates the retrieval condition for secure
packets
DeSimone discloses that, when a client elects a socket of
another client
whose packets it wishes to receive, the socket is added to the
electing clients
MRAL, and the electing client informs the multicast routers of
the elected socket
by positively responding to a query from a multicast router.
(DeSimone at Abstract,
3:5-21, 27-40, 64-67; 4:28-67; 5:1-11; & 6:4-15 (EX1003);
Tygar 167
(EX1006)). For example, a POSA would recognize that, in the
example provided
-
IPR2015-01607 U.S. Patent No. 7,113,996
45
in VII.C.2.b, if client 101-5 is not receiving video multicast
packets from clients
101-1 or 101-2, but later elects to receive video signals from
clients 101-1 or 101-
2, the socket request (retrieval packet) would have to be
conveyed through
multicast router 105 to multicast router 103, so that multicast
router 103 can route
the packets through multicast router 105 to client 101-5.
(DeSimone at 4:35-67;
5:1-11; Fig. 1; see also id. at Abstract; 3:5-21, 27-40, 64-67;
4:1-5 (EX1003);
Tygar 167 (EX1006)).
Moreover, DeSimone discloses that, at any time during a
conference, a client
may choose to receive or not receive multicast packets from
another client.
(DeSimone at 4:35-54 (EX1003)). A POSA would recognize that, for
each time a
client elects to receive multicast packets from a client, it
would send a positive
response to the multicast query for that socket. (Tygar 168
(EX1006)). Thus, a
POSA would recognize that, if a client were to choose to receive
packets from a
particular client, then were to choose not to receive those
packets, and then were to
again choose to receive the packets, the client would
successively respond
positively to the multicast query regarding the multicast
socket. (Id. 168
(EX1006).
Thus, a POSA would recognize DeSimone as disclosing that the
electing
node (second node) causes the positive response to be conveyed
to multiple
multicast routers (successively forwards multiple identical
retrieval packets to
-
IPR2015-01607 U.S. Patent No. 7,113,996
46
said multiple secure relays, wherein each retrieval packet
indicates the retrieval
condition for secure packets). (Id. 169)
However, to the extent it could be argued that DeSimone does not
disclose
that the requested socket is conveyed through multiple multicast
routers, or that
DeSimone does not disclose that the multiple identical retrieval
packets are
forwarded to the multicast routers, such a feature was
well-known at the time the
996 Patent was filed. (Id. 170).
For example, Francis discloses a system and method for
transmitting
multicast packets to members of a multicast group. (Francis at
Abstract
(EX1005)). Each of the multicast packets transmitted to a
multicast group includes
a multicast address of a core node. (Id. at 6:25-30). If a node
wishes to join the
multicast group, it transmits a control packet including a join
request message and
the multicast address of the core node, and this packet is
re-transmitted via
intermediary nodes until reaching a node that is part of the
multicast tree. (Id. at
6:55-65); Tygar 171 (EX1006)). A POSA would recognize that, each
time a node
requests to join the multicast tree, it would have to send this
control packet, and
would thus, successively forward[] multiple identical control
packets (multiple
retrieval packets) via intermediary nodes (to said multiple
secure relays), where
each control packet (retrieval packet). (Id. 171). Moreover, a
POSA would
recognize that each control packet indicates a request for
multicast packets (a
-
IPR2015-01607 U.S. Patent No. 7,113,996
47
retrieval condition) and that each control packet includes a
multicast address
(flag) that instructs the intermediary nodes to identify the
multicast packets that
contain the multicast address (identify packets that contain the
same retrieval
information). (Id. 171).
To a POSA at the time that the 996 Patent was filed, it would
have been
obvious to modify the multicast Internet network of DeSimone so
that, when a
client wishes to join a multicast group, rather than having a
multicast router query
the client, the client sends a packet including the requested
socket through
intermediary multicast routers until the packet reaches a
multicast router that is
part of the multicast tree, such as that taught by Francis. A
POSA would have been
motivated to use Francis techniques for joining a multicast
tree, to reduce the
amount of resources required to manage multicast trees. (Id.
172); see also
Francis at 5:13-28 (EX1005)). Further, use of Francis technique
for joining a
multicast tree would have been a combination of old elements in
which each
element performed as expected to yield the predictable results
of reducing the
amount of information that needs to be stored in multicast
routers in a network.
(Tygar 172 (EX1006)).
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 element,
-
IPR2015-01607 U.S. Patent No. 7,113,996
48
this element was well-known at the time the 996 Patent was filed
(see VII.B.2.i
above). (Tygar 173 (EX1006)).
b) wherein each said retrieval packet contains a flag that
instructs said multiple secure relays to identify secure packets
that contain the same retrieval information
As noted above in VII.C.3.a, DeSimone discloses that a positive
response
for a socket is conveyed to the multicast routers. (Tygar 175
(EX1006)). The
response informs the multicast routers to forward multicast
packets including the
socket to the requesting client. (DeSimone at 4:43-67; 5:1-11;
see also id. at
Abstract; 3:5-21, 34-40, 64-67; 4:26-42 (EX1003); Tygar 175
(EX1006)). Thus,
each response contains a socket (flag) instructing the multicast
routers (multiple
secure relays) to identify multicast packets (secure packets)
containing the
socket (that contain the same retrieval information). (Id.
175).
To the extent a narrow interpretation of the terms secure
packets and/or
secure relays is taken, and to the extent one could argue that
DeSimone does not
disclose these terms, these terms were well-known at the time
that the 996 Patent
was filed (see VII.B.2.i above). (Tygar 176 (EX1006)).
4. Claim 14 is Obvious in view of DeSimone, Munger, and
Francis
a) [a] method for maintaining a secure distributed storage
system by initiating a transmission of a message from a first node
to a second node in a secure manner, wherein the second node may be
the first node, comprising the steps, executed in a data processing
system
-
IPR2015-01607 U.S. Patent No. 7,113,996
49
This limitation recites that the second node may be the first
node (emphasis
added). As such, the limitation does not require that the second
node be the first
node.
DeSimone discloses a multicast network, over which clients
can
communicate audio and video (messages) in a multimedia
conference.
(DeSimone at Abstract; 4:61-67; & 5:1-11 (EX1003)).
Multicast conference
packets are routed to clients in the multicast network through
multicast routers
(e.g., MRs 103-105). (DeSimone at 3:12-21, 39-40,, 64-67; 4:1-5,
45-60; 5:8-11
(EX1003); Tygar 180 (EX1006)). Similar to the 996 Patent (see
996 Patent at
2:28-33; 3:44-50), multicast packets of DeSimone are stored as
they are routed
through the distributed network. (DeSimone at 3:56-67; 4:1-5;
& Fig. 1 (EX1003);
Tygar 180 (EX1006)). Thus, DeSimone discloses a distributed
storage system.
(Tygar 180 (EX1006)).
A client communicating in a conference, and thereby transmitting
packets, is
a first node. (Tygar 181 (EX1006)). A client listening in the
conference, and
thereby receiving packets, is a second node. (Tygar 181
(EX1006)).
As noted in VII.C.2.a, a user must authenticate before being
able to receive
multicast packets from other conference participants. (DeSimone
at 5:57-67; 6:1-8;
& Fig. 3 (EX1003)). If the user is not authenticated, the
user is precluded from
joining the conference. (DeSimone at 6:2-4 & Fig. 3
(EX1003)). Thus, the
-
IPR2015-01607 U.S. Patent No. 7,113,996
50
conference packets of DeSimone are transmitted in a secure
manner, and the
distributed storage system is secure. (Tygar 182 (EX1006)).
Moreover, the
processes of DeSimone are carried out in a system (data
processing system) that
includes a multicast capable IP network, client terminals, and a
Directory Server.
(DeSimone at 3:56-67; 4:1-8; & Figs. 1-3 (EX1003); Tygar 182
(EX1006)).
To the extent a narrow interpretation of the terms secure
distributed storage
system and/or transmitting . . . a message . . . in a secure
manner is taken, and to
the extent one could argue that DeSimone does not disclose these
terms, these
terms were well-known at the time the 996 Patent was filed (see
VII.B.2.i
above). (Tygar 183 (EX1006)).
b) creating a set of secure packets associated with the message,
wherein each secure packet contains an identical first retrieval
key, wherein the first retrieval key is created by the first
node
As noted in VII.C.2.a, DeSimone discloses multicast routers that
relay
multicast packets (secure packets) between clients in a network.
(Tygar 185
(EX1006)). Each conference participants client is assigned a
unique socket on
which to transmit each media type, and each packet transmitted
by the terminal
thereafter includes the assigned socket in its header. (DeSimone
at 3:27-36
(EX1003)). Other clients then receive this clients transmissions
by selecting the
clients assigned socket. (id. at 6:8-15; see also id. at
Abstract; 3:5-21, 34-40; 4:26-
67; 5:1-11). Thus, the transmitting client (first node) creates
multicast
-
IPR2015-01607 U.S. Patent No. 7,113,996
51
conference packets (a set of secure packets) associated with an
media
transmission (a message), where each of the multicast conference
packets
contains the assigned socket (contains an identical first
retrieval key, wherein the
first retrieval key is created by the first node). (Tygar 185
(EX1006)).
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 above).
(Tygar