You are on page 1of 64

IPR201600836

U.S. Patent 8,285,648

DOCKET NO.: 0981731006063


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 941113834
Tel: (415) 5760200
Email: phaughey@kilpatricktownsend.com
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) 8058931
Email: jonathan@unifiedpatents.com
UNITED STATES PATENT AND TRADEMARK OFFICE
____________________________________________
BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________________________________
UNIFIED PATENTS INC.
Petitioner
v.
VERIFY SMART CORP.
Patent Owner
IPR201600836
Patent 8,285,648
PETITION FOR INTER PARTES REVIEW OF
U.S. PATENT NO. 8,285,648
CHALLENGING CLAIMS 13, 57, 916 and 19
UNDER 35 U.S.C. 312 AND 37 C.F.R. 42.104

IPR201600836
U.S. Patent 8,285,648

TABLE OF CONTENTS
Mandatory Notices ...........................................................................................1

I.
A.

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

B.

Real PartyinInterest ...................................................................................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.

V.

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

A.

downloading local software or software downloaded ...........................8

B.

device identifier .........................................................................................9


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

A. Ground 1: Claims 13, 57, 916 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

4.

Claim 3 is obvious in view of Law ...........................................................29

5.

Claim 6 is obvious in view of Law ...........................................................30

6.

Claim 7 is obvious in view of Law ...........................................................30

IPR201600836
U.S. Patent 8,285,648

7.

Claim 9 is obvious in view of Law ...........................................................31

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

12.

Claim 16 is obvious in view of Law ......................................................35

13.

Claim 19 is obvious in view of Law ......................................................37

B. Ground 2: Claims 13, 57, 916 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

5.

Claim 3 is obvious over Blonder in view of Weller. ................................50

6.

Claim 6 is obvious over Blonder in view of Weller. ................................50

7.

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

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

ii

IPR201600836
U.S. Patent 8,285,648

LIST OF EXHIBITS
Exhibit
EX1001
EX1002
EX1003
EX1004
EX1005
EX1006
EX1007
EX1008
EX1009
EX1010
EX1011

Description
U.S. Patent No. 8,285,648 (the 648 Patent)
Unified Patents Inc.s Voluntary Interrogatories
U.S. Pub. 20050184145 to Law (Law)
U.S. Patent 7,827,115 to Weller et al. (Weller)
U.S. Pat. 5,708,422 to Blonder et al. (Blonder)
U.S. Pat. 7,606,560 to Labrou (Labrou)
Verify Smart Corp.s Response to Invalidity Contentions
Declaration of Stephen Gray
U.S. Pat. 8,572,391 to Golan (Golan)
PTO Assignment database record for the 648 Patent
Verify Smart v. Basecamp complaint

iii

IPR201600836
U.S. Patent 8,285,648

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-cv05117, dismissed), Bank of America, NA (NJD-2-15-cv-05348, dismissed),
Microsoft Corporation (NJD-2-15-cv-05596, dismissed), Apple Inc. (NJD-2-15-cv06207, 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).

IPR201600836
U.S. Patent 8,285,648

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 PartyinInterest
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 Unifieds
participation in this proceeding or the filing of this petition. In this regard, Unified
has submitted voluntary discovery. See EX1002 (Petitioners 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 phaughey@kilpatricktownsend.com

and jonathan@unifiedpatents.com, 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

IPR201600836
U.S. Patent 8,285,648

(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 13, 57, 916 and 19 of the 648 patent.

IPR201600836
U.S. Patent 8,285,648

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 13, 57, 916 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)),

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

America Invents Act (AIA). Accordingly, preAIA statutory framework applies.

IPR201600836
U.S. Patent 8,285,648

demonstrates that there is a reasonable likelihood that Petitioner will prevail with
respect to challenged claims 13, 57, 916 and 19. See 35 U.S.C. 314(a).

Ground
1
2

Proposed Statutory Rejections for the 648 Patent


Claims 13, 57, 916 and 19 are obvious under 35
U.S.C. 103(a) over Law (EX1003)
Claims 13, 57 and 916 are obvious under 35 U.S.C.
103(a) over Blonder (EX1004) in view of Weller
(EX1005).
Claim 19 is obvious under 35 U.S.C. 103(a) over
Blonder (EX1004) in view of Weller (EX1005) and
Labrou (EX1006).

VI.

Overview of the 648 Patent

C.

Priority date of the 648 Patent

Exhibit No.
EX1003
EX1004
EX1005
EX1004
EX1005
EX1006

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:2429;
6:5255; Fig. 1. When the user wishes to execute a financial transaction such as a
5

IPR201600836
U.S. Patent 8,285,648

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:3441; 8:1339. In
response, the user enters and sends a PIN or password (putative secure
identifier), Id. at 8:5157, 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:510.
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) 2025.
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

IPR201600836
U.S. Patent 8,285,648

mobile number as well as a PIN of the user are preenrolled 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 applicants 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.

