System and method for the management of wireless communications device system software downloads in the field

(background) (1. Field of invention) The present invention relates generally to wireless communication, and more specifically to security systems for reprovisioning and reprogramming wireless communication devices.

(2. Related technology) Wireless communication devices, including any type of device that communicates over a wireless communication network, are programmed and provisioned when manufactured. Alternatively, these devices may be programmed and provisioned when launched by a retailer such as Sprint, Verizon, AT & T Mobile or a network access provider. Wireless communication devices (also referred to herein as "wireless devices", "handsets" or "mobile devices") programs and provisioning (collectively referred to herein as "programming") have mobile identification numbers (also referred to herein as "programming"). Provides "MIN") (phone number and other operating parameters, also known as network parameters) and application software. These items are placed in permanent memory on the handset, where they cannot be modified or deleted.

The handset is typically programmed by the carrier or service provider when the handset is activated. In a conventional handset, after this program is performed, a lock code (also referred to herein as an "access code") is also placed in permanent memory on the handset. Subsequent attempts at any future program will first refer to the access code, ie, reprovisioning or reprogramming (collectively "reprogramming" herein) before the handset allows modification of its permanent memory. A process known as (called) must be provided.

Traditional security of this type for reprogramming handsets faces many challenges. Application utilities and tools have been developed with the gray and black market interests in being able to know the access code of a handset, thereby allowing the handset to be reprogrammed. Often, the reprogrammed phone is then sold to unsuspecting consumers as a gray market product. In addition, these fraudulently reprogrammed phones are also sold in the black market, where they confuse legitimate consumers by disrupting the network with unpaid traffic.

<p> Therefore, there is a need for systems and methods that provide additional security against unauthorized reprogramming in the handset without interfering with authorized reprogramming.</p>

<p> (Summary) Traditional handsets can now be reprogrammed in the field with fairly inexpensive software utilities and serial connections. Such reprogramming allows these handsets to be sold to the gray or black market, where their illegal use disrupts radio waves with additional traffic and disrupts network access for paying customers.</p><p> Systems and methods that improve security in handset reprogramming to prevent handsets from being reprogrammed in the field without specific authorization from a service provider (also referred to herein as the "carrier"). Is provided. A particular advantage of this new solution is that carriers can keep a record of when, where, and by whom the market-distributed phones were reprogrammed. In addition, requiring carrier approval to reprogram the handset significantly increases the difficulty and complexity of reprogramming the handset to be distributed to the gray or black market.</p><p> If the handset receives a reprogramming request or detects a reprogramming attempt, the handset communicates with the carrier for reprogramming authorization. The network may provide authorization, deny authorization, request more information from the reprogramming device, or communicate directly with the reprogramming device to authorize the reprogramming.</p><p> Advantageously, the handset can be manufactured without the access code being stored in permanent memory. The absence of this access code does not provide the possibility of the handset being reprogrammed without the operator's knowledge and authorization. Further advantages and applications of the systems and methods presented herein will become apparent after a review of the detailed description.</p><p> Details of the invention can be gathered by examining the accompanying drawings in part, both in terms of structure and operation. In these drawings, the same reference numerals refer to the same parts.</p>

(Detailed explanation) Specific embodiments described herein provide a system and method of two-way communication of a dynamic instruction set between a wireless communication device and a wireless communication network. For example, one method described herein allows a wireless communication device to dynamically build an instruction set and send it to a network to execute and process the instruction set.

After reading this description, those skilled in the art will appreciate embodiments of the present invention in various embodiments and alternative applications. However, although various embodiments of the invention are described herein, it is understood that these embodiments are merely exemplary and not limited. Therefore, the detailed description of these various alternative embodiments should not be construed as limiting the scope or gist of the invention as set forth in the appended claims.

Some parts of the detailed description below are presented with procedures, steps, logic blocks, code, processing, and other symbolic representations of operation in a wireless device microprocessor or data bits in memory. These descriptions and representations are the means utilized by those skilled in the art of data processing technology, which are intended to provide the other technician in question with the substance of the work most effectively. Procedures, steps performed on a microprocessor, applications, logic blocks, processes, etc. are considered herein and generally as a consistent sequence of steps or instructions that lead to the desired result. This step is a step that requires a physical operation of a physical quantity. Usually, but not required, these quantities can take the form of electrical or magnetic signals that can be stored, transmitted, coupled, compared, and otherwise manipulated in microprocessor-based wireless devices. Showing these signals as bits, values, elements, symbols, letters, terms, numbers, etc. has proven to be a common usage in principle and sometimes convenient. When referring to physical devices such as memory, they are connected to other physical devices via a bus or other electrical connection. These physical devices interact with a logical process or application and can therefore be considered "connected" to a logical operation. For example, memory can store or access code for additional logical operations, or an application can call a code section from memory to perform.

However, all these and similar terms should relate to appropriate physical quantities and are merely convenient labels that apply to these quantities. Unless otherwise specified, terms such as "processing," "connection," "translation," "display," "prompt," "judgment," "display," or "recognition" throughout the invention, as will be apparent from the following description. The description using is similar to the data shown as the physical (electrical) quantity in the register and memory of the computer system as the physical quantity in the wireless device memory or register or other such information storage device, transmitting device or display device. Shows the actions and processes of a wireless device microprocessor system that manipulates and converts to other data shown in.

FIG. 1 is a schematic block diagram of the entire 100 wireless device software maintenance system. The organization of the system software of the present invention is shown in detail below and follows General Overview 100 of Software Maintenance Systems. A typical system 100 describes the process of delivering system software updates and instruction sets (programs), and installing the delivered software on wireless devices. System software updates and patch manager runtime instructions (PMRTIs), more commonly known as instruction sets or dynamic instruction sets, are created by the handset manufacturer. The system software is organized into a symbol library. The symbol library is located within the code section. If the symbol library is updated, software update 102 is transported as one or more code sections. Software updates are either broadcast to field radio devices (wireless communication devices 104 are representative) or are separate from base station 106 in known conventional air and using data or message transport protocols. It is sent by the communication of. The present invention is readily modified to allow wireless communication devices to handle any available over-the-air transport protocol for the purpose of receiving system software and PMRTI updates. As you get, you are not limited to any particular transportation format.

System software can be considered a collection of different subsystems. Code objects can be tightly connected to one of these abstract subsystems, and the resulting collection can be labeled as a symbol library. This provides a logical breakdown of the code base, and software patches and fixes may be associated with these symbol libraries. Often, a single update is associated with one or at most two symbol libraries. The rest of the code base, the other symbol libraries, remains unchanged.

The symbol library concept provides a mechanism for working with code and constants. Read / write (RW) data, on the other hand, fits into a unique individual RW library that contains RAM-based data for all libraries.

When received by the wireless device 104, the transported code section must be processed. This wireless device overwrites the unique code section of non-volatile memory 108. Non-volatile memory 108 includes a file system section (FSS) 110 and a code storage section 112. The code section is typically compressed before transport to minimize FSS110 occupancy. Often, the updated code section is accompanied by RW data, which is another type of symbol library that contains all the RW data for each symbol library. The system software is loaded into random access volatile read-write memory 114 at run time, but RW data must always be stored in non-volatile memory 108, so RW data is stored every time the wireless device is reset. Can be loaded into random access volatile read-write memory 114. This includes loading the first RW data into random access volatile read-write memory. RW data is typically placed in the patch manager code section, as described in more detail below.

System 100 includes the concept of virtual tables. With such a table, the symbol library of one code section is patched (replaced) without breaking (replace) other parts of the system software (other code sections). The virtual table runs from random access volatile read-write memory 114 for efficiency. The code section address table and the symbol offset address table are virtual tables.

The updated code section is received by the wireless device 104 and stored in the FSS 110. The wireless device user interface (UI) usually notifies the user that new software is available. In response to the UI prompt, the user acknowledges the notification and signals the patch or update action. Alternatively, the update operation is automatically executed. The wireless device may not be able to perform standard communication tasks when the update process is performed. The patch manager update section may also include a non-volatile read-write driver symbol library loaded into random access volatile read-write memory 114. The non-volatile read-write driver symbol library overwrites the code section with the code section to be updated. As shown in the figure, the code section n and the patch manager code section are overwritten with the updated code section. The patch manager code section includes read-write data, a code section address table, and a symbol offset address table, as well as symbol accessor codes and symbol accessor code addresses (discussed below). A portion of this data is invalid when the updated code section is introduced, and the updated patch manager code section is valid read-write data, code section address table, and code section address table for the updated code section. Includes symbol offset address table. Once the updated code section is loaded into the code storage medium 112, the wireless device is reset. Following the reset operation, the wireless device may run the updated system software. Note that the patch manager code section may include other symbol libraries not mentioned above. These other symbol libraries do not need to be loaded into read-write volatile memory 114.

