KR100856478B1 - A method for configuring an electronic device, an electronic device, a computer readable medium storing a data structure, a server, and a computer readable medium - Google Patents

Abstract

Receiving a command to identify first data at the electronic device; Automatically determining an attribute of the identified first data; Automatically identifying an executable file from the determined attribute; And operating on the identified first data using the identified executable file.

Description

A method for configuring an electronic device, an electronic device, a computer readable, a computer readable medium storing a electronic device, a data structure, a server, and a computer readable medium. medium storing a data structure, a server, and a computer readable medium}

Embodiments of the invention relate to configuring an electronic device. Certain embodiments relate to a standard process for configuring mobile cellular phones, for example in point of sale management.

The current trend for electronic devices is to have more features. This can make electronic devices difficult to configure.

The user of the device may spend a significant amount of time and effort configuring the device's settings to operate the device exactly and / or as they wish. The new device may be considered less attractive to the user because the time and effort required can be very large.

This is especially true for mobile cellular phones. Mobile phones are typically designed such that they can be configured for use in any one of a plurality of different cellular wireless telephone networks controlled by different operators. However, each operator may need different settings in order to be able to operate the telephone exactly or in a manner desired by the operator. The operator (service provider) may wish to personalize the mobile phone with the necessary settings. Moreover, the mobile phone is a personal device and the user may want to configure it with their favorite ring tones, Internet bookmarks, screensavers and the like.

Therefore, it would be desirable to provide some form of automatic setup process to electronic devices and especially mobile cellular phones.

It would be desirable for the setup process to be able to be used with more than one electronic device without specific adaptation to the device. For example, it would be desirable if the setup process could be used to initially configure all or most mobile cellular phones.

The inventors considered whether automatic configuration would be possible using a SyncML message to send data to the target device and execute executables on the transmitted data on the target device.

SyncML ^™ Device Management (DM) is an open, general purpose industry standard. It provides third parties, such as service providers and enterprise information management departments, the ability to create and manage management trees stored on mobile devices. The SyncML Device Management Tree and Description, v1.1.1 ( www.syncml.org ), dated February 10, 2003, describes the creation and maintenance of management trees. The management tree has nodes connected by branches. Each node can be uniquely addressed by a URI. A node can be any internal node that can have any number of child (slave) nodes but can't store any value, or a node can be a leaf node that can't have child (slave) nodes but can store a value have. The value can be a string, file, number, or the like. SyncML DM therefore provides a mechanism for providing data on-the-fly to the mobile device.

The SyncML Representation Protocol, v1.1 ( www.syncml.org ), February 15, 2002, is a common extensible markup language (XML: Extensible) available by all SyncML protocols, including the Data Management (DM) protocol. Markup Language) stores syntax and semantics. The commands include Add, Copy, Delete, Exec, Get, Replace. Exec allows the originator of the command to request that the named executable be called by the recipient.

The SyncML Device Management Tree and Description, v1.1.1 ( www.syncml.org ), February 10, 2003, describes how Add is used to create a management tree. SyncML DM does not specify how instructions executable using SyncML DM can be executed for specific data. The exec command includes an item element, including a target element, including a LocURI element. The LocURI element specifies only the location of the executable file on the device. Thus the exec command does not allow the data to be used by the executable file to be specified.

Moreover, the exec command requires the identification of a suitable executable file on the target device. Therefore, there must be prior knowledge of the identification information of the executable file on the target device, specified in the LocURI element of the exec command. This is complicated and inconvenient and prevents a single SyncML message or package from being used with multiple mobile devices.

It would be desirable to generate SyncML code suitable for performing a common process on a plurality of target devices that do not require specific adaptation for use with each device.

It would be desirable to use SyncML code that can be reused for other devices to instruct an executable to be performed on specific data.

According to an embodiment of the present invention, there is provided an electronic device comprising: receiving a command for identifying first data at an electronic device; Automatically determining an attribute of the identified first data; Automatically identifying an executable file from the determined attribute; And operating on the identified first data using the identified executable file.

According to another embodiment of the present invention, there is provided a method of transmitting a code including a command to a mobile cellular telephone, the command comprising: identifying a first leaf node of a hierarchical node type data structure; Determining an attribute of the identified first leaf node; Identifying an executable file from the determined attribute; And operating on data stored in the identified first leaf node using the identified executable file.

