throbber
CBM2016-00063
`U.S. Patent 8,266,432
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION,
`
`
`
`Petitioner
`
`v.
`
`NADER ASGHARI-KAMRANI and KAMRAN ASGHARI-KAMRANI,
`
`Patent Owners
`
`
`
`U.S. PATENT 8,266,432
`
`Case CBM2016-00063
`
`
`
`PATENT OWNERS RESPONSE
`
`
`
`
`
`
`
`
`
`Mail Stop: PATENT BOARD
`
`Patent Trial and Appeal Board
`
`United States Patent and Trademark Office
`
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`
`
`i
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION ………………………………………………………. 1
`
`II.
`
`SUMMARY OF THE 432 PATENT …………………………………… 1
`
`III. CLAIM CONSTRUCTION ……………………………………....……. 2
`
`A. “User” ………………………………………………………....…….. 3
`
`B. “Central Entity” ………………………………………………....…….. 3
`
`C. “External Entity” ………………………………………………....……. 6
`
`D. “Authenticating” ……………………………………………....…….. 6
`
`E. “Transaction” ………………………………………………....……..
`
`6
`
`F. “During the Transaction” ……………………………………....…….. 8
`
`G. “Dynamic Code” ……………………………………………....…….. 10
`
`IV. UNINTENTIONALLY DELAYED BENEFIT CLAIM GRANTED … 10
`
`V.
`
`PRIORITY DATE OF THE 432 PATENT …………………………….. 11
`
`A. Benefit of Priority based on the 837 and 129 Patents ………………. 12
`
`1. Copendency ……………………………………………………… 12
`
`2. Written Description Support in the 837 Patent ………………….. 12
`
`3. Written Description Support in the 129 Patent …………………... 13
`
`
`a. User vs. Individual ………………………………………… 13
`
`b. Central-Entity vs. Trusted-Authenticator ………………….. 14
`
`c. External-Entity vs. Business ………………………………. 16
`
`d. During the Transaction …………......................................... 17
`
`
`
`ii
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`
`e. Dynamic Code vs. Dynamic Key …………………………. 19
`
`B. Benefit of Priority based on the 837 and 676 Patents ……………… 20
`
`1.
`
`2. Written Description Support in the 837 Patent ………………. 20
`
`3. Written Description Support in the 676 Patent ………………. 21
`
`Copendency ………………………………………………….. 20
`
`
`
`a. User vs. Originator ………………………………………… 21
`
`b. Central-Entity vs. DID Operator ………………………….. 22
`
`c. External-Entity vs. Receiver ………………………………. 24
`
`d. During the Transaction ……………………………………. 25
`
`e. Dynamic Code vs. Digital Identity ………………………… 27
`
`
`VI. NOREFORS DOES NOT QUALIFY AS PRIOR ART ………………. 27
`
`VII. INSTITUTION OF THIS CBMR WAS IMPROPER ………………..… 28
`
`
`
`
`VIII. CONCLUSION ………………………………………………………...……. 29
`
`
`
`iii
`
`
`
`
`
`

