KR20100105210A - Mobile terminal with mobile platform managed and updated in module type, method for operating the mobile platform, managing module and updating the module - Google Patents

Abstract

The present invention relates to a mobile communication terminal equipped with a mobile platform managed and updated in a module form, a mobile platform driving method, a module management method, and a module update method.

According to the present invention, the module manager controls each module that performs unit functions constituting the mobile platform by being formed in a unique platform code binary form independent from the terminal binary. It also provides an interface to use each module between each module or in an application. Each module is updated to a higher version through a module updater.

Therefore, it is easy to add, change, and delete new functions to the mobile platform, and after the terminal is released, new function modules may be added and changed for the purpose of improving the mobile platform function and providing new services of the telecommunications carrier.

Description

Mobile communication terminal equipped with a mobile platform that is managed and updated in the form of a module, a method for operating the mobile platform, a module management method and a module update method {Mobile terminal with mobile platform managed and updated in module type, method for operating the mobile platform, managing module and updating the module}

The present invention relates to a mobile communication terminal equipped with a mobile platform managed and updated in a module form, a mobile platform driving method, a module management method, and a module update method.

Recently, due to the performance improvement of mobile communication terminals and various convergence needs of customers, the installation of 'General Purpose OS (Operating System)' has been attempted in feature phones and smart phones, and the mobile platform has changed accordingly. It is required.

The emergence of specialized terminals to meet the diverse needs of these customers puts a burden on the deployment of a huge mobile platform with all functions. Therefore, there is a need for a lightweight mobile platform combining only necessary functions according to terminal characteristics.

In addition to the performance improvement of mobile communication terminals, the number of terminals equipped with general purpose OS such as Windows Mobile and Embedded Linux is increasing. This trend requires the structural improvement of the platform so that mobile platforms can be easily ported onto various general-purpose operating systems.

1 illustrates a conventional mobile platform structure, and FIG. 2 illustrates a binary structure of a conventional mobile platform.

According to FIG. 1, a conventional mobile platform includes a ROM binary 11, an EFS binary 13, APP 1, 2, and 3 15, an application performance management (APM) module 17, and a downloader. (19), KIKA 21, Native system software 23 and kernel 25, and Hardware Adaptation Layer (HAL) 27.

According to Fig. 2, the native system software 23 and the kernel 25 use one binary platform code, which links the binary code of the mobile communication terminal. In other words, the platform code is statically linked to the terminal binary so that the platform code is loaded into the memory when the terminal is booted.

Figure 3a shows the package type of the conventional mobile platform, Figure 3b shows the package interrelationship.

According to FIG. 3A, in the conventional mobile platform, modules are divided into package units. The top-level package includes a wec package 31, a java package 33, and an org package 35 as a package 29 provided by a CP (Contens Provider), and a com package 39 as an internally implemented package 37. , ams package 41, and javax package 43.

However, as shown in FIG. 3B, the interrelationships between the packages 31, 33, 35, 39, 41, and 43 are difficult to discern between upper and lower relations, and are horizontally and intricately intertwined, thereby dynamically adding and modifying modules of functional units. It is a structure that is difficult to delete.

In addition, the kernel of the conventional mobile platform is a structure in which all functions of the kernel are composed of objects and linked to one binary. In other words, the kernel of the conventional mobile platform is that all the functions are configured as one binary. Here, the parts that need to be changed according to 'Target O / S' are also built and included in the binary. In addition, both the module with the H / W dependency and the graphic module are included in the kernel to make mutual function calls directly.

Therefore, the mobile platform of such a kernel structure has a problem that the distinction between functions is ambiguous, lower layer reference code exists, and a kernel rebuild suitable for a target is required.

As described above, due to the low specification of the past mobile communication terminal, the conventional mobile platform is designed in a structure that is linked to the terminal manufacturer binary. Therefore, in order to improve or add some functions of the mobile platform, a time / cost problem occurs that must go through various steps such as the entire mobile platform build, manufacturer distribution, and terminal manufacturer binary link. In other words, it is difficult to update the function unit and add the function after the release of the mobile communication terminal.

Structural problems of these mobile platforms has made a variety of 3 ^rd Part solution providers or individuals difficult to practically participate in the platform extensions. This means that they can be eliminated from the recent fierce competition in the mobile platform sector.

The technical problem to be achieved by the present invention is to provide a mobile communication terminal equipped with a mobile platform that is managed and updated in a module form, a mobile platform driving method, a module management method, and a module update method.

According to one aspect of the invention, there is provided a mobile communication terminal equipped with a mobile platform. The mobile communication terminal controls each module constituting the mobile platform, wherein each module implements each of the unit functions constituting the mobile platform in a unique platform code binary form independent of the terminal binary. A module manager providing an interface to use each module between the respective modules or in an application; And a module updater for updating each module to a higher version.

According to another feature of the invention, a method for driving a mobile platform is provided. In the mobile platform driving method, the module manager, where the module manager is formed in a unique platform code binary form independent from the terminal binary and controls each module constituting the mobile platform, is a platform from an original equipment manufacturer (OEM) layer module. Receiving a request for driving; Initializing a hardware adaptation layer interface information table storing a module information table and a hardware adaptation layer (HAL) list for managing information about the respective modules; And driving the mobile platform by loading the kernel module.

According to another feature of the invention, a module management method is provided. The module management method includes a module manager, wherein the module manager is formed in a unique platform code binary form independent from the terminal binary to control each module constituting the mobile platform; Recording module loading information and module binaries of the specific module in the allocated memory, and loading the specific module; And a module pool for managing information on the respective modules loaded by the module manager into a memory and a module loading table for the specific module in a module information table managing information on the respective modules installed in the mobile communication terminal. Updating the information.

According to another feature of the invention, a module update method is provided. The module update method may include: receiving a module updater, wherein the module updater is formed in a unique platform code binary form independent from the terminal binary to perform an update function of each module constituting the mobile platform; And deleting the previously stored lower version module and downloading and storing the higher version module.

According to the present invention, it is easy to update the function of the mobile platform without replacing the terminal binary by minimizing the range of modules statically mounted on the mobile platform.

Therefore, it is easy to add, change, and delete new functions to the mobile platform, and after the terminal is released, new function modules may be added and changed for the purpose of improving the mobile platform function and providing new services of the telecommunications carrier.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise. In addition, the terms “… unit”, “… unit”, “module”, etc. described in the specification mean a unit that processes at least one function or operation, which may be implemented by hardware or software or a combination of hardware and software. have.

In the present specification, the mobile platform refers to a runtime execution environment of a terminal that can be mounted on a mobile communication terminal and execute an application program created according to a mobile standard platform standard. The mobile platform includes application management and application programming interface (API) management.

According to an embodiment of the present invention, the mobile platform is divided into functional units and has a modular structure for each function.

Hereinafter, a mobile communication terminal equipped with a mobile platform managed and updated in a module form according to an embodiment of the present invention, a mobile platform driving method, a module management method, and a module update method will be described with reference to the drawings.

4 is a conceptual diagram illustrating a modular structure for each function of a mobile platform according to an embodiment of the present invention.

As shown in FIG. 4, the mobile platform has a modular structure for each function. At this time, the modular structure for each function consists of horizontal modularity and vertical modularity.

Horizontal modularization defines the unit functions for the mobile platform and implements the unit functions modularly. In this way, the mobile platform configured with modules selectively selected according to the type and hardware characteristics of the terminal may be mounted on the terminal. In addition, it is easy to add, change, or delete new functions on the mobile platform. Therefore, after launching the terminal, a new function module may be added and changed for the purpose of improving the mobile platform function and providing a new service for the communication service provider.

