a2) United States Patent
`US 6,463,534 B1
`(10) Patent No.:
`;
`Oct. 8, 2002
`(45) Date of Patent:
`Geiger et al.
`
`
`US006463534B1
`
`(54) SECURE WIRELESS
`ELECTRONIC-COMMERCE SYSTEM WITH
`WIRELESS NETWORK DOMAIN
`
`(75)
`
`Inventors: Robert L. Geiger, Algonquin, IL (US);
`Jyh-Han Lin, Coral Springs, FL (US);
`Rajiv Mehta, Plantation, FL (US)
`
`(73) Assignee: Motorola, Inc., Schaumburg, IL (US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C, 154(b) by 0 days.
`
`(21) Appl. No.: 09/276,978
`aay
`aA:
`P
`eee
`($1)
`INtsCh? susccacacncsniennenacccsce: GO6F 1/24
`(52) US. Ch ceeseseessssessssseesss 713/168; 713/169; 713/175;
`705/50; 705/76; 380/278; 380/282
`(58) Field of Search .......s.ssces705/50, 67,76,
`7205/1: 380/278, 282: 713/168, 169, 175
`——"
`, 176. 200 301.
`173
`:
`aaa
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,659,616 A *
`5,671,279 A *
`5,712,914 A *
`
`8/1997 Sudia .cissisaasecaienee, SO0/23
`9/1997 Elgamal
`
`........ . 380/23
`1/1998 Aucsmith etal. a 380/30
`
`8/1998 Cordery etal.
`.............. 380/55
`5,796,841 A *
`
`3/1999 Aucsmith et al. 2.0.0... 380/30
`5,878,144 A *
`3/1999 Ryan, Jr. etal.
`........... 455/410
`5,884,158 A *
`5/1999 Talati et al. cesses, 705/26
`5,903,878 A *
`5,987,440 A * 11/1999 O'Neil et al. v.cc..eeees FOS/44
`cited by examiner
`
`Primary Examiner—Thomas R. Peeso
`(74) Altorney, Agent, or Firm—Hisashi D. Watanabe; Hugh
`C. Dunlop
`7
`ABSTRACT
`67)
`A method ofconducting transactions in a wireless electronic
`commerce system, where the system comprises a wireless
`network operatorcertification authority (400) having a root
`public key certificate and at
`least one attribute authority
`(404, 405, 406) having a digital certificate that is dependent
`from the root public key certificate. The attribute authority
`is accessible by a wireless client device (450, 452) via a
`wireless network. Thedigital certificate is delivered from the
` altribute authority to the wireless device,
`the attribute
`authority is verified to the wireless client device using the
`digital certificate and the root public key certificate pre-
`loaded in the wireless client device under authority of the
`wireless network operator. An attribute (software, service,
`right/permission or other content
`item) is delivered to the
`wireless client device over the wireless network and ulti-
`mately enabled at the wireless client device.
`
`19 Claims, 5 Drawing Sheets
`
`~oe ce
`SECURE ELECTRONIC COMMERCE INFRASTRUCTURE
`
`7s;
`
`a
`
`‘
`
`
`CERTIFICATE AUTHORITY
`(ISSUES LICENSE &
`PUBLIC KEY CERTIFICATES)
`
`
`ih)
`
` SOFTWARE SERVER (ISSUES
`
`PRODUCT CERTIFICATES)
`
`WEB SERVER
`
`WAP PROXY SERVER
`
`‘
`
`WIRELESS
`NETWORK
`
`LANDLINE TELEPHONE
`
`—_l
`jj
`COMPUTER
`
`WIRELESS DEVICE
`
`APPLE 1006
`
`APPLE 1006
`
`1
`
`