`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`
`
`
`
`
`LIST OF EXHIBITS
`
`Exhibit 2007
`
`Statutory Disclaimer filed December 1, 2016
`
`Exhibit 2008
`
`Certificate of Correction issued Oct. 25, 2016
`
`Exhibit 2009 Original Disclosure of Application 11/333,400
`
`Exhibit 2010
`
`Declaration of Dr. Alfred C. Weaver (“Weaver”)
`
`Exhibit 2011
`
`Curriculum Vitae of Dr. Alfred C. Weaver
`
`Exhibit 2012
`
`Witness Experience of Dr. Alfred C. Weaver
`
`Exhibit 2013
`
`Unwired Planet, LLC v. Google Inc. (Fed. Cir. 2016)
`
`
`
`
`
`iv
`
`

`
`
`
`
`
`I.
`
`INTRODUCTION
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`Challenged U.S. Patent 8,266,432 (“the 432 Patent,” Ex. 1001) includes
`
`claims 1-55. Patent Owner has disclaimed claims 4, 11, 29, 46, 49, and 53. See
`
`Exs. 2001 and 2007. Accordingly, claims 1-3, 5-10, 12-28, 30-45, 47, 48, 50-52,
`
`54, and 55 (“the challenged claims”) remain under consideration in this Covered
`
`Business Method Patent Review (“CBMR”). None of the challenged claims has
`
`been amended.
`
`The Patent Trials and Appeals Board (“the Board”) instituted this CBMR on
`
`the following grounds: 35 U.S.C. § 102(b) for being anticipated by U.S. Patent
`
`Application Publication 2006/0094403 (“Norefors”) (Ex. 1032), and 35 U.S.C. §
`
`103(a) for being unpatentable over Norefors in view of U.S. Patent 5,740,361
`
`(“Brown”) (Ex. 1035). Patent Owner respectfully submits that the proposed
`
`grounds are incorrect and the Board should not cancel any of the challenged claims
`
`because Norefors does not qualify as prior art.
`
`II.
`
`SUMMARY OF THE 432 PATENT
`
`The 432 Patent relates to “a system and method provided by a central-entity
`
`for centralized identification and authentication of users and their transactions to
`
`increase security in e-commerce.” Ex. 1001 at 2:52–55. In an example, a customer
`
`(e.g., user 10) and a business (e.g., external-entity 20) can attempt an online
`
`transaction. Id. at FIG. 2, 3:35–40, 4:44-61, and 5:5-9. Before the transaction can
`
`be completed, the business requests a digital identity of the customer. Id. at 5:10-
`
`13. The customer obtains the digital identity from a central-entity, which the
`
`central entity may generate by combining information identifying the user (e.g., a
`
`
`
`1
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`username) with a dynamic, non-predictable and time-dependent code. Id. at 5:13-
`
`20. The customer can then provide the digital identity to the business. Id. at 5:20-
`
`22. The external-entity authenticates the digital identity with the central-entity. Id.
`
`at 5:23-27. If the digital identity is valid, the central-entity authenticates the user to
`
`the business, which then completes the transaction. Id. at 5:28-43. After
`
`authentication, the central-entity may invalidate the digital identity, such that it
`
`cannot be used for another transaction. Id. at 6:7-13.
`
`III. CLAIM CONSTRUCTION
`
`Pursuant to 37 C.F.R. § 42.100(b), claims of an unexpired patent are given
`
`their broadest reasonable construction in light of the specification of the patent in
`
`which the claims appear (“BRI”). Under that construction, claim terms are to be
`
`given a meaning that is consistent with their ordinary and customary meaning as
`
`would be understood by a person of ordinary skill in the art (“POSITA”) in the
`
`context of the entire patent disclosure.1 The customary meaning applies unless the
`
`specification reveals a special definition given to the claim term by the patentee, in
`
`which case the lexicography of the inventors governs.2
`
`Patent Owner submits the following constructions of certain claim terms
`
`
`
`1. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005) (en banc); In re
`
`Cortright, 165 F.3d 1353, 1359, 49 USPQ2d 1464, 1468 (Fed. Cir. 1999);
`
`Research in Motion v. Wi-Lan, Case IPR2013-00126, Paper 10 at 7 (P.T.A.B. June
`
`20, 2013).
`
`2. See Phillips, 415 F.3d at 1316.
`
`
`
`2
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`solely for the purposes of this CBMR.3 Any term not discussed below should be
`
`construed as having its ordinary and customary meaning, as governed by BRI.
`
`A. “User”
`
`For the purposes of this CBMR, the Board construed the term “user” to
`
`mean “a person or business consuming goods and services” Paper 14, at 15.
`
`B.
`
`“Central-Entity”
`
`The “Background” section of the 432 Patent discloses:
`
`As used herein, a "Central-Entity" is any party [(i.e., entity)] that has
`
`user’s personal and/or financial information, UserName, Password
`
`and generates dynamic, non-predictable and
`
`time dependable
`
`SecureCode for the user.
`
`Ex. 1001 at 2:13-18. See, also, Id. at 2:56-3:26.
`
` In view of the application as a whole, a POSITA would understand that the
`
`claimed “central-entity,” as governed by BRI, does not require all of the
`
`information listed in the above passage of the Background. Rather, a POSITA
`
`would have considered “central-entity” to mean, “a party that has a user’s personal,
`
`financial, identification information, UserName, and/or Password, and generates
`
`
`
`3. Patent Owner expressly reserves the right to advance different constructions in
`
`proceedings outside CBM2016-00063 and CBM2016-00064, including the matter
`
`involving U.S. Patent No. 8,266,432 now pending in district court, as the issues
`
`involved and
`
`the applicable claim constructions standards are different.
`
`Accordingly, the constructions presented herein are not an admission for any issues
`
`or proceedings outside of this CBM2016-00063 and CBM2016-00064.
`
`
`
`3
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`dynamic, non-predictable and time-dependent codes for the user.” Weaver, ¶¶ 30-
`
`35.
`
`More specifically, the specification of the 432 Patent describes information
`
`that can be used by the central-entity to identify a user, including alphanumeric
`
`names, IDs, login names, identification phrases, alphanumeric passwords, secret
`
`codes, PINs, or other codes. See Ex. 1001 at 2:27-34. The disclosed authentication
`
`system and method does not require all such information for performing a
`
`transaction and authenticating a user. See, Id. e.g., FIG. 2, Steps D – L, and Col. 5,
`
`Lines 5-58. Instead, the disclosed transaction and authentication can use a “digital
`
`identity,” which can be a combination of a SecureCode (i.e., dynamic code) and
`
`user information, such as a UserName. Id. at 2:41-43.
`
`The claimed invention does not recite or otherwise use all of the information
`
`described in the Background of the 432 Patent. For example, claim 1 recites,
`
`“receiving electronically by the central-entity a request for authenticating the user
`
`… based on a user-specific information …” Also, claim 15 recites, “user
`
`information comprises one or more of the following: an alphanumeric name, an ID,
`
`a login name, and an identification phrase.” Thus, in the context of the claims, the
`
`“central-entity” does not necessarily possess or use personal and/or financial
`
`information, a UserName, and a Password. Accordingly, giving the claimed
`
`“central-entity” its BRI, a POSITA would have interpreted the claimed “central-
`
`entity” such that the Central-Entity has some or all of such user information
`
`described in the Background. Weaver at ¶¶ 30-31.
`
`
`
`4
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`Additionally, a POSITA would interpret the claimed “central-entity” to
`
`include one or more computing devices. Id. at ¶¶ 32-34. For example, claim 1
`
`recites “a computer associated with a central-entity” and claim 25 recites, “a first
`
`central-entity computer” and “a second central-entity computer.” FIG. 2 illustrates
`
`the central-entity 30 includes a computing system that communicates with users 10
`
`and external-entities 20 over communication network 50 (e.g., the Internet). This
`
`computing system performs functions including “secure code generation” and
`
`“digital identity comparison” in an electronic communication or transaction with
`
`user 10 and external-entity 20 via the communication network 50.
`
`A POSITA would have understood that the functions of the computing
`
`system can be performed by separate computer software processes (e.g., a separate
`
`code generation process and a separate identity authentication process) or separate
`
`computing devices (e.g., a random number generator device and an authentication
`
`device), or the functions could be combined into a single software process (e.g., a
`
`combined identification and authentication application) or computing device (e.g.,
`
`a combined identification and authentication server). Id.
`
`Accordingly, for the purposes of this CBMR, Patent Owner construes the
`
`term “central-entity” to mean “a party comprising one or more computing devices,
`
`that has a user’s personal, financial, identification information, UserName, and/or
`
`Password, and that provides dynamic, non-predictable and time-dependent codes
`
`for the user.”
`
`
`
`5
`
`

`
`
`
`
`
`C. “External-Entity”
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`The 432 Patent states “an External-Entity” is a “party offering goods or
`
`services in e-commerce and needs to authenticate the users based on digital
`
`identity.” Ex. 1001 at 3:4-6. Accordingly, for the purposes of the CBMR, Patent
`
`Owner construes the term “external-entity” as defined above.
`
`D. “Authenticating”
`
`The 432 Patent does not expressly define “authenticating.” The specification
`
`states, e.g., “… a secure identification and authentication system 1 would identify
`
`legitimate users 10 and unauthorized users 10.” Ex. 1001, 432 Patent at 4:48-53.
`
`Further, the specification states, e.g.,, “… the Central-Entity 30 locates the user’s
`
`digital identity (UserName and SecureCode) in the system 134 and compares it to
`
`the digital identity received from the External-Entity 20 to identify and validate the
`
`user 10, 138.” Id. at 5:27-32. Thus, in the context of the disclosure of the 432
`
`Patent, the central-entity 30 authenticates a user 10 by verifying the identity of the
`
`user 10. Accordingly, for the purposes of this CBMR, Patent Owner construes the
`
`term “authenticating” to mean “verifying the identity of a user.” See Weaver at ¶
`
`36.
`
`E. “Transaction”
`
`The Board construed the term “transaction” as “a single electronic
`
`transaction between the user and the external entity.” Paper 14, pp. 24-25. The
`
`Board arrived at this construction because the claims features refer to the same
`
`“electronic transaction” recited in the preamble of the independent claims.
`
`However, the Board’s analysis was directed to whether a particular embodiment of
`
`
`
`6
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`the 676 Patent illustrated in FIGS. 4-7 provides written description support for the
`
`claims of the 432 Patent. Id. The Board concluded that the “interbank funds
`
`transfer transaction” depicted in FIGS. 4-7 involves different transactions (debiting
`
`an account and crediting a different account) between different entities (OPFI 25
`
`and RPFI 35). Therefore, to exclude the embodiment illustrated in FIGS. 4-7, the
`
`Board concluded that there must be a “single transaction.” Patent Owner
`
`respectfully submits that the term “single” in the Board’s construction of
`
`“transaction” is not consistent with BRI because it may be considered to exclude
`
`disclosed embodiments encompassed by the claimed invention.
`
` One of ordinary skill in the art would understand intrabank fund transfer
`
`transactions would be within the scope of the claimed invention. Weaver at ¶
`
`0037. E.g., in FIG. 2 of the 432 Patent, the External-Entity 30 can be a bank
`
`performing a banking service for a user 10. Id. Such a transaction involves sub-
`
`transactions of debiting a first account at a bank and crediting a different account.
`
`However, in accordance with aspects of the 432 Patent, if authentication fails, then
`
`the entire transfer (including the sub-transactions) necessarily fails. Otherwise,
`
`funds could be debited from the first account without crediting the second account.
`
`Because the claimed invention encompasses transactions involving more
`
`than one sub-transaction, including the term “single” in the meaning of
`
`“transaction” is not consistent with BRI. Accordingly, for the purposes of this
`
`CBMR, Patent Owner construes the term “transaction” to mean “an electronic
`
`transaction between the user and the external entity.”
`
`
`
`7
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
` F. “During the Transaction”
`
`The 432 Patent does not expressly define the term “during the transaction.”
`
`For the reasons detailed below, a POSITA would interpret this term to mean “a
`
`period after the initiation of the transaction between a user and an external-entity
`
`and before the transaction is completed,” when the term is properly construed in
`
`view of the specification and drawings of the 432 Patent.
`
` The specification discloses the steps of an example “transaction phase.”
`
`See, e.g., Ex. 1001 at FIGS. 2, 4, and 5, and 5:5-22. In this regard, the 432 Patent
`
`discloses:
`
`… [T]he transaction phase, where the user 10 attempts to access a
`restricted web site or attempts to buy services or products 110, as
`illustrated in FIG. 4 …. The External-Entity 20 displays the access or
`purchase authorization form requesting the user 10 to authenticate
`himself using his UserName and SecureCode as digital identity. The
`user 10 requests SecureCode from the Central-Entity 30 by accessing
`his account over the communication network 50, 114. The Central-
`Entity 30 generates dynamic, non-predictable and time dependable
`SecureCode 118 for the user 10. … When the user 10 receives the
`SecureCode 120, the user 10 provides his UserName and SecureCode
`as digital identity to the External-Entity 20, 124, FIG. 4.
`
`The third phase is identification and authorization phase. Once the
`
`user 10 provides his digital identity to the External-Entity 20, the
`
`External-Entity 20 forwards users digital identity along with the
`
`identification and authentication request to the Central-Entity 30, 130
`
`… When the Central-Entity 30 receives the request containing the
`
`user’s digital identity, the Central-Entity 30 locates the user’s digital
`
`
`
`8
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`identity (UserName and SecureCode) in the system 134 and compares
`
`it to the digital identity received from the External-Entity 20 to
`
`identify and validate the user 10, 138. The Central-Entity 30 generates
`
`a
`
`reply back
`
`to
`
`the External-Entity 20 via a communication
`
`network 50 as a result of the comparison. If both digital identities
`
`match, the Central-Entity 30 will identify the user 10 and will send an
`
`approval of the identification and authorization request to the
`
`External-Entity 20, 140 …
`
`Id. at 5:5-43
`
`Thus, the disclosed transaction phase includes user 10, e.g., initiating a
`
`transaction by attempting to access a restricted web site or attempting to buy
`
`services or products via the external entity 20. However, after such transaction is
`
`initiated with the external-entity 20, the central-entity 30 must successfully
`
`authenticate the user 10 for the external-entity 20 before permitting completion of
`
`such an attempted transaction. See, e.g., Ex. 1001 at 1:35-37, 2:64-3:6, 3:35-40,
`
`and 3:52-53. Consequently, a POSITA would understand that the steps included in
`
`the transaction phase and the authorization phase illustrated in FIG. 2 occur after
`
`the attempted transaction is initiated and before the attempted transaction is
`
`completed. Weaver at ¶ 38.
`
`In view of at least the above-identified passages, Patent Owner construes the
`
`term “during an electronic transaction” for the purposes of this CBMR to mean “a
`
`period after the initiation of a transaction between a user and an external-entity and
`
`before the transaction is completed.”
`
`
`
`9
`
`

`
`
`
`
`
`F. “Dynamic Code”
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`The claimed “dynamic code” corresponds to the disclosed “SecureCode.”
`
`The 432 Patent states:
`
`The term “SecureCode” is used herein to denote any dynamic, non-
`
`predictable and time dependent alphanumeric code, secret code, PIN
`
`or other code, which may be broadcast to the user over a
`
`communication network, and may be used as part of a digital identity
`
`to identify a user as an authorized user.
`
`Ex. 1001 at 2:35-40.
`
`The Board construed the term “dynamic code” as “an alphanumeric code
`
`that is non-predictable and time dependent, which may be broadcast to the user
`
`over a communication network, and may be used as a part of a digital identity to
`
`identify a user as an authorized user.” Paper 14 at p. 18. However, the Board’s
`
`construction is not consistent with the BRI because the 432 Patent does not require
`
`that the SecureCode be alphanumeric. Weaver at ¶ 39-40. Additionally, the term
`
`“may be” is optional language that does not limit the meaning of the term
`
`“dynamic code.” Id. Accordingly, for the purposes of the CBMR, Patent Owner
`
`construes the term “dynamic code” to mean “a code that is non-predictable and
`
`time-dependent.”
`
`IV. UNINTENTIONALLY DELAYED BENEFIT CLAIM GRANTED
`
`
`
`The Office granted a Petition to Accept an Unintentionally Delayed Benefit
`
`Claim in the 432 Patent on September 19, 2016. This paper was previously
`
`submitted to the Board on September 23, 2016, as Exhibit 2006. This Benefit
`
`Claim establishes a chain of priority to the filing date of U.S. Patent Application
`
`
`
`10
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`09/940,635 (Ex. 1016) through U.S. Patent Application 11/333,400 (Ex. 2004).
`
`V.
`
`PRIORITY DATE OF THE 432 PATENT
`
`Pursuant to 35 U.S.C. § 120 and 37 C.F.R. § 1.78 (a)(1) and (d), a
`
`nonprovisional patent application can claim benefit to one or more prior-filed
`
`copending applications. A patent claim is entitled to the benefit of the filing date of
`
`a prior-filed application only if the original disclosure of the prior-filed application
`
`provides written description support for the patent claim as required by 35 U.S.C. §
`
`112, first paragraph.4 The claimed subject matter need not be described in haec
`
`verba in the original specification in order to satisfy the written description
`
`requirement.5 Rather, the test for determining compliance with the written
`
`description requirement is whether the original disclosure of the prior-filed
`
`application reasonably would have conveyed to a person having ordinary skill in
`
`the art that the inventor had possession of the claimed subject matter at the time of
`
`the prior-filed applications filing date.6
`
`
`
`4. In re NTP, Inc., 654 F.3d 1268, 1276–77 (Fed. Cir. 2011); In re Chu, 66 F.3d
`
`292, 297 (Fed. Cir. 1995).
`
`5. In re Wright, 866 F.2d 422, 425 (Fed. Cir. 1989).
`
`6. Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en
`
`banc); Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555, 1563–64 (Fed. Cir. 1991); In re
`
`Kaslow, 707 F.2d 1366, 1375 (Fed. Cir. 1983).
`
`
`
`11
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`A. Benefit of Priority Based on the 837 and the 129 Patents
`
`1. Copendency
`
`The Office issued Corrected Filing Receipt (Ex. 2006) and a Certificate of
`
`Correction issued on Oct. 25, 2016, (Ex. 2008) establishing copendency from the
`
`837 Patent to the 129 Patent, and from the 129 Patent to the 432 Patent. More
`
`specifically, the application that issued as the 432 patent has an actual filing date of
`
`September 15, 2008. Ex. 1001 at [22]. That application claims the benefit, as a
`
`continuation-in-part application, of the following prior-filed non-provisional
`
`applications:
`
`(1) U.S. Patent Application 09/940,635 (Ex. 1016), which was filed
`
`on August 29, 2001, and issued as U.S. Patent 7,356,837 B2 on April
`
`8, 2008 (Ex. 1005 at [22], [45]); and
`
`(2) U.S. Patent Application 11/333,400 (Ex. 2004), which was filed
`
`on January 18, 2006, and issued as U.S. Patent 8,281,129 B1 on
`
`October 2, 2012 (Ex. 2004 at [22], [45]).
`
`2. Written Description Support in the 837 Patent
`
`The specification of the 837 Patent is substantially identical to the originally-
`
`filed Application 09/940,635, which issued as the 837 Patent. Further, the
`
`specification of 837 Patent is substantially identical to that of the 432 Patent. See
`
`Exhibits 1001 and 1016. Therefore, it follows that the specification of the 837
`
`Patent as originally filed provides sufficient written description support for the 432
`
`Patent under § 112, first paragraph.
`
`
`
`12
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`3. Written Description Support in the 129 Patent
`
`For the Board’s convenience, Patent Owner herein cites to the specification
`
`and drawings of the 129 Patent, which are substantially identical to those of the
`
`originally-filed application 11/333,400 (Ex. 2009), which issued as the 129 Patent.
`
`Patent Owner submits that the challenged claims of the 432 Patent are supported
`
`by the originally-filed disclosure of the 129 Patent.
`
`As detailed below, the 129 Patent and the 432 Patent use different
`
`terminology to describe examples of different implementations consistent with the
`
`invention. Even though their terminology differs, the 129 Patent supports the
`
`subject matter recited in the claims of the 432 Patent. A claim chart is appended
`
`hereto as Appendix 1, illustrating specific written description support for the claim
`
`features recited in the challenged claims.
`
`a. User vs. Individual
`
`Patent Owner adopted the Board’s claim construction of the term “user” to
`
`mean “a person or business consuming goods and services” for the purposes of this
`
`CBMR.
`
`The 129 Patent describes an individual 10 as “a person, company or
`
`organization that has established a trusted relationship with a trusted-authenticator
`
`30.” Ex. 2004 at 7:51-53. The individual 10 can be, e.g., a customer 10 of a
`
`business 20 and, in more particular examples, can be a customer of a car dealership
`
`or an applicant of credit from creditor. Id. at Abstract, 1:12-15, 4:67-5:4, 8:59-67,
`
`9:1-12, and 11:24-31. Thus, the individual 10 can be a person or business
`
`consuming goods and services, as the term “user” is construed. Moreover, in both
`
`
`
`13
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`the 129 and 432 Patents, the user and individual can be authenticated by a trusted
`
`party (e.g., the 432 Patent’s central entity 30 and the 129 Patent’s trusted
`
`authenticator 30) to complete electronic transactions with an external entity (e.g.,
`
`the 432 Patent’s external entity 20 and the 129 Patent’s business 20).
`
`Consequently, a POSITA would reasonably conclude that the “individual”
`
`disclosed in the 129 Patent provides sufficient written description support for the
`
`claimed “user” of the 432 Patent. Weaver at ¶¶ 42-45.
`
`b. Central-Entity vs. Trusted-Authenticator
`
`Patent Owner construed the term “central-entity” to mean “a party
`
`comprising one or more computing devices, that has a user’s personal, financial,
`
`identification information, UserName, and/or Password, and that provides
`
`dynamic, non-predictable and time-dependent codes for the user” for the purposes
`
`of this CBMR.
`
`The 129 Patent discloses, “The proposed method enables businesses to
`
`determine whether the customer is truly the person who he says he is by adopting a
`
`new two-factor authentication technique and authenticating customer’s identity
`
`utilizing trusted authenticator.” Ex. 2004, Abstract. The 129 Patent describes a
`
`“trusted-authenticator” as follows:
`
`… an entity that already knows the individual 10, maintains
`
`information about that individual 10, and has established a trusted
`
`relationship with that individual 10. A reasonable candidate for such a
`
`trusted-authenticator 30 would be a bank or other financial institution.
`
`
`
`…
`
`14
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`… A static key might be any identification phrases such as password,
`
`name, UserName, SSN, alias, account number, customer number, etc
`
`or the combination of this information.
`
`The use of “dynamic key” refers to SecureCode which is a key or
`
`information that is variable and is provided to the individual 10 by the
`
`individual's trusted-authenticator 30 at the time it is needed for
`
`authentication. The dynamic key is an alphanumeric code and will
`
`have a different value each time the individual 10 receives it from
`
`his/her trusted-authenticator 30 for authentication purposes. … [The]
`
`dynamic key may have a non-repeating value, may be time dependent
`
`(valid for some period of time) and may be in an encrypted format.
`
`Id. at 7:59-8:23.
`
`Further, the 129 Patent discloses:
`
`… [T]he trusted-authenticator 30 calculates and sends 102 a dynamic
`
`key to the individual 10 over a communication network 50. The
`
`trusted-authenticator 30 maintains both the static and dynamic keys
`
`…
`
`Id. at 9:22-28.
`
`As illustrated in, e.g., FIGS. 2a and 2b of the 129 patent, the trusted-
`
`authenticator 30 comprises a party (e.g., an entity) including at least one computing
`
`device in the depicted system. Because the trusted-authenticator 30 can be a bank
`
`or other financial institution having a relationship with the individual, it logically
`
`follows that the trusted-authenticator 30 would possess an individual’s 10 personal
`
`and/or financial information. And, because trusted-authenticator 30 maintains the
`
`static key, it follows that the trusted-authenticator 30 can possess a password,
`
`name, UserName, SSN, alias, account number, customer number, etc. Moreover,
`
`
`
`15
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`the functions of the trusted-authenticators in the 129 Patent are substantially
`
`similar to those of the central-entity of claim 1 of the 432 Patent. Weaver at ¶ 46.
`
`See, also, 129 Patent at FIGS. 2a and 2b, and 9:13-10:20.
`
`In view of at least the above-identified portions of the 129 Patent, in addition
`
`to other locations, the trusted-authenticator 30 sufficiently discloses a party (e.g. a
`
`bank or financial institution) comprising one or more computing devices, that has a
`
`user’s (individual 10) personal, financial, identification information (e.g., bank or
`
`financial account information), UserName, and/or Password (e.g., static key), and
`
`that provides dynamic, non-predictable and time-dependent codes (e.g., dynamic
`
`codes) for the user. Thus, the trusted-authenticator 30 includes all the elements of
`
`the “central-entity” as construed above. Consequently, a POSITA would
`
`reasonably conclude that the trusted-authenticator disclosed in the 129 Patent
`
`provides sufficient written description support for the claimed “central-entity” of
`
`the 432 Patent. Weaver at ¶ 46.
`
`c. External-Entity vs. Business
`
`Patent Owner construed this term “external-entity” to mean “a party offering
`
`goods or services in e-commerce and needs to authenticate the users based on
`
`digital identity” for the purposes of this CBMR.
`
`The 129 Patent discloses that a business broadly refers to a company or
`
`organization (online or offline) that has established a trusted relationship with a
`
`trusted-authenticator 40 and that needs
`
`to authenticate
`
`the identity of the
`
`individual 10.” Ex. 2004 at 7:54-58. For example, business 20 offers goods or
`
`
`
`16
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`services in e-commerce, and needs to authenticate users based on digital identity.
`
`Id. at FIGS. 2a and 2b. Further, the business 20 performs the functionality of the
`
`“external entity” claimed in the 432 Patent. Weaver at ¶ 48. See, also, 129 Patent
`
`at FIGS. 2a and 2b, and 9:13-10:20. Thus, a POSITA would reasonably conclude
`
`that the business 20 disclosed in the 129 Patent provides sufficient written
`
`description support for the claimed “external entity” of the 432 Patent. Weaver at
`
`¶ 47-48.
`
`d. During the Transaction
`
`Patent Owner construed this term “transaction” to mean “an electronic
`
`transaction between the user and the external entity” and the term “during the
`
`transaction” to mean “a period after the initiation of a transaction between a user
`
`and an external-entity and before the transaction is completed” for the purposes of
`
`this CBMR.
`
`The 129 Patent does not expressly state that certain functions are performed
`
`“during a transaction,” as recited in the claims of the 432 Patent. Nevertheless, for
`
`the reasons below, a POSITA would reasonably conclude that this subject matter is
`
`disclosed by the specification of the 129 patent. As depicted in, e.g., FIG. 2 of the
`
`432 Patent and, e.g., in FIG. 2a of the 129 Patent, both disclose a process in which
`
`a first entity (e.g., the 432 Patent’s central-entity 30 and the 129 Patent’s trusted-
`
`authenticator 30) authenticates a user during a period after an electronic transaction
`
`(e.g., accessing a restricted website via network 50) between a user (e.g., the 432
`
`Patent’s user 10 and the 129 Patent’s individual 10) and external entity (e.g., the
`
`
`
`17
`
`

`
`
`
`
`
`
`
`
`CBM2016-00063
`U.S. Patent 8,266,432
`
`432 Patent’s external-entity 20 and the 129 Patent’s business 20) is initiated, and
`
`before such electronic transaction is permitted to be completed.
`
`In accordance with an example embodiment of the 129 Patent, before the
`
`business 20 completes the transaction, the business 20 may request that the
`
`individual 10 validate his/her identity by providing a static key and dynamic key.
`
`Ex. 2004 at FIG. 2a, 110, and 9:15-18. To fulfill this request, before the
`
`transaction can be completed, the individual 10 can request a dynamic key from
`
`the trusted-authenticator 30. Id. at FIG. 2a, 100, and 9:19-22. In response to the
`
`request from the individual 10, before the transaction can be completed, the
`
`trusted-authenticator 30 calculates a dynamic key, and sends the dynamic key to
`
`the individual, and maintains the dynamic key and a static key of the individual. Id.
`
`at FIG. 2a, 102, and 9:23-25. After receiving the dynamic key f

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket