BACKGROUND OF THE INVENTION [0003] Many cellular telephones and other communications devices are now programmable in a variety of ways. For instance, many cellular telephones contain editable phone books to permit convenient storage and dialing of frequently-used or important numbers. Other cellular telephones or other devices have Web browsing, file sharing and other enhanced functionality, whether via graphical user interface, voice commands or other interfaces. Moreover, cellular telephones are becoming available which include integrated positioning capability, such as the ability to track, record and communicate handset position via GPS or other location service. Games, ring tones and other features may likewise be provisioned over the air. Other services are being and will be deployed. Over-the-air programming (OAP) standards such as those employing the Java programming language have enhanced the provisioning and delivery of such services, on an on-demand or other basis.

[0004] However, not all onboard applications bundled by original equipment manufacturers (OEMs) may be configured for OAP support. Cellular or other devices containing those types of applications may not be able to receive on-demand provisioning for new features or services as a result. Handsets and other communications devices may benefit from more open and flexible programming resources.

[0005] At the same time, when OAP capability is available there are risks associated with that heightened programmability of cellular telephones and other devices.

Handsets and other devices may have the storage capacity and intelligence to store a variety of sensitive or personal information, such as a handset's International Mobile Equipment Identity (IMEI) data, a subscriber identity module (SIM) or ID, phone books, position tracking or other information. Devices which may accept or be configured to accept Java or other over-the-air code could be presented with security risks due to malicious code such as viruses, disguised games or ring tones, or other code or data. Once a malicious process has invaded the device, the user's sensitive hardware, phone book, positioning or other data could be exposed and compromised.

[0006] While user-facing security measures may be incorporated, such as requiring passwords on a handset interface before permitting access to hardware, phone book or other data, over-the-air and other threats may continue to test the integrity of the mobile device and its data, including by way of low-level code which insinuates into the device at comparatively low levels, such as application programming interfaces (APIs) and other open ports or interfaces. Better core level security on communications devices is desirable. Other problems exist.

SUMMARY OF THE INVENTION [0007] The invention overcoming these and other problems in the art relates in one regard to a system and method for distributed authorization and deployment of over the air provisioning for communications devices, in which a cellular handset of other communications device may be equipped to receive requests for over the air provisioning or other requests by Java or other applications. In embodiments, the communications device may present an API to internally executing programs through which all requests for OAP provisioning may be made. The API may communicate those requests, for instance, via an over-the-air interface to a remote support server for authentication and initiation. When a request is validated, permission may be retuned to the communications device to permit the requesting code to obtain the desired data or perform the desired provisioning.

BRIEF DESCRIPTION OF THE DRAWINGS [0008] The invention will be described with reference to the accompanying drawings, in which like elements are referenced with like numbers, and in which: [0009] Fig. 1 illustrates a distributed provisioning architecture, according to an embodiment of the invention.

[0010] Fig. 2 illustrates request fields in a provisioning request, according to an embodiment of the invention.

[0011] Fig. 3 illustrates a header and body of a provisioning message, according to an embodiment of the invention.

[0012] Fig. 4 illustrates data in the body of a provisioning message, according to an embodiment of the invention.

[0013] Fig. 5 illustrates a flowchart of overall provisioning processing, according to an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS [0014] Fig. 1 illustrates a distributed communications architecture in which an embodiment of the invention may operate. As illustrated in that figure, a communications device 102 may wirelessly communicate with a provisioning server 120 to initiate and validate a provisioning request 114 made by an application 104 running on communications device 102 for access to provisioning codes 110 contained within communications device 102. Communications device 102 may be or include, for instance, a cellular telephone, a network-enabled wireless device such as a personal digital assistant (PDA) or personal information manager (PIM) equipped with an IEEE 802.1 lb or other wireless interface, a laptop or other portable computer equipped with an 802. 11b or other wireless interface, or other communications or client devices. Communications device 102 may communicate with provisioning server 120 via antenna 112, for instance in the 800/900 MHz, 1.9 GHz, 2.4 GHz or other frequency bands, or by optical or other links.

[0015] Provisioning codes 110 may be or include, for instance, modifiable bits located within tiering structs which indicate services or features permitted or enabled on communications device 102, or other flags or information. Provisioning codes 110 may be stored in communications device 102, for instance, in electronically programmable memory (EPROM), flash cards, or other electronic, optical or other media. In embodiments the provisioning codes 110 may be, include or relate to, for instance, handset ring tones, games, contact or scheduling applications, the type or quantity of long distance service associated with the communications device 102, home or roaming areas, voice mail, text or other messaging service, or other services or features related to the communications device 102 or user.

[0016] The communications device 102 may execute one or more application 104, for instance a Java application, which in embodiments may include a Java Micro Edition application, C or C++ or other program or code. In embodiments application 104 may be or include, for instance, a contact scheduler application, a phone book application, a Web browsing application, a financial application, a personal information manager (PIM) application, a game application, a ring tone application or other application or service. In embodiments, application 104 may conform to or be implemented using the Java mobile information device profile (MIDP) standard, which applications may be referred to as MIDlets, or other languages or environments. In embodiments, application 104 may be received over the air via antenna 112, or received or stored from other sources, such as a cable-connected download.