Vertical modularization plays a pivotal role in the platform such as Kernel Layer 101, which manages processes, memory, and events, network, InputOutput (IO), media, etc. 103) and an API layer 105 that is responsible for the standard of the API used by the application. In this case, each layer includes a plurality of unit functions, and each unit function is implemented by one module 107.

Here, the module 107 is defined as an independent platform code binary classified for each function constituting the mobile platform. Accordingly, unlike the conventional platform code is statically linked to the terminal binary, the mobile platform according to the embodiment of the present invention has a structure capable of selectively selecting the terminal-mounted binary according to each module.

The mobile platform is divided into functional units to classify functions that cannot be configured as dynamic libraries and implement them as modules 107. In other words, by minimizing the range of statically loaded modules, some functions of the mobile platform can be updated without replacing the terminal binary.

Each module 107 provides a module export interface and a module import interface. That is, the module 107 provides a module export interface for outputting a function provided by the module 107 so that it can be used by another module or application. In addition, the module 107 provides a module import interface to receive a function from another module when using the interface of another module.

In addition, the functions of the mobile platform supporting both the C and JAVA interfaces are classified into the API layer 105 by configuring a single module 107. In other words, it can perform the same function and create a library by gathering the sources that provide the C and JAVA interfaces.

5 is a block diagram of a mobile platform according to an embodiment of the present invention.

As shown in FIG. 5, the mobile platform mounted in the mobile communication terminal includes an EFS binary (Embeded File System Binaries) 301, a ROM binary 303, an application performance management (APM) module 305, and an application programming interface (API). ) Layer module 311, system layer module 323, kernel layer module 331, and original equipment manufacturer (OEM) layer module 341.

Application files running on the mobile platform are included in the EFS binary 301 and the ROM binary 303.

The EFS binary (Embeded File System Binaries) 301 is a code area that is easily accessible to the user, and stores basic application programs in the mobile communication terminal. It is a code area that is accessible to users such as short messages, pictures, ringtones, and games. In order to provide various services in the mobile communication terminal, a basic application program is stored in the mobile communication terminal. In addition, it is an area having a size that is set in advance by consultation with operators and developers.

The ROM binary 303 is a code area in which a user's access to an operating system (OS) and essential applications, which are essential for the operation of the mobile communication terminal, is stored. The platform activator 345 of the OEM layer module 341 is statically linked to the ROM binary 303.

Application Performance Management (hereinafter referred to as 'APM') module 305 controls the download, registration, storage, deletion, etc. of the applications 1, 2 (307, 309) and add related APIs and components, Control the update. Applications 1 and 2 (307, 309) are various service applications that operate on the mobile platform base such as email, location-based, games, character bell, video streaming, multimedia message service (MMS).

The application programming interface (API) layer module 311 includes API functions for executing applications 1 and 2 (307 and 309), and includes respective modules. Each module may include a Display module 313, a Network module 315, a Handset module 317, a Termres module 319, a File module 321, and the like.

At this time, the API layer module 311 is a set of functions that applications 1 and 2 (307, 309) can call to the operating system for specific processing, and API and application 1, 2 (307, 309) for controlling handset hardware. Includes APIs that are used in practice.

The system layer module 323 refers to a Rex OS in a CDMA network, and includes a simple terminal operating system function, a communication function, and various device drivers. It includes a system module 325 and a file module 321 that are responsible for the pivotal functions of the mobile platform such as a network, IO (Input / Output), media, and perform API functions. Here, the system module 325 manages a hardware adaptation layer (HAL) API 329 provided by the mobile platform.

The kernel layer module 331 is the most essential operation in the entire execution process of the mobile platform. The kernel layer module 331 resides in a memory, manages processes and memory, controls devices of a mobile communication terminal, and processes input / output.

The kernel layer module 331 implements essential functions, which are basic in the mobile platform, as modules, and configures one independent layer. The kernel layer module 331 provides basic functions such as a memory manager, a thread manager, a timer, a class loader, and the like. The kernel layer module 331 includes a kernel module 333 and a module manager 337.

Here, the kernel module 333 manages the HAL API 335 provided by the mobile platform. In this case, although not shown in the figure, the kernel module 333 may include one of a core module, a thread module, and a target module, each of the functions constituting the kernel layer module 331 implemented in a module form. . The core module is a module that performs functions specific to the mobile platform, and the thread module is designated to utilize threads supported by an operating system installed in the mobile communication terminal, and the target module is determined according to the central processing unit (CPU) of the mobile communication terminal. Specified to satisfy kernel functionality that requires different code.

In addition, the module manager 337 is a mobile platform kernel module that manages a life cycle such as load and unload of modules for each function constituting the mobile platform. Module manager 337 includes a HAL interface 339. The HAL interface 339 refers to an in-memory data structure that allows the mobile platform to call the HAL API provided by the OEM in a structure in which the mobile platform and the OEM are not statically linked.

The original equipment manufacturer (OEM) layer module 341 includes a handset application layer (HAL) module 343 and a platform activator 345, an abstraction layer that enables hardware independence in platform porting.

Here, the HAL module 343 is an abstraction layer for maintaining hardware independence of the mobile platform, and supports upper layers to operate independently of the system layer module 323 on the HAL module 343. HAL defines APIs for handset manufacturers and introduces an abstraction layer called HAL to support different devices. And when this HAL is ported to the handset, it can be equipped with a mobile platform execution engine. In a desktop Windows environment, porting the HAL to WIN 32 makes the emulator straight away.

In addition, the platform activator 345 is a wireless Internet platform for interoperability (WIPI) executable binary mounted on the mobile communication terminal. The platform activator 345 is the place where the HAL provided by the mobile platform and the event exchange with the operating system (OS, Oriented System) is located and is configured in a binary format provided by the OS. In addition, the module manager 337 serves to load. And a HAL interface 347 for communicating with the kernel layer module 331.

The operation of the mobile platform configured as described above will be described. The operation of the mobile platform is composed of platform driving flow, terminal API call flow / HAL call flow, and platform-provided HAL API call flow from the OEM. In this case, the lower parenthesis order is consistent with the order shown in the figure, and the communication between the modules is indicated by an ordered arrow.

1) Upon booting of the mobile communication terminal, the OEM layer module 341 requests the platform activator 345 to drive the mobile platform.

2) The platform activator 345 loads the module manager 337 and passes the HAL interface 347 pointer.

3) The loaded module manager 337 looks up the required basic HAL API through the HAL interface 347 pointer provided by the OEM.

4) The module manager 337 loads basic modules required for the mobile platform operation and initializes the mobile platform.

5) The module manager 337 drives the APM module 305 to complete a terminal booting operation.

6) Application 2 309 is run and Application 2 309 calls the API provided by the mobile platform. For example, the File API is called.

7) At this time, the function module of the system layer module 323 that the corresponding API function is called. For example, the File module 321 is called. If the function module of the system layer module 323 is not loaded, the module manager 337 loads the function module.

8) The File module 321 of the system layer module 323 requests the HAL API call from the module manager 337.

9) The module manager 337 calls the HAL API retrieved from 3).

10) The platform activator 345 of the OEM layer module 341 calls the HAL API provided by the mobile platform to perform an interworking function with the mobile platform. The platform activator 345 implements the HAL API wrapper provided by the mobile platform.

11) The platform activator 345 calls the platform-provided HAL API through the module manager 337 to perform a function.

Then, the configuration in which the mobile platform described above is managed and updated in a module form will be described in detail.

6 shows a configuration for module management and updating according to an embodiment of the present invention.

As shown in FIG. 6, the module manager 337 includes a module manager interface 337a, a module pool 337b, a module information table 337c, a HAL interface 339 and a control manager 337e.

