UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GUEST TEK INTERACTIVE ENTERTAINMENT LTD.,
`
`Petitioner,
`
`v.
`
`NOMADIX, INC.,
`
`Patent Owner.
`
`U.S. Patent No. 8,606,917 to Short et al.
`Issued: December 10, 2013
`Filed: October 24, 2012
`
`Title: SYSTEMS AND METHODS FOR PROVIDING CONTENT AND
`SERVICES ON A NETWORK SYSTEM
`
`____________
`
`IPR2019-01191
`____________
`
`Declaration of Dr. Peter Dordal
`
`GUEST TEK EXHIBIT 1002
`Guest Tek v. Nomadix, IPR2019-01191
`
`

`

`TABLE OF CONTENTS
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................... 1
`
`QUALIFICATIONS AND PROFESSIONAL EXPERIENCE ...................... 1
`
`III. MATERIALS CONSIDERED IN FORMING MY OPINIONS .................... 3
`
`IV.
`
`V.
`
`VI.
`
`SUMMARY OF OPINION ............................................................................. 3
`
`UNDERSTANDING OF LEGAL PRINCIPLES ........................................... 4
`
`THE ‘917 PATENT ......................................................................................... 6
`
`VII. PRIORITY DATE FOR CLAIMS 1 AND 11 OF THE ‘917 PATENT ....... 10
`
`VIII. CLAIM CONSTRUCTION .......................................................................... 28
`
`IX.
`
`X.
`
`LEVEL OF ORDINARY SKILL IN THE ART ........................................... 30
`
`TECHNICAL BACKGROUND AND STATE OF THE ART AT TIME OF
`ALLEGED INVENTION .............................................................................. 31
`
`XI. OVERVIEW OF SPECIFIC PRIOR ART .................................................... 55
`
`U.S. Patent No. 8,046,578 (“Trudeau”) .............................................. 55
`
`David Whyte et al., DNS-based Detection of Scanning Worms in an
`Enterprise Network, Proceedings of the 12th Annual Network and
`Distributed System Security Symposium, San Diego, USA (Feb. 3-4,
`2005) (“Whyte”) .................................................................................. 56
`
`U.S. Patent No. 6,463,474 (“Fuh”) ..................................................... 59
`
`John Wack et al., Keeping Your Site Comfortably Secure: An
`Introduction to Internet Firewalls, NIST Special Publication 800-10
`(Dec. 1994) (“NIST”) .......................................................................... 62
`
`XII. OPINION REGARDING OBVIOUSNESS OF CLAIMS 1 AND 11 OF THE
`‘917 PATENT ................................................................................................ 65
`
`i
`
`

`

` My Opinion Regarding the Combination of Trudeau and Whyte ...... 66
`
` My Opinion Regarding the Combination of Trudeau, Whyte, and Fuh.
` ............................................................................................................. 70
`
` My Opinion Regarding the Combination of Fuh and NIST. .............. 76 
`
`
`
`

`

`I.
`
`INTRODUCTION
`1. My name is Dr. Peter Dordal, and I have been retained as a technical
`
`expert by counsel for Petitioner Guest-Tek Interactive Entertainment Ltd. to provide
`
`assistance in the above captioned inter partes review proceeding. Specifically, I
`
`have been asked by counsel to opine on the validity of claims 1 and 11 of U.S. Patent
`
`No. 8,606,917 (“the ‘917 patent”). This report contains a statement of my opinions
`
`formed in this matter and provides the bases and reasons for those opinions. I make
`
`the following statements based on my own personal knowledge and, if called as a
`
`witness, I could and would testify to the following.
`
`II. QUALIFICATIONS AND PROFESSIONAL EXPERIENCE
`2.
`I have included as Attachment A a copy of my current curriculum vitae,
`
`which provides an overview of my qualifications and professional experience in
`
`relation to this matter. To summarize, I received my undergraduate and masters’
`
`degrees in Mathematics in 1978 from the University of Chicago, and my Ph.D. in
`
`Mathematics from Harvard University in 1982.
`
`3.
`
`Since receiving my doctorate degree in 1982, I have been employed as
`
`a faculty member at Loyola University Chicago, first in the Mathematical Sciences
`
`Department and then, starting in 2001, in the newly formed Computer Science
`
`Department. I received tenure in 1988, and was at that time promoted to Associate
`
`Professor, my current rank. For the past 36 years, I have focused on teaching
`
`1
`
`

`

`computer programming courses to undergraduate and graduate students, including
`
`Programming Languages, Computer Networks, and Advanced TCP/IP Networks.
`
`During part of my tenure, I was Acting Chair and Graduate Program Director for the
`
`Computer Science Department. I am also currently supervising a student thesis
`
`called Software-defined Networking and Dynamic Traffic Rerouting.
`
`4.
`
`From 1984-2003, I was the System Administrator for departmental
`
`computing facilities at Loyola University. As System Administrator, my
`
`responsibilities included managing University computers and network services,
`
`supporting University workstations, and maintaining University computer labs.
`
`Sometimes this work entailed significant software development; for example, I
`
`implemented a TCP/IP layer for the University that allowed communication between
`
`computers supporting only the 3BNET networking software and a server supporting
`
`TCP/IP. My other exemplary experiences in system management and programming
`
`through the University are set forth in Attachment A.
`
`5.
`
`Since 1982, I have also spent a significant amount of time, as part of
`
`my everyday course preparation and teaching, conducting research on, as well as
`
`performing and demonstrating, computer programing and network device
`
`management and support.
`
`6.
`
`In addition to my professional experience, I have published a
`
`substantial number of books and articles on computer programming networks. For
`
`2
`
`

`

`example, I authored the book An Introduction to Computer Networks, published by
`
`Loyola University of Chicago in 2012. I also significantly contributed to the book
`
`Computer Networks: A Systems Approach, 2nd Edition, Peterson & Davie, Morgan-
`
`Kaufmann 2000, which provides computer network and protocol exercises for
`
`students. I fill list of my publications and contributions is shown in my attached
`
`curriculum vitae.
`
`7.
`
`I am a member of the Mathematical Association of America and the
`
`Association for Symbolic Logic.
`
`III. MATERIALS CONSIDERED IN FORMING MY OPINIONS
`8.
`In preparing this declaration, I have reviewed and relied on various
`
`materials, including but not limited to the following exemplary materials: (1) certain
`
`prior art, including the prior art cited in this declaration; (2) the ‘917 patent; (3) the
`
`‘917 patent’s prosecution history; (4) all patent applications to which the ‘917 patent
`
`claims priority; and (5) all of the other materials referenced in this declaration.
`
`IV. SUMMARY OF OPINION
`9.
`As described in more detail below, it is my opinion that claims 1 and
`
`11 of the ‘917 patent would have been obvious to a person of ordinary skill in the
`
`art under 35 U.S.C. § 103 over (1) U.S. Patent No. 8,046,578 in view of David Whyte
`
`et al., DNS-based Detection of Scanning Worms in an Enterprise Network,
`
`Proceedings of the 12th Annual Network and Distributed System Security
`
`3
`
`

`

`Symposium, San Diego, USA (Feb. 3-4, 2005); (2) the same combination further in
`
`view of U.S. Patent No. 6,463,474; and (3) U.S. Patent No. 6,463,474 in view of
`
`John Wack et al., Keeping Your Site Comfortably Secure: An Introduction to
`
`Internet Firewalls, NIST Special Publication 800-10 (Dec. 1994).
`
`V. UNDERSTANDING OF LEGAL PRINCIPLES
`10.
`I am not a legal expert and offer no legal opinions. I have been
`
`informed by counsel, however, of the various legal standards that apply to the
`
`pertinent technical issues, and I have applied those standards in arriving at the
`
`conclusions expressed in this report. I understand that determining the validity of a
`
`patent requires a two-step analysis. First, the meaning and scope of the patent claims
`
`are construed and then the construed claims are compared to the prior art.
`
`11.
`
`It is my understanding that to prove that a claim is invalid for
`
`obviousness under 35 U.S.C. § 103, the challenger of its validity must demonstrate
`
`that, for example, two or more prior art references in combination disclose, expressly
`
`or inherently, every claim limitation and also that the claim, as a whole, would have
`
`been obvious to a person of ordinary skill in the art at the time the invention was
`
`made. The relevant standard for obviousness is as follows:
`
`(a) A patent may not be obtained though the invention is not
`identically disclosed or described as set forth in section 102 of this
`title, if the differences between the subject matter sought to be
`patented 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 having ordinary skill in the art to which said subject matter
`4
`
`

`

`pertains. Patentability shall not be negatived by the manner in which
`the invention was made.
`35 U.S.C. §103.
`
`12.
`
`In determining whether or not a patented invention would have been
`
`obvious, the following factual inquiries must be made: (1) the scope and content of
`
`the prior art; (2) the differences between the prior art and the claims at issue; (3) the
`
`level of ordinary skill in the pertinent art at the time the invention was made; and (4)
`
`such secondary considerations as commercial success, long felt but unsolved needs,
`
`failure of others, etc.
`
`13.
`
`I understand that a patent composed of several elements is not proved
`
`obvious merely by demonstrating that each of its elements was, independently,
`
`known in the prior art. Most, if not all, inventions rely on building blocks of prior
`
`art. The challenger of the patent’s validity must prove that, at the time of the claimed
`
`invention, there was a reason that would have prompted a person having ordinary
`
`skill in the field of the invention to combine the known elements in a way the claimed
`
`invention does, taking into account such factors as: (1) whether the claimed
`
`invention was merely the predictable result of using prior art elements according to
`
`their known function(s); (2) whether the claimed invention provides an obvious
`
`solution to a known problem in the relevant field; (3) whether the prior art teaches
`
`or suggests the desirability of combining elements claimed in the invention; and (4)
`
`whether the change resulted more from design incentives or other market forces. To
`
`5
`
`

`

`find it rendered the invention obvious, the prior art must have provided a reasonable
`
`expectation of success.
`
`14.
`
`I further understand that it is not permissible to use hindsight in
`
`assessing whether a claimed invention is obvious. Rather, I understand that, to
`
`assess obviousness, you must place yourself in the shoes of a person having ordinary
`
`skill in the relevant field of technology at the time the invention was made who is
`
`trying to address the issues or solve the problems faced by the inventor, consider
`
`only what was known at the time of the invention and ignore the knowledge you
`
`currently now have of the inventions.
`
`15.
`
`I understand that certain objective evidence known as “secondary
`
`considerations,” such as commercial success, long-felt but unsolved needs, failure
`
`of others, and unexpected results, to the extent they exist, may be relevant in
`
`determining whether or not an invention would have been obvious. However, I am
`
`not aware of any such secondary considerations applicable with respect to claims 1
`
`or 11 of the ‘917 patent.
`
`VI. THE ‘917 PATENT
`16. The ‘917 patent describes systems and methods for “managing and
`
`providing content and services on a network system.” Abstract. The patent
`
`describes network access controller (AC) that receives a transmission control
`
`protocol (TCP) request from a source device, such as a laptop, for access to the
`
`6
`
`

`

`Internet, intranet, or other communications network. In one embodiment, the request
`
`includes the Internet Protocol (IP) address of the source device, as well as the IP
`
`address of the Internet server or other destination server that the source device is
`
`trying to communicate with. ‘917 patent at 3:57-61. The AC uses that information
`
`in evaluating whether the source device is allowed to access the destination server
`
`or network.
`
`17. The embodiments related to claims 1 and 11 are described in the
`
`patent’s “Summary” section. The Summary explains that, after receiving the
`
`request, the AC determines whether authentication is required before network access
`
`is granted. The AC does so by comparing the source IP address with the IP addresses
`
`contained in profiles of authorized source devices. If the source IP address is
`
`included in a profile of an authorized source device, the source device is granted
`
`access without further authorization. ‘917 patent at 3:60-4:1.
`
`18.
`
`If the source IP address is not included in an authorized profile, the
`
`access controller determines whether the destination IP address is included in a
`
`plurality of destination IP addresses associated with the access controller. ‘917
`
`patent at 4:1-8. If the destination IP address is included in the plurality of destination
`
`IP addresses, the source device is granted access without further authorization.
`
`Maintaining lists of authorized addresses, often called “white lists,” that could be
`
`checked against the source or destination addresses in incoming packets has been a
`
`7
`
`

`

`well-known packet filtering or authorization technique since at least 1995. I provide
`
`an overview of address filtering techniques, including whitelists, in section X below.
`
`19.
`
`If the destination IP address is not included in the white list, the source
`
`device is redirected to a login page for entering credentials. Credentials could
`
`include data like a username and password. Once those credentials have been
`
`verified, the source device is allowed access to the network. ‘917 patent at 4:9-17.
`
`This feature was known in the prior art as a “captive portal,” a topic for which I will
`
`describe in detail in section X below.
`
`20. As mentioned, I have been asked to opine on the validity of claims 1
`
`and 11 of the ‘917 patent. Claim 1 recites a “method for granting access to a
`
`computer network.” Claim 11 recites most of the same limitations of claim 1, except
`
`claim 11 is in system form, directed to a “system for providing network access to a
`
`source device.”
`
`21. The full language of the claims is as follows, where the individual
`
`subparagraphs have been designated (1.a)-(1.g) and (11.a)-(11.e) for convenient
`
`reference:
`
`A method for granting access to a computer network, comprising:
`[1.a] receiving at an access controller a request to access the network from
`a source computer, the request including a transmission control protocol
`(TCP) connection request having a source IP address and a destination IP
`address;
`
`[1.b] determining by the access controller whether the source computer
`must login to access the network, including:
`8
`
`

`

`
`[1.c] comparing the source IP address with profiles of authorized source
`devices, each profile including an IP address, wherein if the source IP
`address is included in a profile of an authorized source device, the source
`device is granted access without further authorization, and
`
`[1.d] if the source IP address is not included in a profile associated with
`an authorized source device, then determining whether the destination IP
`address is included in a plurality of destination IP addresses associated
`with the access controller, wherein if the destination IP address is included
`in the plurality of destination IP addresses, the source device is granted
`access without further authorization, and
`
`[1.e] if the destination IP address is not included in the plurality of
`destination IP addresses, then the access controller determines the source
`device must be authorized to access the network and provides the source
`device with a login page;
`
`[1.f] using the access controller to authenticate credentials provided from
`the source device via the login page; and
`
`[1.g] authorizing the source device access to the network if the provided
`credentials are authenticated.
`
`Claim 11 recites mostly the same claim limitations in system form:
`A system for providing network access to a source device comprising:
`
`[11.a] an access controller configured to receive a request to access the
`network from the source device, the request including a transmission
`control protocol (TCP) connection request having a source IP address and
`a destination IP address,
`
`[11.b] the access controller further configured to redirect the source
`device to a login page if it is determined that authentication is required
`prior to network access being granted, the authentication based on;
`
`[11.c] comparing the source IP address with profiles of authorized source
`devices, each profile including an IP address, wherein if the source IP
`address is included in a profile of an authorized source device, the source
`device is granted access without further authorization, and
`9
`
`

`

`
`[11.d] if the source IP address is not included in a profile associated with
`an authorized device, then determining whether the destination IP address
`is included in a plurality of destination IP addresses associated with the
`access controller, wherein if the destination IP address is included in the
`plurality of destination IP addresses, the source device is granted access
`without further authorization, and
`
`[11.e] if the destination IP address is not included in the plurality of
`destination IP addresses, then the access controller authorizes network
`access to the computing device after authenticating user credentials
`received from the source device via the login page have been
`authenticated.
`
`VII. PRIORITY DATE FOR CLAIMS 1 AND 11 OF THE ‘917 PATENT
`22.
`I have been told and understand that, in order for the claims of a later-
`
`filed application to be entitled to the filing date of an earlier-filed application, the
`
`claims must have written description and enablement support in the earlier-filed
`
`application. My understanding is that 35 U.S.C. § 112 sets forth the written
`
`description and enablement requirements. As to written description, “[t]he
`
`specification shall contain a written description of the invention.” 35 U.S.C. § 112.
`
`I understand that the written description requirement is satisfied if a skilled artisan,
`
`reading the specification, would conclude that the inventor(s) had possession of the
`
`claimed invention. As to enablement, the specification must describe “the manner
`
`and process of making and using [the invention], in such full, clear, concise and
`
`exact terms as to enable any person skilled in the art to which it pertains, or with
`
`which it is most nearly connected, to make and use the same . . . .” Id. In other
`
`10
`
`

`

`words, the specification must contain sufficient disclosure such that a skilled artisan
`
`could make and use the claimed invention without having to conduct undue
`
`experimentation.
`
`23.
`
`I have reviewed U.S. patent application no. 13/659,851, which is the
`
`application that was filed for the ‘917 patent on October 24, 2012. I have also
`
`reviewed all of the earlier patent applications to which the ‘917 patent claims
`
`priority. Those applications include:
`
`U.S. patent application ser. no. 13/566,904 filed Aug. 3, 2012;
`
`U.S. patent application ser. no. 12/685,585, filed Jan. 11, 2010;
`
`U.S. patent application ser. no. 11/427,143, filed on Jun. 28, 2006;
`
`U.S. patent application ser. no. 09/693,060, filed on Oct. 20, 2000;
`
`U.S. patent application ser. no. 09/458,569, filed on Dec. 8, 1999;
`
`U.S. provisional application ser. no. 60/111,497 filed on Dec. 8, 1998;
`
`U.S. patent application ser. no. 09/458,602, filed Dec. 8, 1999;
`
`U.S. provisional application ser. no. 60/161,182, filed Oct. 22, 1999;
`
`U.S. provisional application ser. no. 60/160,890, filed Oct. 22, 1999;
`
`U.S. provisional application ser. no. 60/161,139, filed Oct. 22, 1999;
`
`U.S. provisional application ser. no. 60/161,189, filed Oct. 22, 1999;
`
`U.S. provisional application ser. no. 60/160,973, filed Oct. 22, 1999;
`
`U.S. provisional application ser. no. 60/161,181, filed Oct. 22, 1999; and
`
`11
`
`

`

`U.S. provisional application ser. no. 60/161,093, filed Oct. 22, 1999.
`
`24. Notably, Application 09/693,060 resulted
`
`in patent 7,194,554;
`
`application 11/427,143 resulted in patent 7,689,716. For the disclosures that are
`
`relevant here, the ‘554 and ‘716 patents are in most cases identical.
`
`25.
`
`In my opinion, claims 1 and 11 of the ‘917 patent are not entitled to the
`
`priority date of any application earlier than U.S. patent application no. 13/659,851
`
`filed on October 24, 2012 because none of the earlier applications contain written
`
`description and enablement support for all steps of the claims. A skilled artisan like
`
`myself would not have believed that the purported inventors of the ‘917 patent had
`
`possession of the claimed invention as of the filing of any of the earlier applications.
`
`26. For our purposes here, the primary predecessor of the ‘917 patent is
`
`U.S. patent no. 7,194,554. This was applied for on October 20, 2000, as application
`
`US09/693,060 (the ‘060 application); the patent was awarded in 2007. There is one
`
`patent and application in between the ‘554 and ‘917 patents: patent 7,689,716
`
`(granted in 2010) and its application US11/427,143, dated June 28, 2006. For the
`
`disclosures that are relevant here, the ‘554 and ‘716 patents are identical. Therefore,
`
`I will focus my discussion on the ‘060 application.
`
`27. Here are at least three primary recitations by the ‘917 patent that in my
`
`opinion are not disclosed by the predecessor applications:
`
`(a) The source-IP-address difference: the ‘917 patent states that the source
`
`12
`
`

`

`IP address is the key to be used in retrieving the profile record. The ‘554 patent
`
`application, along with other earlier documents, mentions using the source IP
`
`address, but not for this purpose.
`
`(b) The check-source-IP-address-then-destination-IP-address difference.
`
`The predecessor applications handle this differently than the ‘917 patent. A
`
`closely related way of describing this difference is that the '917 patent allows
`
`access to whitelisted sites without authentication of any form, while the
`
`predecessor applications at no point indicate that any form of access without
`
`authentication is permitted. I discuss these two forms of this difference
`
`together because the arguments are similar, but, architecturally, the second
`
`formulation may appear to be broader.
`
`(c) The list-of-destination-IP-addresses difference. The '917 patent states
`
`that access to certain sites is allowed, even if the source IP address is not found
`
`in a source profile, if “the destination IP address is included in a plurality of
`
`destination IP addresses.” The prior applications do not disclose this precise
`
`sequence.
`
`28.
`
`I will address each of the features individually.
`
`Recitation (a)
`
`29. First, as to recitation (a), the ‘060 application does not disclose
`
`limitations 1.c and 11.c of the ‘917 patent. Those limitations require comparing the
`
`13
`
`

`

`source “IP address” with profiles of authorized source devices that contain IP
`
`addresses and other information. Specifically, the ‘917 patent recites in Claim 1
`
`(and similarly in Claim 11):
`
`[1.c] comparing the source IP address with profiles of authorized source
`
`devices, each profile including an IP address, wherein if the source IP address
`
`is included in a profile of an authorized source device, the source device is
`
`granted access without further authorization, and
`
`30. The ‘554 and ‘716 patents, along with other earlier applications,
`
`mention using the source IP address, but not for this purpose. As an example, below
`
`is a paragraph appearing in both the ‘554 and ‘716 patents, and also in their
`
`immediate patent applications:
`
`In operation, a source computer requests (block 200) access to a
`network, destination, service, or the like. Upon receiving a packet
`transmitted to the AAA server 30, the AAA server 30 examines the
`packet to determine the identity of the source (block 210). The
`attributes transmitted via the packet are temporarily stored in the source
`profile database so that the data can be examined for use in determining
`authorization rights of the source. The attributes contained in the
`packet can include network information, source IP address, source port,
`link layer information, source MAC address, VLAN tag, circuit ID,
`destination IP address, destination port, protocol type, packet type, and
`the like. After this information is identified and stored, access
`requested from a source is matched against the authorization of that
`
`14
`
`

`

`source....
`‘060 application specification at 17:25-18:2. In my opinion, this passage does not
`
`disclose the very specific limitations of (1) comparing the source IP address with
`
`profiles of authorized source devices; (2) that each profile includes an IP address; or
`
`(3) that the source device is granted access without further authorization if the source
`
`IP address is included in a profile of an authorized source device, in claims 1 and 11.
`
`31. For example, the text here does not say, or even suggest, that the source-
`
`IP-address attribute may be used to identify the source. What is stated is that the
`
`“AAA server examines the packet to determine the identity of the source”, and then
`
`lists additional packet attributes that would further be stored in the profile that may
`
`affect authorization rights for the specific request at hand. There is no indication
`
`that these additional attributes play a role in identifying the source. The source IP
`
`address is listed along with the destination IP address, the destination port
`
`(presumably the destination TCP port), and the protocol type. These destination
`
`attributes would be of no use in identifying the source, suggesting that instead these
`
`additional attributes are stored to specify the traffic filtering being performed. For
`
`example, a given source IP address of 10.0.0.3 might be allowed HTTP access
`
`(destination port 80) to all IP addresses except those on a restricted list. This is, and
`
`was at the time of the ‘060 application, a typical traffic-filtering specification, one
`
`not meant to identify the sender. There is no reason to believe the source IP address
`
`15
`
`

`

`attribute, as described in this passage, was to be compared against by a source IP
`
`address in an incoming connection request to grant access.
`
`32. Notably, to further demonstrate the lack of disclosure, the specific
`
`embodiments disclosed in the ‘060 application for accessing source profiles involve
`
`using a MAC address, User ID, or VLAN ID. They do not mention comparing
`
`source IP addresses against IP addresses in profiles. No other portion of the ‘060
`
`application discloses the specific limitations of 1.c or 11.c either.
`
`33. At most the above passage (‘060 application specification at 17:25-
`
`18:2) discloses a general idea of determining authorization rights from attributes
`
`transmitted by a packet. It does not provide written description support of the
`
`specific means of implementing that idea in claims 1 and 11, which is authorizing
`
`access based specifically on comparing a source IP address against a source IP
`
`address in a profile.
`
`34. As a further example, claim 1 of the ‘554 patent states:
`
`identifying an attribute associated with the source based upon a packet
`transmitted from the source computer and received by the gateway
`device;
`accessing a source profile corresponding to the source and stored in a
`source profile database, wherein the source profile is accessed based
`upon the attribute, and wherein the source profile database is located
`external to the gateway device and in communication with the gateway
`device, and
`
`16
`
`

`

`determining the access rights of the source based upon the source
`profile, wherein access rights define the rights of the source to access
`the network.
`35. But the attributes proposed in the associated descriptions for identifying
`
`the source do not include the source IP address. Patent ‘554 claim 3, for example,
`
`suggests that the source might be identified by its location; claim 4 suggests that the
`
`source might be identified by its RADIUS login credentials, claim 5 suggests the use
`
`of LDAP login credentials, and claim 8 suggests the use of “a MAC address, User
`
`ID or VLAN ID associated with the source computer”. Nowhere, here or elsewhere,
`
`do any of the predecessor applications suggest the use of the source IP address. At
`
`most these claims and associated descriptions in the specification disclose a general
`
`idea of determining authorization rights from attributes transmitted by a packet.
`
`They do not provide written description support of the specific means of
`
`implementing that idea in claims 1 and 11, which is authorizing access based
`
`specifically on comparing a source IP address in an incoming connection request
`
`against a source IP address in a profile.
`
`Recitation (b)
`
`36. Second, in my opinion, neither the ‘060 application nor any other prior
`
`application discloses “if the source IP address is not included in a profile associated
`
`with an authorized device, determining whether the destination IP address is
`
`included in a plurality of destination IP addresses associated with the access
`
`17
`
`

`

`controller” in limitations 1.d and 11.d.
`
`37. The ‘917 patent claim 1 (and similarly claim 11) recites the following
`
`limitations:
`
`[1.c] comparing the source IP address with profiles of authorized source
`
`devices, each profile including an IP address, wherein if the source IP address
`
`is included in a profile of an authorized source device, the source device is
`
`granted access without further authorization, and
`
`[1.d] if the source IP address is not included in a profile associated with an
`
`authorized source device, then determining whether the destination IP address
`
`is included in a plurality of destination IP addresses associated with the access
`
`controller, wherein if the destination IP address is included in the plurality of
`
`destination IP addresses, the source device is granted access without further
`
`authorization, and
`
`38. Thus, claims 1 and 11 require comparing the source IP address against
`
`a profile, and if the address is not included in a profile, then determining whether the
`
`destination IP address is in a plurality of destination IP address in order to grant
`
`access without further authorization. These steps clearly indicate that access to a
`
`whitelisted destination will be granted even if no source profile corresponding to the
`
`source IP address can be found, and, as a consequence, that authentication of the
`
`18
`
`

`

`device in question is not complete. That is, the ‘917 patent discloses the idea that
`
`access to whitelisted destinations can be made without source authentication.
`
`39. None of the prior applications to which the ‘917 patent claims priority
`
`disclose this concept. For instance, the ‘554 patent and its predecessors consistently
`
`declare that source authentication is a necessary precondition for any network
`
`access; I demonstrate this by presenting a series of passages from the ‘554 patent.
`
`40. The closest the ‘554 and ‘716 patents come to suggesting some form of
`
`destination-address whitelisting are the following passages (both of which appear in
`
`both ‘554 and ‘716) [emphasis added]:
`
`According to the system and method of the present invention, each
`packet can be filtered through the selective AAA process, so that any
`or all sources can be authorized access to a particular destination
`based on the access rights associated with the respective sources.
`
`Alternatively, the AAA method according to the present invention
`allows some or all sources to connect directly to a specific site, such as
`credit card or billing servers for collecting billing information, which
`can collect payment or billing information so that the source profile
`can be updated and the source thereafter authorized access to
`networks.
`
`Crucially, however, neither passage can be read as disclosing access based solely on
`
`the presence of the destinatio