Mobile Communication Device Dynamic Service Application and Dynamic Service Application Scripting

Information

  • Patent Application
  • 20100197327
  • Publication Number
    20100197327
  • Date Filed
    April 12, 2010
    14 years ago
  • Date Published
    August 05, 2010
    14 years ago
Abstract
A dynamic service application is stored and executed on a mobile or wireless communication device (e.g., a cellular telephone) to enable it to be programmed without specialized hardware, software, and other proprietary information. For example, dynamic service application programs or scripts may be entered directly by a user or may be received as a wireless or radiated digital message transmission. The dynamic service application executes the dynamic service application script, which is of a format to accommodate wireless or radiated transmission and storage on the device. The dynamic service application script may be written by a user on a computer or a mobile communication device or may be written with the aid of scripting “wizard” software. In addition to being received as radiated transmissions, dynamic service application scripts may also be sent as radiated transmissions from mobile communication devices to other devices or computers.
Description
BACKGROUND

Continued advancements in computing technologies have transformed the mobile telephone into a powerful telecommunication and entertainment device that has revolutionized the manner in which personal and business related tasks are performed each day. A few examples of tasks that may be performed using the mobile phone include communication (voice, electronic mail, texting, etc), navigation, shopping, and searching the World Wide Web.


Although the mobile phone has revolutionized the manner in which personal and business related tasks are performed, it is often difficulty and cumbersome to generate and/or executing computer programs (“scripts”) via the mobile phone.


SUMMARY

The present disclosure relates to mobile or wireless communication devices, including digital cellular telephones, and in particular to a short text message dynamic service application for such devices.


Programming small mobile or wireless communication devices, like digital cellular telephones phones, typically requires specialized hardware or software, or access to proprietary information like authentication keys, codes, etc. As a consequence, it is typically difficult or impossible for end-users to program such mobile devices. As is known in the art, digital cellular telephones of the Global System for Mobile Communications (GSM) type include removable Subscriber Identity Modules (SIMs), which are sometimes called smart cards or chip cards. To program a GSM cellular telephone, for example, it is necessary to use a smart card programming device and a smart card programming toolkit, and to access the account authentication key, the last of which is typically not accessible except by wireless service providers. The inability of users to program or modify mobile or wireless communication devices limits the versatility and usefulness of such devices.


Accordingly, the present disclosure includes a dynamic service application that is stored and executed on a mobile or wireless communication device to enable it to be programmed without specialized hardware, software, and other proprietary information. For example, the dynamic service application may be distributed with or stored on the wireless device in a conventional manner, but dynamic service application programs or scripts may be entered directly by a user or may be received as a wireless or radiated digital message transmission. In contrast, conventional programming of such a device requires a direct or conductive hardware coupling to the device.


The dynamic service application executes the dynamic service application script, which is of a format that accommodates wireless or radiated transmission and storage on the device. The dynamic service application script may be written directly by a user on a computer or a mobile communication device or may be written with the aid of scripting “wizard” software that runs on a computer and guides the writing of script without the user having to work directly with the dynamic service application script. In addition to being received as radiated transmissions, dynamic service application scripts may also be sent as radiated transmissions from mobile communication devices to other devices or computers.


In one exemplary implementation, a dynamic service application of the present disclosure may be stored on a SIM or smart card for use in an associated GSM cellular telephone. Dynamic service application scripts may be received at and sent from the GSM cellular telephone as short text message dynamic service scripts that conform to the short message service (SMS) format for GSM cellular telephones. In communicating with a conventional (e.g., desktop) computer, the scripts may be prepared and sent or received and run by software operating locally on the computer or at a site on the global computer network (e.g., a Web site).


The dynamic service application interprets and executes short text message dynamic service scripts that the cellular telephone receives, whenever the scripts are supported by a service present on the cellular telephone. The contents of the short text message dynamic service script could be either a new application, a part of the application (e.g., applications could be broken into segments), an application update, a command to execute, or data for a particular application. The user can also send messages from the phone to the web site. These messages can be distributed to other users as needed.


Additional objects and advantages of the present disclosure will be apparent from the detailed description of the preferred embodiment thereof, which proceeds with reference to the accompanying drawings.





BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.



FIG. 1 illustrates a Global System for Mobile Communications (GSM) cellular telephone as an exemplary mobile wireless communication device operating environment for an embodiment of the present disclosure.



FIG. 2 is a block diagram illustrating operation of a short message service (SMS) system compatible with transmission of short text message dynamic service scripts of the present disclosure.



FIG. 3 is a flow diagram of a mobile device dynamic service method according to the present disclosure.





DETAILED DESCRIPTION

The present disclosure relates to mobile or “wireless” communication devices capable of transmitting and/or receiving radiated (i.e., wireless) fixed length text messages of up to a maximum fixed length. Such communication devices may be implemented with various functions and in numerous forms including digital cellular telephones, portable and handheld computers, personal digital assistants, etc. The disclosure is described in reference to a digital cellular telephone, but is similarly applicable to other mobile or wireless communication devices that transmit and/or receive radiated fixed length text messages.



FIG. 1 illustrates a Global System for Mobile Communications (GSM) cellular telephone 10 as an exemplary mobile wireless communication device operating environment for an embodiment of the present disclosure. GSM cellular telephone 10 may conform, for example, to the European Telecommunications Standards Institute (ETSI) specifications GSM 11.11 and GSM 11.14 for Global Systems for Mobile communications. It will be appreciated, however, that GSM cellular telephone 10 could instead conform to another communication standard or a standard not yet developed, such as the ETSI 3rd Generation Mobile System standard that is sometimes referred to as the Third Generation Partnership Project or “3GPP”.


GSM cellular telephone 10 includes a removable Subscriber Identity Module (SIM) 12, which is sometimes called a smart card or chip card. For example, SIM 12 can be of a smart card format that has the well-known size of credit cards (e.g., standardized dimensions of 53.98 mm×85.60 mm×0.76 mm), or can be of a smaller format that is sometimes called a “plug-in SIM”. SIM 12 includes a medium 14 that supports a SIM electronic circuit 16 (e.g., one or more semiconductor integrated circuits or chips). Medium 14 typically includes multiple laminated synthetic layers, with one or more internal layers being between outer layers. SIM electronic circuit 16 is incorporated into or on at least one of the internal layers.


SIM electronic circuit 16 includes a central processing unit or CPU 20 (e.g., a microprocessor or microcontroller) in conjunction with a memory system 22, a data transmit interface 24, and a data receive interface 26, all of which are interconnected by a bus structure 28. Similarly, GSM cellular telephone 10 includes a central processing unit or CPU 30 (e.g., a microprocessor or microcontroller) in conjunction with a memory system 32, a data transmit interface 34, and a data receive interface 36, all of which are interconnected by a bus structure 38. In addition, GSM cellular telephone 10 includes a system display 40 and a user input device or keypad 42, as well as a power supply (e.g., a battery), telephonic audio input and output elements, and radio frequency transmitting and receiving elements that are not shown.


While SIM electronic circuit 16 includes the basic elements of a simple computer, neither SIM 12 nor SIM electronic circuit 16 is capable of functioning as a stand-alone computer. Both the SIM 12 and the SIM electronic circuit 16 lack a power source and user interface components by which a user could interact with SIM 12 or SIM electronic circuit 16. The computer functionality of SIM 12 can be accessed only by connecting it to another computer, such as GSM cellular telephone 10 or a SIM reader that is connected to a personal computer, as is known in the art. When connected to another computer, such as GSM cellular telephone 10, SIM 12 is powered and communicates through its interfaces 24 and 26 to receive data from and provide data to the other computer.


As is common, GSM cellular telephone 10 supports a fixed length text message service by which radiated (i.e., wireless) fixed length text messages of up to a maximum fixed length may be transmitted or received by GSM cellular telephone 10. As an example, the fixed length text message service could include or conform to the short message service (SMS) standard that is part of the GSM Phase 1 standard. The SMS standard allows transmission of radiated fixed length text messages of up to 160 characters in length. Such a fixed length text message service may be distinguished from conventional network connections or services in which files of generally arbitrary size may be transmitted. While referring to transmission of SMS messages, the following description may be similarly applicable to other standards or formats for radiated fixed length text messages.