The module manager interface 337a is defined as an interface required for module use in an application or between modules. The module manager interface 337a includes an interface for list inquiry, module information inquiry, module download, and generation for the module.

The module list inquiry provides list information of modules installed in the terminal. At this time, the module to be included in the list is a module that has been installed. That is, if the download of the module is not completed or the installation of the module is not completed, it is not included in the list. Each module installed in the terminal has a unique identifier, and the ID of the module serves as an identifier. That is, since the application accesses the module through the module ID, the module list format is configured in the form of a string in which the module IDs are continuously listed.

Here, when a module list inquiry is requested, the module manager searches for a module installed in the terminal and constructs and provides a module list including only valid modules.

The module information inquiry is a function of providing information of a specific module installed in the terminal after the module list inquiry. That is, it provides information of the module installed in the terminal. Information on the modules provided is shown in Table 1 below.

Information Explanation id Module ID. Identifier consisting of hexadecimal values name User-recognized module name version Configured as installed module version xx.xx size Module size installed. Byte unit state Whether the module is loaded

Here, when an application or a module configures a parameter for querying module information and requests information on a specific module along with parameter transfer, the module manager searches for a valid module by searching for a module installed in the terminal. It provides module information consisting of the name, version, size and loading status of a valid module.

The module loading function is a function provided to use another module in a module. It is similar to the interface search function of an application DLL, but this function is limited to a module only.

The module download function provides a download function of a new module and an upgrade function of a module already installed in the terminal based on the provided module information. The module updater is responsible for directly performing the module download. When the application requests the module download, the module updater is started and the download request module information is transmitted to the module updater. There can be more than one module download request. That is, the application may construct a list of modules and request a download.

At this time, the function parameter to be configured in the module download API is composed of "[module ID1] # [module version1], [module ID2] # [module version2]".

Here, if the application configures the module information parameter requested to download and configures the parameter to be stopped at the time of downloading, the module manager checks whether the module information is valid. If the module information is valid and the module requested for download is not already installed, the APM module is requested to run the module updater by specifying the parameters necessary to drive the module updater. At this time, the APM module stops the application and drives the module updater.

The module pool 337b is managed in a linked list as data that manages information about each module 107 loaded in the memory, that is, loaded by the module manager 337.

The module information table 337c is a data for managing information on each module 107 installed in the terminal and is managed in a linked list.

HAL interface 339 is an in-memory data structure for calling the HAL API provided by OEM layer module 341.

Each module 107 is not a structure that is statically linked to the terminal binary. Thus, each module 107 does not know the address of the HAL API. In this regard, the HAL interface 339 is designed so that each module 107 can call the API through the function table of the HAL interface provided by the OEM layer module 341.

The HAL interface list used by the module manager 337 may be defined as shown in Table 2 below.

HAL interface HAL interface name Explanation Interface HAL hal_interface Interface required for look-up of OEM-supplied HAL interfaces System HAL hal_system Interface needed for memory allocation for module loading File HAL hal_file Interface needed to access module information file, module binary file

The control manager 337e also controls the operation of the module manager interface 337a, the module pool 337b, the module information table 337c, and the HAL interface 339. In addition, the module updater 349 interworks with the module updater 349, and the module updater 349 performs update-related operations for each module 107. The module manager 337 provides a HAL interface, manages module information, and performs dynamic loading and unloading of modules. The module manager 337 inquires a list of modules installed in the terminal and inquires information of a specific module.

The module updater 349 is a system application for module update of the mobile platform and is stored in the EFS binary 301. Therefore, the update of the module updater itself can be updated in the same way using the update function of the general application.

The module updater 349 makes it possible to update each module 107 constituting the mobile platform to a higher version. In addition, all modules 107 except for the platform activator 345 and some modules of the kernel layer module 331 required for the update are updated.

The module update server 351 is a system that allows a user to access an application through a terminal to download an application, and stores the latest version of each module 107. The module updater 349 accesses the module update server 351 to download the latest version of each module.

7 to 10 show detailed operations of the module manager 337.

First, FIG. 7 is a flowchart illustrating a process of driving a mobile platform according to an embodiment of the present invention.

As shown in FIG. 7, when the OEM layer module 341 requests platform driving through the initialization function MH_pltStart, the platform activator 345 requests the module manager 337 to initialize the module manager (S101).

The module manager 337 initializes the HAL interface information table and the module information table (S103). The platform activator 345 notifies the module manager initialization completion (S105).

The platform activator 345 requests the module manager 337 to drive the platform (S107). The module manager 337 loads the kernel module 333 (S109) and requests the kernel module 333 to drive the platform (S111).

8 illustrates a process of providing a HAL interface according to an embodiment of the present invention.

As shown in FIG. 8, the platform activator 345 requests the module manager 337 to initialize the module manager (S201). At this time, a function table pointer of the "hal_interface" interface is passed as a parameter.

The module manager 337 initializes the HAL interface information table (S203).

The module manager 337 requests the HAL interface list from the OEM layer module 341 using the "hal_interface" interface received in step S201 (S205).

The OEM layer module 341 composes the list of HAL interfaces provided by the OEM layer to the module manager (S207).

The module manager 337 registers the returned HAL interface list in the HAL interface information table (S209).

Thereafter, the client module requests the module manager 337 to search for a specific HAL interface (S211). At this time, the name of the HAL interface is passed as a parameter in the form of a string. Here, the client module is any module that requests a specific operation from the module manager 337, and may be the module manager itself.

The module manager 337 queries (S213) the HAL interface information table. In operation S215, it is determined whether information for retrieving the requested HAL interface is obtained.

At this time, if the search fails, the failure response is notified to the client module (S217).

However, if the search is successful, the module manager 337 requests the OEM layer module 341 to search for the requested HAL interface (S219).

The OEM layer module 341 configures the function table of the requested HAL interface (S211) and returns it to the module manager 337 (S223).

The module manager 337 registers the returned HAL interface address in the HAL interface information table (S225), and then returns a search response indicating success to the client module (S227).

As such, the module manager 337 retrieves and retrieves the HAL interface so that each module 107 constituting the mobile platform can use the HAL API.

9 illustrates a module manager initialization process according to an embodiment of the present invention. In other words, it shows the module information table loading process when initializing the module manager.

As shown in FIG. 9, the module manager 337 determines whether the platform manager 345 has succeeded in initializing the module manager requested by step S301 (S303).

If successful, the module information table 337c is initialized (S305), and the module information files stored in the EFS binary 301 are searched (S307) to determine whether the module information file exists (S309). Here, the module information file is a file stored in a protocol in which module information is designated. Modules are stored with module information files for module management and module update. Therefore, even when downloading a module of a higher version than a module mounted in a new module or terminal, the module information file is downloaded together.

If the module information file exists, the validity of the module information file is checked (S311) to determine whether it is valid (S313). That is, it is determined whether the module information file and the module binary file stored in the EFS binary 301 are mapped and whether the format of the module information file is normal.

If valid, the found module information file is registered in the module information table 337c (S315). In addition, the platform activator 345 notifies that the module manager initialization is successful (S317).

On the other hand, if the module manager initialization is not successful in step S303, if no module information file stored in the EFS binary (301) and if the module information file is not a valid file is considered as a platform driving failure (S319) and platform activator This is reported to (345) (S321).

In this way, the module manager 337 inquires the module information files installed in the terminal during its initialization process to configure the module information table 337c with the information of each module.

10 illustrates a module information table update process according to an embodiment of the present invention.

As shown in FIG. 10, when the module upgrade S401 is made, the module updater 349 notifies the module manager 337 of the module update (S403). In this case, the added and updated module ID is transmitted as a parameter.

The module manager 337 inquires the module information table 337c (S405) and determines whether the updated module is loaded (S407).

