US20070192829A1

Authenticated communication using a shared unpredictable secret

Claim Score by NHIP

Abstract

Systems, methods and computer readable media for authenticating one or more client devices (1) to a server (5). A shared unpredictable secret (50) is generated. The shared unpredictable secret (50) is stored in the client device (1) and in the server device (5). The client device (1) proves possession of the correct shared unpredictable secret (50) to the server (5). The shared unpredictable secret (50) is replaced by a new shared unpredictable secret (54) each time the client device (1) logs in to the server device (5).

US20070192829A1, drawing sheet 1 — Sheet 1 of 6

Term

Term ended

Projected expiry passed 28 July 2023, 3.2 years ago.

18 claims: 3 independent, 15 dependent

1
Broadest claimClaim Score 72, broad(NHIP)A method for validating a client device by a server device, said method comprising the steps of:generating a shared unpredictable secret;storing the shared unpredictable secret in the client device and in the server device;requiring the client device to prove that it holds a correct secret as a precondition to the server device validating the client device;and replacing the shared unpredictable secret by a new shared unpredictable secret when the server device validates the client device, wherein: the server device sends update data to the client device;the client device applies the update data to the shared unpredictable secret to generate a new secret;and the client device replaces the shared unpredictable secret with the new secret.
17
A system for enabling a server device to validate a client device, said system comprising:at least one client device;a server device;a shared unpredictable secret;means for storing the shared unpredictable secret in the client device;means for storing the shared unpredictable secret in the server device;coupled to the client device and to the server device, means for determining whether the client device holds a correct secret;coupled to the determining means, means for allowing the server device to validate the client device when the client device proves that it holds a correct secret;and coupled to the client device and to the server device, means for replacing the original shared unpredictable secret with a new shared unpredictable secret when the server device validates the client device, said means for replacing further comprising: means for the server device to send update data to the client device;means for the client device to apply the update data to the shared unpredictable secret to generate a new secret;and means for the client device to replace the shared unpredictable secret with the new secret.
18
A computer readable medium containing computer program instructions for enabling a server device to validate a client device, said computer program instructions causing the execution of the following steps:generating a shared unpredictable secret;storing the shared unpredictable secret in the client device and in the server device;requiring the client device to prove that it holds a correct secret as a precondition to allowing the client device to be validated by the server device;and replacing the shared unpredictable secret by a new shared unpredictable secret when the client device is validated by the server device, wherein: the server device sends update data to the client device;the client device applies the update data to the shared unpredictable secret to generate a new secret;and unpredictable secret with the new secret.

Independent claims3

42 paragraphs in 5 sections, as filed

0001This application is a continuation of U.S. patent application Ser. No. 09/921,265, originally entitled “Countering Credentials Copying,” filed Aug. 1, 2001; which claims priority from U.S. Provisional Patent Application Ser. No. 60/226,429, “Countering Credentials Theft,” filed on Aug. 18, 2000. The subject matter of all of the foregoing are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

00021. Field of the Invention

0003This invention pertains to the field of secure communications between and among digital devices such as computers, and, specifically, pertains to techniques for thwarting the copying of credentials by nefarious persons or otherwise.

00042. Description of the Related Art

0005Diffie-Hellman key exchange, as described in U.S. Pat. No. 4,200,770, is a mechanism to permit two entities to have a shared secret; the secret could be an encryption key. In the present invention, shared unpredictable secret 50 is not an encryption key.

SUMMARY OF THE INVENTION

0006The present invention comprises systems, methods, and computer readable media for authenticating a client device (1) to a server device (5). A preferred method comprises the steps of generating a shared unpredictable secret (50), storing the shared unpredictable secret (50) in the client device (1) and in the server device (5), and requiring the client device (1) to prove that it contains the correct shared unpredictable secret (50) as a precondition to allowing the client device (1) to log in to the server device (5). The shared unpredictable secret (50) is replaced by a new shared unpredictable secret (54) each time the client device (1) logs in to the server device (5).

BRIEF DESCRIPTION OF THE DRAWINGS

0007These and other more detailed and specific objects and features of the present invention are more fully disclosed in the following specification, reference being had to the accompanying drawings, in which:

