unified patents inc. v. verify smart corp., ipr2016-00836 (petition)

8/18/2019 Unified Patents Inc. v. Verify Smart Corp., IPR2016-00836 (Petition)

1/64

IPR2016–00836

U.S. Patent 8,285,648

DOCKET NO.: 098173–1006063

Filed on behalf of Unified Patents Inc.

By: Paul C. Haughey, Reg. No. 31,836

Scott Kolassa, Reg. No. 55,337

Kilpatrick Townsend & Stockton LLP

Two Embarcadero Center, Eighth Floor

San Francisco, CA 94111–3834

Tel: (415) 576–0200

Email: [email protected]

Jonathan Stroud, Reg. No. 72,518

Kevin Jakel, Reg. No. 58,790

Unified Patents Inc.

1875 Connecticut Ave. NW, Floor 10

Washington, D.C., 20009

Tel: (202) 805–8931

Email: [email protected]

UNITED STATES PATENT AND TRADEMARK OFFICE

____________________________________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD

____________________________________________

UNIFIED PATENTS INC.

Petitioner

v.

VERIFY SMART CORP.

Patent Owner

IPR2016–00836Patent 8,285,648

PETITION FOR I NTER PARTES REVIEW OF

U.S. PATENT NO. 8,285,648

CHALLENGING CLAIMS 1–3, 5–7, 9–16 and 19

UNDER 35 U.S.C. § 312 AND 37 C.F.R. § 42.104


2/64

IPR2016–00836

U.S. Patent 8,285,648

i

TABLE OF CONTENTS

I. Mandatory Notices ........................................................................................... 1

A. Related Matters ..............................................................................................1

B. Real Party–in–Interest ...................................................................................2

C. Counsel ..........................................................................................................2

D. Service Information ....................................................................................... 2

E. Fee Payment .................................................................................................. 3

II.

Certification of Grounds for Standing .............................................................. 3

III. Overview of Challenge and Relief Requested ................................................. 3

A. Prior Art Patents and Printed Publications ....................................................4

B. Grounds for Challenge ..................................................................................4

C. Priority date of the ’648 Patent ..................................................................... 5

D. Summary of the Alleged Invention ............................................................... 5

E. Level of Ordinary Skill in the Art .................................................................6

F. Prosecution History .......................................................................................6

IV. Claim Construction ........................................................................................... 7

A. “downloading local software” or “software downloaded” ...........................8

B. “device identifier” .........................................................................................9

V. Specific Grounds for Petition ......................................................................... 10

A. Ground 1: Claims 1–3, 5–7, 9–16 and 19 are obvious in view of Law

(EX1003). .............................................................................................................10

1. Law ...........................................................................................................10

2.

Claims 1 And 5 are obvious in view of Law ............................................. 13

3. Claim 2 is obvious in view of Law ........................................................... 22





3/64

IPR2016–00836

U.S. Patent 8,285,648

ii


8.

Claim 10 is obvious in view of Law ......................................................... 32

9. Claims 11 and 12 are obvious in view of Law ......................................... 33

10. Claim 13 is obvious in view of Law ...................................................... 34

11. Claims 14 and 15 are obvious in view of Law ......................................34



B. Ground 2: Claims 1–3, 5–7, 9–16 and 19 are obvious over Blonder in view

of Weller. ..............................................................................................................39

1. Blonder .....................................................................................................39

2. Weller .......................................................................................................39

3. Claims 1 And 5 are obvious over Blonder in view of Weller. .................. 41

4. Claim 2 is obvious over Blonder in view of Weller. ................................ 46




8.

Claim 9 is obvious over Blonder in view of Weller. ................................ 51

9. Claim 10 is obvious over Blonder in view of Weller. .............................. 52

10. Claims 11 and 12 are obvious over Blonder in view of Weller. ........... 53

11. Claim 13 is obvious over Blonder in view of Weller. ........................... 54

12. Claims 14 and 15 are obvious over Blonder in view of Weller. ........... 54

13. Claim 16 is obvious over Blonder in view of Weller. ........................... 55

C. Ground 3: Claim 19 is obvious over Blonder in view of Weller and

Labrou. .................................................................................................................56

VI. Conclusion ...................................................................................................... 59


4/64

IPR2016–00836

U.S. Patent 8,285,648

iii

LIST OF EXHIBITS

Exhibit Description

EX1001 U.S. Patent No. 8,285,648 (“the ’648 Patent”)

EX1002 Unified Patents Inc.’s Voluntary Interrogatories

EX1003 U.S. Pub. 20050184145 to Law ( Law)

EX1004 U.S. Patent 7,827,115 to Weller et al. (Weller )

EX1005 U.S. Pat. 5,708,422 to Blonder et al . ( Blonder )

EX1006 U.S. Pat. 7,606,560 to Labrou ( Labrou)

EX1007 Verify Smart Corp.’s Response to Invalidity Contentions

EX1008 Declaration of Stephen GrayEX1009 U.S. Pat. 8,572,391 to Golan (Golan)

EX1010 PTO Assignment database record for the ’648 Patent

EX1011 Verify Smart v. Basecamp complaint


5/64

IPR2016–00836

U.S. Patent 8,285,648

1

I. MANDATORY NOTICES

A.

Related Matters

The Patent Office Assignment Database shows that the ’648 Patent is shown

as assigned to Dan Scammell ( see EX1010), but Verify Smart Corp. asserts in its

various patent assertion district court complaints that the patent was assigned to

Verify Smart Corp. ( see example in EX1011, Verify Smart v. Basecamp

complaint).

Between May 19, 2014 and March 17, 2016, Verify Smart filed patent

infringement lawsuits in various district courts (i.e., Eastern District of Texas, New

Jersey, Southern District of New York). Verify Smart sued HSBC USA Inc.

(NJD-2-14-cv-03217, dismissed), Bank of America Corporation (NJD-2-14-cv-

05117, dismissed), Bank of America, NA (NJD-2-15-cv-05348, dismissed),

Microsoft Corporation (NJD-2-15-cv-05596, dismissed), Apple Inc. (NJD-2-15-cv-

06207, dismissed), Facebook, Inc. (NYSD-1-15-cv-08673, dismissed), Yahoo! Inc.

(NJD-2-15-cv-07965, dismissed), Basecamp, Inc. (TXED-2-16-cv-00239,

pending), Dropbox, Inc. (TXED-2-16-cv-00238, pending), Salesforce.com, Inc.

(TXED-2-16-cv-00237, pending), USAA (TXED-2-16-cv-00236, pending), and

Twitter, Inc. (TXED-2-16-cv-00235, pending).


6/64

IPR2016–00836

U.S. Patent 8,285,648

2

Additionally, a petition for Covered Business Method review filed by Bank

of America, NA, was dismissed due to settlement before any preliminary response

or an institution decision (CBM2015-00173).

B.

Real Party–in–Interest

Under 37 C.F.R. § 42.8(b)(1), Unified Patents Inc. (“Unified” or

“Petitioner”) certified that Unified is the real party-in-interest, and further certifies

that no other party exercised control or could exercise control over Unified’s

participation in this proceeding or the filing of this petition. In this regard, Unified

has submitted voluntary discovery. See EX1002 (Petitioner’s Voluntary

Interrogatory Responses).

C.

Counsel

Paul C. Haughey (Registration No. 31,836) will act as lead counsel; Kevin

Jakel (Registration No. 58,790), Jonathan Stroud (Registration No. 72,518), and

Scott Kolassa (Registration No. 55,337) will act as back-up counsel.

D.

Service Information

Unifed consents to electronic service at [email protected]

and [email protected], provided both are copied and served together.

Petitioner can be reached at Kilpatrick Townsend & Stockton LLP, Eighth Floor,

Two Embarcadero Center, San Francisco, CA, 94111, USA, and by telephone at


7/64