If already loaded, the module updater 349 reports that it is already loaded (S409).

However, if it is not loaded, the module information file is searched (S411) to determine whether the module information file exists (S413).

If the module information file does not exist, the module update failure is reported to the module updater 349 (S415).

However, if the module information file exists, the module information file is read (S417) to determine whether the module information file is a valid file (S419). In other words, check if the file format is normal.

If the file is invalid, the module update failure is reported to the module updater 349 (S421).

However, if the file is valid, the module information file is added to the module information table 337c and updated (S423). The module manager 337 returns success to the module updater 349 (S425).

In this way, the module manager 337 queries the added and updated module information files and updates the module information table 337c with the information of each module.

11 illustrates a module loading process according to an embodiment of the present invention.

As shown in FIG. 11, when a loading of a specific module is requested from the client module (S501), the module manager 337 determines whether to load the specific module by inquiring (S503) the module information table 337c (S505). S507).

If it is already loaded, the module module 337b updates the data structure of the specific module in step S509 without loading the specific module into memory and terminates.

However, if not loaded, the module manager 337 requests the OEM layer module 341 to allocate memory for module loading information (S511). Here, the module loading information is information for managing a module loaded in the memory.

The OEM layer module 341 allocates the memory as much as the requested memory size (S513) and then transmits a memory allocation response to the module manager 337 (S515).

The module manager 337 records module loading information in the allocated memory (S517), and retrieves the module binary of the specific module from the EFS binary (301) (S519).

As a result of the search, it is determined whether the module binary exists (S521), and if present, the module manager 337 reads the module binary (S523) and determines whether the module binary is valid (S525).

If it is not valid, the client module reports the loading failure of the specific module (S527).

If valid, the module manager 337 requests the OEM layer module 341 to allocate the memory required for loading the specific module (S529). The OEM layer module 341 allocates the memory as much as the requested memory size (S531) and responds (S533).

The module manager 337 loads the corresponding module code in the allocated memory (S535).

The module manager 337 calls a module initialization function registered by the module (S537).

The module manager 337 updates the module loading information to register it in the module pool 337b (S539), then updates the module information table 337c (S541) and completes module loading (S543).

12 illustrates a module unloading process according to an embodiment of the present invention. That is, the process of unloading the used modules at the end of the application is shown.

As shown in FIG. 12, the client module notifies the module manager 337 of the termination of a specific application (S601). At this time, the application ID to be terminated and the module loading list pointer are transmitted as parameters.

The module manager 337 searches for the received module loading list (S603) and determines whether there is a loaded module (S605).

If the loaded module does not exist, the procedure is terminated. In other words, the module manager 337 does nothing.

However, if there is a loaded module, the module manager 337 removes an entry corresponding to the application ID from the module loader list among the module loading information of the found module (S607).

The module manager 337 determines whether all terminated application entries have been deleted (S609), and repeats step S607 until there are no remaining entries. In other words, make sure that none of the programs / DLLs / modules have loaded the searched modules.

Thereafter, the module manager 337 returns the memory used by the corresponding module to the OEM layer module 341 (S611) and removes the module loading information of the corresponding module from the module pool 337b (S613). The module information table 337c is updated (S615).

13 illustrates a Java class reference process by an application according to an embodiment of the present invention. That is, it represents a scenario in which an application refers to a class provided by a specific module.

As shown in FIG. 13, the client module requests a class reference from a class loader (S701).

The class loader requests a class entry look-up from the module manager 337 (S703). The class name is passed as a parameter.

The module manager 337 inquires the module information table 337c (S705) and determines whether the requested class exists or not (S707). At this time, if the class does not exist, returns a NULL value to the class loader (S709).

However, if the class exists, the module manager 337 acquires module information including the class (S711) and starts loading the memory of the corresponding module (S713).

It is determined whether the memory loading of the module is successful (S715), and when it fails, a NULL value is returned to the class loader (S717).

However, if the memory loading is successful, the module manager 337 requests the loaded module to search for a class entry, and the module queries its class table to find the address of the requested class entry. It returns to (337) (S719).

The module manager 337 returns the address of the class entry requested to the class loader (S721). The class loader returns the address of the class entry to the client module (S723).

14 illustrates a C API call process by an application according to an embodiment of the present invention. In other words, it represents a scenario in which the application calls the Korea Wireless Internet Standardization Forum (KWISF) standard WIPI-C API.

As shown in FIG. 14, the application requests the kernel module 333 to search for the WIPI-C interface through the 'Stub' code at its driving time (S801). The kernel module 333 requests the module manager 337 to search for the WIPI-C interface (S803).

The module manager 337 checks the module information table 337c (S805) and checks whether the requested WIPI-C interface is included, that is, whether the search is successful (S807).

If the search fails, the module manager 337 returns a driving failure to the kernel module 333 (S809), and the kernel module 333 returns a driving failure to the application (S811).

However, if the search is successful, the module manager 337 obtains module information including the WIPI-C interface (S813). The module is loaded into the memory (S815).

If loading fails (S817), the module manager 337 returns a driving failure to the kernel module 333 (S819), and the kernel module 333 returns a driving failure to the application (S821).

However, if the loading is successful (S817), the module manager 337 requests the loaded module to search for the WIPI-C interface and the module returns its WIPI-C interface address to the module manager 337 (S823). Then, the module manager 337 returns the WIPI-C interface address to the kernel module 333 (S825), and the kernel module 333 returns the WIPI-C interface address to the application (S827).

Then, the application calls the WIPI-C API by referring to the returned WIPI-C interface address.

Next, FIGS. 15 to 23 show detailed operations of the module updater 349.

The request path of the module update has three embodiments. In other words, this is the case of an update through an update platform menu, an update by receiving a callback short message service (SMS), and an update by an update request from an application. Here, the update through the platform menu for update is performed by the wireless update from the module update server, the update to the module stored in the external storage device, and the update by the universal serial bus (USB) communication with the personal computer (PC). Can be used.

15 is a flowchart illustrating a module update process according to the first embodiment of the present invention. That is, the module updater 349 shows a process of performing a module update according to the update driving type.

As shown in FIG. 15, when the module updater 349 is driven, the module updater 349 checks the driving type (S901).

Here, the driving type is defined as 'UPDATE_REQUEST_FROM_WIPI type', 'UPDATE_REQUEST_FROM_CBSMS', and 'UPDATE_REQUEST_FROM_APP', respectively. At this time, 'UPDATE_REQUEST_FROM_WIPI type' indicates an update through the update platform menu. 'UPDATE_REQUEST_FROM_CBSMS' indicates an update by receiving a callback SMS. 'UPDATE_REQUEST_FROM_APP' indicates an update by an update request from an application. In this case, when the driving type is 'UPDATE_REQUEST_FROM_CBSMS' and 'UPDATE_REQUEST_FROM_APP', the 'update request module list' is transmitted as a parameter when the module updater 349 is driven.

Therefore, the module updater 349 determines whether the driving type is based on the menu (S903), and when the menu is driven by the menu, that is, when the module is updated to 'UPDATE_REQUEST_FROM_WIPI type', obtains the latest version module list from the module update server 351. (S905).

Then, the module updater 349 generates an 'update target module list' based on the 'update data request module list' received as a parameter when the module updater 349 is driven or the latest version module list obtained from the module update server 351. (S907).

The module updater 349 checks whether a module of the 'update target module list' is a requested update request by specifying a version (S909).

At this time, in the case of driving the module updater 349 through the update menu, the module requesting the list of modules of the latest version is queried from the module update server 351, so that the module of 'update request module list' is configured. This is a specified update request. However, when an update request is made from a callback SMS or an application, an update request to the latest version is possible without specifying a module.

