CN100565458C - Security access manager in the middleware - Google Patents

Abstract

Be used to control method and system to the visit of the platform of the platform of the portable terminal of radio telecommunications system or another product.This system comprises the platform with software services component and interface component, and this interface component has at least one interface, is used to provide the visit to software services component, so that can install, load and move application domain software in platform.Access controller control application domain software is via the visit of at least one interface to software services component.Access controller comprises blocking module, is used for receiving from application domain software the request of access software services component; And comprise security access manager, be used to determine whether permit license request.If security access manager is permitted this license request, then permit application domain software via at least one interface accessing software services component.

Description

Security Access Manager in Middleware

technical field

The present invention relates generally to the field of wireless telecommunications, and more particularly, the present invention relates to a system and method for controlling access to a platform of a mobile terminal of a wireless telecommunications system.

Background technique

Since the cellular telecommunication system was first introduced in the 80's, the mobile terminals (mobile stations) used in the system have become increasingly complex. Originally, mobile terminals were primarily designed to provide voice telephony services (ie, receive and send voice communications). In recent years, mobile terminals have been developed that also have the ability to communicate user data unrelated to voice telephone calls. Such user data includes data to be transferred over a dial-up network connection initiated via a personal computer (PC).

Currently, so-called "third generation" (3G) systems are being developed for future mobile telecommunication systems. 3G systems combine high-speed Internet access with traditional voice communications and enable users to use the following functions in addition to voice communications: Internet browsing, streaming audio/video, positioning, video conferencing, and many others.

The Third Generation Partnership Project (3GPP) has been established to ensure compatibility among the several 3G systems being developed around the world. 3GPP is developing the Universal Mobile Telephone System (UMTS) to provide terrestrial and satellite systems capable of delivering voice, data and multimedia anywhere in the world.

Through the 3GPP standardization work, the functions included in cellular telecommunication systems are rapidly increasing, which places a lot of demands on developers of mobile terminals to be used in the system. This requirement is exacerbated by the fact that mobile terminals are size, memory and power constrained "resource hungry" environments.

Traditionally, mobile terminal vendors design, manufacture, and sell essentially complete mobile terminal systems that include all the hardware and software required for basic terminal operation, as well as features that are desired by the manufacturer or specific users based on their understanding of market needs and the hardware and software required to function. This approach does not provide the flexibility to quickly adapt to rapidly changing market demands or to meet the diverse needs of multiple users.

Recognizing the inadequacies of the traditional process of designing and manufacturing mobile terminals, mobile terminal platform devices have been developed that include multiple functionally complementary software and hardware units that can be sold as a unit to multiple users. Each user can then install, load and run his own application software on the platform device, so as to provide a customized platform system for the mobile terminal that meets the user's own specific needs. Mobile terminal platform devices and platform systems are described in detail in commonly assigned US Patent Application Nos. 10/359911 and 10/359835, the disclosures of which are incorporated herein by reference.

The above-mentioned platform system (wherein the mobile terminal platform device software and the application software are developed separately, and then combined by installing, loading and running the application software in the mobile terminal platform device) may require non-native software to be run on the virtual machine. Applications, such as Javamidlet (Java mobile information device applet). The virtual machine ensures that illegal memory accesses do not occur. However, such non-native applications rely on the functionality provided by the native code of the mobile terminal platform device. Unrestricted access to such native functionality, eg in the platform domain or application domain, may compromise the integrity of the mobile terminal, eg by initiating a cost-inducing event without notifying the end user.

Using a certificate of origin for the application to determine the level of trust therein grants the non-native execution environment access to a subset of services available on the mobile terminal platform device. However, the above situation is further complicated by the fact that granted permissions may be changed at runtime by the mobile terminal user.

Therefore, there is a need to be able to dynamically register permissions and access the native code of the mobile terminal platform device at any time (eg, runtime).

Contents of the invention

A system for controlling access to a platform includes a platform having a software service component and an interface component having at least one interface for providing access to the software service component to enable installation, loading and Run the application domain program. The above system further includes an access controller, configured to control the access of the requesting application domain software to the software service component via at least one interface. The access controller includes: an intercepting module, configured to receive the request for the application domain software to access the software service component; and a decision entity, configured to determine whether to grant the request. If the request is granted, the requesting application domain software is granted access to the software service component via at least one interface.

A method for controlling access to a platform having a software service component and an interface component includes receiving a request requesting application domain software to access the application software component. The interface component has at least one interface, which is used to provide access to the software service component, so that the application domain program can be installed, loaded and run on the platform. The above method also includes determining whether the above request should be granted, and if the request is granted, granting access to the requested software service component via at least one interface.

A system for controlling access to a platform of a mobile terminal of a wireless telecommunications system includes a platform having software service components and interface components. The interface component has at least one interface for providing access to the software service component so that non-native application software can be installed, loaded and run on the platform. The above system also includes an access controller for controlling access of the non-native application software to the software service component via at least one interface. The access controller includes: an interception module, used for receiving the above-mentioned non-native application software's request for accessing the software service component; and a decision entity, used for determining whether to grant the request. If the request is granted, the non-native application software is permitted to access the software service component via at least one interface.

According to the above solution of the present invention, the software service component includes a plurality of well-structured functional software units for providing services, and the services are provided to users via the interface component.

Description of drawings

1 is a schematic block diagram showing a platform system for a mobile terminal of a wireless telecommunication system, to help explain the principles of the present invention;

2 is a schematic block diagram showing a configuration view of a mobile terminal platform device of the platform system of FIG. 1, to further help explain the principles of the present invention;

Fig. 3 is a schematic block diagram showing the software architecture of the mobile terminal platform device of Fig. 1 and 2, to further help explain the principle of the present invention;

Figure 4A is a logical block diagram showing details of the middleware service layer of Figures 1-3 according to an exemplary embodiment of the present invention;

Figure 4B is an implementation view showing the relationship between the different parts of the system, namely the application domain 500, the middleware domain 501 and the platform domain 502;

5 is a schematic block diagram showing details of the open application framework API domain of the middleware service layer of FIG. 4 according to another exemplary embodiment of the present invention;

Figure 6A is a schematic block diagram showing details of messages related to permission requests and decisions in accordance with the principles of the present invention;

6B is a schematic block diagram showing details of messages related to permission requests and decisions according to another exemplary embodiment of the present invention;

7 is a flowchart illustrating the steps of a method for requesting access to and receiving a permission decision from a SAM 518 in accordance with the principles of the present invention;

8A and 8B are flowcharts illustrating the steps of a method of requesting access and receiving permission decisions in a more efficient manner according to another exemplary embodiment of the present invention;

Figure 9 is a schematic block diagram showing details of a secure access manager in accordance with the principles of the present invention;

Fig. 10 is a schematic block diagram illustrating details of an interception module according to another exemplary embodiment of the present invention.

Detailed ways

Fig. 1 is a schematic block diagram showing a platform system for a mobile terminal of a wireless telecommunication system to help explain the principles of the present invention. The platform system is generally indicated by reference numeral 10, which includes a mobile terminal platform device 12 and one or more applications (ie, application software) 14 that have been installed, loaded into the mobile terminal platform device 12 and run therein. Platform system 10 is suitable for incorporation in a mobile terminal, indicated generally by dashed line 16 .

The mobile terminal platform device 12 includes a software service component 22 , a hardware component 24 and an interface component 26 . The software service component 22 includes a plurality of well-structured functional software units for providing services, which are provided to users via the interface component 26 . In the exemplary system 10 shown in FIG. 1, the plurality of software units includes a plurality of vertically oriented functional software stacks 30-38. The hardware components 24 comprise a set of hardware units associated with and controlled by their respective functional software stacks. In the exemplary system 10 shown in FIG. 1, the hardware elements are distinct hardware blocks 40-48 associated with software stacks 30-38.