FIG. 2 is a block diagram illustrating operation of a SMS system 50 for transmitting SMS messages from any of transmitting short message terminals 54 to a receiving short message terminal 56, which may be implemented as GSM cellular telephone 10.


For purposes of simplicity, this illustration is directed to communication in only direction: from transmitting short message terminal 54 to receiving short message terminal 56. It will be appreciated that each of short message terminals 54 and 56 would typically be capable of bi-directional communication so that the following description would be similarly applicable to communication from terminal 56 to any or all of terminals 54.


Transmitting short message terminal 54 may be any text-capable digital device, including a computer (e.g., desktop, portable, handheld, server, etc.), a personal digital assistant, a digital telephone, a digital cellular telephone, etc. An SMS message created at transmitting short message terminal 54 is transmitted over a communication channel 58 to a short message service center or message center 60 that functions as a store and forward center for transmitting SMS messages between short message terminals. For example, message center 60 receives a SMS message from transmitting short message terminal 54 and stores the SMS message until it can be forwarded to receiving short message terminal 56. Message center 60 then transmits the SMS message to receiving short message terminal 56 over a communication channel 62.


In view of the variety of devices that can function as message terminals 54 and 56, communication channels 58 and 62 may be or include any public or private computer network (e.g., the global computer network called the Internet) or any telephone network (e.g., any PSTN or any cellular or other wireless communication network). With receiving short message terminal being GSM cellular telephone 10 in the illustrated example, communication channel 62 will include at least a GSM cellular telephone network.



FIG. 3 is a flow diagram of a mobile device dynamic service method 100 according to the present disclosure. In one implementation, mobile device dynamic service method 100 is performed by various elements of SMS message system 50, including a dynamic service application stored on SIM 12. It will be appreciated that in other implementations, the dynamic service application may be stored or executed on any part of a short message terminal 54 or 56.


Process block 102 indicates that a short text message dynamic service script is formed. In one implementation, the short text message dynamic service script may conform to the SMS message format associated with GSM cellular telephones.


Process block 104 indicates that the short text message dynamic service script is transmitted to a receiving short message terminal. For example, the short text message dynamic service script could be transmitted via a message center 60 to GSM cellular telephone 10.


Process block 106 indicates that the short text message dynamic service script is interpreted and executed by the dynamic service application. Interpretation of the short text message dynamic service script by the dynamic service application includes correlating operations indicated by the short text message dynamic service script with the corresponding application programming interfaces (APIs) and any other resources available from SIM 12. For example, one option is to save the script and add the application name to the cellular telephone.


Process block 108 indicates that the short text message dynamic service script is received and stored, such as on a SIM 12 of a GSM cellular telephone 10.


Process block 110 indicates that the short text message dynamic service script is executed, such as on a SIM 12 of a GSM cellular telephone 10.


The short text message dynamic service scripts functions as short text message applications and can be formed in a variety of ways. As one example, a user could write a short text message application directly in accordance with a scripting notation, as described below in greater detail. As another example, a user may be guided through a script formation process or “wizard” that is accessed from a personal computer. The script formation process or “wizard” may be run locally on the personal computer or may be accessed from a network site (e.g., a Web page) on the global computer network.


Set forth below are exemplary steps through which scripting wizard software could direct a user creating a short text message dynamic service script or application. The exemplary steps could be offered or presented to the user in different sequences according to choices or selections made by the user. Once each branch or segment of the application is completed, the scripting wizard software codes and encrypts the application so that it can be sent to the receiving mobile communication device (e.g., GSM cellular telephone 10) as one or more short text messages (e.g., SMS messages). Once it receives the one or more short text messages, the dynamic service application on the mobile communication device interprets it or them and executes the steps as specified in the script. As an example, one option is to save the script and add the application name to the mobile communication device (e.g., cellular telephone).