IPR2016–00836

U.S. Patent 8,285,648

3

(415) 273-4787 (Paul), or at Unified Patents Inc., 1875 Connecticut Ave. NW,

Floor 10, Washington, D.C., 20009, and by telephone at (650) 999-0899 (Jonathan).

E.

Fee Payment

The required fees are submitted under 37 C.F.R. §§ 42.103(a) and 42.15(a). If any

additional fees are due during this proceeding, the Office may charge such fees to

Deposit Account No. 20-1430.

II.

CERTIFICATION OF GROUNDS FOR STANDING

Petitioner certifies under Rule 42.104(a) that the patent for which review is

sought is available for inter partes review, that (1) the petitioner is not the owner

of the ’648 patent; (2) the petitioner is not barred or estopped from requesting IPR;

and (3) this Petition is being filed less than a year after service of a complaint

alleging infringement of the ’648 patent.

III.

OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

Pursuant to Rules 42.22(a)(1) and 42.104(b)(1)–(2), Petitioner challenges

claims 1–3, 5–7, 9–16 and 19 of the ’648 patent.


8/64

IPR2016–00836

U.S. Patent 8,285,648

4

A. Prior Art Patents and Printed Publications

The following references are pertinent to the grounds of unpatentability

explained below:1

1. U.S. Pub. 2005/0184145 to Law (“ Law,” EX1003), filed Feb. 7, 2005,

published Aug. 25, 2005, which is prior art under 35 U.S.C. § 102(b).

2. U.S. Pat. 5,708,422 to Blonder (“ Blonder ,” EX1004) filed May 31, 1995,

issued Jan. 13, 1998, which is prior art under 35 U.S.C. § 102(b).

3.

U.S. Pat. 7,827,115 to Weller, filed April 24, 2001, issued Nov. 2, 2010

(“Weller,” EX1005), which is prior art under 35 U.S.C. § 102(e).

4. U.S. Pat. 7,606,560 to Labrou, filed March 24, 2006, issued Oct. 20,

2009 (“ Labrou,” EX1006), which is prior art under 35 U.S.C. § 102(e).

B.

Grounds for Challenge

Petitioner requests cancellation of claims 1–3, 5–7, 9–16 and 19 of the ’648

Patent as unpatentable under 35 U.S.C. § 103. This Petition, supported by the

accompanying declaration of Stephen Gray (“Gray Decl.” (EX1008)),

1The ’090 Patent issued from a patent application filed prior to enactment of the

America Invents Act (“AIA”). Accordingly, pre–AIA statutory framework applies.


9/64

IPR2016–00836

U.S. Patent 8,285,648

5

demonstrates that there is a reasonable likelihood that Petitioner will prevail with

respect to challenged claims 1–3, 5–7, 9–16 and 19. See 35 U.S.C. § 314(a).

Ground Proposed Statutory Rejections for the ’648 Patent Exhibit No.

1Claims 1–3, 5–7, 9–16 and 19 are obvious under 35

U.S.C. § 103(a) over Law (EX1003) EX1003

2

Claims 1–3, 5–7 and 9–16 are obvious under 35 U.S.C.

§ 103(a) over Blonder (EX1004) in view of Weller

(EX1005).

EX1004

EX1005

3

Claim 19 is obvious under 35 U.S.C. § 103(a) over

Blonder (EX1004) in view of Weller (EX1005) and

Labrou (EX1006).

EX1004

EX1005

EX1006

VI. Overview of the ’648 Patent

C.

Priority date of the ’648 Patent

The ’648 Patent was filed March 27, 2009, claiming priority to

PCT/CA2007/001639 filed Sept. 14, 2007. Thus, for this petition, the priority date

is Sept. 14, 2007.

D.

Summary of the Alleged Invention

The ’648 Patent (EX1001) describes using a verification code (e.g., a

password) to verify the identity of a user in a financial transaction. A user is

assigned a PIN or password (“bona fide secure identifier”), which is stored in a

“verifier-database” accessible to a “verifier-computer.” ’648 Patent at 4:24–29;

6:52–55; Fig. 1. When the user wishes to execute a financial transaction such as a


10/64

IPR2016–00836

U.S. Patent 8,285,648

6

credit card purchase, the verifier-computer opens a communications link and sends

an “identity verification request (IVR)” to the user (e.g., an SMS text message)

requesting entry of the assigned PIN or password. Id . at 4:34–41; 8:13–39. In

response, the user enters and sends a PIN or password (“putative secure

identifier”), Id . at 8:51–57, which the verifier-computer compares to the previously

assigned bona fide secure identifier. If they match, the financial transaction is

allowed to proceed. Id . at 9:5–10.

E.

Level of Ordinary Skill in the Art

A person of ordinary skill in the art (“POSA”) for the ’648 Patent would

have an undergraduate degree in Management Information Systems, Computer

Science, or Electrical Engineering, or equivalent professional system development

experience, plus two years of work experience with payment systems and

computer networking. Gray Decl. (EX1008) ¶20–25.

F.

Prosecution History

The ’648 Patent was originally filed as a PCT, and the PCT report indicated

that the claims were novel and had inventive step. Narainsamy WO 2005/001670

(D1) was identified as the closest prior art. It was described as follows: “Although

D1 teaches most of the steps of the present method, D1 does not teach that the


11/64

IPR2016–00836

U.S. Patent 8,285,648

7

mobile number as well as a PIN of the user are pre–enrolled and stored at a verifier

database for later use.”

In a first office action mailed 11/10/2010, the claims were rejected as

indefinite under §112 and obvious over Pierson 20050278543 and Official Notice.

The application was abandoned, and taken over by new counsel. A petition

to revive was filed along with an amendment on 8/23/2011. A series of Statements

were added to the specification corresponding to the original claims. Claim 1 was

not amended, but other claims were canceled and new claims added. New claim

21 [issued claim 5] was characterized as “essentially Claim 1 re-written without

the “pre-enrolling” language.” 8/23/2011 Amendment at 32. Claim 1 was

distinguished from Pierson for many reasons, including that the “network device

identifier” corresponded to a device, not a user. The amendment was found to be

non-compliant, and a revised version was mailed 12/12/2011.

A notice of allowance was mailed 6/8/2012. The Reasons for Allowance

referred to the applicant’s remarks filed 12/12/2011.

IV.

CLAIM CONSTRUCTION

Claim terms of a patent in inter partes review are normally given the

“broadest reasonable construction in light of the specification.” See 37 C.F.R.


12/64

IPR2016–00836

U.S. Patent 8,285,648

8

§ 42.100(b): see also In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1279–81

(Fed. Cir. 2015).

The following discussion proposes constructions and support for those

constructions. Any claim terms not included in the following discussion should be

given their ordinary meaning in light of the specification, as commonly understood

by those of ordinary skill in the art. The broadest reasonable interpretation of a

claim term may be the same as or broader than the construction under the ordinary

meaning standard set forth in Phillips v. AWH Corp, 415 F.3d 1303 (Fed. Cir.

2005), but it cannot be narrower. See Facebook, Inc. v. Pramatus AV LLC , 2014

U.S. App. LEXIS 17678, *11 (Fed. Cir. 2014). The constructions proposed below

should be applied regardless of whether the terms are interpreted under the Phillips

standard or the “broadest reasonable interpretation” standard.

Patent Owner has defined numerous terms in the Background of the ’648

Patent. ’648 Patent at 1:10–2:55. Petitioner adopts those definitions for purposes

of this Petition. The following additional terms are construed (See Gray Decl.

(EX1008) ¶27–34):

A.

“downloading local software” or “software downloaded”

According to the ’648 Patent, “downloading local software” can be done

through a “number of . . . techniques [that] will be obvious to those skilled in the


13/64

IPR2016–00836

U.S. Patent 8,285,648

9