Interface component 26 comprises middleware service layer, and this middleware service layer comprises at least one application programming interface (API), is used for installing, loading and running one or more applications 14 in mobile terminal platform device 12, and this middleware service layer The mobile terminal platform device 12 is isolated from the application 14 using the platform device 12 through the interface, and various other services are provided for the application 14 . Specific details of the middleware service layer will be described later.

The mobile terminal platform device 12 of the platform system 10 is adapted to function as an interface with application software 14 (the term "application software" as used herein may be any software that provides functionality other than platform software functionality that a user (such as a manufacturer or an end user) may wish to utilize. ) separate complete, sealed units to design, implement, assemble, and test. Accordingly, users can develop or obtain their own application software 14 and later add this software 14 to the mobile terminal platform device 12 to adjust the platform system 10 according to their needs. Accordingly, the mobile terminal platform device 12 can be sold or transferred to a plurality of different users, wherein each user can customize the platform system 10 by installing, loading and running their own application software on the platform device to meet their own needs. Special requirements for platform systems.

FIG. 2 is a schematic block diagram showing an example of a configuration view of the mobile terminal platform system 12 of FIG. 1 to further help understanding of the present invention. As shown in FIG. 2 , the mobile terminal platform device 12 is controlled via software executed in the main CPU 50. The main CPU 50 may include one or more processors, such as microprocessors, micro programmable processors or DSPs (Digital Signal Processors). The software stacks 30-38 of the software components 22 each include hardware driver software 60-68 that operates the hardware units associated with each stack. Further details of the mobile terminal platform device 12 and platform system 10 are given in the aforementioned commonly assigned US Patent Application No. 10/359835. The software incorporated in the mobile terminal platform device 12 is preferably configured in such a way that the software organization is easy to understand, so that the software is easier to design, easier to upgrade or modify.

FIG. 3 is a schematic block diagram showing the software architecture of the mobile terminal platform device 12 to further help explain the principles of the present invention. As shown in FIG. 3, the service components 22, in addition to being organized into multiple vertical functional software stacks 30-38 as described above, are also arranged to define multiple horizontal layers so that the software of the middleware service layer and the software of the software service components 22 The software collectively defines a layered structure (generally indicated at 70) in which layers are arranged in descending order from high-level service layers to low-level service layers.

The software architecture differs from the standard ISO/OSI (ISO Open Systems Interconnection) model in that it comprises a number of horizontally divided functional software units complementing a number of vertically divided software layers. Horizontal division is very helpful for creating independent modular components.

The highest layer of the layered structure is the middleware service layer. The layers of the software service component 22 include: an application server layer 80 that provides application services; a platform service layer 82 that provides specific platform services for applications; a protocol layer 84 that provides session protocols and specific application protocols; provides audio access/control, data communication transmission Transport layer 86 for protocols, messaging protocols, etc.; data access layer 88 for providing external data IF access, structured storage services, and other low-level platform support services; logical driver layer 90 and physical driver layer 92 for encapsulating hardware dependencies. Additionally, the software services component 22 includes a base system services layer 94 that provides the general services required by the platform device.

The bottom two layers 90 and 92 constitute the Hardware Abstraction Layer (HAL), which isolates dependencies between software and hardware. Only the physical driver layer deals with hardware details (ie which register in the ASIC hardware will be addressed). The logical driver layer 90 provides a logical mapping to hardware, ie, this layer provides a bridge between the hardware and software parts of the mobile terminal platform device 12 .

The software itself is organized into a number of software modules, such as modules 102 , 104 , 106 as specifically shown in FIG. 3 . In software service component 22, a single module may reside in only one vertical functional stack and only one horizontal layer in that stack. Each layer can contain one or more modules, and all modules in a particular layer within a particular stack have the same level of abstraction. Communication between modules is accomplished through a software back plane (SwBP) 112 controlled by the basic rules set for software modules and module access. These rules can be summarized as follows:

- A software module can call functions in all layer interfaces below the layer to which it belongs.

