Targeted queries using oma dm protocol

FIELD: radio engineering, communication.

SUBSTANCE: disclosed are various technologies and techniques for extending the functionality of the open mobile alliance (OMA) device management (DM) protocol. An addition is made to the OMA DM protocol that enables the server to specify node filtering criteria as part of a query to a target node on a mobile device to indicate a sub-set of the device management data for the target node that should be returned. As another variation, a modification is made to the OMA DM protocol that enables the server to specify what attributes should be selected on the mobile device in one parameter of a target URI of the Get command, and what format the device management data should be returned in as another parameter of the target URI of the Get command.

EFFECT: extending the functionality by providing access to applications and information on devices.

20 cl, 7 dwg

PRIOR art

In the modern world of technology, many mobile devices can be used by busy people. Some examples of mobile devices include personal digital assistants (PDAs), wireless phones, PDA phones, portable computers, devices, vehicles or embedded devices, to name a few examples. Some mobile devices are used to place phone calls, accessing personal information, send text messages and e-mail, or sometimes even a remote connection to a corporate network applications. In order for organizations to manage mobile devices, technologies related to the management of devices have been designed to provide customization, maintenance and personalization options. Methods of control devices can be used to provide mobile device or providing the necessary performance parameters for the mobile device. Since the functional capabilities offered by mobile devices continue to increase, also increasing the number of parameters and settings that you want to manage mobile devices.

Some methods of control devices adopted the s as industry standards. For example, the open mobile Alliance (OMA) supports device management (DM), which uses to advantage the wireless application Protocol (WAP), giving scheme, next to her own control structures, devices to provide devices for information access applications and information about specific devices. For example, the standard OMA DM determines that the device features should be represented as a tree of named nodes, rooted at the node named ".". In the session management OMA DM server and the mobile device communicate through the Protocol standards, called OMA DM Protocol. During such a session OMA DM server sends to the mobile device, some of the commands in the XML format (extensible markup language)that queries or modifies the nodes, either by structure or by value.

OMA DM Protocol allows the server to request data from a target site on a mobile device. However, if the target node, which is at the root of its own subtree, the data that is returned can contain all the data for the target node, and the data for the complete subtree. When the desired piece of information can be effective to obtain the desired data. For example, one approach that can be prin the t to obtain the desired data, there is for the server to perform numerous iterations of the querying device, receiving the response and parse the response and so It can be slow and inefficient due to the processing of additional data that are not needed and also because of the bandwidth and the time spent on additional round trips (tree search) to retrieve the data. Another approach that can be adopted, there is for the server to request a full subtree, where ever is the desired node. It can also lead to data processing that are not needed, and the cost of additional system resources, as it returns a complete subtree, even if the server only need a small portion of the data in this subtree.

The INVENTION

Disclosed various technologies and methods to extend the functionality of OMA (open mobile Alliance) DM Protocol (device management). The addition is made to the OMA DM Protocol, which allows the server to define the filter criteria of the nodes as part of a request for a target site on a mobile device, to identify a subset of the data management device to the target node, which must be returned. The server sends a request to the mobile device. When the request has been successfully processed on a mobile device is TBE, the response is received from the mobile device that includes only a subset of the data management device, which perform filtering criteria nodes.

In another embodiment, made modifications to the OMA DM Protocol, which allows the server to determine which attributes should be selected on the mobile device in one target URI command get (Get), and what format the data management device should come back as another parameter for the target URI command get (Get).

This invention provides to use a selection of concepts in a simplified form, which further described below in the detailed description. This invention is not intended to identify key features or essential characteristics of the claimed object, not meant to use it as an aid in determining the scope of the claimed object.

BRIEF DESCRIPTION of DRAWINGS

Figure 1 is a schematic representation of the OMA DM structure of a variant of implementation.

Figure 2 is a schematic representation of some exemplary source code to define filtering criteria node in numerous places team (Get), using SQL syntax.

Figure 3 is a schematic representation of some exemplary source code to determine the criteria is to filter the nodes in the argument node filtering OMA DM request, using the syntax of the SQL query.

Figure 4 is a schematic representation of some exemplary source code to define the filtering criteria of the nodes in the argument node filtering in a separate data parameter OMA DM query using the syntax of the Xpath query.