FIG. 2 is a schematic block diagram of Software Maintenance System 100 highlighting the installation of instruction sets via the airlink interface. In addition to the update system software code section, maintenance system 100 may download and install a dynamic instruction set, program, or patch manager instruction set (PMIS), referred to herein as the patch manager runtime instruction (PMRTI). .. The PMIS code section 200 is transported to the wireless device 104 in the same manner as the system software code section described above. The PMIS code section is first stored in FSS110. The PMRTI code section is usually a binary file that can be visualized as an instruction to a compiled handset. The PMRTI code section is comprehensive enough to provide the performance of basic mathematical operations and the performance of operations performed conditionally. For example, RF-tuned PMRTI may perform the following actions:

<maths num="1"><img file="JP4728359B2_D0001.tif" /></maths>

PMRTI may support basic mathematical operations such as addition, subtraction, multiplication, and division. The PMRTI code section, along with the system software code section, can be loaded in response to a UI prompt, and the wireless device must be reset after PMRTI is loaded into the code storage section 112. The PMRTI section can then be executed. If the PMRTI code section is associated with any virtual table or read-write data, the updated patch manager code section is transported with the PMIS for installation in code storage section 112. Alternatively, PMRTI can be retained and processed from FSS110. After the handset 104 has executed all the instructions in the PMRTI section, the PMRTI section may be removed from the FSS110. Alternatively, PMRTI is maintained for further operation. For example, PMRTI can be performed each time a wireless device is energized.

PMRTI is a very powerful runtime instruction engine. The handset may execute any instruction delivered to the handset via the PMRTI environment. This mechanism can be used to support RF tuning and PRI updates. More generally, PMRTIs can be used to remotely debug wireless device software, typically when software issues such as the result of user dissatisfaction are recognized by the manufacturer or service provider. PMRTI can also record the data needed to diagnose software problems. PMRTI can launch newly downloaded system applications for data analysis, debugging, and modification. PMRTI may provide RW data-based updates for analysis of a problem and correction in the shortest possible time, instead of the updated system software code section. PMRTI may provide a memory compression algorithm for use by wireless devices.

In some aspects of the invention, organizing the system software into a symbol library can affect the size of the volatile and non-volatile memory 114 required for execution. This is due to the fact that the code section is larger than the symbol library, which is usually located within the code section. These larger code sections exist to accommodate the update code sections. Organizing system software as a collection of libraries affects the size requirements of non-volatile memory. The fact that the code section can be larger than the symbol library placed inside increases the amount of non-volatile memory used for the same code size.

Once the software update has been delivered to the wireless device, the software maintenance system 100 supports memory compression. Memory compression is similar to a desktop computer disk defragmentation application. The compression mechanism ensures that memory is best utilized and well balanced for future code section updates, where the size of the code section to be updated is unpredictable. System 100 parses the patched (updated) code storage section. System 100 attempts to adapt the updated code section to the memory space occupied by the code section being replaced. If the updated code section is larger than the code section to be replaced, system 100 compresses the code section in memory 112. Alternatively, the compression may be calculated by the manufacturer or service provider and the compression instructions may be transported to the wireless device 104.

Compression can be a time-consuming process due to the complexity of the algorithm and the enormous amount of data movement. The compression algorithm predicts feasibility before any processing begins. UI prompts can be used to apply permission from the user before compression is attempted.

In certain aspects of the invention, the entire system software code section may be updated at the same time. However, a complete system software update requires a larger FSS110.

FIG. 3 is a schematic block diagram showing the execution of the dynamic instruction set of the present invention in a wireless communication device. The system 300 comprises a code storage section 112 in memory 108 containing executable wireless device system software divided into a plurality of current code sections. Code sections 1 (302), 2 (304), and n (306), as well as patch manager code section 308 are shown. However, the invention is not limited to any particular number of code sections. System 300 also includes a first plurality of symbol libraries located within a second plurality of code sections. Shown are symbol libraries 1 (310) located in code section 1 (302), symbol libraries 2 (312) and 3 (314) located in code section 2 (304), and code section n (306). ) Is the symbol library m (316). Each library contains symbols with associated functionality. For example, symbol library 1 (310) may be involved in the operation of a wireless device liquid crystal display (LCD). And the symbol is related to the display function. Further symbol libraries are located in patch manager code section 308, as detailed below.

FIG. 4 is a schematic block diagram of the wireless device memory. As shown, the memory is the code storage section 112 of FIG. The memory is a writable non-volatile memory such as a flash memory. It is understood that the code section does not necessarily have to be stored in the same memory as the FSS110. It is also understood that the system software structure of the present invention is enabled by code sections stored in multiple collaborative memories. The code storage section 112 includes a second plurality of consecutively addressed memory blocks, where each memory block stores a code section corresponding to the second plurality of code sections. Therefore, code section 1 (302) is stored in the first memory block 400, code section 2 (304) is stored in the second memory block 402, and code section n (306) is stored in the nth memory. It is stored in block 404, and the patch manager code section (308) is stored in memory block 406 of p.

In contrast to Figures 3 and 4, the starting point of each code section is stored at the corresponding starting address in memory, and the symbol library is arranged to start at the starting point of the code section. That is, each symbol library starts at the first address and runs through a range of addresses consecutively from the first address. For example, code section 1 (302) starts at the first start address 408 (marked with an "S") in code storage section memory 112. In FIG. 3, symbol library 1 (310) starts at the starting point 318 of the first code section. Just as code section 2 (304) starts at the second starting address 410 (Figure 4), symbol library 2 starts at the starting point 320 of code section 2 (Figure 3). The code section n (306) starts at the third starting address 412 (FIG. 4) of the code storage section memory 112, and the symbol library m (316) starts at the starting point of the code section n322 (FIG. 3). The patch manager code section starts at the start address 414 of p in the code storage section memory 112, and the first symbol library of the patch manager code section 308 starts at the start point 324 of the patch manager code section. Therefore, the symbol library 1 (310) is finally stored in the first memory block 400. If the code section contains a plurality of symbol libraries such as code section 2 (304), the plurality of symbol libraries are stored in the corresponding memory blocks (in this case, the second memory block 402).

In FIG. 3, system software structure 300 further includes code section address table 326 as a type of symbol contained in the symbol library located in patch manager code section 308. The code section address table cross-references the code section identifier with the corresponding code section start address in memory.

FIG. 5 is a table showing the code section address table 326 of FIG. The code section address table 326 is referenced to find the code section start address for the symbol library. For example, system 300 searches code section 1 when a symbol in symbol library 1 is needed for execution. The code section address table 326 is referenced to find the starting address of code section 1 and therefore position the symbol in symbol library 1. The placement of the code section symbol library and the tracking of the code section by the table allows the code section to be moved and expanded. Extended or move behavior may be required to install the upgraded code section (including the upgraded symbol library).

Returning to FIG. 3, not all symbol libraries start at the beginning of the code section. As shown, symbol library 3 (314) is located in code section 2 (304) but does not start at code section start address 320. Therefore, if the symbols in symbol library 3 (314) are needed for execution, system 300 references code section address table 326 for the starting address in code section 2 (304). The symbol offset address table allows the symbols of symbol library 3 (314) to be positioned, as described below. Spreading symbols across multiple libraries is not a problem unless they are kept in the same code section.

As mentioned above, each symbol library contains functionally related symbols. A symbol is a programmer-defined name for locating and using a communication body, variable, or data structure over the air. Therefore, the symbol can be an address or a value. The symbol can be internal or external. Internal symbols are not visible beyond the scope of the current code section. More specifically, internal symbols are not searched by other symbol libraries in other code sections. External symbols are used and called between code sections and are searched by libraries in different code sections. The symbol offset address table usually contains a list of all external symbols.

For example, the symbol library (310) produces characters on a wireless device display. The symbols in this library generate phone numbers, names, times, or other display functions. Each function is generated by communication over the air, which is referred to as a symbol in the present specification. For example, one symbol in symbol library 1 (310) generates a phone number on the display. This symbol is represented by an "X" and is external. When a wireless device receives a phone call and the caller ID service is activated, the system must generate a number on the display if it wants to execute the "X" symbol. Therefore, the system must position the "X" symbol.