User selects application options:

    • 1. Specify application name and various application properties
      • A. Name
      • B. Description
      • C. Access (Publish/don't publish in directory service)
      • D. Membership (Members only/open to public)
      • E. Author information
    • 2. Execute on the cell phone only once
      • A. Manually (application is added to the phone app menu and deleted after execution)
      • B. Upon receipt of SMS message
      • C. With a delay after receiving SMS message
      • D. At a specified time, date
      • E. Triggered with events
    • 3. Execute on the cell phone more than once
      • A. Manually (application is added to the phone app menu)
      • B. With specified interval
      • C. At specified time(s), date(s)
      • D. Triggered with events


User selects initial interaction type between the application and the cell phone user after the application is launched.


Examples of operations:

    • 1. Show selection list (user is required to select item(s) from a list)
      • A. Enter text describing the list
      • B. Enter items of the list
      • C. Specify operation(s) to execute upon selection of an item (each item may be associated with a different operation that follows)
    • 2. Show “edit box” (user is required to enter text)
      • A. Enter text describing the edit box (description of the text to be entered).
      • B. (Optional) Enter a text string that triggers a specific operation and specify this operation.
      • C. (Optional) Additional specification(s) as in B.
      • D. (Optional) Specify operation(s) to execute after any other non-empty text is entered.
    • 3. Print text
      • A. Specify text to be printed
      • B. Specify delay time before continuing, or manual continuation
      • C. Specify conditions under which this operation (print text) will or will not execute (time, location, . . . ). Execution continues with the following operation (C)
      • D. (Optional) Specify operation to execute after text is printed.
    • 4. Play tone
      • A. Specify tone parameters (type of tone, length, etc)
    • 5. Send message/command to specified destination(s)
      • A. Specify message/command
      • B. (Optional) Specify operation to execute after message/command is successfully sent
      • C. (Optional) Specify operation to execute after sending message/command failed.
    • 6. File operation
      • A. Clear
      • B. Delete
      • C. Delete Item
      • D. Append


Selected aspects of a first implementation of a format of a short text message dynamic service script are described below with reference to an exemplary script. It will be appreciated that this exemplary script is provided merely to illustrate the various script elements and does not include all potential elements in the script format or the full range of potential functionality that can be provided by the script format.


In this implementation, a typical script includes a file or variable with multiple successive statements that each may include one or more script elements. The successive statements of a script may form one or more files that are each no larger than the basic memory buffer size for a receiving mobile or “wireless” communication device (e.g., 128 bytes for a SIM), thereby allowing a complete script file to be completely contained in the memory buffer. In the illustrated exemplary script of Table 1, different statements are initiated by the terms Start, Efopen, Cont1, Iter, Cont2, which may be referred to as the statement names.









TABLE 1





Exemplary Script

















Start:



!gEFopen



oF1“/Pgm/SV.m”



gCont1



EFopen:



T1=“Error opening file ”



T1<T0<“ (“<hIE<”)”



pT1



q



Cont1:



T2=“T1=s”



!gCont2



I1=0



Iter:



T2<“,”<h22<F1(I1, 11)<h22



I1+16



glter



Cont2:



T2<“q;”



!q



cF1



xT2



tT1



T2=“/Pgm/”



T2<T1



T2<“.a”



oF1T2



xF1



q










In this implementation, script elements are generally represented by only one or two alphanumeric characters to minimize the script size, and operators are indicated by lower case letters. For example, the Start statement begins with an error handling indicator “!” that is coupled with a get element “g” and a statement name “EFopen.” This script element combination is interpreted and executed by the dynamic service application as follows: if an error arises (!), get (g) the indicated statement (EFopen). The get element g may have as its argument any statement name in a file, a file name, a memory location pointer, etc. Accordingly, the get element g functions as a versatile program control device for directing script execution toward a variety of elements.


The EFopen statement sets a text variable (T1) to a text string “Error opening file,” and the element T1<T0<“(“<hIE<”)” functions to append a text variable T0 and the text “(32)” (where the value of 32 is an example value of the file handle, hIE) to text variable T1, with the text variable TO being a temporary buffer having the value of _ the file name (last statement's text). Element pT1 functions to print (p) (i.e., display) the error indication specified for variable T1 (i.e., text string “Error opening file”), and the quit element (q) ends execution of the script.


In the absence of an error indication by the executing mobile device, the Start statement proceeds to the script element oF1“/Pgm/SV.m”, which opens (o) as a file variable (F1) the file SV.m stored on the device in subdirectory Pgm. The .m extension may indicate that the file SV.m is a listing or menu of available script or application files available in the Pgm subdirectory. The script element gCont1 then gets (g) statement Cont1. The file variable (F1) represents a file-type variable that can be indexed over a range of values to support file operations (e.g., open, o). This script format implementation also includes, for example, an indexed text variable (e.g., T1) and an indexed numeric or numeric variable (e.g., I1) to support text and integer operations, respectively.


In the Cont1 statement, script element T2=“T1=s” sets a text variable index T2 to the indicated text string (T1=s). Script element !gCont2 directs the script to get or goto (g) statement Cont2 in case of an error indication. Script element I1=0 sets a value of zero to the integer variable I1.


In the absence of an error indication in it, statement Cont1 proceeds to statement Iter, which functions as an iteration operation. Script element T2<“,”<h22<F1(I1, 11)<h22 appends to text variable T2 a comma, a quote (by operation of element h22), 11 characters at iteration variable location I1 in file F1, and another quote (by operation of element h22). Element I1+16 is an integer operation adding variable I1 and the number 16. Element gIter repeats operation of statement Iter for another iteration. For example, each address location in a file could include 16 character positions, so this script element would function to obtain the first 11 characters at each address location in file F1.


In the Cont2 statement, element T2<“q;” appends a quit operator to text variable T2. As a result, of the operation of statements Iter and Cont2, variable T2 includes the following elements:

    • T2: T1=s, F1(0,11), F1(1,11), . . . , q;


in which the elements F1(0,11), F1(1,11), . . . include the 11 character text strings at locations 0, 1, . . . in file F1. The 11-character iteration may reflect that the mobile communication device displays 11 characters per line. Script element cF1 closes (c) file F1, and script element xT2 executes (x) variable T2, in which the select element s functions to display each text string F1(1,11) so a user can select one of them. Script element tT1 trims spaces at the beginning and at the end of the text. The script elements T2=“/Pgm/”, T2<T1, and T2<“.a” set variable T2 to the subdirectory and application name and extension (.a) of the application selected by the user. Script element oF1T2 opens as file F1 the specified file, and element xF1 executes it.


The exemplary script functions to display a list of text message applications available on a mobile communication device and to allow a user to select and execute one of the applications. It will be appreciated that such an application would typically require significantly greater memory and syntax resources if it were written in a conventional scripting language.


Selected aspects of a second implementation of a short text message dynamic service script format are described below. This second implementation includes more programming specificity than the first, but disadvantageously increases the memory requirements of the dynamic service application.


Message consists of two components:














<MSGHEADER><COMMANDS>


  <MSGHEADER>: <MSGID><MSGOPTS>/<APPNAME>


    <MSGID> - Message ID for this recipient (cell phone, web


  site), sequence 0,1,2,3,... (only decimal digits)


    <MSGOPTS> - Message options


      A - ACK of the message with MSGID following (eg.


    A123)


      R - ACK of this message requested


      I - Install as application. <COMMANDS> are stored


    in a file, added to apps menu, and executed by the user.


    Otherwise <COMMANDS> are executed upon receipt of


    the message.


      C<Item>-<Of> - Not complete message. This is item


    <Item> of <Of> items. The contents of this message are


    appended to already loaded chunks.


    <APPNAME> - Name of the application represented by


  the message contents









Example
98I/Nearby














    <COMMANDS>  consists   of   a   set   of


<CMD><CMDOPT>/<CMDBODY> separated with ‘&’


      <CMD> - Command:


        S - Select item from the list of items in the


    <CMDBODY> separated with ‘/’


        The text before the first ‘/’ after <CMDOPT>


    is the description of the items to select. If it is empty


    (<CMD><CMDOPT>//...) then the text “Select:” is printed.


        <CMDOPT> (all optional):


          A - append to clipboard


          T - the result is text of the selected


      item instead of index (1,2,...)


          E<CMDID> -  error  handler  -


      command to execute next on error.


            <CMDID> specifies  which


        command to execute (1,2,...)


        Result: Selected item. Result is appended to


    the clipboard


        Notes: All items are separated with ‘/’ and


    optionally, following the separator is a number that


    specifies a command ID of a command to execute if this


    item is selected.


        The first item is the title of the selection


    with optional preceding default command ID.









Examples














          S/Where?/My   Office/Room


      123/Park


          SML1E13A/15Where?/12My


      Office/14Room 123/15Park


    E - Enter value (text) for the text described in the


body.


    <CMDOPT>/<CMDID><Text>[/<CMDID><Text>/<CMDID>


<Text>...]


    <CMDOPT> (all optional):


      L - Allow letters and digits


      A - Append to clipboard


      T - append to text the clipboard, save


  clipboard


      C - Set clipboard (default)


      D - Allow to enter decimal digits only


      N - specifies minimum size of input


  (followed by size)


      X - specifies maximum size of input


  (followed by size)


      E<CMDID> - error handler - command to


  execute next on error.


        <CMDID> specifies which command


    to execute (1,2,...)


    Result: Entered item text. Result is added to the


clipboard depending on the options specified.


    Notes:


      The body of the command may consist of a


  list of items separated with ‘/’ with preceding command


  ID of a command to execute if this item is entered.


      The first item is the title of the edit box with


  optional preceding default command ID (command to be


  executed next).









Examples

















      E/Enter your name



      EX8N3E13A/31Enter       your



  name:/01Cezary/02Harry/03Lili/04 007



    P - Print text <CMDOPT>/<CMDID><Text>



      <CMDOPT>:



        T - Append to the text content of the



    clipboard and print the result



        C - Append the specified text to the



    clipboard and print the result



        E<CMDID> -  error  handler  -



    command to execute next on error.



        <CMDID> specifies which command



    to execute (1,2,...)



    Result: Printed text. Result is appended to the



clipboard if T nor C specified. If option T is specified the



clipboard contains the printed text.










Examples

















        P/Hello World!



        PTE13/Hello World!



    F - File operation



      <CMDOPT> (One of C, A, O, D required):



        C - Append the content of the specified file



    to the clipboard



        A - Append the text of the clipboard to the



    specified file



        O - Overwrite the content of the file with



    the content of clipboard



        D - Delete specified file



        B - Treat file as binary



        E<CMDID> - error handler - command to



    execute next on error.



          <CMDID> specifies which command



      to execute (1,2,...)










Examples

















      FC/“/Pgm/Test.data”



      FBOE13/“/7F20/6F74”



    C - Clipboard operation - set the content to the specified



text



      <CMDOPT>/<ContCommandID><Text>



        T - Append to the text content of the



    clipboard and store the result



        C - Clear the contents



        A - Append the specified text (instead of



    setting the value)



        E<CMDID> - error handler - command to



    execute next on error.



          <CMDID> specifies which command



      to execute (1,2,...)










Examples

















C/Hello World!



CAE13/Hello World!










Examples

















      &P/Hello World!!!



      &C/Hello... &PC/from clipboard!!!



      &C/ hello!!!&PT/From clipboard



      &C/Hello &EA/Enter your name:&PC/, good to see



you!










In accordance with the practices of persons skilled in the art of computer programming, the present disclosure is described above with reference to acts and symbolic representations of operations that are performed by various computer systems, including mobile communication devices and “smart cards.” Such acts and operations are sometimes referred to as being computer-executed and may be associated with the operating system or the application program as appropriate. It will be appreciated that the acts and symbolically represented operations include the manipulation by a CPU of electrical signals representing data bits, which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the computer system operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, or optical properties corresponding to the data bits.


Having described and illustrated the principles of our disclosure with reference to an illustrated embodiment, it will be recognized that the illustrated embodiment can be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computer apparatus, unless indicated otherwise. Various types of general purpose or specialized computer apparatus may be used with or perform operations in accordance with the teachings described herein. Elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa.


In view of the many possible embodiments to which the principles of our disclosure may be applied, it should be recognized that the detailed embodiments are illustrative only and should not be taken as limiting the scope of our disclosure. Rather, we claim as our disclosure all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.


CONCLUSION

Although the techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing such techniques.

Claims
  • 1. A method comprising: receiving, by a mobile digital communication device, a short text message embodied on a radiated data signal, the short text message configured as a dynamic service script program having a data structure;extracting, by the mobile digital communication device, the dynamic service script program having the data structure from the short text message, the data structure including at least one statement, the statement comprising: a first data field containing no more than two characters indicating a command, anda second data field containing data indicating an operand on which the command is to be executed, the first and second data fields appended together to form the statement being void of any spaces; andexecuting, by a dynamic service application within the mobile digital communication device, the dynamic service script program to facilitate programming of the mobile digital communication device.
  • 2. The method of claim 1, wherein the data structure further comprises a third data field having a length of a single character containing an error handling indicator which allows execution of the first data field if an error is indicated.
  • 3. The method of claim 2, wherein the third data field includes an exclamation point character.
  • 4. The method of claim 1, wherein the command indicated in the first data field is at least one of get, open, print, quit, close, trim, and execute command.
  • 5. The method of claim 1, wherein the short text message is compatible with a Short Message Service (SMS) format.
  • 6. The method of claim 1, wherein a size of the dynamic service script program is less than or equal to 128 bytes.
  • 7. The method of claim 1, wherein a last character of the first data field is a lowercase character and a first character of the second data field is an uppercase character.
  • 8. A computer readable medium having computer executable instructions for performing acts for forming applications for a mobile digital communications device, the acts comprising: providing a user input interface to: specify an application property;specify a manner of execution;specify an initial interaction between the application and the mobile digital communications device;specify a message or command to be sent to a specified destination; andconvert the application property, manner of execution, initial interaction, and message or command into a script file having a data length no larger than a short text message, the data file have a plurality of command lines, at least one command line having a first data field and a second data field, the first data field containing a command and the second data field containing data indicating a statement name on which the command is to be executed, the script file comprising a dynamic service script program for execution by a dynamic service application within a mobile digital communication device.
  • 9. The computer readable medium of claim 8, wherein the dynamic service application executes variables, operators, program control elements, error indicators, and information of the dynamic service script program to facilitate programming of the mobile digital communication device.
  • 10. The computer readable medium of claim 8, wherein the user input interface specifies the manner of execution as at least one of: manual,upon receipt of a message,at a delay time after receiving a message,at a specified date and time,with a specified interval time, orupon occurrence of a user selected event.
  • 11. The computer readable medium of claim 8, wherein the script file is compatible with a short message service (SMS) format.
  • 12. The computer readable medium of claim 8, wherein the first data field contains a single lowercase character indicating a command and the second data field begins with an uppercase character.
  • 13. The computer readable medium of claim 8, wherein the first and second data fields are appended together to form the at least one command line such that the at least one command line is void of spaces.
  • 14. A mobile digital communication device that receives radiant transmission of short text messages comprising: a dynamic service application that receives a radiantly transmitted short text message dynamic service script and interprets and executes the short text message dynamic service script on the mobile digital communication device to facilitate programming of the mobile digital communication device, the short text message dynamic service script comprising a statement including a first data field indicating a command, and a second data field indicating an operand on which the command is to be executed; anda subscriber identity module that is distinct from a base portion of the mobile digital communication device and that stores at least one executable operation indicated in the short text message dynamic service script.
  • 15. The device of claim 14, wherein the first and second data fields appended together to form the statement such that the statement is void of spaces.
  • 16. The device of claim 14, wherein the dynamic service application is stored on the subscriber identity module.
  • 17. The device of claim 14, wherein the short text message dynamic service script is stored on the mobile digital communication device for repeated execution.
  • 18. The device of claim 14, wherein execution of the short text message dynamic service script on the mobile digital communication device includes obtaining information from an operator of the mobile digital communication device.
  • 19. The device of claim 14, wherein the statement further includes a third data field having a length of a single character containing an error handling indicator which allows execution of the first data field if an error is indicated.
  • 20. The device of claim 14, wherein the third data field includes an exclamation point character.
CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patent application Ser. No. 11/013,161, filed Dec. 14, 2004, which claims the benefit of priority to U.S. Pat. No. 7,418,254, issued on Aug. 26, 2008, which is herein incorporated by reference in its entirety.

Divisions (1)
Number Date Country
Parent 09789432 Feb 2001 US
Child 11013161 US
Continuations (1)
Number Date Country
Parent 11013161 Dec 2004 US
Child 12758146 US