5 is a flowchart of the process for one possible implementation that illustrates the steps involved in sending a query that has a criteria filter nodes for mobile devices using OMA DM Protocol.

6 is a schematic representation of some of the source code to determine a single parameter that indicates which attributes should be selected and the other parameter that indicates which format should be returned to the data management device.

7 is a schematic representation of a computer system of one implementation options.

DETAILED DESCRIPTION

Technologies and techniques herein may be described in the General context as extensions and/or modifications to OMA (open mobile Alliance) DM Protocol (device management), but the technologies and techniques also serve other purposes in addition to these.

As previously mentioned, the OMA DM standard advantageously uses the WAP Protocol (wireless application Protocol), providing the schema button R is the house with its own control structures, devices to provide devices for information access applications and information about specific devices. These structures control devices shown on the OMA DM structure 100 figure 1 as objects 102 management OMA DM. Standard OMA DM determines that the mobile device should be represented as a tree of named nodes, rooted at the node named ".". An example of this structure is given briefly. In the session management OMA DM server and the mobile device communicate through the Protocol standards, called OMA DM Protocol. During such a session OMA DM server sends to the mobile device, some of the commands in the XML format (extensible markup language)that queries or modifies the nodes, either by structure or by value. OMA DM Protocol allows the server to request data from a target site on a mobile device. The term "target site" as used herein refers to a node in the tree, the device management OMA DM, which is the object of a certain team OMA DM server (for example, the command get (Get)). The target node may include zero or more nodes descendants.

As shown in figure 1, in one embodiment, the extension to the OMA DM Protocol 104 to add one or more criteria 108 filter nodes to determine 106 query target nodes. Criteria 108 filter nodes allow the server to determine a subset of the data driven by the I device, want to return from your mobile device. The term "filter criteria nodes", as used herein, means the inclusion of one or more parameters, criteria, or other values that determine how the device control data should be filtered. As described in additional detail in figure 2-5 in this document, in one embodiment, at least part of the filtering criteria of the nodes included in the new parameter added to the target URI is included in the command get (Get). Other variants of implementation is also described in additional detail.

Alternative or in addition to the criteria 108 filter nodes other criteria 110 may also be modified and/or included in the OMA DM Protocol 104. As one non-limiting example, can be made modification for OMA DM Protocol, from the condition that one parameter was used to specify which attributes should be selected on the mobile device and the other parameter is used to indicate in which format the data management device must be returned. This non-limiting example described in additional detail in Fig.6. Some examples are now provided in figure 2-6 to further illustrate the filtering criteria nodes and other ideas.

Returning now to figure 2-6, kotory sample source code and processes for implementing one or more embodiments OMA DM Protocol 104 described in additional detail. In some embodiments, the implementation of the processes described in the Chapter 2-6, at least partially implemented in the operating logic of computing device 300 (Fig.7).

Figure 2 is a schematic representation of 130 some sample source code to define filtering criteria node in numerous places in the command get (Get), using SQL syntax. Before considering the details of the syntax sample source code shown in figure 2, first described example to further illustrate the idea of filter nodes.

Assume that only part of the data management device is required for the server to perform some operation control device. Below is a hypothetical example of a tree data, which may be present on the mobile device:

x

y

b (value=1)

(value=2)

d

e (value=51)

y2

b (value=3)

(value=4)

d

e (value=28)

y3

b (value=5)

(value=6)

d

e (value=51)

Suppose that the server only needs to retrieve the values of all nodes {./x/y/b,./x/y/c}, where appropriate./x/y/d/e.value ==51. A query such as the one shown in figure 2, can be run from the server to the mobile device, which shortly describes additional detail. After processing the results on the mobile device, the server then takes the result is back, which is similar to the following:

./x/y/b (value=1)

./x/y/c (value=2)

./x/U3/b (value=5)

.x/y3/c (value=6)

It should be noted that the above list of results is a simplified representation of what the server actually accepts, and is presented in simplified form for illustrative purposes. Actual results may be returned in XML or another format, for example, the format specified by the server or the client. Below is an example of what can be similar to the results in XML format.

<MgmtTree xmlns="syncml:dmddfl.2">

<VerDTD> 1.2</VerDTD>

<Node>