In response to the versioned update request, the module updater 349 inquires whether the corresponding module is mounted in the terminal (S911).

If the terminal is installed in the terminal, the module updater 349 inquires a version (S913) and determines whether a lower version is installed in the terminal than the module version requested to be updated (S915).

If the lower version is mounted on the terminal, the corresponding module is added to the 'update target module list' (S917). In addition, the module that is requested to update without a version is also added to 'Update target module list'. In addition, the module not mounted in the terminal is also added to the 'update target module list'.

On the other hand, when a module having a higher version or the same version than the version of the update request module is mounted in the terminal, the module update is unnecessary, and thus it is not added to the update target module list.

The module updater 349 determines whether the next module exists (S919), and repeats the subsequent steps from step S911 on all modules of the 'update target module list'.

If the next module does not exist, the module updater 349 obtains module information of the module included in the "update target module list" from the module update server 351 (S921). In this case, the module information includes a module name, a module version, an interface list, a size, and the like.

At this time, when a module update is requested by the callback SMS or an application, there is a possibility that an update is requested to a version of a module that does not actually exist in the module update server 351. Therefore, when the module updater driving type is callback SMS or application, a process of comparing the update request version of the update target module with the latest version in the module update server should be added.

That is, the module updater 349 determines whether the driving type is based on the menu (S923), and when the module update is requested by a callback SMS or an application other than the menu type (S925), the module updater 349 determines.

If it is not a version designation update request, it is determined whether the corresponding module is mounted on the terminal (S927).

If it is mounted on the terminal, it is determined whether the version of the module mounted on the terminal is smaller than the update request version (S929) (S931). If small, the EFS binary capacity is checked (S935).

In addition, if it is determined in step S925 that the version designation update request, it is determined whether the update request version is less than or equal to the version of the module stored in the module update server (S933). If less than or equal to, check the EFS binary capacity (S935).

Also, in the case of the menu type, the EFS binary capacity is also checked (S935).

In addition, when the module is mounted in the terminal in step S927, the EFS binary capacity is also checked (S935).

The module binary of the module is downloaded from the module update server 351 (S937) and installed (S939). At this time, if there is no space to download the module in the EFS area of the terminal during module update, enter the application deletion menu to secure the EFS storage space and download the module. When the EFS storage space is secured, the module updater 349 downloads the module for the update target module, stores the module in the EFS binary of the terminal, and deletes the lower version module mounted on the terminal.

On the other hand, if the update request version is larger than the version of the module stored in the module update server 351, the update is not possible because the version of the requested module does not exist in the module update server 351. In addition, when the version of the module mounted on the terminal is larger than the update request version, the module update is unnecessary. Therefore, in this case, the corresponding module is not updated, and the update processing continues to the next module of the 'update target module list' (S941).

When the update process is completed for all modules in the "Update target module list", the module update is completed.

16 is a flowchart illustrating a module update process according to a second embodiment of the present invention. That is, the user can enter the module update menu provided by the platform and provide a function to update the module.

As shown in FIG. 16, the user drives the module updater 349 in the storage box (S1001) to select a wireless module update (S1003). Then, the storage box requests the module updater 349 to drive the module updater (S1005).

The module updater 349 requests the module update server 351 for querying the latest module information list (S1007). In other words, it retrieves module ID and version list. Then, the module update server 351 transmits the latest module information list to the module updater 349 (S1009).

The module updater 349 receives and transmits the version of the module mounted in the terminal to the module manager 337 (S1011) and receives it (S1013).

The module updater 349 compares the latest version of the module information received from the module update server 351 with the platform module information mounted in the terminal to generate an update target module list (S1015).

The module updater 349 notifies the user of the number of modules to be updated and allows the user to determine whether to update (S1017).

At this time, when the user selects the module update, the module updater 349 requests and transmits the module information included in the update target module list to the module update server 351 (S1019) (S1021).

The module updater 349 checks the capacity of the storage space corresponding to the size of the module information received in S1021 in the EFS binary (S1023).

The module updater 349 downloads the module from the module update server 351 (S1025) and installs it (S1027). That is, delete the lower version module from the EFS binary and install the downloaded higher version module.

The module updater 349 displays a screen informing the user that the update is completed (S1029), and ends the driving.

17 is a flowchart illustrating a module update process according to a third embodiment of the present invention. That is, it shows the update process by receiving a callback SMS.

As shown in FIG. 17, the module update server 351 transmits a callback SMS including module information to be updated to the mobile communication terminal (S1101). Then, the text message handler of the mobile communication terminal outputs the callback SMS reception screen (S1103) and displays it to the user.

When the user selects the module update in the callback SMS (S1105) to drive the module updater 349, the text message handler requests the module updater 349 to drive the module update (S1107).

The module updater 349 extracts module information from the callback SMS (S1109), and compares the extracted module information with the module information mounted on the terminal to generate an update target module list (S1111).

The module updater 349 informs the user of the number of modules to be updated and allows the user to determine whether to update (S1113).

When the user selects the update, the module updater 349 receives the module information included in the update target module list by inquiring (S1115) the module information server (S1117).

The module updater 349 compares the module version of the module information received from the module update server 351 with the update request module version included in the update target module list (S1119).

The module updater 349 checks whether the storage space corresponding to the size of the inquired module is in the EFS binary (S1121).

The module updater 349 downloads the module from the module update server 351 (S1123) and installs it (S1125). That is, the module updater 349 stores the downloaded upper version module in the EFS binary and deletes the lower version module from the EFS binary.

The module updater 349 notifies the user of the completion of the update and ends (S1127).

18 is a flowchart illustrating a module update process according to a fourth embodiment of the present invention. That is, the update process by the update request from the application is shown.

As shown in FIG. 18, the application which has started execution (S1201) is sent to the module manager 337 by inquiring (S1203, S1205) a list of modules mounted in the terminal (S1207, S1209). The application searches the received module list to determine whether a module required by the application exists (S1211). In this case, if there is a module version 337, the module version 337 is inquired (S1213), and received (S1215). If it does not exist, the module version inquiry is not performed.

Thereafter, the application requests the module update from the APM module 305 (S1217) and the application stops executing (S1219). The APM module 305 requests the module updater 349 to drive the module update (S1221).

The module updater 349 generates an update target module list by comparing the module version information requested for the update from the application with the module version information mounted in the terminal (S1223). The module updater 349 informs the user of the number of modules to be updated and determines whether to update (S1225).

When the user selects the update, the module updater 349 inquires the module information included in the update target module list to the module update server 351 (S1227) and receives it (S1229).

The module updater 349 compares the module version inquired by the module update server 351 with the module version included in the update target module list (S1231).

The module updater 349 checks whether the storage space corresponding to the size of the inquired module exists in the EFS binary (S1233).

The module updater 349 downloads and installs the module (S1235) (S1237) and informs the application that the module update is completed (S1239, S1241). The application then resumes execution (S1243).

Meanwhile, when the user enters the 'hidden' menu in the module update menu, the user may select update through USB or update through an external storage device. Here, the 'hidden' menu entry is performed as follows. That is, the user can enter the 'hidden' menu by driving the module updater through the menu of the storage box, entering '*' with the long key on the initial screen, and then entering the password. In this case, the 'hidden' menu provides a UI (UserInterface) for selecting a USB or an external storage device.

First, FIG. 19 is a flowchart illustrating a module update process according to a fifth embodiment of the present invention. That is, the update process by USB communication with a PC is shown. At this time, software for module update (hereinafter referred to as 'PC S / W') must exist in PC, and this PC S / W must be running on PC when selecting module update through USB in module updater. .