- There is no restriction on the direction of serial data flow. Serial data streams can flow in any direction.

- A software module must not call functions in layer interfaces (in SwBP 112) above the layer it belongs to, regardless of which module these layers belong to.

- A software module may call a function in a layer interface in the layer to which it belongs in the same vertical stack.

- A software module may call a function in a software module in the same layer in another vertical stack (this capability is allowed to limit the number of layers in the vertical stack).

There is no hard coupling between different modules and interfaces in SwBP 112. Thus, the implementation of the module and/or the interface can be changed at will without affecting the clients of the interface. A client is, for example, an application, utility, plug-in, or any other consumer of a platform service. The lack of hard coupling is an important capability because it allows individual modules to be added, removed or changed without affecting other modules in the platform device.

Further details of the layered architecture, including the SwBP software structure enabling internal communication between modules within a mobile terminal platform device, are described in the aforementioned commonly assigned US Patent Application No. 10/359911. The middleware service layer is used to provide a well-defined interface between the software in the mobile terminal platform device 12 and the application software 14 to be installed, loaded and run in this platform device, and the mobile terminal platform device 12 is packaged, and The platform device 12 is isolated from applications by itself, and provides various other services to applications.

Figure 4A is a schematic block diagram showing details of the middleware service layer of the interface component 26 in accordance with the principles of the present invention. As shown in Figure 4A, the middleware service layer includes multiple API domains, including non-native environment (such as Java Execution (Java ExE) environment) API domain 202, Open Application Framework (OAF) API domain 204, Open Platform API (OPA ) domain 206 and UI toolkit API domain 208.

Through the API 202-208 in the middleware service layer, the mobile terminal platform device 12 supports multiple application environments. In the exemplary embodiment of FIG. 4, the middleware service layer supports a native application (i.e., an application compiled to run on a specific processor and its instruction set) environment and a non-native application (such as JAVA J2ME CLDC/MIDP (Java 2 micro version connects limited device configuration/mobile information device profile)) environment. Each application environment has its own characteristics in terms of:

- The method of developing the application (programming language support, compiling and linking).

- method of executing the application (e.g. interpreted or native code execution)

- Functional services provided.

- Potential limitations in use.

By providing a variety of optional application environments, it helps to provide a wide range of products with different requirements such as cost, ease of use, time to market, feature set, size, portability, etc.

Figure 4B shows the relationship between different parts of the system by means of an implementation view. The main domains are application domain 500 , middleware domain 501 and platform domain 502 . Modules at higher levels are considered to have dependencies on lower level modules in Figure 4B. Application domain 500 may house non-native applications 506(1)-(N) and native applications 516 encapsulated within a non-native environment 504 (eg, a JAVA virtual machine). However, application domain 500 does not necessarily need to accommodate any non-native applications. Service requests from applications 506 and 516 are subject to access control through interception module 508 before being passed on to low-level services. Such low-level services may include plug-ins containing advanced graphics support (eg, UI toolkit 510 ) as well as more basic services represented by Open Platform API (OPA) 512 in middleware domain 501 . Through OPA 512, applications can communicate with Application Manager (AM) 514 to request updates of access permissions. In an exemplary embodiment, AM 514 notifies Security Access Manager (SAM) 518 of any such requests. Further details of the middleware service layer 26 are described in commonly assigned US Patent Application No. 10/359772.

FIG. 5 is a block diagram showing main software modules in the Open Application Framework (OAF) API domain 204 according to an exemplary embodiment of the present invention. As shown, these modules include SAM 518 and access interception module (IM) 223. The SAM 518 is responsible for granting non-native applications, such as Java applications, access to the Open Platform API domain 206 in order to monitor these applications based on their credentials. In other words, the SAM 518 is responsible for determining whether calls from non-native environments should be allowed. SAM 518 houses and maintains security policies related to platform service access. In this regard, the Java Exe environment 504's access to native platform services may be more restricted than the native application environment's 516 access. The IM 223 is responsible for monitoring service requests from applications running in a non-native (eg Java) environment 504, and in some cases, application service request monitoring for native execution environments may also be considered.