<NodeName>b</NodeName>

<Path>./x/y</Path>

<RTProperties>

<Value>l</Value>

</RTProperties>

</Node>

<Node>

<NodeName>c</NodeName>

<Path>./x/y</Path>

<RTProperties>

<Value>2</Value>

</RTProperties>

</Node>

<Node>

<NodeName>b</NodeName>

<Path>./x/y3</Path>

<RTProperties>

<Value>5</Value>

</RTProperties>

</Node>

<Node>

<NodeName>c</NodeName>

<Path>./x/y3</Path>

<RTProperties>

<Value>6</Value>

</RTProperties>

</Node>

</MgmtTree>

In both of the above examples, the nodes that were returned, include only the required fields, where they meet certain criteria filter nodes. In this hypothetical example, the filter criteria included the requirement that certain parts of the data to dominioscase for nodes, who have the "e"node with a value of 51. The results included selected data fields for sites that met these criteria.

Returning now to the example code of figure 2, one way to implement the filtering criteria of nodes using the OMA DM Protocol, there is to add filtering criteria nodes to the command get (Get). The command get (Get) is supported in the OMA DM Protocol to allow the server to receive device control data from the mobile device. In the example source code shown in figure 2, the parameter 132 LocURI command get (Get) modified to enable the filter 134 nodes, which determines the language 136 query that is used to Express the criteria nodes. In this example, the actual filtering criterion nodes then really expressed anywhere in the command get (Get), for example, in section 138 of the data, using the syntax of the query language that was specified in the parameter 134 of filter nodes. In this example, the parameter 134 filter node determines that the syntax 136 query language used in SQL. SQL query 140 is then activated to section 138 of the data. The SQL query contains the same criteria that were used in the earlier example, which limited the entry records "b" and "c" for nodes that have values equal to 51.

The use is, shown in figure 2, is just one example of numerous possible ways in which OMA DM Protocol may be modified to include criteria for filtering nodes. For example, in other embodiments, the implementation of certain filter criteria nodes can simply be included directly in the parameter 132 LocURI, in some other section of the command get (Get) or in some external location that is accessible from command get (Get).

Figure 3 is a variation of figure 2, which illustrates how the same criteria 156 filtering SQL nodes can alternatively be incorporated directly into the parameter 152 LocURI as part of the filter 154 knots. In other words, the wording of the actual query that indicates criteria that should be used to select subsets of the data management device can be embedded directly in the parameter 152 LocURI as another possible variant.

Figure 4 is a schematic representation of 170 some sample source code to define the filtering criteria of the nodes in the argument node filtering in a separate data parameter OMA DM query using the syntax of the Xpath query. Sample source code figure 4 shows a variation of figure 2, where the syntax of the Xpath query is used for a hypothetical query instead of SQL Cinta the SIS. In this example, the parameter 172 LocURI command get (Get) contains the parameter 174 filter nodes, which indicates the value of the Xpath for syntax 176 query language. Section 178 data command get (Get) then includes the query with the actual filtering criteria of nodes in the syntax of the Xpath query language. Criteria specified in the Xpath syntax, are the same filtering criteria as above, but instead uses the Xpath syntax for illustration. Although the query shown in the data section in examples 2 and 4, and directly in the parameter LocURI figure 3, taken into account that the request for expressions of filtering criteria nodes can be specified in any of numerous ways, as happens to a person skilled in the field of computer software. Any appropriate type to represent the filtering criteria of the nodes directly in or available for the command get (Get) OMA DM Protocol can be used in other variants of the implementation.

Returning now to figure 5, shown is a flowchart 200 of a process for one possible implementation that illustrates the steps involved in sending a query that has a criteria filter nodes for mobile devices using OMA DM Protocol. Request additional is made from a mobile device that p is glaset server to start the session management device (step 202). As one non-limiting example, a mobile device can connect to the server (via HTTP or other protocols) and to request updates. In any event, the server somehow determines that it is time to interact with the mobile device to retrieve and/or update the data management device. The server sends a request to the mobile device, which includes the command get (Get) the filter nodes to retrieve data management device (step 204).