As shown in FIG. 19, the user drives the module updater 349 in the storage box (S1301). Then, the module updater 349 enters the 'hidden' menu and selects the USB update from the 'hidden' menu (S1303). The library then requests the module updater 349 to drive the module updater (S1305).

The module updater 349 outputs and receives a user screen UI (S1307) so as to input a port and a connection speed to the user for communication with the PC (S1309).

The module updater 349 requests the OEM layer module 341 to connect to the PC at the input port and the connection speed (S1311). The OEM layer module 341 connects to the PC S / W (S1313) and responds to the module updater 349 (S1315).

The module updater 349 determines whether the connection is successful (S1317). At this time, if the connection fails, that is, if the PC S / W is not stored in the PC, the user is notified that the update via the USB and the module updater 349 is terminated.

However, if the connection is successful, the module updater 349 requests the module list (module ID) stored in the PC to the PC S / W (S1319).

The PC S / W transfers the module list stored in the PC to the module updater 349 (S1321). PC S / W sends the platform updater the list of platform modules in the specified folder. In this case, if the module is not stored, the module updater 349 notifies that the module does not exist.

The module updater 349 informs the user of the number of modules stored in the PC and determines whether to update (S1323).

When the user selects the update, the module updater 349 requests and transmits the module information file included in the module list to the PC S / W (S1325) (S1327).

In addition, the module updater 349 inquires the version of the module mounted in the terminal to the module manager 337 (S1329) and receives the received information (S1331). The module updater 349 compares the module information mounted in the received terminal with the module information received from the PC S / W (S1333). That is, the module updater compares the module version information with the module version mounted in the terminal and performs a module update process when a module having a higher version than the version mounted in the terminal is stored in the PC. If the EFS binary and the module version stored in the PC are the same or if the lower version is stored in the PC, the update is unnecessary, so do not update it.

The module updater 349 checks whether the storage space corresponding to the size of the inquired module is in the EFS binary (S1335).

The module updater 349 downloads and installs the module binary to the PC S / W (S1337) (S1339). That is, the module updater requests the module information file ([module ID] .mdf) stored in the PC to the PC S / W and creates a temporary module information file ([module ID] .tdf) in the terminal EFS. The module updater secures the space required for the version copy for the module to be updated and reads the module binary ([module ID] .jar) in the PC to generate a temporary module binary ([module ID] .tmp) in the terminal EFS. When the temporary module binary file generation is completed, the wrddj and wrddc files in the binary file are read and written to the temporary module information file ([module ID] .tdf). After writing to the temporary module information file, the temporary module binary file and the temporary module information file are renamed. Then, the user is notified that the update is completed (S1341).

20 is a flowchart illustrating a module update process according to a sixth embodiment of the present invention. That is, the process of updating to the module stored in the external storage device. In this case, when the module is stored in the external storage device, the module should be stored together with the module information file in the folder designated by the module updater 349.

As shown in FIG. 20, the user drives the module updater 349 in the storage box (S1401). The module updater 349 enters a 'hidden' menu and selects a module update function through an external storage device (S1403). The library requests the module updater 349 to drive the module updater (S1405).

The module updater 349 inquires whether an external storage device is attached (S1407). If not attached, it notifies that the external storage device is not attached and terminates the module updater 349. However, if attached, the module updater 349 queries the module existing in the external storage device to determine whether the module exists (S1409). If the module does not exist, the user is informed that there is no module to update and the module updater 349 terminates. However, if the module exists, the module updater 349 informs the user of the number of modules stored in the external storage device and determines whether to update (S1411).

When the user selects the update, the module updater 349 requests the OEM hierarchical module to retrieve all the file list stored in the module storage folder of the external storage device using the 'MH_fileList ()' function (S1413) (S1415). .

The module updater 349 performs a module update for a module in which both the module binary and the module information file exist in the external storage device. The module updater 349 reads the module information file stored in the external storage device and copies the module information file in operation S1417. That is, the module updater reads the module information file ([module ID] .mdf) stored in the external storage device and creates a temporary module information file ([module ID] .tdf) in the EFS binary.

The module updater 349 receives and transmits the module version installed in the terminal to the module manager 337 (S1419) (S1421).

The module updater 349 compares the module version mounted in the terminal with the module version in the external storage device (S1423). That is, the module updater compares the module version information included in the temporary module information file with the module version mounted in the terminal and performs a module update process when a module having a higher version than the version mounted in the terminal is stored in the external storage device. . If the module version stored in the EFS binary and the external storage device is the same or if a lower version is stored in the external storage device, no update is required.

The module updater 349 checks whether the storage space corresponding to the module size to be updated is in the EFS (S1425).

The module updater 349 copies and installs the module from the external storage device (S1427). In other words, the module updater reserves the space required for version copy for the module to be updated and reads the module binary ([module id] .jar) stored in the external storage device to the temporary module binary ([module id] .tmp) in the EFS binary. ) When the temporary module binary file generation is completed, the wrddj and wrddc files in the binary file are read and written to the temporary module information file ([module ID] .tdf). After writing to the temporary module information file, the temporary module binary file and the temporary module information file are renamed. Then, the user is notified of the completion of installation (S1429).

21 illustrates a module update process according to a seventh embodiment of the present invention. In other words, it indicates the update according to the location of the lower version module.

As shown in FIG. 21, when an update is requested, the module updater 349 checks the type of an update target module (S1501). In this case, the type may indicate the type of the location where the update target module is stored.

When the module to be updated is the module to be updated in the EFS binary 301 (S1503), the module updater 349 deletes the existing module when the lower version of the module is updated (S1505). The downloaded higher version module is stored (S1507). Subsequently, when the module is loaded, the higher version module stored in the EFS binary 301 is loaded (S1509).

In addition, when the module to be updated is a static module, that is, a module statically loaded in a code area (S1511), the module updater 349 may download the downloaded higher version module to the EFS binary 301. Save (S1513). Thereafter, when the module is loaded, the updated version stored in the EFS binary 301, rather than the lower version in the code region, is loaded first (S1509).

In addition, when the module to be updated is a new module, that is, when a module that is not mounted on the terminal is downloaded (S1515), the module updater 349 stores the newly downloaded module in the EFS binary 301 (S1517). The manager 337 also provides a version control function for the new module. Thereafter, when the module is loaded, the module stored in the EFS binary 301 is loaded (S1509).

22 is a flowchart illustrating a module update process according to an eighth embodiment of the present invention. That is, the HAL module update process is shown. The module updater 349 supports to update the HAL module 343 as well as each module 107 constituting the mobile platform in a terminal supporting an open operating system (Open O / S).

As shown in FIG. 22, the module updater 349 determines whether the update target module is the HAL module 343 by checking the file type (S1603) after querying the module information file (S1601) of the update target module (S1605).

That is, when the value of 'Type' included in the module information file is '10', the platform module update process is performed (S1607). However, when the value of 'Type' is '11', the HAL module 343 is updated. The update process of the HAL module 343 is as follows.

The module updater 349 obtains the module information file mdf in the form of a temporary file by including the HAL module 343 in the update target module in step S1601. If 'Type' has a value of '11' among the information included in the module information file, it means the HAL module 343 and is updated separately from the platform module.

The module updater 349 obtains module interface information of the HAL module 343 corresponding to the update target module ID from the HAL module 343 using the 'MH_infGetInfo (M_Char * name, MH_InterfaceInfo * pInfo) API' (S1609, S1611). The module interface information includes version information of the module.

The module updater 349 compares the module version included in the HAL module 343 interface information inquired from the terminal with the module version included in the module information file acquired in step S1601 (S1613), and the update request version is mounted on the terminal. It is determined whether it is higher than the version (S1615). That is, the update is performed only when the version of the HAL module 343 in the current terminal is a lower version than the module version to be updated.