IPR201600836
U.S. Patent 8,285,648

42.100(b): see also In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 127981
(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:102:55. Petitioner adopts those definitions for purposes
of this Petition. The following additional terms are construed (See Gray Decl.
(EX1008) 2734):
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


8

IPR201600836
U.S. Patent 8,285,648

art. 648 Patent (EX1001) at 11:2832. 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:3236. 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
preloading 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 doesnt use the term device identifier outside the claims,

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


Patent at 18:515. 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 usercomputer is
a laptop computer, PDA, or other computer instead of a mobile

IPR201600836
U.S. Patent 8,285,648

communications device, the serial number of the computers CPU can


be acquired by the verifier. 648 Patent (EX1001) at 7:613.
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 13, 57, 916 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 realtime authorization
model shown in Figure 3, in which a user is authenticated during a financial
10

IPR201600836
U.S. Patent 8,285,648

transaction. Id. at 47, Fig. 3. Figure 6 shows the pre-registration and a variation
of this realtime authorization model in which the authorization server initiates the
connection. Id. 2 at 6162, 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:5557; 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-ofsale 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 users 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

The 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.

11

IPR201600836
U.S. Patent 8,285,648

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.

12

IPR201600836
U.S. Patent 8,285,648

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 submethods (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 Laws described verifying the PIN of

13

IPR201600836
U.S. Patent 8,285,648

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) 4348. 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.
Preambleverifying user identity during 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.
14

IPR201600836
U.S. Patent 8,285,648

Claim 1
1. A user identity
verification 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:

Law (emphasis added)


[0023] The realtime authorization model . The
transaction 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-enrolling user with bona fide secure identifier


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:4455.
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

15

IPR201600836
U.S. Patent 8,285,648

for an authorizing response. The 648 Patent does not describe how the bona fide
secure identifier is assigned to the user or who makes this assignment. This
limitation would be understood by one of skill in the art to include designation by
the issuing bank or selection by the user, since those are common practices. For a
PIN, a bank or financial institution will typically assign a PIN to a user, but allow
the user to change it. This practice existed many years before the priority date of
the 648 Patent. See Gray Decl. (EX1008) 45.
(a) preenrolling the
user, comprising the
steps of: (a1)
assigning to the user
a bona fide secure
identifier; and,

[0065] . . . before the authorization begins, the user


registers [preenrolling] its GUID with the authorization
server.
[0066] . . . The user will also enter a PIN [bona fide
secure identifier] to authenticate himself or herself to the
authorization server.

Element (a2)storing the bona fide secure identifier in a verifier database


Law teaches the use of a database that is accessible to the authorization
server of the issuing bank (the verifier).

This database stores user account

information, which necessarily includes the PIN (bona fide secure identifier) since
Law later describes verification of a user input PIN, which requires a stored PIN to
compare it to. See Law (EX1003) 4950. See Gray Decl. _.

16

IPR201600836
U.S. Patent 8,285,648

(a2) storing the bona fide


secure identifier in a
database that is accessible
to the verifier;

[0039] The authorization server 24 [verifier]


includes [accessible] a database 26 which stores the
account information [secure identifier] of the users
they serve.

Element (b) preenrolling a user communications device with a user access


number (for a communication link with the device) stored in a verifier 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:2133. An example of a user
access number given in the 648 Patent is a users cell phone number, which may
be used to call the phone or send text messages. Id. at 6:6066.
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 users communications device and the
verifier. 648 Patent at 10:24. The Law GUID is used to contact the wireless
device, and thus opens a communications link.

Law at 38.

The GUID is

preregistered (preenrolling), which one of skill in the art would recognize as

17

IPR201600836
U.S. Patent 8,285,648

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


server.
b) preenrolling a user
communications device,
wherein preenrolling the
user communications
device comprises the
steps of:
(b1) obtaining a user
access 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 a
database that is accessible
to the verifier;

[0065] before the authorization begins, the user


registers [preenrolling] 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 preregistered [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) retrieving the user access number


Law teaches looking up (retrieving) the GUID (access number). Law at 62.
(c) retrieving
the user access
number stored
at Step (b2);

[0062] However, if no valid preauthorization exists, the


authorization 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).

18

IPR201600836
U.S. Patent 8,285,648

Element (d) verifier 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:6612: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 preauthorization


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) verifier sends identity verification request (IVR) to user through
communications link.
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 users identity. 648 Patent at 2:4143. Law teaches that the server will send
out an authorization request to the users 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 preauthorization exists,


the server [verifier] will send out an authorization
request [verification request] to the users wireless
device [user] (Block 74) and start monitoring the
response time from the user (Block 76). The request
19

IPR201600836
U.S. Patent 8,285,648

opened at Step (d);

will travel through an encrypted secure channel


[communications link] connecting the authorization
server and the users wireless device.