In general, AM 514 handles registration, installation, start, stop, uninstall and deletion of all applications. The IM 223 intercepts non-native application service requests from the EXE environment to native platform services (in the case of Java applications, the interception occurs at the boundary of the Java support layer) and accesses the SAM 518 to grant access to the service. If access is granted, the non-native application service request is forwarded to the Open Platform API (OPA) 206 and processed like a native application. Admission requests are traffic between the IM 223 and the SAM 518. A service request is traffic between an application 250 (see, eg, FIGS. 6A-B ) or any software in the application domain 500 and the platform domain 502 . A service request indicates that a customer wants to access a service of the platform domain 502 .

SAM 518 may grant access to native platform services in various ways, an example of which is shown in FIGS. 6A and 7 . Specifically, FIG. 6A is a block diagram of components and messages involved in granting or denying a service request, and FIG. 7 is a flowchart illustrating a flow chart associated with granting or denying a service request, according to an exemplary embodiment of the present invention.

Referring to Figures 6A and 7, at step 280, the non-native application 250 requests services that require access to native platform services. In step 282, the IM 223 intercepts the above-mentioned service request, which includes the ID tag of the requesting non-native application 250. In step 284, a permission request is sent from the IM 223 to the SAM 518 along with the ID token included in the service request. The IM 223 may also send other access information to the SAM 518 along with the identification of the native platform services that the non-native application 250 desires to access. The SAM 518 checks the security policy of the native platform service to determine if non-native application 250 can be granted access. In step 286, SAM 518 forms a permission decision and forwards the decision to IM 223. If the permission request is granted, then at step 288 the service request is forwarded to the one or more native platform services requested by the non-native application 250 . The requested service is then performed at step 290 and, if the permission request is denied, a denial response is sent to the non-native application 250 at step 296 .

If the ID token 320 does not match one of the ID tokens 320 included in the located access record 318, the request is denied at step 292, and the request is aborted at step 296 and returned to the requesting non-native application 250, as shown in FIG. 7 and 8A are shown.

In another alternative, a license decision may require an approval procedure. For example, as shown in step 294, the user may be asked to approve access to native platform services. If at step 294 the user approves the access, then at step 288 the request is forwarded to the native platform service. However, if access is denied at step 294, then the request is denied at step 292, and the request is aborted at step 296 and returned to the requesting client.

Figures 6B, 8A and 8B illustrate another example where the interception module makes a decision locally to grant or deny the request, and the SAM 518 updates the credentials stored in the IM. According to FIG. 6B, a non-native application 250 requests a service. IM 223 intercepts the service request. The IM 223 grants or denies the request locally. At the same time, the SAM 518 sends a request to the IM 223 to update the records kept by the IM 223 and based on each need or at regular intervals.

8A is a flow diagram further illustrating the process of granting or denying a service request according to the example shown in FIG. 6B. As shown, at steps 280 and 282, the non-native application 250 invokes a service request, and the service request and ID token are intercepted by the IM 223. The IM 223 makes the decision locally without sending an ID-tagged permission request from the IM 223 to the SAM 518. In this embodiment, the IM 223 maintains access records of the native platform services. Each access record includes an ID token for a particular application that has been granted access to the requested native platform service. In step 301, the IM 223 searches the access records of the requested native platform service to determine in step 303 whether the ID token of the requesting non-native application 250 is associated with the access records, and thus determines whether the request should be granted. If the ID tag of the requesting non-native application 250 is found in the access record, then in step 303 the non-native application 250 is permitted to access the requested native platform service. Similar to step 288 of FIG. 7 , the above service request is forwarded to the requested native platform service and executed at step 290 . If the ID token of the requesting non-native application 250 is not found in the access record of the requested native platform service, then the request is rejected at step 292, and the request is aborted at step 296 and returned to the client who made the request .

