UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––
`
`Twilio Inc.
`Petitioner
`
`v.
`
`Telesign Corporation
`Patent Owner
`
`––––––––––
`
`Case IPR2016-00450
`Patent No. 8,462,920
`
`––––––––––
`
`
`PETITIONER’S REPLY IN SUPPORT OF ITS REQUEST FOR
`REHEARING
`
`

`
`
`
`In denying institution, the Board stated: “Notably, Petitioner does not argue that Bennett
`
`teaches notifying the user that the notification event occurred.” (Paper No. 17 at 14.) The
`
`language of claim 1, however, does not require that the registrant be notified. Similarly, the
`
`Board’s construction of “notification event” does not require that the step of notifying be read
`
`into claim 1. Claim 1 just requires use of a notification event that can result in the registrant
`
`being notified. The notifying step first appears in claim 4, and the Petition sets forth Grounds 1-
`
`4 to explain methods by which (1) Bennett and (2) Bennett plus Rothe notify the registrant.
`
`These grounds for claim 4 demonstrate that the “notification event” identified for claim 1
`
`“results in the registrant being notified that the event occurred.” The Board did not address this
`
`highly-relevant material.
`
`Even if Claim 1 required actual notification, the Petition addresses it in element 1(e).
`
`The Petition explains that in response to detecting the occurrence of an established notification
`
`event, Bennett’s communication engine transmits a completion code to the user via SMS
`
`message, voice message, or a telephone call. (Paper No. 1 at 33.) Bennett thus notifies the
`
`registrant. (Id. at 44.) Neither the claim language nor the Board’s construction requires any
`
`specific form of notification. Thus, under the Board’s construction, a user can be notified with
`
`either Bennett’s completion code alone (as set forth for claim 1) or Bennett’s completion code
`
`plus an explanatory message (as set forth for claim 4).
`
`Petitioner highlights the following material in the Petition for claims 1 and 4. This
`
`material shows that Bennett’s “notification events” are the types that result in the registrant being
`
`notified that the event occurred. By improperly reading a notifying step into claim 1 and failing
`
`to consider evidence for claims 1 and 4 regarding the notification-event delivery, the Board
`
`committed legal and factual error that warrants rehearing.
`
`
`
`1
`
`

`
`
`
`Claim 1: “establishing a notification event”: The Petition describes multiple
`
`notification-event types: e.g., (1) attempts to access an account from a new device and (2)
`
`decision engine rules. (Id. at 25.) The Petition also explains what happens when the occurrence
`
`of an event is detected: “The decision engine decides whether to require an out-of-band
`
`authentication based on the result...” (Id.) This out-of-band authentication shows that the
`
`notification event results in the registrant being contacted. The subsequent limitations in claims
`
`1 and 4 demonstrate that the occurrence of these events results in the registrant being notified.
`
`Claim 1: “identifying an occurrence of the notification event”: The Petition describes
`
`how Bennett identifies a notification-event occurrence. (Id. at 27.) This Petition section builds
`
`on the types of notification events described in the “establishing” section. (Id.) (“For element
`
`1[c], three examples of notification events were provided.”) For example, the Petition describes
`
`Bennett’s process for identifying when a user attempts to access an account from a new device.
`
`(Id. at 28.) And when Bennett detects such an attempt, it contacts the user with either a
`
`completion code or a completion code plus an explanation (as described for claim 4).
`
`Claim 1: “after
`
`identifying the occurrence of the established notification
`
`event...establishing a second telephonic contact”: The Petition explains that Bennett contacts
`
`the registrant after identifying an occurrence of the established notification event. (Id. at 31.)
`
`The Petition states: “The authentication application then sends the user’s telephone number and a
`
`completion code to the external communication engine 113 to contact the user over the
`
`registrant’s verified contact. (Ex. 1005 at 15:8-13.) The external communication engine 113 may
`
`contact the registrant by SMS text or voice message to the registrant’s contact....” (Id) (emphasis
`
`added.) The Petition notes that that this process of contacting the registrant “applies to the types
`
`of notification examples described above at Parts X.A.8-X.A.10” (Id.) Parts X.A.8 through
`
`
`
`2
`
`

`
`
`
`X.A.10 are the Petition sections corresponding to Claim 1’s “establishing” and “identifying”
`
`limitations. This Petition material demonstrates what methods Bennett would use to notify the
`
`user that a notification event occurred. The Petition also explains for claim 4, that these same
`
`methods can be used to carry a completion code plus an explanation as to why the user is
`
`receiving the completion code. (Id. at 44-47.)
`
`Claim 1: “after identifying the occurrence of the established notification event
`
`...communicating a second communicated verification code to the registrant”: The Petition
`
`explains that in response to identifying the occurrence of a notification event, Bennett
`
`communicates with the registrant: “Bennett discloses that the communication engine then
`
`transmits the completion code (i.e., the second verification code) through the second telephonic
`
`connection, via SMS message, voice message, or a telephone call.” (Id. at 33.) This Petition
`
`material demonstrates that Bennett’s notification events result in the user being notified.
`
`Claim 4: “notifying the registrant of the occurrence of the established notification
`
`event”: The Petition material for Claim 4 demonstrates that the notification events identified in
`
`the Petition for claim 1 are events that result in the registrant being notified upon their
`
`occurrence. For Grounds 1 and 2, the Petition states: “A POSITA would have found it obvious
`
`and simple to include, as part of the SMS or voice message communicating the verification code,
`
`that a notification event had occurred, so that customers were not constantly calling in to inquire
`
`why a re-verification was required.” (Id. at 45.) For Grounds 3 and 4, Petitioner added Rolfe,
`
`which discloses a system that calls a credit-card owner to inform them when a high-dollar
`
`transaction has occurred. (Id. at 46.) The Petition explains that it would have been obvious to
`
`modify Bennett’s re-verification process to deliver both the confirmation code and a Rolfe-type
`
`explanation so the registrant would know why it is receiving the confirmation code.
`
`
`
`3
`
`

`
`
`
`
`
`
`
`October 11, 2016
`
`BAKER BOTTS L.L.P.
`ATTN: Wayne O. Stacy
`2001 Ross Ave., #800
`Dallas, TX 75201
`Tel: (214) 953-6678
`Fax: (214) 661-4678
`
`
`
`
`Respectfully submitted,
`BAKER BOTTS L.L.P.
`
`/Wayne O. Stacy/
`Wayne Stacy
`Reg. No. 45,125
`Lead Counsel
`
`
`
`
`
`
`
`
`

`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 C.F.R. §§ 42.6(e) and 42.105(b), the undersigned certifies
`
`that on October 11, 2016, the foregoing was served electronically via email on the
`
`following:
`
`Elena McFarland
`(EMCFARLAND@shb.com)
`Tawni Wilhelm
`(TWILHELM@shb.com, TeleSignIPR@shb.com)
`Jesse Camacho
`(JCAMACHO@shb.com)
`Counsel for Patent Owner, TeleSign Inc.
`Shook, Hardy & Bacon LLP
`2555 Grand Blvd.
`Kansas City, MO 64108
`
`Amy Foust
`(AFOUST@shb.com)
`Counsel for Patent Owner, TeleSign Inc.
`Shook, Hardy & Bacon LLP
`201 S. Biscayne Blvd., Suite 3200
`Miami, FL 33131
`
`
`By: /Wayne O. Stacy/
`Wayne Stacy
`Reg. No. 45,125
`Lead Counsel