Element (f)user inputs secure identifier.


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:4455. 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 through the communications link.
Law discloses sending the PIN through an encrypted secure channel. Law at
49.
(g) sending
through the
communications
link opened at
Step (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 the
appropriate response parameters are sent back to the
authorization server through an encrypted secure channel
[communication link] via the wireless network.

20

IPR201600836
U.S. Patent 8,285,648

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 identifiers and
authorizing the transaction if 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]

21

IPR201600836
U.S. Patent 8,285,648

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.
3.

within the users 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 the
authorization server to complete the transaction.

Claim 2 is obvious in view of Law


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

preenrolling steps, and is invalid for the same reasons. Elements af 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, subelements 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

22

IPR201600836
U.S. Patent 8,285,648

(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:2127. 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:5862. 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:5152 (customer enters a putative password into the I/O device of her
mobile phone); 9:1720 (local software in the customers phone . . . displays the
messages on the phones I/O device); 9:5862.

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.

23

IPR201600836
U.S. Patent 8,285,648

Law describes a smart phone, which was understood to include a touch screen
display and/or buttons. Law at 41. See Gray Decl. (EX1008) at 49.
The usercomputer (603) of element (f) is described in the 648 Patent as
the standard computing processor of a conventional cell phone:
A customer 103 has a communications device such as cell phone
2303 . . . comprising a wireless transceiver 403, local software is run
by a usercomputer 603, and an I/O device 503 for interfacing the
mobile communications with the customer.
648 Patent 9:5862, Fig. 3. Law describes a mobile phone which one of skill in
the art would understand to include a processor. Also, Law describes the mobile
phone will process the request. See Gray Decl. at 50.
The subelements of element (f.) correspond to the steps shown in claim 1
above. Element i) requires display on said I/O device an incoming identity
verification request (IVR). Claim 1 showed the sending of the request (element
e), and the chart below shows this is displayed to the user. Id at 63. Element ii)
says the user enters the putative secure identifier, shown above in claim 1 element
(f) and below. Element iii) recites the response from the user to the verifier, shown
above in claim 1 element (g) and below. Elements iv) vi) recited the verifier
receiving the putative secure identifier, comparing it to the bona fide secure

24

IPR201600836
U.S. Patent 8,285,648

identifier from the database, and allowing the transaction to proceed upon a match.
This is shown above in claim 1 elements (h) and (i).
Claim 2
Law (emphasis added)
A system for verifying the
See claim 1 above, preamble.
identity of a user by a verifier
during the course of an electronic
transaction, said system
comprising:
a. a verifier-database (703);

See claim 1, element a(2)

b. a verifier-computer (903),
wherein said verifiercomputer
is adapted to write data to and
retrieve data from said verifierdatabase;
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 verifiercomputer;
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;

See claim 1 authorization server 24 [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.
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 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 [communications from/to] from the
authorization server [verifier]. Id. at 41.
25

IPR201600836
U.S. Patent 8,285,648

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 usercomputer (603) coupled The wireless device 38 must be
computationally capable [usercomputer] of
to said user communication
creating an encrypted secure connection within
device and coupled to said I/O
a reasonable time. The wireless device must
device, wherein said user
also be able to store an application that will
computer is adapted to:
process [usercomputer] the request from the
authorization server. Id. at 41.
The request will travel through an encrypted
i) display on said I/O device an
secure channel connecting the authorization
incoming identity verification
server [verifier computer] and the users
request (IVR) sent to said user
wireless device [through said verifier
communications device by the
communications device]. . . . Upon receiving
verifier computer through said
verifier communications device; the request, the wireless device will notify the
user and automatically display the request for
the user. Id. at 49.
ii) acquire the users input to said The user will have the opportunity to input
I/O device, wherein the users
the response through the wireless device and
input includes a putative secure
be able to provide a PIN or personal digital
identifier; and,
signature [putative secure identifier] (Block
78). Id. at 49.
iii) send a response to the IVR
from said user communications
device to said first verifier
communications device,

The PIN or digital signature along with the


appropriate response parameters are sent back
to the authorization server [verifier] through
an encrypted secure channel via the wireless
network. Id. at 49.
wherein at least one of said user See claim 1 elements (h) and (i).
computer and said verifier
Upon receiving the response from the wireless
Computer is adapted to:
device, the authorization server 24 will check if
iv) receive as a first input a bona the response was received within a specified
26

IPR201600836
U.S. Patent 8,285,648

fide secure identifier retrieved


from said verifierdatabase;
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 users 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 identity