FIG. 6 is a detailed view of the symbol library 1 (310) of FIG. 3 having symbols. The symbols are arranged so that they are offset from the start address of each code section. In many situations, the starting point of a symbol library is the starting point of a code section, but this is not the case if the code section contains more than one symbol library. Symbol library 1 starts at the starting point of code section 1 (see Figure 3). As shown in FIG. 6, the "X" symbol is located at an offset of (03) from the starting point of the symbol library, and the "Y" symbol is located at an offset of (15). The symbol offset address is stored in the symbol offset address table 328 in the patch manager code section (Figure 3).

FIG. 7 is a table showing the symbol offset address table 328 of FIG. The symbol offset address table 328 cross-references the symbol identifier by the corresponding offset address and the corresponding code section identifier in memory. Therefore, the system searches to execute the "X" symbol in symbol library 1, and the symbol offset address table 328 is referenced to locate the exact address of the symbol for the code section in which it is located.

Returning to FIG. 3, all of the first plurality of symbol libraries usually contain read-write data that must be referenced or set at run time of these symbol libraries. For example, a symbol library may contain behaviors that depend on conditional statements. Refer to the read-write data section to determine the status required to complete a conditional statement. The present invention groups read-write data into read-write sections shared by all symbol libraries. In one aspect of the invention, the read-write data 330 is located in patch manager code section 308. Alternatively (not shown), the read-write data can be located in a different code section, eg code section n (306).

The first plurality of symbol libraries also include a symbol accessor code that is placed in the code section to calculate the address of the symbol to be searched. The symbol accessor code may be located and stored at the address of a separate code section, eg code section 2 (304). However, as shown, the symbol accessor code 332 is located and stored at the address of patch manager code section 308. The system software structure 300 further includes a first location for storing the symbol accessor code address. The first location can be the code storage section 112, or the code section in a separate memory section of the wireless device (not shown). The first position can also be located in the same code section as the read-write data. As shown, the first position 334 is a patch manager code section with read-write data 330, symbol offset address table 328, code section address table 326, symbol accessor code 332, and patch library (patch symbol library) 336. Stored in 308.

The symbol accessor code uses the code section address table and the symbol offset address table to find the exact address of the symbol to be searched for in memory. That is, the symbol accessor code calculates the address of the symbol searched using the corresponding symbol identifier and the corresponding code section identifier. For example, if the "X" symbol in symbol library 1 is searched, the symbol accessor is called to search for the symbol identifier (symbol ID) X_1 corresponding to the "X" symbol (see Figure 7). Is done. The symbol accessor code refers to the symbol offset address to determine that the X_1 symbol identifier has an offset of (03) from the starting point of code section 1 (see Figure 6). The symbol accessor code is called to look up the code section identifier CS_1, corresponding to code section 1. The symbol accessor code refers to the code section table to determine the starting address associated with the code section identifier (code section ID) CS_1. In this method, the symbol accessor code determines whether the symbol identifier X_1 is an offset of (03) from the address of (00100) or is located at the address (00103).

The symbol "X" is a reserved name because it is part of the actual code. In other words, the symbol "X" is the absolute value data associated with it. The data can be an address or a value. A symbol identifier is an alias generated to track a symbol. Both the symbol offset address table and the code section address table work with identifiers to avoid confusion with reserved symbols and code section names. Also, the same symbol name can be used across many symbol libraries. The use of identifiers avoids confusion between these symbols.

Returning to FIG. 1, the system software structure 300 further includes read-write volatile memory 114, typically random access memory (RAM). Read-write data 330, code section address table 326, symbol offset address table 328, symbol accessor code 332, and symbol accessor code address 334 are read-write from the patch manager section for running access of the system software. Loaded into volatile memory 114. As is well known, access time for code stored in RAM is much shorter than access to non-volatile memory such as Flash.

Returning to Figure 3, the symbol libraries are sized to exactly contain the corresponding code sections where the memory blocks are stored, although they do not necessarily have to fill the code section in which they are located. .. Instead, each of the second plurality of code sections has a byte size that accommodates the symbol library to be placed, and each of the contiguously addressed memory blocks accommodates the corresponding code section. Has a bite size to do. For example, code section 1 (302) can be a 100-byte section containing a symbol library having a length of 100 bytes. The first block of memory is 100 bytes, which matches the byte size of code section 1. However, the symbol library loaded in code section 1 may be smaller than 100 bytes. As shown in FIG. 3, code section 1 (302) has unused section 340 if symbol library 1 (310) is less than 100 bytes. Therefore, each of the second plurality of code sections has a size larger than the size required to accommodate the symbol library to be placed. An "excessive size" code section may accommodate a larger updated symbol library.

A memory block that is continuously addressed is to divide the physical memory space into logic blocks of various sizes. Code sections and memory blocks are terms that are virtually interchangeable when code sections are stored in memory. The concept of code sections is used to identify when a symbol library in a code section, or a section of code that is probably larger than a collection of symbol libraries, is moved and manipulated.

As found in FIG. 3, in order to place a new code section in the code storage section that has the current code section, system 300 includes a patch symbol library referred to herein as patch library 336. The placement of the new code section along with the current code section in the code storage section forms an updated executable system software. Patch Manager 336 not only places a new code section with the current code section, but also replaces the code section with the updated code section.

Returning to FIG. 4, file system section 110 in memory 108 receives new code sections such as new code section 450 and updated patch manager code section 452. The file system section also receives a first patch manager runtime instruction (PMRTI) 454 containing instructions for placing a new code section along with the current code section. As found in FIG. 1, the airlink interface 150 receives a new or updated code section, as well as a first PMRTI. Note that the airlink interface 150 is represented by an antenna, but the airlink interface 150 also includes an RF transceiver, a baseband circuit and a demodulation circuit (not shown). File system section 110 stores a new code section received via airlink interface 150. Patch library 336 runs from read-write volatile memory 114 and updates the first code section of the code storage section, eg code section n (306), in response to the first PMRTI454. Replace with code section 450. Patch manager code section 308 is typically replaced with patch manager code section 452 that is updated. If the code section is replaced, patch library 336 will replace the first code section in code storage section 112, eg code section n (306), with the updated code section in file system section 110, eg code section. Overwrite 450. In the extreme case, all code sections in code storage section 112 are replaced with updated code sections. That is, the FSS110 receives a second plurality of updated code sections (not shown), and the patch library 336 is a second in the code storage section 112. Replace multiple code sections with a second multiple updated code sections. Naturally, the FSS110 must be large enough to accommodate a second set of updated code sections received via the airlink interface.

As mentioned above, the received updated code has a read-write data code section, a code section address table code section, a symbol library, a symbol offset address table code section, a symbol accessor code section, or a code with a new patch library. Can include sections. All these code sections can be stored as separate and independent code sections, along with related symbol libraries and symbols. Each of these code sections is then replaced with a uniquely updated code section. That is, the updated read-write code section is received and replaces the read-write code section in the code storage section. The updated code section address table code section is received and replaces the code section address table code section in the code storage section. The updated symbol offset address table code section is received and replaces the symbol offset address table code section in the code storage section. The updated symbol accessor code section is received and replaces the symbol accessor code section in the code storage section. Similarly, the updated patch manager code section (which has the patch library) is received and replaces the patch manager code section in the code storage section.

However, the code sections mentioned above are usually bundled within the patch manager code section. Therefore, the read-write code section in the code storage section is replaced with the updated read-write code section from file system section 110 if patch manager code section 308 is replaced with updated patch manager code section 450. Will be done. Similarly, if the updated patch manager code section 450 is installed, the code section address table, symbol offset address table, symbol accessor code section, and patch library will be replaced. New read-write data, new code section address table, new symbol offset address table, new symbol accessor code, and updated patch manager New patch library as code section 450, placed with the current code section in the code storage section Form updated executable system software.

When file system section 110 receives the updated symbol accessor code address, the patch manager replaces the symbol accessor code address at the first location in memory with the updated symbol accessor code address. As mentioned above, the first location of 334 in memory is usually in the patch manager code section (see Figure 3).

As found in FIG. 3, patch library 308 may further include a compressor, or compressor symbol library 342. Compressor 342 can also be enabled as separate and separate code sections, but as mentioned above, bundling features associated with system software upgrades into a single patch manager code section is useful and efficient. .. Generally, the compressor 342 can be thought of as resizing the code section, which allows the new section to be placed with the current code section in the code storage section 112.

With respect to the aspects of the present invention of organization, download, and compression established herein, the following description will be focused on the wireless communication device dynamic instruction set execution system 300. System 300 includes executable system software and system data separated from the code section, as described in detail above. In addition, the system 300 includes a dynamic instruction set for computing on system data and system software and controlling the execution of the system software. As shown in FIG. 4, the dynamic instruction set 470 is organized into a first PMRTI454. As found in Figure 3, the system also includes a run-time engine for processing the dynamic instruction set enabled by run-time library 370. As mentioned for compressor library 342 and patch library 336, runtime library 370 is typically located in patch manager code section 308. However, the runtime library 370 may instead be located in another code section, eg, the first code section 304.