If the request is successfully processed on the mobile device (point 206 of the decision), then the server accepts the response from the mobile device, which includes a subset of the data management device, which perform filtering criteria nodes (step 208), in contrast to other nodes that do not satisfy the filtering criteria of nodes. In some implementations, the server may receive a status indication or other auxiliary information together with certain requested data that met the criteria of the filter nodes. In such scenarios, the server does not accept the data nodes in the tree that is definitely requesting for filter criteria filter nodes. In the event that the request fails processed on a mobile device (that is ka 206 decisions) then the server receives an error from a mobile device, where applicable (step 210). If an error occurs, for example, due to communication errors between the server and the mobile device, then it may be impossible to take the error code, because the connection was lost.

Returning now to Fig.6, described another modification for OMA DM Protocol, to illustrate how the choice of attributes can be included in a separate option from the format selection data to select nodes in the parameter LocURI command get (Get). Sample source code 240 has a parameter 242 LocURI parameter 244 list, which describes the format in which the data management device must be returned. In one embodiment, if the value list is "StructData", then all nodes are returned in separate items in the results with the static data set for each node. If the value for the parameter 244 list is "TNDS", XML BLOB (binary large object) is returned, describing for each node in the data set for all sites; this choice attribute is configurable, but the setting itself is embedded in the value list TNDS. Parameter 246 properties, however, are exempt from the selection of attributes from other parts of the query syntax, for example, the choice of installation sites and selecting format data, and therefore the parameter 246 properties can be specified in the connection with any other possibility to determine the set of nodes or select a data format. This parameter 246 properties by itself indicates what attributes should be chosen from the installation of addressable nodes of the mobile device. The attributes specified in the parameter 246 properties may include properties of nodes and value nodes, and multiple attributes can be specified at one time. It should be noted that these parameters can be named differently than described in Fig.6, but are just one example.

As shown in Fig.7, one exemplary computer system for use by implementing one or more parts of the system includes a computing device such as computing device 300. In the most basic configuration, computing device 300 typically includes at least one block 302 and the memory 304. Depending on the exact configuration and type of computing device, memory 304 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc. or some combination of both. This is the most common base configuration is illustrated in Fig.7. using a dashed line 306.

In addition, the device 300 may also have the additional features/functionality. For example, the device 300 may also include additional storage device (removable and/or fixed), which shall include, but not limited to magnetic or optical disks or magnetic tape. Such additional storage device is illustrated in Fig.7. a removable storage device 308 and non-removable storage device 310. The storage media of the computer include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as machine-readable commands, data structures, program modules and other data. The memory 304, removable storage media 308 and non-removable storage media 310 - all are examples of storage media of the computing machine. Computer storage media include, but not as a limitation, RAM (random access memory, RAM), ROM (read only memory device ROM), EEPROM (electrically erasable and programmable ROM), flash memory or other memory technology, CD-ROM on the CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage device or other magnetic storage devices, or any other medium that can be used to store the desired information and which can be done to blunt the device 300. Any such storage media of the computer may be part of the device 300.

Computing device 300 includes one or more compounds of 314 links that allow computing device 300 to communicate with other computers/applications 315. The device 300 may also have a device(a) 312 input, for example, keyboard, mouse, pen, audio input device, touch input device, etc. Device(s) 311 output, for example, a display, speakers, printer, etc. may also be included. These devices are commonly known in the art and need not be described in detail in this document.

Although the object was described in the language of the characteristic structural features and/or methodological acts, it is necessary to understand that the object defined in the attached formula, not necessarily limited to the above-described characteristic features or actions. More precisely, the features and steps described above are disclosed as exemplary forms of implementing the claims. All equivalents, changes and modifications which come within the spirit of the embodiments as described herein, and/or subsequent claims of the invention, it is desirable to protect.

For example, a specialist in the field of computer software finds out that at the minimum level, considered in this document, can be arranged differently on one or more computers, to include fewer or additional options or features, than shown in the examples.

1. Machine-readable media on which are executable by the computer components that contain:
the structure of a device management (DM) Open mobile Alliance (OMA), which includes standard control objects OMA DM associated with the OMA DM Protocol to control data management device on the mobile device, and the OMA DM Protocol allows the server to send to a destination node on a mobile device, a request to retrieve the data management device associated with the target node; and
addition to the OMA DM Protocol, which allows the server to specify the filter criteria nodes and the syntax of the language used for these criteria nodes, as part of the above mentioned request for designation of a subset of the data management device to the target node, which must be returned, with the addition to the OMA DM Protocol allows the server to specify the filter criteria of nodes to filter the data management device included in said subset of the data management device, based on one or more of the backside of the data values in the data management device.