verification request (IVR), e.g., the SafePass code [Bank of
Americas 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 nonobvious 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,

27

IPR201600836
U.S. Patent 8,285,648

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 authorization requests [IVR]
and also provide an interface for the user to respond to the
authorization request [response including putative secure identifier].
. . . The wireless device must also be able to store an application that
will process the request [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 request [IVR], accepting and creating the response


[response including putative secure identifier].
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
doesnt 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

28

IPR201600836
U.S. Patent 8,285,648

instructions to either authorize or deny the third party's request. Law at 47.
However, these claims dont mention authorization at all they simply say the
transaction is allowed to proceed if there is a match of the identifiers, and that is
clearly shown in Law above with respect to element (i) and (j) of claim 1 and
element (vi) of claim 5, where the authorization server of Law, not the user, does
the comparison and allows the transaction to proceed.
4.

Claim 3 is obvious in view of Law


Claim 3 depends from Claim 2 and recites that the user communications

device is a personal communications device defined in the 648 Patent as:


"Personal communications device" refers to a communications device sufficiently
small and mobile to be carried by a user, including, without limitation, cell phones,
PDA's, 648 Patent at 2:2730. Law describes such a cell phone. Law at 41.
Claim 3
The system of claim 2
wherein said user
communications device
is a personal
communications device.

Law (emphasis added)


Typically the wireless device [communications
device] is a mobile cellular phone [personal
communications device], a wirelessly enabled personal
digital assistant (PDA), and/or a mobile cellular
capable personal digital assistant such as a smart
phone. Id. at 41.

29

IPR201600836
U.S. Patent 8,285,648

5.

Claim 6 is obvious in view of Law


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
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.
6.

Law
See Claim 1
elements f, g, i and j.

Claim 7 is obvious in view of Law


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:2832. 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:3236. Law states that the
wireless device (the user communications device) must also be able to store an

30

IPR201600836
U.S. Patent 8,285,648

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
7. The method of
claim 5 further
comprising the step
of: (m) downloading
local software to the
user communications
device.
7.

Law (emphasis added)


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.

Claim 9 is obvious in view of Law


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.
Claim 9
9. The method of claim 7
wherein the local
software downloaded at
Step (m) performs at
least one of: (i) sending

Law (emphasis added)


The wireless device must also be able to store an
application [software downloaded] that will process
the request [sending the response] from the
authorization server. Id. at 41.

31

IPR201600836
U.S. Patent 8,285,648

the response received at


Step (h) and, (ii) Step
(k).

8.

On the wireless device 38, proprietary software


[downloaded software] is used to send/receive
messages [sending the response] to/from the
authorization server. Id. at 70.

Claim 10 is obvious in view of Law


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:3839. 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.
Claim 10
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.

Law (emphasis added)


See Claim 9.
The wireless device must also be able to
store
an
application
[software
downloaded] 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
32

IPR201600836
U.S. Patent 8,285,648

request, accepting and


response. Id. at 41.
9.

creating

the

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.
Claim 11
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.

Law (emphasis added)


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 storing
certificates/encryption keys, displaying the
request, accepting and creating the response.
Id. at 41.

33

IPR201600836
U.S. Patent 8,285,648

Claim 12
12. The method
of claim 5
wherein at least
one of the IVR
of Step (f) and
the response
received at
Step (h) are
encrypted when
sent.

10.

Law (emphasis added)


However if no valid preauthorization exists, the server will
send out an authorization request to the users 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
users 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.

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 users account

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


Claim 14 is similar, but depends from claim 13. Law describes preauthorization
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


34

IPR201600836
U.S. Patent 8,285,648

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.
Claim 15
15. The method of claim
5 further comprising the
step 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.

12.

Law (emphasis added)


The authorization server will verify the user W's PIN
and other security credentials (Block 54). If the
information is correct, the set of preauthorization
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 preauthorized instructions
do not match or the instructions have expired [flag], the
request can either be denied or the realtime (Block 66)
and/or postauthorization models (Block 68) can be
executed. Id. at 46.

Claim 16 is obvious in view of Law


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 preenrollment phase the user
provides the verifier with account access information and a standing

35

IPR201600836
U.S. Patent 8,285,648

authorization to access one or more of the accountsa VISA.RTM.D


creditcard account in this example.
648 Patent at 14:3134. 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:6062.
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.
Claim 16
16. The
method of
claim 5 further
comprising the
steps of: (v)
acquiring
access
information
for an account
of the user;
and, (w)
storing the
account access
information on
a database that
is accessible to
the verifier.

Law (emphasis added)


[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 by
the 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 preprocesses the request to
determine [access information] if it has the right criteria (Block
60). In the case of credit card authorization, the criteria could
include validity of the credit card number, sufficient funds in the
account, and possibility of nonfraudulent activities.

36

IPR201600836
U.S. Patent 8,285,648

13.

Claim 19 is obvious in view of Law


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.

37

IPR201600836
U.S. Patent 8,285,648

Claim 19
19. The method of claim
5 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
communications device
of Step (e); and,
(gg) comparing the
device identifier
retrieved at Step (ee)
with the device identifier
obtained 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).

Law (emphasis added)


The authorization server 24 includes a database 26
which 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 symmetrickey
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 users response will
be executed [transaction is allowed to proceed] by the
authorization server. Id. at 50.
38

IPR201600836
U.S. Patent 8,285,648

B.
Ground 2: Claims 13, 57, 916 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 twoway 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:
39

IPR201600836
U.S. Patent 8,285,648

One embodiment of the invention for authenticating the identity of a


cardholder during an online transaction involves querying an access
control server to determine if a cardholder is enrolled in the payment
authentication service, requests a password from the cardholder,
verifies the password, and notifies a merchant whether the
cardholder's authenticity has been verified. In another aspect of the
invention, a chip card and the authentication service independently
generate cryptograms that must match in order for the service to
verify that the correct chip card is being used by the cardholder.
Weller at Abstract.

Fig. 2 of Weller copied below illustrates the pre-

enrollment.

40

IPR201600836
U.S. Patent 8,285,648

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:3740. 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:3334. Thus, Blonder shows all the
elements of claims 1 and 5. Blonder doesnt 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:3740. Blonder also describes a pre-stored profile specified by the principal
41

IPR201600836
U.S. Patent 8,285,648

[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:4360. 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 preenrolling. Blonder at 3:1526.
To the extent preenrolling isnt 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 5557.
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
42

IPR201600836
U.S. Patent 8,285,648

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
1. A user identity
verification 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:

Blonder and Weller (emphasis added)


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) preenrolling 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 [preenrolling] the
transaction is authorized. Blonder at 10:3740.

A payment authentication service [verifier]


authenticates [verifying] the identity of a payer during
[in the course of] online transactions. Weller,
Abstract.

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, email address, shopper identification, an
account verification value, cardholderspecific
password [bona fide secure identifier], and issuer
specific authentication information may also be
entered by the cardholder. Weller at 8:116.

43

IPR201600836
U.S. Patent 8,285,648

(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:3340.
FIG. 2 illustrates the process through which a
cardholder 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:116.

To begin with, a highlevel description of the


authentication process used by the Payer
Authentication Service (PAS) will be provided.
Weller at 3:6567.
Upon receiving a validation request message,
b) preenrolling a user
validation database 106 uses card number 201 as a
communications device,
wherein preenrolling the search key to perform a table lookup operation for
the purpose of retrieving the profile associated with
user communications
the card number. When the cardholder is a minor, and
device comprises the
the card is a storedvalue smartcard, a passphrase or
steps of:
proxy information provided by the minor may be used
(b1) obtaining a user
as search key to retrieve the profile of FIG. 3.
access number for the
Blonder at 5:2531.
user communications
device, wherein the user
Shown in FIG. 3 is an illustrative table that
access number can be
associates alerting and approval threshold parameters
used to open a
communications link with to credit card numbers. . . . The table of FIG. 3
the user communications includes a cardholder's name field 301; a card number
field 302; alert and authorization flags 303 and 304,
device; and,
respectively; a trigger group of fields; a
(b2) storing the user
44

IPR201600836
U.S. Patent 8,285,648

access number in a
communications address field 307 [access number]; .
database that is accessible . . . Blonder at 5:4856.
to the verifier;
Whenever a card owner is to be notified of a
conditionbreaching 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:5054.
(c) retrieving the user
When a profile stores alerting parameters that may
access number stored at
require communications with one or more called
Step (b2);
parties, validation database 106 uses one of the
Automatic Dialing Units (ADU) 1101 to 110N to
dial a telephone number [access number] retrieved
from a profile associated with a card number.
Blonder at 5:4348.
. . . validation database 106 [verifier] uses one of the
(d) opening a
Automatic Dialing Units (ADU) 1101 to 110N to
communications link
between the verifier and dial [opening a communications link] a telephone
number [access number] retrieved from a profile
the user
communications device associated with a card number. Blonder at 5:4348.
by using the user access
number retrieved at Step
(c);
If so, validation database 106 [verifier] fetches the
(e) sending an identity
communications address of the credit card owner and
verification request
(IVR) from the verifier to any other appropriate information to format an
authorization request [IVR] and/or alert message
the user through the
that is transmitted to the card owner. Blonder at
communications link
7:2832.
opened at Step (d);
(f) inputting by the user a Optionally, the cardholder may be required to provide
putative secure
[input] a secret code [putative secure identifier] that
identifier;
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:3740.

45

IPR201600836
U.S. Patent 8,285,648

(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:3740.
(h) retrieving the bona
Optionally, the cardholder may be required to provide
fide secure identifier
a secret code that matches a similar code [bona fide
stored at Step (a2);
secure identifier] included in the response received
from the card owner before the transaction is
authorized [retrieving]. Blonder at 10:3740.
(i) comparing the putative Optionally, the cardholder may be required to provide
a secret code [putative secure identifier] that matches
secure identifier input at
Step (f) with the bona fide [comparing] a similar code [bona fide secure
secure identifier retrieved identifier] included in the response received from the
card owner before the transaction is authorized
at Step (h); and, (j)
[allowing transaction to proceed]. Blonder at 10:37
allowing the transaction
40.
to proceed only if the
comparison of Step (i)
results in a match
between the putative
secure identifier and the
bona fide secure
identifier.
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 af simply set forth
the verifier database and computer (Blonders verification database), verifier and
user communication devices (Blonders communication networks), a user device

46

IPR201600836
U.S. Patent 8,285,648

I/O (the keypad and display of Blonders 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:5862. 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
A system for verifying the
identity of a user by a
verifier during the course of
an electronic transaction,
said system comprising:
a. a verifier-database (703);
b. a verifier-computer (903),
wherein said verifiercomputer is adapted to write
data to and retrieve data
from said verifierdatabase;
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 verifiercomputer;

Weller (emphasis added)


See claim 1 above, preamble.

See claim 1, element a(2)


See claim 1.
Validation database 106 is a processor
controlled [verifiercomputer] centralized database
facility . Blonder at 5:3334.
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 Dialing
Units (ADU) [communications device] 1101 to
110N to dial a telephone number retrieved from a
profile associated with a card number. Blonder at
5:4348.
The communications system of FIG. 1 includes a
communications network 102, a validation database
47

IPR201600836
U.S. Patent 8,285,648

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;
e. an input/output (I/O)
(503) device that accepts
input from the user and
displays output to the user;
and,

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:

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:4551.
The communications system of FIG. 1 includes a
communications network 102, a validation database
106 and a paging system network 111.
Communications network 102 includes one or a
series of interconnected communications switches
[communications device] arranged to relay [sending
communications] to validation database 106 (via
lines 130-1 to 130-N) information received from
card reader 101. Blonder at 4:4551.
For example, a card owner may be prompted to
enter a "1" on a telephone dialpad [input/output] to
approve a transaction, or a "2" on the dialpad to
disapprove the transaction. Also included in IVRS
125 is a means to respond to touch-tone commands
from a caller. In particular, IVRS 125 is arranged to
translate the Dual Tone Multi-Frequency (DTMF)
signal received from the card owner to a machinereadable format, such as ASCII, that is recognizable
by validation database 106. Alternatively, IVRS 125
may include a word recognition unit that is arranged
to prompt a card owner for particular information
that is converted to ASCII format for delivery to
validation database 106. Blonder at 8:3341.
In addition, although the above embodiments
focused primarily on communication via wireless
paging devices (e.g., one-way or two-way pagers), it
will be obvious to those skilled in the art that many
other communications mechanisms may be used
instead of, or in addition to, wireless paging
devices. These mechanisms include, for example,
48

IPR201600836
U.S. Patent 8,285,648

cellular telephones, conventional wired telephones,


personal computers, etc. Blonder at 16:1522.
i) display on said I/O device When the incoming message is an alert signal from
validation database 106, pager 135 can be any
an incoming identity
commercially available paging device with a small
verification request (IVR)
screen for displaying the message of FIG. 4.
sent to said user
Blonder at 9:1114.
communications device by
the verifier computer
through said verifier
communications device;
See claim 1 element (f).
ii) acquire the users input
to said I/O device, wherein
the users input includes a
putative secure identifier;
and,
See claim 1 element (g).
iii) send a response to the
IVR from said user
communications device to
said first verifier
communications device,
wherein at least one of said See claim 1 elements (h) and (i).
usercomputer and said
verifierComputer is
adapted to:
iv) receive as a first input a
bona 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.
49