A dynamic instruction set is one or more sets of instructions that contain conditional operation codes and typically contain data items. The runtime engine reads the operation code and determines which operations need to be performed. The operation code can be conditional, mathematical, procedural or logical. The run-time engine, or run-time library 370, processes a dynamic instruction set to perform operations such as mathematical or logical operations. That is, the runtime engine reads the dynamic instruction set 470 and executes a sequence of operations in response to this operation code. The dynamic instruction set is not limited to any particular language, but the operation code is usually in the form of machine code because the wireless device memory is limited and execution speed is important. Opcodes are considered conditional in that they analyze data items and make decisions as a result of the analysis. The run-time engine may also decide that operations on the data are performed before it is parsed.

For example, the operation code may specify that the data from the wireless device memory is compared to a given value. If the data item is less than a given value, the data item is left alone, and if the data item is greater than a given value, it is replaced with a given value. Alternatively, the operation code may add a second predetermined value to the data item from the wireless device memory before the comparison operation described above is performed.

As mentioned above, the file system section non-volatile memory 110 receives a dynamic instruction set through an interface such as the Airlink 150. As shown in Figure 1, the interface can also be a radio frequency (RF) hardline 160. The PMRTI can then be received by the FSS110, rather than the system software being in an operating state, such as in a factory tuning environment. PMRTIs may also be received via logical port interface 162, or installable memory module 164. The memory module 164 may be installed on the wireless device 104 by initial adjustment or during factory readjustment. Unless otherwise stated, PMRTI can be received via an infrared or Bluetooth interface.

Figure 8 shows the instructions accessed by the runtime engine 370. Shown are the first instruction 800, the second instruction 802, and the jth instruction 804, but the dynamic instruction set is not limited to any particular number of instructions. The length of the operation code in each instruction is fixed. The runtime engine 370 captures the length of an instruction, like a byte or bit measurement, and determines whether the instruction contains a data item. The remaining length of the instruction after the operation code is subtracted includes the data item. The runtime engine extracts data items from instructions. As shown, length 806 of the first instruction 800 is measured and data item 808 is extracted. Note that not all instructions necessarily contain the data item to be extracted. The runtime engine 370 uses this extracted data 808 when executing a sequence of operations in response to operation code 810 at instruction 800.

FIG. 9 is a more detailed view of the first instruction 800 of FIG. Using the first instruction 800 as an example, the instruction includes operation code 810 and data 808. The instruction, and more specifically, the data item section 808, includes a symbol identifier, which acts as a link to the symbol in the wireless device code section. As already described in detail, the symbol identifier is used with the code section address table 326 (see Figure 5) and the symbol offset address table 328 (see Figure 7) to place the symbol corresponding to the symbol identifier. Be done. As shown, the symbol identifier "X_1" is given in the first instruction 800. The symbol offset address table 328 places the corresponding symbols in the code section with the "CS_1" identifier and the offset of "3". The code section address table 326 gives the starting address (302) of code section 1. In this way, the symbol "X" is found (see Figure 6).

After the runtime engine places the symbol corresponding to the received symbol identifier using the code section address table and the symbol offset address table, it extracts the data if the placed symbol is a data item. For example, if the symbol "X" is a data item in symbol library 1 (310), the runtime engine will extract it. Alternatively, the "X" symbol can be an operation code, and the runtime engine causes the symbol "X" to be executed when it is placed.

PMRTI can be used to update system data or system data items. In some aspects of the invention, system data is stored in the file system section 110, eg, the code section in code section 472 (see Figure 4). The runtime engine accesses and parses the system data from code section 472. The run-time engine processes the operation code of dynamic instructions to perform mathematical or logical operations on data items, as described above. After the operation, the runtime engine processes instructions that generate updated system data. Note that the updated system data may contain data items that do not change in some situations. The system data in section 472 of the second code is replaced with the updated system data in response to the operation code. Therefore, the processing of instructions by the run-time engine controls the system software to execute with the updated system data in code section 472. In this way, a particular targeted symbol in the system software can be updated, but the entire code section is not replaced. By the same process, system data can be replaced in the code section in the code storage section 112. For example, the system data may be stored in the third code section 344 and the runtime engine may replace the system data in the third code section with the updated system data in response to the operation code.

PMRTI can also be used to update the data in volatile memory 114. As an example, volatile memory 114 receives read-write data 330 (see Figure 1). Read-write data may be output from one or more code sections in the code storage section 112 and / or FSS110. The runtime engine accesses the read-write data, parses the read-write data 330, generates updated read-write data, and responds the read-write data 330 in the volatile memory 114 to the operation code. And replace it with the updated read-write data 330. The system software is then controlled to run with the updated read-write data in volatile memory 114.

In some aspects of the invention, the runtime engine monitors the execution of system software. Performance monitoring is widely defined to include a large number of wireless device activities. Data such as records of data items in RAM may be collected through a sequence of operations leading to, for example, channel parameters, channel characteristics, system stacks, error states, or certain failure or performance degradation states. It is also possible to use a dynamic instruction set to analyze the collected performance data, provide variants of the updated data, and recapture the data to consider possible solutions to the problem. Primary repairs may also be provided using the PMRTI process.

More specifically, the runtime engine collects performance data and stores the performance data in the file system section in response to the operation code. The system software is then controlled to perform by collecting performance data for evaluation of the system software. The evaluation can be performed as a form of analysis performed by the dynamic instruction set operation code, or the evaluation can be performed outside the wireless device. In some aspects of the invention, the runtime engine accesses the performance data collected from the file system section and sends the performance data over the airlink interface in response to the operation code. Collecting performance data from field wireless devices allows manufacturers to thoroughly analyze problems locally or globally without having to recall the device.

In some aspects of the invention, file system section 110 receives patch manager runtime instructions that include a new code section. For example, the new code section 474 is shown in Figure 4. Alternatively, a new code section, such as the new code section n (450), cannot depend on PMRTI. For example, the new code section n (450) may be received over previous airlink communications or may be installed during factory adjustments. The runtime engine responds to the operation code by adding a new code section 474 (450) to the code storage section. In some aspects of the invention, new code sections are added to unused blocks in code storage section 112. Alternatively, a compression operation is required. The system software is then controlled to run using the new code section 474 (450). In another aspect of the invention, PMRTI454 includes updated code section 474. Alternatively, the new code section 450 is an updated code section that does not depend on PMRTI. The runtime engine replaces the code section in the code storage section, eg, code section 2 (304), with code section 474 (450) that is updated in response to the operation code. The system software is controlled to run using the updated code section 474 (450). In some aspects of the invention, compression operations are required to accommodate updated code sections. Alternatively, the updated code section is added to the unused or empty section of the code storage section.

As mentioned above, adding a new code section or updating a code section usually requires the generation of a new code section address table, which means that these operations are new and / or modified code section start addresses. This is because it includes a table. In addition, compression operations also require a new code section address table. The compression operation can be the result of the operation of compressor 342 described above, or the result of a PMRTI instruction that provides details about the compression method. If the PMRTI contains download and compression instructions, the PMRTI will also include a new code section address table that will usually take effect after the download and compression are complete.

10a and 10b are flowcharts showing the method of the present invention to execute a dynamic instruction set in a wireless communication device. For clarity, it is shown as a sequence of numbered steps, but unless otherwise stated, the order should not be inferred from numbering (and numbering in the methods described below). The method begins at step 1000. Step 1001a forms the system software into a symbol library, where each symbol library contains symbols with associated functionality. Step 1001b places the symbol library in the code section. Step 1002 runs the system software. Step 1003 receives the dynamic instruction set. The step of receiving the dynamic instruction set in step 1003 receives the dynamic instruction set through an interface selected from the group including airlinks, radio frequency (RF) hardlines, installable memory modules, infrared and logical port interfaces. Including doing. In some aspects of the invention, the step of receiving a dynamic instruction set in step 1003 comprises receiving a patch manager runtime instruction (PMRTI) in the file system section non-volatile memory.

Step 1004 starts the runtime engine. The step of starting the runtime engine usually involves calling the runtime library from the first code section. The runtime engine can be started from volatile or non-volatile memory. Step 1006 processes the dynamic instruction set. The steps of processing a dynamic instruction include processing the instruction in response to mathematical and logical operations. In some aspects of the invention, step 1007 (not shown) removes the dynamic instruction set following the processing of the dynamic instruction set. Step 1008 computes on system data and system software. Step 1010 controls the execution of the system software in response to system data and operations on the system software.

