PWEGA 01/913‘Mé
`
`
`
`u.x<
`
`,1H.
`
`v:
`
`PA 494424
`
`
`
`
`Infiifii
`
`
`
`
`
`
`
`
`
`
`
`“Emma
`
`UNITED STATES DEPARTMENT OF COMMERCE
`
`United States Patent and Trademark Office
`
`November 27, 2001
`
`THIS IS TO CERTIFY THAT ANNEXED HERETO IS A TRUE COPY FROM
`THE RECORDS OF THE UNITED STATES PATENT AND TRADEMARK
`
`OFFICE OF THOSE PAPERS OF THE BELOW IDENTIFIED PATENT
`APPLICATION THAT MET THE REQUIREMENTS T0 BE GRANTED A
`
`FILING DATE UNDER 35 USC 111.
`
`APPLICATION NUMBER: 60/270,663
`
`FILING DATE: Februaly 20, 2001
`
`PRIORIT
`
`DOCUMENT
`SUBMITTED OR TRANSMITTED IN
`COMPLIANCE WITH RULE 17.1(a) OR (b)
`
`By Authority of the
`
`effigy/w
`
`N. WOODSON
`
`Certifying Officer
`
`«3:323.
`
`
`
`
`
`
`
`
`.3“;1:3s:_memmamgugL13:
`
`
`mum.
`
`
`mummmmxmmmin
`
`
`
`
`Page 1 of 30
`
`GOOGLE EXHIBIT 1005
`
`

`