In another alternative, a Licensing Judgment may require an Approval Process. For example, the user may be required to approve access to native platform services, as shown in step 294 . If the user approves access at step 294, the request is forwarded to the native platform service as shown at step 288. However, if the access is denied at step 294, the request is denied at step 292, and the request is aborted at step 296 and returned to the client who made the request.

SAM 518 may distribute license update requests to at least one IM 223 when needed or at predetermined intervals. As shown in Figure 8B, there are different circumstances as to when such an update can be made. During runtime, a user may change permissions to a particular non-native application 250 via AM 514 (as shown in step 412), requiring an update of the access records maintained by SAM 518 (as shown in step 414). The updated license may then be forwarded by the SAM to the IM (as shown in step 416). Other situations where the records of SAM and IM must be updated include when new applications are added to the system (shown in steps 404 and 406) and when existing applications are deleted from the system (shown in steps 408 and 410). To further speed up licensing decisions, a decision cache may be used according to one embodiment of the IM 223 as described below.

Referring now to FIG. 9, details of a SAM 518 according to one embodiment of the present invention are shown. As shown, the SAM 518 includes a decision cache for recording the most frequent and/or recent service requests in order to find admission decisions associated with a particular service request. A given non-native application 250 may submit the same service request multiple times. Accordingly, the decision cache 310 records frequent service requests and can search through earlier requests to find permission decisions associated with a particular service request. For example, a Java application may request a particular native platform service multiple times. The received permission request includes requesting an ID token for the non-native application 250 .

When a non-native application 250 first makes a service request, the SAM 518 accesses the access control list (ACL) 312 to determine whether permission should be granted to the requested native platform service. ACL 312 stores a number of access records from the application's certificate of origin. These records 314 are associated with each registered and installed non-native application, such as a specific Java application. The SAM 518 searches the possible records of the requesting application 314 to find a match with the particular requesting application. If the particular requesting application is found in the record set, permissions are searched 316 to determine whether access to the requested native platform service should be granted. A license decision is generated based on the associated and stored license 316 . The permission decision is sent to the IM 223 and may also be stored in the decision cache 310 along with the permission request. The next time the IM 223 intercepts a service request from the same non-native application 250 and forwards it to the SAM 518, the decision cache 310 is searched for that permission request. When a permission request is found, the permission decision associated with that permission request is forwarded to the IM 223. By utilizing the decision cache 310, the SAM 518 becomes more efficient in making admission decisions.

FIG. 10 shows details of an IM 223 according to another embodiment of the invention. Note that although in this example the ACL and decision cache are located in the IM 223, the same principles would apply if the ACL and decision cache were located in the SAM 518. In FIG. 10, ACL 312 stores an access record in a different format from the access record shown in FIG. 9. Specifically, in FIG. 10, the ACL 312 stores the access record 318 of the mobile terminal native platform service. There is an access record 318 for each native platform service (or group of services) of the mobile terminal. Each access record 318 includes ID tokens 320 of non-native applications 250 that are permitted to access the particular native platform service (or set of services) associated with the access record 318 . When access lists and records need to be updated, SAM 518 sends a request to IM 223. The update request includes the ID token 320 of the non-native application 250 associated with the update and the identification of the native platform service requested if permissions must be changed. The IM 223 searches the ACL 312 for the requested native platform service's access record 318. Once found, the IM 223 determines whether the ID token 320 of the requesting non-native application 250 is included in the found access record 318. If the ID token 320 of the requesting non-native application 250 matches one of the ID tokens 320 included in the lookup access record 318, permission is granted to the requesting non-native application 250 and the service request is forwarded to the native platform service processor. Licensing decisions may also be stored in decision cache 310 in a manner similar to that described with reference to FIG. 9 .

If the ID token 320 does not match one of the ID tokens 320 included in the found access record 318, the request is rejected at step 292, and the request is aborted at step 296 and returned to the requesting non-native application 250, as shown in FIG. 7 and 8A are shown.

