`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 1 of 10
`
`6,018,724
`
`HONEST JOE'S COMPUTERS
`
`if you can't trust Honest Joe, who can you trust?
`
`This Month's UNBELIEVABLE Specials:
`
`120
`
`[:1 250 Mhz Famous Make Computer, 32 MB Ram, 5GB
`
`/ Hard Drive, Monitor, Printer, $2000 of software:
`HONEST JOE'S UNBELIEVABLE PRICE: $499.00!
`C] Do it in Laser Color! Famous Make Color Laser Printer,
`
`/ 16 MILLION colors; 25 pages per minute:
`130
`Elsewhere $5000,
`HONEST JOE'S UNBELIEVABLE PRICE: $699.00!
`
`To order, just dick the box next to the item you want,
`fill in your name address and credit card number, and
`click the "Buy!" button, and your new computer product
`will be on its way!
`
`Name: j
`Street
`
`City, State Zip:
`
`Credit Card
`
`Expiration I:
`
`FIG. 1
`
`Page 00002
`
`
`Page 00002
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 2 of 10
`
`6,018,724
`
`
`
`Request proof
`of certification from
`
`merchant
`
`220
`
`Display "C erlified"
`symbol
`
`270
`
`
`
`Display "Not
`Certified’ symbol
`
`
`
`Certification
`Provided?
`
`
`200
`
` 210
`
`Yes
`
`Test authenticity
`of certification
`
`Yes
`
`0
`
`/..28
`
`Test other data
`
`FIG. 2
`
`Page 00003
`
`
`
`
`
`Display "Not
`Certified" symbol
`
`
`
`
`
`230
`
`240
`
`\
`250
`
`
`Page 00003
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 3 of 10
`
`6,018,724
`
`HONESTJOESCOMPUTERS
`
`If you can't trust Honest Joe, who can you trust?
`
`This Month's UNBELIEVABLE Specials:
`
`[:]
`
`250 Mhz Famous Make Computer, 32 MB Ram, 5GB
`Hard Drive, Monitor, Printer, $2000 of software:
`
`HONEST JOE'S UNBELIEVABLE PRICE: $499.00!
`
`in Laser Color! Famous Make Color Laser Printer,
`C] Do it
`16 MILLION colors; 25 pages per minute:
`
`WARNING!
`This site IS
`
`Elsewhere $5000,
`HONEST JOE'S UNBELIEVABLE PRICE: $699.00!
`
`Not Certified!
`
`— To order, just click the box next to the item you want,
`300 >< fill
`in your name address and credit card number, and
`click the "Buy!" button, and your new com puter product
`will be on its way!
`
`Name: L:::
`Street:
`
`City, State Zip:
`
`Credit Card
`
`Expiration [:|
`
`100
`
`FIG. 3
`
`Page 00004
`
`
`Page 00004
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 4 of 10
`
`6,018,724
`
`HONESTJOEGCOMPUTERS
`
`If you can't trust Honest Joe, who can you trust?
`
`This Month's UNBELIEVABLE Specials:
`
`[:]
`
`250 Mhz Famous Make Computer, 32 MB Ram, 5GB
`Hard Drive, Monitor, Pnnter, $2000 of software:
`
`HONEST JOE'S UNBELIEVABLE PRICE: $499.00!
`
`in Laser Color! Famous Make Color Laser Printer,
`|:| Do it
`16 MILLION colors; 25 pages per minute:
`
`Cert
`
`Elsewhere $5000,
`HONEST JOE'S UNBELIEVABLE PRICE: $699.00!
`
`To order, just click the box next to the item you want,
`fill
`in your name address and credit card number, and
`click the "Buy!“ button, and your new computer product
`will be on its way!
`
`Name: ::|
`Street:
`
`City, State Zip:
`
`Credit Card
`
`Expiration l:l
`
`100
`
`FIG. 4
`
`Page 00005
`
`
`Page 00005
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 5 of 10
`
`6,018,724
`
`
`ciaigéggi
`
`
`
`
`
`
`500
`
`|DX21A7
`
`/
`
`520
`
`FIG. 5
`
`510
`
`\W
`
`IIIIIIU
`
`text String
`
`Stan da rd Graphic
`
`User defined
`
`FIG. 7
`
`Page 00006
`
`
`Page 00006
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 6 of 10
`
`6,018,724
`
`HONESTJOESCOMPUTERS
`
`If you can't trust Honest Joe, who can you trust?
`
`This Month's UNBELIEVABLE Specials:
`
`D 250 Mhz Famous Make Computer, 32 MB Ram, 5GB
`Hard Drive, Monitor, Printer, $2000 of software:
`
`HONEST JOE'S UNBELIEVABLE PRICE: $499.00!
`
`[:1 Do it in Laser Color! Famous Make Color Laser Pnnler,
`16 MILLION colors; 25 pages per minute:
`
`Cert med
`
`IDX2 1A7
`
`Elsewhere $5000,
`HONEST JOE'S UNBELIEVABLE PRICE: $699.00!
`
`To order, just click the box next to the item you want,
`fill in your name address and credit card number, and
`click the "Buyl“ button, and your new computer product
`will be on its way!
`
`Name: ::
`Street:
`
`City, State Zip:
`
`Credit Card
`
`Expiration E
`
`100
`
`FIG. 6
`
`Page 00007
`
`
`Page 00007
`
`
`
`U.S. Patent
`
`Jan. 25,2000
`
`Sheet 7 of 10
`
`6,018,724
`
`
`
`811
`
`K TRUSTED
`
`812
`
`/' UNTRUSTED
`
`
`
`812
`
`|D2X21A7
`
`
`
`
`
`
`
`
`
`
`
`816
`
`814
`
`
`
`0;:
`
`
`
`
`816
`
`
`
`812
`
`
`TRUSTED
`
`.._4
`
`
`
`820
`
`816
`
`824
`
`826
`
`4
`
`Page 00008
`
`
`Page 00008
`
`
`
`U.S. Patent
`
`Jan. 25, 2000
`
`Sheet 8 of 10
`
`6,018,724
`
`Page 00009
`
`Begin Wallet setup
`
`Prom pt user to
`
`K enter text string
`
`Ask user to confirm
`
`K entered text string
`
`952
`
`Store text string in
`Wallet database
`
`954
`
`I
`
`
`Page 00009
`
`
`
`U.S. Patent
`
`.%2n.
`
`0
`
`E>Em
`
`u:9
`
`
`
`>mO§m2>mOEm§
`
`10:
`
`M
`
`682
`
`7.8,Eat
`
`f
`
`we.:2oz:22mE0252S:_<OO.._
`
`mO<mOHmW mmDO_>_n_m<Om>mv_
`
`Page 00010
`
`
`Page 00010
`
`
`
`U.S. Patent
`
`Jan. 25, 2000
`
`Sheet 10 of 10
`
`6,018,724
`
` Total Cost of Items
`Total Discounts
`Saies Tax
`Shipping fHand1inq
`Purchase Total
`
`34333
`
`V Mileage Plus
`First Card
`
`Hanufacturer3
`Coupon
`
`'I’I1U!'-TEE‘
`
`,
`
`FIG. 11
`
`Page 00011
`
`
`Page 00011
`
`
`
`1
`METHOD AND APPARATUS FOR
`AUTHENTICATING ON-LINE
`TRANSACTION DATA
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`
`The present invention relates to electronic commerce, and
`more particularly to a method and apparatus for authenti-
`cating and verifying data related to electronic transactions.
`Portions of the disclosure of this patent document contain
`material that is subject to copyright protection. The copy-
`right owner has no objection to the facsimile reproduction
`by anyone of the patent document or the patent disclosure as
`it appears in the Patent and Trademark Office file or records,
`but otherwise reserves all copyright rights whatsoever.
`2. Background Art
`Electronic commerce via distributed network environ-
`
`ments such as the internet and intranets has the potential for
`replacing many forms of traditional commerce. One factor
`impeding the growth of electronic commerce is a concern
`over the security of transactions conducted via the internet.
`This concern stems in part from the difficulty of providing
`verification and accountability via the internet. It is easy for
`legitimate and illegitimate businesses alike to set up web
`sites to solicit business over the internet. Accordingly, there
`is a degree of uncertainty about the identity and legitimacy
`of any business offering goods or services via an internet
`web page and about the authenticity of data related to on-line
`transactions. Customers are wary about purchasing goods or
`services and sending confidential information such as credit
`card numbers to internet based businesses without a degree
`of certainty as to the authenticity and legitimacy of an
`internet merchant.
`
`SUMMARY OF THE INVENTION
`
`The present invention comprises a method and apparatus
`for authenticating and verifying data related to electronic
`transactions and for providing positive confirmation to a
`user of such authentication and verification.
`In one
`embodiment, such data includes the contents of an electronic
`“wallet,” including identity and other data from a transaction
`party, electronic payment instrument data, security protocol
`data, and wallet operation data. The invention utilizes a
`user-customized certification indicator that informs a user as
`to the success or failure of one or more authentication and/or
`security protocols implemented on a user communications
`access device such as a personal computer, a network
`computer (“NC”), a personal digital assistant (“PDA”), an
`enhanced function telephone, etc.
`In one or more
`embodiments, the certification indicator includes multiple
`components. One of the components of the indicator is user
`defined, and locally stored, reducing the likelihood of inter-
`ception and counterfeiting. In one or more embodiments, the
`indicator components include a centrally provided graphic
`element and a user defined text overlay. In one embodiment,
`the centrally provided graphic element is a graphic image,
`for example an image of an official seal, supplied by a
`trusted certification authority that provides transaction party
`certification services. The user defined text overlay is a user
`defined text string, similar to a user defined password. When
`a user initiates an electronic transaction with a transaction
`
`party, a background validation process is initiated that
`implements procedures for determining the authenticity of
`the transaction party as well as of other data related to the
`transaction.
`In one embodiment, such transaction data
`includes data received by and displayed (for example using
`
`6,018,724
`
`2
`
`a “wallet” interface) by the user’s communications access
`device. If the validation process determines that the data is
`authentic,
`the validation process displays a certification
`indicator comprising the graphic of the official seal overlaid
`with the user defined text-string. In another embodiment, the
`certification indicator includes one or more multi-media
`
`components, such as, for example, an audio component.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 shows an example of an on-line merchant’s web
`page.
`
`FIG. 2 is a flow chart of a method that may be used by a
`user’s communications access device to authenticate an
`on-line-merchant.
`
`FIG. 3 shows an example of a certification indicator
`indicating an absence of certification displayed on a user’s
`communications access device.
`
`FIG. 4 shows an example a certification indicator dis-
`played on a user’s communications access device.
`FIG. 5 shows an example of a multi-component certifi-
`cation indicator.
`
`10
`
`15
`
`20
`
`FIG. 6 shows an example of a multi-component certifi-
`cation indicator displayed on a user’s communications
`access device.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`FIG. 7 is a block diagram of a certification indicator
`comprising a sequence of multi-media components.
`FIG. 8 shows examples of multi-component certification
`indicators.
`
`FIG. 9 is a flow chart of a method for generating a
`user-defined component of a certification indicator.
`FIG. 10 is a schematic showing an example of a commu-
`nications access device that may be used with one or more
`embodiments of the invention.
`
`FIG. 11 shows an example of a Java Wallet in which a
`certification indicator is displayed.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`A method and apparatus for authenticating data related to
`on-line transactions is described.
`In the following
`description, numerous specific details are set forth in order
`to provide a more thorough description of the invention. It
`will be apparent, however, to one skilled in the art that the
`invention may be practiced without these specific details. In
`other
`instances, well-known features have not been
`described in detail so as not to obscure the invention.
`
`FIG. 1 shows an example of a web page 100 of an internet
`merchant that offers items for sale via the internet. Web page
`100 may, for example, be an HTML page, and may include
`functionality provided by Java applets, as is well known in
`the art.
`
`In the example of FIG. 1, web page 100 contains a
`merchant’s name 110, a list of items for sale 120, check
`boxes 125 and 130, purchasing instructions 135, a customer
`information entry area 140, and a “buy” button 150. Accord-
`ing to purchasing instructions 135, to purchase one of the
`items listed in list 120, a user clicks the check box next to
`the item desired, fills in the user’s name, address and credit
`card information in customer information entry area 140,
`and clicks on button 150. In the example of FIG. 1 these
`payment mechanisms are provided by the web page and the
`user’s web browser. In other embodiments, payment mecha-
`nisms may be provided in a different manner, for example by
`an electronic “wallet” application program or applet.
`
`Page 00012
`
`
`Page 00012
`
`
`
`6,018,724
`
`3
`Auser browsing a merchant’s web page such as web page
`100 may be interested in purchasing one or more items being
`offered for sale on the web page, but may have concerns
`about buying from an on-line merchant whose identity and
`business practices are unknown to the user and with whom
`the user has had no previous experience.
`One way to alleviate the user’s concerns is for an entity
`trusted by the user to certify the legitimacy of the merchant.
`The trusted entity may be a certification authority that
`evaluates and certifies merchants that meet the certification
`
`authority’s certification criteria, for example, by issuing
`digital certificates to certified merchants or by including the
`merchant in a database of certified merchants maintained by
`the certification authority.
`To check the authenticity of a particular on-line merchant,
`the computer or other communications access device used
`by the user (for example a personal digital assistant (PDA),
`a network computer, an internet television access device
`such as “WebTV” (tm), an enhanced cellular telephone, etc.)
`is provided with computer processor readable program
`instructions for determining whether a merchant has been
`certified by a trusted certification authority and for verifying
`the identity of the merchant and other data related to the
`transaction. The instructions may, for example, form part of
`an internet browser application, or may be part of a separate
`application program, such as an electronic “wallet,” that
`may be used in conjunction with an internet browser.
`FIG. 2 is a block diagram of a method that may be used
`by a user’s communications access device to authenticate an
`on-line-merchant. As shown in FIG. 2, the user’s commu-
`nications access device sends a request for proof of certifi-
`cation to the merchant at step 200. The sending of the
`request may be initiated as part of some other transaction
`(e.g. requesting an invoice) or may be initiated through an
`express user action. The requested proof of certification may
`have any of a variety of forms as are known in the art. For
`example, the proof of certification may comprise a digitally
`signed message or a copy of a digital certificate from a
`trusted certification authority. At step 210, a determination is
`made as to whether a requested proof of certification was
`provided by the merchant in response to the user’s request.
`If no proof of certification was provided by the merchant, the
`user’s access device displays a certification indicator that
`indicates an absence of certification to the user. An example
`of a certification indicator that
`indicates an absence of
`
`certification is indicator 300 of FIG. 3. In the example of
`FIG. 3, certification indicator 300 is displayed by the user’s
`access device as a graphic that floats above merchant web
`page 100. In other embodiments, certification indicator 300
`may be displayed elsewhere, such as in the interface of
`another application program or applet. For example, in one
`embodiment certification indicator 300 is displayed in an
`electronic “wallet” interface.
`
`If it is determined at step 210 that the merchant did supply
`a proof of certification in response to the user’s request at
`block 200, the authenticity of the certification is tested at
`step 230, using an appropriate testing process for the form
`of proof of certification provided by the merchant. For
`example, if the proof of certification is a digital signature,
`the user’s device may obtain a copy of the merchant’s public
`key from a trusted party, and use the key to test
`the
`merchant’s digital signature.
`At step 240, a determination is made as to whether the test
`of the merchant’s proof of certification has authenticated the
`merchant. If the merchant is not authenticated, a certification
`indicator indicating an absence of certification, such as
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`indicator 300 of FIG. 3, is displayed to the user at step 250.
`The certification indicator may be displayed as a graphic that
`floats over the merchants web page as shown in FIG. 3, or
`may be displayed in some other manner, for example in an
`electronic “wallet” interface.
`
`is authentic, a
`the merchant
`is determined that
`If it
`determination is made at step 260 as to whether any other
`data related to the transaction needs to be certified. Such
`
`other data may include, for example, the contents of an
`electronic “wallet” that is being displayed, such as electronic
`payment instruments displayed in the wallet. Data to be
`certified may also include, without limitation, security pro-
`tocols and electronic payment or transfer operations. If there
`is no additional data to be certified, a certification indicator
`indicating successful certification is displayed to the user at
`step 270. An example of a certification indicator that indi-
`cates successful certification is symbol 400 of FIG. 4. In the
`example of FIG. 4, certification indicator 400 is displayed by
`the user’s access device as a graphic that floats above
`merchant web page 100. Alternatively, certification indicator
`400 may be displayed elsewhere, such as in the interface of
`another application program or applet,
`for example an
`electronic “wallet” applet or application program.
`If there is additional data to be certified, such data is tested
`at step 280, and a determination as to the data’s authenticity
`is made at step 290. If the data is not authenticated, a
`certification indicator indicating an absence of certification
`is displayed to the user at step 250.
`If the data is
`authenticated, a certification indicator confirming authenti-
`cation is displayed to the user at step 270.
`In the embodiment of FIG. 4, certification indicator 400 is
`a standard symbol supplied as part of the program code that
`performs the authentication process of FIG. 2. One draw-
`back of using a standard certification indicator such as
`symbol 400 of FIG. 4 is that an unscrupulous merchant
`could make a copy of the certification indicator and cause it
`to be displayed on the user’s access device to make it appear
`that the user’s device has successfully authenticated the the
`transaction data, even when the user’s access device has
`found the data to be not certified.
`
`To prevent unauthorized counterfeiting of a certification
`indicator, one or more embodiments of the invention use a
`certification indicator that comprises a component that has
`been customized by the user. This user defined component is
`stored in a secure form in a local storage device of the user’s
`internet access device. Since the user defined component is
`not predictable and is available only on the user’s local
`access device, it cannot be easily copied and forged by an
`unscrupulous merchant.
`One embodiment of a certification indicator of the inven-
`
`tion comprising a user defined component is shown in FIG.
`5.
`In this embodiment, certification indicator 500 is a
`multi-component indicator that consists of a standard com-
`ponent 510 and a user defined component 520.
`In the
`example of FIG. 5, standard component 510 comprises a
`graphic symbol supplied, for example, by the supplier of the
`user’s merchant authentication computer code.
`In this
`embodiment, user defined component 520 consists of a text
`string, similar to a password, selected by the user. The text
`string may be selected, for example, during a setup phase of
`the user’s merchant authentication software. The text string
`may include any kind of text
`in any machine readable
`format, including ASCII, Unicode, etc.
`Standard component 510 and user defined component 520
`are stored in separate locations on the user’s computer or
`other communications access device. In the embodiment of
`
`Page 00013
`
`
`Page 00013
`
`
`
`6,018,724
`
`5
`FIG. 5, they are retrieved and combined to form certification
`indicator 500 only after a particular merchant or other
`transaction party has been authenticated. For example, in the
`embodiment of FIG. 2, components 510 and 520 are
`retrieved from storage and combined as part of step 270.
`FIG. 6 shows combined certification indicator 510 displayed
`on top of merchant web page 100. Alternatively, certification
`indicator 510 may be displayed elsewhere, such as in the
`interface of another application program or applet,
`for
`example an electronic “wallet” applet or application pro-
`gram.
`In the embodiment of FIG. 5, the certification indicator
`comprises two components: a standard graphic component
`and a user-defined text string. The certification indicator
`may, however, have any of a variety of other structures,
`provided that some aspect of the indicator is user defined so
`that the indicator cannot easily be forged.
`The term “indicator” as used with respect to the invention
`includes static indicators as well as dynamic, multi-media
`indicators. FIG. 7 is a block diagram of an embodiment of
`a certification indicator of the invention that comprises a
`sequence of one or more media items such as graphics, text,
`sound, animation, and video. In the embodiment shown in
`FIG. 7, certification indicator 700 comprises a sequence of
`three media items: a standard graphic 710, an audio segment
`720, and a user-defined text string 730. In this embodiment,
`when the certification indicator is to be displayed to the user
`(as, for example, at step 250 of FIG. 2), the indicator is
`presented to the user in a sequential manner. First, standard
`graphic 710 is displayed. Next, audio segment 720 is played.
`Finally, user-defined text string 730 is superimposed on
`standard graphic 710. It will be apparent to those skilled in
`the art that media items of a certification indicator can be
`
`presented in any desired order, and that more than one media
`item may be presented simultaneously.
`Preferably, certification indicator 700 comprises at least
`one user defined component. Such a user-defined component
`may constitute a user-defined media item (such as, for
`example, user defined text string 730), or a user-defined
`order for presentation of different media components, or a
`user defined selection of media items from a pool of supplied
`standard media items.
`FIGS. 8 shows embodiments of certification indicators
`
`that may be used in conjunction with the Java Wallet (TM),
`a user interface for the Java Electronic Commerce Frame-
`
`work (TM) (“JECF”) from JavaSoft. JECF includes a client-
`side software architecture for secure electronic commerce
`
`and sensitive data transactions. The Java Wallet (TM) is a
`user interface for JECF that provides interaction controls
`and user
`input and display areas that allow on-line
`purchases, value transfers and administrative functions.
`When activated for use, the Wallet is displayed indepen-
`dently on a user’s communications access device on top of
`other applications, such as, for example, World Wide Web
`browsers or operating environments such as the various
`implementations of Windows from Microsoft. A description
`of the Java Wallet (TM) user interface is attached as Appen-
`dix A. FIG. 11 shows an example of a Java Wallet 1100 in
`which a certification indicator 1110 is displayed. A descrip-
`tion of the procedure used to display indicator 1110 in Java
`Wallet 1100 is attached as Appendix B.
`A Java Wallet, in conjunction with JECF, includes com-
`puter program instructions for performing authentication
`tests on web site proprietors and on other on-line transaction
`parties, and for authenticating data related to on-line trans-
`actions. These instructions have the ability to determine
`
`6
`
`whether or not a transaction party is authentic (i.e. is who the
`party says the party is). The instructions also have the ability
`to determine whether or not an offer presented to a user (e.g.
`via a web site) has been digitally signed by the party making
`the offer, as well as whether or not other information
`displayed to the user by the Wallet
`is authentic. These
`determinations are made by the Wallet and JECF transpar-
`ently to the user. The possible results of these determinations
`include the following:
`1. The transaction party and/or other transaction data is
`authentic and the offer is signed.
`2. The transaction party and/or other transaction data is
`authentic and the offer is unsigned.
`3. The transaction party and/or other transaction data is
`not authentic (or not recognized) and the offer is signed.
`4. The transaction party and/or other transaction data is
`not authentic (or not recognized) and the offer is unsigned.
`These results are displayed to the user using certification
`indicators such as the indicators shown in FIG. 8.
`
`FIG. 8 shows components 810, 812, 814, and 816 that are
`assembled, as appropriate, into certification indicators 818
`and 820. Components 810 and 811 are standard graphic
`components which may, for example, be supplied to the user
`as part of the Java Wallet code. Components 812 and 814 are
`standard text strings comprising the words “TRUSTED” and
`“UNTRUSTED,” respectively. Like standard graphic com-
`ponents 810 and 811, standard text string components 812
`and 814 may be supplied to the user as part of the Java
`Wallet Code. Component 816 is a user defined text string
`which may, for example, be generated during a setup pro-
`cedure for the Java Wallet.
`
`Certification indicator 818 is displayed to the user in
`situation number 1 listed above: when the transaction party
`and/or other transaction data is authentic and the offer from
`the transaction party is signed. At
`the time of display,
`certification indicator 818 is assembled from components
`810, 812 and 816, as shown in FIG. 8.
`Certification indicator 820 is displayed to the user in
`situation number 2 listed above: when the transaction party
`and/or other transaction data is authentic and the offer from
`the transaction party is unsigned. At the time of display,
`certification indicator 820 is assembled from components
`810, 814 and 816, as shown in FIG. 8.
`Certification indicator 822 is displayed to the user in
`situation number 3 listed above: when the transaction party
`and/or other transaction data is not authentic (or is not
`recognized) and the offer from the transaction party is
`signed. At the time of display, certification indicator 822 is
`assembled from components 811, 812 and 816, as shown in
`FIG. 8.
`
`Certification indicator 824 is displayed to the user in
`situation number 4 listed above: when the transaction party
`and/or other transaction data is not authentic (or is not
`recognized) and the offer from the transaction party is
`unsigned. At the time of display, certification indicator 824
`is assembled from components 811, 814 and 816, as shown
`in FIG. 8.
`Certification indicators 826 and 828 are versions of cer-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`tification indicators 822 and 824, respectively, that do not
`include component 816. Certification indicators 826 and 828
`are used in certain embodiments instead of indicators 822
`
`and 824, respectively.
`In one or more embodiments, indicators 818, 820, 822,
`824, 826 or 828, as applicable, are displayed as part of the
`user’s Java Wallet interface when the user initiates use of the
`
`65
`
`to an on-line transaction. For
`Java Wallet with respect
`example, while browsing the internet, a user may happen
`
`Page 00014
`
`
`Page 00014
`
`
`
`6,018,724
`
`7
`upon a web site with which the user wants to transact
`business. The user calls up the user’s Java Wallet by
`activating an appropriate icon displayed, for example, by the
`user’s browser or on the web site’s web page. As the Java
`Wallet program code is being activated, authentication mes-
`sages are sent from the user’s device to the web site, and the
`responses received, if any, are evaluated according to the
`Wallet’s authorization protocols to determine the authentic-
`ity of the web site. Depending on the result, the appropriate
`certification indicator is displayed as part of the Wallet
`interface.
`In one or more embodiments, the certification indicators
`of FIG. 8,
`like the indicator shown in FIG. 7,
`include
`additional media components such as, for example, sound,
`video and animation.
`
`In the embodiment of FIG. 8, the user-defined component
`816 is defined by the user as part of the initial setup of the
`user’s Java Wallet interface. A flow chart for a portion of the
`Java Wallet setup process used to generate the user-defined
`text string is shown in FIG. 9.
`As shown in FIG. 9, the Wallet setup process begins at
`step 900. The setup process may, for example, be invoked
`the first time the user starts the Wallet process. During the
`Wallet setup process, the user is asked to select user pref-
`erences and enter user information. The dotted arrow in FIG.
`
`9 between step 900 and 950 indicates that additional steps
`not directly related to the certification indicator may occur in
`between these steps. At step 950, the user is prompted to
`enter a text string to be used as the user-defined component
`of the user’s certification indicator. In one embodiment, the
`user is prompted to enter an eight digit alphanumeric text
`string. After the user has entered the text string, the user is
`asked to confirm the text string at step 952. After the user has
`confirmed the user’s choice of text string, the text string is
`stored at step 954 in a Wallet database containing Wallet
`related information. The Wallet setup process ends at step
`990.
`The Wallet database is stored in a secure manner on local
`
`storage of the user’s computer or other communications
`access device. In one or more embodiments, the user defined
`component is stored separately from standard components
`(such as, for example, components 810 and 811).
`An example of a communications access device with
`which one or more embodiments of the invention may be
`used is shown in FIG. 10. The access device of FIG. 10 is
`
`a personal computer. However, the access device can com-
`prise any of a variety of other devices, including, without
`limitation, personal digital assistants, network computers,
`enhanced cellular and hard-wired telephones,
`internet-
`capable television sets, etc.
`An embodiment of the invention can be implemented as
`computer software in the form of computer readable pro-
`gram code executed on a general purpose computer such as
`computer 1000 illustrated in FIG. 10. Akeyboard 1010 and
`mouse 1011 are coupled to a bi-directional system bus 1018.
`The keyboard and mouse are for introducing user input to
`the computer system and communicating that user input to
`central processing unit (CPU) 1013. Other suitable input
`devices may be used in addition to, or in place of, the mouse
`1011 and keyboard 1010.
`I/O (input/output) unit 1019
`coupled to bi-directional system bus 1018 represents such
`I/O elements as a printer, A/V (audio/video) I/O, etc.
`Computer 1000 includes a video memory 1014, main
`memory 1015 and mass storage 1012, all coupled to bidi-
`rectional system bus 1018 along with keyboard 1010, mouse
`1011 and CPU 1013. The mass storage 1012 may include
`both fixed and removable media, such as magnetic, optical
`
`8
`or magnetic optical storage systems or any other available
`mass storage technology. Bus 1018 may contain,
`for
`example,
`thirty-two address lines for addressing video
`memory 1014 or main memory 1015. The system bus 1018
`also includes, for example, a 32-bit data bus for transferring
`data between and among the components, such as CPU
`1013, main memory 1015, video memory 1014 and mass
`storage 1012. Alternatively, multiplex data/address lines
`may be used instead of separate data and address lines.
`In one embodiment of the invention, the CPU 1013 is a
`microprocessor manufactured by Motorola, such as the
`680X0 processor or a microprocessor manufactured by Intel,
`such as the 80X86, or Pentium processor, or a SPARC
`microprocessor from Sun Microsystems. However, any
`other suitable microprocessor or microcomputer may be
`utilized. Main memory 1015 is comprised of dynamic ran-
`dom access memory (DRAM). Video memory 1014 is a
`dual-ported video random access memory. One port of the
`video memory 1014 is coupled to video amplifier 1016. The
`video amplifier 1016 is used to drive the cathode ray tube
`(CRT) raster monitor 1017. Video amplifier 1016 is well
`known in the art and may be implemented by any suitable
`apparatus. This circuitry converts pixel data stored in video
`memory 1014 to a raster signal suitable for use by monitor
`1017. Monitor 1017 is a type of monitor suitable for
`displaying graphic images.
`Computer 1000 may also include a communication inter-
`face 1020 coupled to bus 1018. Communication interface
`1020 provides a two-way data communication coupling via
`a network link 1021 to a local network 1022. For example,
`if communication interface 1020 is an integrated services
`digital network (ISDN) card or a modem, communication
`interface 1020 provides a data communication connection to
`the corresponding type of telephone line, which comprises
`part of network link 1021. If communication interface 1020
`is a local area network (LAN) card, communication interface
`1020 provides a data communication connection via net-
`work link 1021 to a compatible LAN. Wireless links are also
`possible. In any such implementation, communication inter-
`face 1020 sends and receives electrical, electromagnetic or
`optical signals which carry digital data streams representing
`various types of information.
`Network link 1021 typically provides data communica-
`tion through one or more networks to other data devices. For
`example, network link 1021 may provide a connection
`through local network 1022 to host computer 1023 or to data
`equipment