art.” ’648 Patent (EX1001) at 11:28–32. Examples include downloading the

software to a chip provided by the verifier or downloading to a dedicated device at

the time of manufacture. Id . at 11:32–36. The specification of the ’648 Patent thus

makes it clear that the local software may be “downloaded” to the user

communication device by any means, including as part of the manufacturing

process prior to the purchase of the device

Petitioner submits the construction of “downloading local software” is

loading software on a user communication device by any means, including the

pre–loading of such software on a user communication device as part of the

manufacturing process. Petitioner submits the construction of “software

downloaded” is software obtained by “downloading local software.”

B. “device identifier”

The ’648 Patent doesn’t use the term “device identifier” outside the claims,

except in “Statement 15” parroting claim 19 and added during prosecution. ’648

Patent at 18:5–15. However, “device identification information” is described:

“At this point the verifier can optionally also acquire from the mobile phone a device identification information that can be used to identify

that particular phone. In embodiments in which the user–computer is

a laptop computer, PDA, or other computer instead of a mobile


14/64

IPR2016–00836

U.S. Patent 8,285,648

10

communications device, the serial number of the computer’s CPU can

be acquired by the verifier.” ’648 Patent (EX1001) at 7:6–13.

Consistent with this use, Petitioner submits the construction of “device

identifier” is device identification information that can be used to identify a

particular device.

V. SPECIFIC GROUNDS FOR PETITION

A.

Ground 1: Claims 1–3, 5–7, 9–16 and 19 are obvious in view of Law (EX1003).

1. Law

Law, titled “Secure Wireless Authorization System,” was published on

August 25, 2005. The USPTO did not consider Law during the prosecution of the

’648 Patent.

Law discloses “a secure wireless authorization system by which a user can

employ a wireless device to authorize a request that is initiated by a remote third

party and transmitted to the user by an authorization server.” Law (EX1007) at

Abstract. Law describes three authorization models that can be implemented with

the disclosed system: pre-authorization, real-time authorization and post-

authorization. Id . at ¶42. These models can operate individually, in a pair, or all in

unison. Id. Of particular relevance to this Petition is the real–time authorization

model shown in Figure 3, in which a user is authenticated during a financial


15/64

IPR2016–00836

U.S. Patent 8,285,648

11

transaction. Id. at ¶47, Fig. 3. Figure 6 shows the pre-registration and a variation

of this real–time authorization model in which the authorization server initiates the

connection. Id.2 at ¶¶61–62, Fig. 6. Like the claimed invention of the ’648 Patent,

the real-time authorization model disclosed in Law (Fig. 3 or 6) can be used to

verify the identity of a buyer in a credit card transaction. ’648 Patent (EX1001) at

9:55–57; Law at ¶21.

In this real-time authorization model, a user initiates a transaction with a

third party such as, for example, an online merchant or a retailer with a point-of-

sale device. Law at ¶36. The transaction is put in a “pending” state while the third

party submits an authorization request to an “authorization server.” Id. at ¶47. The

server then sends an authorization request to the user’s wireless device with the

transaction details. Id. ¶¶47, 49. The user authorizes the transaction by entering a

PIN number, which is transmitted back to the authorization server.

Id. at ¶49. If the PIN provided is correct (i.e., matches one previously stored for

2The Figure 6 embodiment is identical to that of the Figure 3 embodiment, but with

the added steps 90, 92, 94 and 96. Cites to one embodiment should be understood

to reference both with the exception of these four steps. Id . at ¶61.


16/64

IPR2016–00836

U.S. Patent 8,285,648

12

that user), the authorization server sends a response back to the third party to allow

the transaction to proceed. Id. at ¶50. Fig. 6 of Law is copied below.


17/64

IPR2016–00836

U.S. Patent 8,285,648

13

2.

Claims 1 And 5 are obvious in view of Law

Claims 1 and 5 recite the same substantive method steps with the only

difference being that Claim 1 groups some of these steps into “pre-enrolling” sub-

methods (a) and (b), whereas Claim 5 does not. During prosecution claim 21

[issued claim 5] was characterized as “essentially Claim 1 re-written without the

“pre-enrolling” language.” File history, 8/23/2011 Amendment at p. 32. Also,

claim 1(g) recites “sending through the communication link” while claim 5 (h)

recites “receiving through the communication link. Thus, these claims are

addressed together with only the language of claim 1 in the claim chart.

Law shows all the elements by itself, except that certain elements may be

argued to not be explicitly shown, but are inherent in how one of skill in the art

would understand the teachings of Law, or are common knowledge or an obvious

design choice for one of skill in the art. In particular, as set forth below, it is

common knowledge for a PIN as in Law to be designated by the issuing bank or

selected by the user, and to be stored in a database (for the later comparison

described in Law). The described “preregistered” GUID of Law would be

understood to require storing it in a database accessible by the authorization server.

One of skill in the art would recognize that Law’s described verifying the PIN of


18/64

IPR2016–00836

U.S. Patent 8,285,648

14

the user upon receiving the user response requires that the PIN be “retrieved” from

the database.

These minor differences from the claimed invention are also obvious in view

of the scope of the prior art ( Law) as discussed below, in accordance with the level

of ordinary skill in the art discussed above, pursuant to the factors in Graham v.

John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966) as reiterated by the Supreme

Court in KSR International Co. v. Teleflex Inc. (KSR), 550 U.S. 398, 82 USPQ2d

1385 (2007) , based on the following factual inquiries:

• (A) Determining the scope and content of the prior art; and

• (B) Ascertaining the differences between the claimed invention and the prior

art; and

• (C) Resolving the level of ordinary skill in the pertinent art.

See Gray Decl. (EX1008) ¶ 43–48. Certain minor features of the dependent

claims are similarly obvious as described in more detail below, also based on being

inherent, common knowledge, obvious design choice and meeting the KSR criteria

as described above.

Preamble—verif ying user identi ty dur ing electronic transaction

Law teaches verifying the identity of a user with a PIN by an authorization

server [verifier] during a transaction as shown in the below chart.


19/64

IPR2016–00836

U.S. Patent 8,285,648

15

Claim 1 Law (emphasis added)

1. A user identityverification method for

verifying the identity of

a user by a verifier in

the course of an

electronic transaction,

said user identity

verification method

comprising the steps of:

“[0023] The real–time authorization model …. Thetransaction is placed in a pending state [in the course

of] until the third party initiates a transaction request to

the authorization server. The authorization server

[verifier] determines if the user and the third party have

the right criteria. …the authorization server sends out

an authorization request to the user's wireless device.

The user either approves or denies the request along

with a personal identification number (PIN) or personal

digital signature [verifying the identity].”

Element (a) Pre-enroll ing user with bona fide secure identif ier

The ’648 Patent defines a “secure identifier” as follows (emphases added):

Secure identifier"––a generic term for a secure data representation

used to identify a person. The term includes, by way of example,

secure alphanumeric representations, passwords, codes, secret

numbers, PINs, . . . that can be used to identify a person or entity. . . .

The term "putative secure identifier" refers to a secure identifier that

is offered in response to an IVR [Identity Verification Request]. A

"bona fide secure identifier" refers to a known valid secure identifier

to which a putative secure identifier is compared.

’648 Patent at 2:44–55.

Law discloses a providing a PIN to an authorization server during

registration [pre-enrolling], and thus is a “bona fide secure identifier” to be later

compared with a user input PIN “putative secure identifier” during a transaction


20/64


21/64

IPR2016–00836

U.S. Patent 8,285,648

17

(a2) storing the bona fide

secure identifier in a

database that is accessible

to the verifier;

“[0039] The authorization server 24 [verifier]

includes [accessible] adatabase

26 which stores the

account information [secure identifier] of the users

they serve.”

Element (b) – pre–enr oll ing a user communi cations device with a user access

number (for a communication li nk with the device) stored in a ver if ier database.