Even at runtime, on-demand update requests and periodic license update requests may be distributed from the SAM 518 to registered IMs 223. A user may update the permissions granted to a particular non-native application 250 so that outdated and erroneous information is present in the SAM 518. Accordingly, whenever needed or at periodic intervals, SAM 518 sends a permission update request to IM 223 to update access record 318 of ACL 312, thereby maintaining correct permissions and/or ID tokens. The ID token 320 of a particular non-native application 250 may need to be added to or removed from certain access records 318 in accordance with changes to the user's permissions for that particular non-native application 250 .

In order to further simplify the permission judgment procedure, types such as ID token 320 and permission 326 can be classified to improve the efficiency of searching the ACL 312 of the IM 223 (or searching the SAM 518 when the SAM 518 module holds the ACL). For example, each native platform service can be assigned to a specific security category, and each security category is associated with a specific permission. Licensing decisions are then made based on security categories rather than individual native platform services. Typically, the number of security categories will be significantly smaller than the number of native platform services, thereby reducing the search time associated with determining permission decisions.

Although what has been described constitutes exemplary embodiments of the invention, it should be understood that the invention can be modified in many ways without departing from the scope of the invention. For example, although the present invention is primarily described in connection with wireless terminal platforms for wireless telecommunications systems, it can also be used in connection with other product platforms. Since the invention can be modified in many ways, it should be realized that the scope of the invention is limited only by the appended claims.

Claims (40)

1. a control is to the system of platform access, and described system comprises:

Platform, it has software services component and interface component, and described interface component has at least one interface, is used to provide the visit to described software services component, so that can install, load and move the application domain program in described platform; And

Access controller is used for control request application domain software via the visit of described at least one interface to described software services component, and described access controller comprises:

Blocking module is used to receive the request of the described software services component of described request application domain softward interview; And

Judgement entity is used to determine whether permit described request; And

Wherein,, then permit described request application domain software via the described software services component of described at least one interface accessing if permit described request,

Described software services component comprises a plurality of functional software unit that are used to provide service, and described service offers the user via described interface component.

2. the system as claimed in claim 1, it is characterized in that: described judgement entity is a security access manager, described security access manager comprises visit and admission policy.

3. described system as claimed in claim 2 is characterized in that:

Described request comprises the sign of described request application domain software; And

Described security access manager comprises the record set of approved request application domain software, is used for determining whether permit based on described sign the described request of described request application domain software.

4. system as claimed in claim 3 is characterized in that:

Described record set comprises the access control collection;

Described security access manager comprises the permission collection that is associated; And

The described permission collection that is associated is used to determine whether permit the described request that included request application domain software is concentrated in described access control.

5. system as claimed in claim 2 is characterized in that: described security access manager comprises decision cache, is used for the request record of maintenance application territory software, so that determine before whether permission decision to have been licensed to described request application domain software.

6. system as claimed in claim 2 is characterized in that:

Described security access manager has the record of request application domain software; And

Described security access manager determines whether permit described request based on the sign that is stored in the described record.

7. system as claimed in claim 2 is characterized in that: if rejecting said request then sends to described request application domain software by described blocking module with refuse information.

8. system as claimed in claim 2 is characterized in that: described application domain software comprises non-machine application domain software.

9. system as claimed in claim 8 is characterized in that: described non-machine application domain software comprises the Java application software.

10. the system as claimed in claim 1, it is characterized in that: described application domain software comprises this machine application software.

11. the system as claimed in claim 1 is characterized in that: described interface component comprises middleware services layer.

12. system as claimed in claim 2 is characterized in that: described platform comprises the platform of the portable terminal that is used for radio telecommunications system.

13. the system as claimed in claim 1 is characterized in that: described judgement entity belongs to described blocking module.

14. system as claimed in claim 13 is characterized in that:

Described request comprises the sign of described request application domain software; And

Described blocking module comprises the record set of approved request application domain software, is used for determining whether permit based on described sign the described request of described request application domain software.