If it is determined that the S1615 is not the higher version, since the update of the HAL module 343 is unnecessary, the temporary module information file, that is, the update target module information file is deleted, and the update of the corresponding module is terminated.

If it is determined that the S1615 is the higher version, that is, if the update of the HAL module 343 is determined, the module updater 349 obtains the update target module binary (S1617). In other words, obtain the temporary module binary of the update target module. When the temporary module binary is normally acquired, the 'MH_infInstall (M_Char * name, M_Char * path') API 'is called (S1619), and the HAL module 343 installs the higher version HAL module 343 (S1621) and the result value is obtained. The module is transmitted to the module updater 349 (S1623).

When the module updater 349 receives the HAL module installation result from the HAL module 343 normally, the module updater 349 deletes the update target module information file, that is, the temporary module information file (S1625). If the return value of the 'MH_infInstall' function is 1, the terminal is rebooted (S1627).

At this time, the module of the higher version is stored in the EFS in the form of a temporary file to update the module, and when the saving is completed normally, the module of the lower version is deleted and the higher version module is installed. Therefore, at the time of module update, the capacity of the higher version module should be secured in the EFS binary. 23 shows a processing process when the memory storage space is insufficient.

23 is a flowchart illustrating a module update process according to a ninth embodiment of the present invention.

As shown in FIG. 23, when obtaining update target module information from the module update server 351 (S1701), the module updater 349 checks the module size (S1703). Then, it is checked whether the EFS binary capacity of the module size is secured (S1705).

If the module download space is not secured in the EFS binary, the module updater 349 outputs a dialog to the user to confirm whether to delete the contents to secure the storage space (S1709).

At this time, if the user selects 'No' (S1711), the procedure ends.

However, if the user selects "Yes" (S1711), the module updater 349 outputs a list of applications that can be deleted for content deletion (S1713).

The user selects an application to delete from the application list and requests deletion (S1715).

The module updater 349 checks whether the storage space is secured after deleting the requested application (S1717).

At this time, if the storage space is not secured, the application delete process is output again to the user and the application deletion process is repeated (S1709, S1711, S1713, 1715, and S1717).

However, if space is available, module download continues.

In addition, when the EFS binary capacity is greater than or equal to the module size in step S1701 and when the storage space is secured through application deletion, the module updater 349 downloads the module binary (S1719) and installs it (S1721) to update the module. To perform.

Meanwhile, in addition to the basic API provided by the mobile platform, a module development interface for dynamically adding or updating a module is defined. The module has a passage for communicating with the outside called an interface. An interface is a "unit that assigns a name and version to a group of functions and variables." Interfaces are the basic unit for adding and updating APIs.

24 illustrates a module development interface configuration according to an embodiment of the present invention.

As shown in FIG. 24, the module development interface 401 includes a module entry definition API 403, a module entry list definition API 405, a module initialization API 407, a module exit API 409, and a module notify API 411. ).

The module entry definition API 403 defines an entry of an interface to export. An item that must be specified when developing a module. An item for defining an entry includes an interface structure pointer, an interface name, and an interface version (Major, Minor).

The module entry list definition API 405 specifies a list of defined module entries. A module can define more than one interface entry.

The module initialization API 407 defines a function that should be called once when the module is loaded. Using the function defined here, the module developer can perform the initialization required before the module is used. If not declared, the initialization function is not called at loading time.

The module exit API 409 defines a function that should be called once when the module is released from memory. Using the function defined here, the module developer can take necessary actions (eg, release resources) before the module terminates. If not declared, the exit function is not called when unloading the module.

The module notify API 411 defines a function that notifies the module that the application has been started / ended when the application using the module is started / ended. Using the function defined here, the module developer can take necessary actions when the application using the module is started / closed. If not declared, the module notify function is not called.

The embodiments of the present invention described above are not only implemented by the apparatus and method but may be implemented through a program for realizing the function corresponding to the configuration of the embodiment of the present invention or a recording medium on which the program is recorded, The embodiments can be easily implemented by those skilled in the art from the description of the embodiments described above.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

1 is a conventional mobile platform structure.

2 illustrates a binary structure of a conventional mobile platform.

Figure 3a shows the package type of the conventional mobile platform, Figure 3b shows the package interrelationship.

4 is a conceptual diagram illustrating a modular structure for each function of a mobile platform according to an embodiment of the present invention.

5 is a block diagram of a mobile platform according to an embodiment of the present invention.

6 shows a configuration for module management and updating according to an embodiment of the present invention.

7 is a flowchart illustrating a process of driving a mobile platform according to an embodiment of the present invention.

8 illustrates a process of providing a HAL interface according to an embodiment of the present invention.

9 illustrates a module manager initialization process according to an embodiment of the present invention.

10 illustrates a module information table update process according to an embodiment of the present invention.

11 illustrates a module loading process according to an embodiment of the present invention.

12 illustrates a module unloading process according to an embodiment of the present invention.

13 illustrates a Java class reference process by an application according to an embodiment of the present invention.

14 illustrates a C API call process by an application according to an embodiment of the present invention.

15 is a flowchart illustrating a module update process according to the first embodiment of the present invention.

16 is a flowchart illustrating a module update process according to a second embodiment of the present invention.

17 is a flowchart illustrating a module update process according to a third embodiment of the present invention.

18 is a flowchart illustrating a module update process according to a fourth embodiment of the present invention.

19 is a flowchart illustrating a module update process according to a fifth embodiment of the present invention.

20 is a flowchart illustrating a module update process according to a sixth embodiment of the present invention.

21 illustrates a module update process according to a seventh embodiment of the present invention.

22 is a flowchart illustrating a module update process according to an eighth embodiment of the present invention.

23 is a flowchart illustrating a module update process according to a ninth embodiment of the present invention.

24 illustrates a module development interface configuration according to an embodiment of the present invention.

Claims (27)

