Source: http://www.google.com/patents/US7730527?dq=6,757,682
Timestamp: 2017-01-20 23:17:29
Document Index: 74474343

Matched Legal Cases: ['art 3', 'art 11', 'art 11', 'art 11', 'art 3', 'art 3', 'art 3', 'art 11', 'art 3', 'art 11', 'art 3', 'art 3', 'art 11', 'art 11', 'art 11', 'art 11', 'art 4', 'art 4']

Patent US7730527 - Procedure for controlling access to a source terminal network using a block ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsDisclosed is a method and system for controlling access of a source terminal to a network that includes, in particular, a firewall and an authentication portal that maintains the firewall during an access request originating from the source terminal and which permits access when periodically and subsequently...http://www.google.com/patents/US7730527?utm_source=gb-gplus-sharePatent US7730527 - Procedure for controlling access to a source terminal network using a block mode tunnel and computer programs for its implementationAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS7730527 B2Publication typeGrantApplication numberUS 11/139,034Publication dateJun 1, 2010Filing dateMay 27, 2005Priority dateJun 1, 2004Fee statusPaidAlso published asDE602004003568D1, DE602004003568T2, EP1605660A1, EP1605660B1, US20050273848Publication number11139034, 139034, US 7730527 B2, US 7730527B2, US-B2-7730527, US7730527 B2, US7730527B2InventorsOlivier Charles, Laurent Butti, Franck VeyssetOriginal AssigneeFrance TelecomExport CitationBiBTeX, EndNote, RefManPatent Citations (4), Non-Patent Citations (27), Referenced by (19), Classifications (20), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetProcedure for controlling access to a source terminal network using a block mode tunnel and computer programs for its implementation
US 7730527 B2Abstract
Disclosed is a method and system for controlling access of a source terminal to a network that includes, in particular, a firewall and an authentication portal that maintains the firewall during an access request originating from the source terminal and which permits access when periodically and subsequently provided with a valid authentication token. The source terminal can also communicate in tunnel mode with the destination terminal of the network via a block mode tunnel. Authentication tokens are periodically supplied on the OSI Layer 2 level so that the tokens continue to be provided during a block tunnel mode communication. A network operator can maintain access control using a captive portal paradigm even when a user chooses to use a block mode tunnel.
the firewall includes an authentication protocol module and a filtering module; said authentication protocol module provides said filtering module with a status indicating “pass” or “block” for the communication between the source terminal and the computer network, depending on whether the source terminal is authenticated or not,
For operational or security reasons, a network users can indeed be forced to establish a tunnel to a remote host, within which they encapsulate their traffic. Depending on the configuration and software programs used, this tunnel can be a block tunnel—that is, it can reject any communications that do not use this tunnel in both the reception and transmission directions.
In fact, this block mode is an additional security guarantee for the user. Indeed, if a user connects to his/her company's private network or “Intranet” via a tunnel, a hacker cannot attack this user's machine to use it as a relay to access the user's company Intranet.
Traditionally, the term “secret information” as it is used in this description will be understood as covering not only, in the literal sense, specific, distinct, and directly useable secret information, but also all the elements that allow deriving or regenerating such secret information in the literal sense.
the firewall includes an authentication protocol module and a filtering module; said authentication protocol module gives said filtering module the status “pass” or “block” for the communication between the source terminal and the computer network, depending on whether the source terminal is authenticated or not,
HMAC-MD5 (Keyed-Hashing for Message Authentication—Message Digest 5): Keyed-hashing function (see this term)—type cryptographic algorithm.
HMAC-SHA1 (Keyed-Hashing for Message Authentication—“Secure Hash Algorithm”): “Keyed-hashing” (see this term) type cryptographic algorithm.
HTTPS (Hypertext Transfer Protocol Secure): Transmission protocol originated for the “Netscape” browser and linked to a secure connection.
SSL (Secure Socket Layer): Secure network communication mode standard, used initially by the “Netscape” browser and then standardised.
TCP (Transport Control Protocol): Oriented online transport protocol that allows reliable exchange of any quantity of data between two equipment pieces (OSI Level 4—see this term) linked using one or several networks using IP (see this term.)
UDP (User Datagram Protocol): Transport protocol of independent data blocks or “packets” that travel over a network and contain all the data necessary for their routing.
[ARP] Address Resolution Protocol, “An Ethernet Address Resolution Protocol,” RFC 826, November 1982.
[HMAC-MD5] Krawczyk H., Bellare M., and Canettit R., “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, February 1997.
[IEEE-802.1x-2001] Institute of Electrical and Electronics Engineers, “Local and Metropolitan Area Networks: Port-based Network Access Control,” IEEE Standard 802.1x, September 2001.
[IEEE802.3-2002] IEEE Standard for Information Technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 3: Carrier Sense Multiple Access with Collisions Detection (CSMA/CD) Access Method and Physical Layer Specifications.
[IEEE-802.11-1977] Institute of Electrical and Electronic Engineers, “Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Network—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE Standard 802.11.1997.
[IEEE-802.11-1999] Institute of Electrical and Electronic Engineers, “Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Network—Specific Requirements—Part Iq: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE Standard 802.11.1999.
[IEEE-802.11i] Institute of Electrical and Electronic Engineers, “Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange between Systems—LAN/MAN Specific Requirements—Part II: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security,” IEEE Draft 802.11i (work in progress,) 2003.
[IPSec] Kent, S., and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, November 1998.
[OSI] International Organisation for Standardisation, “Open Systems Interconnection,” OSI 7498.
[TLS] Dierks, T. and Allen, C., “The TLS Protocol Version 1.0,” RFC 2246, January 1999.
The invention can find relevant use in radioelectric IEEE 802.1 ([IEEE-802.11-1977] and [IEEE-802.11-1999]) and “first generation” networks—that is, networks that do not implement new security functionalities at the [OSI] model Level 2 such as WPA or 802.11i., and in wired IEEE 802.3 ([IEEE802.3-2002]) and Ethernet networks that control access according to the “captive portal” paradigm.
ensuring that only the users that the operator has authorized can use the network—that is, prevent unauthorized users from using the network, and
maintaining the authentication relationship with the user—that is, ensuring that the authorized user that uses the network is indeed the same user that has been authenticated, in order to prevent unauthorized users from taking over the identity of an authorized user.
In the absence of security mechanisms that include level 2 access (linked to the data) of the [OSI] seven layer model or due to the costs related to the deployment of such mechanisms when they exist and due to their very low penetration rate in user equipment, the “captive portal” paradigm has been developed.
The “captive portal” paradigm such as it has been described until now is applicable, for example, to both radioelectric networks using IEEE802.11 technology and local wired networks using IEEE 802.3/Ethernet technology.
In the case of radioelectric networks using IEEE 802.11 technology, the security mechanisms foreseen originally in the [IEEE802.11-1997] and [IEEE802.11-1999] standard have quickly revealed significant problems that make their use both complicated and ineffective: it is the failure in 2000 and 2001 of security mechanisms known as “WEP.”
Two scenarios in which the “captive portal” paradigm is applied to radioelectric networks using IEEE-802.11 technology are:
in local radioelectric networks, called “Hot-Spots,” that use IEEE 802.11 technology and are deployed in areas with heavy traffic, for example, in hotel reception halls or airport waiting lounges, where the availability of an Internet connection represents high added value, and
Nevertheless, their penetration rate in user equipment parks is still low. This is why a company wishing to offer network access to its visitors, for example, in a meeting room, can be lead to use the “captive portal” paradigm.
either the securisation by token exchange is therefore purely and simply abandoned in the “captive portal” paradigm, in which case, access control to the network will only consist in filtering by IP address and/or MAC address, which presents critical vulnerabilities,
To do so, the session control—that is, normally the token exchange mechanism between the source terminal T_SOUR and the portal PORT, is moved to the OSI model Level 2 (L2 on FIGS. 2 and 3,) which allows separating it from all the block modes (M_BLQ on FIG. 3) that may be implemented by the user of the terminal T_SOUR on the higher layers of this model.
Specifically, the invention uses, on the one hand, an authentication protocol entity (also called “module”) PA1 and an application program APPLI1 implemented in the source terminal T_SOUR, and on the other, an authentication protocol entity (or “module”) PA2 and a filtering FILT function (also called “module”) implemented in the firewall PF, and lastly, an application program APPLI2 implemented in the captive portal PORT.
The authentication protocol entity PA2 implemented in the firewall PF must be able to interact (dialogue D3 in FIG. 2) with the application program APPLI2 that in turn distributes the secret information when the authentication of the terminal T_SOUR on the network is successful, and with the packet filtering FILT function (dialogue D3 in FIG. 3) to make it “pass” when the authentication checked by the PA1 and PA2 entities is successful and “block” when the authentication checked by the PA1 and PA2 entities is not successful.
Except in the case of a specific adaptation that will be discussed later, the terminal T_SOUR and the firewall PF must be in direct view on the OSI model Layer 2—that is, exempt of any intermediary router.
As long as this re-authentication is successful, the filtering module FILT of the firewall PF is told by the PA2 entity (dialogue D3 in FIG. 3) to remain in “pass” mode for the terminal T_SOUR data (dialogue D2 in FIG. 3;) this filtering module FILT is, otherwise, told to go into “block” mode.
Under these conditions, as long as the filtering FILT module remains in “pass” mode, the data stream in which the terminal T_SOUR is implicated can flow freely. If this terminal chooses to pass to “block” mode, for example, by invoking IPSec with specific types of software programs, then the re-authentication between the PA1 and PA2 entities can continue, and the access control at the firewall PF level thus remains valid.
This section presents a classical operating mode of a user connection to a network that supports “captive portal” technology. This technology is implemented in several commercial products, and is also available in an Open Source product called NoCatAuth (described, in particular, in the following site: http://nocat.net.)
This “captive portal” Open Source solution controls several Open Source filtering engines, such as “iptables,” “packetfilter,” or “IPFilter,” respectively described in the following sites:
4. The user sends a request to the Internet that is intercepted by the filtering engine (default rules) and redirected to the “captive portal.” The “captive portal” then presents the authentication banner to the user.
5. The user enters the authentication data (normally user name and password) that will be validated by the “captive portal.”
6. The “captive portal” interacts with the filtering engine in order to modify the default filtering rules for this user. At this time, the user can then communicate with the outside (normally the Internet) according to the new filtering rules transmitted by the filtering engine.
7. The “captive portal” pushes a periodic authentication window to the user. This window allows maintaining the session between the user and the captive portal using the notion of authentication tokens, herein referred to as “session maintenance window.”
The use of the session maintenance window, which is protected by SSL/TLS-based cryptographic mechanisms (https in FIG. 2,) allows obtaining secret information that is specific to the terminal T_SOUR and the captive portal PORT. The invention can therefore use these specific cryptographic mechanisms to ensure the confidentiality of the data transported on the new protocol specified at the OSI model Level 2, as well as the “anti-replay” function—that is, the function designed to block connection parasite attacks that consist in making it seem that a user is still active and in recovering the user's connection at a chosen time, for example, during a premature disconnection.
a. If the user suddenly disconnects from the network—that is, without using the disconnection button in the session maintenance window, the user closes the session maintenance window at the same time so that the application software PA1 will no longer be running. Consequently, the captive portal PORT will only continue to authorise the connection of the terminal T_SOUR during the pre-fixed residual session time. The access control system of the portal PORT will then consider that the user is no longer present on the network and no longer authorized to communicate via the firewall PF. The captive portal will therefore update the filtering rules of the firewall PF to prohibit connection of the terminal T_SOUR.
The protocol used by the session maintenance application software is located at Level 2 of the OSI layer, it does not cross Level 3 equipment—normally routers. It may therefore be necessary to also specify an encapsulation protocol and bi-directional frame Layer 2 transport protocol from the user and/or to the remote firewall.
This constraint is applicable within the framework of centralized architectures between several “hot spots” distributed in distinct geographical areas, which are all interconnected over a central site where the central captive portal will be located.
Nevertheless, another solution consists in deploying captive portals for each remote “hot spot” and in no longer performing access control on the central site.
The purpose of the analysis and decision module M_ANAL_DEC, in turn, is to check the contents of the authentication frames TR_AUTH received from the source terminal—that is, to generate a decision function g based on these frames TR_AUTH.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS7454622 *Dec 31, 2002Nov 18, 2008American Express Travel Related Services Company, Inc.Method and system for modular authentication and session managementUS20030035006 *Apr 16, 2002Feb 20, 2003Kodosky Jeffrey L.Graphical association of a device icon with a graphical programUS20030204744Apr 26, 2002Oct 30, 2003Robert-Claude MaltaisNetwork access controlUS20040053601 *Sep 9, 2003Mar 18, 2004Frank Ed H.Method and system for providing multiple encryption in a multi-band multi-protocol hybrid wired/wireless network* Cited by examinerNon-Patent CitationsReference1(IEEE Std 802.1X-2001), ] Institute of Electrical and Electronic Engineers, IEEE Standard for Local and Metropolitan Area Networks, "Port-Based Network Access Control", Sponsor: LAN/MAN Standards Committee of the IEEE, Approved Jun. 14, 2001 IEEE-SA Standards Board, Approved Oct. 25, 2001 American National Standards Institute, pp. 1-142.2[1EEE-802.11-1997] Institute of Electrical and Electronic Engineers, "Information Technology-Telecommunications and Information Exchange between Systems-Local and Metropolitan Area Network-Specific Requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," IEEE Standard 802.11,1997, pp. 1-459.3[1EEE-802.11-1997] Institute of Electrical and Electronic Engineers, "Information Technology—Telecommunications and Information Exchange between Systems—Local and Metropolitan Area Network-Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications," IEEE Standard 802.11,1997, pp. 1-459.4[ARP] Address Resolution Protocol, "An Ethernet Address Resolution Protocol," RFC 826, Nov. 1982, pp. 1-8.5[HMAC-MD5] Krawcyzk, H., Bellare M., and Canettit, R., "HMAC: Keyed-Hashing for Message Authentification," RFC 2104, Feb. 1997, pp. 1-11.6[IPSec] Kent, S., and R. Atkinson, "Security Architecture for the Internet Protocol," RFC 2401, Nov. 1998, pp. 1-63.7[TLS] Dierks, T. and Allen, C., "The TLS Protocol Version 1.0," RFC 2246, Jan. 1999., pp. 1-76.8802.3® IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements, Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications Published by The Institute of Electrical and Electronics Engineers, Inc.,3 Park Avenue, New York, NY 10016-5997, USA, Mar. 8, 2002, IEEE Computer Society, Sponsored by the LAN/MAN Standards Committee. pp. 1-578.9802.3® IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements, Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications Published by The Institute of Electrical and Electronics Engineers, Inc.,3 Park Avenue, New York, NY 10016-5997, USA, Mar. 8, 2002, IEEE Computer Society, Sponsored by the LAN/MAN Standards Committee. pp. 1-578.10802.3® IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications Section Three: This section includes Clauses 34 through 43 and Annexes 36A through 43C, pp. 1-379. Telecommunications and information exchange between systems- Local and Metropolitan area networks-Specific requirements-Part 11: Wireless Lan Medium Access Control (Mac) and Physical Layer (Phy) Specifications - Sponsor Lan Man Standards Committee of the IEEE Computer Society - Reaffirmed 6/12/03 IEEE-Sa Standards Board, pp. 1-528.Multiple Access with Collision Detection.11802.3® IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications Section Three: This section includes Clauses 34 through 43 and Annexes 36A through 43C, pp. 1-379. Telecommunications and information exchange between systems— Local and Metropolitan area networks—Specific requirements—Part 11: Wireless Lan Medium Access Control (Mac) and Physical Layer (Phy) Specifications - Sponsor Lan Man Standards Committee of the IEEE Computer Society - Reaffirmed 6/12/03 IEEE-Sa Standards Board, pp. 1-528.Multiple Access with Collision Detection.12802.3® IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications Section Two: This section includes Clauses 21 through 33 and Annexes 22A through 32A, pp. 1-582.13802.3® IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements—Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications Section Two: This section includes Clauses 21 through 33 and Annexes 22A through 32A, pp. 1-582.14ANSI/IEEE Std 802.11, 1999 Edition (R2003)Information technology-Telecommunications and information exchange between systems-Local and Metropolitan area networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications-Sponsor LAN MAN Standards Committee of the IEEE Computer Society-Reaffirmed Jun. 12, 2003 IEEE-SA Standards Board, pp. 1-528.15ANSI/IEEE Std 802.11, 1999 Edition (R2003)Information technology—Telecommunications and information exchange between systems—Local and Metropolitan area networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications—Sponsor LAN MAN Standards Committee of the IEEE Computer Society—Reaffirmed Jun. 12, 2003 IEEE-SA Standards Board, pp. 1-528.16EEE Std 802.11i(TM)-2004 [Amendment to IEEE Std 802.11(TM), 1999 Edition (Reaff 2003) as amended by IEEE Stds 802.11a(TM)-1999, 802.11b(TM)-1999, 802.11b(TM)-1999/Cor 1-2001, 802.11d(TM)-2001, 802.11g(TM)-2003, and 802.11h(TM)-2003]802.11iTM IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements-3 Park Avenue, New York, NY 10016-5997, USA-IEEE Computer Society Sponsored by theLAN/MAN Standards Commitee-Jul. 23, 2004 Print: SH95248 PDF: SS95248, pp. 1-190.17EEE Std 802.11i™-2004 [Amendment to IEEE Std 802.11™, 1999 Edition (Reaff 2003) as amended by IEEE Stds 802.11a™-1999, 802.11b™-1999, 802.11b™-1999/Cor 1-2001, 802.11d™-2001, 802.11g™-2003, and 802.11h™-2003]802.11iTM IEEE Standard for Information technology—Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements—3 Park Avenue, New York, NY 10016-5997, USA—IEEE Computer Society Sponsored by theLAN/MAN Standards Commitee—Jul. 23, 2004 Print: SH95248 PDF: SS95248, pp. 1-190.18Haidong Xia et al., "Detecting and Blocking Unauthorized Access in Wi-Fi Networks"; Networking 2004, Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications. Third International IFIP-TC6 Networking Conference Proceedings. (Lecture notes in Comput. Sci., May 2004), pp. 795-806.19International Standard ISO/IEC 7498-3 Second edition 1997-04-I 5-Information technology-Open Systems Interconnection-Basic Reference Model: Naming and addressing- Reference No. ISO/I EC 7498-3 : 1997(E) pp. 1-32.20International Standard ISO/IEC 7498-3 Second edition 1997-04-I 5—Information technology—Open Systems Interconnection—Basic Reference Model: Naming and addressing— Reference No. ISO/I EC 7498-3 : 1997(E) pp. 1-32.21International Standard ISO/IEC 7498-I-Second edition 1994-I I-I 5-Corrected and reprinted 1996-06-I 5 Information technology- Open Systems Interconnection-Basic Reference Model; The Basic Model-Reference No. ISO/I EC 7498-I : 1994(E), pp. 1-68.22International Standard ISO/IEC 7498-I—Second edition 1994-I I-I 5—Corrected and reprinted 1996-06-I 5 Information technology— Open Systems Interconnection—Basic Reference Model; The Basic Model—Reference No. ISO/I EC 7498-I : 1994(E), pp. 1-68.23International Standard ISOIEC-7498-4 First edition-1989-II-15-Information processing systems -Open Systems Interconnection- Basic Reference Model-Part 4 : Management framework-Reference No. ISO/I EC 7498-4 : 1989(E), pp. 1-16.24International Standard ISOIEC—7498-4 First edition—1989-II-15—Information processing systems —Open Systems Interconnection— Basic Reference Model—Part 4 : Management framework—Reference No. ISO/I EC 7498-4 : 1989(E), pp. 1-16.25Vaughn-Nichols S.J., "Securing your Wi-Fi Connection on the Road", Wi-Fi Planet, "Online", Nov. 7, 2003, www.wi-fiplanet.com/tutorials/article.php/3106011.26Wi-Fi Protected Access (WPA) Abstract-This document captures those clauses of the IEEE 802.11i Draft 3.0 that comprise an enhanced security implementation for 802.11i known as Wi-Fi Protected Access. Implementation notes are also provided. Line number references to the 802.11i Draft 3.0 standard are used throughout this document. In order to ensure consistent referencing, this document should be used in conjunction with the Portable Document Format (PDF) version of the IEEE 802.11i Draft 3.0 standard, pp. 1-32.27Wi-Fi Protected Access (WPA) Abstract—This document captures those clauses of the IEEE 802.11i Draft 3.0 that comprise an enhanced security implementation for 802.11i known as Wi-Fi Protected Access. Implementation notes are also provided. Line number references to the 802.11i Draft 3.0 standard are used throughout this document. In order to ensure consistent referencing, this document should be used in conjunction with the Portable Document Format (PDF) version of the IEEE 802.11i Draft 3.0 standard, pp. 1-32.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8108362Feb 8, 2007Jan 31, 2012Microsoft CorporationSecure content descriptionsUS8272039 *May 2, 2008Sep 18, 2012International Business Machines CorporationPass-through hijack avoidance technique for cascaded authenticationUS8527757 *Jun 23, 2008Sep 3, 2013Gemalto SaMethod of preventing web browser extensions from hijacking user informationUS8650589 *Jan 8, 2007Feb 11, 2014At&T Intellectual Property I, LpSystem for provisioning media servicesUS8688841 *Jun 5, 2008Apr 1, 2014Modena Enterprises, LlcSystem and method for content rights based on existence of a voice sessionUS8767526Dec 27, 2010Jul 1, 2014Juniper Networks, Inc.Supplicant framework to handle clientless devices on a dot1x platformUS9088891Aug 13, 2012Jul 21, 2015Wells Fargo Bank, N.A.Wireless multi-factor authentication with captive portalsUS9124943Jan 6, 2014Sep 1, 2015At&T Intellectual Property I, LpSystem for provisioning media servicesUS9208239Jun 29, 2011Dec 8, 2015Eloy Technology, LlcMethod and system for aggregating music in the cloudUS9407967Jul 27, 2015Aug 2, 2016At&T Intellectual Property I, LpSystem for provisioning media servicesUS20080168524 *Jan 8, 2007Jul 10, 2008At&T Knowledge Ventures, LpSystem for provisioning media servicesUS20080320300 *Dec 4, 2006Dec 25, 2008Microsoft CorporationAuthorisation and AuthenticationUS20090138486 *Feb 8, 2007May 28, 2009Microsoft CorporationSecure Content DescriptionsUS20090276838 *May 2, 2008Nov 5, 2009International Business Machines CorporationPass-through hijack avoidance technique for cascaded authenticationUS20090307361 *Jun 5, 2008Dec 10, 2009Kota Enterprises, LlcSystem and method for content rights based on existence of a voice sessionUS20100015975 *Jul 17, 2008Jan 21, 2010Kota Enterprises, LlcProfile service for sharing rights-enabled mobile profilesUS20100015976 *Jul 17, 2008Jan 21, 2010Domingo Enterprises, LlcSystem and method for sharing rights-enabled mobile profilesUS20100235637 *Jun 23, 2008Sep 16, 2010Gemalto, SaMethod of Preventing Web Browser Extensions from Hijacking User InformationUS20140359733 *Dec 21, 2011Dec 4, 2014Warwick Valley NetworksAuthentication System and Method for Authenticating IP Communications Clients at a Central Device* Cited by examinerClassifications U.S. Classification726/11International ClassificationH04L9/32, H04L12/56, H04L12/28, G06F12/14, H04L9/00, H04L29/06, G06F11/30, G06F9/00Cooperative ClassificationH04L63/0807, H04L63/08, H04L63/0272, H04W74/00, H04W12/08, H04W12/06, H04W84/12, H04L67/02European ClassificationH04L63/08, H04L63/02C, H04L63/08ALegal EventsDateCodeEventDescriptionAug 16, 2005ASAssignmentOwner name: FRANCE TELECOM, FRANCEFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHARLES, OLIVIER;BUTTI, LAURENT;VEYSSET, FRANCK;REEL/FRAME:016894/0113;SIGNING DATES FROM 20050802 TO 20050808Owner name: FRANCE TELECOM,FRANCEFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHARLES, OLIVIER;BUTTI, LAURENT;VEYSSET, FRANCK;SIGNING DATES FROM 20050802 TO 20050808;REEL/FRAME:016894/0113Nov 27, 2013FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services