IPR201600836
U.S. Patent 8,285,648

5.

Claim 3 is obvious over Blonder in view of Weller.


Claim 3 depends from Claim 2 and recites that the user communications

device is a personal communications device defined in the 648 Patent as:


"Personal communications device" refers to a communications device sufficiently
small and mobile to be carried by a user, including, without limitation, cell phones,
PDA's, . . . pagers, beepers, and other personal devices having wireless transceiver
capabilities. 648 Patent at 2:2730, emphasis added. Blonder describes such a
pager : A preferred method of alerting the customer and receiving a confirmation
to authorize the transaction back from the customer is illustratively afforded by
conventional twoway pagers. Blonder at Abstract, 9:1114.
6.

Claim 6 is obvious over Blonder in view of Weller.


Claim 6 depends from Claim 5 and recites that 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, Blonder discloses the user response
including a secret code [putative secure identifier] is sent to the verifier, and thus
received. Claim 1 above, elements i and j, showed that the authorization database
[verifier] does the comparison to the bona fide secure identifier.

50

IPR201600836
U.S. Patent 8,285,648

7.

Claim 7 is obvious over Blonder in view of Weller.


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

user communications device. As noted under claim construction above, the 648
Patent uses this term to cover both initially installing at manufacture and later
downloading software. As construed under Claim Construction above, this means
loading software on a user communication device by any means. Accordingly, this
simply refers to the software on the device.
Weller describes: The second method involves the ACS dynamically
downloading the software onto the additional client device to be used by the
cardholder. Weller at 6:6365. Blonder describes substituting a cell phone or
computer for the pager. It would be obvious to use the downloaded software of
Weller on the pager or substitute computer or cell phone of Blonder. Also, it
would be obvious that the pager of Blonder, or a substitute cell phone, would have
software installed at the time of manufacture. See Gray Decl. (EX1008) at 60.
8.