`

`U.S. Patent
`
`Oct. 8, 2002
`
`Sheet 1 of 5
`
`US 6,463,534 B1
`
`c—}/
`yuindnod
`al=
`
`
`
`JNOHdITILINTTONY)
`
`il~
`
`SSITINIM
`
`AYOMLIN
`
`|Sls
`
`
`
`JOIAIOSSITINIM
`
`
`
`YIAYISAXOYdd¥M
`
`
`S3NSSI)Y3AYISJYVMLIOS
`
`(S3LVOT4I1930LONdOYd
`
`(SILVOI4T1Y3AIXOTTANd®3SN3011
`S3NSSI)
`
`
`
`
`
`YGAN3S83MALINOHINY3LVOT4TLYIO
`
`eee
`
`
`
`JUNLONYLSVYINIJOYINAODJINOYLIITIIuNdIS
`
`
`
`
`
`iiitiiinis
`
`2
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Oct. 8, 2002
`
`Sheet 2 of 5
`
`US 6,463,534 B1
`
`
`
`
`GENERATE
`GENERATE PUBLIC KEY
`LICENSE
`FOR PHONE IN
`
`
`
`CERTIFICATE(S)
`FACTORY
`
`
`GENERATE PRODUCT/
`CONTENT ITEM
`CERTIFICATE
`
`
`
`
`CA SERVER SIGNS
`CERTIFICATE AND
`RETAINS COPY
`
`
`
`
`SERVER 17 SIGNS
`CERTIFICATE
`
`
`
`
`
`
`
`INSTALL
`CERTIFICATE
`
`INSTALL SIGNAL
`SOFTWARE
`
`
`
`
`
`
`FIG.2
`
`
`
`
`BOOT AND
`VALIDATE
`
`VALID LICENSE
`CERTIFICATE FOR THIS
`
`reubNeT
`
`ENABLE SOFTWARE
`PRODUCT
`
`3
`
`