In the mobile communication terminal equipped with a mobile platform, Each module constituting the mobile platform, wherein each module controls each of the unit functions constituting the mobile platform in a form of a unique platform code binary independent from the terminal binary, and between the respective modules. Or a module manager providing an interface to use each module in an application; And Module updater to update each module to higher version Mobile communication terminal equipped with a mobile platform comprising a. The method of claim 1, The module manager, A module manager interface for implementing an interface for at least one of module list query, module information query, module download and generation for each module; A module pool managing information about each module loaded by the module manager into memory; A module information table for managing information about each module installed in the mobile communication terminal; A hardware adaptation layer interface information table that interfaces with an original equipment manufacturer (OEM) layer module so that each module can call a hardware adaptation layer (HAL) interface and stores a hardware adaptation layer interface list. A hardware adaptation layer interface comprising a; And A control manager controlling operations of the module manager interface, the module pool, the module information table, and the hardware adaptation layer interface Mobile communication terminal equipped with a mobile platform comprising a. The method of claim 2, The module manager interface, A module list inquiry application programming interface (API) providing a list of modules in a form in which module IDs are sequentially listed; A module information inquiry application programming interface for providing module information about a specific module including at least one of a module ID, a module name, a module version, a module size, and whether the module is loaded; A module loading application programming interface for loading a particular module into memory; And Module download application programming interface for downloading new modules and upgrading already installed modules Mobile communication terminal equipped with a mobile platform comprising a. The method according to claim 2 or 3, The control manager, When the mobile platform is requested to run from the OEM layer module, the hardware adaptation layer interface information table and the module information table are initialized to request a kernel module to run the mobile platform. If the initialization is successful, the mobile platform, the hardware adaptation layer interface list received from the OEM layer module is registered in the hardware adaptation layer interface information table, and the previously stored module information file is searched and registered in the module information table. The mounted mobile communication terminal. The method of claim 4, wherein The control manager, When the hardware adaptation layer interface search is requested from each module, the address of the hardware adaptation layer interface requested by each module is returned from the OS layer module based on the information obtained by searching the hardware adaptation layer interface information table. Mobile communication terminal equipped with a mobile platform, characterized in that providing. The method of claim 4, wherein The control manager, When the module update is notified from the module updater, the mobile platform is installed, wherein the updated module ID is received and the module information file of the corresponding module is searched and registered in the module information table to update the module information table. Mobile communication terminal. The method of claim 4, wherein The control manager, When the loading of a specific module is requested, the module information table is queried to determine whether the specific module is loaded, and when loaded, the data structure of the specific module is updated in the module pool. Loading a module and registering the module loading information of the particular module in the module pool and the module information table. The method of claim 4, wherein The control manager, When the termination of the specific application is notified, the module loading information is searched based on the received ID of the specific application and the module loading list, and an entry corresponding to the ID of the specific application is deleted and the module pool and the module information table are deleted. Mobile communication terminal equipped with a mobile platform, characterized in that for removing the module loading information of the modules included in the module loading list. The method of claim 4, wherein The control manager, A mobile communication terminal equipped with a mobile platform, characterized in that the application provides a function of referring to a class provided by a specific module and a C API call function by the application. The method of claim 1, The module updater, Wired through a connection with a universal serial bus or an external storage device that receives an update request via a path including one of selecting an update menu by a user, receiving a callback text message containing update information from a module update server, and requesting an update by an application. A mobile communication terminal equipped with a mobile platform, characterized in that for performing an update for each module by wirelessly or accessing the module update server. The method of claim 1, The module updater, If the update target module is stored in the embedded file system (EFS) binary, the previously saved lower version module is deleted and the higher version module is downloaded and stored. If the update target module is a statically stored module in the code area, Storing a module of a version in the EFS binary and loading the module stored in the EFS binary when the module is loaded, and when the update target module is a new module, storing and loading a newly downloaded module in the EFS binary. Mobile communication terminal equipped with a mobile platform. The method according to claim 10 or 11, wherein The module updater, When the module update is driven, if the drive type is by selecting the update menu, the module update server is queried for the latest version of the module list to construct an update target module list, and a lower version than the latest version is mounted on the terminal. If the module is not loaded, update the corresponding module, and if the driving type is caused by receiving the callback text message or updating by the application, construct an update target module list based on the update request module list acquired in the form of the parameter to the latest version. A mobile communication terminal equipped with a mobile platform, characterized in that for updating the module when a lower version is mounted on the terminal or not. The method of claim 12, The module updater, If the memory capacity to download the module is insufficient when updating the module, the mobile communication terminal equipped with a mobile platform, characterized in that to download the module after securing the memory capacity by deleting the application selected by the user. The method of claim 12, The module updater, In the case of a hardware adaptation layer (HAL) file by querying the module information file of the update target module for which the module update is requested, the module request information is obtained from the hardware adaptation layer module so that the update request version is higher than the previously installed version. In the case of the mobile communication terminal equipped with a mobile platform, characterized in that for installing the hardware adaptation layer file. The method of claim 1, In addition to the basic application programming interface provided by the mobile platform further includes a module development interface for dynamically adding or updating modules, The module development interface, A module entry definition application programming interface defining an entry of an interface for each module to output; A module entry list definition application programming interface specifying a list of defined module entries; A module initialization application programming interface defining a function to be called once when each module is loaded; A module exit application programming interface defining a function to be called once when each module is released from memory; And Module notification application programming interface defining a function for informing each module that the application has been started or terminated when an application using the respective module is started or terminated. Mobile communication terminal equipped with a mobile platform comprising a. A module manager, wherein the module manager comprises a platform code binary form independent from the terminal binary to control each module constituting the mobile platform; receiving a request for platform operation from an original equipment manufacturer (OEM) layer module; Initializing a hardware adaptation layer interface information table storing a module information table and a hardware adaptation layer (HAL) list for managing information about the respective modules; And Loading Kernel Modules to Run Mobile Platforms Mobile platform driving method comprising a. The method of claim 16, After the step of receiving the request, Receiving a hardware adaptation layer interface list from the OEM layer module and registering the hardware adaptation layer interface information table in the hardware adaptation layer interface information table; And Searching for module information files stored in an embedded file system (EFS) binary and registering them in the module information table Mobile platform driving method further comprising a. The method of claim 17, After registering in the hardware adaptation layer interface information table, Retrieving the hardware adaptation layer interface information table when a specific hardware adaptation layer interface search is requested; Requesting the OEM layer module for the specific hardware adaptation layer interface based on the information obtained by searching the hardware adaptation layer interface information table; And Receiving the address of the specific hardware adaptation layer interface from the OEM layer module and registering the address in the hardware adaptation layer interface information table Mobile platform driving method further comprising a. A module manager, wherein the module manager is formed in a unique platform code binary form independent from the terminal binary to control each module constituting the mobile platform; Recording module loading information and module binaries of the specific module in the allocated memory, and loading the specific module; And Module loading information for the particular module in a module pool for managing information about each module loaded by the module manager into a memory and for each module installed in the mobile communication terminal. Steps to update Module management method comprising a. The method of claim 19, Between the requesting step and the loading step, Querying the module information table, if it is determined that the specific module has already been loaded, updating and terminating the data structure of the specific module in the module pool; Module management method further comprising. 21. The method according to claim 19 or 20, After the updating step, Receiving a request for module unloading due to termination of a specific application; Deleting an entry corresponding to the ID of the specific application from a module loader list including application information loading a specific module; Removing module loading information of the specific module from the module pool and the module information table Module management method further comprising. A module updater, wherein the module updater is formed in a unique platform code binary form independent from the terminal binary to perform an update function of each module constituting the mobile platform; And Delete the previously saved lower version module and download and save the higher version module Module update method comprising a. The method of claim 22, The storing step, Determining whether the driving type is by selecting an update menu, by receiving a callback text message, or by an application; Querying the module update server for a list of modules of the latest version when the update menu is selected, and constructing an update target module list; Constructing an update target module list based on an update request module list acquired in the form of a parameter when the driving type is due to receiving the callback text message or updating by the application; And Determining whether to download a corresponding module if a version lower than a version of a module included in the update target module list is loaded in the terminal or if the corresponding module is not loaded; Module update method comprising a. 24. The method of claim 23, After the determining step, Determining whether a memory capacity for downloading the module is sufficient; If the memory capacity is not sufficient, outputting a list of erasable applications to a user; Deleting the application selected by the user to secure a memory capacity; And Downloading and storing the corresponding module Module update method further comprising a. The method according to any one of claims 22 to 24, The requesting step, A path including one of selecting an update menu by a user, receiving a callback text message with update information from a module update server, and requesting an update by an application, and by wire or via the connection with a universal serial bus or an external storage device. Module update method characterized in that the request to update by wireless access to the update server. The method of claim 22, The storing step, Querying a module information file of an update target module for which a module update is requested; If the module information file is a hardware adaptation layer (HAL) file, obtaining module interface information from a hardware adaptation layer module; And Installing the hardware adaptation layer file when the update request version is higher than the pre-loaded version. Module update method further comprising a. The method of claim 22, The storing step, Confirming, by the module to which the module is requested to be updated, a location currently stored in the terminal; Deleting the previously stored lower version module and downloading and storing the upper version module when the EFS binary is stored; If the module is statically stored in a code area, storing the downloaded higher version module in the EFS binary and loading the module stored in the EFS binary when the module is loaded; And If the module to be updated is a new module, downloading the new module and storing and loading the new module in the EFS binary Module update method comprising a.

Images