Law discloses a user “wireless device,” such as a “mobile cellular phone.”

Law at ¶41. This is a “user communications device,” which is defined by the ’648

Patent to include “cell phones.” ’648 Patent at 2:21–33. An example of a “user

access number” given in the ’648 Patent is a user’s cell phone number, which may

be used to call the phone or send text messages. Id . at 6:60–66.

Law discloses the use of a Global Unique Identifier (GUID), which is a

unique number used to contact the wireless device. Law at ¶39. Like the ’648

Patent, Law states that the GUID may be the SMS number which would be used to

send text messages. Id . at ¶60. The ’648 Patent defines “communications link”

simply as a “wireless link” between the user’s communications device and the

verifier.” ’648 Patent at 10:2–4. The Law GUID is used to contact the wireless

device, and thus opens a communications link. Law at ¶38. The GUID is

“preregistered” (pre–enrolling), which one of skill in the art would recognize as


22/64

IPR2016–00836

U.S. Patent 8,285,648

18

necessarily requiring it be stored in a database accessible by the authorization

server.

b) pre–enrolling a user

communications device,

wherein pre–enrolling the

user communications

device comprises the

steps of:

(b1) obtaining a useraccess number for the

user communications

device, wherein the user

access number can be

used to open a

communications link with

the user communications

device; and,

(b2) storing the user

access number in adatabase that is accessible

to the verifier;

“[0065] …before the authorization begins, the user

registers [pre–enrolling] its GUID [access number of

user communication device] with the authorization

server.”

“[0060[ ….For GUIDs that rarely change, such as

SMS numbers, they can be pre–registered [pre–

enrolling]….”“[0039] The authorization server 24 [verifier] includes

[accessible] a database 26 which stores the account

information of the users they serve. ….Depending on

which authorization model used, the server must also

keep track of the global unique identifier (GUID)

[access number] of the wireless device in order to be

able to contact it [open a communications link].”

“[0060] ….Alternatively, another server can maintain

[database] the current list of active wireless devices [user communication device] and their identifiers

[user access number].”

Element (c) – retr ieving the user access number

Law teaches looking up (retrieving) the GUID (access number). Law at ¶62.

(c) retrievingthe user access

number stored

at Step (b2);

“[0062] However, if no valid pre–authorization exists, theauthorization server will look up [retrieving] the GUID [access

number] of wireless device 38 and attempt to connect to the

wireless device with the GUID obtained (Block 94).”


23/64

IPR2016–00836

U.S. Patent 8,285,648

19

Element (d) – verif ier opens communications link with user device using access

number.

Law teaches that the authorization server uses the GUID (access number) to

connect to the wireless device. This connection is a “communications link,” which

is described in the ’648 Patent as “any communications technology now existing or

to be implemented in the future.” ’648 Patent (EX1001) at 11:66–12:2.

(d) opening a

communications link

between the verifier and the

user communications

device by using the user

access number retrieved at

Step (c);

“[0062] However, if no valid pre–authorization

exists, the authorization server [verifier] will look

up the GUID of wireless device 38 and attempt to

connect [open communication link] to the wireless

device [user communication device] with the

GUID [user access number] obtained (Block 94).”).

Element (e) – verif ier sends identity ver i f ication request (I VR) to user thr oughcommunications li nk.

The ’648 Patent defines “Identity Verification Request (IVR)” as “an

electronic request initiated by a verifier and sent to a user asking the user to verify

the user’s identity.” ’648 Patent at 2:41–43. Law teaches that “the server will send

out an authorization request to the user’s wireless device.” Law at ¶49.

(e) sending an identity

verification request (IVR) from the verifier

to the user through the

communications link

“[0049] However if no valid pre–authorization exists,

the server [verifier] will send out an authorization

request [verification request] to the user’s wireless

device [user] (Block 74) and start monitoring the

response time from the user (Block 76). The request


24/64

IPR2016–00836

U.S. Patent 8,285,648

20

opened at Step (d); will travel through an encrypted secure channel

[communications link] connecting the authorization

server and the user’s wireless device.”

Element (f )—user inputs secure identi f ier .

A “putative secure identifier” is defined as “a secure identifier that is offered

in response to an IVR,” and “secure identifier” is defined to include PINs. ’648

Patent at 2:44–55. Law discloses a user input PIN in response to the authorization

request.

(f) inputting by the user

a putative secure

identifier;

“[0049] ….The user will have the opportunity to input

the response through the wireless device and be able to

provide [input] a PIN or personal digital signature

[secure identifier] (Block 78).”

Element (g) – a response to the request is sent thr ough the communications link.

Law discloses sending the PIN through an encrypted secure channel. Law at

¶49.

(g) sending

through the

communications

link opened atStep (d) a

response to the

IVR of Step (e);

“[0040] . . . The wireless device can also use SMS to return

the message back to the authorization server. . . .”

“[0049] . . . The PIN or digital signature along with theappropriate response parameters are sent back to the

authorization server through an encrypted secure channel

[communication link] via the wireless network.”


25/64

IPR2016–00836

U.S. Patent 8,285,648

21

Element (h)—retrieving the bona fide secure identifier stored during pre–

enrolling.

Law discloses verifying the security credentials (PIN) of the user upon

receiving the user response, which one of skill in the art would recognize as

requiring the PIN be “retrieved” from the database in which it was stored. Gray

Decl. (EX1008) at ¶ 48.

(h) retrieving

the bona fide

secure

identifier stored

at Step (a2);

“[0049] …. Upon receiving the response from the wireless

device, the authorization server 24 will check if the response was

received within a specified timeout period (Block 80) and verify

[retrieve] the security credentials [secure identifier] of the user

and the wireless device (Block 82).”

Elements (i ) & (j )—comparing received and stored secure identi f iers and

author izing the transaction i f they match.

Law discloses comparing the putative secure identifier (PIN entered by the

user) with the bona fide secure identifier (previously assigned and stored PIN) and

allowing the transaction to proceed only if the comparison results in a match. Law

at ¶47, 50.

(i) comparing the

putative secure

identifier input at

Step (f) with the

bona fide secure

identifier

“[0050] Upon receiving the response from the wireless device,

the authorization server 24 will check if the response was

received within a specified timeout period (Block 80) and

verify [comparing] the security credentials of the user and the

wireless device (Block 82). ….If the correct security credentials

are provided, the specified instructions [transaction approval]


26/64

IPR2016–00836

U.S. Patent 8,285,648

22

retrieved at Step

(h); and, (j)

allowing the

transaction to

proceed only if

the comparison

of Step (i) results

in a match

between the

putative secure

identifier and the

bona fide secureidentifier.

within the user’s response will be executed by the authorization

server. An appropriate response will be sent back to the third

party (Block 64). Additional processing by the third party may

be required to complete the transaction [allowing transaction to

proceed] . . . .”

“[0047] . . . This will allow the user to receive instant

notification and provide time critical instructions to either

authorize or deny the third party's request. ….The approval

response will be processed [allow transaction to proceed] by

the authorization server and the appropriate actions taken. Then

an acknowledgement is sent back to the third party by theauthorization server to complete the transaction.”

3.

Claim 2 is obvious in view of Law

Claim 2 is simply a system version of method claims 1 and 5, without the

pre–enrolling steps, and is invalid for the same reasons. Elements a–f simply set

forth the verifier database and computer, verifier and user communication devices

(Rx/Tx), a user device I/O and a user computer. Element f, sub–elements i)–vi) are

the same steps set forth in elements e)–j) of claim 1, with slightly different wording

and details that are inherent, common knowledge and obvious design choices in the

steps of claim 1, such as displaying the request on the user I/O device.

Law discloses the element (a.) “verifier database” as shown above in claim

1, element a(2). The “verifier-computer” of element (b.) was shown in claim 1 as