`fl; "2/ —-0/
`
`Pleasety ea lus si n + inside this box —’ +
`p
`P
`9 ( )
`
`PTO/$5116 (8-00)
`Approved for use through10l31/2002. 0MB 0651-0032
`US. Patent and Trademark Office; U.S. DEPARTMENT OF COMMERCE
`-:ier the PapenNork Reduction Act or 1995. no persons are required to respond to a collection of Information Unless it displays a valid OMB control number.
`PROVISIONAL APPLICATION FOR PATENT COVER SHEET
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 153(c)-
`INVENTOR(S)
`
`Residence
`
`r,2,M/JJIIIHIIIIIII
`
`°Michael
`
`Brown
`
`P.O. Box 216, 7 Danube Drive
`Heidelberg, Ontario NOB 1Y0
`CANADA
`
`Family Name or Surname
`
`Ci
`
`and either State or Forei n Coun
`
`Additional inventors are being named on the __ separater numbered sheets attached hereto
`TITLE OF THE INVENTION 280 characters max
`
`CODE 5 IGNING SYSTEM AND METHOD
`
`Bar Code Label here
`
`~
`
`Firm or
`Individuamame
`
`Address
`
`FILING FEE
`
`AMOUNT $
`$ 19 0 ' 00
`
`l
`
`RESPMWW Date
`‘
`I
`SIGNATURE
`REGISTRATION N0.
`
`TYPED or PRINTED NAME _———f———-———-DavidB - COChran
`(ifappmpfiate)
`Docket Number:
`
`4
`
`3 9 , 14 2
`
`555255012198
`
`USE ONLY FOR FILING A PROVISIONAL APPLICATION FOR PATENT
`This collection of information is required by 37 CFR 1.51. The information is used by the public to file (and by the PTO to process) a
`provisional application. Confidentiality is govemed lg! 35 use. 122 and 37 CFR 1.14. This collection is estimated to take 8 hours to
`complete, including athen'ng, preparin , and subml
`'ng ‘Ihe complete rovisional a plicalion to the PTO. Time will va
`depending u
`n
`the IndIVIdual case.
`y comments on
`e amount 0 time you require 0 complete
`is form andIor suggestions for re using this bur en,
`should be sent to the Chief lnfon'nation Officer US. Patent and Trademark Office, US. De anment of Commerce, Washington, 0.0.
`20231. DO NOT SEND FEES OR COMPLETED FORMS TO THIS ADDRESS. SEND O: Box Provisional Application, Assistant
`Commissioner for Patents, Washington, DC. 20231.
`
`Direct all correspondence to:
`CORRESPONDENCE ADDRESS
`a: ——+
`OR
`Type Customer Number here
`-
`Dav1d B. Cochran, Esq.
`Jones, Day, Reavis 6; Pogue
`North Point, 901 Lakeside Avenue
`Cleveland was
`16 586—3939
`I
`ENCLOSED APPLICATION PARTS check all thata - I 1
`Specification NumberofPages
`mgkmm t
`[El Drawing(s) NumberofSheets
`omefls edfy)
`error of Attorney fo
`p
`rovi ions. 5,--
`I: Application Data Sheet. See 37 CFR 1.76
`METHOD or PAYMENT OF FILING FEES FOR THISAL APPLICATION FOR PATENT
`I:
`Applicant claims small entity status. See 37 CFR 1.27.
`CI
`A check or money order is enclosed to cover the filing fees
`X
`The Commissioner is hereby authorized to chargefiling _
`fees or credit any overpayment to Deposit Account Number:
`50l432
`[1 Payment by credit card. Fom'I PTO-2038 is attached.
`Ref :
`555 255 0 1 2 1 9 B
`The invention was made by an agency of the United States Government or under a contractwith an agency of the
`United States Government.
`,
`@ No.
`[:1 Yes, The name of the us Government agency and ihe Government contract number are: ___________,________.____.__
`______—4
`
`Address
`
`Page 2 of 30
`
`

`

`PROVISIONAL APPLICATION COVER SHEET
`Additional Page
`
`PTO/$5116 (8-00)
`
`David
`
`Yach
`
`254 Castlefield Ave.
`Waterloo, Ontario NZK 2N1
`CANADA
`
`U.S. Patent and Tra emafk Office, U.S, DEPARTMENT OF COMMERCE
`Agrroved for use mmth 1013172002. 0MB 0651-0032
`Under the Paperwork Reduction AC1 of 1995, no persons are requlrzd to res and to a collection of Information unless It dis [a s a valid OMB comm! number.
`Docket Number
`555255012198
`INVENTOR(S)IAPPUOANT(S)
`_Given Name first and middle
`an
`Famii or Surname
`Ci
`and either State or Forei n Coun
`Herb
`Little
`523A Rosemeadow Crescent
`Waterloo, Ontario NZT lZ9
`CANADA
`
`be included on this form. Provide credit card Information and authorization on PTO—2038.
`
`Number
`
`1
`
`WARNING: information on this form may become public. Credit card information should not
`
`Page 3 of 30
`
`

`

`Title:
`
`Code Signing System and Method
`
`lnventor(s):
`
`Michael Brown, Herb Little, David Yach
`
`Assignee:
`
`Research In Motion Limited
`
`BACKGROUND OF THE INVENTION
`
`Field of the Invention
`
`This invention relates to security protocols with dynamic library linking
`
`digital signature to a program in order to use it on a mobile communications device.
`
`9
`9
`programs such as JavaTM programs. Specifically, this invention relates to assi nin a
`
`-1-
`
`Description of the Prior Art
`
`When an application program arrives at a mobile communications device
`
`such as the RIM Wireless Handheld 957TM or a multiple mode device incorporating both
`
`data and voice communications features, there is a need to control the access that the
`
`application has. For example, if such a device is to be exported, access to any strong
`
`cryptographic routines residing on the device must be restricted.
`
`interfaces to a radio
`
`transmitter may be protected so that destructive applications are unable to flood a wireless
`
`network with transmission signals; similarly, interfaces to a database or file system may be
`
`protected so that destructive applications are unable to fill a device’s storage space with
`
`unwanted data or alter existing data.
`
`One scheme for protecting interfaces involves application software signing,
`
`commonly called code signing. In conventional code signing schemes, an application
`
`Page 4 of 30
`
`

`

`application. If the author is a trusted source, the application may be loaded and executed
`
`on the device.
`
`Most known code signing schemes grant access to device or system
`
`resources for an application program based on authentication of the author of the
`
`application. However, there remains a need for a code signing scheme which provides for
`more selective resource access restriction, based on the particular application instead of
`
`solely upon author authentication.
`
`SUMMARY OF THE INVENTION
`
`it is therefore an object of the invention to provide an improved coding signing
`
`program developer or author generates a signature indicating the identity of the author and
`appends the signature to the application. Upon the arrival of a signed application at a
`device such as described above, the signature is used to authenticate the author of the
`
`-2-
`
`system and method.
`it is a related object of the invention to oversee the management and
`
`execution of Java and other dynamic library link-based applications arriving at a mobile
`
`communications device.
`
`It is a further object of the invention to verify that any application has been
`
`digitally signed as having permission to carry out its intended functions.
`
`A still further object of the invention is to prevent unacceptable applications
`
`from gaining access strong cryptographic routines and any other application programming
`
`interface (API) designated by the API author as “sensitive”.
`
`In the present invention, digital signatures are used to control access to
`
`Page 5 of 30
`
`

`

`sensitive APls, thereby allowing access to only those applications that have been digitally
`
`of the conventional authentication scheme. According to this aspect of the invention, a
`
`5
`
`device checks a digital signature appended to an application to determine whether or not
`
`signed by the author of a sensitive API or by a signing authority acting on behalf of the API
`author. The invention thereby advantageously implements an authorization scheme instead
`
`-3-
`
`the application has been authorized to access device resources.
`
`In a preferred embodiment of the invention, a Java application, which will
`
`access a sensitive API, is developed to run on a device.
`
`in order to run on the device and
`
`access the sensitive API, the author of the API must approve the application by attaching a
`
`digital signature using the author’s private key. Before the application can be executed on
`a device, the signed application will be verified. The author of any APl may decide that the
`
`API should not be exposed to every application on the device, but only to those that have
`
`been verified to be non-destructive, orforwhich some business arrangement pre-exists, for
`
`example.
`
`Further features of the invention will be described or will become apparent in
`
`the course of the following detailed description.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`In order that the invention may be more clearly understood, embodiments
`
`thereof will now be described in detail by way of example, with reference to the
`
`accompanying drawings, in which:
`
`Fig. 1 is a system diagram of a first preferred embodiment the invention;
`
`Figs. 2A and ZB illustrate components of a device on which an application
`
`Page 6 of 30
`
`

`

`may be loaded and executed;
`Fig. 3 is a detailed flow diagram of the signing process according to the first
`
`embodiment;
`
`Fig. 4 is a detailed flow diagram of the handling of a signed application on the
`
`5
`
`device in accordance with the first embodiment;
`Fig. 5 is a system diagram of a second preferred embodiment the invention;
`
`Fig. 6 is a detailed flow diagram of the signing process according to the
`
`second embodiment; and
`Fig. 7 is a detailed flow diagram of the handling of a signed application on the
`
`0
`
`device in accordance with the second embodiment.
`
`application, creating the signed application 8. The signed application 8 may now access
`
`application Y can be executed and granted access to the sensitive API 6, a code signer 10,
`which may be the author of the sensitive API or a competent signing authority chosen by
`the API author and acting on behalf of the API author must sign the application. That is,
`using the author's private key, code signer 10 must attach a digital signature to the
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
`
`Several embodiments of the invention will now be described with reference to
`
`Figures 1-8.
`
`FIG 1 is an overall system diagram of a first embodiment of the invention. An
`
`application developer 2, creates an application Y, 4, such as a Java application, to run on
`the device 12 and access some sensitive API 6.
`In this embodiment, before the device
`
`20
`
`Page 7 of 30
`
`

`

`and appended to the application. It is also contemplated that a single signature may grant
`
`access to a group of related APls. Signature requirements are easily established in
`
`accordance with any desired level of control of API access.
`
`The signed application 8, having one or more appended signatures, may be
`
`sent via the wireless network 9 or via a serial link (not shown) to the device. In the example
`
`of a Java application, a Java virtual machine (as shown in Fig. 2A) on the device will verify
`
`the digital signature of the signed application 8 before allowing the signed application
`
`access to the sensitive API.
`
`the sensitive API it requires when it arrives on the device.
`If access to more than sensitive
`API is required by the application, a unique signature is preferably generated for each API
`
`applications. Where the device 12 is a multiple mode device capable of data and voice
`
`FIG 2A is a'diagram of the basic components of the invention on the device,
`
`including the Java virtual machine 20, applications 22, and libraries 24. Although the
`
`device represented in Fig. 2A is enabled for Java applications, the invention is in no way
`
`limited thereto. References in this description to Java applications and associated device
`
`components are for illustrative purposes only. As described above, the invention is
`
`applicable to other dynamic library linking-based applications which require access to
`
`device libraries or interfaces.
`
`The Java virtual machine 20 is responsible for managing the linking and
`
`execution of all Java applications that are running on the device. The applications may be
`
`sent to the device over the wireless network or through a serial link. As shown in FIG 23,
`
`the applications 22 may include some signed applications 23 as well as some unsigned
`
`Page 8 of 30
`
`

`

`
`
`
`
`
`
`.32..llitilfll...“‘51:)“ _L o
`
`communications for example, the applications may include data applications, voice
`
`applications and possibly applications relating to both data and voice functionality.
`
`If a library on the device 12 exposes a sensitive API,
`
`it must contain the
`
`following three items:
`
`a) A string 26 that provides a short description of the contents of the library;
`
`b) A public key 28 corresponding to the private key held by the code signer 10, which
`
`public key will be used to verify signatures on signed applications that require
`
`access to the sensitive API; and
`
`c) An API identifier 30 that uniquely identifies the sensitive API. If a library exposes
`
`more than one sensitive API, the library will include an identifier for each sensitive
`
`API.
`
`Any signed application 23 on the device must contain the following three items:
`
`a) The Java byte code that is to be run;
`
`b) One or more digital signatures; and
`
`c) An API identifier for each digital signature indicating which API the digital signature
`
`protects.
`
`FIG 3 is a flow diagram of the code signing scheme ofthe first embodiment. it
`
`on a device, through a library X for example as shown at step 40, then the finished
`
`application will need to be signed before it can run on the device. The developer can write
`
`such an application 4 (FIG 1) and test it in a locally available device simulator environment
`
`in which signature checking is disabled (step 42). Once the developer is satisfied that the
`
`an application developer is writing an application that will require access to a sensitive APl
`
`Page 9 of 30
`
`