Claim 9 is obvious over Blonder in view of Weller.


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).
As noted above, the software downloaded is simply the software on the device.

51

IPR201600836
U.S. Patent 8,285,648

Blonder discloses that the pager, and thus its software, sends the response.
Blonder at 9:1822.
Claim 9
9. The method of claim 7
wherein the local software
downloaded at Step (m)
performs at least one of: (i)
sending the response
received at Step (h) and, (ii)
Step (k).
9.

Blonder and Weller (emphasis added)


In that case, the card owner transmits an
approval/disapproval message [response] by
entering a pre-defined code in the two-way pager
[local software downloaded]. The pre-defined code
is then transmitted to validation database 106 via
paging system network 111. Blonder at 9:1822.

Claim 10 is obvious over Blonder in view of Weller.


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

receives, formats and displays the IVR (verification request). As noted above, the
software downloaded is simply the software on the device. Blonder teaches
receiving and displaying the message. Blonder at 9:1114. One of ordinary skill
in the art would understand that displaying the request necessarily includes
formatting the request for display, as discussed above with respect to Law. See
Gray Decl. (EX1008) at 61.
Claim 10
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,

52

Law (emphasis added)


See Claim 9.
When the incoming message is an
alert signal from validation
database 106, pager 135 can be

IPR201600836
U.S. Patent 8,285,648