Typically, the step of receiving the patch manager runtime instruction in step 1003 involves receiving a conditional operation code and a data item. The step of processing the dynamic instruction set in step 1006 then includes a substep. Step 1006a1 uses the runtime engine to read the patch manager runtime instruction operation code. Step 1006b executes a sequence of operations in response to the operation code.

In some aspects, the step of placing the symbol library in the code section in step 1001b starts the symbol library at the start of the code section and places the symbol offset from the respective code section start address. Including that. The method then involves further steps. Step 1001c stores the start of the code section at the corresponding start address. Step 1001d maintains a code section address table (CSAT) that cross-references the code section identifier with the corresponding starting address. Step 1001e maintains a symbol offset address table (SOAT) that cross-references the symbol identifier with the corresponding offset address and the corresponding code section identifier.

In some aspects of the invention, the step of receiving a patch manager runtime instruction in step 1003 comprises receiving a symbol identifier. The method then involves further steps. Step 1006a2 places the symbol corresponding to the symbol identifier received by using the code section address table and the symbol offset address table. The step of executing a sequence of operations in response to the operation code in step 1006b includes substeps. Step 1006b1 extracts the data if the placed symbol is a data item. Step 1006b2 executes this symbol if the placed symbol is an instruction.

In some aspects of the invention, the step of processing a dynamic instruction in step 1006b1 includes a further substep. Step 1006b1a, patch manager Use the runtime engine to capture the length of the runtime instructions. Step 1006b1b extracts the data item from the patch manager runtime instruction in response to the operation code. Step 1006b1c uses the extracted data in response to the operation code to execute the sequence of operations.

FIG. 11 is a flowchart showing an exemplary dynamic instruction set operation. Some of the steps in FIG. 11 are the same as in FIG. 10 and are not repeated here for brevity. The step of processing the dynamic instruction set in step 1106 includes substeps. Step 1106a accesses the system data stored in the second code section of the file system section. Step 1106b analyzes the system data. Step 1106c generates updated system data. The steps of calculating on the system data and system software in step 1108 then include the step of replacing the system data in the second section with the updated system data, and the step of controlling the execution of the system software in step 1010. Includes the steps of using updated system data in the execution of system software.

FIG. 12 is a flowchart showing another exemplary dynamic instruction set operation. Some of the steps in FIG. 12 are the same as in FIG. 10 and are not repeated here for brevity. Step 1201c stores a plurality of code sections in the code storage section non-volatile memory. The step of processing the dynamic instruction set of step 1206 includes substeps. Step 1206a accesses the system data stored in the third code section in the code storage section (CSS). Step 1206b analyzes the system data. Step 1206c generates updated system data. The steps of computing on the system data and system software in step 1208 include replacing the system data in the third code section with the updated system data. The step of controlling the execution of the system software in step 1210 includes the step of using the updated system data in the execution of the system software.

FIG. 13 is a flowchart showing a third exemplary dynamic instruction set operation. Some of the steps in FIG. 13 are the same as in FIG. 10 and are not repeated here for brevity. Step 1301c stores a plurality of code sections in the code storage section non-volatile memory. Step 1301d loads the read-write data into volatile memory. The step of processing the dynamic instruction set of step 1306 includes substeps. Step 1306a accesses read-write data in volatile memory. Step 1306b analyzes the read-write data. Step 1306c generates updated read-write data. The step of computing on the system data and system software in step 1308 includes replacing the read-write data in the volatile memory with the updated read-write data. The step of controlling the execution of the system software includes the step of using the updated read-write data in the execution of the system software.

FIG. 14 is a flowchart showing a fourth exemplary dynamic instruction set operation. Some of the steps in FIG. 14 are the same as in FIG. 10 and are not repeated here for brevity. Steps that process a dynamic instruction set include substeps. Step 1406a monitors the execution of system software in response to the operation code. Step 1406b collects performance data. Step 1406c stores performance data. Step 1406d sends the stored data over the airlink interface. The system data of step 1408 and the step of calculating on the system software include the step of using the performance data in the evaluation of the system software.

FIG. 15 is a flowchart showing a fifth exemplary dynamic instruction set operation. Some of the steps in FIG. 15 are the same as in FIG. 10 and are not repeated here for brevity. Step 1501c stores a plurality of code sections in the code storage section non-volatile memory. The step of receiving the patch manager runtime instruction in step 1503 includes the step of receiving a new code section. The step of computing on the system data and system software in step 1508 includes the step of adding a new code section to the code storage section, and the step of controlling the execution of the system software in step 1510 is the new code in the execution of the system software. Includes steps using sections.

Alternatively, the step of receiving a new code section in step 1503 includes the step of receiving an updated code section. The step of computing on the system data and system software of step 1508 then includes replacing the fourth code section in the code storage section with the updated code section.

Systems and methods are provided to perform dynamic instruction sets in wireless communication devices, thereby assisting the process of updating software and monitoring software performance. The system is easily updatable because the symbol library is located in the code section and uses a table to access the start address of the code section in memory and the offset address of the symbol in the symbol library. The use of dynamic instruction sets allows custom changes to be made to each wireless device based on the specific characteristics of that device. Some common examples are given to show the possible use of dynamic instruction sets. However, the present invention is not limited to these examples. Other modifications and embodiments of the present invention will come to those skilled in the art.

FIG. 16 is a diagram of a high-level network showing an exemplary wireless communication network according to an embodiment of the present invention. The wireless communication networks shown are connected to wireless communication devices 10, 12 and 14, respectively, via multiple wireless communication devices 10, 12 and 14, multiple base stations 20 and 22, PMRTI server 30, and network 40, respectively. It is equipped with a security server 35.

Further illustrated in the exemplary embodiment is a reprogramming device 45 that is connected to the handset 14 by a direct connection 47. The direct connection 47 is a hard-wired physical connection between the handset 14 and the device 45 to be reprogrammed, for example, a serial cable or a wired network connection. The device 45 to be reprogrammed may also be connected to a network such as the Internet 42, which may provide the device 45 to be reprogrammed with access to the network 40. Further, the device 45 to be reprogrammed may have a wireless communication capability that allows it to connect to the network 40 via a base station such as, for example, a base station 22.

The wireless communication device 10 can be any type of device capable of communicating within the wireless communication network. For example, the wireless communication device 10 can be a cell phone, a personal digital assistant (PDA), a laptop computer, a wristwatch, or any other device configured for wireless communication. Wireless communication devices may also be referred to herein as "handsets," "mobile phones," or "mobile devices."

The base station 20 is preferably configured to communicate with a plurality of wireless communication devices over the air, and is a transceiver (not shown) that converts the communication over the air into wired communication moving through the network 40. including. Preferably, the network 40 is a private network operated by a wireless carrier. The network 40 preferably provides an infrastructure for handoff between base stations such as base stations 20 and 22. In addition, network 40 preferably provides communication links between various uses, services, and other computer-based servers such as PMRTI server 30 and security server 35.

Network 40 also includes integrated services digital network (ISDN), subscriber telephone network (PLMN), public land mobile network (PSTN), and packet-switched public data network (Packet Switched). It can be used as a conduit for connecting to public data networks (PSPDN)) and other networks (not shown) such as the Internet (only a few).

The PMRTI server 30 is realized as one computer or multiple servers logically arranged to provide a dynamic instruction set to a mobile device and execute the dynamic instruction set received from the mobile device. obtain. Similarly, the security server 35 can be implemented using a general purpose computer with one or more microprocessors, as is well known in the art. Remarkably, both the security server 35 and the PMRTI server 30 can be implemented on a single physical server machine, where they share hardware and system resources. The security server 35 and PMRTI server 30 can further share data files and can be combined to communicate through interprocess communication technology, or can be physical or wireless communication over network 40.

FIG. 17A shows an exemplary wireless communication device 10 according to an embodiment of the present invention. The general features of wireless communication devices that allow such functioning are well known to those of skill in the art and are therefore not shown or described herein.

In one embodiment, the handset 10 includes an access code 55. The access code 55 is stored in permanent memory on the handset 10 that cannot be modified or deleted. The access code 55 can be an alphanumeric string, a hexadecimal number, a binary number, or the like. Preferably, the access code 55 is a large number or string that is very difficult to obtain by random and rogue reprogramming utilities and tools. In an alternative embodiment, handset 10 does not include access code 55. If the access code is not available on the handset 10, it is completely impossible for the reprogramming utility to gain access to the handset in a manner that allows reprogramming. Advantageously, in the absence of the access code present in Handset 10, only the carrier may authorize reprogramming. Such an embodiment significantly improves the security of reprogramming in the handset.