[0017] The application 104 may interact with an application programming interface 106, which in turn communicates with provisioning server 120 and with native layer 108 executing on communications device 102. Application programming interface 106 may present a programming interface to application 104 to mediate requests to the set of provisioning codes 110 on communications device 102 and perform other tasks. In embodiments, application programming interface 106 may present application-accessible interfaces to data or object classes such as, for instance, network, user interface, data attributes and data content, and other resources. Native layer 108 may in embodiments operate at a comparatively low level in communications device 102, and act on requests passed by application programming interface 106 for access to or modification of provisioning codes 110. Native layer 108 may for example in embodiments perform supervisory, file and memory management, and other tasks.

[0018] As illustrated in Fig. 2, the provisioning request 114 may illustratively contain a set of request fields 116 to identify a location of the provisioning server 120, the communications device 102, and related parameters. As shown in that figure, the request fields 116 may include, for instance, an embedded address (universal resource locator, URL) associated with the provisioning server 120. In embodiments embedding a base URL or other address into the application programming interface may prevent the redirection of the authorization process to another remote resource.

The request fields 116 may likewise contain a unit or hardware identifier related to the communications device 102, such as IMEI or other data, which may in embodiments prevent a request from one device mimicking another device.

[0019] The request fields 116 may furthermore contain request parameters, that is, variables passed to the provisioning server 120 depending on the request being made.

In embodiments the request parameters may be or include alphanumeric strings, or may in embodiments include or be associated with data fields such as an array of bytes or other data. An illustrative set of request parameters shown in Fig. 2 may be or include"qt=asd&search=GO". Other request parameters and formats are possible.

The request parameters may provide a degree of flexibility as to the type and number of arguments passed in to and back from the provisioning server 120. In embodiments, the request parameters may conform to the RFC1738 standard, or other standards or protocols.

[0020] When application 104 presents the provisioning request 114 to access or modify one or more parts of provisioning codes 110, to ensure the integrity of that data and prevent unauthorized or malicious access to that or other information, application programming interface 106 may trap that provisioning request 114 at the system level for offboard processing, before permitting any of provisioning codes 110 to be accessed or modified.

[0021] Specifically, when application programming interface 106 receives an provisioning request 114 from application 104 to access or modify provisioning codes 110, application programming interface 106 may communicate with provisioning server 120 to evaluate and authorize that provisioning request 114. Application programming interface 106 may communicate with the provisioning server 120 via server antenna 118, or other wireless or wired interfaces. Application programming interface 106 may transmit provisioning request 114 containing, for instance, the type of service or data requested to be accessed from the set of provisioning codes 110, the name or other identifying information for application 104, access parameters such as time of last access, passwords if requested, or other data related to the provisioning request 114 for part or all of provisioning codes 110 to provisioning server 120.

[0022] Provisioning server 120 may maintain a set of authorization parameters against which to process the provisioning request 114 for access to provisioning codes 110. Those parameters may be maintained in an authorization table 124 or other form, which parameters may be stored in or accessed by provisioning server 120.

Provisioning server 120 may store a set of application identifiers which may in embodiments include a list application names or other identifiers, such as "phonebook. MID","contactlist. c", "positiontrack. exe" or other names or indicia.

Provisioning server 120 may maintain a set of associated access levels, correlated by application name or other indicia, which may indicate whether a given application 104 may be permitted to access provisioning codes 110, and in embodiments at which levels or with what privileges (e. g. , read, edit, or other) that access may be granted.

[0023] When the pending provisioning request 114 by application 104 is validated against authorization parameters by provisioning server 120, provisioning server 120 may transmit a provisioning message 122 to communications device 102. An illustrative example of provisioning message 122 is shown in Fig. 3, containing a provisioning message header 124 and provisioning message body 126. As shown in the figure, the provisioning message 122 may contain, for instance, a code, flag or other indication (Content-Authorize OK as illustrated) that application 104 may access provisioning codes 110 within a hyper text transfer protocol (HTTP) or other provisioning message header 124. Provisioning message 122 may likewise contain a code, flag, or other indication in a provisioning message header 124 or other section specifying the content-type or other provisioning message payload delivered by provisioning server 120. As illustrated, that string may be or include, for instance, a Multipurpose Internet Mail Extension (MIME) or other field specifying"x-iden- device\write_feature", indicating that application 104 may access provisioning codes 110 with write privileges according to directed conditions. The provisioning message header 124 or other section may also contain an indication of the size of the provisioning message body 126 or other payload section, in bytes. In embodiments, the provisioning message 122 may contain additional fields or variables in provisioning message header 124 or other section by which access to provisioning codes 110 may be regulated.

[0024] As illustrated in Fig. 4, the provisioning message 122 may likewise contain a provisioning message body 126 which contains the payload of the response of provisioning server 120 to the provisioning request 114. Provisioning message body 126 may contain, for example, data in MIME or other format indicating provisioning features and states which application 104 may access or modify. For example, in the status register shown in Fig. 4 the directive returned from provisioning server 120 may indicate that the 15 bit in the 2nd tiering flag may be turned on (state = 1), which may correspond to enabling a ring tone, voice mail, text or other messaging service, or other services or features. Other fields and indicators are possible, including different MIME extensions or other formats.