authorization server 24. Element (c.) is “a first verifier communications device


27/64

IPR2016–00836

U.S. Patent 8,285,648

23

(2403)” which is shown as “Tx/Rx” in Fig. 6 of the ’648 Patent which also defines

“communications device” to include “communications devices of any nature linked

in a communications system.” ’648 Patent (EX1001) at 2:21–27. Law discloses

the communications device in the form of a “wireless gateway,” which “bridges

the authorization server [the verifier] with the wireless network,” with the network

connecting with the user wireless device. Law at ¶40.

The element (d.) “user communications device (2303)” is shown in Fig. 3 of

the ’648 Patent as “cell phone 2303.” ’648 Patent 9:58–62. Law discloses a user

cell phone as shown above in claim 1, element (b), as a “wireless device.” The

Law “wireless device” is used for communicating with the verifier as shown in the

chart below. The element (e) “input/output (I/O) (503)” is simply a mobile phone

I/O, or display screen with inputs. The I/O device of the ’648 Patent is described as

being the standard input/output components of a conventional cell phone. ’648

Patent at 8:51–52 (“customer enters a putative password into the I/O device of her

mobile phone”); 9:17–20 (“local software in the customer’s phone . . . displays the

messages on the phone’s I/O device”); 9:58–62. Law teaches displaying the

request to the user and receiving a user input, which one of skill in the art would

understand to mean an interactive touch screen display and/or buttons. Law at ¶63.


28/64


29/64

IPR2016–00836

U.S. Patent 8,285,648

25

identifier from the database, and allowing the transaction to proceed upon a match.

This is shown above in claim 1 elements (h) and (i).


A system for verifying the

identity of a user by a verifier

during the course of an electronic

transaction, said system

comprising:

See claim 1 above, preamble.

a. a verifier-database (703); See claim 1, element a(2)

b. a verifier-computer (903),

wherein said verifier–computer

is adapted to write data to and

retrieve data from said verifier-

database;

See claim 1 authorization server 24 [verifier–

computer].

c. a first verifier communications

device (2403) for receiving

communications from the user

and transmitting communications

to the user, wherein said first

verifier communications device

is accessible to said verifier-

computer;

“The wireless gateway 30 [verifier

communications device] is an entity that

bridges the authorization server with the

wireless network 36. It translates

communication requests and information onto

wireless network protocols that can be relayed

to the wireless device.” Id . at ¶40.

d. a user communications device

(2303) for receiving

communications from the

verifier and transmitting

communications to the verifier,wherein said user

communications device is

accessible to the user;

“The wireless device 38 [user communication

device] is an entity which has the ability to

notify users of authorization requests and also

provide an interface for the user to respond to

the authorization request. The wireless device38 must be computationally capable of creating

an encrypted secure connection within a

reasonable time. The wireless device must also

be able to store an application that will process

the request [communications from/to] from the

authorization server [verifier].” Id . at ¶41.


30/64

IPR2016–00836

U.S. Patent 8,285,648

26

e. an input/output (I/O) (503)

device that accepts input from

the user and displays output to

the user; and,

“Upon receiving the request, the wireless

device 38 will notify the user and automatically

display [I/O] the request for the user. The user

will have the opportunity to input [I/O] the

response through the wireless device and be

able to provide a PIN or personal digital

signature (Block 78).” Id . at ¶63.

f. a user–computer (603) coupled

to said user communication

device and coupled to said I/O

device, wherein said user

computer is adapted to:

“The wireless device 38 must be

computationally capable [user–computer] of

creating an encrypted secure connection within

a reasonable time. The wireless device must

also be able to store an application that will process [user–computer] the request from the

authorization server.” Id . at ¶41.

i) display on said I/O device an

incoming identity verification

request (IVR) sent to said user

communications device by the

verifier computer through said

verifier communications device;

“The request will travel through an encrypted

secure channel connecting the authorization

server [verifier computer] and the user’s

wireless device [through said verifier

communications device]. . . . Upon receiving

the request, the wireless device will notify the

user and automatically display the request forthe user.” Id . at ¶49.

ii) acquire the user’s input to said

I/O device, wherein the user’s

input includes a putative secure

identifier; and,

“The user will have the opportunity to input

the response through the wireless device and

be able to provide a PIN or personal digital

signature [putative secure identifier] (Block

78).” Id . at ¶49.

iii) send a response to the IVR

from said user communications

device to said first verifiercommunications device,

“The PIN or digital signature along with the

appropriate response parameters are sent back

to the authorization server [verifier] throughan encrypted secure channel via the wireless

network.” Id . at ¶49.

wherein at least one of said user–

computer and said verifier–

Computer is adapted to:

iv) receive as a first input a bona

See claim 1 elements (h) and (i).

“Upon receiving the response from the wireless

device, the authorization server 24 will check if

the response was received within a specified


31/64

IPR2016–00836

U.S. Patent 8,285,648

27

fide secure identifier retrieved

from said verifier–database;

v) receive as a second input the

putative secure identifier; and,

vi) compare the first input with

the second input; wherein the

electronic transaction proceeds if

the first input and second input

match.

timeout period (Block 80) and verify [compare]

the security credentials of the user [bona fide

secure identifier] and the wireless device

(Block 82)…..If the correct security credentials

are provided [putative secure identifier], the

specified instructions [transaction approval]

within the user’s response will be executed by

the authorization server. An appropriate

response will be sent back to the third party to

complete the transaction [transaction

approval] (Block 64).” Id . at ¶50.

In the Verify Smart v. Bank of America litigation, Patent Owner discussed

Law briefly with respect to Claim 2, noting that the same argument applies to

independent Claim 5 (EX1007 at 2):

Law does not teach at least using the same user

communications device both to receive an incoming identityverification request (IVR), e.g., the SafePass® code [Bank of

America’s product accused of infringement in the litigation] sent via

SMS from the verifier, and to then transmit the putative secure

identifier, e.g., the user copied SafePass® code via SMS, back to the

verifier that originally sent it.

This difference is not a matter of mere design choice, in

that it represents a non–obvious distinction in architecture and

security philosophy, underlying a different inventive concept. For

example, unlike Law, the ’648 patent in suit does not “create a secure

authorization from the user in response to the third party request”,


32/64

IPR2016–00836

U.S. Patent 8,285,648

28

rather it is the third party, i.e., the bank, that creates the secure

authorization.

Verify Smart Response to Invalidity Contentions (EX1007) at 5. The first

paragraph is incorrect. Law explicitly teaches that the same user communications

device (called a “wireless device”) both receives an incoming IVR and transmits

the putative secure identifier back to the verifier that sent the IVR:

The wireless device 38 [user communications device] is an entity

which has the ability to notify users of author ization requests [I VR]

and also provide an interface for the user to respond to the

authorization request [ response including putati ve secure identif ier ] .

. . . The wireless device must also be able to store an application that

will process the request [ I VR] from the authorization server. This

wireless application will be responsible for setting up the secure

connection 32, securely storing certificates/encryption keys,

displaying the request [I VR] , accepting and creating the response

[response including putative secure identi f ier ] .

Law (EX1003) at ¶41 (emphasis added). The second paragraph is also incorrect,

suggesting that in Law the user, rather than a bank, does the authorization. Claim 2

doesn’t specify who does the authorization, but claims 1 and 5 imply it is the

verifier, since the comparison is done after the response from the user. This

comment appears directed to Law specifying that the user response includes


33/64


34/64

IPR2016–00836

U.S. Patent 8,285,648

30

5.


Claim 6 depends from Claim 5 and recites the user response (Step h)

includes the putative secure identifier input by the user (Step g), and wherein the

comparison to the bona fide secure identifier (Step k) is performed by the verifier.

As shown above in claim 1, elements f and g, Law discloses the user response

including a PIN [putative secure identifier] is sent to the verifier, and is thus