`

`protected API, in step 44. . As indicated at step 46, the code signer for the protected API
`
`reviews the application and verifies that it may be granted access to the sensitive APl on
`
`the device 12. The code signer may apply a plurality of criteria to determine whether or not
`
`such access to the sensitive API is to be granted, including but in no way limited to: a
`
`maximum application size restriction, the specific device resources used by the application,
`
`the perceived utility and value of the application to a device user, its interaction with other
`
`applications on the device, and perhaps most important, whether or not the application
`
`appears to contain a virus or destructive code.
`
`application is working properly, the application is submitted to the code signer for the
`
`to it. As described above, the code signer may be the API author or a signing authority
`
`In step 48, the code signer makes a determination of whether or not to sign
`
`the submitted application. If the code signer is satisfied, then in step 50, the code signer
`
`generates a signature, preferably using a hash of the application and a private key, and
`
`appends the digital signature (including the API identifier) to the application. Where the
`
`application requires access to more than one sensitive APl such that more than one
`
`_|. U]
`
`it,“ii...lt
`"iii;
`
`signature is required, steps 46 through 54 would be repeated (not shown). The signed
`
`application is then returned to the application developer as in step 52. Provided that all
`
`required signatures granting access to all required APls have been appended to the
`
`application, the application developer may then send the signed application, as in step 54,
`
`to a real device for execution therein. in step 56, if the code signer does not accept the
`
`code or does not wish to grant access to one or more of the required APls, the developer
`
`receives a rejection notice and the submitted application will not run on the device, if sent
`
`Page 10 of 30
`
`

`

