System and method for delivering a challenge response in an authentication protocol
Summary by NHIP
Active Script Authentication
The system authenticates users by delivering an active script component through a parameter of an access-challenge message. This script configures a user device to modify a static authentication interface when the network protocol is RADIUS and the reply-message field carries the executable code.
Claim Score by NHIP
Abstract
A system and method for authenticating a user that includes receiving an access-request of a network protocol at a challenge-response server; determining if an access-challenge message is required; delivering an active script component through a parameter of an access-challenge message of the network protocol when an access-challenge is required; receiving a challenge-response of a user; validating the challenge-response; and selectively sending an access-accept response for a valid challenge-response and sending an access-denied response for an invalid challenge-response.

Term
6 yearsleft in the term
Expires 8 October 2032, including 38 days of term adjustment.
- Priority and filed
- Granted
- Today
- Expires
14 claims: 2 independent, 12 dependent
- 1Broadest claimClaim Score 60, broad(NHIP)A method for authenticating a user comprising:receiving an access-request of a network protocol at a challenge-response server, wherein the network protocol is a client/server protocol running in the application layer and using a user datagram protocol as transport;determining if an access-challenge message is required;configuring an active script component to modify an existing static authentication interface of a user device;delivering the active script component through a parameter of an access-challenge message of the network protocol when an access-challenge is required;receiving a challenge-response of a user;validating the challenge-response;and selectively sending an access-accept response for a valid challenge-response and sending an access-denied response for an invalid challenge-response.
- 10A method for authenticating network access comprising:receiving an access-request of a network protocol at a challenge response server, wherein the network protocol is a client server protocol running in the application layer and using the User Datagram Protocol (UDP) as transport;processing the access-request to verify credentials;the challenge response server selectively replying with an access-accepted message for verified credentials, an access-denied message if credentials are denied, and an access-challenge message if the credentials require a challenge to verify the credentials;configuring an active script component to transform an authentication interface of a user device;wherein replying with an access-challenge message includes embedding the active script component in a parameter of the access-challenge;receiving a challenge-response of a user;validating the challenge-response;and selectively sending an access-accept response for a valid challenge-response and sending an access-denied response for an invalid challenge-response.
Independent claims2
23 paragraphs in 5 sections, as filed
CROSS-REFERENCE TO RELATED APPLICATIONS
p-0002This application claims the benefit of U.S. Provisional Application No. 61/529,375, filed 31 Aug. 2011, titled “SYSTEM AND METHOD OF DELIVERING ACTIVE SCRIPTING VIA CHALLENGE-RESPONSE PROTOCOLS”, which is incorporated in its entirety by this reference.
TECHNICAL FIELD
p-0003This invention relates generally to the authentication field, and more specifically to a new and useful system and method for delivering a challenge response in an authentication protocol in the authentication field.
BACKGROUND
p-0004Protocols such as RADIUS (Remote Authentication Dial In User Service) are commonly used for Authentication, Authorization, and Accounting management. Such protocols can be used to authenticate users or devices, authorize those users or devices for certain services, and account for the usage of those services. For example, to authenticate a user, a RADIUS client will send an Access-Request message to a RADIUS server containing proof of the user's identity (most commonly a username and password) and optionally information about the service to be accessed. The RADIUS server can reply to this Access-Request message with three types of responses: (1) if the RADIUS server deems that the user has not authenticated properly (eg. incorrect username or password) or is unauthorized to access the requested service, the RADIUS server can reply with an Access-Reject message; (2) if the RADIUS server deems the user has authenticated properly and is authorized, the RADIUS server can respond with an Access-Accept message; and (3) if the RADIUS server requires additional information from the user, it can reply with an Access-Challenge message. The last response type, the Access-Challenge message, is most commonly used to request additional information to authenticate the requesting user. Such information can include a password, PIN, token code, or other identifier attesting to the identity of the user. The RADIUS client will retrieve the requested information from the user and then relay it back to the RADIUS server to complete authentication. The challenge-response mechanism provided by the RADIUS Access-Challenge message is commonly used to implement two-factor authentication. In practice, a user attempting to log in to a service (eg. a VPN, website login, etc) will provide his primary credentials (eg. commonly a username and password), the RADIUS client will send those credentials in an Access-Request, the RADIUS server will validate the credentials and send an Access-Challenge back to the RADIUS client, the user will be challenged to enter a secondary factor of authentication (eg. commonly a one-time password (OTP) generated by a hardware or software token) and the response to that challenge will be sent to the RADIUS server for validation. Commonly, the challenge presented to the user in the form of a single instructional message (defined by the Reply-Message attribute in the Access-Challenge message) and an input box to collect the challenge response from the user. Unfortunately, this interface is often statically defined by the service (eg. a single input field with an optional textual caption) and does not provide a rich or interactive mechanism for the user to respond to the challenge. Thus, there is a need in the authentication field to create a new and useful system and method for delivering a challenge response in an authentication protocol. This invention provides such a new and useful system and method.
BRIEF DESCRIPTION OF THE FIGURES
p-0005<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic representation of a system of a first preferred embodiment of the invention;
p-0006<figref idrefs="DRAWINGS">FIG. 2</figref> is a schematic representation of a method of a first preferred embodiment of the invention; and
p-0007<figref idrefs="DRAWINGS">FIG. 3</figref> is a schematic representation of a variation of a method embedding an active script identifier.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
p-0008The following description of the preferred embodiments of the invention is not intended to limit the invention to these preferred embodiments, but rather to enable any person skilled in the art to make and use this invention.
h-0006A System for Delivering a Challenge Response
p-0009As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, a system for delivering a challenge response of a preferred embodiment includes at least a challenge-response server (CRS) <b>110</b> and an active script component <b>120</b>. The system functions to modify a client authentication interface of a network protocol. The system can preferably provide an interactive method of collecting the response of a user to a protocol-defined challenge (eg. RADIUS Access-Challenge) by delivering active scripting content (eg. Javascript) which is executed and rendered within the user's web browser when the challenge is received, instead of using the simple, static interface defined by the service (eg. SSL VPN, website login, etc) for collecting the response from the user. The invention enables a server to initiate a challenge crafted in such a way that enables the execution of active scripting component upon delivery to a web browser of a user. Upon execution, the active scripting component can modify the web page in which it is embedded to create a rich interactive interface to collect a response to the challenge. The system is preferably used to provide a richer and improved user experience when collecting a challenge response. The system may additionally include a challenge-response client (CRC) <b>130</b> and/or a user device <b>140</b>. The system is preferably used alongside or integrated with a networking protocol that provides authentication, authorization and/or accounting management for device usage of a network service. The networking protocol is preferably a client/server protocol that runs in the application layer using the User Datagram Protocol (UDP) as transport, such as Remote Authentication Dial In User Service (RADIUS), but the may be used with any suitable protocol. The networking protocol may be used to manage access to the internet or internal networks, wireless networks, e-mail services. RADIUS servers are ubiquitous for providing authentication functionality, and the system preferably enables new interaction capabilities leveraging devices designed for integration with a RADIUS server.
p-0010The challenge-response server (CRS) <b>110</b> of a preferred embodiment functions to receive, process, and respond to access requests of networking protocol. The CRS <b>110</b> can be any software or hardware system that is involved in the authentication or authorization of a user or device. The CRS <b>110</b> preferably includes an input to receive an access-request message, challenge-response message, and any suitable messages. The CRS <b>110</b> can additionally preferably send access-accept messages, access-reject messages, access-challenge messages, challenge-accept messages, and/or any other suitable messages. The CRS <b>110</b> preferably includes a credential processing module to verify access request messages and credentials using any suitable authentication scheme. In response to a login or access-request from the challenge-response client (CRC) <b>130</b>, the CRS <b>110</b> may deem that additional information is required from the User in order to authenticate or authorize the User. If the CRS <b>110</b> deems that a challenge is required, it may construct and deliver a challenge with an embedded active scripting component in its access-challenge message to the CRC <b>130</b>. Typically, the CRS <b>110</b> is a RADIUS server as described above but the CRS <b>110</b> may alternatively be any suitable network authentication, authorization, or accounting protocol server.
p-0011The active scripting component <b>120</b> of a preferred embodiment functions to trigger execution of an interface on a user device <b>140</b>. The active scripting component <b>120</b> is preferably included in a challenge response generated and communicated but the CRS <b>110</b>. An active scripting component <b>120</b> may additionally or alternatively be included in any response from the CRS <b>110</b>. The active scripting component <b>120</b> in one preferred embodiment is an embeddable script. The embeddable script is preferably Javascript that is configured to manipulate the Document Object Model (DOM) of a browser of a user, but the embeddable script may be any suitable executable code component. The embeddable script is preferably a static script that may be embedded in any challenge request. Alternatively the embeddable script may be a dynamically generated script. The CRS or other suitable device can preferably generate a customized embeddable script using parameters from the access-request such as username, location, or any suitable parameter. The active scripting component <b>120</b> of a second preferred embodiment is a script identifier that functions to trigger a pre-delivered script on a user device <b>140</b>. The script identifier is preferably a unique code or identifier that is automatically detected by a script pre-delivered script, and the pre-delivered script preferably generates an interface to capture a user response to an access challenge message.
p-0012The system may additionally include a challenge-response client <b>130</b>, which functions to prompt a user for authentication and communicating with the CRS <b>110</b> to validate credentials. The CRC <b>130</b> preferably hosts and/or protects a network service to which a user device is attempting to connect. The CRC <b>130</b> preferably relays the access protocol related communication between the CRS <b>110</b> and a user device <b>140</b>. If the CRS <b>110</b> deems that a challenge is necessary, the CRC <b>130</b> will receive an access-challenge message, deliver the access-challenge to a user device <b>140</b>, collect a user response to the access-challenge, and transmit the challenge-response back to the CRS <b>110</b>. Typically, the CRC <b>130</b> contains the functionality of a RADIUS client to interact with the RADIUS Server (CRS) as well as a web server to interact over an HTTP/HTTPS protocol with the user device <b>140</b>.
p-0013The system may additionally include a user device <b>140</b>, which functions to initiate authentication, authorization, or accounting management request and to enable capture of input from a User. The user device is preferably a computing device such as a computer, mobile phone, tablet or any suitable computing device. The user device may additionally include a browser application through which a user (eg. person, device, etc) attempts to authenticate to a desired service hosted or protected by the CRC <b>130</b>. The user device <b>140</b> preferably communicates a primary form of authentication (eg. a username and password) to the CRC <b>130</b>, which is subsequently validated by the CRS <b>110</b>. If the CRS <b>110</b> then deems that a challenge is necessary to collect additional information from the user device, the CRS <b>110</b> can issue a challenge with the active scripting component <b>120</b>, which is delivered to the CRC <b>130</b>, which may be passed down to the web browser of the user device <b>140</b>. Upon delivery and execution of the active scripting component <b>120</b>, a User would interact with the challenge interface constructed by the active scripting component and submit a response back to the CRC <b>130</b>, to be validated by the CRS <b>110</b>. Typically, a user device <b>140</b> is accessing the desired service via a web browser capable of executing and rendering the active scripting component that may be delivered by an access-challenge message sent from the CRS/CRC.
h-0007A Method for Delivering a Challenge Response
p-0014As shown in <figref idrefs="DRAWINGS">FIG. 2</figref>, a method of a preferred embodiment may include receiving an access-request of a network protocol at a challenge-response server S<b>210</b>, determining if an access-challenge is required S<b>220</b>; delivering an active script component through a parameter of an access-challenge of the network protocol S<b>230</b>; receiving a challenge-response of a user device S<b>240</b>; validating the challenge-response S<b>250</b>; and selectively sending a reply according to the validity of the challenge-response S<b>260</b>. The method functions to modify a client authentication interface that relies on a network authentication, authorization, and/or access management protocol. The method preferably enables an improved, alternative, and/or otherwise altered authentication process for a user device. The method is preferably employed to generate an interface that captures user input during an access challenge portion of authentication, but the method may alternatively be employed to generate an interface at any suitable portion of authentication. The method is preferably implemented by a system substantially similar to the one described above. The method is preferably used on systems integrated with a networking protocol that provides authentication, authorization and/or accounting management for device usage of a network service. The networking protocol is preferably a client/server protocol that runs in the application layer using the User Datagram Protocol (UDP) as transport such as a Remote authentication Dial In User Service (RADIUS), but may alternatively be any suitable networking protocol. The networking protocol may be used to manage access to the internet or internal networks, wireless networks, e-mail services. RADIUS servers are ubiquitous for providing authentication functionality, and the system preferably enables new interaction capabilities leveraging devices designed for integration with a RADIUS server.
p-0015Step S<b>210</b>, which includes receiving an access-request of a network protocol at a challenge-response server (CRS), functions to receive a communication indicating that a user device is attempting to authenticate. The access-request is preferably relayed to the CRS by a challenge-response client (CRC). The CRC preferably initially received an access-request initiated by a user device. In an alternative embodiment, the method may additionally include communicating access credentials at a user device to a CRC and at the CRC relaying an access-request with the access credentials to the CRS. For example a user may attempt to log in to a SSL VPN server using a web browser. The user enters their primary credentials, typically a username and password, and transmits them to the SSL VPN server (i.e., CRC). The SSL VPN server utilizes a RADIUS client to verify the credentials received from the User by sending them in a RADIUS access-request to the RADIUS server (i.e., CRS).
p-0016Step S<b>220</b>, which includes determining if an access-challenge is required, functions to determine the response of the CRS and optionally generate an access-challenge with an active script component. Determining if an access challenge is required preferably includes processing the access-request to verify credentials and the CRS selectively replying with an access-accepted message for accepted credentials, an access-denied message if credentials are denied, or an access-challenge message if the CRS determines to challenge the credentials. Replying with an access-challenge message is preferably selected when the CRS requires additional information or action by a user to confirm the authentication, authorization, or account management request. In an exemplary embodiment, the method may have a RADIUS server (i.e., the CRS) verifying credentials of a user as relayed by the RADIUS client (i.e., the CRC). If the RADIUS server deems it is necessary to challenge the user, such as for a secondary authentication factor, the RADIUS server transmits a RADIUS Access-Challenge back to the RADIUS client as described in Step S<b>230</b>.
p-0017Step S<b>230</b>, which includes delivering an active script component through a parameter of an access-challenge of the network protocol, functions to include a component to enable a customized interface on a user device. The active script component is preferably embeddable Javascript, but may alternatively be any suitable embeddable script. The embeddable script is preferably configured to construct an arbitrary interface on a user device. More preferably, the embeddable script updates the document object model (DOM) of a browser. Delivering the active script component preferably includes inserting the active script component as string input in the reply-message parameter of the access challenge message. In the example where the method is employed with a RADIUS server, the reply-message is a text field that is used to hold the active script component. A RADIUS server may embed HTML script tags that contain Javascript code, that are configured to cause a web browser to execute the Javascript when it is delivered and rendered in the web browser. The rendered interface preferably facilitates completing the authentication step of the access-challenge. For example, the active scripting delivered to a web browser may construct an interface to a third-party service for authentication purposes, challenge the user to authenticate himself to that service, and then the service may generate and submit the value or identifier attesting to the identity of the User back to the CRC through the browser with assistance of the active scripting. Preferably the active scripting component is a static script file that may be used for a plurality of user devices. Delivering an active script component may alternatively include dynamically generating the active script component. A dynamically generated active script component may be dynamically generated according to the credential parameters, time of day, location information, or any suitable parameter. In another embodiment the active scripting component is a script identifier as shown in <figref idrefs="DRAWINGS">FIG. 3</figref>. The script identifier is preferably delivered in the reply message parameter similar to the executable code variation described above. A user device active script is preferably preprogrammed to recognize the script identifier upon delivery to a user device. The user device script is preferably Javascript that may be included in a webpage. The method may additionally include delivering the user device script. When this unique identifier is delivered to a user device (e.g., a web browser) in the reply-message, the user device active script detects this unique identifier and triggers the creation of the interface to collect user input in response to the challenge.
p-0018Step S<b>240</b> and Step S<b>250</b>, which include receiving a challenge-response of a user device and validating the challenge-response, functions to determine if a response of a user satisfies the challenge. The challenge-response is preferably received at a CRS. Receiving a challenge-response of a user device may additionally include receiving a challenge-response at a CRC and communicating the challenge-response from the CRC to the CRS. The challenge-response preferably includes an input set according to the user response to the access-challenge message. The input may be directly set by the user (e.g., the challenge-response includes an answer supplied by the user) but the input may alternatively be generated in response to a response of the user (e.g., a signature indicating a user completed a challenge or created from a third party authentication service). The input preferably signifies the value of a single response but may additionally include values for a plurality of challenges. For example, one embodiment may generate several challenge questions and all the responses may be formatted in to a single input. Validating a challenge-response may be performed through any suitable technique. In one exemplary embodiment, after user interaction with the interface generated by the active scripting component, a response to a challenge by a user is transmitted to a SSL VPN (i.e., a CRC). The SSL VPN then transmits an access-request message to a RADIUS server (i.e., a CRS) through a RADIUS client component of the SSL VPN. The access-request preferably includes a challenge-response value relayed from the user.
p-0019Step S<b>260</b>, which includes selectively sending a reply according to the validity of the challenge-response, functions to determine if the challenge was successfully completed. Selective sending a reply according to the validity of the challenge response preferably includes sending access-accept reply for a valid challenge response and sending an access denied reply for an invalid challenge-response. Additionally the CRS may send a second access-challenge. For example, if a RADIUS server deems the challenge-response valid, it returns an access-accept response that is sent back to the RADIUS client. Upon receiving an access-accept response the SSL VPN preferably sets any suitable session state to indicate the user device has logged in successfully and optionally returning a success message to the user device.
p-0020A method of a preferred embodiment may additionally include at a user device rendering of the reply-message parameter of the access-challenge on the user device. Preferably, the reply-message is rendered in the context of a web browser, thereby executing the embedded active script payload (e.g., Javascript). The active script payload is then preferably free to manipulate the DOM structure of the web browser and construct arbitrary HTML elements and interactions with the User to collect their response to the challenge. For example, instead of simply displaying a static HTML input field and optional message derived from the reply-message, the Javascript rendered in the user's browser can create additional form input fields, pull in external resources, display arbitrary text, images, or media to the end user, etc. The method may additionally include receiving and processing secondary authentication communication from a rendered challenge interface. A secondary authentication system may cooperatively facilitate the receiving and processing of a secondary authentication communication. Any suitable form of secondary authentication may be performed. In one such exemplary application, this method can be used to take an existing static RADIUS challenge interface (e.g., hardcoded by the SSL VPN) which only displays a single HTML input box that the User inputs a one-time password into for secondary authentication, and modify that interface dynamically via the embedded Javascript payload into a rich interface for secondary authentication that allows the User to select between a number of secondary authentication factors and receive dynamic content and real-time feedback from the secondary authentication service.
p-0021An alternative embodiment preferably implements the above methods in a computer-readable medium storing computer-readable instructions. The instructions are preferably executed by computer-executable components preferably integrated with a challenge response server. The computer-readable medium may be stored on any suitable computer readable media such as RAMs, ROMs, flash memory, EEPROMs, optical devices (CD or DVD), hard drives, floppy drives, or any suitable device. The computer-executable component is preferably a processor but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device.
p-0022As a person skilled in the art will recognize from the previous detailed description and from the figures and claims, modifications and changes can be made to the preferred embodiments of the invention without departing from the scope of this invention defined in the following claims.
Contents5
4 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US2003126472A1 | Cites | United States of America | Applicant |
| US2005268107A1 | Cites | United States of America | Applicant |
| US2006130139A1 | Cites | United States of America | Applicant |
| US2007199060A1 | Cites | United States of America | Applicant |
| US2009187986A1 | Cites | United States of America | Search report |
| US2010042954A1 | Cites | United States of America | Applicant |
| US2010114740A1 | Cites | United States of America | Applicant |
| US2010115578A1 | Cites | United States of America | Applicant |
| US2010121767A1 | Cites | United States of America | Applicant |
| US2010216425A1 | Cites | United States of America | Applicant |
| US2011138469A1 | Cites | United States of America | Applicant |
| US2011197267A1 | Cites | United States of America | Applicant |
| US2011219449A1 | Cites | United States of America | Applicant |
| US2012090028A1 | Cites | United States of America | Search report |
| US2012198050A1 | Cites | United States of America | Applicant |
| US2012216239A1 | Cites | United States of America | Applicant |
| US2013042002A1 | Cites | United States of America | Applicant |
| US2013110676A1 | Cites | United States of America | Applicant |
| US2013125226A1 | Cites | United States of America | Applicant |
| US2013174246A1 | Cites | United States of America | Applicant |
| US2014047546A1 | Cites | United States of America | Applicant |
| US6823359B1 | Cites | United States of America | Applicant |
| US6934858B2 | Cites | United States of America | Applicant |
| US7447784B2 | Cites | United States of America | Applicant |
| US7463637B2 | Cites | United States of America | Applicant |
| US7574733B2 | Cites | United States of America | Applicant |
| US7982595B2 | Cites | United States of America | Applicant |
| US8136148B1 | Cites | United States of America | Applicant |
| US8161527B2 | Cites | United States of America | Applicant |
| US8332627B1 | Cites | United States of America | Applicant |
| US8402526B2 | Cites | United States of America | Applicant |
| US8495720B2 | Cites | United States of America | Applicant |
| US8499339B2 | Cites | United States of America | Applicant |
2 members in 1 office
Members2
| Document | Office | Kind | |
|---|---|---|---|
| US2013212387A1 | United States of America | A1 | |
| US8892885B2This record | United States of America | B2 |
76 transactions on the USPTO file
Allowed without a rejection on record.
- Non-final rejections
- 0
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Payment of Maintenance Fee, 12th Year, Large EntityM1553 | M1553 | |
| Payment of Maintenance Fee, 8th Year, Large EntityM1552 | M1552 | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Payment of Maintenance Fee, 4th Year, Large EntityM1551 | M1551 | |
| Entity Status Set To Undiscounted (Initial Default Setting or Status Change)BIG. | BIG. | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Interview Summary - Examiner Initiated - TelephonicEXET | EXET | |
| Interview Summary - Examiner InitiatedEXIE | EXIE | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail First Action Interview Office ActionMFAIA | MFAIA | |
| Pilot-First Action Interview Office Action (FAI Step 2)FAIA | FAIA | |
| Interview Summary - Applicant Initiated - TelephonicEXAT | EXAT | |
| Interview Summary- Applicant InitiatedEXIA | EXIA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response to PICO-RequestRPICO | RPICO | |
| Letter Requesting Interview with ExaminerM865 | M865 | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Mail Pre-Interview CommunicationMPICO | MPICO | |
| Pre-Interview Communication (FAI Step 1)PICO | PICO | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Email NotificationEML_NTR | EML_NTR | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Email NotificationEML_NTR | EML_NTR | |
| Filing Receipt - UpdatedFLRCPT.U | FLRCPT.U | |
| Sent to Classification ContractorPGPC | PGPC | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Additional Application Filing FeesADDFLFEE | ADDFLFEE | |
| A statement by one or more inventors satisfying the requirement under 35 USC 115, Oath of the ApplicOATHDECL | OATHDECL | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Email NotificationEML_NTR | EML_NTR | |
| Notice Mailed--Application Incomplete--Filing Date AssignedINCD | INCD | |
| Filing ReceiptFLRCPT.O | FLRCPT.O | |
| Cleared by L&R (LARS)L128 | L128 | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Electronic Information Disclosure StatementEIDS. | EIDS. | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| Referred to Level 2 (LARS) by OIPE CSRL198 | L198 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
8 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Maintenance fee paymentMAFP | MAFP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee payment procedureENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.)FEPP | FEPP | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS |
Numbers
- Publication
- 08892885
- Application
- 13601431
Titles
- English
- System and method for delivering a challenge response in an authentication protocol
Patent term adjustment
- A delay
- +76 daysthe office missed an examination deadline
- Applicant delay
- −38 days
- Net adjustment
- 38 days
Classification
- IPC, 2
- H04L29 06
- H04L9 32
- USPC, 2
- 713168000
- 713151000