According to another embodiment of the present invention, there is provided a step of transmitting a reusable code to a mobile cellular telephone, the code having leaf nodes and internal nodes, including first data stored in a first leaf node. Instructions for generating a hierarchical node-like data structure in the electronic device and a first command for identifying the first leaf node; Determining an attribute of the identified first leaf node; Identifying an executable file from the determined attribute; And operating on the first data stored at the first leaf node using the identified executable file. A method for configuring a plurality of mobile cellular telephones is provided.

According to another embodiment of the invention, there is provided an apparatus, comprising: means for storing first data; Means for receiving a command to identify the first data; Means for determining an attribute of the identified first data; Means for identifying an executable file from the determined attribute; And means for operating on the identified first data using the identified executable file.

According to another embodiment of the present invention, a data structure is provided for reuse in setting up different mobile cellular telephones, comprising code identifying the first data and specifying execution of an unidentified executable on the first data. .

According to another embodiment of the present invention, there is provided an electronic device comprising: instructions for generating, at an electronic device, a hierarchical node type data structure having leaf nodes and internal nodes, the first data being stored at a first leaf node; And a first instruction for identifying the first leaf node specifying execution of an unidentified executable file on the first data stored at the first node. .

Embodiments of the present invention allow an executable file residing on a target device to be executed without specifying identification information of the executable file. Since the identification information of the resident executable may vary from device to device, this allows SyncML code to be reused to perform a common process on multiple target devices.

Embodiments of the invention may allow executable files residing on the target device to be used for specified data.

According to another embodiment of the invention, reusing to set up different electronic devices comprising means for associating each of the plurality of user friendly instructions with different code portions, each comprising one or more instructions. A system is provided for creating a data structure.

Reference will now be made to the accompanying drawings as an example only for a better understanding of the invention.

1 illustrates a client-server system that includes a mobile device in communication with a server 20.

2 illustrates a management tree data structure.

3 is a signaling diagram for the download of a setup code.

4 schematically shows the content of the setup code 50.

1 shows a client-server system 2 comprising a mobile device 10 that communicates with a server 20 via a cellular wireless telephone network 18. The mobile device 10, in this embodiment a mobile cellular phone, comprises a processor 11, a cellular radio transceiver 12, a memory 13, an input device 14, for example a keypad, a display 15, a smart card. 16 and an audio output device 17.

The processor 11 controls the mobile phone 10. It is connected to write to and read from the memory 13. It receives input data from keypad 14 and provides output data to the display 15 and audio output device 17. It controls the cellular radio transceiver so that it can communicate in a cellular telephone network 18, which can be for example a GSM or WCDMA network. The processor is also coupled to a smart card 16 that provides at least user identification information to the processor, such as a user's telephone number or IMSI. The operation of the processor 11 is controlled by software stored in the memory 13 and loaded into the processor. In operation, the processor receives and transmits data through the transceiver 12, writes data to and reads data from the memory 13.

It should be understood that in other embodiments the mobile cellular phone may not have a smart card 16 or may have multiple processors.

The server 20 includes an input / output interface 21, a processor 22 and a memory 23 connected directly or indirectly to the cellular wireless network 18. The server 20 is a SyncML DM server. It issues SyncML DM commands to the mobile phone 10 via the input / output interface 21 and correctly interprets the responses from the mobile phone 10.

In the mobile phone 10, the processor 11 can operate as a management client (MC) and maintain the management tree data structure 100 in the memory 13. The MC correctly interprets the SyncML DM commands received from the server, executes the appropriate operations on the mobile phone 10 and sends relevant responses via the transceiver 12 to the issuing management server.

The management tree is a hierarchical node type data structure in which the management client interacts with the mobile phone 10. The MC may store or retrieve values from the tree and adjust the attributes of the tree. The management tree has nodes connected to the forks. Each node can be uniquely addressed by a URI. A node can be an internal node that can have any number of child (slave) nodes, but can't store any value, or a node can be a leaf node that can't have child (slave) nodes but can store a value. The value can be a string, file, number, or the like.