15. system as claimed in claim 14, it is characterized in that: described blocking module comprises decision cache, be used to safeguard application software identifier record, so that determine before whether permission decision to have been licensed to described request application domain software by this machine platform service packet.

16. system as claimed in claim 13 is characterized in that:

Described blocking module has the record of each platform service of described platform; And

Described blocking module determines whether permit described request based on the sign that is stored in the described record.

17. system as claimed in claim 13 is characterized in that: described application domain software comprises non-machine application software.

18. system as claimed in claim 13 is characterized in that: described application domain software comprises this machine application software.

19. the system as claimed in claim 1 is characterized in that also comprising:

System's access modules; And

Wherein said system access modules is suitable for using that to be used to determine to permit by described blocking module still be that the information of rejecting said request is upgraded described blocking module.

20. system as claimed in claim 19 is characterized in that: periodically upgrade by described system access modules.

21. system as claimed in claim 19 is characterized in that: described system access modules is upgraded according to update request.

22. a control is to the method for the visit of platform with software services component and interface component, described interface component has at least one interface, be used to provide visit to described software services component, so that can install on described platform, load and move application domain software, described method comprises:

Receive the request of the described software services component of request application domain softward interview;

Determine whether permit described request; And

If the allowance described request is then permitted via the described requested software services component of described at least one interface accessing,

Described software services component comprises a plurality of functional software unit that are used to provide service, and described service offers the user via described interface component.

23. method as claimed in claim 22 is characterized in that:

Described request comprises the sign of described request application domain software; And

Possible request application domain software assembly is used to determine whether permit the described step of described request.

24. method as claimed in claim 23 is characterized in that: described set comprises:

The access control collection; And

Wherein said determining step comprises the described access control collection of visit.

25. method as claimed in claim 22 is characterized in that: described determining step comprises determines before whether once judgement to have been licensed to described request application domain software.

26. method as claimed in claim 22 is characterized in that:

Store the record of described each platform service of platform; And

Described determining step comprises based on the sign that is stored in the described record and determines whether described request is licensed to described request application domain software.

27. method as claimed in claim 22 comprises:

If rejecting said request then sends to refuse information described request application domain software.

28. method as claimed in claim 22 is characterized in that: described application domain software comprises non-machine application software.

29. method as claimed in claim 28 is characterized in that: described non-machine application domain software comprises the Java application software.

30. method as claimed in claim 22 is characterized in that: described application domain software comprises this machine application software.

31. method as claimed in claim 22 is characterized in that: described platform comprises the platform of the portable terminal that is used for radio telecommunications system.

32. method as claimed in claim 22 is characterized in that also comprising: being used to determine permit still is the lastest imformation of rejecting said request.

33., it is characterized in that: periodically repeat described step of updating as method as described in the claim 32.

34. method as claimed in claim 32 is characterized in that: carry out described step of updating according to update request.

35. a system that is used to control to the visit of the platform of the portable terminal of radio telecommunications system, described system comprises:

Platform, it has software services component and interface component, and described interface component has at least one interface, is used to provide the visit to described software services component, so that can install, load and move non-machine application software on described platform; And

Access controller is used to control described non-machine application software via the visit of described at least one interface to described software services component, and described access controller comprises:

Blocking module is used to receive the request of described non-the described software services component of machine accessible with application software; And

Judgement entity is used to determine whether permit described request; And

Wherein,, then permit described non-machine application software via the described software services component of described at least one interface accessing if permit described request,

Described software services component comprises a plurality of functional software unit that are used to provide service, and described service offers the user via described interface component.

36. system as claimed in claim 35 is characterized in that: described judgement entity belongs to described blocking module.

37. system as claimed in claim 35 is characterized in that: described judgement entity belongs to security access manager.

38. system as claimed in claim 35 is characterized in that: described at least one interface comprises middleware services layer.

39. system as claimed in claim 35 is characterized in that: described non-machine application software comprises the Java application software.

40. system as claimed in claim 35 is characterized in that: can on described platform, load, install and this machine of operation application software.

Images