`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