`acting on behalf of the APl author.
`
`FIG 4 is a flow diagram of a method, in accordance with the first embodiment
`
`of the invention, that a device uses to handle a signed application. Once an application
`
`has arrived on the device in step 60, through a wireless communication link or a direct
`
`connection to the device, the virtual machine 20 may begin the verification process. Any
`
`libraries that the application requires must also be present on the device before the
`
`process can continue. Once the device has all of the libraries required by the application, it
`
`will determine if the application needs access to a sensitive APl within one of these
`
`libraries, in step 62.
`
`If not, the application can be linked with all of the libraries it requires,
`
`and executed in step 76.
`
`in step 64, if the application does require access to a protected
`
`'APl, the virtual machine can extract the public key and API identifier from the library
`
`exposing the API. Then, in step 66, the virtual machine looks through all of the signatures
`
`appended to the application, and tries to find one with an identifier matching the API
`l
`
`-3-
`
`identifier extracted from the library. The virtual machine determines if there is a match in
`
`step 68.
`
`if a signature for the specific API is found in step 66, it must then be verified.
`
`Verification of the signature at step 68 preferably involves hashing the application, applying
`
`a public key corresponding to the private key used by the code signer during the code
`
`signing process, and comparing the result with the appended signature. A match between
`
`the locally generated result and the appended signature verifies the signature. if the
`
`signature cannot be verified, the application is not loaded or executed (step 74) and the
`
`process ends (step 78). According to a further aspect of the invention, non-verified
`
`Page 11 of 30
`
`