received. Claim 1 above, elements i and j, showed that the authentication server

[verifier] does the comparison to the bona fide secure identifier.

Claim 6 Law

6. The method of claim 5 wherein the response received at

Step (h) includes the putative secure identifier input at Step

(g), and wherein Step (k) is performed by the verifier.

See Claim 1

elements f, g, i and j.

6.


Claim 7 depends from Claim 5 and adds “downloading local software to the

user communications device.” According to the ’648 Patent, “downloading local

software” can be done through a “number of . . . techniques [that] will be obvious

to those skilled in the art.” ’648 Patent (EX1001) at 11:28–32. Examples include

downloading the software to a chip provided by the verifier or downloading to a

dedicated device at the time of manufacture. Id . at 11:32–36. Law states that the

wireless device (the “user communications device”) “must also be able to store an


35/64

IPR2016–00836

U.S. Patent 8,285,648

31

application” and “proprietary software” that performs various functions described

in Law. Law (EX1003) at ¶¶41, 70. One of ordinary skill in the art would know

that this application/software was necessarily “downloaded” prior to use, since

“downloaded” can include installation at manufacture as set forth under Claim

Construction above. See Gray Decl. (EX1008) at ¶ 51.

Claim 7 Law (emphasis added)7. The method of

claim 5 further

comprising the step

of: (m) downloading

local software to the

user communications

device.

“The wireless device must also be able to store an

application [downloading local software] that will process

the request from the authorization server.” Id . at ¶41.

“On the wireless device 38, proprietary software is used to

send/receive messages to/from the authorization server.”

Id . at ¶70.

7.


Claim 9 depends from Claim 7 and recites that the downloaded software

performs either sending the response received at Step (h) or comparing (Step k).

Law discloses that the local downloaded software sends the response. Law

(EX1003) at ¶70. These messages include the response to the IVR. See Id . ¶41.


9. The method of claim 7

wherein the local

software downloaded at

Step (m) performs at

least one of: (i) sending

“The wireless device must also be able to store an

application [software downloaded] that will process

the request [sending the response] from the



36/64

IPR2016–00836

U.S. Patent 8,285,648

32

the response received at

Step (h) and, (ii) Step

(k).

“On the wireless device 38, proprietary software

[downloaded software] is used tosend/receivemessages [sending the response] to/from the


8.


Claim 10 depends from Claim 7 and recites that the downloaded software

receives, formats and displays the IVR (verification request). Law teaches that the

stored application will “process the request,” and performs “displaying the

request.” Law (EX1003) at ¶41. One of ordinary skill in the art would understand

this “processing” and “displaying” of the request to necessarily refer to and include

“formatting” the request for display. The ’648 Patent simply says the IVR is

formatted for display, without describing how it is formatted. See, e.g., ’648 Patent

at 8:38–39. Any message must be formatted for display, as was commonly known

prior to the priority date of the ’648 Patent. Gray Decl. (EX1008) at ¶ 52.


10. The method of claim 7 wherein

the local software downloaded at

Step (m) performs the steps of:

(n) receiving the IVR sent at Step (f);(o) formatting the IVR for display;

and,

(p) displaying the IVR formatted at

Step (o) on an input/output (I/O)

device of the user communications

device.

See Claim 9.

“The wireless device must also be able to

store an application [softwaredownloaded] that will process the request

[receiving the IVR] from the authorization

server. This wireless application will be

responsible for setting up the secure

connection 32, securely storing

certificates/encryption keys, displaying the


37/64

IPR2016–00836

U.S. Patent 8,285,648

33

request, accepting and creating the

response.” Id . at ¶41.

9. Claims 11 and 12 are obvious in view of Law

Claim 11 depends from Claim 7 and additionally requires the local

downloaded software to perform either decryption or encryption. Claim 12

depends from Claim 5 and adds that either the IVR (verification request) or the

response is encrypted. Law discloses that the local software stores

encryption/decryption keys and that a secure encrypted channel is used. One of

skill in the art would recognize that this means encryption/decryption is performed

and that the request and response are encrypted. Law (EX1003) at ¶49. See Gray

Decl. (EX1008) at ¶ 53.


11. The method of claim 7

wherein the local software

downloaded at Step (m)

performs at least one of:

(i) decrypting information

received by the user

communications device, and

(ii) encrypting information sent by the user communications

device.

“The wireless device 38 must be

computationally capable of creating an

encrypted secure connection within a reasonable

time. The wireless device must also be able to

store an application that will process the request

from the authorization server. This wireless

application will be responsible for setting up the

secure connection 32, securely storingcertificates/encryption keys, displaying the

request, accepting and creating the response.”

Id . at ¶41.


38/64

IPR2016–00836

U.S. Patent 8,285,648

34


12. The methodof claim 5

wherein at least

one of the IVR

of Step (f) and

the response

received at

Step (h) are

encrypted when

sent.

“However if no valid pre–authorization exists, the server willsend out an authorization request to the user’s wireless device

(Block 74) and start monitoring the response time from the user

(Block 76). The request [IVR] will travel through an encrypted

secure channel connecting the authorization server and the

user’s wireless device. ….The user will have the opportunity to

input the response through the wireless device and be able to

provide a PIN or personal digital signature (Block 78). . . . The

PIN or digital signature [response] along with the appropriate

response parameters are sent back to the authorization server

through an encrypted secure channel via the wireless network.” Id . at ¶49.

10. Claim 13 is obvious in view of Law

Claim 13 depends from claim 5 and adds that the authorization comprises sending

a request to the user, receiving a response, and allowing the transaction if the

response is to authorize. Law shows all these elements as set forth above under

claim 1, elements (e)–(j).

11. Claims 14 and 15 are obvious in view of Law

Claim 15 depends from claim 5 and adds setting a flag on the user’s account

in the database indicating whether transaction authorization is to be performed.

Claim 14 is similar, but depends from claim 13. Law describes pre–authorization

instructions which prevent querying the user for transaction authorization, but if

not present or expired, the real time authorization request is sent. Law at ¶44, 46.

In other words, the existence of preauthorization that is not expired prevents


39/64

IPR2016–00836

U.S. Patent 8,285,648

35

querying the user for authorization. Such existence must be indicated in a

database. One of skill in the art would recognize that the preauthorization would

be stored with the account information in a database, and would constitute a flag.

See Gray Decl. (EX1008) at ¶ 54.


15. The method of claim

5 further comprising thestep of: (u) setting a flag

in a database record,

wherein the flag is

associated with an

account of the user and

wherein the flag

indicates whether or not

transaction

authorization is to be

performed.

“The authorization server will verify the user W's PIN

and other security credentials (Block 54). If theinformation is correct, the set of pre–authorization

information will be stored [database record] by the

authorization server or by an alternative database server

(Block 56).” Id . at ¶44.

“[0046] Alternatively, if the pre–authorized instructions

do not match or the instructions have expired [flag], the

request can either be denied or the real–time (Block 66)

and/or post–authorization models (Block 68) can be

executed.” Id . at ¶46.

12.


Claim 16 depends on claim 5 and adds acquiring user account information

access information, and storing it where is accessible to the verifier. The ’648

Patent describes:

In this embodiment, during the pre–enrollment phase the user

provides the verifier with account access information and a standing


40/64

IPR2016–00836

U.S. Patent 8,285,648

36

authorization to access one or more of the accounts––a VISA.RTM.D

credit–card account in this example.

’648 Patent at 14:31–34. The ’648 Patent later describes that this account access

can be used to communicate with the card issuer to verify “whether the user's

account has sufficient credit available to meet the transaction.” Id . at 15:60–62.

Law shows the account information stored in an authorization server database and

used to determine if there are sufficient funds in the account. Id . at ¶39, 42, 45.


16. The

method of

claim 5 further

comprising the

steps of: (v)

acquiringaccess

information

for an account