In one embodiment, the access code 55 may include a flag that directs the carrier network to visit to authorize the handset to be reprogrammed. In this way, the carrier can update the flag contained in access code 55, which can turn off reprogramming security and reset it for local decisions (eg, providing the correct access code). If), or may be reset for carrier approval. Advantageously, this allows carriers to flexibly control reprogramming security at a finer level of individual handsets.

Handset 10 further includes a runtime engine 50, a remote operation code (opcode) library 60, a server opcode library 70, and a remote runtime opcode section 80. The runtime engine 50 may preferably be configured to handle a dynamic instruction set. An example of a dynamic instruction set is the PMRTI instruction set. Another example of a dynamic instruction set is the RPMRTI instruction set. The differences between these two instruction sets include those functions that the PMRTI set can perform by wireless devices, while the RPMRTI instruction set includes those functions that can be performed by the PMRTI server 30 residing on network 40. Including.

Processing the dynamic instruction set includes executing the RPMRTI set received from the PMRTI server 30 and compiling the PMRTI set and the corresponding data for transmission to the PMRTI server 30. Preferably, the runtime engine 50 can be started by the wireless communication device 10 as needed, thereby computing only when needed on the device 10 and with the minimum amount of system resources (eg, memory, CPU cycles, etc.). ) Is consumed.

The remote opcode library 60 preferably comprises a population of opcodes representing each PMRTI function or executable code segment. Advantageously, the remote opcode library 60 contains operation code that is used as a placeholder for actually executable machine code functions or code segments. Therefore, the remote opcode library 60 includes a list of all available operation codes corresponding to each and all PMRTI functions that can be performed by the wireless communication device 10.

Similarly, the server opcode library 70 preferably contains a population of operation codes representing each PRMRTI function or executable code segment. Advantageously, the server opcode library 70 contains only currently executable machine code functions or code segment operation codes that do not reside on the wireless communication device 10. Therefore, the server opcode library 70 contains a list of all operation codes for each available RPMRTI function that can be performed by the PMRTI server 30 on behalf of the wireless communication device 10.

In a preferred embodiment, the number of RPMRTI features available can well exceed the number of PMRTI features available. This is because the PMRTI server 30 does not suffer from the minimum resources normally found on mobile devices such as cell phones and PDAs.

In addition, the wireless communication device 10 includes a remote runtime instruction code section 80. Code section 80 is where the actual machine code or executable instructions reside in permanent memory on device 10. These executable instructions or code segments preferably have a one-to-one correspondence with the opcodes contained in the remote opcode library 60. FIG. 17B is a block diagram showing an exemplary code section 80 according to an embodiment of the present invention. As shown, any number of PMRTI functions from instruction 01 to instruction n may be included in code section 80. Optimally, a number of features are available in code section 80, and it consumes very little resource (eg, permanent memory) of device 10.

Advantageously, the server opcode library 70, the remote opcode library 60, and the corresponding code section 80 are wireless communication devices during the manufacture of device 10 and before it is deployed in the field (ie, before it is purchased by the customer). Can be installed in permanent memory on 10. Future updates to the set of opcodes contained in the library or the set of executable instructions in code section 80 may be provided by the PMRTI server 30 that implements the process described below with respect to FIG.

Finally, in the embodiments shown, the wireless communication device includes a communication link 90 over the air. The realization of a communication link 90 is well known to those of skill in the art and provides the wireless communication device 10 with the ability to communicate within the wireless communication network 100 over a wireless or other aerial connection. Advantageously, the aerial communication link 90 may provide a means for the PMRTI server 30 to update the remote opcode library 60, the server opcode library 70 and the remote runtime opcode section 80.

FIG. 18A is a block diagram showing an exemplary PMRTI server 30 according to an embodiment of the present invention. The functions of a general-purpose computer that can realize a PMRTI server will be described later with reference to FIG.

In the embodiments shown, the PMRTI server 30 includes a control module 95, a remote opcode library 60, a server opcode library 70, and a server runtime opcode section 82. The remote opcode library 60 and the server opcode library 70 preferably include a list of the same operation codes as the libraries present on the wireless communication device 10. The control module 95 preferably processes a dynamic instruction set and manages a network of PMRTI communication between the PMRTI server 30 and a plurality of wireless communication devices available over the wireless communication network. It is composed of.

For example, the control module 95 may compile various dynamic PMRTI sets and send these instruction sets to various separate wireless communication devices. Similarly, the control module 95 may further receive multiple dynamic RPMRTI sets and execute these instruction sets instead of transmitting wireless communication devices.

The remote opcode library 60 preferably contains a population of operation codes corresponding to each available PMRTI function or executable code segment. Advantageously, the remote opcode library 60 contains a list of operation codes that are used as placeholders for the actual feasible machine code functions (on wireless communication devices) or code segments in the remote runtime instruction code section 80. Therefore, the remote opcode library 60 includes a list of all available opcodes for all available PMRTI features that can be performed by the wireless communication device.

Similarly, the server opcode library 70 preferably contains a population of operation codes corresponding to each RPMRTI function or executable code segment. Advantageously, the server opcode library 70 contains only the operation code of the machine code function that can actually be executed, or the code segment that can be executed by the PMRTI server 30. In a preferred embodiment, the number of RPMRTI features available can well exceed the number of PMRTI features available. This is because the PMRTI server 30 does not suffer from the minimal resources normally found on mobile devices such as cell phones and PDAs.

In addition, PMRTI server 30 includes server runtime instruction code section 82. Code section 82 is where the actual machine code or executable instructions reside in permanent memory on the server 30. These executable instructions or code segments preferably have a one-to-one correspondence with the operation code contained in the server opcode library 70, which resides on both the server 30 and the wireless communication device 10. FIG. 18B is a block diagram showing an exemplary server runtime instruction code section according to an embodiment of the present invention.

FIG. 19 is a flow chart illustrating an exemplary process for executing a dynamic instruction set on a wireless communication device according to an embodiment of the present invention. First, in step 500, the wireless device receives a set of remote opcodes. The set of remote opcodes can be received via a communication link over the air, for example a link with a wireless communication network. Preferably, the opcode is optimized to minimize the amount of data transmitted over the air. In addition, the data payload may be included with the set of opcodes received by the wireless device.

In step 502, the wireless device launches the runtime engine to process the remote opcode set. As shown in step 504, the runtime engine parses the remote opcode set and then extracts the data payload in step 506. This step can be omitted if the data payload does not exist. If a data payload is present, the resulting data may be stored in an available portion of volatile memory for later use. The run-time engine then retrieves the executable instructions that correspond to the opcodes in the remote opcode set, as shown in step 508. These instructions can be obtained from the remote runtime instruction code of the wireless device.

Once the executable instruction corresponding to the opcode in the remote opcode set is obtained, the runtime engine executes the instruction, as shown in step 510. When the instruction is executed, any necessary data to be calculated can be obtained from the volatile memory where the data payload is stored. Alternatively, or in addition, any required data to be calculated can be obtained as a result of the executed instruction.

For example, the data payload may include updated software modules for wireless devices. In addition, one of the opcodes in the remote opcode set may correspond to an executable instruction to replace a section of permanent memory with a portion of the data payload. In this example, that portion of the permanent memory to be replaced is the stale software module, and as a result, the software module to be updated is loaded into the permanent memory by instruction. Therefore, the remote opcode and data payload are calculated by the wireless device to update the software module.

Once the instruction set is fully executed by the run-time engine, the run-time engine can be terminated, as shown in step 512. Advantageously, the runtime engine can be started and terminated, which allows the runtime engine to run only as needed. This can save system resources on wireless devices and, for example, volatile memory space and CPU cycles.

FIG. 20 is a flow chart illustrating an exemplary process for compiling a dynamic instruction set on a wireless communication device according to an embodiment of the present invention. First, the runtime engine is started, as shown in step 520. Once the runtime engine is running, the engine can compile a set of server opcodes, as shown in step 522. A set of server opcodes can be obtained from a background process running on a wireless device. Alternatively, the server opcode set can be obtained from a process running on the wireless device under the direction of the user.

For example, a wireless device may include a routine set that is periodically and automatically run by the operating system to perform system maintenance or other desired function. These procedures can generate a server opcode set by the runtime engine as a result of executing them. Alternatively, the user initiates multiple sets of routines that are performed only when requested by the user. Multiple sets of routines may also allow the server opcode set to be generated by the runtime engine. In both cases, the result is produced by the runtime engine, as shown in step 522.