2. Machine-readable storage medium according to claim 1, with the filter criteria of the nodes included in the request as part of the command get (Get) OMA DM.

3. Machine-readable storage medium according to claim 2, with the command get (Get) set in XML syntax.

4. Machine-readable storage medium according to claim 3, with the filter criteria of nodes set in the LocURI in XML syntax.

5. Machine-readable storage medium according to claim 1, with at least part of the filtering criteria of the nodes specified in the new parameter added to the unified target ID information resource identifier (URI) in the above query.

6. Machine-readable storage medium according to claim 5, in this new parameter specifies the syntax of the language used for the filtering criteria of nodes.

7. Machine-readable storage medium according to claim 6, while the syntax of the language is selected from the group consisting of SQL and Xpath.

8. Machine-readable storage medium according to claim 1, in this section the data of the above query contains the actual wording of the request, which indicates the criteria that should be used to select the above-mentioned subset of the data management device.

9. Machine-readable storage medium of claim 8, with the specified syntax is used to upomyanutoj the data section of the request and sets the new parameter in the target URI of the above query.

10. Machine-readable storage medium according to claim 9, in which the target URI of the above query also contains one parameter that indicates which attributes should be selected on the mobile device, and another parameter that indicates in what format the data management device must be returned.

11. The method of extracting subsets of data to the target node using the Protocol device management (DM) Open mobile Alliance (OMA) (OMA DM Protocol), comprising stages, which are:
send to a mobile device a request to retrieve the data management device using the OMA DM Protocol, and the request includes the command get (Get) the filter nodes and syntax of the language used for these criteria nodes, and filter criteria nodes denote the subset of the data management device, which must be returned to the target node, while the filter criteria nodes indicate that the data management device included in said subset of data from the control device shall be filtered based on one or more specified values of the data management device; and
when the request has been successfully processed on the mobile device, receive from the mobile device a response that includes only upon the mentioned subset of the data management device, which satisfy the above criteria nodes.

12. The method according to claim 11, further containing the step at which, when made attempt to query on a mobile device, but the request was not successfully processed on the mobile device, receive from the mobile device the error message that describes the error that occurred on the mobile device.

13. The method according to claim 11, further containing a phase in which, prior to sending the request, receiving from the mobile device, the communication request, which indicates that the data request control device, you must send in your mobile device.

14. The method according to claim 11, in which at least part of the filtering criteria of nodes is contained as a parameter in the target unified ID information resource identifier (URI), which is part of the command get (Get).

15. The method according to 14, in which the parameter in the target URI specifies the syntax of the language that you want to use for the filter criteria.

16. The method according to 14, in which in a separate section of the command get (Get) included the actual query that specifies the filter criteria of the nodes, and that the actual query is written in the syntax of the language specified in the parameter in the target URL.

17. The method according to 14, in which a separate section is a data section of the command get(Get).

18. The method according to 14, in which the target UR1 has one parameter, which indicates what attributes should be selected on the mobile device, and another parameter that indicates which format should be returned to the data management device.

19. Machine-readable media on which are executable by the computer components that contain:
the structure of a device management (DM) Open mobile Alliance (OMA), which includes standard control objects OMA DM associated with the OMA DM Protocol to control data management device on the mobile device, while the OMA DM Protocol allows the server to send the command get (Get) to the target node on the mobile device to retrieve the data management device associated with the target node; and
the modification for OMA DM Protocol, which allows the server to specify which attributes should be selected on the mobile device, in one option unified target ID information resource (UR1) command retrieve (Get), and in what format must be returned to the data management device as another target UR1 command get (Get), with modification for OMA DM Protocol allows the server to specify criteria for filtering the data management device the PTO based on one or more specified values of the data management device.

20. Machine-readable storage medium according to claim 19, in which there are further executable by the computer components containing addition to the OMA DM Protocol, which allows the server to define the filter criteria of the site as part of the command get (Get) to denote the subset of the data management device to the target node that should be returned.