0008<figref idref="DRAWINGS">FIG. 1</figref> is a block system-level diagram of a preferred embodiment of the present invention.

0009<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram of a preferred embodiment of the registration/reset phase of the present invention.

0010<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram of a preferred embodiment of the log-in phase of the present invention.

0011<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram illustrating an alternative embodiment of the method illustrated in <figref idref="DRAWINGS">FIG. 3</figref>.

0012<figref idref="DRAWINGS">FIG. 5</figref> is an illustration of shared unpredictable secret 50 and its progeny.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0013As used in the present patent application, client (sometimes referred to as “client device”) 1 can be any digital device, e.g., a personal computer, mobile phone, smartcard, Internet appliance, or any other network accessible device. There may be one client 1 or, as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, a finite number n of clients 1. Each client 1 wishes to communicate with an infrastructural component that is referred to in the present patent application as a server (or “server device”) 5. Server 5 may provide any type of service to client 1. For example, server 5 might be an Internet service provider or a telephone network access point. The communications link between client 1 and server 5 may be any link, such as a wireless link, a wired link, or a link over a network 4, which may be an open network such as the Internet. The communications link 4 may be an encrypted connection such as SSL. The initiation of a communication session between client 1 and server 5 is referred to herein as a log-in.

0014One concern in such an environment pertains to credentials sharing. In this scenario, a person who has access to a client device 1 voluntarily shares his personal credentials, such as a password or private cryptographic key, with other user devices 2. All of these user devices 2 employ the user account of the original user. Two problems that arise from this scenario are: 1) It is difficult for server 5 to hold particular users 2 accountable for their actions when using the services provided by server 5, since some or all users 2 are indistinguishable from each other; and 2) Users may fraudulently avoid paying subscription fees that are designed for payment on a per-user basis.

0015Another concern is outright credentials theft. In this scenario, a nefarious person having access to a client-like device, referred to as “attacker 3” in <figref idref="DRAWINGS">FIG. 1</figref>, penetrates a legitimate client device 1 copies stored credentials data from client device 1 into attacker device 3, perhaps supplements this thievery with a determination of other information such as the user's password, personal identification number, or social security number from other sources, and then masquerades as the legitimate user from the attacker device 3. When the client device 1 being attacked is a hardware device and not a software module, this scenario is sometimes referred to as “device cloning”. Client devices 1 that are typically cloned include mobile telephones and smartcards.

0016The present invention uses a method of stateful authenticators to provide a low cost, low overhead means of detecting when one user account is being used for more than one client device 1 over a period of time. Specifically, the stateful authenticator used herein is a shared unpredictable secret 50. The present invention has utility in countering credentials sharing behavior by effectively restricting use of a user account to one or a limited number of client devices 1. The invention also counters credentials theft by means of detecting the use of one user account from more than one client device 1 after stored credentials have been copied between client devices 1, regardless of how easy or difficult it was to copy the credentials from the original device 1.

0017All of the method steps illustrated herein describe modules that can be implemented in hardware, software, and/or firmware. Some of these modules reside on the client device 1 and some on the server device 5, as will be understood by examining the Figures in conjunction with the following description.

0018The method will first be described with respect to a special case in which there is but one legitimate client device 1 and one legitimate user associated therewith. There are two phases of the method of the present invention: a registration/reset phase and a log-in phase.

0019<figref idref="DRAWINGS">FIG. 2</figref> illustrates the registration/reset phase. In step 21, client 1 presents its authentication data to server 5. The ensuing dialog between client 1 and server 5 is geared to determining whether the user associated with client 1 is legitimately associated with a claimed user account. The authentication data presented by client 1 may include private personal data, a response to a pre-established challenge question posed by server 5, a biometric input such as a fingerprint or an eyeball scan, etc. The registration/reset phase is designed to be undertaken only infrequently.

0020At step 22, server 5 decides whether the authentication data presented by client 1 are acceptable. If not, client 1 is not allowed to register (step 24). If acceptable, client 1 is allowed to register (step 23). In this eventuality, the shared unpredictable secret 50 is generated (step 24).