Once the server opcode set has been generated, the runtime engine determines in step 524 whether the data payload accompanies the server opcode set. If there is required data to accompany the server opcode set, in step 526 the runtime engine executes an instruction to fetch that data from permanent or volatile memory or return the required data. Once the data is retrieved, the runtime engine then inserts the data into the server opcode set, as shown in step 528. One easy way to achieve this is to attach the data payload to the server opcode set in a single data packet.

Once the data payload is combined with the server opcode set, or if the data payload is not required, the runtime engine servers the server opcode set (with or without the data payload), as shown in step 530. Send to. After the server opcode set has been sent, the runtime engine may be terminated to free resources on the wireless device, as shown in step 532.

FIG. 21 is a flow chart illustrating an exemplary process for executing a dynamic instruction set on a PMRTI server according to an embodiment of the present invention. First, in step 540, the server receives the server opcode set. An opcode set is preferably a list of names (monikers) that represent a series of executable instructions, each opcode representing a separate executable or a separate set of executable instructions. Once the set of server opcodes is received, in step 542 the server parses the server opcode set and extracts any data payload contained with the server opcode set, as shown in step 544. If the data payload is extracted, it may be temporarily stored in volatile memory on the server for later use.

The server then gets the corresponding instruction set, as shown in step 546. Preferably, the corresponding instruction set is stored in the server runtime instruction code section, which resides in permanent memory on the PMRTI server machine. Once the instruction set is obtained, the server executes the instruction set, as found in step 548. When the instruction set is executed, the routine to execute may use the data payload that came with the server opcode set. Preferably, the data payload is stored in memory on the server for this purpose. Alternatively, the routine to be executed may include instructions that generate the data that the instruction set needs to perform this function.

FIG. 22 is a flow chart illustrating an exemplary process for operator authorization of handset reprogramming. First, in step 580, the handset receives a reprogramming request from the device to be reprogrammed. The device can be connected to the handset via a direct serial cable or a local physical network connection. The device can also be connected to multiple handsets via a local network connection or via a one-to-many serial cable connection that allows the device to be reprogrammed to work with multiple handsets.

Once the handset receives a reprogramming request, a reprogramming attempt, or an attempt to determine the access code of the handset, the handset sends a query to the carrier via wireless communication means, as shown in step 582. .. This request is sent to determine if handset reprogramming is authorized by the carrier. If the handset receives a response from the carrier over the same wireless means, it determines if reprogramming is authorized, as shown in step 584. If reprogramming is authorized in step 586, the handset allows reprogramming, for example, by providing the access code to the device to be reprogrammed if the access code is present.

If reprogramming is not authorized, reject the reprogramming request as shown in step 588. Advantageously, the carrier can log the request. In addition, the carrier may query the handset for location information such as GPS to determine the location where the reprogramming attempt was made. This information can be useful if the reprogramming attempt has not been approved.

FIG. 23 is a flow chart showing an exemplary disclosure and private key process for handset reprogramming carrier authorization. First, in step 590, the handset receives a reprogramming request. The handset then gets as much information as possible about the reprogramming. For example, the handset may obtain the IP address or MIN of the device to be reprogrammed if the device's radio is enabled. Additional information may also be obtained.

In step 594, the handset acquires unique information such as MIN and ESN, as well as other information requested by the carrier to identify the handset. Once the information has been collected, the handset sends the information to the carrier, as shown in step 596. This information may be transmitted to a security server on the wireless network for processing. After transmitting the information, the handset receives the private key from the carrier, as shown in step 598. The handset converts the private key with a unique public key in step 600 and then receives the key from the device to be reprogrammed in step 602. The handset then proceeds to compare the converted keys with the keys from the device to reprogram and find out if they match, as shown in step 604. If the keys match, authorization is provided for reprogramming, as shown in step 608. However, if the keys do not match, at step 606 the handset rejects the reprogramming request.

Similar to the carrier contacting the reprogramming device with the device information reprogrammed (from the handset perspective) in the process described above, and the carrier sending the private key to the handset in step 598. It is important to note that the carrier's private key is sent to the device to be reprogrammed. The private key is the origin of any key conversion by the reprogramming device, so the reprogramming device must obtain the private key, and thus this is a handset to be converted and compared. Can be sent to. If the device to be reprogrammed cannot receive the private key and convert it to send the converted key to the handset, the handset will time out and be configured to reject the reprogramming request. Can be done.

FIG. 24 is a flow chart illustrating an exemplary process for generating an unauthorized reprogramming window on a handset. In embodiments where the carrier has a large inventory of telephones that need to be reprogrammed, the carrier may choose to turn off the reprogramming security procedure for a predetermined time interval. For example, a 6-hour window can be thought of as allowing a service provider to reprogram a block of handsets.

First, the carrier sends the instruction to a group of handsets, or, instead, a single handset. Such instructions can be delivered by the PMRTI server using the remote opcode set described above. At step 620, the handset receives this command from the carrier. The instruction orders the reprogramming security procedure to be turned off during a specific time window. The instruction can also instruct the handset to indefinitely turn off the reprogramming security procedure. Alternatively, the instruction commands the handset to turn on security procedures. In this case, the instruction orders the handset to turn off the security procedure for a 6-hour window and is started immediately.

At step 622, the handset turns off the reprogram security feature. The handset is then periodically checked to determine if the end of a predetermined cycle has been reached, as shown in step 624. If the cycle is still valid, the handset continues to wait, as shown in step 626. The latency between each check can be set at small, large, or various intervals that determine how closely the interval at which the reprogramming security feature is turned back on.

FIG. 25 is a flow chart illustrating an exemplary PMRTI process for handset reprogramming carrier authorization. First, the handset receives the reprogramming request, as shown in step 640. Upon receiving such a request, the handset retrieves information from the device to be reprogrammed, as shown in step 642. This information may include a software identification number (to identify the reprogramming utility), MIN, or any other unique identifier of the device or software utility, or tool used by the device to be reprogrammed.

At step 644, the handset acquires unique identifying information such as useful or useful information such as MIN, ESN and location. Once the device information to be reprogrammed is obtained by the handset, in step 646, the handset generates a data payload containing this information. Further information may be provided. Next, in step 648, the handset includes a server opcode containing the data payload and a server opcode representing an instruction that the server authorizes reprogramming. This server opcode set is then sent to the carrier in step 650, where it is first delivered to the PMRTI server and then to the security server. These two servers can be implemented on the same machine and even run as a single combined software application.

After the server opcode set has been processed by the carrier, the handset receives the remote opcode set from the carrier, as shown in step 652. Upon receiving the remote opcode set, the handset extracts the data payload in step 654 and then translates the set's remote opcode into executable instructions, as shown in step 656. The handset then executes these instructions in step 658 to determine if authorization has been provided by the carrier. Authorization or rejection from the carrier may be included in the data payload along with instructions to unpack the response from the data payload and deliver the response to the handset operating system, or utility that communicates with the device to be reprogrammed. Thus, once the handset has authorization or rejection from the carrier, the handset responds to the device reprogramming in a positive or negative manner.

On the server side, the carrier preferably logs each reprogramming request from the handset. In addition, carriers may retain statistics on successful or unsuccessful reprogramming attempts. In addition, the carrier may authorize the reprogramming based on the information provided with the device to be reprogrammed. In addition, the carrier may authorize partial reprogramming of the handset. For example, this is advantageous if an older handset is donated to a shelter or other institution. These handsets retain the original MIN of the handset while they can be reprogrammed for certain types of network access.

FIG. 26 is a block diagram showing an exemplary computer system 550 that can be used with the various examples described herein. For example, the computer system 550 can be used as a PMRTI server or security server resident in a wireless communication network. The computer system 550 can also be used as any of a variety of other common or general purpose computer systems, including wireless communication networks and their components. However, as will be apparent to those skilled in the art, other computer systems and architectures may be used.

The computer system 550 preferably comprises one or more processors, such as a processor 552. Auxiliary processor that manages inputs and outputs, auxiliary processor that performs floating minority scoring operations, dedicated microprocessor (eg, digital signal processor) with the appropriate architecture to run signal processing algorithms at high speed, dependent on the main processing system Additional processors such as slave processors (eg, back-end processors), additional microprocessors or controllers for dual or multiprocessor systems, or coprocessors may be provided. Such auxiliary processors can be separate processors or can be integrated with processor 552.