(p) displaying the IVR formatted at Step (o)


on an input/output (I/O) device of the user
communications device.

10.

any commercially available paging


device with a small screen for
displaying the message of FIG. 4.
Blonder at 9:1114.

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


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. Weller describes using encryption for all the channels in the
transaction and approval process. Weller at 14:5915:13. Such use of encryption
was standard before the priority date of the 648 Patent. It would be obvious to
add the encryption of Weller to Blonder, or add the additional information of
Blonder to Weller as described above. One of skill in the art would be motivated
to combine the references to provide protection for sensitive financial data. See
Gray Decl. (EX1008) at 62.
Claim 11
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

Blonder and Weller (emphasis added)


The channel between the cardholder and the
ACS should be encrypted by the ACS by
using an SSL certificate obtained from a
service organizationapproved certificate
authority. . . . The channel between the ACS
to the cardholder should be encrypted to
protect the prompt for the cardholder's
password and the cardholder entered
53

IPR201600836
U.S. Patent 8,285,648

(ii) encrypting information sent by


the user communications device.

password. Weller at 14:5915:13.

Claim 12
12. The method of claim 5 wherein at least
one of the IVR of Step (f) and the response
received at Step (h) are encrypted when sent.
11.

Blonder and Weller


See claim 11.

Claim 13 is obvious over Blonder in view of Weller.


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 it to authorize. Blonder shows all these elements as set forth above
under claims 1 and 5, elements (e) (j).
12.

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


Claim 15 depends from claim 5 and adds setting a flag on the users account

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


Claim 14 is similar, but depends from claim 13. Blonder describes an approval
flag field 304 in Fig. 3 that indicates approval must be sought if pre-established
conditions are violated (e.g., a charge more than a set amount). Blonder at 6:510.

54

IPR201600836
U.S. Patent 8,285,648

Claim 15
15. The method of claim 5 further
comprising the step 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.

13.

Blonder and Weller (emphasis added)


The approval flag field 304 alerts the card
issuer that credit card transactions that violate
preestablished conditions need to be
authorized by the card owner as part of the
card validation process. These pre
established conditions may be preselected
by the card owner or they may be conditions
imposed by the card issuer. Blonder at 6:5
10.

Claim 16 is obvious over Blonder in view of Weller.


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

access information, and storing it where is accessible to the verifier. As described


under claim 16 with respect to Law above (although not part of the claim) the 648
Patent describes the access as being used to determine if sufficient credit is
available to meet the transaction. Blonder shows the account information stored in
the validation database, and also shows using that account information to
determine if there is sufficient balance in the account for the transaction. Blonder
at 12:2630, 5665.
Claim 16
16. The method
of claim 5
further
comprising the
steps of: (v)
acquiring access

Blonder and Weller (emphasis added)


At the transaction processing center, the authorization process
is performed automatically by a computer based system
comprising, inter alia, a database (e.g., validation database 106
of FIG. 1) containing account information for each credit card
subscriber (step 13). Blonder at 12:2630.

55

IPR201600836
U.S. Patent 8,285,648

information for
an account of
the user; and,
(w) storing the
account access
information on a
database that is
accessible to the
verifier.