`

`applications are purged from the device. If the signature is Verified properly in step 68, then
`
`the application must have been signed using the code signer's private key. Since onlythe
`
`code signer has access to that private key, the code signer must have been satisfied that
`
`may be repeated, when the application requires access to more than one sensitive API for
`
`example. When all signatures have been verified, the virtual machine will display a
`
`notification message to the user, including the description of the API required by the
`
`application, such as: “Application X requires access to the 'strong cryptographic primitives’
`
`API.” The user will then be asked if the application should be allowed to proceed, at step
`
`70.
`
`If the user chooses to execute the application, the virtual machine will link the
`
`application with any required libraries and, once the linking process is complete, the
`
`application will be executed as in step 76. Othenrvise, the application will be not be loaded
`
`or executed, and the process ends (78).
`
`the application should be granted access to the sensitive API. This verification process
`
`in the art will appreciate, most application developers invest significant time and expense to
`
`The first embodiment of the invention as described above therefore provides
`
`for control of access to sensitive APls by a code signer. However, this necessitates a
`
`through review of every application requiring access to any sensitive APls on the device by
`
`the code signer. Such application review is a time- and labor-intensive process. The code
`
`signer must also assume the substantial responsibility of ensuring that the code for all such
`
`applications is “clean”, or free from viruses and destructive code.
`
`For an application developer, a code signing scheme according to the first
`
`embodiment requires the transmission of an application to the code signer. As those skilled
`
`Page 12 of 30
`
`

`

`A code signing scheme according to a second embodiment of the invention
`
`provides for API access control, but overcomes both of the above potential disadvantages
`
`of the first embodiment. An overall system diagram of a second embodiment of the
`
`invention is shown in FIG 5. As described above in conjunction with FIG 1, an application
`
`developer 2, creates an application Y, 80, to run on the device 12 and access a sensitive
`
`API 6. The application must therefore be granted access to the sensitive API in order to
`
`run on the device. In accordance with the second embodiment of the invention, the
`
`application developer 2 uses a hashing algorithm, such as the known Secure Hashing
`
`Algorithm SHA1, to generate a hash of the application. For a Java application, the Java
`
`.cod file is preferably used in the hashing operation. Instead of sending the application to a
`
`code signer for approval as in the first embodiment, the hash of the application Y, 82, is
`
`sent to the a signing authority 11. The signing authority 11 is similar to the code signer 10
`
`of the first embodiment, but performs somewhat different functions as will become
`
`apparent as this description proceeds.
`
`between the application developer 2 and the signing authority 11 before the hash of the
`
`application Y, 82, is sent to the signing authority 11. Such a registration process is
`
`preferably initiated when a development or other business relationship between the
`
`prevent early release of applications currently under development. Therefore, a code
`
`signing scheme as described above may actually discourage application development by
`
`certain developers.
`
`application developer 2 and the signing authority 11 is established. Where an application
`
`In a particularly preferred embodiment, a registration process is executed
`
`Page 13 of 30
`
`