The processor 552 is preferably connected to the communication bus 554. The communication bus 554 may include a data channel to facilitate communication between the storage and other peripheral components of the computer system 550. The communication bus 554 may provide a set of signals used for communication with the processor 552, including a data bus, an address bus, and a control bus (not shown). The communication bus 554 is, for example, ISA (Industry Standard Architecture), EISA (Extended industry Standard Architecture), MCA (Micro Channel Architecture), PCI (Peripheral Component Interconnect), local bus, or IEEE488GPIB (General-Purpose Interface). Bus), any standard such as a bus architecture conforming to the standard promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE696 / S-100, etc., or a non-standard bus architecture may be provided.

The computer system 550 may preferably include a main memory 556 and also a secondary memory 558. Main memory 556 provides storage of instructions and data for programs running on processor 552. Main memory 556 is typically semiconductor-based memory such as dynamic access memory (DRAM and / or static random access memory (SRAM). Other semiconductor-based memory types are read-only memory (ROM). ), For example, synchronous dynamic random access memory (SDRAM), rambus dynamic random access memory (RDRAM), strong dielectric random access memory (FRAM), and the like.

The secondary memory 558 selectively includes a hard disk drive 560 and / or, for example, a floppy® disk drive, a magnetic tape drive, a compact disk (CD) drive, a digital versatile disk (DVD) drive, and the like. May include a removable storage drive 562. The removable storage drive 562 reads from and / or writes to the removable storage medium 564 in a well-known manner. The removable storage medium 564 can be, for example, a floppy (registered trademark) disk, magnetic tape, CD, DVD, or the like.

The removable storage medium 564 is preferably a computer-readable medium that stores computer-executable code (ie, software) and / or data. The computer software or data stored in the removable storage medium 564 is read into the computer system 550 as a telecommunications signal 578.

In an alternative embodiment, the secondary memory 558 may include other similar means that allow a computer program, or other data or instruction, to be loaded into the computer system 550. Such means may include, for example, an external storage medium 572 and interface 570. Examples of the external storage medium 572 may include an external hard disk drive or an external optical drive, or an external magneto-optical drive.

Other examples of secondary memory 558 are programmable read-only memory (PROM)), erasable programmable read-only memory (EPROM, electrically erasable read-only memory (EEPROM), or flash memory (EEPROM). Bro similar to EEPROM It may include semiconductor-based memory such as (cook-oriented memory). In addition, any other removable storage unit 572 and interface 570 that allow software and data to be transmitted from the removable storage unit 572 to the computer system 550 are included.

The computer system 550 may further include a communication interface 574. Communication interface 574 allows software and data to be transmitted between the communication system 550 and an external device (eg, a printer), network, or information source. For example, computer software or executable code may be transferred from a network server to computer system 550 via communication interface 574. Examples of communication interface 574 include modems, network interface cards (NICs), communication ports, PCMCIA slots and cards, infrared interfaces, and IEEE1394 firewires, to name a few.

The communication interface 574 is preferably an Ethernet® IEEE 802 standard, fiber channel, digital subscriber line (DSL), asynchronous digital subscriber line (ADSL), frame relay, asynchronous transfer mode ("DSL"). "ATM"), Integrated Services Digital Communication Network ("ISDN"), Personal Communication Service ("PCS"), Transmission Control Protocol / Internet Protocol ("TCP / IP"), Serial Line Internet Protocol / Point-to-Point Protocol ("" It implements industry-wide protocol standards such as "SLIP / PPP"), but can also implement customized or non-standard interface protocols.

Software and data transmitted over communication interface 574 is typically in the form of telecommunications signal 578. These signals 578 are preferably provided to communication interface 574 via communication channel 576. Communication channel 576 carries signal 578 and is a variety of means of communication, including wires or cables, fiber optics, conventional telephone lines, cellular telephone links, radio frequency (RF) links, or infrared links, to name a few. Can be implemented using.

Code that can be executed by a computer (ie, a computer program or software) is stored in main memory 556 and / or secondary memory 558. The computer program may also be received via communication interface 574 and stored in main memory 556 and / or stored in secondary memory 558. Such a computer program, when executed, allows the computer system 550 to perform various functions, as described above.

In this description, the term "computer readable medium" is used for any medium used to provide computer system 550 with code that can be executed by a computer (eg, software and computer programs). Examples of these media include main memory 556, secondary memory 558 (including hard disk drive 560, removable storage medium 564, and external storage medium 572), and communication interface 574 (including network information servers or other network devices). ) Includes any peripheral devices that are communicatively connected. A computer-readable medium is a means of providing executable code, program instructions, and software to a computer system 550.

In embodiments implemented using software, the software is stored on a computer-readable medium using removable storage drive 562, interface 570, or communication interface 574, and loaded onto the computer system at 550. In such an embodiment, the software is loaded into the computer system 550 in the form of telecommunications signal 578. When the software is executed by the processor 552, it preferably causes the processor 552 to perform the features and functions of the invention described above.

The various embodiments are also implemented primarily in hardware that uses components such as, for example, application-specific integrated circuits (ASIC) or field programmable gate arrays (FPGA). Implementations of hardware state machines capable of performing the functions described herein are also apparent to those of skill in the art. Further, various embodiments may be realized using a combination of both hardware and software.

The particular systems and methods detailed and described herein can fully achieve the aforementioned objects of the invention, and the descriptions and drawings provided herein are the present. It should be understood that it represents a subject widely considered by the invention. It can be further understood that the scope of the invention fully includes other embodiments that may be apparent to those skilled in the art, and thus the scope of the invention is not limited by anything other than the appended claims.

<figref num="1">FIG. 1 is a schematic block diagram of the entire maintenance system for wireless device software.</figref><figref num="2">Figure 2 is a schematic block diagram of a software maintenance system that highlights an instruction set installation via an airlink interface.</figref><figref num="3">FIG. 3 is a schematic block diagram showing a system of the present invention for executing dynamic instructions in a wireless communication device.</figref><figref num="4">FIG. 4 is a schematic block diagram of the wireless device memory.</figref><figref num="5">FIG. 5 is a table representing the code section address table of FIG.</figref><figref num="6">FIG. 6 details one of the symbol libraries of FIG. 3 having symbols.</figref><figref num="7">FIG. 7 is a table representing the symbol offset address table of FIG.</figref><figref num="8">FIG. 8 is a diagram of the operation code (opcode) accessed by the runtime engine.</figref><figref num="9">FIG. 9 is a more detailed view of the first operation code of FIG.</figref><figref num="10">FIG. 10 is a flowchart showing the method of the present invention for executing a dynamic instruction set on a wireless communication device.</figref><figref num="11">FIG. 11 is a flowchart showing an exemplary dynamic instruction set operation.</figref><figref num="12">FIG. 12 is a flowchart showing another exemplary dynamic instruction set operation.</figref><figref num="13">FIG. 13 is a flowchart showing a third exemplary dynamic instruction set operation.</figref><figref num="14">FIG. 14 is a flowchart showing a fourth exemplary dynamic instruction set operation.</figref><figref num="15">FIG. 15 is a flowchart showing a fifth exemplary dynamic instruction set operation.</figref><figref num="16">FIG. 16 is a diagram of a high-level network showing an exemplary wireless communication network.</figref><figref num="17A">FIG. 17A is a block diagram showing an exemplary wireless communication device.</figref><figref num="17B">FIG. 17B is a block diagram showing the instruction code section of an exemplary remote runtime.</figref><figref num="18A">FIG. 18A is a block diagram showing an exemplary PMRTI server.</figref><figref num="18B">FIG. 18B is a block diagram showing an exemplary server runtime instruction code section.</figref><figref num="19">FIG. 19 is a flow chart illustrating an exemplary process for executing a dynamic instruction set on a wireless communication device.</figref><figref num="20">FIG. 20 is a flow chart illustrating an exemplary process for compiling a dynamic instruction set on a wireless communication device.</figref><figref num="21">FIG. 21 is a flow chart illustrating an exemplary process for executing a dynamic instruction set on a PMRTI server.</figref><figref num="22">FIG. 22 is a flow chart illustrating an exemplary process by which a carrier authorizes handset reprogramming.</figref><figref num="23">FIG. 23 is a flow chart showing an exemplary public / private key process in which a carrier authorizes reprogramming of a handset.</figref><figref num="24">FIG. 24 is a flow chart illustrating an exemplary process of generating an unauthorized reprogramming window on a handset.</figref><figref num="25">FIG. 25 is a flow chart showing an exemplary PMRTI process in which a carrier authorizes handset reprogramming.</figref><figref num="26">FIG. 26 is a block diagram showing an exemplary computer system that may be used in the context of the various embodiments described herein.</figref>