The management tree may be adjusted by the MC. New nodes can be created and values at some leaf nodes can be changed. There is simultaneous runtime access to the leaf nodes and internal nodes.

As described in more detail below, the MC creates an 'operator' management object as part of the automatic setup process in response to receiving a setup code from the server 20. As shown in FIG. 3, the 'operator' management object 102 is in this example a sub-tree subordinate to the root 104 of the management tree 100 and used during the setup process.

The automatic setup process can be initiated, for example, by inserting a smart card 16 into the cellular mobile phone 10. The smart card 16 contains the necessary information to bootstrap the autoconfiguration process. The mobile telephone 10 transmits a download start message 60 to the server 20 as shown in FIG.

The server 20 stores the setup code 50 in a memory 23, which can be used with multiple devices without adaptation. The server 20 initiates a SyncML data management (DM) session 62 in response to the download start message. The DM session 62 is used to send the stored setup code 50 to the mobile phone 10.

The download initiation message 60 may be sent by any suitable means, such as a Short Message Service (SMS) message, or if the device is a personal digital assistant without mobile phone capability, then IR, Bluetooth or It can be sent over a serial data connection such as USB.

The setup code 50 is shown schematically in FIG. 4. The setup code 50 is a data structure for reuse in setting up different mobile phones.

The setup code 50, in this example, comprises two parts that may be logically separated but interleaved. There is a first portion 52 for creating a management tree or updating an existing management tree. There is a second portion 54 for performing the executable files.

The first portion 52 for updating an existing management tree includes a sub-part for creating internal nodes of the management tree and a sub-part for creating leaf nodes of the management tree.

As an example, the code may use an XML code similar to the following to create an internal node 'operator' 106 that depends on the root 104:

<Add>

<CmdID> 1 </ CmdID>

<Item>

      <Meta>

            <Format xmlns = 'syncml: metinf'> node / <Format>

            <Type xmlns = 'syncml: metinf'> interior / <Type>

      </ Meta>

      <Target>

            <LocURI> / Operator </ LocURI>

      </ Target>

</ Item>

</ Add>

As an example, the code can subsequently create an internal node 108 that depends on the 'operator' node 106 using XML code similar to the following:

<Add>

<CmdID> 2 </ CmdID>

<Item>

      <Meta>

            <Format xmlns = 'syncml: metinf'> node / <Format>

            <Type xmlns = 'syncml: metinf'> interior / <Type>

      </ Meta>

      <Target>

            <LocURI> / Operator / ring_tones </ LocURI>

      </ Target>

</ Item>

</ Add>

As an example, the code can create a leaf node 110 that depends on the node 108 using XML code similar to the following:

<Add>

<CmdID> 3 </ CmdID>

<Item>

      <Meta>

            <Format xmlns = 'syncml: metinf'> format / <Format>

            <Type xmlns = 'syncml: metinf'> MIDI ringing tone / <Type>

      </ Meta>

      <Target>

            <LocURI> / Operator / ring_tones / smashhit # 1 </ LocURI>

      </ Target>

      <Data> the data </ Data>

</ Item>

</ Add>

In the above, the data is data for generating the smashhit # 1 ring tone in a format as defined by a format.

The second portion 54 for executing the executable files each includes a plurality of sub-parts for executing the executable files. The order of the sub-parts determines the order in which the executable files are performed. At least some of the sub-parts specify that the executable is performed using specific data. As an example, the code for this sub-part may be XML code similar to the following:

<Exec>

<CmdID> 3 </ CmdID>

<Item>

      <Source>

            <LocURI> / Operator / ring_tones / smashhit # 1 </ LocURI>

      </ Source>

</ Item>

</ Add>

The exec command specifies the execution of an executable file that is not identified on data contained in a 'source', that is, the smashhit # 1 ring tone. The Exec command does not specify which executable file should be used and the meaning of the command depends on the content type of the data it identifies.

The DM client of the mobile cellular telephone processes the received setup code 50. Portion 52 for updating an existing management tree is processed according to the SyncML DM specification. Thus, the DM client creates a sub-tree 102 that depends on the route as shown in FIG. 2, according to the given example.