`

`developer 2 has entered into an agreement with a manufacturer or service provider of
`
`device 12 to provide further services to the device 12 for example, registration of the
`
`application developer 2 could be performed, regardless of whether or not an application
`
`has yet been completed. The registration of an application developer 2 is preferably limited
`
`to specific APls, such that applications from a particular application developer 2 would be
`
`signed for access only to certain APls. Therefore, a hash of an application from an
`
`application developer registered with the signing authority 11 for developing applications
`
`requiring access to a data messaging API or a voice- or telephony—related API in a
`
`communication device for example, would not be signed by the signing authority 11 to also
`
`thus closely controlled.
`
`The registration process begins with a request from an application developer
`
`-2 to use a particular API.
`
`‘If the developer 2 has established some sort of business
`
`relationship as described above, the signing authority 1 1 may then provide the application
`
`developer 2 with detailed information about the API to allow the application developer2 to
`
`‘ write applications which operate with the API. The application developer 2 may submit a
`
`grant access to a cryptographic or any other sensitive API on'the device. API access is
`
`-11..
`
`registration request to the signing authority 11 to be registered as a developer of
`
`applications for the particular API. The signing authority 1 1 then registers the application
`
`developer 2 accordingly
`
`The signing authority 11 thereby controls which application developers may
`
`write applications requiring access to sensitive APls. Dilferent developers may have
`
`different API access requirements and may thus acquire differentAPl access registrations.
`
`Page 14 of 30
`
`

`

`The nature of some APls, such as any cryptographic APls, may require more strict controls
`
`than messaging or telephony APls for example. As described above, export regulations
`
`may define specific guidelines for access to any cryptographic APls on a device. The
`
`registration operations performed by the signing authority 11 can be adapted to implement
`
`any such guidelines.
`
`If export regulations require that an application developer obtain a
`
`permit in order to access a cryptographic API, then the signing authority 11 would confirm
`
`that the application developer has obtained such a permit before registering the developer
`
`for cryptographic API access.
`
`When a hash of an application Y, 82, is sent to the signing authority 11, an
`
`-12-
`
`wireless network or loaded onto the device through a direct connection (not shown). The
`\
`
`authentication process is performed by the signing authority 11 to authenticate the
`
`application developer 2. Provided that the application developer 2 has previously been
`
`registered with the signing authority 11 and the registration has not expired or been
`
`revoked, the signing authority 11 will sign the hash of the application and send the
`
`signature 84 back to the application developer 2. The signature 84 is generated using a
`
`secret key of the signing authority 11 and the hash 82 of the application, as described
`
`above. Most modern signature algorithms involve calculation of a hash of an input file or
`
`data, and any such algorithm may be used in this embodiment of the invention. Instead of
`
`generating a hash of its input however, the signing authority 11 may use the hash 82 of the
`
`application sent by the developer 2. The signature 84 is then appended to the application
`
`80 to form a signed application 86, which may be transmitted to the device 12 over a
`
`device 12 must verify the appended signature 84 before the application is executed. if
`
`Page 15 of 30
`
`

`

`access to more than one sensitive API is required, then more than one signature 84 may
`
`be generated by the signing authority 11 and appended to the application 80.
`
`The second embodiment of the invention differs from the first embodiment
`
`primarily in aspects relating to code signing and signature verification. The actual
`
`applications and executiOn thereof are substantially the same for both embodiments. Thus,
`
`applications 80, signed in accordance with the code signing scheme of the second
`
`embodiment of the invention, may be executed in a device as shown in FIG 2A and FIG 28
`
`-13-
`
`developer as in step 94. Steps 56, 92 and 94 may be repeated if access to more than one
`
`as described above.
`
`The code signing process according to the second embodiment
`
`is
`
`represented in the flow diagram of FIG. 6. As in FIG 4, an application requiring access to a
`
`sensitive API on a device is shown at 40, using a library X for example. The application,
`
`when complete, may be tested in a device simulator environment in which signature
`
`checking is disabled (step 42).
`
`If proper operation of the application within the simulator
`
`environment/is verified, then the application is hashed and the hash of the application is
`
`submitted to the author of the protected API orthe signing authority, in step 88. At step 90,
`
`the signing authority 11 determines whether or not the application developer is registered
`
`with the signing authority 11 . If so, then in step 92, a signature is generated using a private
`
`key, and the digital signature (including the API identifier) is returned to the application
`
`sensitive API is required by the application. The application developer appends the
`
`signature or signatures to the application (96) and may then send the signed application,
`
`as in step 98, to a device. In step 56, if the application developer is not registered with the
`
`Page 16 of 30
`
`

`