of the user;

and, (w)

storing the

account access

information on

a database that

is accessible tothe verifier.

“[0039] The authorization server 24 includes a database 26 which

stores the account information of the users they serve. The

account information is used to associate the third party request

with a particular user and their wireless device.”

“[0042] There are three authorization models that can be used bythe user and their wireless device to allow a third party to access

information and or complete a financial transaction.”

“[0045] When the third party initiates a transaction request (Block

58) through a wide access network (e.g., such as private networks,

public networks, local area networks, wireless networks, Internet

and/or a hybrid of these networks) to the authorization server,

then the authorization server pre–processes the request to

determine [access information] if it has the right criteria (Block

60). In the case of credit card authorization, the criteria couldinclude validity of the credit card number, sufficient funds in the

account, and possibility of non–fraudulent activities.”


41/64

IPR2016–00836

U.S. Patent 8,285,648

37

13.


Claim 19 depends from Claim 5 and recites verifying a device in addition to

the user. Claim 19 requires the verifier to store the device identifier, retrieve it,

compare it to an obtained identifier and allow the transaction to proceed upon a

match.

As noted above, a device identifier should be construed to include “device

identification information that can be used to identify a particular device.” Law

discloses the use of a “device password”/”Device key” or “client certificate” as

means for identifying and authenticating the wireless device (user communications

device) independent of the user PIN numbers (secure identifiers). Law (EX1003)

at ¶67. Because the “device password”/”Device key” or “client certificate” is a

data representation used to identify a device, it is a “device identifier” as required

by Claim 19. Law further describes the “device password”/”Device key” or “client

certificate” [device identifier] as being stored in a database accessible to the

authorization server [verifier]. Id . at ¶39. Law additionally describes separately

verifying the identity of the user and the identity of the user communication

device. Id . at ¶50.


42/64

IPR2016–00836

U.S. Patent 8,285,648

38


19. The method of claim5 further comprising the

steps of:

(dd) storing a device

identifier of the user

communications device

of Step (c) in a database

that is accessible to the

verifier,

(ee) retrieving the device

identifier stored at Step(dd);

(ff) obtaining the device

identifier of the user


of Step (e); and,

(gg) comparing the

device identifier

retrieved at Step (ee)

with the device identifierobtained at Step (ff);

wherein the transaction

is allowed to proceed

only if the comparison of

Step (gg) results in a

match between the

device identifier

retrieved at Step (ee) and

the device identifier

obtained at Step (ff).

“The authorization server 24 includes a database 26which stores the account information of the users they

serve. The authorization server will also include the

secure storage 28 of encryption keys and/or

certificates [device identifier] used to create a secure

connection with the wireless devices. Depending on

which authorization model used, the server must also

keep track of the global unique identifier (GUID) of the

wireless device in order to be able to contact it.” Id . at

¶39.

“Alternatively, another server can maintain the current

list [storing] of active wireless devices and their

identifiers.” Id . at ¶60.

“In using a public key encryption scheme such as

Transport Layer Security (TLS), the symmetric–key

mentioned in the previous section can be used as a

device password (Device key). This is necessary if the

wireless device 38 does not have its own certificate.

While the authentication server 24 can be authenticated

via its own certificate using the public and private keys,

the wireless device 38 should be authenticated with a

password scheme [comparison] if a client certificate is

not available on the device. Note that this is different

from user authentication which takes place with the

PIN. If the wireless device has a client certificate, then

the Device key system can be abandoned.” Id . at ¶67.

“Upon receiving the response from the wireless device,

the authorization server will check if the response was

received within a specified timeout period (Block 80)and verify the security credentials of the user and the

wireless device (Block 82) [comparison]. . . . If the

correct security credentials are provided [match], the

specified instructions within the user’s response will

be executed [transaction is allowed to proceed] by the



43/64

IPR2016–00836

U.S. Patent 8,285,648

39

B. Ground 2: Claims 1–3, 5–7, 9–16 and 19 are obvious over Blonder in

view of Weller.

1. Blonder

Blonder describes:

An automated method for alerting a customer that a transaction is

being initiated and for authorizing the transaction based on a

confirmation/approval by the customer thereto. …A preferred method

of alerting the customer and receiving a confirmation to authorize the

transaction back from the customer is illustratively afforded by

conventional two–way pagers.

Blonder at Abstract. Fig. 3 of Blonder copied below shows the user profile.

2. Weller

Weller , assigned to Visa, is well summarized in the Abstract:


44/64


45/64

IPR2016–00836

U.S. Patent 8,285,648

41

3.

Claims 1 And 5 are obvious over Blonder in view of Weller.

As per Ground 1, Claims 1 and 5 recite the same substantive method steps

except “pre-enrolling” missing from Claim 5, and thus only claim 1 is charted

below. Blonder describes, during a transaction, the cardholder providing a secret

code [putative secure identifier] that is matched against a similar code [bona fide

secure identifier] previously received [enrolled] from the cardholder. Blonder at

10:37–40. Blonder describes a “validation database” that accesses a user profile

(shown in Fig. 3) with a “communications field” with a phone number of a

cardholder. The phone number is used to contact the cardholder with an

authorization request, with the response containing the secret code. See Claim

chart below. While the database is described as doing various communications,

one of skill in the art would recognize that Blonder is referring to a server or

computer associated with the database. Blonder describes the database as

including a processor: “Validation database 106 is a processor-controlled

centralized database facility . . . “ Blonder at 8:33–34. Thus, Blonder shows all the

elements of claims 1 and 5. Blonder doesn’t explicitly describe pre-enrolling, but

one of skill in the art would recognize such pre-enrolling is necessary, and is what

is referred to when Bonder refers to a code “previously received.” Blonder at

10:37–40. Blonder also describes “a pre-stored profile specified by the principal


46/64

IPR2016–00836

U.S. Patent 8,285,648

42

[customer],” which one of skill in the art would understand to mean the customer

needs to register or pre-enroll to provide the profile. Blonder at 2:43–60. The

customer has “a profile specified by the customer” and authorization may be based

on “conditions pre-defined by the card owner,” which are further evidence of pre-

enrolling. Blonder at 3:15–26.

To the extent pre–enrolling isn’t clear from Blonder , it is clearly shown in

Weller . As shown in the claim chart below, Weller describes enrolling a user with a

credit card account, obtaining a password and an email.

It would be obvious to combine Blonder and Weller to add the phone

number and secret code of Blonder to the data enrolled by Weller . Both show

systems for authorizing a transaction in real time by contacting the cardholder and

obtaining a code or password in response in order to authorize the transaction. The

Blonder information is additional user data that would be obvious to add, since it is

needed to later contact the user device and is a detail needed to implement Weller .

See Gray Decl. (EX1008) at ¶ 55–57.

Any elements of Blonder or Weller not explicitly shown in the quoted

language below are inherent in how one of skill in the art would understand their

teachings, or are common knowledge or an obvious design choice for one of skill

in the art. See Gray Decl. ¶ 58 (EX1008). Certain minor features of the dependent


47/64

IPR2016–00836

U.S. Patent 8,285,648

43

claims are similarly obvious as described in more detail below, also based on being

inherent, common knowledge, obvious design choice and meeting the KSR criteria

as described above.

Claim 1 Blonder and Weller (emphasis added)

1. A user identity

verification method for

verifying the identity of

a user by a verifier inthe course of an

electronic transaction,

said user identity

verification method

comprising the steps of:

“An automated method for alerting a customer that a

transaction is being initiated and for authorizing the

transaction based on a confirmation/approval by the

customer thereto.” Blonder, Abstract

“A payment authentication service [verifier]

authenticates [verifying] the identity of a payer during

[in the course of] online transactions.” Weller ,

Abstract.

(a) pre–enrolling the

user, comprising the steps

of: (a1) assigning to the

user a bona fide secure