Based on the customer identifier, a database (such as validation


database 106 of FIG. 1) is consulted to determine whether the
transaction should be authorized (steps 21 and 22). For example,
the database may include account balance and credit limit
information indicating that the customer's account balance is
not permitted to exceed a given credit limit. In such a case,
the system will determine that the transaction should not be
authorized if the sum of the account balance and the amount of
the purchase to be authorized exceeds the credit limit.
Blonder at 12:5665.

C.
Ground 3: Claim 19 is obvious over Blonder in view of Weller and
Labrou.
Claim 19 depends from Claim 5 and recites verifying a device in addition to
verifying the user. Claim 19 requires the verifier to store the device identifier,
retrieve it, compare it to an obtained device 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. Labrou
discloses the use of two-factor authentication for a transaction, with the two factors
being a user personal identification entry (PIE) and a mobile device ID. Labrou
at Abstract. Labrou thus verifies the device, in addition to verifying the user
through the PIE, which can be a password or PIN. One of skill in the art would be
motivated to look to Labrou to add the device identifier to the verification of

56

IPR201600836
U.S. Patent 8,285,648

Blonder and Weller. It was common before the priority date of the 648 Patent, for
fraud detection purposes, to consider various parameters identifying a user in a
transaction. One of many examples is U.S. Pat. 8,572,391 to Golan (Golan,
EX1009), filed Sept. 13, 2003, issued Oct. 29, 2013, which describes a device ID
as one of many factors used to verify a user for risk assessment:
In certain embodiments of the current invention Transaction risk
assessment is based on any of the following criteria, or similar
criteria; other suitable criteria may be used.. Such information may
include, but is not limited to: IP addresses and their derived
information (location, organization etc), source, address, user, account
information, product type, transaction amount, time in day, day in
week, type of account, date of birth, velocity of Transactions, account
number, device ID/fingerprint; Hijacked computer/Trojan infected
computer indicator, or other suitable information, as well as any
combination of such criteria.
Golan at 9:556:2. It would be obvious to use all the parameters in Blonder,
Weller and Labrou since all of them related to authorizing transactions. Blonder
and Labrou both describe using a customer PIN to authorize a transaction, and it
would be obvious to add other standard fraud detection information, such as the
device identifier of Labrou, to Blonder. Just as it would be obvious to include

57

IPR201600836
U.S. Patent 8,285,648

other user information, such as name, address, etc., a device identifier would be
obvious to add. See Gray Decl. (EX1008) at 6364.
Claim 19
19. The method of claim 5
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
communications device of Step
(e); and,
(gg) comparing the device
identifier retrieved at Step (ee)
with the device identifier
obtained 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).

Blonder and Weller and Labrou (emphasis


added)
At operation 454, the STS 120 stores in a
database 203, a unique identifier (referred to as
Device ID, or DID) for the mobile phone 104,
which can, for example, be a mobile phone
number of the mobile phone 104 or .The
unique identifier (device ID (DID)) of the
mobile phone 104 is used by the STS 120 to
correlate [compare and match] a transaction
message with the authentic mobile ID
application 108 (i.e., to correlate the DID with
the software authentication parameter(s) and the
PIE stored at the STS 120, so that the STS 120
can generate a key that corresponds to a device
104 having the DID. . According to an aspect
of the embodiment(s) described herein, an
authentication transaction message is bound to a
unique combination of a user 102 and a mobile
device authenticator 104, the binding to the user
is via the PIE and the binding to the device 104
is via the software authentication parameter(s)
of the authentic mobile ID app 108. In
particular, a transaction is an SAS based
encrypted message and the encrypted message
can be traced back to a combination of the user
102 and the device 104 through the PIE and the
software authentication parameter(s) of the
authentic mobile ID application 108. Labrou
at 10:56-11:20.

58

IPR201600836
U.S. Patent 8,285,648

VI.

CONCLUSION
Based on the foregoing, the challenged claims of the 648 Patent recite

subject matter that is unpatentable. The Petitioner requests institution of an inter


partes review to cancel these claims.
Respectfully Submitted,
/Paul C. Haughey/
Paul Haughey
Registration No. 31,836

59

IPR201600836
U.S. Patent 8,285,648

CERTIFICATE OF SERVICE
The hereby certify that on April 13, 2016, I caused a true and correct copy of the
foregoing materials:
Petition for Inter Partes Review of U.S. Patent No. 8,285,648 Under 35
U.S.C. 312 and 37 C.F.R. 42.10
Exhibits for Petition for Inter Partes Review of U.S. Patent No. 8,285,648
(EX100110011)
To be served via Overnight Express Mail at the following correspondent of record
as listed on PAIR:
DAN SCAMMELL
1729 Hampton Drive
Coquitlam, BC, Canada V3E 3C9
VERMETTE & CO.
1177 West Hastings Street, Suite 320
Vancouver, BC, V6E 2K3 CANADA
Respectfully

By: /Paul C. Haughey/


Paul C. Haughey
Registration No. 31,836
Counsel for Petitioner

Dated: April 13, 2016

You might also like