`the hash of the application should not be signed, then the developer receives a rejection
`
`notice and the submitted application will not run on any device.
`
`FIG 7 illustrates the operations executed on a device upon receipt of an
`
`application signed in accordance with the second embodiment of the invention. The
`
`process begins at a step 60 when an application with at least one appended signature
`
`arrives at the device. As described above, any libraries that the application requires must
`
`also be present on the device before the process can continue. At step 62, it is determined
`
`whether or not the application requires access to a sensitive API within any of these
`
`I libraries.
`
`If not, the application is linked with all of the libraries it requires and executed, at
`
`step 76.
`
`In step 64, it the application does require access to a protected API, the virtual
`
`machine (FIG 2A) extracts the public key and API identifier from the library exposing the
`
`API.
`
`it a corresponding signature with an identifier matching the API identifier extracted
`
`from the library has been appended to the application, as determined at step 66, then the
`
`virtual machine attempts to verify the signature (102) by calculating a hash of the
`
`application 80 and using the public key corresponding to the private key used by the
`
`signing authority 11.
`
`if the signature cannot be verified, the application is not loaded or
`
`executed (step 74) and the process ends (step 78). As described above, non-verified
`
`signing authority 1 1 or is not registered for access to one of the required APls, such that
`
`-14-
`
`applications may possibly be purged from the device.
`
`if the signature is verified in step 102, then the virtual machine will display a
`
`notification message to the user, including the description of the API required by the
`
`application, and await input from the user to indicate whether or not the application should
`
`Page 17 of 30
`
`

`

`be allowed to proceed, at step 70.
`
`If the user chooses to execute the application, the
`
`virtual machine will link the application with any required libraries and the application will be
`
`executed (76). Otherwise, the application will be not be loaded or executed (74), and the
`
`process ends (78).
`
`Notably, in the second embodiment, only a hash 84 of the application is sent
`
`to the signing authority 11 by the application developer 2, such that the signing authority 11
`
`does not check the application for errors, viruses, and the like. Responsibility forthe code
`
`therefore lies with the application developer 2. Since the application developer 2, in order
`
`to be registered with the signing authority 11, must have established a service or other
`
`business relationship with the signing authority 1 1 or the entity on whose behalf the signing
`
`authority 11 acts, the application developer 2 will ensure that no destructive or othenrvise
`
`problematic code is sent to any devices. Should any such code be found in a signed
`
`application or suspected because of peculiar, destructive or problematic behaviour
`
`-15-
`
`
`
`5i?ll:iiiLIl'tit:
`
`exhibited when a signed application is executed on a device, the signature forthe particular
`
`application will be revoked. The registration or privileges of the application developer2 with
`
`the signing authority 11 may also be suspended or revoked, since the signature 84
`
`provides an audit trail through which the developer of a problematic application may be
`
`identified. In such an event, all devices would preferably be informed of the revocation or
`
`instructed to download an updated revocation list.
`
`it any applications for which the
`
`corresponding signatures have been revoked are running on a device, the device halts
`
`execution of the application and may purge the application from its local storage. Every
`
`device would also preferably store and periodically update a revocation list to ensure that
`
`Page 18 of 30
`
`

`

`80, not the application 80 itself, is sent to the signing authority 11 .
`
`Although the signature 84 generated by the signing authority 11 is dependent
`
`upon authentication of the application developer and confirmation that the application
`
`developer has been properly registered, the signature 84 includes the hash of the
`
`signing schemes, in which API access is granted to any applications arriving from trusted
`
`application developers or authors.
`
`In the invention, APl access is granted on an
`
`application-by—application basis and thus can be more strictly controlled or regulated.
`
`It will be appreciated that the above description relates to the preferred
`
`embodiment by way of example only. Many variations on the invention will be within the
`
`scope of those knowledgeable in the field, and such variations are within the scope of the
`
`any subsequently received or downloaded signed applications for which a signature has
`
`been revoked will not be verified and are therefore not executable on any device.
`
`in addition, hashing algorithms are designed to prevent reconstruction of an
`
`input from the hash, or at least render such reconstruction computationally infeasible. As
`
`such, security concerns regarding the release of applications under development for
`
`verification by a signing authority should be alleviated. Only a hash 84 of the application
`
`application 80 and is therefore application-specific. This cont