The portion 54 for executing the executable file is processed as follows. The code is analyzed to identify the first sub-part. The first sub-part is analyzed to identify the URI specified by the element LocURI included in the element source. The element LocURI identifies a leaf node in the newly created sub-tree of the management tree.

The DM client accesses the identified leaf node, which is Operator / ring_tones / smashhit # 1 in the example given above. It reads the attributes of the identified leaf node and in particular those contained within the meta.

The DM client identifies the content type of the data stored in the identified leaf node using the content of the Format element and / or the content of the Type.

The DM client uses, for example, a lookup table to associate possible Formats and Types with different executable files residing on the mobile phone. Thus, the DM client can associate the leaf node identified with the leaf node's Format and / or Type with the executable file. In this way, if the leaf node stores a sound file it is associated with an audio player, if the leaf node stores a video file it is associated with a video player and if the leaf node stores a picture file it Associated with the viewer, if the leaf node is a Java middlelet, it is associated with a Java Virtual Machine (JVM); if the leaf node is a contact detail, it is associated with an executable that adds it to the phone's contact list. If the leaf node is a bookmark, it is associated with an executable file that adds the bookmark to the phone's bookmark list and the like.

SyncML DM uses a number of different commands, including:

Add: Allows the originator of the command to request that the data element or data elements contained by the command be added to data accessible by the recipient. For example, when sent from a server to a mobile terminal it may add nodes to the DM tree.

Copy: allows the originator of the command to request that the data element or data elements contained by the command accessible to the recipient be copied.

Delete: Allow the originator of the command to request that the data element or data elements included in the command, accessible to the recipient, be deleted. For example, when sent from a server to a mobile terminal it may remove the node from the DM tree.

Exec: Allows the originator of the command to request a named or supplied executable to be called by the recipient.

Get: allows the originator of the command to request a data element or elements from the receiver. For example, when sent from a mobile terminal to a server it can obtain the content of a node of the DM tree.

Replace: Allow the originator of the command to request that a data element or data elements accessible to the recipient be replaced.

SyncML DM also requires specific syntax to be used with each command. It would be desirable for each operator to be able to easily generate the appropriate setup code 50 without detailed knowledge of the SyncML DM instructions and their syntax. A computer program can be provided to the server 20 to do this. The computer program actually provides a macro that converts simple user friendly instructions into suitable SyncML DM instructions with the correct syntax.

The computer program may, for example, provide the operator with the following options:

a) Install X

b) X preview (with installation)

c) X preview (no installation)

d) Run X (installation implied)

The computer program, for example, converts the options to:

a) SyncML Add command

b) SyncML Add command followed by SyncML Exec command

c) SyncML Add command followed by SyncML exec command followed by SyncML Delete command

d) SyncML Exec Command

Although embodiments of the invention have been described in the previous paragraphs with reference to various examples, it should be understood that changes to the examples provided may be made without departing from the scope of the invention as claimed. Although described with reference to a mobile phone for example, it should be understood that the present invention can be applied to any user configurable electronic device. It may be particularly applicable in mobile devices such as mobile phones and personal digital assistants, but for example also in personal computers.

Although the effort in the foregoing specification to draw attention to the features of the present invention is considered particularly important, whether or not the applicant has particularly emphasized any of the above-referenced drawings and / or shown in the figures It is to be understood that claims are made with respect to patented features or combinations of the above features.

Claims (71)

delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete Receiving a command to identify first data at the electronic device; Automatically determining an attribute of the identified first data; Automatically identifying an executable from the determined attribute; And Operating on the identified first data using the identified executable file. 32. The method of claim 31, wherein the determined attribute of the identified data indicates a content type. 33. The method of claim 31 or 32, wherein the command comprises an identifier of the first data. 34. The method of claim 33, wherein the identifier identifies a node of a hierarchical node type data structure. 35. The method of claim 34, wherein the command is an exec command and the identifier is a URI contained within a source element included within the exec command. 33. The method of claim 31 or 32, wherein the command is received as an XML code. 37. The method of claim 36, wherein the command is a SyncML command. 33. The method of claim 31 or 32, wherein the identified first data is stored at the mobile device. 37. The method of claim 36, wherein the identified first data is stored as a first leaf node of a hierarchical node type data structure. 40. The method of claim 39 wherein each leaf node of the hierarchical node-like data structure has attributes and determining the content type uses attributes of the first leaf node. 41. The method of claim 39 or 40, wherein each leaf node of the hierarchical node-like data structure has metadata and determining the content type uses metadata of the first leaf node. Way. 33. The method of claim 31 or 32, wherein determining the content type uses a value of a Type element and / or a Format element associated with the first data. 33. The method of claim 31 or 32, further comprising associating a plurality of different executable files with each of the plurality of different attributes. 42. The method of claim 41 wherein automatically identifying an executable file from the determined attribute comprises identifying an executable file associated with the determined attribute. 44. The method of claim 43, wherein the plurality of different executable files are stored on the electronic device. 33. The method of claim 31 or 32, further comprising, prior to receiving a command to identify the first data, receiving instructions at the electronic device to create a hierarchical, node-like data structure comprising the first data. It further comprises a method. Transmitting a code containing the command to the electronic device, the command comprising: identifying a first leaf node of the hierarchical node type data structure; Determining an attribute of the identified first leaf node; Identifying an executable file from the determined attribute; And Operating on data stored in the identified first leaf node using the identified executable file. Receiving a re-usable code at an electronic device, wherein the code is: Instructions for creating, at the electronic device, a hierarchical, node-like data structure having leaf nodes and internal nodes, the first command identifying the first leaf node, the first leaf node comprising first data stored at the first leaf node Comprising; Determining an attribute of the identified first leaf node; Identifying an executable file from the determined attribute; And Operating on the first data stored at the first leaf node using the identified executable file. A memory for storing first data; A receiver for receiving a command identifying the first data; And And a processor operable to determine an attribute of the identified first data, identify an executable file from the determined attribute, and operate on the identified data using the identified executable file. . The method of claim 49, The receiver is for receiving a setup code and the processor is configured to generate a hierarchical node type data structure having leaf nodes and internal nodes, including a first leaf node storing the first data. And operable to interpret the received setup code. 51. The electronic device of claim 50, wherein the processor is operable to interpret a first command in the received configuration code to determine an attribute of the leaf node identified by the first command. A computer readable medium having stored thereon a data structure comprising code identifying first data and specifying execution of an executable file not identified on the first data. 53. The computer readable medium of claim 52, wherein the code further specifies transmission of the first data to an electronic device. Instructions for creating, at the electronic device, a hierarchical node-like data structure having leaf nodes and internal nodes, the first data stored at the first leaf node; And And store a data structure comprising a first instruction for identifying the first leaf node specifying execution of an unidentified executable file on the first data stored at the first leaf node. 55. A method comprising using a data structure according to any of claims 52-54. 55. A method comprising setting an electronic device using the data structure of any of claims 52-54. 55. A method according to any one of claims 52 to 54, comprising the step of reusing the data structure according to any one of claims 52 to 54 to set different electronic devices. 55. A server for storing and transmitting a data structure according to any of claims 52-54. delete delete delete delete Means for storing first data; Means for receiving a command to identify the first data; Means for determining an attribute of the identified first data; Means for identifying an executable file from the determined attribute; And Means for operating on the identified data using the identified executable file. Transmitting a code identifying the first data; And Designating execution of an executable file not identified on said first data. Transmitting instructions for creating a hierarchical node type data structure having leaf nodes and internal nodes, the first data stored at the first leaf node; And Transmitting a first command identifying the first leaf node specifying execution of an unidentified executable file on the first data stored at the first leaf node. And a memory for storing code identifying the first data and for specifying execution of an executable file that is not identified on the first data. 67. The server of claim 66, wherein said code is for setting an electronic device. 68. The server of claim 66 or 67, wherein said code is for reuse in setting up different electronic devices. Store instructions for generating, at the electronic device, a hierarchical node-like data structure having leaf nodes and internal nodes, the first data stored at a first leaf node; And a memory for storing a first command identifying said first leaf node specifying execution of an executable file not identified on data. Program code for automatically determining an attribute of a received command that identifies the first data; Program code for automatically identifying an executable file from the determined attribute; And And program code for enabling the identified first data to be operated using the identified executable file. delete

Images