0021As illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, the shared unpredictable secret (SUS) 50 comprises an unpredictable component 51 and an optional fixed component 52. Unpredictable component 51 must be unpredictable because, pursuant to the present invention, it is replaced during each log-in. Thus, unpredictable component 51 may be generated by a random number generator, a pseudo-random number generator, or a quasi-random number generator. Typically, unpredictable component 51 is generated at server 5, but it may also be generated at client 1, or at a combination of server 5 and client 1. For example, it may be pre-installed in client 1 during manufacture or during a device 1 personalization process.

0022When used, fixed component 52 is typically identification information. For example, fixed component 52 may be a serial number of the client device 1. This could be useful when there are two or more client devices 1 associated with the same user account number. Conversely, fixed component 52 could be the user account number when there is more than one user account number associated with the same client device 1. This situation may occur, for example, when a user has one account number for business use and another account number for personal use; or when two users share the same cellular telephone 1.

0023Typically, after server 5 has generated SUS 50, server 5 transmits SUS 50 to client 1. The transmission is preferably encrypted, for reasons of security. Any type of encryption, including symmetric or asymmetric encryption, may be used. Alternatively, an SUS 50 having an unpredictable component 51 is generated by the aforementioned Diffie-Hellman key exchange technique, or pre-installed in device 1 as described previously. The same SUS 50 is stored in both server 5 and client 1 (step 25). SUS's 50 should be stored in a secure fashion, such as using tamper-resistant hardware protection, e.g., epoxied integrated circuits, or by means of dynamically changing the location of SUS's 50 (and new SUS's 54) in storage.

0024<figref idref="DRAWINGS">FIG. 3</figref> illustrates the basic method of the log-in phase. The log-in, at least for legitimate users, is not meant to be attempted until after the registration/reset phase has successfully concluded. Steps 30, 31, and 32 are optional. At step 30, client 1 presents credentials to server 5. The credentials may include a password, personal identification number (PIN), a transformed (e.g. hashed) password, biometric signature, or cryptographic authentication proof generated from a private cryptographic key. Since log-ins normally occur more frequently than registration/rests, the character and content of the credentials and procedure are such that the server's check of the credentials is simpler and faster than the server's check of the user's authentication data in previously-described step 21. In step 31, server 5 checks the credentials. If the check fails, typically the client is not allowed to log in (step 32).

0025If the check passes, the method moves to step 33, where client 1 presents proof data to server 5. The proof data allows server 5 to verify that client 1 holds the correct SUS 50. It is desirable that SUS 50 itself be not directly communicated over an open network 4 lest it be intercepted by a nefarious person. One method by which client 1 computes proof data without revealing SUS 50 itself is for client 1 to compute a one-way function of SUS 50. The one-way function is typically a cryptographic hash function. Then, at step 34, server 5 checks the proof data by applying its proof data generation algorithm to its (server 5's) stored version of SUS 50. If the proof data generated by server 5 matches the proof data presented by client 1, client 1 has passed the test and is allowed to log in at step 36. Otherwise, client 1 has failed the test and is given reduced or no privileges at step 35. In order for this method to work, client 1 and server 5 have to be using consistent if not identical proof data generation algorithms. It is immaterial whether or not an eavesdropper knows what this algorithm is (or what these algorithms are).

0026If step 35 is entered, one or more things may happen. For example, client 1 may be rejected outright and not allowed to attempt to log in ever again. Less onerously, client 1 could be allowed to log in but with reduced privileges, such as the ability to read a Web page stored on server 5 but not to conduct any financial transactions thereon; or client 1 could be made to re-enter the registration/reset phase.

0027As a corollary to client 1 being allowed to log in at step 36, a new shared unpredictable secret 54 is generated at step 37. Again, new SUS 54 (see <figref idref="DRAWINGS">FIG. 5</figref>) is typically generated by sever 5. Then, at step 38, server 5 sends update data 53 to client 1. Update data 53 is such that client 1 and server 5 are able to generate new SUS 54 from the most recent version of SUS 50 by means of applying update data 53 thereto. For example, update data 53 could be a new random, pseudo-random, or quasi-random number that client 1 and server 5 XOR with old SUS 50 in order to generate new SUS 54. Alternative to the use of update data 53, server 5 could send an encrypted new SUS 54 to client 1, but the advantage of sending update data 53 is that update data 53 does not have to be encrypted, thus making for a simpler and less cumbersome protocol.

0028At step 39, client 1 updates its (client 1's) storage area that is allocated to SUS's with new SUS 54, and at step 40, server 5 updates its (server 5's) storage area that is allocated to SUS's with new SUS 54.

0029The method illustrated in <figref idref="DRAWINGS">FIG. 3</figref> works well when the communication channels 4 are clean and uncorrupted, but a potential problem arises in the case of a noisy or corrupted channel 4: update data 53 could be lost in transit between client 5 and server 1.

0030One solution to the problem of noisy or corrupted channels 4 is illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, wherein an acknowledgement (ACK) message is used. This embodiment is identical to the embodiment illustrated in <figref idref="DRAWINGS">FIG. 3</figref> up through step 39, except that step 36 is not executed until later—user 1 is not allowed to log in until the ACK is received by server 5. In step 41, client 1 sends the ACK to server 5 after client 1 has successfully received update data 53. The ACK may optionally contain proof data that allows server 5 to verify that client 1 has successfully computed the new SUS 54. The proof data should not be the same proof date as used in step 33; otherwise, a replay attack would be possible.

0031Step 42 illustrates the reality that server 5 may or may not receive the ACK, either because the update data 53 were lost in transit, the ACK was lost in transit, or the client device 1 failed. If server 5 receives the ACK, then client 1 is allowed to check in at step 36 and step 40 is entered into, i.e., server 5 updates its (server 5's) storage area that is allocated to SUS's with the new SUS 54. Thus, in future log-in attempts, both client 1 and server 5 will have stored therewithin new SUS 54; and the proof data (of client 1 in step 33 and server 5 in step 34) will be based upon new SUS 54.

0032If, on the other hand, server 5 does not receive the ACK from client 1, server 5 (at step 43) is programmed to accept proof data emanating from both old SUS 50 and new SUS 54. Thus, if the situation is that client 1 has received the update data 53, but for some reason the ACK has been lost in transit, during the next log-in attempt client 1 at step 33 will be presenting proof data emanating from new SUS 54 and server 5 at step 34 will be programmed to accept it. If, on the other hand, the reason that server 5 did not receive the ACK at step 42 was that update data 53 was not received by client 1, then, during the next log-in attempt, client 1 at step 33 will be presenting proof data emanating from old SUS 50 and server 5 at step 34 will be programmed to accept it.

0033The protocols described herein have the following desirable properties: 1) Any SUS (50) value produces no more than one successful log-in; and 2) If the protocol fails at any stage, both client 1 and server 5 are left in a state that a new invocation of the protocol will operate correctly.

0034Optionally, for example in conjunction with step 34, server 5 maintains an audit trail of log-in attempts, noting in particular those log-in attempts in which the step 34 checks have failed. Each audit record should contain the then current values of old SUS 50 and new SUS 54. In the event a legitimate user disputes accountability for actions attributed to use of his account, if server 5 maintains an audit trail of log-in attempts, the service provider or systems administrator can use the audit trail in resolving such disputes.

0035By using the techniques described herein, any user possessing or knowing correct credentials and attempting a log-in from a client device 1 that holds the correct SUS 50 will succeed in logging in, even in the event a log-in sequence is not successfully completed, owing, for example, to a communication or system failure.

0036The present invention automatically protects against message replay, i.e., the situation where an eavesdropper records a session and plays it back. This is because a new SUS 54 is generated at each successful log-in.

0037If the legitimate user of the credentials voluntarily shares his credentials with one or more other users who will be operating from what in essence becomes an illegitimate client device 2, only one client (legitimate client 1 or illegitimate client 2) can successfully log in subsequently without server 5 invoking special action, such as causing the requesting client 1,2 to re-execute the registration/reset phase. This represents a disincentive for the legitimate user to share his credentials, since his own usage of his account will be negatively impacted.

0038If the legitimate user's credentials are copied in a credentials theft, then one of the following scenarios will subsequently occur:

00391) The legitimate client 1 logs in again before the attacker 3 attempts to masquerade as a legitimate user. In this case, the attacker 3 log-in will be alerted to the server 5 and consequently be subject to special action, such as rejection outright or granting of reduced privileges.

00402) The attacker 3 logs in before legitimate client 1 logs-in again. In this case, attacker 3 can successfully masquerade as a legitimate user up to the time of the legitimate user's next log-in attempt. On the legitimate user's next log-in attempt, server 5 will be alerted and special action taken. This special action might include out-of-band communication with the legitimate user, investigation of the situation, and consequent shut-out of attacker 3 from further log-ins.

0041As stated previously, there may be legitimate use of a number n of different client devices 1 by a single legitimate user. In this case, server 5 holds current SUS's 50 and new SUS's 54 for each client device 1, and considers each client device 1 to be legitimate; and each client device 1 has its own unique SUS 50 and new SUS 54. The number n of clients 1 may be restricted in accordance with local policy. In this scenario, SUS's 50, 54 are respectively unique from one device 1 to the next. The registration/reset process has to be undertaken by each client device 1 to establish each SUS 50. In all other respects, the invention is the same as described above in conjunction with the single client 1 embodiment.

0042The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the spirit and scope of the present invention.

Contents5

Every citation, both ways

Citations
Document	Relation	Office	Cited during
US8606234B2	Cited by	United States of America	Applicant
US9582685B2	Cited by	United States of America	Applicant
US8453222B1	Cited by	United States of America	Search report
US2005180572A1	Cited by	United States of America	Pre-grant
US8397281B2	Cited by	United States of America	Applicant
US9946855B2	Cited by	United States of America	Applicant
US7802085B2	Cited by	United States of America	Search report
US2011159848A1	Cited by	United States of America	Pre-grant
US2011162053A1	Cited by	United States of America	Pre-grant
US2014068738A1	Cited by	United States of America	Pre-grant
US7925751B1	Cited by	United States of America	Search report
US2001048745A1	Cites	United States of America	Pre-grant
US4200770A	Cites	United States of America	Pre-grant
US5146498A	Cites	United States of America	Pre-grant
US5323464A	Cites	United States of America	Pre-grant
US5613214A	Cites	United States of America	Pre-grant
US5661807A	Cites	United States of America	Pre-grant
US5815665A	Cites	United States of America	Pre-grant
US5940007A	Cites	United States of America	Pre-grant
US5953420A	Cites	United States of America	Pre-grant
US5991405A	Cites	United States of America	Pre-grant
US5995624A	Cites	United States of America	Pre-grant
US6029150A	Cites	United States of America	Pre-grant
US6148404A	Cites	United States of America	Pre-grant
US6182220B1	Cites	United States of America	Pre-grant
US6240184B1	Cites	United States of America	Pre-grant
US6445780B1	Cites	United States of America	Pre-grant
US6757825B1	Cites	United States of America	Pre-grant
US6802000B1	Cites	United States of America	Pre-grant
US6938157B2	Cites	United States of America	Pre-grant
US7032109B1	Cites	United States of America	Pre-grant

6 members in 3 offices

This recordMember, by publication datePriority claim

Priority claims8

Priority claims
Document	Office	Kind	Date
22642900	United States of America	P	2000-08-18
92126501	United States of America	A	2001-08-01
34094806	United States of America	A	2006-01-27
09921265	–	–	–
60226429	–	–	–
US20000226429P	–	–	–
US20010921265	–	–	–
US20060340948	–	–	–

Members6

Family members, oldest first
Document	Office	Kind
WO0217555A2	World Intellectual Property Organization (WIPO)	A2	2002-02-28
AU8508301A	Australia	A	2002-03-04
US2002062452A1	United States of America	A1	2002-05-23
WO0217555A3	World Intellectual Property Organization (WIPO)	A3	2003-01-03
US2007192829A1	United States of America	A1	2007-08-16
US8478998B2	United States of America	B2	2013-07-02

105 transactions on the USPTO file

Allowed after 3 non-final rejections, 2 final rejections and 4 RCEs.

Non-final rejections: 3
Final rejections: 2
RCEs: 4
Appeals: 0

Over time

Point at a mark for the transaction

Transactions

Prosecution transactions, newest first
	Event	Code
2017-09-29	Correspondence Address ChangeC.ADB	C.ADB
2013-07-02	Recordation of Patent Grant MailedPGM/	PGM/
2013-07-02	Patent Issue Date Used in PTA CalculationAllowedPTAC	PTAC
2013-06-12	Issue Notification MailedAllowedWPIR	WPIR
2013-05-23	Dispatch to FDCD1935	D1935
2013-05-23	Application Is Considered Ready for IssuePILS	PILS
2013-05-22	Issue Fee Payment VerifiedN084	N084
2013-05-22	Issue Fee Payment ReceivedIFEE	IFEE
2013-02-22	Mail Notice of AllowanceAllowedMN/=.	MN/=.
2013-02-22	Notice of Allowance Data Verification CompletedAllowedN/=.	N/=.
2013-01-10	Date Forwarded to ExaminerFWDX	FWDX
2013-01-10	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2013-01-07	Request for Continued Examination (RCE)RCEX	RCEX
2013-01-07	Workflow - Request for RCE - BeginBRCE	BRCE
2012-11-02	Mail Notice of AllowanceAllowedMN/=.	MN/=.
2012-11-01	Notice of Allowance Data Verification CompletedAllowedN/=.	N/=.
2012-11-01	Case Docketed to Examiner in GAUDOCK	DOCK
2012-10-31	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2012-10-30	Information Disclosure Statement consideredIDSC	IDSC
2012-10-30	Reference capture on IDSRCAP	RCAP
2012-10-30	Information Disclosure Statement (IDS) FiledM844	M844
2012-10-30	Request for Continued Examination (RCE)RCEX	RCEX
2012-10-30	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2012-10-30	Workflow - Request for RCE - BeginBRCE	BRCE
2012-07-30	Mail Notice of AllowanceAllowedMN/=.	MN/=.
2012-07-30	Notice of Allowance Data Verification CompletedAllowedN/=.	N/=.
2012-07-25	Reasons for AllowanceEX.R	EX.R
2012-07-25	Examiner's Amendment CommunicationEX.A	EX.A
2012-07-13	Change in Power of Attorney (May Include Associate POA)PA..	PA..
2012-07-12	Correspondence Address ChangeC.AD	C.AD
2012-03-16	Date Forwarded to ExaminerFWDX	FWDX
2012-03-12	Response after Non-Final ActionA...	A...
2012-03-12	Request for Extension of Time - GrantedXT/G	XT/G
2011-10-14	Electronic ReviewELC_RVW	ELC_RVW
2011-10-14	Email NotificationEML_NTF	EML_NTF
2011-10-14	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2011-10-06	Non-Final RejectionNon-final rejectionCTNF	CTNF
2011-07-27	Date Forwarded to ExaminerFWDX	FWDX
2011-07-27	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2011-07-25	Request for Continued Examination (RCE)RCEX	RCEX
2011-07-25	Request for Extension of Time - GrantedXT/G	XT/G
2011-07-25	Workflow - Request for RCE - BeginBRCE	BRCE
2011-05-05	Email NotificationEML_NTR	EML_NTR
2011-05-05	Email NotificationEML_NTR	EML_NTR
2011-05-05	Change in Power of Attorney (May Include Associate POA)PA..	PA..
2011-05-05	Mail Examiner Interview Summary (PTOL - 413)MEXIN	MEXIN
2011-04-28	Correspondence Address ChangeC.AD	C.AD
2011-04-25	Examiner Interview Summary Record (PTOL - 413)EXIN	EXIN
2011-02-24	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2011-02-23	Final RejectionFinal rejectionCTFR	CTFR
2010-12-23	Date Forwarded to ExaminerFWDX	FWDX
2010-12-20	Response after Non-Final ActionA...	A...
2010-12-20	Request for Extension of Time - GrantedXT/G	XT/G
2010-10-12	Case Docketed to Examiner in GAUDOCK	DOCK
2010-08-20	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2010-08-19	Non-Final RejectionNon-final rejectionCTNF	CTNF
2010-04-10	Date Forwarded to ExaminerFWDX	FWDX
2010-04-10	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2010-04-08	Information Disclosure Statement consideredIDSC	IDSC
2010-04-08	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2010-04-08	Information Disclosure Statement (IDS) FiledM844	M844
2010-04-08	Request for Continued Examination (RCE)RCEX	RCEX
2010-04-08	Request for Extension of Time - GrantedXT/G	XT/G
2010-04-08	Workflow - Request for RCE - BeginBRCE	BRCE
2010-03-22	Correspondence Address ChangeC.ADB	C.ADB
2010-03-17	Mail Examiner Interview Summary (PTOL - 413)MEXIN	MEXIN
2010-03-11	Examiner Interview Summary Record (PTOL - 413)EXIN	EXIN
2010-02-22	Mail Advisory Action (PTOL - 303)MCTAV	MCTAV
2010-02-18	Advisory Action (PTOL-303)CTAV	CTAV
2010-02-10	Date Forwarded to ExaminerFWDX	FWDX
2010-02-08	Response after Final ActionA.NE	A.NE
2009-12-08	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2009-12-06	Final RejectionFinal rejectionCTFR	CTFR
2009-10-05	Date Forwarded to ExaminerFWDX	FWDX
2009-08-17	Response after Non-Final ActionA...	A...
2009-08-17	Request for Extension of Time - GrantedXT/G	XT/G
2009-02-17	Mail Notice of Restarted Response PeriodMNRES	MNRES
2009-02-04	Letter Restarting Period for Response (i.e. Letter re References)NRES	NRES
2009-02-03	Correspondence Address ChangeC.AD	C.AD
2008-10-09	Case Docketed to Examiner in GAUDOCK	DOCK
2008-09-11	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2008-09-10	Non-Final RejectionNon-final rejectionCTNF	CTNF
2007-08-16	PG-Pub Issue NotificationPG-ISSUE	PG-ISSUE
2007-05-08	Receipt of all Acknowledgement LettersL130	L130
2007-05-08	Receipt of Acknowledgment LetterL197	L197
2007-05-08	Receipt of Acknowledgment LetterL197	L197
2007-04-17	IFW TSS Processing by Tech Center CompleteTSSCOMP	TSSCOMP
2007-04-17	Case Docketed to Examiner in GAUDOCK	DOCK
2007-03-30	Mail-Petition Decision - GrantedMPTGR	MPTGR
2007-03-26	Change in Power of Attorney (May Include Associate POA)PA..	PA..
2007-03-25	Correspondence Address ChangeC.AD	C.AD
2007-02-08	Petition EnteredPET.	PET.
2006-04-03	Information Disclosure Statement consideredIDSC	IDSC
2006-04-03	Information Disclosure Statement (IDS) FiledM844	M844
2006-04-03	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2006-04-03	Reference capture on IDSRCAP	RCAP
2006-03-15	Application Is Now CompleteCOMP	COMP
2006-03-14	Application Dispatched from OIPEOIPE	OIPE
2006-03-13	Agency Referral Letter MailedML196	ML196
2006-03-13	Agency Referral Letter MailedML196	ML196

Showing 100 of 105

8 legal events, as the office reported them to INPADOC

Over the term

Point at a mark for the event

Events

Legal events, newest first
	Event	Code
2021-08-31	Lapsed due to failure to pay maintenance feeLapsedFP	FP
2021-08-09	Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS	LAPS
2021-08-09	Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH	STCH
2021-02-22	Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP	FEPP
2019-11-21	AssignmentAS	AS
2016-12-28	Fee paymentFPAY	FPAY
2013-06-12	Information on status: patent grantGrantedPATENTED CASESTCF	STCF
2010-12-14	AssignmentAS	AS

Authenticated communication using a shared unpredictable secret

Claim Score by NHIP

Abstract