`

`U.S. Patent
`
`Oct. 8, 2002
`
`Sheet 3 of 5
`
`US 6,463,534 B1
`
`PURCHASE FEATURE
`THROUGH WEB
`SERVER 16
`
`200
`
`SERVER 16 VERIFIES
`
`}—202
`
`
`
`SEND ID AND PRODUCT
`NAME TO SERVER 15
`FOR NEW LICENSE
`CERTIFICATE
`
`[3293
`
`DOWNLOAD CERTIFICATE|apg
`TO PHONE
`
`(SOFTWARE
`PRE-INSTALLED)
`ai
`
`206
`
`ENABLE SOFTWARE
`
`7270
`
`ERROR
`
`208
`
`(SOFTWARE NOT
`PRE-INSTALLED)
`
`
`
`
`SEND REQUEST 10
`SERVER 16 AND DOWNLOAD
`SOFTWARE
`
`226
`
`ENABLE SOFTWARE
`
`——2J0
`
`FIG.3
`
`4
`
`

`

`U.S. Patent
`
`Oct. 8, 2002
`
`Sheet 4 of 5
`
`US 6,463,534 B1
`
`‘\
`
`:
`!
`:
`|
`|
`|
`|
`|
`
`|
`
`| |
`
`|
`|
`|
`|
`|
`|
`|
`i
`|
`|
`
`|
`
`Se sitie Moco eee ee Lo meg,
`
`500
`
`402
`
`WIRELESS
`NETWORK
`CONTROL
`
`
`
`406
`
`452
`
`420
`
`cr
`
`|
`
`:
`:
`i
`|
`|
`|
`|
`|
`
`|
`
`|
`
`|
`|
`|
`|
`|
`|
`|
`|
`|
`|
`
`|
`
`/
`\ X
`x
`(meee ieii
`
`‘
`
`450
`
`5
`
`

`

`U.S. Patent
`
`Oct. 8, 2002
`
`Sheet 5 of 5
`
`US 6,463,534 B1
`
`510
`
`515
`
`me
`
`CLIENT ESTABLISHES
`WIRELESS CONNECTION
`TO AA VIA WIRELESS
`
`GATEWAY
`
`AA DELIVERS
`CERTIFICATE T0
`CLIENT
`
`CLIENT VERFIES
`CERTIFICATE
`
`CLIENT DELIVERS
`CERTIFICATE
`TO AA
`
`AA VERFIES
`CERTIFICATE
`
`AA DELIVERS
`
`CONTENT ITEM UATE)
`
`TO CLIENT
`
`540
`
`wn>on
`
`950—
`
`570
`
`CONTENT ITEM
`IS ENABLED
`ON CLIENT
`
`AA INSTRUCTS CA
`TO BILL CUSTOMER
`
`CA BILLS CUSTOMER
`AND CREDITS AA
`
`555
`
`60
`
`FIG.5
`
`CLIENT PROVIDES
`CREDIT CARD
`
`DETAILS TO AA AA CONTACTS CREDIT
`
`CARD SERVER AND
`VERFIES TRANSACTION
`
`
`
`
`530
`
`6
`
`

`

`US 6,463,534 Bl
`
`1
`SECURE WIRELESS ELECTRONIC-
`COMMERCESYSTEM WITH WIRELESS
`NETWORK DOMAIN
`
`FIELD OF THE INVENTION
`
`This invention relates to secure electronic commerce
`distribution and sales having the ability to offer software
`enhancements and new features in a simpler, faster, and
`cheaper method than previously available. Secure electronic
`commerce brings together three important functions: repro-
`grammable software or other content (generically referred to
`also as “product”, which includes services); wireless data
`service; and security (encryption & authentication).
`
`BACKGROUND OF THE INVENTION
`
`Secure electronic commerce offers a way for customers to
`add or change features in their phone using the convenience
`of the wireless data service already available in the phone.
`Moreover,
`the customer can achieve these goals within
`minutes and in the comfort of the customer’s home or
`business.
`
`Secure electronic commerce offers many advantages,
`among them: greater ease of distribution, sale and revenue
`collection for software-only features; flexible and upgrade-
`able phone platform—this reduces obsolescence; ability to
`thwart theft ofservices and cloning; reduced warranty costs
`in case of software patch updates; and convenience of
`wireless reprogramming.
`
`SUMMARY OF THE INVENTION
`
`In one aspect, the present invention provides a methodof
`conducting transactions in a wireless electronic commerce
`system, where the system comprises a wireless network
`operator certification authority having a root public key
`certificate andat least one attribute authority having a digital
`certificate that
`is dependent
`from the root public key
`certificate, where the attribute authority is accessible by a
`wireless client device via a wireless network. The digital
`certificate is delivered from the attribute authority to the
`wireless device,
`the attribute authority is verified to the
`wireless client device using the digital certificate and the
`root public key certificate pre-loaded in the wireless client
`device under authority of the wireless network operator. An
`attribute (software, service, right/permission or other con-
`tent item) is delivered to the wireless client device over the
`wireless network and ultimately enabled at
`the wireless
`client device.
`
`Payment for the attribute may be transacted by delivering
`a second digital certificate from the wireless client device to
`the attribute authority and verifying the second digital
`certificate using the root public key certificate from the
`certification authority.
`the invention provides a method of
`In another aspect,
`conducting transactions in a wireless electronic commerce
`system that includes establishing a wireless communication
`between the wireless client device and a
`first attribute
`authority; delivering a first attribute to the wireless client
`device over the wireless network; generating an electronic
`voucher verifiable by a secondattribute authority; establish-
`ing a wireless communication between the wireless client
`device and the second attribute authority;
`requesting a
`second attribute from the secondattribute authority; identi-
`fying the electronic voucher at the second attribute author-
`ity; and delivering the second attribute from the second
`attribute authority to the wireless device.
`
`15
`
`20
`
`25
`
`30
`
`40
`
`$0
`
`55
`
`60
`
`65
`
`2
`The electronic voucher may be delivered from the first
`attribute authority to the second attribute authority via a
`connection therebetween or may include delivering the
`electronic voucher from the first attribute authority to the
`second attribute authority via the wireless client.
`Also described is a wireless electronic commerce system.
`
`
`
`AA
`API
`CA
`DER
`EC
`GSM
`ID
`ME
`PER
`PIN
`PK
`PKI
`RA
`RSA
`SHA-1
`SIM
`SMS
`WAP
`WIM
`WML
`WMLScript
`WDP
`WILs
`
`Glossary of Abbreviations
`
`Attribute Authority
`Application Programming Interface
`Certification Authority
`Distinguished Encoding Rules (ASN.1)
`Elliptic Curve
`Global System for Mobile Communication
`Identifier
`Mobile Equipment
`Packed Encoding Rules (ASN.1)
`Personal Identification Number
`Public Key
`Public Key Infrastructure
`Registration Authority
`RSA(Rivest, Shamir, Adleman) public key algorithm
`Secure Hash Algorithm 1
`Subscriber Identity Module
`Short Message Service
`Wireless Application Protocol
`Wireless Identity Module
`Wireless Markup Language
`Wireless Markup LanguageScript
`Wireless Datagram Protocol
`Wireless Transport Layer Security
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG, 1 is a block diagram ofa secure wireless electronic
`commerce system in accordance with a first aspect of the
`invention.
`
`FIG, 2 is a flow diagram illustrating software installation
`and boot-up steps for the wireless client device of FIG, 1.
`FIG. 3 is a flow diagram illustrating steps in a process of
`software download to a wireless device in the field or
`enabling of software in a wireless device in the field.
`FIG. 4 is a block diagram of a secure wireless electronic
`commerce system in accordance with a secondaspect of the
`invention,
`
`FIG, 5 ts a flow diagram illustrating steps of operation of
`the system of FIG. 4.
`DETAILED DESCRIPTION OF THE DRAWINGS
`
`The overall security model employs cryptographic API
`and underlying cryptographictoolkits providing a base level
`of security features, which other stack layers, such as a
`Wireless Transport Layer Security (WTLS) API, certificate
`standardization, and wireless applications such as a Wireless
`Application Protocol (WAP) browser, can build upon. FIG.
`1 showsthe entities and relationships ofthe system.
`The customer interfaces with the secure electronic com-
`merce system 10 by using a wireless phone 11 or other
`wireless device plus a
`landline phone 12 or
`Internet-
`accessible computer (dialup, Ethernet, cable, etc.) 13. Vari-
`ous servers 15, 16, 17, 18 within the system 10 perform the
`tasks of secure electronic commerce. Whether directly
`accessing through an Internet connection 13, or using a
`conventional
`telephone 12 to talk with an operator,
`the
`customer inputs an order to the secure electronic commerce
`system 10 at the Web server 16.
`The web server 16 communicates with the Certificate
`Authority server 15 to issue a new Product Certificate. This
`
`7
`
`

`

`US 6,463,534 Bl
`
`3
`certificate will ensure that only the targeted phone 11 will be
`able to obtain and use the new feature. Because the phone
`originally contained a Product Certificate from the Software
`Server 17 (while in the factory), an audit
`trail, or
`accountability, is maintained for the life of the phone. The
`phone 11 cannot operate software it was not allowed to
`based on the content of the certificate. The system 10 also
`contains a copy of the phone’s certificate and so it has a
`record of the capabilities of the phone.
`The Certificate Authority server 15 is a server which
`creates and distributes Public Key Certificates and License
`Certificates throughout the secure electronic commerce sys-
`tem.
`License Certificates allow devices, such as wireless
`phones,
`to operate specified software products. License
`Certificates are issued to each manufactured device prior to
`leaving the factory, and subsequently when new software is
`bought. License Certificates include the device’s serial num-
`ber as part of the data, which when digitally signed by the
`CA, will bind the right-to-use software license only to the
`phonethat has that serial number, which by design must be
`unalterable. Therefore, these certificates can only be used by
`the targeted party and no oneelse.
`Public Key Certificates enable devices to establish trust
`through the CA. The CA digitally signs the certificate stating
`that a given device, denoted by its serial number, has the
`following public key associated with it.
`The WebServer 16 is the front-end server for the secure
`electronic commerce system. It may be a series of servers
`(i.e. order entry, billing, order processing, etc.) but concep-
`tually is thought of as one entity. This server contains the
`order entry system by which customers enter orders. Orders
`may be taken online through the Web, or by phone via an
`operator. This server completes the order entry by first
`verifying the user’s information (user name, device serial
`number, credit card, etc.). The Web server then sends a
`request to the CA for a new License Certificate.The CA
`sends the License Certificate to the device. The License
`Certificate may be “pushed” by the CA or sent on-demand
`from the device. The device now holds the new License
`Certificate and has been authorized to use the new software.
`The Software Server 17 makes available all of the soft-
`ware products sold by the system provider/operator. It may
`be a series of servers including various factory servers but
`conceptually is thought of as one entity. The function of the
`Software Server 17 is to digitally sign software products and
`make the software product and corresponding certificate
`(known as the Product Certificate) available for download.
`The function of the WAP Proxy Server 18 is to translate
`HTMLsyntax into WMLsyntax (Internet to WAP protocol)
`and vice-versa.
`Certificates are the cornerstone of the secure electronic
`commerce system and a description ofdigital certificates can
`be found in Draft American National Standard X9.68-199x:
`Digital Certificates for Mobile, Account Based and High
`Transaction Volume Financial Systems, available from
`American Bankers Association Standards Department 1120
`Connecticut Avenue., NW Washington D.C. 20036.
`Various of the protocols and techniques in the secure
`electronic commerce system 10 operate on certificates
`(either reading/parsing certificates, or adding/modifying/
`deleting certificates). Every device (servers 16, 17 and 18
`and wireless devices 11) in the system has one or more
`certificates. They all have a trusted root certificate which is
`the Public Key Certificate of the CA from the CA server 15.
`Given this, the secure electronic commerce system can be
`deployed.
`
`15
`
`30
`
`40
`
`$0
`
`55
`
`60
`
`65
`
`4
`There now follows a description of the basic certificate
`types and the use ofcertificates in the lifetime of a phone.
`A Public Key Certificate contains information that ties a
`wireless device 11 with its public key. This is accomplished
`by hashing the relevant data. The certificate is comprised of
`the aforementioned data plus the hash result. Anyone wish-
`ing to verify whether the public key belongs to the device
`only needs to hash the data again, andverify that it matches
`the hash result stored with the certificate.
`
`Additionally, the hash is digitally signed by a certifying
`authority.
`In this model
`the CA is the trusted certifying
`authority. That is, the previously mentioned hash result is
`signed with the CA’s private key. Anyone who has the
`public key for the CA will be able to verify the encrypted
`hash. Subsequently, if the verified hash result matches that
`of the user-computedhash of the certificate data, that tells
`the userthat (1) the certificate must have been signed by the
`trusted CA since the CA’s public key was able to properly
`verify the signed hash and(ii) the certificate does belong to
`the subject because the subject’s private key can verify data
`signed by the public key.
`ties a
`A License Certificate contains information that
`wireless device 11 with certain access rights. In particular, a
`License Certificate contains, at a minimum, fields for soft-
`ware product and device serial number. The software prod-
`uct field contains a product identifier. This identifier grants
`the device a license to use the product. A device will be able
`to run the specified software product if its internal serial
`number, embedded in the device, matches the License
`Certificate’s serial number. As in the Public Key Certificate,
`the data in the License Certificate is hashed and signed by
`the CA. The device will not be able to verify forged License
`Certificates since it won't be able to validate the certificate
`to the CA’s signature (unless the CA has been
`compromised),
`A Product Certificate ties a content item or subject (e.g. a
`software product name) to a fingerprint. In this case, the
`fingerprint is the hash of the software product. Therefore,
`anyone who has a software product along with its Product
`Certificate can verify the integrity of the software by com-
`paring a user-computed hash of the software with the hash
`result stored in the certificate. As in the Public Key
`Certificate,
`the hash result in the Product Certificate is
`digitally signed by the Motorola CA. So, when the user
`compares the computed hash with the Product Certificate’s
`hash result, a match implies that the software product is the
`same which the Motorola CA had digitally signed.
`Having described the various infrastructure devices and
`the role that certificates play in the system, the way in which
`the secure electronic commerce system is deployed can now
`be described.
`The following sections describe briefly how the system
`functions using examples that occur for a device. The
`examples chosen are for a phone, and include what happens
`when the phoneis setup in the factory, what happens when
`a user turns on and uses the phone, and what happens when
`a user wants to obtain a new feature.
`
`Each phone in the factory has certain some unique char-
`acteristics built-in before the unit is shipped. Physically, the
`phone must contain: (1) ROM available to run unalterable
`certificate verification code; (ii) EEPROM availableto store
`certificates (access to the certificates storage area must be
`restricted) and (iii) an unalterable unique serial number
`(either in ROM, laser-etched, write-once memory, etc.)
`At the factory, a Public Key Certificate is generated for
`the phone (step 100 of FIG. 2), This can be generated by the
`
`8
`
`

`

`US 6,463,534 Bl
`
`5
`Software Server 17, the CAserver15, or by the phone itself.
`The CA server 15 digitally signs the certificate and retains a
`copy of it (step 101). The phone is installed with its own
`Public Key Certificate, plus the CA’s Public Key Certificate
`(102). (The CA, being the root certifying authority, signsits
`owncertificate.) A key. assumption is that inside the factory
`there is a trusted network. In this environment, the genera-
`tion of the phone’s Public Key Certificate, its signing by the
`CA,andthe certificate and CA’s public key transference into
`the phone are deemed to be secure.
`Also at the factory one or more License Certificates are
`issued (step 104). The factory sends a request to the CA
`server 15 (or the software server 17 under the root authority
`of the CA server 15) to sign a License Certificate (step 105).
`The factory provides the CA information on which software
`licenses or products the phone is supposed to have along
`with the phone’s serial number. The License Certificate
`includes the following information: (i) the CA’s identifica-
`tion (the issuer); (ii) the serial number of the phone (the
`subject); (iii) a list of software products the phoneis licensed
`to run; and (iv) a signed (encrypted with CA’sprivate key)
`digest (software hash) of the aforementioned components.
`The license certificate is installed in the phone at step 106.
`The License Certificate may contain multiple licenses in
`one certificate, or there may be multiple License Certificates
`with one license per certificate. Both methods are allowed.
`The CA itself will retain a copy of the phone’s License
`Certificate(s).
`Now, the phone enters the software programming phase.
`The phone must contains various amounts of software—
`some base version plus some (optional) additional features,
`depending on what was ordered. The factory must install the
`correct software package(s) into the phone. The software
`packages include the software itself plus a Product Certifi-
`cate (or more generally a content
`item certificate), The
`Software Server 17 generates a Product Certificate (step
`110) for each software product under the same root authority
`as the CA. Both the software and Product Certificate are
`stored on the Software Server 17. The Software Server 17 is
`responsible for managing the software products and making
`them available for download. The software package andits
`certificates (i.e. digitally signed software) is installed in step
`112.
`
`The purpose ofthe certificate is to bind (i.e associate) the
`software product to a particular name(¢.g. software product
`name and major version number). This association may be
`in the form of a look-up list of product names associated
`with the certificate of a product name anda predefined rule
`identifying permitted new product names (e.g. Browser
`version 1.x permits all future versions of Browser between
`version 1.0 and version 2.0). The certificate contains the
`name of the software along with a hash of the software
`product. Anyone wishing to validate the integrity of the
`software can hash the software and compare it to the one
`found in the Product Certificate. The certificate is signed by
`the Software Server. The Software Server itself has a Public
`Key Certificate signed by the CA, so a line oftrust is
`maintained,
`
`The Product Certificate includes the following informa-
`tion: (i) the Software Server’s identification (the issuer); (ii)
`the software products name (the subject); (iii) a hash ofthe
`software product; and (iv) a signed (encrypted with Software
`Server's private key) digest of the above components.
`The Software Server 17 retains a copy of the Product
`Certificates. It should be noted that
`the CA 16 may also
`perform the function of the Software Server 17,
`in which
`case the CA will be responsible for all
`three types of
`certificates.
`
`15
`
`20
`
`25
`
`30
`
`40
`
`$0
`
`55
`
`60
`
`6
`The phone leaves the factory installed with: (i) the CA’s
`Public Key Certificate; (11) the phone’s Public Key Certifi-
`cate; (iii) one or more License Certificates; and (iv) one or
`more Product Certificates.
`
`Aseries of steps takes place every time a user turns on the
`phone. First, the phone’s boot software validates all of its
`Product Certificates (step 130). That is, a hash is computed
`for each software productin the phone and compared against
`the hash stored in the certificate. Also, a line of trust to the
`CA must be established. Since the Product Certificate was
`signed by a Software Server, not the CA, the phone will
`obtain the Software Server's Public Key Certificate from the
`CA (this should only occur one time after which the phone
`will store the Software Server’s Public Key Certificate in
`memory). Next, the phone’s boot software validates (step
`135) all of its License Certificates. That it is, a comparison
`between the phone’s unalterable serial numberandthe serial
`number stored in the License Certificate(s) associated with
`the products is made. If they match then the phone is allowed
`to operate the software products identified in the License
`Certificate. The software products identified in this certifi-
`cate must match the software Products name field in the
`Product Certificates. in both steps, the phone’s boot software
`compares the digital signature of the certificates with the
`CA’s Public Key Certificate (which was installed in the
`factory) to ensure that forged certificates were not installed.
`In the event that a user wants to modify the phone, such
`as enabling an option or purchasing a new feature (see
`Examples below), a new License Certificate is obtained
`along with the software product
`itself plus its Product
`Certificate. The following steps take place. First, the user
`purchases the feature through the Web Server 16, Whether
`by phone or Web access, the user submits the necessary
`information to the Web Server 16, including name, address,
`credit card number, the phone’s serial number, and desired
`product to purchase (step 16). The Web Server 16 verifies
`the information and creates an order ticket which is also
`given to the customer. Assuming the customers credit has
`been validated, the Web Server 16 sends the phone’s serial
`number along with the name of the software product
`purchased,
`to the CA server 15 to obtain a new License
`Certificate. The License Certificate is made available to the
`phone to download (step 204). The user may initiate a
`sequence to obtain it. The phone validates the new License
`Certificate. If the software product was installed in the
`factory but not enabled (no license certificate), it will now be
`enabled (step 220). If the software productis not foundin the
`phone, it will send a requestto the Software Server to obtain
`it (step 226).
`the Software Server 17 may be
`As an optional step,
`configured to send software products encrypted and only to
`authenticated users, in order to prevent overloading of the
`wireless network and to prevent unauthorized users from
`obtaining the software code (despite the fact that the phone
`cannot run the software anyway without a valid License
`Certificate). This is done by establishing a WTLS connec-
`tion between the Software Server 17 and the phone 11 via
`the WAP proxy server 18. Each. party has a Public Key
`Certificate signed by a common CA, so they trust each
`other’s certificates. Using a key exchange algorithm, a secret
`key is derived and usedfor encrypting the software product
`and Product Certificate. The Software Server then sends the
`software product and Product Certificate over the air to the
`phone, the phone validates the Product Certificate and the
`purchase is complete.
`Note that in this model, if the download is interrupted or
`the software is corrupted, the user can retry the download
`any number of times.
`
`9
`
`

`

`US 6,463,534 Bl
`
`7
`In the event that the phone has to be brought in to a repair
`shop, there are a number of features in the secure electronic
`commerce system available to make updates or modifica-
`tions to the phone a painless one. For example, if for some
`reason a different phone is issued to the user, the repair shop
`could transfer all of the contents of the existing phone
`(software and Product Certificates) into the new one. The
`new phone will not be able to run the software until a new
`set of License Certificates is generated for that phone’s serial
`number. The repair shop requests new License Certificates
`from the CA using the repair shop’s Public Key Certificate
`as proof to the CA that it is empowered to do so. The CA has
`on record the License Certificates for the existing phone.
`New License Certificates are issued for the new phone, and
`the existing phone’s License Certificates are put on a cer-
`tificate revocation list. If for some reason the repair shop
`needed to copy software into the new phone and was unable
`to copyit from the existing phone, the software (and Product
`Certificate) could still be downloaded from the Software
`Server as described previously.
`By implementing the secure electronic commerce system,
`new features, updated software, and software patches can be
`delivered to the phone in a timely efficient manner for the
`customer, The customer benefits from the ease of performing
`the tasks, and the almost immediate cycle time to achieveit.
`Furthermore, the security features built into the system will
`reduce incidents of theft of service or cloning.
`The following examples help clarify what potential solu-
`tions are available in a secure electronic commerce envi-
`ronment for some real world situations.
`
`EXAMPLE1
`Acquiring an Application not Currently in the Phone
`A.useris travelling overseas and wants to have access to
`a voice activated German/English translator on their phone.
`The user can purchase the German/English translator soft-
`ware product from the manufacturer or retailer. The user will
`download the application into the phone and the German/
`English translator is operated locally on the phone, rather
`than through the service provider's infrastructure. This is
`more cost effective if the user plans to use the feature on a
`regular basis. The user feels a sense of ownership, As long
`as the user keeps the phone, he/she owns the software. The
`software operates locally in the phone, The user does not
`access the feature over the air,
`thereby climinating any
`potential out-of-service conditions, bandwidth or throughput
`issues, or unexpected infrastructure downtime. The user
`pays the manufacturer or the retailer for the feature, rather
`than the service provider.
`
`EXAMPLE2
`Enhanced Phone Feature
`A.user wants to be able to use a new Web browser now
`available for the phone, either by downloading the software
`(if the phone did not contain the software when purchased)
`or by enabling access rights to the feature already stored
`within the phone. The user connects the web server 16 (or
`1-800 number), follows instructions to purchase additional
`optionsfor the phone, and waits a short time for the software
`to be downloaded, or enabled, with the new Web browser
`capability. The user gains instant satisfaction by accessing
`the feature minutes after the purchase is made. The cost of
`the feature is lower than it would otherwise be because the
`overhead to bring the feature to the user via electronic
`downloadis low. Because the transactionis authenticated by
`the certificate authority via the CA server 15, theft of service
`is Virtually eliminated.
`
`15
`
`25
`
`30
`
`40
`
`$0
`
`55
`
`60
`
`65
`
`8
`EXAMPLE3
`Software Patch Update
`A software patchis issuedto the field to be installed in an
`existing phones(e.g. under warranty for no charge). The user
`is instructed how to enable the phone to begin a download
`containing the updated software. Another optionis that the
`service provider can automatically update phones while the
`phoneis in service, without the user aware of the upgrade.
`The user does not need to physically return the unit to a
`service shop. The user’s phone is updated in a matter of
`minutes, rather than days spent in a service shop. An instant
`electronic record of the software downloadis retained in the
`
`system 10, rather than relying on field service reports.
`Certain upgrades can be done automatically without the
`user's consent, thereby eliminating any service interrup-
`tions. The cost
`is minimal because no service shop is
`involved in the procedure.
`EXAMPLE4
`
`Metered Service
`
`A.user wants to access an audio bookin his/her car during
`the commute to/from work. The user can purchase an audio
`book from a service provider. Access may be gained by
`means of a secure data service connection which allows the
`metered service (either per book or per minute). Among
`other options, two-way communications allow the user to
`suspend/resume the transmission. This is a new type of
`service not achievable without secure electronic commerce.
`Thus a wireless electronic commerce system has been
`described having a wireless gateway 18 to a wireless net-
`work 19 with which a wireless client device 11 having a
`unique client identifier is capable of communicating.Atleast
`one server has been described coupleable to the wireless
`gateway, delivering content items to the wireless device and
`maintaining digital content certificates for content items and
`digital license certificates for licenses for the content items.
`In the preferred embodiment
`the server 17 delivers the
`content and the CA server 15 maintains the digital license
`certificates. The at
`least one server maintains, for each
`wireless client associated with the system, a record of
`licenses for that client and a record of content items asso-
`ciated with each license. In other words, the CA server 15
`maintains a database or list correlating wireless client IDs
`with licenses (or license certificates) for each client ID and
`content items (e.g. software products) associated with the
`licenses.
`It has been described that the wireless client is able to
`request digital
`license certificate verification for a new
`content item when the new content item is associated with
`an existing digital license certificate that is associated with
`the client identifier. Contentofa first wireless client with a
`first identifier is preferably able to be replicated in a second
`wireless client with a second identifier by reloading the
`content to the second wireless client; replacing,
`in the at
`least oneserver,a first association between thefirst identifier
`and correspond