identifier; and,

“Optionally, the cardholder may be required to provide

a secret code that matches a similar code [bona fide

secure identifier] included in the response received

from the card owner before [pre–enrolling] the

transaction is authorized.” Blonder at 10:37–40.

“FIG. 2 illustrates the process through which a

cardholder registers with PAS according to one

embodiment of the present invention. As shown in

step 1, cardholders visit an enrollment server Internet

web site …. Additional information may also be

entered by the consumer at this point. For instance,

address, e–mail address, shopper identification, anaccount verification value, cardholder–specific

password [bona fide secure identifier], and issuer–

specific authentication information may also be

entered by the cardholder.” Weller at 8:1–16.


48/64

IPR2016–00836

U.S. Patent 8,285,648

44

(a2) storing the bona fide

secure identifier in a

database that is

accessible to the verifier;

“Validation database 106 [verifier]is a processor–

controlled centralized database facility which is a

repository of records or profiles for all credit/debit

card numbers assigned by a card issuer to its

customers. Validation database 106 is designed to

authorize transactions charged to card numbers stored

therein. Such authorization may be based on a set of

pre-defined parameters included in the profiles [bona fide secure identifier] associated with the card

numbers.” Blonder at 5:33–40.

“FIG. 2 illustrates the process through which acardholder registers with PAS [verifier] . . . This

information can be entered in a page [storing] at the

enrollment web site such as page 300 shown in FIG.

3.” Weller at 8:1–16.

“To begin with, a high–level description of the

authentication process used by the Payer

Authentication Service (PAS) will be provided.”

Weller at 3:65–67. b) pre–enrolling a user

communications device,

wherein pre–enrolling the

user communications

device comprises the

steps of:

(b1) obtaining a user

access number for the

user communications

device, wherein the useraccess number can be

used to open a

communications link with

the user communications

device; and,

(b2) storing the user

“Upon receiving a validation request message,

validation database 106 uses card number 201 as a

search key to perform a table look–up operation for

the purpose of retrieving the profile associated with

the card number. When the cardholder is a minor, and

the card is a stored–value smartcard, a passphrase or

proxy information provided by the minor may be used

as search key to retrieve the profile of FIG. 3.”

Blonder at 5:25–31.

“Shown in FIG. 3 is an illustrative table that

associates alerting and approval threshold parameters

to credit card numbers. . . . The table of FIG. 3

includes a cardholder's name field 301; a card number

field 302; alert and authorization flags 303 and 304,

respectively; a trigger group of fields; a


49/64

IPR2016–00836

U.S. Patent 8,285,648

45

access number in a

database that is accessible

to the verifier;

communications address field 307 [access number]; .

. . . Blonder at 5:48–56.

“Whenever a card owner is to be notified of a

condition–breaching credit card transaction, the

communications address field 308 may be used to

identify a telephone number or an electronic mail

address [access number] at which the card owner can

be reached.” Blonder at 6:50–54.

(c) retrieving the user

access number stored at

Step (b2);

“When a profile stores alerting parameters that may

require communications with one or more called

parties, validation database 106 uses one of theAutomatic Dialing Units (ADU) 110–1 to 110–N to

dial a telephone number [access number] retrieved

from a profile associated with a card number.”

Blonder at 5:43–48.

(d) opening a

communications link between the verifier and

the user

communications device by using the user access

number retrieved at Step

(c);

“. . . validation database 106 [verifier] uses one of the

Automatic Dialing Units (ADU) 110–1 to 110–N to

dial [opening a communications link] a telephone

number [access number] retrieved from a profile

associated with a card number.” Blonder at 5:43–48.

(e) sending an identity

verification request

(IVR) from the verifier to

the user through the

communications link

opened at Step (d);

“If so, validation database 106 [verifier] fetches the

communications address of the credit card owner and

any other appropriate information to format an

authorization request [IVR] and/or alert message

that is transmitted to the card owner.” Blonder at

7:28–32.

(f) inputting by the user a putative secure

identifier;

“Optionally, the cardholder may be required to provide[input] a secret code [putative secure identifier] that

matches a similar code [bona fide secure identifier]

included in the response received from the card owner

before the transaction is authorized.” Blonder at

10:37–40.


50/64

IPR2016–00836

U.S. Patent 8,285,648

46

(g) sending through the

communications link

opened at Step (d) a

response to the IVR of

Step (e);

“When validation database 106 receives a response

[sending] from the card owner . . . . Optionally, the

cardholder may be required to provide [sending] a

secret code [response] that matches a similar code

included in the response received from the card owner

before the transaction is authorized.” Blonder at

10:37–40.

(h) retrieving the bona

fide secure identifier

stored at Step (a2);


a secret code that matches a similar code [bona fide

secure identifier] included in the response received

from the card owner before the transaction is

authorized [retrieving].” Blonder at 10:37–40.(i) comparing the putative

secure identifier input at

Step (f) with the bona fide

secure identifier retrieved

at Step (h); and, (j)

allowing the transaction

to proceed only if the

comparison of Step (i)

results in a match between the putative

secure identifier and the

bona fide secure

identifier.


a secret code [putative secure identifier] that matches

[comparing] a similar code [bona fide secure

identifier] included in the response received from the

card owner before the transaction is authorized

[allowing transaction to proceed].” Blonder at 10:37–

40.

4. Claim 2 is obvious over Blonder in view of Weller.

Claim 2 is simply a system version of claims 1 and 5, without the pre–

enrolling steps, and is invalid for the same reasons. Elements a–f simply set forth

the verifier database and computer ( Blonder ’s verification database), verifier and

user communication devices ( Blonder ’s communication networks), a user device


51/64

IPR2016–00836

U.S. Patent 8,285,648

47

I/O (the keypad and display of Blonder ’s pager) and a user computer. One of skill

in the art would recognize a pager has a processor (user computer), and it would

also be obvious to substitute a cell phone, which the ’648 Patent says includes a

“user computer.” ’648 Patent at 9:58–62. Element f, sub-elements i) – vi) are the

same steps set forth in elements e) – j) of claim 1, with slightly different wording

and details that are inherent in the steps of claim 1, such as displaying the request

on the user I/O device. See Gray Decl. (EX1008) at ¶ 59.

Claim 2 Weller (emphasis added)

A system for verifying the

identity of a user by a

verifier during the course of

an electronic transaction,

said system comprising:

See claim 1 above, preamble.

a. a verifier-database (703); See claim 1, element a(2) b. a verifier-computer (903),

wherein said verifier-

computer is adapted to write

data to and retrieve data

from said verifier–database;

See claim 1.

“Validation database 106 is a processor–

controlled [verifier–computer] centralized database

facility … .” Blonder at 5:33–34.

c. a first verifier


(2403) for receiving

communications from theuser and transmitting

communications to the user,

wherein said first verifier


accessible to said verifier-

computer;

“When a profile stores alerting parameters that may

require communications with one or more called

parties, validation database 106 uses [transmitting

communications]one of the Automatic DialingUnits (ADU) [communications device] 110–1 to

110–N to dial a telephone number retrieved from a

profile associated with a card number.” Blonder at

5:43–48.

“The communications system of FIG. 1 includes a

communications network 102, a validation database


52/64

IPR2016–00836

U.S. Patent 8,285,648

48

106 and a paging system network 111.

Communications network 102 includes one or a

series of interconnected communications switches

[communication device] arranged to relay [receiving

communications] to validation database 106 (via

lines 130-1 to 130-N) information received from

card reader 101.” Blonder at 4:45–51.

d. a user communications

device (2303) for receiving

communications from the

verifier and transmitting

communications to theverifier, wherein said user


accessible to the user;

“The communications system of FIG. 1 includes a

communications network 102, a validation database

106 and a paging sys

unified patents inc. v. verify smart corp., ipr2016-00836 (petition)

Documents