[0025] Provisioning message 122 may in embodiments contain further data or fields, in header, body or other sections. Provisioning message 122 may for instance contain a privilege field or flag which indicates whether application 104 may have the right to read, to modify, erase or perform other actions on provisioning codes 110.

Provisioning message 122 may likewise contain a timeout field which sets a period of time in which application 104 may access the desired data, but after which authorization may expire. Other security variables are possible. In embodiments, for example, the authorization may be granted for a single application 104, or for more than one application, or for different applications at different times. In embodiments, authorization to access provisioning codes 110 reflected in provisioning message 122 may be made at differing levels for different parts of that data, depending on the sensitivity of the data, the nature of the application 104 making the provisioning request 114, and other factors.

[0026] When the communications device 102 receives provisioning message 122 and the desired access is granted, the application programming interface 106 may pass the provisioning request 114 to native layer 108 may retrieve or modify the requested data from provisioning codes 110. Native layer 108 may then retrieve and communicate or modify the retrieved provisioning codes 110 and pass that data to application programming interface 106 to be delivered to application 104.

Application 104 may then receive and read the requested part or whole of provisioning codes 110, to operate on or modify that data. In embodiments, application 104 may receive authorization to store or write modified data into provisioning codes 110, to transmit the provisioning codes 110 over the air interface of antenna 112, or take other action, depending on the type or level of authorization received, network security and other parameters.

[0027] When the provisioning server 120 is unable to authorize the provisioning request 114 against authorization parameters 120, the provisioning message 122 may contain a deny flag or other indicator that application 104 may not access part or any of provisioning codes 110. In this case, in embodiments the communications device 102 may notify the user that an application or service has been denied access to device-specific or sensitive information. That notification may be by way for instance of a pop-up message presented on a text or graphical user interface, by a verbal message or otherwise. This notification may, for instance, assist the user in deciding to run an anti-virus or other utility on communications device 102, or take other action. In embodiments, denial of access to provisioning codes 110 may trigger an automatic logging of application 104, automatic transmission of an anti-virus or other utility to communications device 102, or other action.

[0028] Overall processing of distributed authorization for a communications device according to an embodiment of the invention is illustrated in Fig. 5. In step 502, application 104 may request one or more parts of provisioning codes 110 from the communications device 102 via application programming interface 106 and native layer 108, at the API or other level. The provisioning request 114 may in embodiments contain a parameter string as well as optional bytes of further data. In step 504, the provisioning request 114 may be transmitted to the provisioning server 120, for instance via an over-the-air protocol, which for example may be communicated using a secure or other protocol such as secure socket layer (SSL), hyper text transfer protocol secure (HTTPS) or other secure or other protocol or interface. In embodiments, the provisioning request may be generated by appending the parameter string to an embedded URL or other address for the provisioning server 120, as well as hardware identification data such as IMEI, NAM or other codes. The request may, in embodiments, encapsulate further data such as the name or other identifier of application 104, the type of data in provisioning codes 110 being requested, and other information.

[0029] In step 506, the provisioning server 120 may check the provisioning request 114 by application 104 against authorization parameters or other security fields or templates, make an authorization determination and communicate a provisioning message 122 to communications device 102, which communication in embodiments may likewise be via SSL, HTTPS or other secure or other protocols or interfaces. The provisioning message 122 may contain an indication that the provisioning request 114 is granted, denied, deferred, that further information will be required, or that other action may be taken. The provisioning message 122 may return that authorization or a directive, depending on MIME type or other factors. If the MIME type is or contains"x-iden-device\write_feature", then the directive within the body of provisioning message 122 may be used to turn selected features on or off, as specified by tiering structs or other codes. In step 508, upon receipt of a grant decision from provisioning server 120, the native layer 108 may read out the one or more parts of provisioning codes 110 which application 104 has been authorized to access. In step 510, the native layer 108 may communicate the one or more parts of provisioning codes 110 which application 104 has been authorized to access to application programming interface 106. In step 512, the application programming interface 106 may communicate the requested provisioning codes 110 to the application 104, for reading, modifying, writing, storing or taking other action. Processing may then repeat, return to an earlier point, continue to further processing or terminate.

[0030] The foregoing description of the system and method for distributed authorization for access to a communications device according to the invention is illustrative, and variations in configuration and implementation will occur to persons skilled in the art. For instance, while the invention has generally been described as being implemented in terms of a single provisioning server 120, in embodiments one or more servers or other resources may be deployed. Likewise, while the invention has been generally described in terms of a communications device 102 having an intermediary native layer 108, in embodiments the communications device 102 may operate without that type of local layer, for instance with some functionality distributed to provisioning server 120 or otherwise. Communications device 102 may conversely contain or operate on other or multiple supervisory layers. Other hardware, software or other resources described as singular may be implemented in multiple or distributed resources, while other hardware, software or other resources described as distributed may likewise be implemented as integrated resources. The scope of the invention is accordingly intended to be limited only by the following claims.