active 88090184 4 dr. forys dec iso second ipr on 048 patent · 2017-03-22 · university of...

EXHIBIT 1021

Expert Declaration of Dr. Leonard J Forys for Inter Partes Review of US Patent No. 7,406,048

-1-

` EXPERT DECLARATION OF DR. LEONARD J FORYS

FOR INTER PARTES REVIEW OF U.S. PATENT NO. 7,406,048

Viptela, Inc. - Exhibit 1021 Page 1


TABLE OF CONTENTS

-2-

I. INTRODUCTION .......................................................................................... 3

II. QUALIFICATIONS ....................................................................................... 7

III. PERSON OF ORDINARY SKILL IN THE ART ....................................... 15

IV. LEGAL UNDERSTANDING ...................................................................... 17

V. THE ‘048 PATENT ...................................................................................... 24

VI. CLAIM CONSTRUCTION ......................................................................... 35

VII. STATE OF THE ART .................................................................................. 39

VIII. OBVIOUSNESS OF CLAIMS 1, 3-7, 9-13, AND 15-24 OF THE ‘048 PATENT UNDER 35 U.S.C. § 103 ..................................................... 79

IX. CONCLUSION ........................................................................................... 211



-3-

I. INTRODUCTION

1. I, Dr. Leonard J Forys, submit this declaration in support of a Petition

for Inter Partes Review of United States Patent No. 7,406,048 (“the ‘048

Patent”), owned by FatPipe Networks India Limited (“Fatpipe” or “Patent

Owner”). I have been retained in this matter by McGuire Woods (“Counsel”) on

behalf of Viptela, Inc. (“Petitioner”). I understand that Petitioner Viptela is the

Real Party-in-Interest to this Petition. Viptela is a leading provider of Software

Defined WAN (SD-WAN) solutions that proactively manage capacity, reliability

and performance.

2. I make this declaration based upon my personal knowledge. I am over

the age of 21 and am competent to make this declaration.

3. The statements herein include my opinions and the bases for those

opinions, which relate to at least the following documents of the pending inter

partes review petition:

U.S. Patent No. 6,775,235 by Sanchaita Datta and Ragula Bhaskar

entitled “Tools and Techniques for Directing Packets over Disparate

Networks” (“the ‘235 Patent”) (Ex. 1001).

File History for U.S. Patent No. 6,775,235 (Ex. 1002).



-4-

U.S. Patent No. 7,406,048 by Sanchaita Datta and Ragula Bhaskar

entitled “Tools and Techniques for Directing Packets over Disparate

Networks” (“the ‘048 Patent”) (Ex. 1003).

File History for U.S. Patent No. 7,406,048 (Ex. 1004).

U.S. Patent No. 6,628,617 by Mark John Karol and Malathi

Veeraraghavan entitled “Technique for Interconnecting Traffic on

Connectionless and Connection-Oriented Networks” (“Karol”) (Ex.

1006).

TCP/IP Illustrated Volume 1, The Protocols by W. Richard Stevens,

Addison-Wesley Professional Computing Series, 1994, ISBN 0-201-

63346-9, (“Stevens”) (Excerpts provided in Ex. 1007).

Petition for Inter Partes Review, IPR2016-00977, Paper No. 1 (April 29,

2016) (Ex. 1009).

Decision, IPR2016-00977, Paper No. 7 (November 2, 2016) (Ex. 1010).

Data and Computer Communications by William Stallings, Prentice-

Hall, 5th Edition, 1997, ISBN-81-203-1240-6, (“Stallings”) (Excerpts

provided in Ex. 1011).

Fatpipe’s proposed modifications to the claim construction (Ex. 1014).

U.S. Patent No. 6,317,431 by Terence G Hodgkinson and Alan W O'Neill

entitled “ATM Partial Cut-Through” (“Hodgkinson”) (Ex. 1015).



-5-

PLAINTIFF FATPIPE, INC.’S PATENT RULE 3-1 DISCLOSURE OF

ASSERTED CLAIMS AND INFRINGEMENT CONTENTIONS (Ex.

1016).

U.S. Patent No. 6,396,833 to Shujin Zhang et al. entitled “Per User and

Network Routing Tables” (“Zhang”) (Ex. 1017)

U.S. Patent Publication No. 2002/0010866 by David J. McCullough et al.

entitled “Method and Apparatus for Improving Peer-to-Peer Bandwidth

Between Remote Networks by Combining Multiple Connections Which

Use Arbitrary Data Paths” (“McCullough”) (Ex. 1018)

U.S. Patent No. 5,910,951 by Michael David Pearce, Rodd Bryan

Zurcher, and Lewis B. Oberlander entitled “Transmitting Device with

Mobility Manager and Method of Communicating” (“Pearce”) (Ex.

1019)

Patent Owner Response, IPR2016-00977, Paper No. 22 (February 8,

2017) (Ex. 1020).

4. My materials considered for forming my opinions herein have

included at least the above-referenced documents.

5. Although I am being compensated for my time at a rate of $400 per

hour in preparing this declaration, the opinions herein are my own, and I have no



-6-

stake in the outcome of the review proceeding. My compensation does not

depend in any way on the outcome of the Petitioner’s petition.



-7-

II. QUALIFICATIONS

6. I am qualified by education and experience to testify as an expert in

the field of telecommunications. Attached, as Attachment A, is a copy of my

resume detailing my experience and education. Additionally, I provide the

following overview of my background as it pertains to my qualifications for

providing expert testimony in this matter.

7. I received (1) a Bachelor of Science Degree in electrical engineering

from the University of Notre Dame in 1963, (2) a Master of Science Degree in

Electrical Engineering from the Massachusetts Institute of Technology in 1965

(3) a degree of Electrical Engineering also from the Massachusetts Institute of

Technology in 1965 and (4) a Doctor of Philosophy Degree in Electrical

Engineering and Computer Science from the University of California at Berkeley

in 1968. While at Berkeley, I was an Assistant Professor of Electrical

Engineering and Computer Science and my responsibilities included: teaching

courses in network theory, systems theory and communications theory, doing

research in communications systems and serving as faculty advisor to 20

undergraduates.

8. Work Experience

9. I initially began my training in Control Theory with Aerospace

Applications and worked for a while at NASA as an Aerospace Engineer. I then



-8-

changed fields, specializing in communications theory. After completing my

education, I began working for 27 years at the nation’s top telecommunications

companies and an additional 21 years as a private consultant for my own

company.

10. From 1968 to 1973, I was a member of the technical staff at Bell

Telephone Laboratories where I was engaged in various research activities

involving network engineering and performance management in telephone

networks. I also taught several in-house courses in performance analysis and

traffic engineering in telephone networks, including several examples from data

networks.

11. From 1973 to 1984, I was Technical Supervisor at Bell Telephone

Laboratories, heading a small group of technical experts primarily Ph.D.s. My

responsibilities included performance management/analysis and development of

traffic engineering algorithms for various telecommunications networks and their

components, primarily voice switches and PBXs. I was also engaged as a

troubleshooter to uncover root causes of switch and network problems.

12. From 1984 to 1994, I was District Manager for Bell Communications

Research (Bellcore), heading a group of 7 to 15 technical experts, primarily

Ph.D.s. My responsibilities included the data network engineering algorithms for

all of the Regional Bell Operating Companies (RBOCs) as well as the



-9-

engineering of voice switches. In particular, I was responsible for the

engineering performance specification and testing of most of the voice network

and data network components being purchased by the RBOCs, including several

security features such as VPN and closed user groups. This included writing

sections of the requirements used by the regional Bell Operating Companies

(Verizon, SBC, etc.) to buy network components in their networks. I tested the

compliance (to the requirements) of several voice switches made by AT&T,

Nortel, Lucent, Ericsson, Fujitsu, NET and Siemens, as well as data network

routers (suitable for X.25, Frame Relay, TYMNET, Asynchronous Transfer

Mode (ATM) networks, and ISDN data implementations) from these and other

suppliers. I also participated and contributed to various national and international

voice and data standards organizations (such as T1 and ITU). One of my

specialties was network management, for both voice and data networks. This

included devising strategies to allow government agencies to cope with massive

outages.

13. I was a leader in developing novel traffic engineering methods for

Internet data networks. This included characterizing Internet traffic and

developing loading guidelines for network components including routers and

switches. During this period, Bellcore tested the voice over packet capabilities of

several products, including Internet routers.



-10-

14. I was Bellcore’s prime technical leader for determining root causes

(and also proposed solutions) in several Signaling System Number 7 (SS7) data

network outages, including the famous 1990 AT&T nationwide outage, as well as

the 1991 Washington DC, Kansas City and Los Angeles outages. I was

responsible for writing new sets of requirements for SS7 networks and was

involved in a large scale testing and analysis program for a wide variety of SS7

network components.

15. Additionally, I was involved in analyzing the engineering impacts of

various Advanced Intelligent Network (AIN) features such as automatic call

back, which made use of the SS7 infrastructure. I analyzed the potential impact

of earthquakes and other natural disasters on telecommunications network

performance. The National Science Foundation sponsored me to be the sole U.S.

telecommunications industry representative at the First International Joint U.S.-

Japan Earthquake Symposium in 1993.

16. Primarily because of my success in these activities, I was named a

Bellcore Fellow in 1992, only the fifth person to receive such an award.

17. In 1989, I was an Invited Professor of Applied Mathematics at the

University of Adelaide in Australia. I taught two courses in teletraffic models,

one for Ph.D. students emphasizing theory and one for industry students

emphasizing applications in both voice and data networks.



-11-

18. From 1994 to 1995, I was a Chief Scientist at Bell Communications

Research, overseeing the technical work of 50 technical experts, many of whom

had PhDs. Relevant to the subject matter of these cases I was involved in the

teaching of teletraffic engineering and performance management to various

bodies, including the FCC, which included aspects of both voice and data

networks. I served as a “trouble shooter,” responsible for identifying root causes

for diverse network problems involving a variety of technologies, including both

high speed data networks as well as telephone networks. I analyzed the potential

impacts of earthquakes and other natural disasters on telecommunications

network performance. The NSF sponsored me to be the sole US

telecommunications industry representative at the 1st International Joint US-

Japan Earthquake Symposium in 1993.

19. Since 1995, I have been President of my own company, The Forys

Consulting Group, Inc., providing consulting in voice and data communications

services. My work as a consultant included using HP’s SS7 network monitoring

capabilities to analyze Internet traffic patterns in a large metro area. I did root

cause analyses on a variety of problems in data network elements and in

signaling networks. As part of a team of international experts, I investigated a

wide range of issues involving the introduction of a new line of vendor products

in a foreign national network.



-12-

20. I advised on signaling interconnection issues for a foreign telephone

company.

21. I investigated the tradeoffs involved in using various ATM data

service categories to transport signaling traffic. As a consultant to a large

telephone company, I advised them on quality of service issues in providing

voice over ATM, the Internet and also Multiprotocol Label Switching (MPLS)

networks, which are used in some private internets. As a consultant to a major

consulting company, I estimated the equipment augmentation necessary to meet

various traffic demands for a variety of data technologies including ATM, Frame

Relay and MPLS.

22. I analyzed various supplier components for providing hybrid fiber

coax access in a cable network. I consulted with a large company on the

economic and technical problems associated with providing voice and data

communications over a foreign cable network.

23. I researched and developed my own Call Admission Control (CAC)

strategy for ATM switches. In addition, I researched alternative routing in failure

cases for Asynchronous Transfer Mode (ATM) and MPLS IP networks.

24. I researched and analyzed the prevailing proposals for supplying

Local Number Portability (LNP) for a large telecommunications supplier. On

behalf of the European Commission, I served as an advisor on research projects



-13-

involving the Advanced Intelligent Network, part of which involved signaling

interconnections.

25. I did extensive studies of network restoration using digital

crossconnect systems for a large network provider. I provided reliability analyses

and wrote the specifications for various performance and planning tools for a

company providing optical crossconnect systems. This included automatic

rerouting around failed facilities. I headed the effort of a team of experts in

providing routing and network planning tools for the same optical switch

company.

26. I did extensive consulting for various data communications systems

involving satellite access. Specifically I analyzed the performance, provided

traffic inputs and helped specify traffic network management/congestion controls

for three satellite data communications systems capable of handling both

packetized voice as well as Internet traffic. I was responsible for analyzing the

impacts of web caching for a fourth system.

27. I have been involved as an expert witness in several patent cases

involving Voice over IP technologies (for both long distance carriers as well as

cable providers) e.g. ATM, Frame Relay, MPLS, LANS, WANS, VPNs and

other packet switching technologies. I also was involved in patents involving

multiple, disparate, data networks with routing between these networks including



-14-

varieties of LANS, WANS, Unlicensed Mobile Access (UMA), and Generic

Access Networks. In addition, I was involved in investigating alternative routing

strategies for datagram networks in the event of failures as well as various

security features in data networks including firewalls and packet validation.



-15-

III. PERSON OF ORDINARY SKILL IN THE ART

28. I understand that the content of a patent (including its claims) and

prior art should be interpreted the way a person of ordinary skill in the art would

have interpreted the material at the time of invention.

29. I understand that the “time of invention” here is the date that the

applicants for the ‘048 Patent first filed a related application in the United States

Patent and Trademark Office, namely, Dec. 29, 2000.

30. It is my opinion that one of ordinary skill in the art at the time of the

filing date of the ‘048 Patent would have had at least a Bachelor of Science in

Computer Science, Computer Engineering, Electrical Engineering, or an

equivalent field as well as at least 2 years of academic or industry experience in

both connectionless and connection-oriented data protocols.

31. In addition to my testimony as an expert, I am prepared to testify as

someone who actually practiced in the field from 1968 to the present, who

actually possessed at least the knowledge of a person of ordinary skill in the art in

that time period, and who actually worked, supervised and recruited others

possessing at least the knowledge of a person of ordinary skill in the art in that

time period.

32. I understand that the person of ordinary skill is a hypothetical person

who is assumed to be aware of all the pertinent information that qualifies as prior



-16-

art. In addition, the person of ordinary skill in the art makes inferences and takes

creative steps.



-17-

IV. LEGAL UNDERSTANDING

33. I have a general understanding of validity based on my experience

with patents and my discussions with counsel.

34. I have a general understanding of prior art and priority date based on

my experience with patents and my discussions with counsel.

35. I understand that inventors are entitled to a priority date up to one year

earlier than the date of filing to the extent that they can show complete possession

of particular claimed inventions at such an earlier priority date and reasonable

diligence to reduce the claims to practice between such an earlier priority date

and the date of filing of the patent. I understand that if the Patent Owner contends

that particular claims are entitled to an earlier priority date than the date of filing

of the patent, then the Patent Owner has the burden to prove this contention with

specificity.

36. I understand that an invention by another must be made before the

priority date of a particular patent claim in order to qualify as “prior art” under 35

U.S.C. § 102 or § 103, that a printed publication or a product usage must be

publicly available before the priority date of a particular patent claim in order to

qualify as “prior art” under 35 U.S.C. § 102(a), that a printed publication or a

product usage or offer for sale must be publicly available more than one year

prior to the date of the application for patent in the United States in order to



-18-

qualify as “prior art” under 35 U.S.C. § 102(b), or that the invention by another

must be described in an application for patent filed in the United States before the

priority date of a particular patent claim in order to qualify as “prior art” under 35

U.S.C. § 102(e). I understand that the Petitioner has the burden of proving that

any particular reference or product usage or offer for sale is prior art.

37. I have a general understanding of anticipation based on my experience

with patents and my discussions with counsel.

38. I understand that anticipation analysis is a two-step process. The first

step is to determine the meaning and scope of the asserted claims. Each claim

must be viewed as a whole, and it is improper to ignore any element of the claim.

For a claim to be anticipated under U.S. patent law: (1) each and every claim

element must be identically disclosed, either explicitly or inherently, in a single

prior art reference; (2) the claim elements disclosed in the single prior art

reference must be arranged in the same way as in the claim; and (3) the identical

invention must be disclosed in the single prior art reference, in as complete detail

as set forth in the claim. Where even one element is not disclosed in a reference,

the anticipation contention fails. Moreover, to serve as an anticipatory reference,

the reference itself must be enabled, i.e., it must provide enough information so

that a person of ordinary skill in the art can practice the subject matter of the

reference without undue experimentation.



-19-

39. I further understand that where a prior art reference fails to explicitly

disclose a claim element, the prior art reference inherently discloses the claim

element only if the prior art reference must necessarily include the undisclosed

claim element. Inherency may not be established by probabilities or possibilities.

The fact that an element may result from a given set of circumstances is not

sufficient to prove inherency. I have applied these principles in forming my

opinions in this matter.

40. I have a general understanding of obviousness based on my

experience with patents and my discussions with counsel.

41. I understand that a patent claim is invalid under 35 U.S.C. § 103 as

being obvious only if the differences between the claimed invention and the prior

art are such that the subject matter as a whole would have been obvious at the

time the invention was made to a person of ordinary skill in that art. An

obviousness analysis requires consideration of four factors: (1) scope and content

of the prior art relied upon to challenge patentability; (2) differences between the

prior art and the claimed invention; (3) the level of ordinary skill in the art at the

time of the invention; and (4) the objective evidence of non-obviousness, such as

commercial success, unexpected results, the failure of others to achieve the

results of the invention, a long-felt need which the invention fills, copying of the



-20-

invention by competitors, praise for the invention, skepticism for the invention,

or independent development.

42. I understand that a prior art reference is proper to use in an

obviousness determination if the prior art reference is analogous art to the

claimed invention. I understand that a prior art reference is analogous art if at

least one of the following two considerations is met. First a prior art reference is

analogous art if it is from the same field of endeavor as the claimed invention,

even if the prior art reference addresses a different problem and/or arrives at a

different solution. Second, a prior art reference is analogous art if the prior art

reference is reasonably pertinent to the problem faced by the inventor, even if it

is not in the same field of endeavor as the claimed invention.

43. I understand that it must be shown that one having ordinary skill in

the art at the time of the invention would have had a reasonable expectation that a

modification or combination of one or more prior art references would have

succeeded. Furthermore, I understand that a claim may be obvious in view of a

single prior art reference, without the need to combine references, if the elements

of the claim that are not found in the reference can be supplied by the knowledge

or common sense of one of ordinary skill in the relevant art. However, I

understand that it is inappropriate to resolve obviousness issues by a retrospective



-21-

analysis or hindsight reconstruction of the prior art and that the use of “hindsight

reconstruction” is improper in analyzing the obviousness of a patent claim.

44. I further understand that the law recognizes several specific guidelines

that inform the obviousness analysis. First, I understand that a reconstructive

hindsight approach to this analysis, i.e., the improper use of post-invention

information to help perform the selection and combination, or the improper use

of the listing of elements in a claim as a blueprint to identify selected portions of

different prior art references in an attempt to show that the claim is obvious, is

not permitted. Second, I understand that any prior art that specifically teaches

away from the claimed subject matter, i.e., prior art that would lead a person of

ordinary skill in the art to a specifically different solution than the claimed

invention, points to non-obviousness, and conversely, that any prior art that

contains any teaching, suggestion, or motivation to modify or combine such prior

art reference(s) points to the obviousness of such a modification or combination.

Third, while many combinations of the prior art might be “obvious to try”, I

understand that any obvious to try analysis will not render a patent invalid unless

it is shown that the possible combinations are: (1) sufficiently small in number so

as to be reasonable to conclude that the combination would have been selected;

and (2) such that the combination would have been believed to be one that would

produce predictable and well understood results. Fourth, I understand that if a



-22-

claimed invention that arises from the modification or combination of one or

more prior art references uses known methods or techniques that yield

predictable results, then that factor also points to obviousness. Fifth, I understand

that if a claimed invention that arises from the modification or combination of

one or more prior art references is the result of known work in one field

prompting variations of it for use in the same field or a different one based on

design incentives or other market forces that yields predicable variations, then

that factor also points to obviousness. Sixth, I understand that if a claimed

invention that arises from the modification or combination of one or more prior

art references is the result of routine optimization, then that factor also points to

obviousness. Seventh, I understand that if a claimed invention that arises from the

modification or combination of one or more prior art references is the result of a

substitution of one known prior art element for another known prior art element

to yield predictable results, then that factor also points to obviousness.

45. I understand that a dependent claim incorporates each and every

limitation of the claim from which it depends. Thus, my understanding is that if a

prior art reference fails to anticipate an independent claim, then that prior art

reference also necessarily fails to anticipate all dependent claims that depend

from the independent claim. Similarly, my understanding is that if a prior art

reference or combination of prior art references fails to render obvious an



-23-

independent claim, then that prior art reference or combination of prior art

references also necessarily fails to render obvious all dependent claims that

depend from the independent claim.



-24-

V. THE ‘048 PATENT

46. According to the “Field of the Invention” section, the ‘048 Patent,

entitled “Tools and Techniques for Directing Packets over Disparate Networks”

relates to “computer network data transmission” or more specifically, “tools and

techniques for communications using disparate parallel networks, such as a

virtual private network (“VPN”) or the Internet in parallel with a point-to-point,

leased line, or frame relay network, in order to help provide benefits such as load

balancing across network connections, greater reliability, and increased security”

(see, for example, Ex. 1003 at 1:19-26).

47. I note that the ‘235 Patent was filed on Feb. 7, 2003 (see, for example,

Ex. 1001 at (22)). I also note that the ‘235 Patent is a continuation-in-part of US

Patent Application No. 10/034,197 (the “‘197 Application”) filed on Dec. 28,

2001 and that the ‘197 Application claims priority to US Provisional Patent

Application No. 60/259,269 filed Dec. 29, 2000 (see, for example, Ex. 1001 at

(63), (60) or 1:7-13). I further note that the ‘235 Patent also claims priority to US

Provisional Patent Application No. 60/355,509 filed Feb. 8, 2002 (see, for

example, Ex. 1001 at (60) or 1:7-13). Similarly, I note that the ‘048 Patent was

filed on Aug. 3, 2004 and claims priority to the ‘235 Patent (see, for example, Ex.

1003 at 1:6-7).



-25-

48. I understand that in a co-pending litigation Fatpipe, Inc. v. Talari

Networks, Inc., 5:16-CV-54-BO (E.D.N.C.), the Patent Owner has alleged that

claims 1-24 of the ‘048 Patent should be entitled to a priority date of Feb. 8, 2002

(see, for example, Ex. 1009 at p. 5). I am not aware at this time of any basis for

an assertion of a priority date for any claim of the ‘048 Patent that would be

earlier than Feb. 8, 2002. My usage of the foregoing alleged priority dates for my

analyses to follow does not mean that I agree that any claims of the ‘048 Patents

should be accorded these priority dates as alleged by the Patent Owner.

49. In the “Technical Background of the Invention” section, the ‘048

Patent specification notes that the “present application focuses on architectures

involving disparate networks in parallel, such as a proprietary frame relay

network and the Internet” (see, for example, Ex. 1003 at 2:19-21). The ‘048

Patent specification explicitly explains that “the term “private network” is used

herein in a manner consistent with its use in the ’197 application (which

comprises frame relay and point-to-point networks), except that a “virtual private

network” as discussed herein is not a “private network”” because “Virtual private

networks are Internet-based, and hence disparate from private networks, i.e.,

from frame relay and point-to-point networks” (see, for example, Ex. 1003 at

2:21-28). The ‘048 Patent specification explicitly calls out “frame relay” and a

“point-to-point network, such as a T1 or T3 connection” as being “an example of



-26-

a network that is “disparate” from the Internet and from Internet-based virtual

private networks for purposes of the present invention” (see, for example, Ex.

1003 at 1:58-62).

50. The ‘048 Patent specification also describes “FIG. 5” as “a prior art

approach having a frame relay network configured in parallel with a VPN or

other Internet-based network that is disparate to the frame relay network” (see,

for example, Ex. 1003 at 5:20-24).

51.

52. Thus, the ‘048 Patent specification explicitly admits that the fact that

“Organizations” can “use Internet-based redundant connections to backup the

primary frame relay networks” was already well known in the prior art (see, for

example, Ex. 1003 at 4:20-22 and FIG. 5 as annotated herein). Similarly, the ‘048

Patent specification also admits that such prior art usage of parallel disparate

networks not only provides “redundancy” but also “load balancing” subject to the

alleged restriction that the prior art “allowed load-balancing only on a very broad



-27-

granularity, and did not load-balance dynamically in response to actual traffic”

(see, for example, Ex. 1003 at 8:63-9:1). Additionally, the ‘048 Patent

specification admits that secure routing paths to “Internet-based communication

solutions such as VPNs and Secure Sockets Layer (SSL)” are also known in the

prior art and are “advantageous in the flexibility and choice they offer in cost, in

service providers, and in vendors” (see, for example, Ex. 1003 at 4:1-6).

53. According to the ‘048 Patent specification, “By placing inventive

modules 602 between locations and their routers as illustrated in FIG. 10,

however, the invention allows load-balancing, redundancy, or other criteria to be

used dynamically, on a granularity as fine as packet-by-packet, to direct packets

to an Internet router and/or a frame relay/point-to-point router according to the

criteria” (see, for example, Ex. 1003 at 9:4-9). As evident from annotated FIG. 10

herein and the foregoing citation, the alleged invention of the ‘048 Patent is thus

not the use of parallel disparate networks between locations (or “sites”) but

instead the allegedly novel functional characteristics of the “Controller 602” that

routes data traffic from a local site to a remote site over either or both of the

Internet and frame relay or point-to-point networks (see, for example, Ex. 1003 at

9:4-10:47 and FIG. 10 as annotated herein).



-28-

54.

55. The ‘048 Patent specification also depicts the “controller 602 of the

present invention” in FIG. 7, which is described as comprising “an interface

component for each network to which the controller connects, and a path selector

in the controller which uses one or more of the following as criteria: destination

address, network status (up/down), network load, use of a particular network for

previous packets in a given logical connection or session” as well as a “site

interface 702” that “connects the controller 602 to the LAN at the site” (see, for

example, Ex. 1003 at 5:33-40, 10:48-51 and FIG. 7 as annotated herein).

According to the ‘048 Patent specification, “controller 602” may be

“implemented in custom hardware, or implemented as software configuring semi-

custom or general-purpose hardware” (see, for example, Ex. 1003 at 10:54-57).



-29-

56.

57. According to the ‘048 Patent specification, the “path selector 704

determines which path to send a given packet on” according to enumerated

criteria that “may be used to select a path for a given packet, for a given set of

packets, and/or for packets during a particular time period” (see, for example, Ex.

1003 at 10:57-64).

58. The first of these enumerated criteria is “Redundancy”, which the

‘048 Patent specification describes as “use devices (routers, network switches,

bridges, etc.) that will still carry packets after the packets leave the selected

network interfaces, when other devices that could have been selected are not

functioning” (see, for example, Ex. 1003 at 10:65-11:4). However, the ‘048

Patent specification explicitly admits that “Techniques and tools for detecting

network path failures are generally well understood” (see, for example, Ex. 1003

at 11:4-5).



-30-

59. The second of these enumerated criteria is “Load-balancing”, which

the ‘048 Patent specification describes as “send packets in distributions that

balance the load of a given network, router, or connection relative to other

networks, routers, or connections available to the controller 602” (see, for

example, Ex. 1003 at 11:8-11). According to the ‘048 Patent specification, such

“load balancing” is “preferably done on a per-packet basis for site-to-site data

traffic or on a TCP or UDP session basis for Internet traffic”, which the ‘048

Patent specification alleges to be “opposed to prior art approaches which use a

per-department and/or per-router basis for dividing traffic” (see, for example, Ex.

1003 at 11:20-25). However, the ‘048 Patent specification explicitly admits that

“Load-balancing algorithms in general are well understood” (see, for example,

Ex. 1003 at 11:25-26).

60. The third of these enumerated criteria is “Security”, which the ‘048

Patent specification describes as “divide the packets of a given message (session,

file, Web page, etc.) so they travel over two or more disparate networks” (see, for

example, Ex. 1003 at 11:28-30). Alternatively, the ‘048 Patent specification

describes this “security” criterion as simply “one network may be viewed as more

secure than another, encryption may be enabled, or other security measures may

be taken” (see, for example, Ex. 1003 at 11:47-49).



-31-

61. According to the ‘048 Patent specification, the “Path selection criteria

may be specified” by “configuration files, hardware jacks or switches, ROM

values, remote network management tools, or other means” (see, for example,

Ex. 1003 at 12:50-53).

62. The ‘048 Patent specification also states that “FIG. 9 is a flowchart

illustrating methods of the present invention for combining connections to send

traffic over multiple parallel independent disparate networks for reasons such as

enhanced reliability, load balancing, and/or security” (see, for example, Ex. 1003

at 5:44-47, 13:19-22 and FIG. 9 as annotated herein).

63.

64. The ‘048 Patent specification describes an “address range information

obtaining step 900” during which “address ranges for known locations are

obtained” (see, for example, Ex. 1003 at 13:26-27). According to the ‘048 Patent



-32-

specification, “Each address range has an associated network; a network may

have more than one associated contiguous range of addresses which collectively

constitute the address range for that network” (see, for example, Ex. 1003 at

13:33-35). Additionally, the ‘048 Patent specification states that “The locations

reachable through the network have addresses in the address range associate with

the network” and thus “a location reachable through two networks has two

addresses, which differ in their network identifying bits but are typically the same

in their other bits” (see, for example, Ex. 1003 at 13:36-41). The ‘048 Patent

specification also discloses that “Address ranges may be obtained 900 by reading

a configuration file, querying routers, receiving input from a network

administrator, and/or other data gathering means” (see, for example, Ex. 1003 at

13:41-44).

65. The ‘048 Patent specification further describes a “topology

information obtaining step 902” wherein “topology information for the system of

parallel disparate networks is obtained” (see, for example, Ex. 1003 at 13:45-47).

The ‘048 Patent specification also discloses that “Topology information may be

obtained 902 by reading a configuration file, querying routers, receiving input

from a network administrator, and/or other data gathering means” (see, for

example, Ex. 1003 at 13:54-57).



-33-

66. The ‘048 Patent specification also describes a “determining step 906”

in which “the controller 602 (or some other device used in implementing the

method) looks at the packet destination address to determine whether the

destination address lies within a known address range” by comparing “destination

address” to the “known location address ranges that were obtained during step

900, in order to see whether the destination location is a known location” (see, for

example, Ex. 1003 at 14:11-17). According to the ‘048 Patent specification,

“Only packets destined for known locations are potentially rerouted by the

invention to balance loads, improve security, and/or improve reliability” and in

contrast, other “Packets destined for unknown locations are simply sent to the

network indicated in their respective destination addresses” (see, for example,

Ex. 1003 at 14:17-21).

67. The ‘048 Patent specification further describes a “path selecting step

908” wherein the “path selector 704 selects the path over which the packet will

be sent; selection is made between at least two paths, each of which goes over a

different network 106 than the other” (see, for example, Ex. 1003 at 14:27-30).

According to the ‘048 Patent specification, “This path selecting step 908 may be

performed once per packet, or a given selection may pertain to multiple packets”

and further for some embodiments, “selecting a network will also select a path, as

in the system shown in FIG. 10” (see, for example, Ex. 1003 at 14:31-35).



-34-

68. The ‘048 Patent specification similarly describes an “address

modifying step 916” wherein “the packet destination address is modified as

needed to make it lie within an address range (obtained during step 900) which is

associated with the selected path to the selected network (selected during step

908)” as in the example of “if a packet is received 904 with a destination address

corresponding to travel through the Internet but the path selection 908 selects a

path for the packet through a frame relay network 106 to the same destination,

then the packet’s destination IP address is modified 916 by replacing the IP

address with the IP address of the appropriate interface of the controller at Site

B” and “the packet’s source IP address is replaced with the IP address of the

appropriate interface of the source controller” (see, for example, Ex. 1003 at

15:41-53).

69. The ‘048 Patent includes 24 claims. I have been informed by Counsel

that Claims 1-24 are the subject of the Inter Partes Review petition. Note that for

solely purposes of my analyses herein, I have denoted certain elements of Claims

1, 7, 13, and 19 as (a), (b), etc. even though such nomenclature does not appear in

the ‘048 Patent.



-35-

VI. CLAIM CONSTRUCTION

70. I understand that claim construction is a matter of law. However, I

understand that in an Inter Partes Review proceeding the claims are to be given a

broadest reasonable interpretation consistent with the ‘048 Patent specification

such that specific claim terms are given their ordinary and customary meaning as

would be understood by a person of ordinary skill in the art in the context of the

entire disclosure. I also understand that limitations from the specification are not

to be read into the claims. The specification, however, can inform a person of

ordinary skill in the art as to a broadest reasonable interpretation of the claims. In

addition, I understand that a person of ordinary skill in the art would look to

explanations and arguments made by the applicants during prosecution history to

inform a broadest reasonable interpretation of the claims of the ‘048 Patent.

71. I understand that indefiniteness is not an issue that can be addressed as

part of an Inter Partes Review proceeding. Therefore, I have, solely for the

purposes of my prior art invalidity analyses herein as relevant to this Inter Partes

Review proceeding, used a broadest reasonable interpretation for all claim terms

without regard to the consideration that certain of these claim terms may be

found indefinite as a matter of law.

72. The term “private network” appears in at least Claims 1, 2, 6, 7, 8,

12, 13, 14, 18, 19, 20 and 24 of the ‘048 Patent. In the District Court litigation,



-36-

the Patent Owner has alleged that no construction of the claim term is necessary,

or alternatively that this claim term should mean “a communication path that is

unavailable to the general public” (see, for example, Ex. 1014 at p. 1). For the

purposes of my analysis in this declaration solely, I have accepted Patent

Owner’s proposed constructions as being within a broadest reasonable

interpretation of the term “private network”.

73. The term “Internet based network” (or alternatively, “network based

on the Internet”) appears in at least Claims 1, 7, 13, and 19 of the ‘048 Patent. In

the District Court litigation, the Patent Owner has alleged that no construction of

the claim term is necessary, or alternatively that this claim term should mean “a

communication path that is available on the public Internet” (see, for example,

Ex. 1014 at p. 1). For the purposes of my analysis in this declaration solely, I

have accepted Patent Owner’s proposed constructions as being within a broadest

reasonable interpretation of the term “Internet based network”.

74. The term “disparate networks” appears in at least Claims 1, 7, 13,

and 19 of the ‘048 Patent. In the District Court litigation, the Patent Owner has

alleged that this claim term should be construed to mean “networks that are

different in kind, e.g. a private network and an Internet based network” (see, for

example, Ex. 1014 at p. 1). For the purposes of my analysis in this declaration



-37-

solely, I have accepted Patent Owner’s proposed construction as being within a

broadest reasonable interpretation of the term “disparate networks”.

75. The term “per-packet basis” (or alternatively, “packet by packet

basis”) appears in at least Claims 7 and 19 of the ‘048 Patent. In the District

Court litigation, the Patent Owner has alleged that no construction of the claim

term is necessary, or alternatively that this claim term should mean “packet by

packet” (see, for example, Ex. 1014 at p. 2). For the purposes of my analysis in

this declaration solely, I have accepted Patent Owner’s proposed constructions as

being within a broadest reasonable interpretation of the term “per-packet basis”.

76. The term “packet path selector” appears in at least Claims 1, 3, 4,

19, 21 and 22 of the ‘048 Patent. In the District Court litigation, the Patent Owner

has alleged that no construction of the claim term is necessary, or alternatively

that this claim term should mean “module(s) that selects which path to send a

given packet on” (see, for example, Ex. 1014 at p. 2). For the purposes of my

analysis in this declaration solely, I have accepted Patent Owner’s proposed

constructions as being within a broadest reasonable interpretation of the term

“packet path selector”.

77. The term “parallel network” appears in at least Claims 1, 7, 13, and

19 of the ‘048 Patent. In the District Court litigation, the Patent Owner has

alleged that this claim term should be construed to mean “at least two networks



-38-

configured to allow alternate data paths” (see, for example, Ex. 1014 at p. 3). For

the purposes of my analysis in this declaration solely, I have accepted Patent

Owner’s proposed construction as being within a broadest reasonable

interpretation of the term “parallel network”.

78. The term “session” appears in at least Claims 1, 7, 13, and 19 of the

‘048 Patent. In the District Court litigation, the Patent Owner has alleged that this

claim term should be construed to mean “an active communications connection,

measured from beginning to end, between computers or applications over a

network” (see, for example, Ex. 1014 at pp. 3-4). For the purposes of my analysis

in this declaration solely, I have accepted Patent Owner’s proposed construction

as being within a broadest reasonable interpretation of the term “session”.

79. I have applied the plain and ordinary meaning to all remaining claim

terms for the purposes of this review proceeding.

80. In the event that one or more of these constructions is changed, I

reserve the right to revisit my analysis under the different construction(s).



-39-

VII. STATE OF THE ART

81. As of Dec. 29, 2000, when the first of the applications that later

became the ‘048 Patent was filed, the state of the art in the field of “architectures

involving disparate networks in parallel” already fully encompassed the concepts

of and the implementation for routing based upon “load-balancing, redundancy,

or other criteria to be used dynamically, on a granularity as fine as packet-by-

packet” as evidenced by the following sample of art.

Karol (Ex. 1006) 82. For example, amongst the numerous prior art references in this field,

U.S. Patent No. 6,628,617 by Mark John Karol and Malathi Veeraraghavan

entitled “Technique for Interconnecting Traffic on Connectionless and

Connection-Oriented Networks” (“Karol”) was filed on Mar. 3, 1999, which is

more than 1 year before the earliest priority date of the ‘048 Patent (see, for

example, Ex. 1006 at (22)). Thus, I understand that Karol qualifies as prior art to

the ‘048 Patent at least under § 102(e).

83. As Karol discloses in its “Field of the Invention” section, the Karol

patent is directed towards “internetworking of connectionless (e.g. Internet

Protocol or “IP”) and connection oriented (e.g. ATM, MPLS, RSVP) networks”

(see, for example, Ex. 1006 at 1:7-10). The Karol patent defines the terms

“connectionless” by the abbreviation “CL” and “connection oriented” by the

abbreviation “CO” throughout the specification and figures (see, for example, Ex.



-40-

1006 at 1:12-14 and 1:19-20). At least because Karol is directed to an analogous

field of art (data networking) and directed to solving analogous problems (routing

to parallel disparate networks), Karol is analogous art to the ‘048 Patent (see also,

¶¶ 42 and 46 above).

84. More specifically, Karol discloses “nodes called CL-CO gateways, are

arranged to have connectivity to both the CL network and the CO network”

wherein “each CL-CO gateway includes hardware and software modules that

typically comprise” at least “interfaces to the CO network”, “interfaces to the CL

network”, “a database for storing forwarding, flow control, header translation and

other information”, and “a processor containing logic for controlling the gateway

packet handling operations” (see, for example, Ex. 1006 at 2:13-28). Karol

further discloses that for the “parallel configuration” where there are always “at

least two paths” such as “one using the CL network and the other using the CO

network”, then there “is always a routing choice, i.e., CL to CO to CL or entirely

CL” and the “gateway” should “make the routing selection based on maximizing

efficiency” (see, for example, Ex. 1006 at 2:61-66). Thus, Karol is clearly from

the same field of art as the ‘048 Patent and is clearly addressing similar problems

as those purportedly addressed by the ‘048 Patent.

85. Karol discloses that the “CO network can be an MPLS (MultiProtocol

Label Switching) or RSVP (Resource reSerVation Protocol) based IP network, a



-41-

WDM (Wavelength Division Multiplexed) network, an ATM (Asynchronous

Transfer Mode) network, or an STM (Synchronous Time Multiplexing) network,

such as the telephony network or a SONET network” and that the “CL network is

typically, although not necessarily, an IP network” (see, for example, Ex. 1006 at

2:61-66). Karol also discloses that the “CO network” can be comprised of an

“X.25 network” or “point-to-point links” (see, for example, Ex. 1006 at 13:62-

67). Frame Relay was an outgrowth and replacement of X.25.

86. FIG. 1 of Karol is a diagram of “internetworking CO and CL

networks” in a “parallel” configuration in order to “offer enterprises “long-

distance” connectivity of their geographically distributed networks” (see, for

example, Ex. 1006 at 2:65-67, 3:46-51 and FIG. 1). Karol describes the operation

of the network in FIG. 1 as “Traffic from source endpoint 101 destined for

destination endpoint 151 (which is directly connected to and served by a node

132 in a CL network 130) can be routed in at least two different, parallel routes,

and this choice of routes is reflected in how the CL-CO gateway 140 operates”

(see, for example, Ex. 1006 at 4:40-44 and FIG. 1).



-42-

87.

88. Karol continues in reference to the “two different, parallel routes” of

FIG. 1 by nothing that “In the first route, the datagram can follow a path that

traverses only connectionless nodes” including “eventually through node 112,

which routes traffic” to “CL network 120” while “The second path that a

datagram in FIG. 1 can follow extends at least partially over a CO network 160,

using the CL-CO gateways 140 and 150” (see, for example, Ex. 1006 at 4:43-58

and FIG. 1). Karol also discloses that for every “datagram” (or “packet”) that

“arrives at a CL-CO gateway 140 of FIG. 1, a determination is made if that

packet should be carried by CO network 160” (see, for example, Ex. 1006 at

5:23-25 and FIG. 1). Karol also specifically discloses for the CL and CO

networks that the “parallel configuration could occur, for example, if two service



-43-

providers, one with an IP-router-based network and the other with a CO-switch-

based network, offer enterprises "long-distance" connectivity of their

geographically distributed networks” (see, for example, Ex. 1006 at 3:47-51).

89. More specifically with respect to FIG. 1 Karol discloses that

“Connections are set up through CO network 160 for some, but not necessarily

all, of the arriving CL traffic” such that “if a CO connection is not used, the path

might extend from gateway 140 back to node 112 in CL network 110 via path

115, and thence through CL networks 120 and 130 to destination endpoint 151”

and thus “CL-CO gateway 140 handles traffic both from flows for which CO

connections are set up, as well as continues forwarding packets through the CL

network if a CO connection is not set up” (see, for example, Ex. 1006 at 5:28-35

and FIG. 1).

90. As Karol explicitly recites in reference to FIG. 1, “The decision to set

up CO connections is made at CL-CO gateway 140, based on the user-specified

service requirements and the traffic situation in the CL and CO networks”

(emphasis added, see, for example, Ex. 1006 at 5:35-38 and FIG. 1).

91. Thus, a person of ordinary skill in the art at the time of filing of the

‘048 Patent would also readily understand that Karol, just from FIG. 1 and its

corresponding description alone, describes a system wherein a combination of

one or more local switches and/or routers with a path selection gateway at each of



-44-

multiple enterprise sites can have long-distance connectivity for transporting each

packet from one enterprise site to the other over either of an Internet-based

network or a private non-Internet based network arranged in parallel based on

user set criteria and the instant traffic situation in both of the disparate parallel

networks.

92. FIG. 4 of Karol “shows the internal arrangement of CL-CO gateway

140” that “includes hardware and software modules that typically comprise” at

least “a switch fabric for CO networking, shown in FIG. 4 as CO switch 410”, “a

CL packet forwarding engine, shown in FIG. 4 as CL router/switch 420”, “a

protocol converter 450”, and “a processor 430 and associated database 431 for

controlling the gateway packet handling operations and for storing forwarding,

flow control, header translation and other information” (see, for example, Ex.

1006 at 6:31-44 and FIG. 4). FIG. 4 of Karol also discloses “Input line cards 401

and output line cards 402” that “connect the gateway of FIG. 4 to external

networks” such that “datagrams received in input line cards 401 can be directed

either to CO switch 410 or CL router/switch 420” and such that “output line cards

402 can receive datagrams from either of the last mentioned elements and direct

them to external networks” (see, for example, Ex. 1006 at 6:44-50 and FIG. 4).



-45-

93.

94. Karol discloses the structural elements involved in selecting the CL or

CO path for a given packet primarily in the description of the “gateway processor

430” and the “database 431”. In particular, Karol discloses that “Database 431

includes a series of individual databases arranged to store information used in

various of the functions performed by processor 430, and may include, as an

example, a datagram forwarding database 432, a flow database 433, and a header

translation database 434” (see, for example, Ex. 1006 at 7:31-35 and FIG. 4).

More specifically, “datagram forwarding database 432” is described as “the

database used in typical CL IP routers” that “stores the next hop router address

and outgoing port number corresponding to each destination address” and thus

the “fields in each record in this database would be: Destination IP address; Next

hop router; Outgoing port (interface)” (see, for example, Ex. 1006 at 7:36-41).

95. Additionally, Karol discloses that “Flow database 433 stores

information used to determine how to handle packets from flows requiring a

connection-oriented service” wherein “Typical fields in each record in this



-46-

database include: (a) an outgoing port field, which indicates the port on which a

datagram whose entries match a particular record's entries is forwarded; (b) if the

outgoing port is “invalid,” the next field “forward or hold” entry indicates

whether packet should be forwarded or held in packet buffer 440; (c) destination

address; (d) source address; (e) source port; (f) destination port; (g) type of

service; (h) protocol field; (i) TCP Flags; (j) outgoing port; (k) forward or hold

flag, and (l) a mask which indicates which of the data entries is applicable to the

particular record” (see, for example, Ex. 1006 at 7:42-54).

96. Thus, Karol discloses in reference to FIG. 4 that “the processes

performed in CL-CO gateways that enable the internetworking of connectionless

IP networks and CO networks” accomplish two primary functions that are i)

handling “IP packets that arrive at CL-CO gateways to be carried on (not-yet-

established) connections in the CO network, plus IP packets that arrive at CL-CO

gateways but then remain in the CL network”, and ii) creating “routing tables that

enable data flow from the CL network to the CO network” (see, for example, Ex.

1006 at 7:60-8:2).

97. In Karol, “FIG. 5 is a flow diagram illustrating the steps performed

when the gateway of FIG. 4 performs its packet forwarding process” such that

“When an IP datagram arrives at the CL-CO gateway of FIG. 4, the handling

procedure that occurs in CL router/switch 420 is shown in FIG. 5” (see, for



-47-

example, Ex. 1006 at 3:6-8, 8:56-58 and FIG. 5). With respect to FIG. 5, Karol

describes that “CL packets arriving on the input line cards 401 in step 501 are

sent to CL router/switch 420, while a determination is made by gateway

processor 430 in step 503 as to whether the flow should be handled via the CO

network or not” (see, for example, Ex. 1006 at 8:58-62 and FIG. 5). More

specifically, “If the logic in processor 430 determines to use the CO network for

a given flow, a “YES” result is achieved in step 503, and flow database 433 is

consulted in step 505” wherein “If flow database 433 determines that there is a

record whose entries match the incoming packet header fields, a YES result

occurs in step 507, and the packet is sent to packet buffer 440” and subsequently

upon appropriate protocol conversion and confirmation of availability of the CO

network, “the datagram is forwarded in accordance with the entry, in step 521” to

the CO network path via the appropriate output line card (see, for example, Ex.

1006 at 8:62-9:22 and FIG. 5).



-48-

98.

99. Alternatively according to Karol, “If the flow classification

functionality within processor 430 determines that the packet should be handled

in a CL mode, a NO result occurs in step 503” and then “In that event,

forwarding database 432 is consulted in step 525 to determine if there is an entry

corresponding to the header field values of the incoming datagram” such as the

comparison of the packet destination address with that of known addresses as

described above (see, for example, Ex. 1006 at 9:26-31 and FIG. 5). Furthermore,

“If the result of step 527 is YES, indicating that there is an entry in forwarding

database 432 that matches the incoming packet header fields, the datagram is

forwarded in accordance with that entry, in step 529” and “Otherwise, if a NO



-49-

result occurs in step 527, the datagram is dropped in step 531”, which causes the

source routing module from which the packet came to route the packet in an

alternative manner independent of the CL-CO gateway such as by the Internet

(see, for example, Ex. 1006 at 9:31-36, 11:17-31, FIG. 5 and FIG. 7).

100. Karol provides numerous examples of how the “gateway processor

430” and “flow database 433” interact to determine whether a particular packet

belongs to a flow directed to the CO network or the CL network. For example,

some flows correspond to sessions or applications such as “web access, telnet,

file transfer, electronic mail, etc” that utilize the TCP transport layer while others

such as “Internet telephony and other multimedia traffic” may use the “RTP

(Real Time Protocol)” that “has been defined to use UDP” transport layer (see,

for example, Ex. 1006 at 10:25-39 and FIG. 6). As Karol explains, certain

packets carrying either TCP or UDP segments within certain sessions or

applications as listed above are appropriate for a flow to the CO network while

others are better directed to the CL network (see, for example, Ex. 1006 at 10:51-

11:26 and FIG. 6).

101. Karol also describes exemplary embodiments in which for particular

sessions, such as “Internet telephony and other multimedia traffic” that use UDP

transport layer, the CL-CO gateway forwards some datagrams over the CO

network and forwards other datagrams over the CL network (see, for example,



-50-

Ex. 1006 at 10:51-67 and FIG. 6). More specifically, Karol teaches that “If it is

determined in step 603 that the incoming packet is a UDP datagram, a

determination is next made in step 631 as to whether the datagram is from an

application that has an end-to-end handshake prior to data transfer, or a UDP

datagram from an application that does not have such a handshake” because

“based on the packet type, the gateway selects the corresponding "halting" or

"turning around" action to take” (see, for example, Ex. 1006 at 10:51-58). Karol

continues the description of this exemplary embodiment by nothing that “If the

result in step 631 is YES, the application message fields are checked in step 633,

so that a determination can be made in step 635 as to whether the message is

related to opening a session” and “If so, a YES result occurs in step 635, after

which the gateway sends a signal in step 637 requesting connection setup” (see,

for example, Ex. 1006 at 10:58-63). Thus, once the connection is setup,

datagrams carrying UDP segments from the source endpoint to the destination

endpoint associated with this flow or session (i.e. an Internet telephony call) will

be routed at the CL-CO gateway to the CO network (see, for example, Ex. 1006

at 10:51-11:26). However, as clearly shown in FIG. 6, if a “NO result occurs in

step 635”, then additional datagrams carrying UDP segments from the same

source endpoint to the same destination endpoint, even if associated with this

flow or session, will be routed at the CL-CO gateway to the CL network as



-51-

shown in FIG. 6 at step 635 to 625 until such time as the “flow database 433” is

“updated at step 641” (see, for example, Ex. 1006 at 10:63-67 and steps 635 and

625 of FIG. 6).

102.

103. Additionally, Karol informs that “gateways in accordance with the

present invention decide whether a datagram flow should be handled via the CO

network or not. (See step 503 in FIG. 5)” and thus “If the routing scheme used

maintains integrated IP-CO routing tables at the CL-CO gateways, neither type of

traffic poses a serious problem, since the default path expected by CL network

901 provides a path from the CL-CO gateways 960-962 through CL network 901

to the destination” (see, for example, Ex. 1006 at 15:31-39).



-52-

104. Karol also discloses that “FIG. 8 is a flow diagram illustrating the

routing related processes performed in the gateway of FIG. 4” (see, for example,

Ex. 1006 at 3:17-18 and FIG. 8). More specifically, “When a routing protocol

update is received from CL router/switch 420 or from CO switch 410, network,

the process shown in FIG. 8 is executed” such that “After the update arrives in

step 801, and the corresponding table is updated in step 803, a determination is

made in step 805 as to whether the resources of the CO network need to be

communicated to or “advertised” in the CL network” (see, for example, Ex. 1006

at 13:6-12 and FIG. 8).

105.

106. Note that in the system of Karol, such routing topology information is

propagated locally when “a YES result occurs in step 805, and an appropriate

routing protocol message is generated in step 807” or when “a NO result occurs

in step 805, and the integrated routing table is updated in step 809” so that the

system routes packets to the CL and CO networks based at least upon



-53-

conventional IP routing techniques such as OSPF as well as “Link State

Advertisements (LSAs) that report point-to-point links” that are expressed by

associated “link weights” so that “integrated IP-CO routing tables are maintained

at the CL-CO gateways” (see, for example, Ex. 1006 at 14:23-67, FIG. 8 and

FIG. 9).

107. Karol further discloses that the “CL-CO gateways arranged in

accordance with the present invention perform two principal functions: first, they

act as nodes in a CL network (e.g., as IP routers) that are equipped to decide

when to redirect traffic on to a switched CO network, and second, they act as

nodes of the CO network, and therefore execute the routing and signaling

protocols of the CO network” (see, for example, Ex. 1006 at 13:17-23). Thus, the

CL-CO gateways must maintain routing tables for both of the conventional CL

networks and of the CL to CO network routing translation based on their

respective addressing schemes as Karol explains can be done using any of three

ways to “create the routing tables that will enable data flow from CL network 901

to CO network 950” (see, for example, Ex. 1006 at 13:43-44). More specifically,

Karol discloses that “CO network 950 can be represented as a “non-broadcast

network” in the IP routing protocol (this affects routing information at CL-CO

gateways 960-962 and other routers)”, that “integrated routing tables for both the

IP and CO networks 901 and 950, respectively, can be maintained at the CL-CO



-54-

gateways 960-962”, or that “user-specific routing information to be maintained at

the CL-CO gateways 960-962, can be used in conjunction with either of the

above two approaches” (see, for example, Ex. 1006 at 13:45-53). Furthermore,

Karol teaches that “if users specify their desired service requirements at

subscription time, the network provider can set user-specific routing tables at the

CL-CO gateways” so that “the user-specific routing then determines which users'

flows are sent to the CO network” (see, for example, Ex. 1006 at 16:3-9).

108. As discussed also herein, the specific information relevant to these

“routing tables” is maintained in the various “databases” associated with the

“gateway processor” including the “datagram forwarding database 432, a flow

database 433, and a header translation database 434” (see, for example, Ex. 1006

at 7:31-35 and ¶ 94 above). In addition to the address, routing identification, and

network port information described above, the “header translation database 434”

is also updated when the “integrated routing table” that obtains the “resources of

the CO network” to include at least “CO packet header field values or circuit

identifiers” (see, for example, Ex. 1006 at 7:55-59, 13:6-16, and FIG. 8).

109. Karol also explains that this system of parallel CL and CO networks

with path selection for each packet based on flow characteristics has numerous

advantages for long distance enterprise connectivity. For example, Karol

discloses that “the advantage to a user is that the user can ask for and receive a



-55-

guaranteed quality of service for a specific flow” and “The advantage to a service

provider is that bandwidth utilization in a packet-switched CO network is better

than in a CL network with precomputed routes since bandwidth can be

dynamically allocated to flows on an as-needed basis” (see, for example, Ex.

1006 at 17:18-26). In particular Karol notes that “dynamically adjusting link

weights in the routing protocol can also be extended to include diverting

connections away from congested links” or “In other words, link weights can be

adjusted to reflect bandwidth availability” (see, for example, Ex. 1006 at 17:63-

18:2).

110. Thus, in addition to the disclosure summary given at ¶ 91 above, a

person of ordinary skill in the art at the time of filing of the ‘048 Patent would

also readily understand that Karol describes a system where the path selection

gateway is coupled to local site interfaces and to interfaces to at least CL and CO

disparate parallel networks, and wherein this path selection gateway can route

each individual packet to the appropriate one of multiple CL or CO disparate

parallel networks based at least upon: i) a comparison of the individual packet’s

destination address with known destination addresses that correspond to

particular outgoing ports (or interfaces) associated with each of the CL or CO

disparate parallel networks, ii) particular flows for various session types or

applications associated with the packet, and iii) current routing table parameters



-56-

including bandwidth availability and network congestion, and further describes

methodologies for obtaining router tables based upon destination address

identifiers to support such path selections.

Zhang (Ex. 1017) 111. As another example of prior art in this field, U.S. Patent No.

6,396,833 to Shujin Zhang et al. entitled “Per User and Network Routing Tables”

(“Zhang”) was filed on Dec. 2, 1998, which is before the earliest priority date of

the ‘235 Patent. Thus, I understand that Zhang qualifies as prior art to the ‘235

Patent at least under 35 U.S.C. § 102(e).

112. Zhang relates to routing of packets “in systems where a user may

connect to multiple networks”. (Ex. 1017 at 1:7-11.) FIG. 2, reproduced below,

illustrates gateway 82 interfacing computers 80, 86a, and 86b to corporate

networks 92 and 94 and to the Internet 96. (Ex. 1017 at 1:57-64.) Zhang is

directed towards routing at the gateway in support of multiple simultaneous users

where each user may have access to multiple simultaneous networks. (Ex. 1017

at 1:65-2:6.) At least because Zhang is directed to an analogous field of art (data

networking) and directed to solving analogous problems (routing for users

connected to multiple parallel disparate private and public networks), Zhang is

analogous art to the ‘235 Patent. (Ex. 1017 at 5:55-58; FIG. 4.) Like, the ‘235

patent, Zhang also uses a “gateway” which is functionally analogous to the

“controller” in the ‘235 patent to make its routing decisions.



-57-

113.

114. Zhang discloses a gateway which routes a packet sent from a user to a

connected network using a “per user routing table. (Ex. 1017 at 2:49-65.) An

illustrative per-user routing table according to Zhang is shown in FIG. 6,

reproduced below. In Zhang, the per user routing table contains entries

corresponding to one or more accessible networks for the user and the range of

network addresses corresponding to the networks. (Id. at 2:51-55.) First, the

gateway uses the source address of a packet “to find a per-user routing table

corresponding to the user who sent the packet.” (Ex. 1017 at 4:19-20.) In Zhang,

“[e]ach per user routing table 250 contains a user address 252, indicating the host

address of the user to which the routing table corresponds.” (Id. at 4:23-25.) The

per-user routing table also includes “one or more entries 254, each entry



-58-

corresponding to a currently accessible network for the corresponding user.” (Id.

at 4:25-28.) “Each entry 254 may contain a range of addresses 256, indicating

the network addresses which correspond to the corresponding accessible

network.” (Id. at 4:28-30 (emphasis added).)

115.

116. In Zhang, when the gateway receives a packet, it extracts the

destination address from the packet and traverses the entries 254 in the

appropriate per-user routing table to find “a range of network addresses [256]

containing the destination address.” (Ex. 1017 at 4:50-55.) It then routes the

packet to a matching network. (Ex. 1017 at 4:54-58.) One or more networks may

be available.

McCullough (Ex. 1018)



-59-

117. As another example of prior art in this field, U.S. Patent Publication

No. 2002/0010866 by David J. McCullough et al. entitled “Method and

Apparatus for Improving Peer-to-Peer Bandwidth Between Remote Networks by

Combining Multiple Connections Which Use Arbitrary Data Paths”

(“McCullough”) was filed on Dec. 18, 2000, which is before the earliest priority

date of the ‘235 Patent. Thus, I understand that McCullough qualifies as prior art

to the ‘235 Patent at least under 35 U.S.C. § 102(e).

118. McCullough is directed towards connecting two or more remote

private networks using a VPN through one of a multiplicity of ISP networks to

obtain access to a public network such as the Internet. (Ex. 1018 at [0002],

[0022], [0047] and FIGS. 2 and 4.) McCullough recognizes that dedicated point-

to-point lines were a common solution at the time for providing fast, reliable, and

confidential (although costly) communication between, for example, a corporate

LAN in New York and one in Chicago. (Ex. 1018 at [0003]-[0005].)

McCullough provides an example of corporate LANs interconnected through

dedicated point-to-point lines in FIG. 1, reproduced below. McCullough also

recognizes the advantages to connecting remote sites over the Internet (i.e., a

connectionless IP based network) as shown in FIG. 2 below, particularly in terms

of cost. (Ex. 1018 at [0006]) Thus, McCullough addresses the need in the art for a

solution to connect remote private networks through the Internet in a way that



-60-

achieved the same guarantees in terms of speed, reliability, and confidentiality.

At least because McCullough is directed to an analogous field of art (data

networking) and directed to solving analogous problems (interconnecting remote

private networks), McCullough is analogous art to the ‘235 Patent.

119.



-61-

120.

121. McCullough generally describes interconnecting remote private

computer networks using a public network with aggregated multiple links using a

multiplicity of ISPs to go between the private networks and the public network.

(Ex. 1018 at [0002].) More specifically, McCullough describes a “gateway”

capable of aggregating multiple “tunnels” through the public network. (Ex. 1018

at [0055].) These “tunnels” are described as “interior virtual circuits” (IVCs),

each of which is a peer-to-peer connection between an initiator gateway and a

responder gateway which includes a PPP link between the initiator and the public

network, a connection through the public network, and an equivalent PPP link

between the responder and the public network. (Ex. 1018 at [0055], FIG. 4.)

When an initiator gateway receives a data packet, a link manager directs the



-62-

packet through the appropriate “tunnel” (IVC) by “modif[ying] the source and

destination addresses of the tunnel data packet fragment to ensure that the packet

fragment, destined to arrive at particular link, has valid IP addressing for that

IVC.” (Ex. 1018 at [0087] (emphasis added).) McCullough further describes that

when an appropriate IVC is chosen (e.g., a known location address range with the

selected network), the outgoing packet is fragmented and the IP header of the

packet is translated to match the IVC. (Ex. 1018 at [0099].)

122. McCullough describes how a gateway may create superior virtual

circuit (SVC), which comprises a number of IVCs, where the packet load is

distributed “approximately equally over each of the IVCs.” (Ex. 1018 at [0055],

[0056].) According to McCullough, “[i]f this condition were not met, some of

the IVCs would take most of the load causing saturation of those IVCs while

other IVCs would stand idle.” (Ex. 1018 at [0056].) Accordingly, the gateway

may fragment packets in a message in order to distribute the packets “over the

available IVCs to implement load sharing” (e.g., “load balancing”). (Ex. 1018 at

[0077] (emphasis added).) When there is a large transfer of data between peer

networks, a bundle manager at the gateway can distribute 1500 byte fragments on

each available link (IVC) in a round-robin fashion in order to achieve load

balancing. (Ex. 1018 at [0079].)



-63-

123. Furthermore, when the gateway receives a packet for transport, the

gateway includes components which determine whether to fragment the

transmission before it is sent over a given IVC. (Ex. 1018 at [0075], [0080].) In

some instances, the message may not be fragmented into packets and may be

delivered over a single IVC (e.g., on a “per-session basis”).

124. McCullough teaches that a VPN tunnel (IVC or SVC) can have

various traffic filters applied so that only specific private data can travel over the

tunnel between private sites. (Ex. 1018 at [0069], [0070].) In other words, the

gateways apply security criterion so that only certain private data (e.g,. data

requiring more secure transport) can use the VPN tunnels.

Pearce (Ex. 1019) 125. As another example of prior art in this field, U.S. Patent No.

5,910,951 by Michael David Pearce, Rodd Bryan Zurcher, and Lewis B.

Oberlander entitled “Transmitting Device with Mobility Manager and Method of

Communicating” (“Pearce”) issued on June 8, 1999, which is more than 1 year

before the earliest priority date of the ‘235 Patent. Thus, I understand that Pearce

qualifies as prior art to the ‘235 Patent at least under 35 U.S.C. § 102(b).

126. Pearce discloses a transmitting device connected to a receiving device

via a multiplicity of qualifying networks in parallel with one another as shown in

FIG. 1, below. (Ex. 1019 at 1:55-62; FIG. 1.) Pearce discloses several disparate

networks that may operate in parallel, including private circuit-switched networks



-64-

such as circuit-switched cellular, analog cellular, Plain Old Telephone System

(POTS) modem, and Integrated Services Digital Network (ISDN) as well as

packet-switched networks such as Cellular Digital Packet Data (CDPD) (which

are part of Internet access), Ethernet, and paging networks. (Ex. 1019 at 1:55-62,

2:18-22.) At least because Pearce is directed to an analogous field of art (data

networking) and directed to solving analogous problems (routing to parallel

disparate networks), Pearce is analogous art to the ‘235 Patent.

127. In Pearce, the transmitting device includes a mobility manager which

stores a table of the various networks and their characteristics. (Ex. 1019 at 2:1-

16.) When the transmitting device is preparing to send a data object, it compares

the attributes of the data object (e.g., size, priority, sender, etc.) and the

characteristics of each network (such as cost, speed, type of network) and

generates a prioritized list of qualifying networks with varying priorities over

which the data object may be transferred. (Ex. 1019 at 2:14-30.) A message

assembler then appends this list to the data object and passes it to a

communication manager, (analogous to the controller of ‘235). (Ex. 1019 at 2:31-

42; FIG. 2.) The communications manager (e.g., the “packet path selector”) then

selects the highest priority network from the list appended to the data object and

transmits the data over the selected network to the receiving device, to the extent

that network is available. (Ex. 1019 at 2:61-3:5.) The data object is transmitted in



-65-

blocks (e.g., “on a per-packet basis”) to the receiving device. (Ex. 1019 at 5:20-

26.) Moreover, Pearce continually checks for the availability of its networks.

Should a network fail, Pearce would immediately transmit the remaining packets

of a block over a viable network. (Ex. 1019 at 5:44-48.)

128.

129. In Pearce, a network availability monitor at the transmitting device

may detect a newly available network, (Ex. 1019 at 4:13-16.) or the failure of an

existing network. (Ex. 1019 at 5:38-57) This is done on a per packet basis. The

newly available network is then evaluated for priority and compared to the

prioritized list of qualifying networks, where it can be used to transmit a data

block if it is ranked higher than other networks. In this way, the transmission is

always being sent over the highest-priority qualifying network on a per packet



-66-

basis. (Ex. 1019 at 4:3-47.) As Pearce explains, “Procedures for transmitting

and receiving transmission requests while automatically switching among

qualifying networks result in the transmission request being transferred reliably

over the highest-priority qualifying network available for that transmission

request.” (Ex. 1019 at 3:1-5.)

Admitted Prior Art in the ‘048 Patent Specification 130. As described above the ‘048 Patent specification clearly admits that

the prior art includes the disclosure of disparate parallel network paths

comprising at least one private network path (such as a frame relay network) and

one Internet-protocol based network path (such as the public Internet or a VPN)

as illustrated in FIG. 5 of the ‘048 Patent (see, for example, Ex. 1003 at 4:20-22

and FIG. 5 as annotated herein).

131.

132. In particular, the ‘048 Patent specification discloses that the admitted

prior art of Fig. 5 specifically includes routing decisions for packets originating at

one site and destined for another site over at least two disparate parallel networks



-67-

wherein such routing decision considerations include a security criterion such as

the availability of a secure virtual private network (or VPN) link (see, for

example, Ex. 1003 at 4:1-10 and FIG. 5 as annotated herein).

133. The ‘048 Patent specification also clearly admits that the prior art

includes the disclosure of a router that selects a network path for data packets to

one or the other of at least two disparate parallel network paths on the basis of a

reliability criterion (i.e. for purposes of “fault tolerance”, “redundancy”,

“backup”, “disaster recovery”, “continuity”, or “failover”) (see, for example, Ex.

1003 at 3:16-25, 9:43-50 and FIG. 2). Additionally, the ‘048 Patent specification

also clearly admits that the prior art includes the disclosure of “Techniques and

tools for detecting network path failures” that are “generally well understood”

(see, for example, Ex. 1003 at 11:4-5).

134.



-68-

135. Similarly, with respect to the disparate parallel networks of FIG. 5, the

disclosure of the ‘048 Patent specification also clearly admits that the prior art

includes the disclosure of configuring the packet routing to “send all traffic over

a VPN 502” whenever the “frame relay” network “fails” (see, for example, Ex.

1003 at 4:17-19 and FIG. 5 as annotated herein).

136. The ‘048 Patent specification also clearly admits that the prior art

includes the disclosure of “Load-balancing algorithms” that “in general are well

understood” (see, for example, Ex. 1003 at 11:25-26).

Stevens Reference (Ex. 1007) 137. For example, amongst the numerous prior art references in this field,

the book TCP/IP Illustrated, Volume 1 by W. Richard Stevens, Addison-Wesley

Professional Computing Series, ISBN 0-201-63346-9, 1994 (“Stevens”) was a

printed publication available in the USA more than 1 year before the earliest

priority date of the ‘048 Patent (see, for example, Ex. 1007 at inside cover page).

Thus, I understand that Stevens qualifies as prior art to the ‘048 Patent at least

under § 102(b).

138. According to Stevens, this “book describes the TCP/IP protocol suite”

and “provides a look into the implementation of the protocols” (see, for example,

Ex. 1007 at p. xv). Amongst the topics covered in Stevens are “TCP/IP

Layering”, “Internet Addresses”, “The Domain Name System”, “Port Numbers”,

and “The Internet” (see, for example, Ex. 1007 at pp. 6-16). At least because



-69-

Stevens is directed to an analogous field of art (data networking) and directed to

solving analogous problems (routing to redundant networks), Stevens is

analogous art to the ‘048 Patent (see also, ¶¶ 42 and 46 above).

139. More specifically, Stevens describes “IP: Internet Protocol” in

considerable detail including discussions on the “IP Header” and “IP Routing”

(see, for example, Ex. 1007 at pp. 33-41). In particular, Stevens discloses that

every IP datagram (or packet) comprises at least a 32 bit source address and a 32

bit destination address wherein each address comprises at least a network

identifier and a host identifier (see, for example, Ex. 1007 at pp. 8, 34-37, and

42). Stevens further discloses that IP routers maintain “routing tables” that can

associate particular routes amongst multiple possible routes with particular

network interfaces to such routes based upon stored “network addresses” (the

range of addresses corresponding to a network identifier) to which the destination

address in a given packet is compared (see, for example, Ex. 1007 at pp. 37-39).

140. Stevens also describes that “routing performs the following actions”

for each packet arriving at a router or gateway: i) “Search the routing table for an

entry that matches the complete destination IP address (matching network ID and

host ID)”, ii) “Search the routing table for an entry that matches just the

destination network ID”, and iii) “Search the routing table for an entry labeled

“default”” (see, for example, Ex. 1007 at p. 39). Stevens notes that only if i) and



-70-

ii) above “fail is a default route used” – that is when the packet’s destination

network address does not match any of those stored in the routing tables (see, for

example, Ex. 1007 at p. 39). Stevens also provides a specific example wherein a

“first search of the routing table for a matching host address fails, as does the

second search for a matching network address” and thus the “final step is a search

for a default entry, and this succeeds” thereby “sending a datagram across the

Internet to the host” (see, for example, Ex. 1007 at p. 115).

141. Stevens also describes “ping” and the “Internet Control Message

Protocol” (or “ICMP”) that can be used, for example, to perform a “basic

connectivity test between two systems running TCP/IP” (see, for example, Ex.

1007 at p. 96).

142. Stevens also discloses that “dynamic routing is normally used” in

networks with “redundant routes” (see, for example, Ex. 1007 at p. 127). Stevens

describes a particular dynamic routing protocol “Open Shortest Path First” (or

“OSPF”) as an example of a “link state protocol” that is advantageous when

“something changes, such as a router going down or a link going down” (see, for

example, Ex. 1007 at p. 138). More specifically, Stevens notes that when several

“routes to a destination exist, OSPF distributes traffic equally among the routes”

and that “This is called load balancing” (emphasis in original, see, for example,

Ex. 1007 at p. 138).



-71-

143. Note that Stevens is explicitly referenced within the specification of

the Karol patent to describe attributes of the CL-CO gateway (see, for example,

Ex. 1006 at 10:1-8) and thus a person of ordinary skill in the art at the time of the

invention would be specifically motivated to apply the disclosures of the Stevens

reference in combination with the disclosures of the Karol patent.

Stallings Reference (Ex. 1011) 144. For example, amongst the numerous prior art references in this field,

the book Data and Computer Communications by William Stallings, Prentice-

Hall, 5th Edition, 1997, ISBN-81-203-1240-6, (“Stallings”) was a printed

publication available in the USA more than 1 year before the earliest priority date

of the ‘048 Patent (see, for example, Ex. 1011 at inside cover page). Thus, I

understand that Stallings qualifies as prior art to the ‘048 Patent at least under §

102(b).

145. According to Stallings, this “book attempts to provide a unified

overview of the broad field of data and computer communications” (see, for

example, Ex. 1011 at p. vii). Amongst the topics covered in Stallings are “ATM”,

“Frame Relay”, “Packet Switching (Routing)”, “Internetworking”, and “Network

Security” (see, for example, Ex. 1011 at pp. 24-26). At least because Stallings is

directed to an analogous field of art (data and computer communication) and

directed to solving analogous problems (routing to redundant networks), Stallings

is analogous art to the ‘048 Patent (see also, ¶¶ 42 and 46 above).



-72-

146. More specifically, Stallings describes “frame relay” as “designed for

ISDN” but also used “in a variety of public and private networks that do not

follow the ISDN standards” (see, for example, Ex. 1011 at p. 302). In particular,

Stallings discloses that the “frame relay connection” that is “analogous to a

packet-switching virtual circuit” to support “multiple connections over a single

link” wherein each “connection” has “a unique data link connection identifier

(DLCI)” (see, for example, Ex. 1011 at p. 310). Stallings further discloses that in

Frame Relay “routing is controlled by entries in a connection table based on

DLCI” (see, for example, Ex. 1011 at p. 315). Stallings indicates that Frame

Relay was an outgrowth and replacement for X.25, a CO network disclosed by

Karol: “It is used in place of X.25, which consists of both a data link control

protocol (LAPB) and a network-layer protocol (called X.25 packet layer)” (see,

for example, Ex. 1011 at p. 186) “Frame relaying is designed to eliminate much

of the overhead that X.25imposes on end user systems and on the packet-

switching network” (see, for example, Ex. 1011 at p. 302).

147. Stallings discloses that a router “routes packets between potentially

different networks” including “connection-oriented (e.g. virtual circuit)” and

“connectionless (datagram)” service (see, for example, Ex. 1011 at pp. 528-531).

Additionally, Stallings informs that “Routing is generally accomplished by

maintaining a routing table” that “gives, for each possible destination network,



-73-

the next router to which the internet datagram should be sent” (see, for example,

Ex. 1011 at p. 539). Stallings notes that though the “routing table may be static or

dynamic”, a “dynamic table is more flexible in responding to both error and

congestion conditions” (see, for example, Ex. 1011 at p. 539). Stallings provides

the example that “when a router goes down, all of its neighbors will send out a

status report, allowing other routers and stations to update their routing tables”

(see, for example, Ex. 1011 at p. 539). Stallings also notes that a similar routing

table updating scheme “can be used to control congestion” and that “this is a

particularly important function because of the mismatch in capacity between

local and wide-area networks” (see, for example, Ex. 1011 at p. 539).

148. Stallings further discloses that “Routing tables may also be used to

support other internetworking services such as those governing security” (see, for

example, Ex. 1011 at p. 539). Stallings provides an example where “individual

networks might be classified to handle data up to a given security classification”

and thus the “routing mechanism must assure that data of a given security level

are not allowed to pass through networks not cleared to handle such data” (see,

for example, Ex. 1011 at p. 539).

149. Stallings also describes “source routing” whereby the “source station

specifies the route by including a sequential list of routers in the datagram” (see,

for example, Ex. 1011 at p. 539).



-74-

150. Stallings also describes “IP Protocol” in considerable detail including

discussions on the “IP Header”, “IP Addresses” and “Routing Protocols” (see, for

example, Ex. 1011 at pp. 543-549). In particular, Stallings discloses that every IP

datagram (or packet) comprises at least a 32 bit source address and a 32 bit

destination address wherein each address comprises at least a network identifier

and a host (or end system) identifier (see, for example, Ex. 1011 at pp. 535, 544-

545). Stallings further discloses that IP routers maintain “routing tables” that can

route packets to one of multiple network interfaces based upon the network

identifier (or “network portion of the IP address” that corresponds to the range of

end-system addresses associated with a particular route) to which the destination

address in a given packet is compared (see, for example, Ex. 1011 at pp. 535-536,

539, and 549). Per Stallings, each “constituent network” as identified by its

“network identifier” is a “subnetwork” that comprises all of the range of host (or

end system) identifiers within the subset range of possible destination or source

addresses (see, for example, Ex. 1011 at p. 528).

151. Stallings also describes the “Internet Control Message Protocol” (or

“ICMP”) that “provides feedback about problems in the communication

environment” and can be used, for example, to determine if a “datagram cannot

reach its destination” or to update a router that it can “send traffic on a shorter

route” (see, for example, Ex. 1011 at pp. 546-549).



-75-

152. Stallings further describes that a router “must avoid portions of the

network that have failed and should avoid portions of the network that are

congested” and that “In order to make such dynamic routing decisions, routers

exchange routing information using a special routing protocol” (see, for example,

Ex. 1011 at p. 549). In particular, Stallings discloses that such “routing

information” includes “Information about the topology” and the “delay

characteristics of various routes” (see, for example, Ex. 1011 at p. 549).

Exemplary “routing protocols” disclosed in Stallings include “Border Gateway

Protocol” (or “BGP”) and “Open Shortest Path First (OSPF) Protocol” (see, for

example, Ex. 1011 at pp. 550 and 556).

153. Stallings notes that for BGP, “Each router maintains a database of the

subnetworks that it can reach and the preferred route for reaching that

subnetwork” and that “Whenever a change is made to this database, the router

issues an Update message that is broadcast to all other routers” (see, for example,

Ex. 1011 at p. 552). Furthermore, Stallings concludes that these “Update”

messages enable “all of the BGP routers” to “build up and maintain routing

information” (see, for example, Ex. 1011 at p. 552).

154. Stallings describes OSPF in terms of a “link state routing algorithm”

wherein “Each router maintains descriptions of the state of its local links to

subnetworks, and from time to time transmits updated state information to all of



-76-

the routers of which it is aware” such that OSPF computes routes based on a

“user-configurable” function of “delay, data rate, dollar cost, or other factors”

and thus “is able to equalize loads over multiple equal-cost paths” (see, for

example, Ex. 1011 at p. 557).

155. Stallings also teaches the use of “Encapsulating Security Payload” or

(“ESP”) and in particular “Tunnel-mode ESP is used to encrypt an entire IP

packet” (see, for example, Ex. 1011 at p. 660). Stallings illustrates an exemplary

corporate WAN whereby a “virtual private network via tunnel mode” is used

over the Internet via a “security gateway” to each “internal network” for each

corporate site location (see, for example, Ex. 1011 at pp. 661-662 and FIGURE

18.23).

156. Note that Stallings is explicitly referenced within the specification of

the Karol patent to describe attributes of the CL-CO gateway (see, for example,

Ex. 1006 at 12:59-64) and thus a person of ordinary skill in the art at the time of

the invention would be specifically motivated to apply the disclosures of the

Stallings reference in combination with the disclosures of the Karol patent.

Hodgkinson (Ex. 1015) 157. Amongst the numerous prior art references in this field, U.S. Patent

No. 6,317,431 by Terence G Hodgkinson and Alan W O'Neill entitled “ATM

Partial Cut-Through” (“Hodgkinson”) was filed on Jun. 20, 1997, which is more

than 1 year before the earliest priority date of the ‘048 Patent (see, for example,



-77-

Ex. 1015 at (22)). Thus, I understand that Hodgkinson qualifies as prior art to the

‘048 Patent at least under § 102(e).

158. As Hodgkinson discloses in its “Background of the Invention”

section, the Hodgkinson patent is directed towards “transmission of data over

networks” (see, for example, Ex. 1015 at 1:4-5). The Hodgkinson patent

distinguishes between “connectionless” and “connection-oriented” networks (see,

for example, Ex. 1015 at 1:6-20). More specifically with respect to the common

knowledge of a person of ordinary skill in the art at that time, Hodgkinson

describes that “Telecommunication networks such as telephony, FR (Frame

Relay) and x25 are what is know as "connection-oriented"”, in contrast to

“connectionless” networks of which “the most significant connectionless network

is the Internet” (emphasis added, see, for example, Ex. 1015 at 1:9-10 and 1:18-

20). At least because Hodgkinson is directed to an analogous field of art (data

networking), Hodgkinson is analogous art to the ‘048 Patent (see also, ¶¶ 42 and

46 above).

159. At least because Hodgkinson explicitly discloses such default routing

to the Internet behavior as prior art to Hodgkinson’s filing in 1997, then

Hodgkinson’s description of frame relay as an example of connection-oriented

networking represents the common knowledge of a person of ordinary skill in the

art at the time of the alleged invention of the ‘048 Patent.



-78-

160. Note that the Hodgkinson patent was cited by the examiner of the

Karol patent (see, for example, Ex. 1006 at (56)) and thus a person of ordinary

skill in the art at the time of the invention would be specifically motivated to

apply the disclosures of the Hodgkinson patent in combination with the

disclosures of the Karol patent.



-79-

VIII. OBVIOUSNESS OF CLAIMS 1, 3-7, 9-13, AND 15-24 OF THE ‘048

PATENT UNDER 35 U.S.C. § 103

161. In my opinion, Karol in view of Zhang renders obvious at least

Claims 1, 3-4, 6-7, 9-10, 12-13, 15-16, 18-19, 21-22 and 24 of the ‘048 Patent for

at least the reasons described herein.

162. In my opinion, Karol in view of Zhang, further in view of

McCullough renders obvious at least Claims 1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21,

and 23 of the ‘048 Patent for at least the reasons described herein.

163. In my opinion, Karol in view of Pearce renders obvious at least

Claims 1, 3-4, 13, and 15-16 of the ‘048 Patent for at least the reasons described

herein.

164. A general overview of Karol is given at ¶¶ 82-110 above.

165. In my opinion, Karol fully enabled a person of ordinary skill in the art

to practice the subject matter as described above and as applied to relevant

elements of Claims 1, 3-7, 9-13, 15-19, and 21-24 of the ‘048 Patent without

undue experimentation at least to the extent that the ‘048 Patent is considered to

provide an enabling written description of the same elements of such claims and

at least based on the standard that Patent Owner sets regarding alleged

infringement contentions for Petitioner’s products with respect to the same

elements of such claims. In addition, to the extent that Karol is used as an



-80-

obviousness reference to Claims 1, 3-7, 9-13, 15-19, and 21-24 of the ‘048 Patent

in my analyses herein, Karol is also analogous art to the ‘048 Patent (see ¶ 83

above). Similarly, to the extent that Zhang is used as an obviousness reference to

Claims 1, 3-7, 9-13, 15-19, and 21-24 of the ‘048 Patent in my analyses herein,

Zhang is also analogous art to the ‘048 Patent (see ¶ 112 above). Similarly, to the

extent that McCullough is used as an obviousness reference to Claims 1, 3-7, 9-

13, 15-19, and 21-24 of the ‘048 Patent in my analyses herein, McCullough is

also analogous art to the ‘048 Patent (see ¶ 118 above). Similarly, to the extent

that Pearce is used as an obviousness reference to Claims 1, 3-7, 9-13, 15-19, and

21-24 of the ‘048 Patent in my analyses herein, Pearce is also analogous art to the

‘048 Patent (see ¶ 126 above).

166. My specific analysis of Karol, Zhang, McCullough, and Pearce with

respect to every claim element of Claims 1, 3-7, 9-13, 15-19, and 21-24 of the

‘048 Patent is given herein.

‘048 Patent: Claim 1 1. A controller which controls access to multiple independent disparate networks in a parallel network configuration, the disparate networks comprising at least one private network and at least one network based on the Internet, the controller comprising:

a site interface connecting the controller to a site; at least two network interfaces which send packets toward the

disparate networks; and a packet path selector which selects between network interfaces,

using at least two known location address ranges which are respectively associated with disparate networks, according to at least: a destination of the packet, an optional presence of alternate paths to that destination,



-81-

and at least one specified criterion for selecting between alternate paths when such alternate paths are present;

wherein the controller receives a packet through the site interface and sends the packet through the network interface that was selected by the packet path selector.

1(a). A controller which controls access to multiple independent disparate networks in a parallel network configuration, the disparate networks comprising at least one private network and at least one network based on the Internet, the controller comprising:

167. In my opinion, this preamble is a claim limitation.

168. Karol discloses systems and methods of operation thereof whereby a

“CL-CO gateway”, alone or in combination with one or more routers and/or

switches, controls access to either a “connectionless” (or “CL”) network data

path or to a parallel “connection oriented” (or “CO) network data path (see, for

example, Ex. 1006 at 1:7-16). Karol specifically describes the CL network as

being based upon the “Internet Protocol or "IP"” and the CO network as being

based upon “ATM, MPLS, RSVP” or a “telephony network” (see, for example,

Ex. 1006 at 1:7-16, 2:52-58) which is a disparate network. This is further

illustrated in and described with respect to FIG. 1 of Karol (see, for example, ¶¶

83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG. 1 as annotated herein).



-82-

169.

170. In view of Karol’s detailed description, either of the CL-CO gateway

or the combination of the CL-CO gateway with one or more routers and/or

switches discloses a combination of connections for the access network path that

an IP datagram (or “packet”) from the “source” at a first site or location would

take to a “destination” at second site or location. Karol describes the available

network paths as “two different, parallel routes” with one route being based upon

the connectionless Internet protocol and the other based upon a connection

oriented protocol such as “MPLS” (emphasis added, see, for example, Ex. 1006

at 4:40-44, ¶¶ 83-91 above). Karol also specifically discloses for the CL and CO





-83-


geographically distributed networks” (emphasis added, see, for example, Ex.

1006 at 3:47-51).

171. Thus, Karol discloses a “controller” (for example, either of the CL-

CO gateway or the combination of the CL-CO gateway with one or more routers

and/or switches shown in annotated FIG. 1 herein), that such controller “controls

access to multiple independent disparate networks in a parallel network

configuration” (for example, either of the CL-CO gateway or the combination of

the CL-CO gateway with one or more routers and/or switches shown in annotated

FIG. 1 herein is disclosed to route any given IP datagram or packet from source

to destination over one of the CL network path based on, for example, the

Internet protocol or the CO path based on, for example, the ATM or MPLS

protocol) and that such multiple networks are chosen from “disparate networks

comprising at least one private network and at least one network based on the

Internet” (for example, the CL path is based on Internet protocol service from a

first service provider and the CO path is based on ATM or MPLS protocol

service from a second service provider, wherein the CL path and the CO path are

described as “two different, parallel routes”).

172. Note that Patent Owner specifically alleges that a combination of a

packet routing appliance with other routers and/or switches connected to a first



-84-

network using an Internet protocol and a second network using an MPLS

protocol meets the limitations of this claim element under Patent Owner’s

proposed claim constructions (see, for example, Ex. 1016 at Appendix I at p. 1,

as reproduced herein). Thus, to the extent that Patent Owner’s theory of alleged

infringement by Petitioner’s products has any relevance to an analysis of this

claim element, then this also at least indicates that the disclosures of Karol meet

the limitations of this claim element.

173.

174. Therefore, in my opinion, Karol discloses the limitations of this claim

element under the broadest reasonable interpretation proposed herein (see ¶¶ 72-

74 and 77 above).

175. To the extent that in the alternative, the broadest reasonable

interpretation for meeting this claim element were considered to require that the



-85-

term “multiple independent disparate networks in a parallel network

configuration” should mean that at least one of the “alternate data paths” be over

“a frame relay or point-to-point network”, for example, then in my opinion the

knowledge and common sense of the person of ordinary skill in the art at the time

of the invention was sufficient to extrapolate from the disclosures of Karol to

such an interpretation at least because this was within the skill of person of

ordinary skill in the art at the time of the invention, obvious to try and yielded

predictable results as evident by at least the following reasons.

176. First, Karol discloses that the CO network can be represented as a

“non-broadcast network” that includes “point-to-point links” and that the CO

network can be a “telephony network” (see, for example, Ex. 1006 at 2:52-58,

13:55-67).

177. Second, the ‘048 Patent discloses in reference to “private networks”

that are “disparate” from networks based upon Internet protocol that such

networks may be “a point-to-point network, such as a T1 or T3 connection” (see,

for example, Ex. 1003 at 1:61-62).

178. Third, a person of ordinary skill in the art at the time of the invention

would understand that Karol’s disclosure that the CO network can be a

“telephony network” teaches that the CO network is a “private network” under

the alternate interpretation at least because the ‘048 Patent admits that “a point-



-86-

to-point network” can be a “T1 or T3 connection”, both of which are well known

to a person of ordinary skill in the art at the time of the invention to be examples

of Karol’s “point-to-point links” within a “telephony network”.

179. Fourth, a person of ordinary skill in the art at the time of the invention

would consider a “frame relay” network to be a well known example of a

connection oriented or CO network as described in Karol and moreover such

description is explicitly provided within the intrinsic record of Karol (see, for

example, ¶¶ 146 and 158-159 above). At least because only a finite number of

CO networks appropriate to the disclosures in Karol of “combining connections

for access” to an Internet-based network in parallel with a CO network from a

second provider were known at the time of the invention, such as MPLS, ATM or

frame relay CO networks, a person of ordinary skill in the art at the time of the

invention would have found substituting for an MPLS or ATM exemplary CO

network as explicitly disclosed in Karol with a known frame relay exemplary CO

network to be obvious to try in the context of Karol and this claim element.

Furthermore, at least because the characteristics of such MPLS, ATM, or frame

relay exemplary CO networks would have been readily understood by a person of

ordinary skill in the art at the time of the invention, such a substitution to a frame

relay CO network would be highly likely to produce a successful and predictable

result.



-87-

180. Fifth, the ‘048 Patent explicitly admits that a person of ordinary skill

in the art at the time of the invention would have known about routing packets

across multiple parallel disparate networks wherein a first network is Internet-

based and a second network that is frame relay based (see, for example, ¶¶ 130-

131 above). At least because only a finite number of CO networks appropriate to

the disclosures in Karol of “combining connections for access” to an Internet-

based network in parallel with a CO network from a second provider were known

at the time of the invention, such as MPLS, ATM or frame relay CO networks, a

person of ordinary skill in the art at the time of the invention would have found

substituting for an MPLS or ATM exemplary CO network as explicitly disclosed

in Karol with a known frame relay exemplary CO network to be obvious to try in

the context of Karol and this claim element. Furthermore, at least because the

characteristics of such MPLS, ATM, or frame relay exemplary CO networks

would have been readily understood by a person of ordinary skill in the art at the

time of the invention, such a substitution to a frame relay CO network would be

highly likely to produce a successful and predictable result.

181. At least because Karol in view of the knowledge of the person of

ordinary skill in the art renders obvious the limitations of this claim element

under the narrower alternative interpretation described above (see ¶ 175 above),

then Karol in view of the knowledge of the person of ordinary skill in the art also



-88-

renders obvious the limitations of this claim element under the broadest

reasonable interpretation of this claim element (see ¶¶ 72-74 and 77 above).

182. Therefore, in my opinion, Karol in view of the knowledge of the

person of ordinary skill in the art renders obvious the limitations of this claim

element either under the broadest reasonable interpretation of this claim element

(see ¶¶ 72-74 and 77 above) or under the alternative interpretation described

above (see ¶ 175 above).

1(b): a site interface connecting the controller to a site; 183. Karol discloses systems and methods of operation thereof whereby the


switches, comprises at least one “interface” that connects the “controller” of

Karol (see, for example, ¶¶ 168-171 above) with “a source endpoint” or “a

destination endpoint” at an “enterprise” location (see, for example, Ex. 1006 at

3:44-51, 4:36-44, 4:65-67, and FIG. 1 as annotated herein in ¶ 169 above). More

specifically, Karol discloses an exemplary depiction of structural elements within

the CL-CO gateway wherein one or more “input line cards 401” are utilized to

connect the CL-CO gateway to local network routers/switches and

source/destination endpoints via a network connection as further illustrated in and

described with respect to FIG. 4 of Karol (see, for example, ¶¶ 92-95 above, Ex.

1006 at 6:44-50 and FIG. 4 as annotated herein). In addition, the source endpoint

can be connected directly to a CL-CO gateway: [a]lso, the source or destination



-89-

may be directly connected to a CL-CO gateway (e.g., gateway 140) as opposed to

being connected through a CL node.” (Ex. 1006 at 5:5-8).

184.

185. Alternatively, the combination of the CL-CO gateway and with one or

more routers and/or switches shown in annotated FIG. 1 herein also depicts an

“interface” to an exemplary “source endpoint 101” that is “directly connected to

and served by” a local router (“node 111” in “CL network 110”) at an

“enterprise” location in the form of a network connection (see, for example, Ex.

1006 at 3:44-51, 4:36-44, 4:65-67, and FIG. 1 as annotated herein in ¶ 169

above).

186. Thus, Karol discloses a “controller” (for example, the CL-CO

gateway) that is connected to a “site” (for example, local network

routers/switches and/or source/destination endpoints) via a “site interface” (for

example, one or more of the input line cards and/or a network connection).



-90-

Alternatively, Karol also discloses a “controller” (for example, the CL-CO

gateway in combination with one or more routers and/or switches) that is

connected to a “site” (for example, source/destination endpoints) via a “site

interface” (for example, a network connection).


element under the broadest reasonable interpretation proposed herein (see ¶ 79

above).

188. At least because Karol discloses the limitations of this claim element,



reasonable interpretation of this claim element.

1(c): at least two network interfaces which send packets toward the disparate networks;

189. Karol discloses systems and methods of operation thereof whereby the


switches, comprises at least two “network interfaces” that connect the

“controller” of Karol (see, for example, ¶¶ 168-171 above) to both of the CL

network and the CO network (see, for example, Ex. 1006 at 3:58-66, 4:45-65, and

FIG. 1 as annotated herein in ¶ 169 above). More specifically, Karol discloses an

exemplary depiction of structural elements within the CL-CO gateway wherein at

least two “output line cards 402” are utilized to “receive datagrams from either



-91-

of” the “CO switch 410 or CL router/switch 420” and then “direct them to

external networks” as further illustrated in and described with respect to FIG. 4 of

Karol (see, for example, ¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as

annotated herein in ¶ 184 above). Note that while FIG. 4 of Karol illustrates only

one symbol “402” for the “output line cards”, this clearly discloses at least two

such “output line cards” that send packets over network interfaces to the two

respective CL and CO networks as evident at least by the two paths depicted into

symbol “402” in FIG. 4, the written description of FIG. 4 within Karol, the use of

the plural “output line cards” instead of the singular “output line card” within

symbol “402” in FIG. 4, and the two network interfaces depicted from the CL-

CO gateway to nodes “112” and “161” in FIG. 1 (see, for example, Ex. 1006 at

4:36-67, FIG. 1, and FIG. 4). Moreover, the ABSTRACT of Karol explicitly

discloses two interfaces: “each CL-CO gateway includes hardware and software

modules that typically comprise (a) interfaces to the CO network, (b) interfaces

to the CL network” (see Ex. 1006 at Abstract). A POSITA would understand that

these interfaces could be for both inputs and outputs as traffic is typically bi-

directional.


more routers and/or switches shown in annotated FIG. 1 herein also depicts at

least two “network interfaces” to both of the CL network and the CO network



-92-

that are depicted as exemplary router “node 121” and exemplary CO switching

element “node 161” (see, for example, Ex. 1006 at 3:58-66, 4:45-65, and FIG. 1

as annotated herein in ¶ 169 above).


gateway) that has at least two “network interfaces” (for example, the output line

cards respectively coupling the CL router to the CL network and the CO switch

to the CO network), which “send packets toward” the “disparate networks” (for

example, the CL and CO networks). Alternatively, Karol also discloses a

“controller” (for example, the CL-CO gateway in combination with one or more

routers and/or switches) that has at least two “network interfaces” (for example,

the network connections to respective CL and CO networks), which “send

packets toward” the “disparate networks” (for example, the CL and CO

networks).



above).







-93-

1(d): a packet path selector which selects between network interfaces, using at least two known location address ranges which are respectively associated with disparate networks, according to at least: a destination of the packet, an optional presence of alternate paths to that destination, and at least one specified criterion for selecting between alternate paths when such alternate paths are present;



switches, comprises at least a “gateway processor”, a “CL router/switch”, a “CO

switch”, a “packet buffer”, a “protocol converter” and one or more “input line

cards” that together are used to determine if a particular packet (or “datagram”)

from a “source endpoint” should be forwarded to either of the “CL network” or

the “CO network” based on multiple criteria including whether or not a valid

connection through the CO network is presently available for the particular

packet as further illustrated in and described with respect to FIG. 4 of Karol (see,

for example, ¶¶ 92-95 above, Ex. 1006 at 6:31-50 and FIG. 4 as annotated

herein).



-94-

195.

196. As Karol discloses explicitly, “datagrams received in input line cards

401 can be directed either to CO switch 410 or CL router/switch 420” so that

“output line cards 402 can receive datagrams from either of the last mentioned

elements and direct them to external networks” (see, for example, ¶¶ 92-95

above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 184 above).

197. Karol discloses with respect to the CL network that the “datagram

forwarding database 432” is “the database used in typical CL IP routers” that

“stores the next hop router address and outgoing port number corresponding to

each destination address” and thus the “fields in each record in this database

would be: Destination IP address; Next hop router; Outgoing port (interface)”

(emphasis added, see, for example, Ex. 1006 at 7:36-41 and ¶ 94 above). Karol

discloses in reference to FIG. 4 that “the processes performed in CL-CO



-95-

gateways that enable the internetworking of connectionless IP networks and CO

networks” accomplish two primary functions that are i) handling “IP packets that

arrive at CL-CO gateways to be carried on (not-yet-established) connections in

the CO network, plus IP packets that arrive at CL-CO gateways but then remain

in the CL network”, and ii) creating “routing tables that enable data flow from the

CL network to the CO network” (see, for example, Ex. 1006 at 7:60-8:2). Thus,

on a packet-by- packet basis, it must be determined whether a connection has

been established in the CO network. If a connection has not yet been established

in the CO network, then the packet could continue on in the CL network, using

e.g. a “source routing” implementation: “First, the gateway can turn back IP

datagrams to the CL network using IP source routing to override routing tables at

the routers” (Exhibit 1006 at 8:51-53). This would constitute determining a path

depending on the presence (or absence) of an alternative path to a destination.

198. Similarly, Karol discloses with respect to the CO network that “flow

database 433” is used to “determine how to handle packets from flows requiring

a connection-oriented service” wherein “Typical fields in each record in this







-96-




particular record” (emphasis added, see, for example, Ex. 1006 at 7:42-54 and ¶

95 above).

199. Karol also discloses methodologies for obtaining the routing table

information, which include the location address ranges associated with the CL

and CO network paths as shown above, such as having “the network provider can

set user-specific routing tables at the CL-CO gateways” so that “the user-specific

routing then determines which users' flows are sent to the CO network” versus

those that are routed to the CL network (emphasis added, see, for example, Ex.

1006 at 16:3-9 and ¶¶ 104-108 above). Karol similarly discloses processes for

obtaining “updates” to such routing tables (see, for example, Ex. 1006 at 13:6-16,

FIG. 8, and ¶¶ 104-108 above).

200. Karol summarizes the use of the gateway processor by noting that

“the processes performed in CL-CO gateways that enable the internetworking of

connectionless IP networks and CO networks” accomplish two primary functions

that are i) handling “IP packets that arrive at CL-CO gateways to be carried on

(not-yet-established) connections in the CO network, plus IP packets that arrive

at CL-CO gateways but then remain in the CL network”, and ii) creating “routing



-97-

tables that enable data flow from the CL network to the CO network” (see, for

example, Ex. 1006 at 7:60-8:2).

201. Karol further describes that such routing selections between the CL

and CO networks be based at least upon “bandwidth availability” that can be

“dynamically allocated to flows on an as-needed basis” and thus be “diverting

connections away from congested links” (see, for example, Ex. 1006 at 17:18-26

and 17:63-18:2).

202. Thus, Karol discloses a “packet path selector” (for example, the

structural elements depicted in annotated FIG. 4 herein in ¶ 195 above) that

“selects between network interfaces” (for example, the depicted packet path

selector of FIG. 4 compares information in each packet received at the CL-CO

gateway to determine if the packet will be routed to the CL network interface

output line card or to the CO network interface output line card) according to at

least “a destination of the packet” (for example, gateway processor in the CL-CO

gateway compares the destination address of each received packet to fields in

both the forwarding and flow databases), “an optional presence of alternate paths

to that destination” (for example, the gateway processor will only forward a

particular packet to the CO network when a valid connection exists for the flow

associated with the particular packet), and “at least one specified criterion for

selecting between alternate paths when such alternate paths are present” (for



-98-

example, based upon the needs of a particular flow or to avoid congested links),

and wherein such a “packet path selector” is “using at least two known location

address ranges which are respectively associated with disparate networks” (for

example, the addresses stored in the routing tables for routing packets to the CL

network and the addresses stored in the routing tables for routing packets to the

CO network).



above).

204. In the event the Board determines that Karol fails to teach or suggest

“selects between network interfaces, using at least two known location address

ranges which are respectively associated with disparate networks,” this feature is

clearly disclosed in Zhang. Zhang describes per-user routing tables that maintain

entries for each network that is currently accessible to the user. Zhang teaches

“[e]ach entry 254 may contain a range of addresses 256, indicating the network

addresses which correspond to the corresponding accessible network”. (Ex. 1017

at 4:21-32, FIG. 6 (emphasis added).) Zhang describes an IP packet which

contains a “source address” and a “destination address”, while noting that

“[o]ther protocols contain similar fields”. (Ex. 1017 at 4:14-16.) When the packet

arrives at a gateway, the gateway extracts the source address in order to “find a



-99-

per-user routing table corresponding to the user who sent the packet”. (Ex. 1017

at 4:19-20.) Subsequently, “a destination address… is extracted from the packet”

and “entries… of the matching per-user routing table are traversed (or otherwise

searched), looking for a range of network addresses… containing the destination

address”. (Ex. 1017 at 4:50-61.)

205. In my opinion, it would have been obvious to use the network address

ranges of Zhang’s per-user routing tables within Karol’s “packet path selector” in

order to select “between network interfaces” providing access to parallel

disparate networks. A POSITA would have combined Karol in view of Zhang as

described above for several reasons. First, using the per-user routing tables

disclosed in Zhang with Karol would have amounted to nothing more than the

use of a known technique to improve similar methods in the same way or the

combination of prior art elements according to known methods to yield

predictable results. KSR v. Teleflex, 550 U.S. 398, 417 (2007); MPEP § 2143.

Karol teaches that its parallel network configuration offers “enterprises ‘long-

distance’ connectivity of their geographically distributed networks.” (Ex. 1006 at

3:46-51.) A POSITA, recognizing the motivation to connect remote enterprise

networks would have understood that network address ranges as taught by Zhang

would have been applicable to the operation of Karol’s gateway. Zhang depicts a

router 88 connecting a LAN to gateway 82. (Ex. 1017 at FIG. 2.) On the



-100-

destination side, Zhang teaches network address ranges for multiple available

networks each with a router providing connectivity. (Ex. 1017 at 5:65-6:2.)

Karol describes the source endpoint 101 as “a personal computer, workstation, or

other processor attached to any information source.” (Ex. 1006 at 4:36-38.) A

POSITA would have recognized that, similar to Zhang, a router serving a local

area network (LAN) (with an associated range of addresses) was a potential

“source of information” in Karol. In the same way, a router serving a LAN

would have been viewed as a valid destination endpoint by a POSITA.

Alternatively, networks 110 and 130 may be viewed as the “geographically

distributed networks” analogous to Zhang’s corporate intranets. (Ex. 1006 at FIG.

1). A POSITA would have recognized that implementing the routing tables

disclosed in Zhang with the method in Karol would enable Karol to “us[e] at least

two known location address ranges which are respectively associated with

disparate networks” and therefore send data over multiple parallel networks. A

POSITA would look to combine Zhang with Karol because Karol also describes

network addressing in routers over multiple parallel routes, and Zhang describes

additional routing characteristics of network addresses as well as methods to

obtain such network addresses. And a POSITA would have been motivated

because the combination would have predictable results.



-101-

206. Second, the combination of Karol and Zhang was obvious to try. KSR,

550 U.S. at 417; MPEP § 2143. The need in the art was the ability to route to

multiple network locations based on the IP protocol. No other alternative than

the routing structure in Karol and Zhang was in common usage for IP protocol.

Thus, a POSITA would have pursued the combination with a high likelihood of

success.

207. Therefore, in my opinion, Karol in view of Zhang renders obvious the

limitations of this claim element under the broadest reasonable interpretation

proposed herein (see ¶ 74 above).

208. In the event that the Board finds that the requirement of “a packet path

selector which selects between network interfaces . . . according to at least . . .

one specified criterion for selecting between alternate paths when such alternate

paths are present” is not sufficiently disclosed by the combination of Karol and

Zhang, McCullough discloses this feature.

209. McCullough generally describes interconnecting remote private

computer networks using a public network with aggregated parallel multiple links

between the private networks and the public network. (Ex. 1018 at [0002].)

More specifically, McCullough describes a “gateway” capable of aggregating

multiple “tunnels” through the public network. (Ex. 1018 at [0055].) These

“tunnels” are described as “interior virtual circuits” (IVCs), each of which is a



-102-

peer-to-peer connection between an initiator gateway and a responder gateway

which includes a PPP link between the initiator and the public network, a

connection through the public network, and an equivalent PPP link between the

responder and the public network. (Ex. 1018 at [0055], FIG. 4.). McCullough

describes how a gateway may aggregate a group of IVCs to create a superior

virtual circuit (SVC) in order to distribute the packet load “approximately equally

over each of the IVCs.” (Ex. 1018 at [0055], [0056].) According to

McCullough, “[i]f this condition were not met, some of the IVCs would take

most of the load causing saturation of those IVCs while other IVCs would stand

idle.” (Ex. 1018 at [0056].) Accordingly, the gateway may fragment packets in a

message in order to distribute the packets “over the available IVCs to implement

load sharing” (e.g., “load balancing”). (Ex. 1018 at [0077] (emphasis added).)

When there is a large transfer of data between peer networks, a bundle manager

at the gateway can distribute 1500 byte fragments on each available link (IVC) in

a round-robin fashion in order to achieve load balancing. (Ex. 1018 at [0079].)

McCullough also describes a “bandwidth on demand module 142” at the gateway

that maintains threshold settings for each link (expressed as upper and lower

usage thresholds). (Ex. 1018 at [0095].) According to McCullough, “[w]hen set

appropriately by an operator these thresholds can throttle the data capacity of the

SVC such that if traffic drops below a certain level then a link may drop or if



-103-

traffic hits a certain upper threshold, then a new link can be added to carry

additional traffic through the SVC.” [Ex. 1018 at [0095].) Once the bandwidth

on demand module 142 adds an additional IVC link (based on current traffic

conditions at the gateway), the additional traffic will be routed through the new

IVC, thereby dynamically balancing the traffic load. Accordingly, McCullough

clearly teaches a criterion for selecting between alternate paths (IVCs) when such

alternate paths are present.

210. In my opinion, it would have been obvious to a POSITA to implement

applying dynamic load-balancing to the selecting step as taught by McCullough

within Karol’s gateway for accessing parallel disparate networks. First,

introducing the load-balancing functions of McCullough’s initiator and responder

gateways into the CL-CO gateways of Karol would have amounted to nothing

more than the use of a known technique to improve similar methods in the same

way or the combination of prior art elements according to known methods to

yield predictable results. KSR, 550 U.S. at 417; MPEP § 2143. Karol, Zhang,

and McCullough each disclose a “gateway” which provides access to one or more

networks. (Ex. 1006 at 3:30-51; Ex. 1017 at 1:57-64; Ex. 1018 at [0047].) In

each case, the gateway provides access for either a particular source connected to

the gateway or a collection of sources connected to the gateway, for example,

through a local area network (LAN). Karol discloses an embodiment in which



-104-

the source and destination are connected directly to their respective CL-CO

gateways. (Ex. 1006 at 5:5-8.) Both Zhang and McCullough disclose a gateway

that is directly connected to the site network. (Ex. 1017 at 1:57-64, FIG. 2; Ex.

1018 at [0047], FIG. 4.) In these configurations all traffic not destined to the

local network must pass through the gateway. Each of Karol, Zhang, and

McCullough similarly address the problem in the art of providing connectivity to

or between remote private networks (e.g., geographically distributed enterprise

networks). (Ex. 1006 at 3:46-51; Ex. 1017 at 1:31-40; Ex. 1018 at [0003]-

[0006].) Furthermore, McCullough teaches the Initiator and Responder gateways

are connected to the public network through “one or more links” and “that links

can be spread across multiple ISPs” (i.e., Internet service providers). (Ex. 1018 at

[0022], [0047].) A POSITA would have recognized the correspondence between

McCullough’s parallel links and Karol’s parallel disparate networks. Thus, a

POSITA would have had a reasonable expectation of success in drawing from the

teachings of McCullough regarding operation of parallel IVCs and applying them

to the more general setting of operation of a VPN through the CL network in

parallel with a connection through the CO network. More specifically,

performing path selection in a way that dynamically balances loads across a

plurality of both IVCs through the CL network and connections (i.e., calls)

through the CO network would have enabled effective aggregation of the



-105-

individual bandwidths of the parallel networks. Thus, a POSITA would have

been motivated to pursue this combination because it would have yielded

predictable results.

211. Second, the combination of Karol, Zhang, and McCullough was

obvious to try. KSR, 550 U.S. at 417; MPEP § 2143. Dedicated point-to-point

lines were a common solution at the time for providing fast, reliable, and


LAN in New York and one in Chicago. (Ex. 1018 at [0003]-[0005].) There were

known advantages at the time to connecting remote sites over the Internet (i.e., a

connectionless IP based network), particularly in terms of cost. (Ex. 1018 at

[0006]) There was a need in the art for a solution to connect remote private

networks through the Internet in a way that achieved the same guarantees in

terms of speed, reliability, and confidentiality as addressed by McCullough.

Additionally, here was a need in the art for parallel operation of these private

(e.g., CO) and Internet-based (e.g., CL) networks as addressed by Karol. A

POSITA would have recognized that load balancing was one of a set of well-

known criteria for distributing items, data, or tasks (e.g., packets) among parallel

resources (e.g., parallel disparate networks). For these reasons as well as for

those explained above, a POSITA would have pursued the combination of these

known solutions with a reasonable expectation of success.



-106-

212. Therefore, in my opinion, Karol in view of Zhang, further in view of

McCullough renders obvious the limitations of this claim element under the

broadest reasonable interpretation proposed herein (see ¶ 74 above).

213. Alternatively, in the event that the Board finds that the requirement of

“a packet path selector which selects between network interfaces . . . according to

at least . . . one specified criterion for selecting between alternate paths when

such alternate paths are present” is not sufficiently disclosed by Karol, this

feature is disclosed by Pearce.

214. Pearce discloses a transmitting device connected to a receiving device

via a multiplicity of qualifying networks in parallel with one another. (Ex. 1019

at 1:55-62; FIG. 1.) The transmitting device includes a mobility manager that

stores a table of the various available networks and their characteristics. (Ex.

1019 at 2:1-16.) When the transmitting device is preparing to send a data object,

it compares the attributes of the data object (e.g., size, priority, sender, etc.) and

the characteristics of each network (such as cost, speed, type of network) and

generates a prioritized list of qualifying networks with varying priorities over

which the data object may be transferred. (Ex. 1019 at 2:14-30.) A message

assembler then appends this list of networks to the data object and passes it to a

communication manager. (Ex. 1019 at 2:31-42; FIG. 2.) The communications

manager (e.g., the “packet path selector”) then selects the highest priority



-107-

network from the list appended to the data object and transmits the data over the

selected network to the receiving device, to the extent that network is available.

(Ex. 1019 at 2:61-3:5.)

215. By describing a “prioritized list” of qualifying networks, Pearce

discloses “one specified criterion for selecting between alternate paths when such

alternate paths are present.” In Pearce, a network availability monitor at the

transmitting device may detect a newly available network, (Ex. 1019 at 4:13-16.)

or the failure of an existing network. (Ex. 1019 at 5:38-57) This newly available

network is then evaluated for priority and compared to the prioritized list of

qualifying networks, where it can be used to transmit a data block if it is ranked

higher than other networks. (Ex. 1019 at 4:30-47.) In other words, the “specific

criterion” for selecting between alternate networks in Pearce is based on each

networks respective priority ranking.

216. In my opinion, it would have been obvious to a POSITA to perform

packet path selection according to network priority and availability on a per-

packet basis as taught by Pearce in order to aid the function of the gateway

processor in Karol. First, combining packet path selection as disclosed in Pearce

with Karol would have amounted to nothing more than the use of a known

technique to improve similar methods in the same way or the combination of

prior art elements according to known methods to yield predictable results. KSR,



-108-

550 U.S. at 417; MPEP § 2143. Karol recognizes that the CO network is initially

unavailable for a flow of packets while a connection is being established and may

route packets through the CL network in the interim. (Ex. 1006 at 4:12-23, 5:51-

54.) Pearce expands on this approach by teaching a method in which the

availability of all networks is continuously monitored during the transmission of

a flow and the transmission is adapted on a per-packet basis in response. (Ex.

1019 at 4:13-5:6, 5:23-26.) Similarly, both Karol and Pearce recognize the need

to account for both the requirements of the user and the capabilities of the parallel

networks and teach that certain traffic will require a particular network (e.g.,

Pearce only identifies “qualifying networks” on its priority list). (Ex. 1019 at

2:24-30.) Similarly, Karol discloses that there is certain “traffic that requires a

connection.” (Ex. 1006 at 15:46.) A POSITA would have been motivated to

pursue this combination because it would have yielded predictable results.

217. Second, the combination of Karol and Pearce was obvious to try.

KSR, 550 U.S. at 417; MPEP § 2143. Karol and Pearce are both directed to the

need in the art to exploit the availability of parallel networks. (Ex. 1006 at 1:50-

51, 2:13-19; Ex. 1019 at Abstract.) Pearce provides a method for packet path

selection which supports parallel use of a variety of network types, including

connection-oriented and connectionless networks. (Ex. 1019 at 1:6-22, 2:18-22.)



-109-


success.

218. Therefore, in my opinion, Karol in view of Pearce renders obvious the



1(e): wherein the controller receives a packet through the site interface and sends the packet through the network interface that was selected by the packet path selector.



switches, receives datagrams (or “packets”) and such “datagrams received in

input line cards 401 can be directed either to CO switch 410 or CL router/switch

420” so that “output line cards 402 can receive datagrams from either of the last

mentioned elements and direct them to external networks” (see, for example, ¶¶

92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 184 above).

An exemplary process for determining the network path selection and actual

forwarding to the CL or CO network interface is described in detail at FIG. 5 of

Karol (see, for example, ¶¶ 97-100 above, Ex. 1006 at 8:56-9:36 and FIG. 5 as

annotated herein). Note boxes 529 and 521 that read “FORWARD

DATAGRAM AS PER ENTRY”.



-110-

220.


structural elements depicted in annotated FIG. 4 herein in ¶ 195 above) within a

“controller” (for example, the CL-CO gateway) that “receives a packet” (for

example, IP datagram from the source endpoint is routed to the CL-CO gateway)

through the “site interface” (for example, one or more of the input line cards

and/or a network connection) and then “sends the packet through the network

interface that was selected by the packet path selector” (for example, the depicted

packet path selector of FIG. 4 compares information in each packet received at

the CL-CO gateway and then routes each packet either to the CL network



-111-

interface output line card or to the CO network interface output line card

according to the process described in FIG. 5).



above).





‘048 Patent: Claim 3 3. The controller of claim 1, wherein the packet path selector selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

3. The controller of claim 1, wherein the packet path selector selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

224. Karol either anticipates or Karol in view one or more of Zhang,

McCullough, and Pearce renders obvious the recited Claim 1 of this claim

element under either the broadest reasonable interpretation or the various

alternative interpretations described above for at least the reasons summarized in

¶¶ 167-223 above.



-112-



switches, comprises a “packet path selector” that selects between either a

“connectionless” (or “CL”) network data path or to a “connection oriented” (or

“CO) network data path (see, for example, Ex. 1006 at 1:7-16). Karol specifically

describes the CL network as being based upon the “Internet Protocol or "IP"” and

the CO network as being based upon “ATM, MPLS, RSVP” or a “telephony

network” (see, for example, Ex. 1006 at 1:7-16, 2:52-58). This is further


83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG. 1 as shown in ¶ 169 above).

226. Karol discloses an exemplary depiction of structural elements within

the CL-CO gateway wherein at least two “output line cards 402” are utilized to

“receive datagrams from either of” the “CO switch 410 or CL router/switch 420”

and then “direct them to external networks” as further illustrated in and described

with respect to FIG. 4 of Karol (see, for example, ¶¶ 92-95 above, Ex. 1006 at

6:44-50 and FIG. 4 as annotated herein in ¶ 184 above).







-113-







shown in ¶ 220 above).

228. Additionally, Karol provides numerous examples of how the

“gateway processor 430” and “flow database 433” interact to determine whether

a particular packet belongs to a flow directed to the CO network or the CL

network. For example, some flows correspond to sessions or applications such as

“web access, telnet, file transfer, electronic mail, etc” that utilize the TCP

transport layer while others such as “Internet telephony and other multimedia

traffic” may use the “RTP (Real Time Protocol)” that “has been defined to use

UDP” transport layer (see, for example, Ex. 1006 at 10:25-39 and FIG. 6). As

Karol explains, certain packets carrying either TCP or UDP segments within

certain sessions or applications as listed above are appropriate for a flow to the

CO network while others are better directed to the CL network (see, for example,

Ex. 1006 at 10:51- 11:26 and FIG. 6).



-114-








dynamically allocated to flows on an as-needed basis” (emphasis added, see, for

example, Ex. 1006 at 17:18-26). In particular Karol notes that “dynamically

adjusting link weights in the routing protocol can also be extended to include

diverting connections away from congested links” or “In other words, link

weights can be adjusted to reflect bandwidth availability” (emphasis added, see,

for example, Ex. 1006 at 17:63- 18:2). Also "[i]n the parallel configuration, since

at least two paths exist between the originating and destination CL nodes, one

using the CL network and the other using the CO network, there is always a

routing choice, i.e., CL to CO to CL or entirely CL. The gateway can make the

routing selection based on maximizing efficiency.” (Exhibit 1006 at 3:61-66,

emphasis added). Karol also discloses that “[t]he decision to set up CO

connections is made at CL-CO gateway 140, based on the user-specified service

requirements and the traffic situation in the CL and CO networks.” (Exhibit



-115-

1006 at 5:35-38, emphasis added). A POSITA would understand that load-

balancing is a means of maximizing efficiency and accounting for “the traffic

situation” is part of load-balancing.

230. Thus, Karol discloses the “packet path selector” that selects between

“network interfaces” (for example, as described in ¶¶ 194-202 above), and further

that such selection be made “according to a load-balancing criterion” (for

example, the flows at CL-CO gateway that get routed to the CL or CO network

are dynamically allocated in an as-needed basis to dynamically divert away from

congested links based upon a bandwidth availability criterion), thereby

“promoting balanced loads on devices that carry packets on the selected path

after the packets leave the selected network interfaces” (for example, the

adjustment of link weights to reflect bandwidth availability avoids congested

links such that balanced bandwidth utilization is achieved between the CL and

CO networks).

231. Note that Patent Owner specifically alleges that a packet routing

appliance meets the limitations of this claim element under Patent Owner’s

proposed claim constructions based upon the following documented description:

“In the face of network brownouts or soft failures, performance degradation can

be minimized. The tracking of network and path conditions by application-aware

routing in real time can quickly reveal performance issues, and it automatically



-116-

activates strategies that redirect data traffic to the best available path. As the

network recovers from the brownout or soft failure conditions, application-aware

routing automatically readjusts the data traffic paths.” (see, for example, Ex.

1016 at Appendix I at p. 12). Thus, to the extent that Patent Owner’s theory of

alleged infringement by Petitioner’s products has any relevance to an analysis of

this claim element, then this also at least indicates that the disclosures of Karol

meet the limitations of this claim element.



above).

233. To the extent the Board determines that the combination of Karol and

Zhang fail to teach or suggest “wherein the packet path selector selects between

network interfaces according to a load-balancing criterion, thereby promoting

balanced loads on devices that carry packets on the selected path after the packets

leave the selected network interfaces,” McCullough discloses these features as

described above in ¶¶ 208-209 with respect to claim 1[d]. It would have been

obvious to combine McCullough with Karol and Zhang for all the reasons

described in ¶¶ 210-211 above with respect to claim 1[d]. Thus, it is my opinion

that the combination of Karol, Zhang and McCullough render this claim obvious.



-117-


“wherein the packet path selector selects between network interfaces according to

a load-balancing criterion” is not sufficiently disclosed by Karol, claim 3 is

rendered obvious over Karol in view of Pearce. Pearce also teaches that available

networks may be prioritized according to “cost (whether it is cost per byte,

whether it is cost per minute, and whether the cost changes during the day or

week).” (Ex. 1019 at 2:15-18.) A POSITA would understand that cost is a tool

that network providers may vary in order to encourage users to balance network

loads. By varying network costs throughout the day or week, a gateway serving

the interests of the user will prioritize networks in a way that “promote[s] load-

balancing”.

235. It would have been obvious to a POSITA to combine Pearce’s

teachings of network prioritization and highest priority network selection with the

gateway processor of Karol to achieve a “packet path selector” capable of

selecting between interfaces “according to a load-balancing criterion”. First,

combining packet path selection as disclosed in Pearce with Karol would have

amounted to nothing more than the use of a known technique to improve similar

methods in the same way or the combination of prior art elements according to

known methods to yield predictable results. KSR, 550 U.S. at 417; MPEP § 2143.

The “prioritized list of qualified networks” which account for real-time network



-118-

costs as disclosed in Pearce (e.g., Ex. 1019 at 2:1-24) was a known technique for

“packet path selection.” Similarly, Karol recognizes that certain sessions are

more appropriate for transfer over the CO network while others more appropriate

for the CL network. (Ex. 1006 at 10:51-11:26.) Thus, a POSITA would have

recognized that implementing a method of selecting the highest priority network

from a prioritized list of qualifying networks as taught by Pearce within the

gateway processor of Karol would have enabled “packet path selection” in a way

that “promote[s] load-balancing”. And a POSITA would have been motivated

because the combination would have predictable results.

236. Second, the combination of Karol and Pearce was obvious to try.

KSR, 550 U.S. at 417; MPEP § 2143. Karol and Pearce are both directed to the

need in the art to exploit the availability of parallel networks. Pearce and Karol

provide methods for packet path selection which support parallel uses of a variety

of network types, including connection-oriented and connectionless networks.

(Ex. 1006 at 1:50-51, 2:13-19; Ex. 1019 at Abstract, 1:6-22, 2:18-22.) Thus, a

POSITA would have pursued the combination with a high likelihood of success.






-119-

‘048 Patent: Claim 4 4. The controller of claim 1, wherein the packet path selector selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.

4. The controller of claim 1, wherein the packet path selector selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.

238. Karol either anticipates or Karol in view of one or more of Zhang




¶¶ 167-223 above.

239. Generally, Karol’s invention is directed to selecting paths between

two disparate networks if there is “an advantage from the user or service provider

perspective” (Exhibit 1006 at 1:7-16). Karol also discloses that “[t]he decision to

set up CO connections is made at CL-CO gateway 140, based on the user-

specified service requirements and the traffic situation in the CL and CO

networks.” (Exhibit 1006 at 5:35-38, emphasis added). A POSITA would

understand that reliability would be one of the major concerns which would form

part of “user-specified service requirements”. Karol discloses systems and

methods of operation thereof whereby a “CL-CO gateway”, alone or in



-120-

combination with one or more routers and/or switches, comprises a “packet path

selector” that selects between either a “connectionless” (or “CL”) network data

path or to a “connection oriented” (or “CO) network data path (see, for example,

Ex. 1006 at 1:7-16). Karol specifically describes the CL network as being based

upon the “Internet Protocol or "IP"” and the CO network as being based upon

“ATM, MPLS, RSVP” or a “telephony network” (see, for example, Ex. 1006 at

1:7-16, 2:52-58). This is further illustrated in and described with respect to FIG. 1

of Karol (see, for example, ¶¶ 83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and

FIG. 1 as shown in ¶ 169 above).

240. Karol discloses an exemplary depiction of structural elements within

the CL-CO gateway wherein at least two “output line cards 402” are utilized to

“receive datagrams from either of” the “CO switch 410 or CL router/switch 420”

and then “direct them to external networks” as further illustrated in and described

with respect to FIG. 4 of Karol (see, for example, ¶¶ 92-95 above, Ex. 1006 at

6:44-50 and FIG. 4 as annotated herein in ¶ 184 above).








-121-







242. Additionally, Karol provides numerous examples of how the

“gateway processor 430” and “flow database 433” interact to determine whether

a particular packet belongs to a flow directed to the CO network or the CL

network. For example, some flows correspond to sessions or applications such as

“web access, telnet, file transfer, electronic mail, etc” that utilize the TCP

transport layer while others such as “Internet telephony and other multimedia

traffic” may use the “RTP (Real Time Protocol)” that “has been defined to use

UDP” transport layer (see, for example, Ex. 1006 at 10:25-39 and FIG. 6). As

Karol explains, certain packets carrying either TCP or UDP segments within

certain sessions or applications as listed above are appropriate for a flow to the

CO network while others are better directed to the CL network (see, for example,

Ex. 1006 at 10:51-11:26 and FIG. 6).





-122-






dynamically allocated to flows on an as-needed basis” (emphasis added, see, for

example, Ex. 1006 at 17:18-26). In particular Karol notes that “dynamically

adjusting link weights in the routing protocol can also be extended to include

diverting connections away from congested links” or “In other words, link

weights can be adjusted to reflect bandwidth availability” (emphasis added, see,

for example, Ex. 1006 at 17:63-18:2).

244. Thus, Karol discloses the “packet path selector” that selects between


that such selection be made “according to a reliability criterion” (for example, the

flows at CL-CO gateway that get routed to the CL or CO network are selected

based upon ensuring reliability for such flows by guaranteeing quality of service,

meeting bandwidth needs, and diverting away from congested links), thereby

“promoting use of devices that will still carry packets on the selected path after

the packets leave the selected network interfaces, when other devices on a path

not selected are not functioning” (for example, the adjustment of link weights to



-123-

reflect bandwidth availability avoids congested links such that if a link on either

of the CL and CO networks is not functioning due to inadequate bandwidth

availability, then use of the CL or CO network path with bandwidth availability

will be promoted).


under the broadest reasonable interpretation proposed herein (see ¶ 79 above).

246. Although the forgoing description of the disclosures within Karol

clearly shows meeting the limitations of this claim element, to the extent that

additional information disclosing “the packet path selector selects between

network interfaces according to a reliability criterion, thereby promoting use of

devices that will still carry packets on the selected path after the packets leave the

selected network interfaces, when other devices on a path not selected are not

functioning,” were deemed to be necessary to fully disclose this claim element,

then in my opinion Pearce discloses this feature.

247. Pearce describes procedures for transmitting and receiving data while

automatically switching among qualifying networks. (Ex. 1019 at 3:1-4.) As

Pearce explains, “Procedures for transmitting and receiving transmission requests

while automatically switching among qualifying networks result in the

transmission request being transferred reliably over the highest-priority

qualifying network available for that transmission request.” (Ex. 1019 at 3:1-5.)



-124-

The transmitting device also includes a network availability monitor which

continually updates the scheduler regarding availability of qualifying networks.

(Ex. 1019 at 4:12-16.) A transmitting device has a communications manager

which selects a lower-priority qualifying network if all higher-priority qualifying

networks have been deemed unavailable. (Ex. 1019 at 3:6-8; FIG. 1.) The

communications manager will re-attempt to transmit the data over a higher-

priority qualifying network when it becomes available. (Ex. 1019 at 3:8-12.) In

other words, the communications manager selects the network path based at least

in part on whether the network is available (e.g., a “reliability criterion”). This is

exactly how the ’048 Patent describes the reliability criteria (which it describes as

“redundancy”), where the gateway is instructed not to send “the packet(s)

through a network, router, or a connection that is apparently down.” (Ex. 1003 at

10:65-67.) In addition, Pearce describes monitoring the “signal strength and

error rate”, both indicators of reliability in determining the priority and suitability

of a given network path (Ex. 1019 at 3:32-34.) Pearce thus promotes the use of

paths (e.g., available networks) that can carry packets when other paths are not

functioning (e.g., other networks are unavailable.) (Ex. 1019 at 4:48-67.)

248. It would have been obvious to a POSITA to use the method of

monitoring network availability as taught by Pearce within the gateway processor

of Karol to send different blocks (i.e., packets) of a given data object (i.e.,



-125-

message) on different parallel networks when a change in network availability

occurs during transmission of the data object (i.e., during the transmission

session). First, using the network availability monitor disclosed in Pearce with

Karol would have amounted to nothing more than the use of a known technique

to improve similar methods in the same way or the combination of prior art

elements according to known methods to yield predictable results. KSR, 550 U.S.

at 417; MPEP § 2143. Karol recognizes that the CO network is initially

unavailable for a flow of packets while a connection is being established and may

route packets through the CL network in the interim. (Ex. 1006 at 4:12-23, 5:51-

54.) Pearce, when combined, expands on this approach by teaching a method in

which the availability of all networks is continuously monitored during the

transmission session and transmission is adapted in response to changes in

availability. (Ex. 1019 at 4:13-5:6, 5:23-26.) A POSITA would have been

motivated to pursue this combination because it would have yielded predictable

results.

249. Second, the combination of Karol and Zhang with Pearce was obvious

to try. KSR, 550 U.S. at 417; MPEP § 2143. Karol and Pearce are both directed

to the need in the art to exploit the availability of parallel networks. (Ex. 1006 at

1:50-51, 2:13-19; Ex. 1019 at Abstract, 1:6-22.) Pearce provides a method for

packet path selection which supports parallel use of a variety of network types,



-126-

including connection-oriented and connectionless networks. (Ex. 1019 at 2:18-

22.) Thus, a POSITA would have pursued the combination with a high likelihood

of success.


limitations of this claim under the broadest reasonable interpretation proposed

herein (see ¶ 79 above).

‘048 Patent: Claim 5 5. The controller of claim 1, wherein the controller sends packets from a selected network interface to a VPN.

5. The controller of claim 1, wherein the controller sends packets from a selected network interface to a VPN.

251. Karol either anticipates or Karol in view of one or more of Zhang,




¶¶ 167-223 above.



switches, send packets to either a “connectionless” (or “CL”) network data path

or to a “connection oriented” (or “CO) network data path (see, for example, Ex.

1006 at 1:7-16). Karol specifically describes the CL network as being based upon

the “Internet Protocol or "IP"” and the CO network as being based upon “ATM,



-127-

MPLS, RSVP” or a “telephony network” (see, for example, Ex. 1006 at 1:7-16,

2:52-58). This is further illustrated in and described with respect to FIG. 1 of

Karol (see, for example, ¶¶ 83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG.

1 as shown in ¶ 169 above).

253. Karol also discloses systems and methods of operation thereof

whereby the “CL-CO gateway”, alone or in combination with one or more

routers and/or switches, receives datagrams (or “packets”) and such “datagrams

received in input line cards 401 can be directed either to CO switch 410 or CL

router/switch 420” so that “output line cards 402 can receive datagrams from

either of the last mentioned elements and direct them to external networks” (see,

for example, ¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein

in ¶ 184 above).

254. Thus, Karol discloses the “controller” (for example, the CL-CO

gateway) that “sends packets” from a “selected network interface” to an

“Internet-based network” (for example, the depicted packet path selector of FIG.

4 compares information in each packet received at the CL-CO gateway and then

routes each packet either to the Internet-based CL network interface output line

card or to the private network-based CO network interface output line card

according to the process described in FIG. 5). It is notable that Zhang discloses

the use of “tunneling sessions” which are a form of VPN (Ex. 1017,



-128-

ABSTRACT.) As Zhang discloses “Layer Two Tunneling Protocol (L2TP) is a

specific tunneling protocol that acts as an extension to the PPP protocol to allow

ISPs to operate virtual private networks. L2TP or any other tunneling protocol

may be used when establishing the tunneling session.” (Ex. 1017 6:18-23.)

255. However, Karol does not explicitly disclose the exemplary

embodiment wherein the “Internet-based network” is a “VPN”. In my opinion,

McCullough discloses this feature. McCullough discloses a VPN between two

gateways (an initiator and responder), with multiple IVCs spanning the VPN.

(Ex. 1018 at [0047]-[0048]; FIG. 4.)

256. A POSITA would have substituted the VPN network disclosed in

McCullough with the CL network of Karol for several reasons. First, substituting

the VPN network of McCullough to Karol’s CL network would have amounted

to nothing more than the simple substitution of one known element for another to

obtain predictable results. See KSR, 550 U.S. at 417; MPEP § 2143. A VPN was

well-known in the art, and a POSITA could have substituted a VPN into the CL

network of Karol to yield highly predictable and successful results. Additionally,

both Karol and McCullough describe routing packets over various types of

private and parallel networks. (Ex. 1006 at 3:47-51, 4:40-44; Ex. 1018 at [0047],

FIG. 4.) It is notable that Zhang discloses the use of “tunneling sessions” which

are a form of VPN. (Ex. 1017 at ABSTRACT.) As Zhang discloses “Layer Two



-129-

Tunneling Protocol (L2TP) is a specific tunneling protocol that acts as an

extension to the PPP protocol to allow ISPs to operate virtual private networks.

L2TP or any other tunneling protocol may be used when establishing the

tunneling session.” (Ex. 1017 6:18-23.)

257. Second, the combination of Karol and Zhang with McCullough was

obvious to try. KSR, 550 U.S. at 417; MPEP § 2143. At the time of the invention,

the need in the art was to route packets over multiple parallel routes, including a

private network and/or an Internet-based network. A POSITA understood that

only a finite number of CL networks appropriate to the disclosures in Karol

existed. Thus, a POSITA would have pursued the combination with a high

likelihood of success and predictable results.




‘048 Patent: Claim 6 6. The controller of claim 1, wherein the controller sends packets from a selected network interface to a point-to-point private network connection.

6. The controller of claim 1, wherein the controller sends packets from a selected network interface to a point-to -point private network connection.






-130-


¶¶ 167-223 above.







based upon “ATM, MPLS, RSVP” or a “telephony network” (emphasis added,

see, for example, Ex. 1006 at 1:7-16, 2:52-58) which is a disparate network. This

is further illustrated in and described with respect to FIG. 1 of Karol (see, for

example, ¶¶ 83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG. 1 as shown in ¶

169 above).

261. Karol discloses that the “CO network can be an MPLS (MultiProtocol

Label Switching) or RSVP (Resource reSerVation Protocol) based IP network, a

WDM (Wavelength Division Multiplexed) network, an ATM (Asynchronous

Transfer Mode) network, or an STM (Synchronous Time Multiplexing) network,

such as the telephony network or a SONET network” and that the “CL network is

typically, although not necessarily, an IP network” (emphasis added, see, for

example, Ex. 1006 at 2:61-66). Karol also discloses that the “CO network” can be



-131-

comprised of an “X.25 network” or “point-to-point links” (emphasis added, see,

for example, Ex. 1006 at 13:62-67). See also, for example, Ex. 1006 at 6:25-28.

262. Karol also discloses that the CL-CO gateway routes packets to the CL

and CO networks based at least upon conventional IP routing techniques such as

OSPF as well as “Link State Advertisements (LSAs) that report point-to-point

links” that are expressed by associated “link weights” so that “integrated IP-CO

routing tables are maintained at the CL-CO gateways” (emphasis added, see, for

example, Ex. 1006 at 14:23-67, FIG. 8 and FIG. 9).


whereby the “CL-CO gateway”, alone or in combination with one or more

routers and/or switches, receives datagrams (or “packets”) and such “datagrams

received in input line cards 401 can be directed either to CO switch 410 or CL

router/switch 420” so that “output line cards 402 can receive datagrams from

either of the last mentioned elements and direct them to external networks” (see,

for example, ¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein

in ¶ 184 above).


gateway) that “sends packets” from a “selected network interface” to a “point-to-

point private network connection” (for example, the depicted packet path selector

of FIG. 4 compares information in each packet received at the CL-CO gateway



-132-

and then routes each packet either to the Internet-based CL network interface

output line card or to the point-to-point private network-based CO network

interface output line card according to the process described in FIG. 5).



above).

‘048 Patent: Claim 7 7. A method for combining connections for access to disparate parallel networks, the method comprising the steps of:

receiving at a controller a packet which has a first site IP address as source address and a second site IP address as destination address;

selecting, within the controller on a per-packet basis, between a path through an Internet-based network and a path through a private network that is not Internet-based; and

forwarding the packet along the selected path toward the second site.

7(a). A method for combining connections for access to disparate parallel networks, the method comprising the steps of:











-133-




268.













-134-




1006 at 3:47-51).

270. Thus, Karol discloses a “combining connections for access to

disparate parallel networks” (for example, either of the CL-CO gateway or the

combination of the CL-CO gateway with one or more routers and/or switches

shown in annotated FIG. 1 herein is disclosed to route any given IP datagram or

packet from source to destination over one of the CL network path based on, for

example, the Internet protocol or the CO path based on, for example, the ATM or

MPLS protocol) and that such parallel networks are “disparate” (for example, the

CL path is based on Internet protocol service from a first service provider and the

CO path is based on ATM or MPLS protocol service from a second service

provider, wherein the CL path and the CO path are described as “two different,

parallel routes”).








-135-





272.


element under the broadest reasonable interpretation proposed herein (see ¶¶ 74

and 77 above).



term “disparate parallel networks” should mean that at least one of the “alternate

data paths” be over “a frame relay or point-to-point network”, for example, then

in my opinion the knowledge and common sense of the person of ordinary skill in



-136-

the art at the time of the invention was sufficient to extrapolate from the

disclosures of Karol to such an interpretation at least because this was within the

skill of person of ordinary skill in the art at the time of the invention, obvious to

try and yielded predictable results as evident by at least the reasons given at ¶¶

176-180 above.






reasonable interpretation of this claim element (see ¶¶ 74 and 77 above).




(see ¶¶ 74 and 77 above) or under the alternative interpretation described above

(see ¶ 274 above).

7(b): receiving at a controller a packet which has a first site IP address as source address and a second site IP address as destination address;






-137-










278.








-138-

280. Karol describes the operation of the network in FIG. 1 as “Traffic

from source endpoint 101 destined for destination endpoint 151 (which is directly

connected to and served by a node 132 in a CL network 130) can be routed in at

least two different, parallel routes, and this choice of routes is reflected in how

the CL-CO gateway 140 operates” (see, for example, Ex. 1006 at 4:40-44 and

FIG. 1). Since the “traffic” of Karol is described specifically as IP datagrams

(see, for example, Ex. 1006 at 4:36-40), then datagrams (or packets) necessarily

have a “source address” that corresponds to the “source endpoint 101” at a first

site and a “destination address” that corresponds to the “destination endpoint

151” at a second site.






(emphasis added, see, for example, Ex. 1006 at 7:36-41 and ¶ 94 above).







-139-








95 above).


gateway) that is “receiving at a controller a packet” (for example, one or more of

the input line cards and/or a network connection receives an IP datagram from a

source endpoint) wherein the “packet” has “a first site IP address as source

address” (for example, all IP datagrams have source addresses and IP datagrams

from a source endpoint at a first site will have a source address that includes a

network address of the first site) and “a second site IP address as destination

address” (for example, all IP datagrams have destination addresses and IP

datagrams to a destination endpoint at a second site will have a destination

address that includes a network address of the second site).



-140-



above).

7(c): selecting, within the controller on a per -packet basis, between a path through an Internet-based network and a path through a private network that is not Internet-based;











herein).



-141-

286.



“output line cards 402 can receive datagrams from either of the last-mentioned


above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 278 above). Karol












-142-




the routers” (Exhibit 1006 at 8:51-53). This would constitute determining a path



















-143-



95 above).









FIG. 8, and ¶¶ 104-108 above).








example, Ex. 1006 at 7:60-8:2).



-144-





and 17:63-18:2).


gateway) that selects “between a path through an Internet-based network and a

path through a private network that is not Internet-based” (for example, the

depicted packet path selector of FIG. 4 as shown in ¶ 286 above compares

information in each packet received at the CL-CO gateway to determine if the

packet will be routed to the CL network interface output line card or to the CO

network interface output line card) on a “per-packet basis” (for example, each

packet routing decision is unique to a particular IP datagram).


element under the broadest reasonable interpretation proposed herein (see ¶¶ 72,

73 and 75 above).



additional information disclosing “an Internet-based network and a path through

a private network that is not Internet-based,” is required to disclose this claim



-145-

element, Zhang discloses this feature. Zhang discloses a gateway (82) which

interfaces multiple computers to multiple networks. (Ex. 1017 at 1:57-58, FIG.

2.) The multiple networks may include a corporate intranet (e.g., a private

network) and the Internet. (Ex. 1017 at 1:62-64.) It would have been obvious to

a POSITA to connect Karol’s gateway to multiple networks (including a private

intranet and the Internet) described in Zhang. First, incorporating the multiple

network paths (Internet and intranet) disclosed in Zhang with Karol would have

amounted to nothing more than the use of a known technique to improve similar

methods in the same way or the combination of prior art elements according to

known methods to yield predictable results. KSR, 550 U.S. at 417; MPEP § 2143.

Karol already discloses multiple disparate networks, and a POSITA would have

recognized that implementing Internet and intranets disclosed in Zhang with the

method in Karol would enable Karol to “select[] . . . between a path through an

Internet-based network and a path through a private network that is not Internet-

based” and therefore send data over multiple parallel networks. A POSITA would

have been motivated because the combination would have predictable results.

296. Second, the combination of Karol and Zhang was obvious to try.

KSR, 550 U.S. at 417; MPEP § 2143. The need in the art was the ability to route

to multiple network locations based on the IP protocol. No other alternative than

the routing structure in Karol and Zhang was in common usage for IP protocol.



-146-


success.

297. Therefore, in my opinion, Karol in view of Zhang renders obvious the


proposed herein (see ¶¶ 72, 73 and 75 above).

298. In the event that the Board finds that the requirement of “selecting,

within the controller on a per-packet basis, between a path through an Internet-

based network and a path through a private network that is not Internet-based” in

claim 7[c] is not sufficiently disclosed by the combination of Karol and Zhang,

claim 7 is rendered obvious over Karol and Zhang further in view of

McCullough. In McCullough, when the gateway receives a packet for transport,

the gateway fragments the packet and “each fragment becomes its own smaller

packet with its own IP header and is routed independently of any other packets.”

(Ex. 1018 at [0058] (emphasis added).) Thus, McCullough clearly discloses this

feature.

299. It would have been obvious to a POSITA to implement path selection

“on a per-packet basis” as taught by McCullough within Karol’s gateway for

accessing parallel disparate networks. First, introducing the functions of

McCullough’s initiator and responder gateways into the CL-CO gateways of

Karol in order to establish a VPN as taught by McCullough through Karol’s CL



-147-

network would have amounted to nothing more than the use of a known

technique to improve similar methods in the same way or the combination of

prior art elements according to known methods to yield predictable results. KSR,

550 U.S. at 417; MPEP § 2143. Karol, Zhang, and McCullough each disclose a

“gateway” which provides access to one or more networks. (Ex. 1006 at 3:30-51;

Ex. 1017 at 1:57-64; Ex. 1018 at [0047].) In each case, the gateway provides

access for either a particular source connected to the gateway or a collection of

sources connected to the gateway, for example, through a local area network

(LAN). Karol discloses an embodiment in which the source and destination are

connected directly to their respective CL-CO gateways. (Ex. 1006 at 5:5-8.)

Both Zhang and McCullough disclose a gateway that is directly connected to the

site network. (Ex. 1017 at 1:57-64, FIG. 2; Ex. 1018 at [0047], FIG. 4.) In these

configurations all traffic not destined to the local network must pass through the

gateway. Each of Karol, Zhang, and McCullough similarly address the problem

in the art of providing connectivity to or between remote private networks (e.g.,

geographically distributed enterprise networks). (Ex. 1006 at 3:46-51; Ex. 1017

at 1:31-40; Ex. 1018 at [0003]-[0006].) Furthermore, McCullough teaches the

Initiator and Responder gateways are connected to the public network through

“one or more links” and “that links can be spread across multiple ISPs” (i.e.,

Internet service providers). (Ex. 1018 at [0022], [0047].) A POSITA would have



-148-

recognized the correspondence between McCullough’s parallel links and Karol’s

parallel disparate networks. Thus, a POSITA would have had a reasonable

expectation of success in drawing from the teachings of McCullough regarding

operation of parallel IVCs and applying them to the more general setting of

operation of a VPN through the CL network in parallel with a connection through

the CO network. More specifically, routing of packets on a per-packet basis to a

plurality of both IVCs through the CL network and connections (i.e., calls)

through the CO network would have enabled flexible use of the parallel paths.

Thus, a POSITA would have been motivated to pursue this combination because

it would have yielded predictable results.

300. Second, the combination of Karol, Zhang, and McCullough was

obvious to try. KSR, 550 U.S. at 417; MPEP § 2143. Dedicated point-to-point

lines were a common solution at the time for providing fast, reliable, and


LAN in New York and one in Chicago. (Ex. 1018 at [0003]-[0005].) There were

known advantages at the time to connecting remote sites over the Internet (i.e., a

connectionless IP based network), particularly in terms of cost. (Ex. 1018 at

[0006]) There was a need in the art for a solution to connect remote private

networks through the Internet in a way that achieved the same guarantees in

terms of speed, reliability, and confidentiality as addressed by McCullough.



-149-

Additionally, here was a need in the art for parallel operation of these private

(e.g., CO) and Internet-based (e.g., CL) networks as addressed by Karol. A

POSITA would have recognized that path selection on a per-packet basis was one

of a set of well-known techniques for routing packets in the presence of parallel

paths. For these reasons as well as for those explained above, a POSITA would

have pursued the combination of these known solutions with a reasonable

expectation of success.



broadest reasonable interpretation proposed herein (see ¶¶ 72, 73 and 75 above).

7(d): forwarding the packet along the selected path toward the second site. 302. Karol discloses systems and methods of operation thereof whereby the












-150-

annotated herein). Note boxes 529 and 521 that read “FORWARD DATAGRAM

AS PER ENTRY”.

303.

304.

305. Thus, Karol discloses a “forwarding the packet along the selected path

toward the second site” (for example, the depicted packet path selector of FIG. 4

compares information in each packet received at the CL-CO gateway and then

routes each packet either to the CL network interface output line card or to the

CO network interface output line card according to the process described in FIG.

5 in order to send each packet to the destination endpoint at a second site).



-151-



above).









‘048 Patent: Claim 9 9. The method of claim 7, wherein the selecting step selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

9. The method of claim 7, wherein the selecting step selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

309. Karol either anticipates or Karol in view of one or more of Zhang and

McCullough renders obvious the recited Claim 7 of this claim element under

either the broadest reasonable interpretation or the various alternative



-152-

interpretations described above for at least the reasons summarized in ¶¶ 266-308

above.

310. See, for example, ¶¶ 225-230 above regarding claim 3.

311. Thus, Karol discloses the “selecting step” that selects between










CO networks). Also "[i]n the parallel configuration, since at least two paths exist

between the originating and destination CL nodes, one using the CL network and

the other using the CO network, there is always a routing choice, i.e., CL to CO

to CL or entirely CL. The gateway can make the routing selection based on

maximizing efficiency.” (Exhibit 1006 3:61-66, emphasis added). Karol also

discloses that “[t]he decision to set up CO connections is made at CL-CO

gateway 140, based on the user-specified service requirements and the traffic



-153-

situation in the CL and CO networks.” (Exhibit 1006 at 5:35-38, emphasis

added). A POSITA would understand that load-balancing is a means of

maximizing efficiency and accounting for “the traffic situation” is part of load-

balancing.

312. Note that Patent Owner specifically alleges that a packet routing

appliance meets the limitations of this claim element under Patent Owner’s

proposed claim constructions by pointing to “Claim 3” of Patent Owner’s

infringement contentions that are based upon the following documented

description: “In the face of network brownouts or soft failures, performance

degradation can be minimized. The tracking of network and path conditions by

application-aware routing in real time can quickly reveal performance issues, and

it automatically activates strategies that redirect data traffic to the best available

path. As the network recovers from the brownout or soft failure conditions,

application-aware routing automatically readjusts the data traffic paths.” (see, for

example, Ex. 1016 at Appendix I at p. 12). Thus, to the extent that Patent

Owner’s theory of alleged infringement by Petitioner’s products has any

relevance to an analysis of this claim element, then this also at least indicates that

the disclosures of Karol meet the limitations of this claim element.



-154-



above).



additional information disclosing “wherein the selecting step selects between

network interfaces according to a load-balancing criterion, thereby promoting

balanced loads on devices that carry packets on the selected path after the packets

leave the selected network interfaces,” is required to disclose this claim element,

McCullough discloses this feature. See, for example, ¶¶ 233 above with respect

to claim 3. Therefore, in my opinion, Karol in view of Zhang, further in view of



‘048 Patent: Claim 10 10. The method of claim 7, wherein the selecting step selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.

10. The method of claim 7, wherein the selecting step selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.





-155-



above.

316. See, for example, ¶¶ 239-243 above regarding claim 4. Generally,

Karol’s invention is directed to selecting paths between two disparate networks if

there is “an advantage from the user or service provider perspective” (Exhibit

1006, 1:7-16). Karol also discloses that “[t]he decision to set up CO connections

is made at CL-CO gateway 140, based on the user-specified service


1006 at 5:35-38, emphasis added). A POSITA would understand that reliability

would be one of the major concerns which would form part of “user-specified

service requirements”. Also, in general “service guarantees” are better provided

for in CO networks (see e.g. Ex. 1006 at 1:43-46). In addition, Karol explicitly

states “[t]he present invention is useful, for example, in serving the needs of

Internet users who want stricter quality-of-service guarantees for their file

transfer application than is currently offered by the Internet.” (Exhibit 1006 at

2:59-62). A POSITA would understand that reliability is often an important

consideration in providing service guarantees.





-156-











will be promoted).



above).

‘048 Patent: Claim 11 11. The method of claim 7, wherein the forwarding step sends packets from a selected network interface to a VPN.

11. The method of claim 7, wherein the forwarding step sends packets from a selected network interface to a VPN.






-157-


above.


321. Thus, Karol discloses a forwarding step that “sends packets” from a

“selected network interface” to an “Internet-based network” (for example, the

depicted packet path selector of FIG. 4 compares information in each packet

received at the CL-CO gateway and then routes each packet either to the Internet-

based CL network interface output line card or to the private network-based CO

network interface output line card according to the process described in FIG. 5).



McCullough discloses this feature for all the reasons given in ¶¶ 255-257 above

with respect to claim 5. Therefore, in my opinion, Karol in view of Zhang,

further in view of McCullough renders obvious the limitations of this claim


above).

‘048 Patent: Claim 12 12. The method of claim 7, wherein the forwarding step sends packets from a selected network interface to a point-to-point private network connection.

12. The method of claim 7, wherein the forwarding step sends packets from a selected network interface to a point-to -point private network connection.



-158-





above.



“selected network interface” to a “point-to-point private network connection” (for

example, the depicted packet path selector of FIG. 4 compares information in

each packet received at the CL-CO gateway and then routes each packet either to

the Internet-based CL network interface output line card or to the point-to-point

private network-based CO network interface output line card according to the

process described in FIG. 5).



above).

‘048 Patent: Claim 13 13. A method for controlling access to multiple independent disparate networks in a parallel network configuration, the disparate networks comprising at least one private network and at least one network based on the Internet, the method comprising the steps of:

receiving a packet through a site interface that connects a controller to a site;



-159-

selecting between at least two network interfaces of the controller which use at least two known location address ranges which are respectively associated with disparate networks, according to at least: a destination of the packet, an optional presence of alternate paths to that destination, and at least one specified criterion for selecting between alternate paths when such alternate paths are present; and

sending the packet through the selected network interface.

13(a). A method for controlling access to multiple independent disparate networks in a parallel network configuration, the disparate networks comprising at least one private network and at least one network based on the Internet, the method comprising the steps of:











83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG. 1 as annotated herein). In

addition, the source endpoint can be connected directly to a CL-CO gateway:

“Also, the source or destination may be directly connected to a CL-CO gateway



-160-

(e.g., gateway 140) as opposed to being connected through a CL node.” (Ex.

1006 at 5:5-8).

329.














-161-



1006 at 3:47-51).

331. Thus, Karol discloses a “combining connections for access to

disparate parallel networks” (for example, either of the CL-CO gateway or the

combination of the CL-CO gateway with one or more routers and/or switches

shown in annotated FIG. 1 herein is disclosed to route any given IP datagram or

packet from source to destination over one of the CL network path based on, for







332. Thus, Karol discloses “controlling access to multiple independent

disparate networks in a parallel network configuration” (for example, either of

the CL-CO gateway or the combination of the CL-CO gateway with one or more

routers and/or switches shown in annotated FIG. 1 herein is disclosed to route

any given IP datagram or packet from source to destination over one of the CL

network path based on, for example, the Internet protocol or the CO path based



-162-

on, for example, the ATM or MPLS protocol) and that such multiple networks

are chosen from “disparate networks comprising at least one private network and

at least one network based on the Internet” (for example, the CL path is based on

Internet protocol service from a first service provider and the CO path is based on

ATM or MPLS protocol service from a second service provider, wherein the CL

path and the CO path are described as “two different, parallel routes”).











-163-


334.


element under the broadest reasonable interpretation proposed herein (see ¶¶ 72-

74 and 77 above).










-164-



175-181 above.






reasonable interpretation of this claim element (see ¶¶ 72-74 and 77 above).




(see ¶¶ 72-74 and 77 above) or under the alternative interpretation described

above (see ¶ 336 above).

13(b): receiving a packet through a site interface that connects a controller to a site;








-165-







1006 at 6:44-50 and FIG. 4 as annotated herein). In addition, the source endpoint

can be connected directly to a CL-CO gateway: “[a]lso, the source or destination

may be directly connected to a CL-CO gateway (e.g., gateway 140) as opposed to

being connected through a CL node.” (Ex. 1006 at 5:5-8).

340.








-166-


gateway) that is “receiving a packet through a site interface that connects a

controller to a site” (for example, one or more of the input line cards and/or a

network connection receives an IP datagram from a source endpoint) and that is

connected to a “site” (for example, local network routers/switches and/or

source/destination endpoints).



above).





13(c): selecting between at least two network interfaces of the controller which use at least two known location address ranges which are respectively associated with disparate networks, according to at least: a destination of the packet, an optional presence of alternate paths to that destination, and at least one specified criterion for selecting between alternate paths when such alternate paths are present;



switches, comprises at least two “network interfaces” that connect the

“controller” of Karol (see, for example, ¶¶ 339-344 above) to both of the CL

network and the CO network (see, for example, Ex. 1006 at 3:58-66, 4:45-65, and



-167-

FIG. 1 as annotated herein in ¶ 169 above). More specifically, Karol discloses an

exemplary depiction of structural elements within the CL-CO gateway wherein at

least two “output line cards 402” are utilized to “receive datagrams from either

of” the “CO switch 410 or CL router/switch 420” and then “direct them to

external networks” as further illustrated in and described with respect to FIG. 4 of

Karol (see, for example, ¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as

annotated herein in ¶ 340 above). Note that while FIG. 4 of Karol illustrates only

one symbol “402” for the “output line cards”, this clearly discloses at least two

such “output line cards” that send packets over network interfaces to the two

respective CL and CO networks as evident at least by the two paths depicted into

symbol “402” in FIG. 4, the written description of FIG. 4 within Karol, the use of

the plural “output line cards” instead of the singular “output line card” within

symbol “402” in FIG. 4, and the two network interfaces depicted from the CL-

CO gateway to nodes “112” and “161” in FIG. 1 (see, for example, Ex. 1006 at

4:36-67, FIG. 1, and FIG. 4).


more routers and/or switches shown in annotated FIG. 1 herein also depicts at

least two “network interfaces” to both of the CL network and the CO network

that are depicted as exemplary router “node 121” and exemplary CO switching

element “node 161” (see, for example, Ex. 1006 at 3:58-66, 4:45-65, and FIG. 1



-168-

as annotated herein in ¶ 169 above). Karol discloses in reference to FIG. 4 that







example, Ex. 1006 at 7:60-8:2). Thus, on a packet-by- packet basis, it must be

determined whether a connection has been established in the CO network. If a

connection has not yet been established in the CO network, then the packet could

continue on in the CL network, using e.g. a “source routing” implementation:

“First, the gateway can turn back IP datagrams to the CL network using IP source

routing to override routing tables at the routers” (Exhibit 1006 at 8:51-53). This

would constitute determining a path depending on the presence (or absence) of an

alternative path to a destination.








-169-






herein).

348.











-170-















95 above).








-171-




FIG. 8, and ¶¶ 104-108 above).








example, Ex. 1006 at 7:60-8:2).





and 17:63-18:2).


gateway or the CL-CO gateway in combination with one or more routers and/or

switches) that has at least two “network interfaces” (for example, the output line



-172-

cards respectively coupling the CL router to the CL network and the CO switch

to the CO network or the network connections to respective CL and CO

networks), which “selects between network interfaces” (for example, the depicted


the CL-CO gateway to determine if the packet will be routed to the CL network

interface output line card or to the CO network interface output line card)

according to at least “a destination of the packet” (for example, gateway

processor in the CL-CO gateway compares the destination address of each

received packet to fields in both the forwarding and flow databases), “an optional

presence of alternate paths to that destination” (for example, the gateway

processor will only forward a particular packet to the CO network when a valid

connection exists for the flow associated with the particular packet), and “at least


paths are present” (for example, based upon the needs of a particular flow or to

avoid congested links), and wherein such “selecting” uses “at least two known

location address ranges which are respectively associated with disparate

networks” (for example, the addresses stored in the routing tables for routing

packets to the CL network and the addresses stored in the routing tables for

routing packets to the CO network).



-173-



above).

357. In the event the Board determines that Karol fails to teach or suggest

“selecting between at least two network interfaces of the controller which use at

least two known location address ranges which are respectively associated with

disparate networks,” in my opinion, this feature is clearly disclosed in Zhang.

See, for example, ¶¶ 204-207 above regarding claim 1[d]. Therefore, in my

opinion, Karol in view of Zhang renders obvious the limitations of this claim


above).

358. In the event that the Board finds that the requirement of “selecting

between at least two network interfaces . . . according to at least . . . one specified

criterion for selecting between alternate paths when such alternate paths are

present” is not sufficiently disclosed by the combination of Karol and Zhang,

claim 1 is rendered obvious over Karol and Zhang further in view of

McCullough. See, for example, ¶¶ 208-212 above regarding claim 1[d].

Therefore, in my opinion, Karol in view of Zhang, further in view of McCullough


reasonable interpretation proposed herein (see ¶ 74 above).



-174-


“selecting between at least two network interfaces . . . according to at least . . .


paths are present” is not sufficiently disclosed by Karol, claim 1 is rendered

obvious over Karol in view of Pearce. See, for example, ¶¶ 213-218 above

regarding claim 1[d]. Therefore, in my opinion, Karol in view of Pearce renders

obvious the limitations of this claim element under the broadest reasonable

interpretation proposed herein (see ¶ 74 above).

13(d): sending the packet through the selected network interface. 360. Karol discloses systems and methods of operation thereof whereby the





mentioned elements and direct them to external networks” (see, for example,

¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 184

above). An exemplary process for determining the network path selection and

actual forwarding to the CL or CO network interface is described in detail at FIG.

5 of Karol (see, for example, ¶¶ 97-100 above, Ex. 1006 at 8:56-9:36 and FIG. 5

as annotated herein).



-175-

361.

362. Thus, Karol discloses a “sending the packet through the selected

network interface” (for example, the depicted packet path selector of FIG. 4


routes each packet either to the CL network interface output line card or to the

CO network interface output line card according to the process described in FIG.

5 in order to send each packet to the destination endpoint at a second site).



above).



-176-









‘048 Patent: Claim 15 15. The method of claim 13, wherein the method selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

15. The method of claim 13, wherein the method selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.





¶¶ 327-365 above.

367. See, for example, ¶¶ 224-237 above regarding claim 3. Also "[i]n the

parallel configuration, since at least two paths exist between the originating and



-177-

destination CL nodes, one using the CL network and the other using the CO

network, there is always a routing choice, i.e., CL to CO to CL or entirely CL.

The gateway can make the routing selection based on maximizing efficiency.”

(Exhibit 1006 3:61-66, emphasis added). Karol also discloses that “[t]he decision

to set up CO connections is made at CL-CO gateway 140, based on the user-



understand that load-balancing is a means of maximizing efficiency and

accounting for “the traffic situation” is part of load-balancing.











CO networks).



-178-



above).

370. To the extent that the Board determines that the combination of Karol

and Zhang fail to teach or suggest “wherein the method selects between network

interfaces according to a load-balancing criterion, thereby promoting balanced

loads on devices that carry packets on the selected path after the packets leave the

selected network interfaces,” as described above in ¶¶ 208-212 with respect to

claim 1[d], McCullough discloses these features. It would have been obvious to

combine McCullough with Karol and Zhang for all the reasons described in ¶¶

208-212 above with respect to claim 1[d]. Thus, it is my opinion that the

combination of Karol, Zhang and McCullough renders obvious the limitations of

this claim element under the broadest reasonable interpretation proposed herein

(see ¶ 79 above).

371. In the event that the Board finds that the requirement of “wherein the

method selects between network interfaces according to a load-balancing

criterion” is not sufficiently disclosed by Karol, claim 3 is rendered obvious over

Karol in view of Pearce for all the reasons described in ¶¶ 234-237 above with

respect to claim 3. Therefore, in my opinion, Karol in view of Pearce rendered



-179-

obvious the limitations of this claim element under the broadest reasonable

interpretation proposed herein (see ¶ 79 above).

‘048 Patent: Claim 16 16. The method of claim 13, wherein the method selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.

16. The method of claim 13, wherein the method selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.





¶¶ 327-365 above.











-180-




















will be promoted).



-181-



above).

376. To the extent the Board determines that Karol fails to disclose “selects

between network interfaces according to a reliability criterion, thereby promoting

use of devices that will still carry packets on the selected path after the packets

leave the selected network interfaces, when other devices on a path not selected

are not functioning,” Pearce discloses this feature for all the reasons described in

¶¶ 247-249 above with respect to claim 4. Therefore, in my opinion, the

combination of Karol and Pearce teaches or suggests all of the features of claim

4.

‘048 Patent: Claim 17 17. The method of claim 13, wherein the method sends packets from a selected network interface to a VPN.

17. The method of claim 13, wherein the method sends packets from a selected network interface to a VPN.





¶¶ 327-365 above.




-182-


“selected network interface” to an “Internet-based network” (for example, the

depicted packet path selector of FIG. 4 compares information in each packet

received at the CL-CO gateway and then routes each packet either to the Internet-

based CL network interface output line card or to the private network-based CO

network interface output line card according to the process described in FIG. 5).







above).

‘048 Patent: Claim 18 18. The method of claim 13, wherein the method sends packets from a selected network interface to a point-to-point private network connection.

18. The method of claim 13, wherein the method sends packets from a selected network interface to a point-to -point private network connection.






-183-


¶¶ 327-365 above.



“selected network interface” to a “point-to-point private network connection” (for

example, the depicted packet path selector of FIG. 4 compares information in

each packet received at the CL-CO gateway and then routes each packet either to

the Internet-based CL network interface output line card or to the point-to-point

private network-based CO network interface output line card according to the

process described in FIG. 5).



above).

‘048 Patent: Claim 19 19. A controller for combining connections for access to

disparate parallel networks, the controller comprising: a site interface configured for receiving a packet which has a first

site IP address as source address and a second site IP address as destination address;

a packet path selector which selects, within the controller on a per-packet basis, between a path through an Internet-based network and a path through a private network that is not Internet-based; and

wherein the controller receives a packet through the site interface and sends the packet through the network interface that was selected by the packet path selector.



-184-

19(a). A controller for combining connections for access to disparate parallel networks, the controller comprising:












387.



-185-














1006 at 3:47-51).

389. Thus, Karol discloses a “controller” (for example, either of the CL-

CO gateway or the combination of the CL-CO gateway with one or more routers

and/or switches) that is for “combining connections for access to disparate

parallel networks” (for example, either of the CL-CO gateway or the combination

of the CL-CO gateway with one or more routers and/or switches shown in

annotated FIG. 1 herein is disclosed to route any given IP datagram or packet



-186-

from source to destination over one of the CL network path based on, for











proposed claim constructions (see, for example, Ex. 1016 at Appendix I at p. 36).

Thus, to the extent that Patent Owner’s theory of alleged infringement by

Petitioner’s products has any relevance to an analysis of this claim element, then

this also at least indicates that the disclosures of Karol meet the limitations of this

claim element.


element under the broadest reasonable interpretation proposed herein (see ¶¶ 74

and 77 above).



-187-










175-181 above.






reasonable interpretation of this claim element (see ¶¶ 74 and 77 above).






-188-

(see ¶¶ 74 and 77 above) or under the alternative interpretation described above

(see ¶ 393 above).

19(b): a site interface configured for receiving a packet which has a first site IP address as source address and a second site IP address as destination address;













396.



-189-






398. Karol describes the operation of the network in FIG. 1 as “Traffic

from source endpoint 101 destined for destination endpoint 151 (which is directly

connected to and served by a node 132 in a CL network 130) can be routed in at

least two different, parallel routes, and this choice of routes is reflected in how

the CL-CO gateway 140 operates” (see, for example, Ex. 1006 at 4:40-44 and

FIG. 1). Since the “traffic” of Karol is described specifically as IP datagrams

(see, for example, Ex. 1006 at 4:36-40), then datagrams (or packets) necessarily

have a “source address” that corresponds to the “source endpoint 101” at a first

site and a “destination address” that corresponds to the “destination endpoint

151” at a second site.







-190-














95 above).

401. Thus, Karol discloses a “site interface configured for receiving a

packet” (for example, one or more of the input line cards and/or a network

connection receives an IP datagram from a source endpoint) wherein the “packet”

has “a first site IP address as source address” (for example, all IP datagrams have

source addresses and IP datagrams from a source endpoint at a first site will have

a source address that includes a network address of the first site) and “a second



-191-

site IP address as destination address” (for example, all IP datagrams have

destination addresses and IP datagrams to a destination endpoint at a second site

will have a destination address that includes a network address of the second

site).



above).

19(c): a packet path selector which selects, within the controller on a per-packet basis, between a path through an Internet-based network and a path through a private network that is not Internet-based;











herein).



-192-

404.





above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 502 above). Karol












-193-




the routers” (Exhibit 6, 8:51-53). This would constitute determining a path


This process is repeated for each packet (“per-packet”) as long as it takes for the

CO connection to be established.
















-194-





95 above).









FIG. 8, and ¶¶ 104-108 above).









-195-


example, Ex. 1006 at 7:60-8:2).





and 17:63-18:2).


gateway) comprising a “packet path selector” (for example, the structural

elements depicted in annotated FIG. 4 herein in ¶ 404 above) that selects

“between a path through an Internet-based network and a path through a private

network that is not Internet-based” (for example, the depicted packet path

selector of FIG. 4 as shown in ¶ 404 above compares information in each packet

received at the CL-CO gateway to determine if the packet will be routed to the

CL network interface output line card or to the CO network interface output line

card) on a “per-packet basis” (for example, each packet routing decision is

unique to a particular IP datagram).


element under the broadest reasonable interpretation proposed herein (see ¶¶ 72,

73 and 75 above).



-196-



additional information disclosing “a path through an Internet-based network and

a path through a private network that is not Internet-based,” is required to

disclose this claim element, Zhang discloses this feature for all the reasons given

in ¶¶ 295-296 above with respect to claim 7[c]. Therefore, in my opinion, Karol

in view of Zhang renders obvious the limitations of this claim element under the

broadest reasonable interpretation proposed herein (see ¶¶ 72, 73 and 75 above).

414. In the event that the Board finds that the requirement of “a packet path

selector which selects, within the controller on a per-packet basis, between a path

through an Internet-based network and a path through a private network that is

not Internet-based” in claim 19[c] is not sufficiently disclosed by the combination

of Karol and Zhang, claim 19 is rendered obvious over Karol and Zhang further

in view of McCullough for all the reasons described in ¶¶ 298-300 above with

respect to claim 7[c]. Therefore, in my opinion, Karol in view of Zhang, further

in view of McCullough renders obvious the limitations of this claim element

under the broadest reasonable interpretation proposed herein (see ¶¶ 72, 73 and

75 above).

19(d): wherein the controller receives a packet through the site interface and sends the packet through the network interface that was selected by the packet path selector.



-197-






mentioned elements and direct them to external networks” (see, for example,

¶¶ 92-95 above, Ex. 1006 at 6:44-50 and FIG. 4 as annotated herein in ¶ 404

above). An exemplary process for determining the network path selection and

actual forwarding to the CL or CO network interface is described in detail at FIG.

5 of Karol (see, for example, ¶¶ 97-100 above, Ex. 1006 at 8:56-9:36 and FIG. 5

as annotated herein).



-198-

416.


structural elements depicted in annotated FIG. 4 herein in ¶ 404 above) within a

“controller” (for example, the CL-CO gateway) that “receives a packet” (for

example, IP datagram from the source endpoint is routed to the CL-CO gateway)

through the “site interface” (for example, one or more of the input line cards

and/or a network connection) and then “sends the packet through the network

interface that was selected by the packet path selector” (for example, the depicted


the CL-CO gateway and then routes each packet either to the CL network



-199-

interface output line card or to the CO network interface output line card




above).





‘048 Patent: Claim 20 20. The controller of claim 19, wherein the controller controls access to a frame relay private network through a first network interface of the controller, and the controller controls access to the Internet through a second network interface of the controller.

20. The controller of claim 19, wherein the controller controls access to a frame relay private network through a first network interface of the controller, and the controller controls access to the Internet through a second network interface of the controller.





above.



-200-



switches, controls access to either a “connectionless” (or “CL”) network data path

or to a “connection oriented” (or “CO) network data path (see, for example, Ex.

1006 at 1:7-16). Karol specifically describes the CL network as being based upon

the “Internet Protocol or "IP"” and the CO network as being based upon “ATM,

MPLS, RSVP” or a “telephony network” (see, for example, Ex. 1006 at 1:7-16,

2:52-58). This is further illustrated in and described with respect to FIG. 1 of Karol

(see, for example, ¶¶ 83-91 above, Ex. 1006 at 2:65-67, 4:36-67, and FIG. 1 as



whereby the “CL-CO gateway”, alone or in combination with one or more routers

and/or switches, receives datagrams (or “packets”) and such “datagrams received

in input line cards 401 can be directed either to CO switch 410 or CL router/switch





gateway) that “controls access” to a “private network through a first network

interface of the controller” and to “the Internet through a second network interface



-201-

of the controller” (for example, the depicted packet path selector of FIG. 4





424. However, although Karol does not explicitly disclose the exemplary

embodiment wherein the private CO network is a “frame relay” private network,

Karol does disclose an X.25 network which was the logical precursor of frame

relay (see, for example, Ex. 1006 at 13:62-67). In my opinion, the knowledge and

common sense of the person of ordinary skill in the art at the time of the invention

was sufficient to extrapolate from the disclosures of Karol to such an interpretation

at least because this was within the skill of person of ordinary skill in the art at the

time of the invention, obvious to try and yielded predictable results as evident by at

least the following reasons.

425. First, a person of ordinary skill in the art at the time of the invention

would consider a “frame relay” network to be a well known example of a

connection oriented or CO network as described in Karol and moreover such

description is explicitly provided within the intrinsic record of Karol (see, for

example, ¶¶ 82-109 above). For example, Stallings, a common reference textbook

on data and computer communications, specifically discloses that “frame relay”



-202-

has “widespread use in a variety of public and private networks” (emphasis added,

see, for example, Ex. 1011 at p. 302). At least because only a finite number of CO

networks appropriate to the disclosures in Karol of “combining connections for

access” to an Internet-based network in parallel with a CO network from a second

provider were known at the time of the invention, such as MPLS, ATM or frame

relay CO networks, a person of ordinary skill in the art at the time of the invention

would have found substituting for an MPLS or ATM exemplary CO network as

explicitly disclosed in Karol with a known frame relay exemplary CO network to

be obvious to try in the context of Karol and this claim element. Furthermore, at

least because the characteristics of such MPLS, ATM, or frame relay exemplary

CO networks would have been readily understood by a person of ordinary skill in

the art at the time of the invention, such a substitution to a frame relay CO network

would be highly likely to produce a successful and predictable result.

426. Second, the ‘048 Patent explicitly admits that a person of ordinary

skill in the art at the time of the invention would have known about routing packets

across multiple parallel disparate networks wherein a first network is Internet-

based and a second network that is frame relay based (see, for example, ¶¶ 130-132

above). At least because only a finite number of CO networks appropriate to the

disclosures in Karol of “combining connections for access” to an Internet-based

network in parallel with a CO network from a second provider were known at the



-203-

time of the invention, such as MPLS, ATM or frame relay CO networks, a person

of ordinary skill in the art at the time of the invention would have found

substituting for an MPLS or ATM exemplary CO network as explicitly disclosed

in Karol with a known frame relay exemplary CO network to be obvious to try in

the context of Karol and this claim element. Furthermore, at least because the

characteristics of such MPLS, ATM, or frame relay exemplary CO networks would

have been readily understood by a person of ordinary skill in the art at the time of

the invention, such a substitution to a frame relay CO network would be highly

likely to produce a successful and predictable result.

427. Therefore, in my opinion, the combination of Karol and one or more

of Zhang or McCullough, in view of the knowledge of the person of ordinary

skill in the art renders obvious the limitations of this claim element under the

broadest reasonable interpretation proposed herein (see ¶¶ 72-73 above).

‘048 Patent: Claim 21 21. The controller of claim 19, wherein the packet path selector selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.

21. The controller of claim 19, wherein the packet path selector selects between network interfaces according to a load-balancing criterion, thereby promoting balanced loads on devices that carry packets on the selected path after the packets leave the selected network interfaces.





-204-



above.

429. See, for example, ¶¶ 224-237 above regarding claim 3. Also "[i]n the

parallel configuration, since at least two paths exist between the originating and

destination CL nodes, one using the CL network and the other using the CO

network, there is always a routing choice, i.e., CL to CO to CL or entirely CL.

The gateway can make the routing selection based on maximizing efficiency.”

(Exhibit 1006 3:61-66, emphasis added). Karol also discloses that “[t]he decision

to set up CO connections is made at CL-CO gateway 140, based on the user-



understand that load-balancing is a means of maximizing efficiency and

accounting for “the traffic situation” is part of load-balancing.

430. Thus, Karol discloses the “packet path selector” (for example, the


selects between “network interfaces” (for example, as described in ¶¶ 403-411

above), and further that such selection be made “according to a load-balancing

criterion” (for example, the flows at CL-CO gateway that get routed to the CL or

CO network are dynamically allocated in an as-needed basis to dynamically



-205-

divert away from congested links based upon a bandwidth availability criterion),

thereby “promoting balanced loads on devices that carry packets on the selected

path after the packets leave the selected network interfaces” (for example, the



CO networks).



above).



additional information disclosing “wherein the packet path selector selects

between network interfaces according to a load-balancing criterion, thereby

promoting balanced loads on devices that carry packets on the selected path after

the packets leave the selected network interfaces,” is required to disclose this

claim element, McCullough discloses this feature. See, for example, ¶ 233 above

regarding claim 3. Therefore, in my opinion, Karol in view of Zhang, further in

view of McCullough renders obvious the limitations of this claim element under

the broadest reasonable interpretation proposed herein (see ¶ 79 above).



-206-

‘048 Patent: Claim 22 22. The controller of claim 20, wherein the packet path selector selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.

22. The controller of claim 20, wherein the packet path selector selects between network interfaces according to a reliability criterion, thereby promoting use of devices that will still carry packets on the selected path after the packets leave the selected network interfaces, when other devices on a path not selected are not functioning.


McCullough and the knowledge of a POSITA renders obvious the recited Claim

22 of this claim element under either the broadest reasonable interpretation or the

various alternative interpretations described above for at least the reasons

summarized in ¶¶ 385-427 above.












-207-







435. Thus, Karol discloses the “packet path selector” (for example, the


selects between “network interfaces” (for example, as described in ¶¶ 403-411

above), and further that such selection be made “according to a reliability

criterion” (for example, the flows at CL-CO gateway that get routed to the CL or

CO network are selected based upon ensuring reliability for such flows by

guaranteeing quality of service, meeting bandwidth needs, and diverting away

from congested links), thereby “promoting use of devices that will still carry

packets on the selected path after the packets leave the selected network

interfaces, when other devices on a path not selected are not functioning” (for

example, the adjustment of link weights to reflect bandwidth availability avoids

congested links such that if a link on either of the CL and CO networks is not

functioning due to inadequate bandwidth availability, then use of the CL or CO

network path with bandwidth availability will be promoted).



-208-



above).

‘048 Patent: Claim 23 23. The controller of claim 19, wherein the controller sends packets from a selected network interface to a VPN.

23. The controller of claim 19, wherein the controller sends packets from a selected network interface to a VPN.





above.



gateway) that “sends packets” from a “selected network interface” to an

“Internet-based network” (for example, the depicted packet path selector of FIG.

4 compares information in each packet received at the CL-CO gateway and then






-209-







above).

‘048 Patent: Claim 24 24. The controller of claim 19, wherein the controller sends packets from a selected network interface to a point-to-point private network connection.

24. The controller of claim 19, wherein the controller sends packets from a selected network interface to a point-to -point private network connection.





above.



gateway) that “sends packets” from a “selected network interface” to a “point-to-

point private network connection” (for example, the depicted packet path selector

of FIG. 4 compares information in each packet received at the CL-CO gateway



-210-

and then routes each packet either to the Internet-based CL network interface

output line card or to the point-to-point private network-based CO network

interface output line card according to the process described in FIG. 5).



above).



-211-

IX. CONCLUSION

445. In my opinion, claims 1, 3-7, 9-13, 15-19, and 21-24 of the ‘048

Patent are invalid for at least the reasons stated above.

446. I reserve the right to supplement my opinions in the future to respond

to any arguments raised by the owner of the ‘048 Patent and to take into account

new information that becomes available to me.

447. I declare under penalty of perjury that all statements made herein are

of my own knowledge and are true and correct. Signed on this 21stth of March,

2017 at North Adelaide, South Australia, Australia.

Respectfully submitted,

Leonard J Forys


Attachment A


Dr. Leonard J. Forys 823 Holmdel Road Holmdel, NJ 07733 732-739-8820 (W); 732-673-4086(M); 732-739-4982(H) email:[email protected],website:www.forysconsulting.com

Education

U. of Notre Dame Notre Dame, Indiana B.S. in Electrical Engineering

Massachusetts Institute of Technology Cambridge, Massachusetts S.M. and E.E. in Electrical Engineering

U. of California Berkeley, California Ph.D. in Electrical Engineering and Computer Science

Employment

NASA Moffett Field, California Aerospace Engineer

U. of California Berkeley, California Assistant Professor of Electrical Engineering and Computer Science

Bell Telephone Laboratories Holmdel, NJ Member of Technical Staff

Bell Telephone Laboratories Holmdel, NJ Technical Supervisor

Bell Communications Research Red Bank, NJ District Manager

1959 - 1963

1963 - 1965

1965 – 1968 1965

1967 – 1968

1968 - 1973

1973 - 1984

1984- 1994

1989


mailto:[email protected]

U. of Adelaide Adelaide, Australia Invited Professor of Applied Mathematics

Bell Communications Research Red Bank, NJ Chief Scientist

The Forys Consulting Group Inc. (EIN 22-3369136) Holmdel, NJ President

ISC Consulting New York, NY Algorithm Specialist

Glastonbury Musings Holmdel, NJ Senior Consultant on NSF Grant

Awards received

Eta Kappa Nu Runner-up: Outstanding Young Electrical Engineer (USA) of the Year Award

Bell Communications Research Red Bank, NJ Award of Excellence

Bell Communications Research Red Bank, NJ Bellcore Fellow (5th to receive this award)

Functional summary

Technical Analyses, Generic Requirements, Traffic Engineering I led the Bellcore effort to test and analyze a number of ISDN data applications on #5ESS, DMS 100F and Siemens EWSD. I also analyzed various network elements in X.25 packet networks including products from Siemens, NTI and BBN. Had prime responsibility for traffic, network management and performance sections of Bellcore’s Packet Switch Generic Requirements documents. I developed algorithms to design low speed packet networks, which resulted in prototype software. I developed a fundamental new methodology to service packet networks using simple measurements of burstiness.

Data Traffic Characterization, ATM traffic engineering I headed the Bellcore effort to demonstrate inadequacy of current traffic models for engineering of high-speed data and other ATM applications. One of the main areas of application was Internet

1994 - 1995

1995 – present 2000- present 2009-2010

1974

1988

1992

Low Speed Data

High Speed Data


traffic engineering. Was responsible for developing alternative, fractal and self-similar, traffic models which can accurately predict effects of actual high-speed data traffic on system performance. I developed a world-leadership position in developing ATM traffic engineering methodologies. I proposed and modified several Bellcore generic requirements for local access technologies.

Network Integrity Analysis I was Bellcore’s prime technical leader for determining root causes and proposing solutions in several SS7 outages including the 1990 ATT outage and the 1991 DSC STP outages. I had responsibility for the performance and robustness testing of several key Intelligent Network elements and their network management protocols. These included most of the SSPs and STPs used by the RBOCs and two SCPs.

IN Requirements

I was responsible for refining the performance requirements for Intelligent Network elements and end-to-end objectives. Part of this responsibility included the development of mathematical models of AIN performance. This resulted in identification of several problems in the existing SS7 protocols and the performance impacts of a number of proposed solutions were quantified.

PCS & IN Architectures

I had responsibility for determining the impacts of various architectures on PCS (cellular) performance. This included the placement of AIN triggers in switch configurations, various PCS architectures and their performance characteristics, and the real time impacts of selecting protocol parameters for key AIN features such as automatic-call-back.

Technical Analyses I analyzed (and tested) traffic engineering algorithms, traffic performance during normal and overload conditions, and the adequacy of traffic measurements for a number of voice switches. Special emphasis was put on real-time capacities of processors. These switches included: AT&T’s Nos. 1/1A, 2, 4 and 5 ESS; DCT, Dimension PBX and VMS; NTI’s DMS 100F including the SuperNode SE, DMS 200, TOPS and QMS; Siemens’ EWSD; Ericsson’s AXE; DSC’s Megahub; Rockwell’s DCD and parts of others. I was first to quantify effects of non-stationary and non-Poisson traffic on SPC switch performance.

Network Management, Capacity, Traffic, and Overload Requirements I was responsible for developing and maintaining several sections of Bellcore’s Local Switching Systems Generic Requirements (LSSGR) including sections on switch capacity estimation, traffic engineering, overload performance, traffic measurements and essential service protection. I invented the Last- In-First-Out (LIFO) overload strategy used in most modern switches in the US market and required by the LSSGR. I discovered the “traffic synchronization” effect, which can produce undesirable chaotic behavior in switches, and I developed an easily implementable solution. I was part of team that wrote the original requirements for the #5ESS.

Forcing and Facilities Algorithms I had prime responsibility for over 15 years for developing and maintaining all call center force staffing algorithms for the pre-divestiture AT&T and later for the Bell Operating Companies. I also had prime responsibility for facilities engineering issues (see above under Switch Analysis). I was

Intelligent Network

Switch Analysis

Switch Requirements

Operator Services


a key supporter of the economic introduction of new technologies into call centers. I am currently an algorithm specialist for ISC, a company who makes call center staffing software.

Overload and Outage Analyses, Priority Traffic, Network Management I was prime technical contributor to National Emergency Telecommunications System (NETS) study that characterized the impacts of various network outage scenarios on local switch performance. Proposed priority algorithms and quantified their effects in mitigating service impacts on high-priority users. I was sponsored by the NSF to represent the US telecommunications industry at a joint US-Japan earthquake symposium. I analyzed the impacts of earthquakes on local exchange service.

Traffic Forecasting, Private network analysis, Faulty trunk analysis, Video on Demand

I pioneered the introduction of Kalman filtering techniques for traffic forecasting. Analyzed, and resolved, chronic trouble conditions in private networks which included both voice and data. I analyzed trunk termination problems in switching system, as well as network engineering and design. I pioneered the performance analysis of faulty telecommunications trunks having short, but ineffective, holding times. I analyzed several alternatives for providing video on demand services.

Analysis of V-Mail Systems, traffic engineering, switch impact I analyzed (and tested) the traffic handling capabilities of several voice mail platforms and analyzed their engineering algorithms. I determined appropriate engineering loading levels for switch access. I determined switch capabilities and SMDI link limitations for various products.

Aerospace Applications, Satellite Communications, Air Traffic Control I developed optimum algorithms for an infrared tracking system, and optimal detection of initial positions of dynamic objects. I determined optimum radar pulse allocation algorithm, and bounds on transmission rate performance through unknown channels. I analyzed the performance of UPCM coding system. I applied Kalman Filtering algorithms to predict traffic in telecommunications satellite application. I developed models and a validation methodology for air traffic control management system.

University Courses, In-Hours Courses, Outside Short Courses

I developed and taught advanced undergraduate courses in circuit theory, system theory and communications theory. I developed and taught graduate university courses in Teletraffic Models; one emphasizing theory for Ph.D. students, the other emphasizing applications for industry students. I developed and taught several in-hours courses at Bell Labs and Bellcore: Linear Discrete-Time Filtering Theory, Congestion Theory, Advanced Traffic Theory, Real Time Capacity Estimation and Computer Performance Analysis. I also developed and taught short (1-2 day) courses for industry, including the FCC: Introduction to Traffic Engineering.

Publications and Professional Activities

I have contributed extensively to various journals and conferences. I was session chairman at variety of conferences. I have over 39 external publications and talks. I was a reviewer for several technical journals and conferences. I also was a large grant reviewer for the Australian Research Council.

Network Vulnerability

Voice Networks

Voice Mail Systems

Communication and Control Theory

Teaching


Consulting Activities 6/1995-12/2016 (30+ worldwide clients) Analyzed the impacts of Internet access for a major telecommunications carrier. . Analyzed the effects of local switch switching architectures on Internet access. Developed approaches to quantify the performance of various bandwidth-sharing algorithms for ADSL Analyzed (and optimized) the traffic engineering methods provided by three major suppliers of hybrid fiber/coax networks. Analyzed network and switching costs for a voice over cable proposal for an international supplier. Analyzed performance, provided traffic inputs, and helped specify traffic network management/ congestion controls for three packetized voice and data satellite communications systems and analyzed impacts of web caching for a fourth system Established quality of service metrics for large packet switched network on behalf of a major telecommunications carrier. For a large consulting firm, I estimated the equipment augmentation necessary to meet various traffic demands for a variety of data technologies including ATM, Frame Relay and MPLS. Analyzed optimal buffer designs for major Asynchronous Transfer Mode (ATM) data switch supplier. Assessed the effectiveness and efficiency of several suppliers’ ATM Call Admission Controls. Developed CAC algorithms that account for self-similar data traffic, as well as other applications. Investigated merits of using ATM Variable Bit Rate data services to handle associative broadband signaling. Analyzed various Intelligent Network Local Number Portability implementations for a large telecommunications supplier. Wrote a white paper for an Asian regulatory commission analyzing the issues involved in network interconnection for both trunking aspects and SS7 signalling. On behalf of the European Commission, served as an advisor on a Intelligent Network research project. As part of a team of 4 internationally recognized experts, conducted an analysis of nearly all aspects of a modern digital switch in a foreign national network including network management and operational issues. Analyzed the success of a major system provider in integrating a new switching system into its daily operations/network management systems. Resolved capacity and performance problems experienced by a CLEC with a modern digital switch. Analyzed the capabilities of an emerging switching product on behalf of a large potential

Internet Impact

Internet Access

ADSL Performance

Hybrid Fiber/Coax

Satellite Communications

ATM Engineering

ATM Buffer Design

ATM CAC

ATM Signaling

IN and LNP

IN Interconnection

IN Advisor

Switch Analysis

Switch Operations

Switch Performance

Capability Assessment


investor. Determined adaptive algorithms to predict load and force requirements for the IRENE™ call center product. Provided new approach to force management for a large carrier. Was the key technical support expert for international sales for ISC, as well as the key algorithm specialist. On behalf of an Asian regulatory agency analyzed the efficacy of measurements for universal service obligations. Director of Performance Analysis for GLADSIS. Helped architect, engineer and market/sell two client server systems. Consulted on engineering and operational issues for screen based phones providing Internet access, SMS type service using ADSI. Assisted major client in developing advertising capabilities for screen based phones. Analyzed the network routing and signaling capabilities of a major IXC. Defined the functional specs, detailed algorithm specification and GUI specs for a network planning simulation used by a fiber optic switch company. Also defined the functional specs for a network planning tool and capacity expansion tool and network management system. Was responsible for bottleneck analysis and contributed to reliability analysis of a fiber optic switch. Responded to various RFPs for fiber optic technology. Consulted on fiber optic switch design for two fiber optic switch companies. Consulted for a large international consulting company on network design and growth for a variety of network elements including voice, voice over IP, frame relay, ATM, wide area Ethernet.

Helped design, plan and sell a demo emergency notification system to a major telecommunications company. Consulted on technical matters and assisted in international sales for company offering optimal sequencing products. Helped develop and implement a successful NSF proposal for optimally assigning class rooms, students and faculty and parking facilities in a university setting. Expert witness/consultant in many projects involving cellular and landline network performance and cellular architectures/features; IP and patents for data networks, network management, internet technologies including VoIP, ATM networks and switches, IP routing protocols, AIN, voice and data switching, satellite communications, network restoration, agent collaboration, wireless LANs, WiMax, mobile routing protocols, Unlicensed Mobile Access (UMA), voice mail and switch features, locality searches, calling card technology and call center technology, network interface controllers, network restoration, institution communications systems; cellular telephone features: 2 large class action suits involving ISP performance issues, and a contract indemnification dispute.

Call Center Forcing

Regulatory Measurements

Client Server Engineering

IXC Analysis

Fiber Optic Networks

Consultant on Network Design Emergency

Notification System Optimal Sequencing

Expert Witness/Consultant


External Publications/Talks

Dr. Leonard J. Forys

1. “Using Metaheuristics and Queueing Models to Optimize Schedules in the

Academic Enterprise” (with C. Pack, E. Christenesen, R.M. Potter and A. Erramilli) Symposium on Computational Intelligence in Scheduling organized in IEEE Symposium Series in Computational Intelligence March 2011.

2. “Traffic Synchronization and Chaos”, Advances in Control, Communications

Networks and Transportation System, E. H. Abed, editor, Birkhauser Boston MA, June 2005.

3. “Comparing Work Force Management Systems”, invited talk, TUANZ (in 4

cities, New Zealand) May 2003

4. “Traffic Synchronization”, invited talk, U. of Otago, NZ, May 2003.

5. “Chaos in Computers and the Internet”, invited talk, U. of Otago, NZ, May 2003.

6. “Does Modeling Work?”, invited talk, International Conference on Computer Communications”, Princeton NJ, October 1997

7. “Impact of ISP Load on the PSTN”, invited paper, International Communications

Congress 1997, Montreal, Canada June 1997.

8. “Teletraffic Professional Practice”, invited speaker, Proceedings of the 15th International Teletraffic Congress, Washington D.C. June 1997.

9. “New Traffic Engineering and Analysis Methods for Emerging Technologies”,

Proceedings IEEE Globecom, pp. 848-854, Singapore, November 1995.

10. “Chaotic Phenomena in Communications Networks” (with A. Erramilli), SIAM Conference on Dynamical Systems, San Francisco California, 1992.

11. “Earthquake-Induced Congestion Impacts on Local Telephone Networks”, invited

paper, Fifth U.S.-Japan Earthquake Disaster Prevention Symposium for Lifeline Systems”, Tsukuba, Japan, October1992.

12. “An Earthquake-Induced Congestion Modeling Approach for LECs”, invited

paper, Workshop on Assessing State-of-the-Art Approaches to Communications Lifeline Modeling for Earthquake Disasters, Seattle, Washington, August 1992.


13. “Traffic Synchronization Effects in Teletraffic Systems”, (with A. Erramilli) Proceedings of the 13th International Teletraffic Congress, Copenhagen, Denmark, June 1991.

14. "Generic System Performance Modeling Issues", Proceedings 1991 National

Communications Forum, Chicago Illinois, September 1991.

15. "Traffic Engineering", Proceedings 1991 Eastern Communications Forum, Washington DC, 1991.

16. "Traffic Synchronization Effects in Teletraffic Systems", (with A. Erramilli),

Proceedings 13th International Teletraffic Congress, Copenhagen, Denmark, June 1991.

17. "Oscillations and Chaos in a Flow Model of a Switching System", (with A.

Erramilli and E. Shyamsunder), JSAC special issue: Teletraffic Analysis of Communications Systems, February 1991.

18. "Issues Impacting System Performance Modelling", Proceedings of 1990

National Communications Forum, Chicago Illinois, October 8, 1990.

19. "Servicing of Bursty Systems", International Teletraffic Congress Specialist's Seminar, U. of Adelaide, September 1989.

20. "Review of Real Time Capacity Issues", Proceedings of 1989 National

Communications Forum, Chicago, Illinois, October 1989

21. "Major Capacity Issues from the User's Perspective", Proceedings of 1988 National Communications Forum, Chicago, Illinois, October 1988.

22. “Analysis of Load Box Testing for Voice Switches”, Proceedings 12th

International Teletraffic Congress (ITC), Turin, Italy June 1988. 23. "Performance Analysis of a New Overload Strategy, Proceedings 11th

International Teletraffic Congress (ITC), Kyoto, Japan 1986.

24. "Modelling of Large Packet Switch Networks", Proceedings International Seminar on Teletraffic Analysis and Computer Performance Evaluation, Amsterdam, Netherlands, 1985

25. "New Overload Issues in a Divested Environment", Proceedings 10th

International Teletraffic Congress, Montreal, Canada, 1983.

26. "Analyzing the Effectiveness of Audible Ringing", (with H. Zucker), Proceedings of the 10th International Teletraffic Congress Montreal, Canada, 1983.


27. "Coping With Overloads", Bell Laboratories Record, July-August 1981, (also Telephony Magazine, Vol. 201, No. 15, October 5, 1981, pp. 78-83.)

28. "A Characterization of Traffic Variability for SPC Systems", Proceedings 9th

International Teletraffic Congress, Torremolinos, Spain, 1979.

29. "Modelling of SPC Switching Systems", Proceedings ITC Seminar on Modeling of Stored Programme Controlled Exchanges and Data Networks, pp. 83-100, Delft, Netherlands, 1977

30. "Analysis of Trunk Groups Containing Short-Holding-Time Trunks" (with E.J.

Messerli), The Bell System Technical Journal, Vol. 54, No. 6, July-August 1975.

31. "A Study of the Analysis and Control of the Flow of Air Traffic: Part I", (several co-authors), Networks, Vol. 1, pp. 15-42, 1972.

32. "A Study of the Analysis and Control of the Flow of Air Traffic: Part II", (several

co-authors), Networks, Vol. _1, pp. 209-243, 1972.

33. "A Study of the Analysis and Control of the Flow of Air Traffic: Part III", (several co-authors), Networks, Vol. 1, pp. 303-331, 1972.

34. "The Determinability of Classes of Noisy Channels", The Bell System Technical

Journal, Vol. 48, No. 10, December 1969.

35. "The Epsilon-Capacity of Classes of Unknown Channels", (with P. Varaiya), Information and Control, Vol. 14, No. 4, pp. 376-406, April 1969.

36. "A Note Concerning Observable but not Controllable Modes, and Stability", (with

C.A. Desoer), IEEE Transactions on Circuit Theory, February 1969.

37. "On the Continuity of Closed-Loop Feedback Relations", IEEE Transactions on Automatic Control, December, 1967.

38. “Perturbations of Optimal and Sub-Optimal Control Problems” (with P. Varaiya),

Electronic Research Laboratory, U. of California Berkeley, Memorandum No. ERL-M206, 8 March 1967.

39. "On the Stability of Systems Containing a Time-Varying Gain", (with R.

Brockett), Proceedings Second Annual Allerton Conference on Circuit and System Theory, pp. 413-430, September 1964.


Hired by Adversary Case

Identification Nature of Case Involvement

Global Tel*Link

(Sterne Kessler)

Securus Technologies

Case IPR2015-01222, Patent 8,750,486

Inter Partes Review

Call Center Providing Goods and Services to Inmates

1/2 day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2015-01221, Patent 8,489,068

Inter Partes Review

Alternative Billing Methods

1/2 day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2015-01219, Patent 8,626,118

Inter Partes Review

Monetizing Collect Cellular Calls

1/2 day deposition

Global Tel*Link

(Sterne Kessler)


Case CBM2015-00145 Patent 7,860,222

Covered Business Method

Institutional Communications Systems

1/2 day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2015-00155, Patent 7,853,243

Inter Partes Review

User authentification in institutions

One day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2015-00156, Patent 7,551,732

Inter Partes Review

Voice recording, monitoring and retrieval

One day deposition


Time Warner Cable, Inc.

(Kaye Scholer)

Sprint Communications Co.

US District Court, District of Kansas, Case No. 11-2686-JWL

Patent Infringement

(10 patents)

VoIP interworking

One day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00810, Patent 7,324,637

Inter Partes Review

Resource allocation and methods

One day deposition

LG Electronics MobileComm U.S.A.,

(Mayer Brown)

Mobile Telecommunications Technologies, LLC.

US District Court, Eastern District of Texas, Marshall Division

Case No. 2:13-cv-947-JRG-RSP

Patent Infringement (3 patents)

2-way pagers

One day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-01278 Patent 7,860,222

Inter Partes Review


Two one day depositions

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00825 Patent 7,529,357

Inter Partes Review


Half day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00824 Patent 8,340,260

Inter Partes Review Institutional Communications Systems

Half day deposition


Global Tel*Link

(Sterne Kessler)


Case IPR2014-00810 Patent 7,324,637

Inter Partes Review


One day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00749 Patent 8,577,003

Inter Partes Review


Half day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00493

Patent 7,899,167

Inter Partes Review


Half day deposition

Global Tel*Link

(Sterne Kessler)


Case IPR2014-00785

Patent 6,636,591

Inter Partes Review


One day deposition & ½ day deposition

Amazon.com Inc (Latham Watkins)

Telebuyer, LLC Telebuyer LLC v. Amazon.com, Inc.

US District Court for the Western District of Washington at Seattle

Case No. 2:13-cv-01677-BJR


Network Transaction Systems

One day deposition

Marvell Semiconductor

(Quinn Emanuel)

U.S. Ethernet Innovations, LLC

U.S. Ethernet Innovations, LLC,

vs. Acer, Inc., et


Network

One day deposition


al.,

and Atheros Communications, Inc. et al., Intervenors and related third party compaints.

US District Court, Northern District of California, Oakland Division

CASE NO. 4:10-cv-03724-CW (LB)

Interface Controllers

AT&T

(McDermott, Will & Emery)

TR Labs TR Labs v. AT&T et al

US District Court New Jersey

No. 09-3883(PGS)(DEA)

Patent Infringement

(1 patent)

Network Restoration

One day deposition

Muzak

(Baker Hostetler)

Info-Hold Info-Hold, Inc. v. Muzak Holdings LLC and Muzak LLC

US District Court

Southern District of Ohio, Western Division

No. 1:11-cv-283

Patent Infringement (1 patent)

Music Distribution Systems

Two depositions

Cisco (Morgan Lewis)

XpertUniverse XpertUniverse, Inc. v. Cisco Systems

US District Court District of Delaware

No. 09-157-RGA

Patent Infringement, Trade Secret Misappropriation

Collaboration Systems

One day Deposition, trial testimony


Siemens et al (Pepper Hamilton LLP)

Defendant

vTRAX Technologies Licensing, Inc.

VTRAX Technologies Licensing, Inc. v. Siemens Communications, Inc. et. al.

US District Court Southern District of Florida, West Palm Beach Division, case No. 9:10-cv-80369 KLR, filed 3/10/2010

Patent Infringement

Collaboration Systems

One day Deposition

Jingle Networks Inc

(Sterne, Kessler, Goldstein & Fox) - Defendant

Grape Technology Group & KGB USA

Grape Technology Group, Inc. et al v. Jingle Networks

US District Court for the District of Delaware

Case No. 1:08-cv-00408-GMS, filed 7/3/2008

Patent Infringement

Call Center Technologies

One day deposition,

trial testimony

XM/Sirius, Geico (Kramer Levins, Venables) - Defendant

Ronald A. Katz In re Katz Interactive all Processing Patent Litigation,

US District Court Central District of California

Case No. 2:07-ml-01816- RGK -FFM filed 3/30/2007

Ronald A Katz Technology Licensing L. P. v Comcast Corporation et al

Case No. 2:07-cv-06996-RGK-

Patent Infringement


One day deposition


FFM, filed 10/26/20-07

Bell South (Sidley Austin) - Defendant

Florida Power and Light

Carolina Power & Light Company et

al. v. Aspect Software, Inc. el

al.,

THE UNITED STATES

DISTRICT COURT

FOR THE EASTERN

DISTRICT OF NORTH

CAROLINA

WESTERN DIVISION

Case No. 5:08-cv-00449-BO, filed 09/09/2008

Patent Infringement, Contract Indemnification


One day deposition


active 88090184 4 dr. forys dec iso second ipr on 048 patent · 2017-03-22 · university of...

Documents