WO2010007228A1

WO2010007228A1 - Adaptive configuration device

Info

Publication number: WO2010007228A1
Application number: PCT/FR2009/000745
Authority: WO
Inventors: Damien Praca; Razmig Sarkissian
Original assignee: Mobile Distillery
Priority date: 2008-06-24
Filing date: 2009-06-19
Publication date: 2010-01-21
Also published as: FR2932905A1; FR2932905B1

Abstract

The invention relates to a device that includes: a storage memory (4) with code identifiers and parameter data correlating them with electronic product identifiers; a working memory (6) that receives one or more electronic product identifier lists; a syntactical analyzer (8); a requestor (10); and a comparator (12). The device also includes a driver (14), equipped for: * calling the syntactical analyzer (8) with computer pre-program code data to set up a working code identifier list; * for each electronic product identifier list from the working memory (6), and for the identifiers from the working code identifier list: repeatedly calling the requestor (10) with each identifier in the electronic product identifier list, and with the current code identifier, in order to set up a parameter data list that correlates with the electronic product identifier list; repeatedly calling the comparator (12) with data from the parameter data list to determine new electronic product identifier lists, the values of similarity therebetween of which verify a selected criterion; and replacing the electronic product identifier list with the new electronic product identifier list or lists.

Description

Adaptive configuration device

The invention relates to an adaptive computer configuration device.

Nowadays, the number of personal electronic devices available has exploded. Faced with the diversity of existing operating systems, and with reduced product life, the use of virtual machines has exploded.

Thus, a large number of programs for mobile phones are now coded in Java, and more particularly in J2ME. However, despite the standardization that Java offers, many phone-specific settings still make it necessary to produce custom source codes for each phone.

To circumvent this obstacle, software has been developed that provides libraries and or java APIs that can be used to write a program regardless of the phone, and then produce such codes adapted to each phone. An example of such software is the Celsius software from Mobile Distillery. In this case, before processing with Celsius, the code is called "preprogram code".

However, even if these software make it possible to simplify the creation of the code by offering a single generic source, the downstream management of the multiplicity of resulting bit codes is complex. In addition, each binary code requires validation that is obtained by purchasing a relatively expensive certificate.

Producing a program for a plurality of mobile devices is therefore currently complex and expensive.

The invention improves the situation.

For this purpose, the invention proposes an adaptive configuration device, comprising a storage memory, with code identifiers and parameter data matching code identifiers and electronic product identifiers, a working memory, of its own kind. to receive one or more lists of electronic product identifiers, a parser, able to browse computer program code to retrieve a list of code identifiers, a memory request for storing the parameter data corresponding to a given electronic product identifier and a code identifier, a comparator arranged to define a similarity value between parameter data received in input, and a driver, arranged to: * call the parser with computer program code data received as input to establish a list of work code identifiers;

* for each list of electronic product identifiers received in the working memory, and for at least some of the code identifiers the list of work code identifiers: - repeatedly call the requester with each identifier in the list of identifiers electronic product and with the current code identifier, to establish a list of parameter data, maintaining a correspondence with the list of electronic product identifiers; repetitively calling the comparator with the data of the parameter data list, to establish a list of similarity values, maintaining a correspondence with the list of electronic product identifiers; determining one or more new lists of electronic product identifiers each comprising electronic product identifiers whose corresponding similarity values satisfy a chosen criterion, and - replacing in the working memory the list of electronic product identifiers by the one or more new lists of electronic product identifiers.

Such a device is extremely advantageous because it allows to group together the devices for which the code is close if not identical. This allows automated and simplified version management, and a great reduction in validation costs.

The invention also relates to an adaptive configuration method that comprises: a. receiving one or more lists of electronic product identifiers, with preprogram computer code data; b. calling a parser with said preprogram computer code data to establish a list of work code identifiers; vs. define a current work code identifier; d. define a list of current electronic product identifiers; e. deriving from a storage memory a list of correspondence with the list of current electronic product identifiers and the current code identifier; f. repetitively comparing the data of the parameter data list, to determine one or more new lists of electronic product identifiers whose parameter data satisfy a selected criterion; boy Wut. replace the list of current electronic product identifiers with the new electronic product identifier list (s); h. repeat steps d. to g. until all lists of electronic product identifiers have been processed; i. repeat steps c. at h. until all work code IDs have been processed.

Other features and advantages of the invention will appear better on reading the following description, taken from examples given for illustrative and non-limiting purposes, taken from the drawings in which: FIG. 1 represents a schematic view of a device according to the invention; Figure 2 shows a schematic diagram of an operation performed by the device of Figure 1; FIG. 3 represents an exemplary implementation of an operation of FIG. 2; FIG. 4 represents an exemplary implementation of another operation of FIG. 2; Figures 5 and 6 show examples of data arrangement processed in the operations of Figures 2 to 4; FIG. 7 represents an optional operation of the operation of FIG. 4; Fig. 8 shows an exemplary data arrangement resulting from the operation of Fig. 7; and Figure 9 shows a variant of Figure 1.

The drawings and the description below contain, for the most part, elements of a certain character. They can therefore not only serve to better understand the present invention, but also contribute to its definition, if any. This description is likely to involve "by copyright and / or copyright. The rights holder has no objection to the identical reproduction by anyone of this patent document or its description, as it appears in the official records. For the rest, he reserves his rights in full.

FIG. 1 represents a schematic view of a device according to the invention. The device 2 comprises a storage memory 4, a working memory 6, a parser 8, a queryer 10, a comparator 12 and a driver 14.

The storage memory 4 receives a library dictionary 16 and a knowledge base 18. The working memory 6 receives a file 20 containing computer program code, which is in the example described here of the java code.

The file 20 contains pre-program code which is intended to be interpreted according to the telephone on which it is desired to carry the code of the file 20. This code intended to be interpreted is detected by means of keywords which may be method names, variable names, or specific instructions.

The invention is therefore not limited to the code in Java, and it can be extended to any type of computer program code that a person skilled in the art will know how to use.

With the file 20, the driver 14 calls the parser 8, which uses the dictionary 16 to return a file 22 comprising a list of methods or other keywords identified in the code of the file 20.

The working memory 6 also receives a file 24 comprising a list of telephones that one wishes to classify. With the file 22 and the file 24, the driver calls the queryer 10 and the comparator 12, which interact with the knowledge base 18 to establish a file 26.

The file 26 contains a plurality of phone lists similar to that of the file 24 which have been mail-collected in the device 2, based on the keywords identified in the file 20. In the example described here, the destination devices of] which implement a java virtual machine by means of J2ME. However, the invention applies to any set of electronic products on which it is desired to carry a port of a generic code.

Furthermore, the memories 4 and 6 can be made in any manner known to those skilled in the art, for example in the form of hard disks, CD or DVD type optical memories or other, and are not necessarily physically assembled with the other elements of the device 2. Thus, these memories can be accessed by network, or by any other means known to those skilled in the art.

Thus, thanks to the device 2, starting from a generic pre-program code that one seeks to carry on phones, and a list of such phones, it is possible to establish a plurality of telephone lists. For each list, a port can be made, this porting being identical for all the telephones of the same list.

The manner in which the device 2 establishes these lists will now be described with FIGS. 2 to 9.

Figure 2 shows a schematic diagram of the operations of the device 2 on the files 20, 22 and 24.

In an operation 200, the device 2 receives in the memory 6 the files 20 and 24. As we saw above, these are the files that will serve as a basis for grouping phones.

In an operation 300, the driver 14 calls an Anl () function which will be detailed with FIG. 3. The Anl () function receives as argument the java code of the file 20, and calls the parser to extract keywords from it. contained in the dictionary 16 as seen above. The result is stored in file 22.

Then, in an operation 400, the driver 14 calls a function Comp () which will be detailed with FIG. 4. The function CompQ receives as argument the keyword file 22 and the file 24 from the list of telephones, and calls the quercher 10 and comparator 12 by accessing knowledge base 18 to group phones by group. In each group, the telephones are identified as a code associated with the keywords of the file 22. All of these groups are returned and stored in the file 26.

The operation 300 will now be described with reference to FIG. 3. The operation starts at 302 from the reception of the arguments of the function Anl (), namely the code contained in the file 20.

A loop is then started in 304, in which a string Str is extracted from the code. In an operation 306, the string Str is searched in the dictionary 16 by means of a function Dic ().

When the string Str is present in the dictionary 16, this string is added in 308 to the variable Meu \ _Lst which will be returned as a result.

Then, or when the string Str is not present in the dictionary 16, the loop ends with a test 310 on the text remaining in the file 20.

If the file 20 is not empty, then the loop resumes at 304. Otherwise, the operation 300 ends at 312 with the return of the variable Meth_Lst in the file 22.

In the example described here, the searched keywords are names of methods related to the Celsius library.

This library makes it possible to produce a code of pre-program in java which is adapted for all the mobile phones of the market. For this, the programmer uses, for items whose implementation is specific to phones, generic methods.

Then, this java code "agnostic" can be processed by CELSIUS software, to implement the methods of the library in a specific way to each phone.

In other embodiments, the dictionary may contain other elements, such as variable names or others. Operation 400 will now be described with reference to receiving the arguments of the Comp () function, namely file 22 with the keyword list MethJLst, and file 24 which includes a list of phones that the we want to group together to make a single port. Then, this list of phone identifiers is stored in a Tel_Lst_Arr array in an operation 403.

Then, a double loop begins in 404 with unstacking a current keyword Par file 22. The double loop works as follows: - the first loop is an unstacking of the keywords of the file 22; the second loop is an unstacking of the telephone lists of the Tel_Lst_Arr table.

The second loop is used to group together the phones for which the knowledge base indicates that they have a similar port for the current keyword.

In an operation 406, the current keyword is searched in the knowledge base 18 to determine if it corresponds to a discriminant port.

Discriminant port means that two phones that have a different implementation of the code associated with the current keyword require two separate ports. For example, if the keyword is for the type of sound files used, it will be necessary to provide a port for MIDI compatible phones only, and another for MP3 compatible phones. Therefore, the associated keyword is considered as discriminating.

If the current keyword does not correspond to a discriminant port, then the second loop is avoided, and the operation can be extended by an optional boosting operation 408 described with FIG. 7. Then, the first loop ends with a operation 410 in which it is checked whether there remain other keywords to be analyzed.

If it is determined that the current keyword corresponds to a discriminant port, then the second loop is started with the retrieval to 412 of a list of Tel_Lst_Tmp telephones from the Tel_Lst_Arr array.

As we saw above, the Tel_Lst_Arr table is initialized with the Tel_Lst list of the file 24. Thus, during the first iteration, the Tel_Lst_Arr table contains a single list of phones, which contains all the phones that one will as it will appear, the number of lists in the table Tel_Lst_Arr increases, as one detects different portings necessary.

Once the current telephone list Tel_Lst_Tmp has been retrieved, an array SpI is set to zero in 414. The table SpI is then filled for each telephone in the list Tel_Lst_Tmp with a value indicative of the portage associated with the current keyword Par on each of these. phones.

For this, a loop is started at 416 in which the Tel_Lst_Tmp list is popped up to obtain a Tel phone identifier.

This operation is followed in 418 by the requestor's call with the Tel identifier and the current keyword By (or an identifier of this keyword) with a function Val ().

The function Val () calls the knowledge base 18 with these two parameters and stores the corresponding value in the table SpI.

Then, a test checks in 420 if the Tel_Lst_Tmp list has been completely traversed, and therefore whether the set of indicative porting values have been retrieved or not. If there are still phones, operations 416 and 418 are repeated. Otherwise, a Split () function is called in 422.

The Split () function takes the SpI array as an argument, and returns a file containing one or more New_Lst phone lists.

The purpose of the SplitQ function is to analyze the indicative porting values of the SpI table, and to return as one or more lists in the NewJLst list the identifiers of the telephones, collected by identical porting.

The Split () function can be implemented in several ways.

In the embodiment described here, the Split () function calls the comparator 12 with each pair of values in the SpI array. The comparator 12 returns each time a value that indicates whether the pair of values is identical or sufficiently similar to achieve a identical porting, and the split () function classifies the identifii according to the similarity value.

Those skilled in the art will be able to consider other embodiments of the Split () function. Note that as a result of the Split () function, New_Lst includes the same phone identifiers as Tel_Lst_Tmp. However, in NewJLst, these identifiers are arranged in lists that do not overlap.

Operation 422 is a segmentation of the Tel LstJTmp telephone list into one or more lists according to the particular porting requirement. Thus, in the case where a single port is suitable for Tel_Lst_Tmp telephones for the Par parameter, the list New_Lst is identical to the list Tel_Lst_Tmp.

Then, at 422, the New_Lst file is added to a New_Tel_Lst_Arr file. The Tel_Lst_Arr array, the NewJLst list, and the New_Tel_Lst list can be seen as shown in Figure 5, i.e. as an array of telephone lists.

Each list of telephones of these elements, just like the TelJLst list of the file 24, can be seen as represented in FIG. 6, that is to say as an array of telephone identifiers.

The second loop is extended to 426 with the Tel_Lst_Arr list test. If this list is empty, it means that all lists of Tel_Lst_Arr have been browsed for the current keyword Par, and separated and stored as necessary in the New_Tel_Lst_Arr list.

The second loop is then terminated at 428 with the replacement of the list Tel_Lst_Arr by the list New_Tel_Lst_Arr. The test of the operation 410 then determines whether all the keywords have been browsed.

If this is the case, the Comp () function ends in 430 with the return of file 26 which contains the TelJLst_Arr list. Otherwise, the updated Tel_Lst_Arr list is further analyzed with the following keyword with operation 404. Thus, starting from a list of global phones, we pΣ keywords and segment the list successively each time an element indicating the need for a separate port is detected.

At the end, we obtain a plurality of telephone lists for which it is known that the same port can be made with respect to the keywords found in the file 20.

FIG. 7 represents an exemplary implementation of the optional operation 408. This operation aims to establish a DynJLst dynamization table which makes it possible to reduce the number of telephone lists by reducing the criticality of the indicative carrying values.

For example, a keyword might be associated with a screen width, or a phone-specific error correction. In principle, this type of difference should be considered as critical, and involve the generation of distinct porting, that is, the segmentation of telephone lists.

However, since these are light modifications, such as a value to be changed or a short piece of code to conditionally add, it may be interesting to classify them as non-discriminative porting, and to anticipate the generation of information to manage the variables. different cases in operation 408.

In fact, the operation 408 is very close in its implementation of the second loop of FIG. 4, and the operations 702, 706, 708, 710, 712 and 716 are identical to the operations 412 to 420 and 426.

The operations 704 and 718 have the role of keeping the list Tel_Lst_Arr current (it is recalled that the operation 408 does not modify this list, but merely establish dynamization parameters). After operation 718, operation 408 ends in 720.

The operation 714 is the call of a function Dyn () which takes as argument the table SpI and adds to the table DynJLst the various values indicative of porting that it contains in correspondence each time of the phone of identifier Tel and the current keyword By correspondents. Figure 8 shows an example of the DynJLst table. Thus tested and that the telephones have been divided into porting lists, the Celsius software can use these lists as well as the DynJLst table to generate the adapted ports taking into account all the specificities of each phone.

Note that the values in the DynJLst table can be relative or absolute. Thus, some parameters such as the font size can be set to default values, and the difference between this value and that of each phone should be stored. Conversely, some settings such as compatible image formats, or the best displayable font are absolute in nature and must be stored individually.

Figure 9 shows a variant of Figure 2. In this figure, optional step 408 is implemented. Thus, it comprises the three operations 200, 300 and 400 described above. These operations are completed by an operation 900 and an operation 920.

The operation 900 has the function of generating a telephone determination algorithm.

Indeed, the current versions of J2ME do not make it possible to determine the phone on which a java virtual machine works.

Therefore, to allow the data from the DynJLst table to be used, an algorithm must be established that allows each phone to determine the corresponding dynamic parameters.

This is done by a Diff () function, which generates a Tel_Alg_Arr file. The Tel_Alg_Arr file will contain one or more algorithms that allow the phones to identify the corresponding dynamic data, and one or more databases that contain this dynamic data.

Depending on the segmentations of Tel_Lst_Arr, each particular list will see its number of phones decrease. Thus, when porting the code of the file 22 for this particular list, the data of Dyn Lst are for the most part not connected to the particular telephones of this list.

The Diff () function can therefore be implemented in many different ways, depending on whether this excess data is taken into account or not. In a first implementation, it is not necessary that the information contained in DynJLst is only really useful for a limited number of telephones. The DynJLst list is thus fully embedded in Tel_Alg_Arr, and integrated into each port.

To allow the telephones to access the data of Dyn Lst which concerns them, it is then useful to envisage an algorithm or a formula which returns an index of each telephone according to its peculiarities, this index corresponding to a corresponding index in DynJLst.

This first implementation is resource intensive, because we will store unnecessary data in each port, and a relatively complex formula (because adapted to the detection of any phone). It has the advantage of offering a unified approach that does not really care about the phone lists established in the previous steps.

In a second implementation, it is taken into account that most of the information contained in Dyn_Lst is only really useful for a limited number of phones. The list DynJLst is therefore segmented into a plurality of sub-lists that are specific to each Tel_Lst_Arr phone list.

To allow the telephones to access the data of the sub-list which concerns them, it is then useful to envisage an algorithm or a formula which returns an index of each telephone according to its peculiarities, this index corresponding to a corresponding index in the sublist. Such a formula can be greatly simplified based on the differences of the phones between them within the sublist.

This second implementation is resource-efficient because only the data will be stored for each port, and the identification formula can be simplified (because it is suitable for detecting a phone within a restricted sub-list). ). It has the advantage of offering a personalized approach for each list of phones established in the previous steps.

Finally, the operation 920 is performed by a function CompileQ, which uses the files 20 and 26 to produce a plurality of files JAR and JAD which correspond to the porting of the code of the file 20 on each phone list. For this, this also allows to produce an offended code.

With the device described above, it is possible to greatly reduce the number of different executables for porting a given application. This has a number of benefits, such as simplified versioning, reducing the number of validation certificates to pay to certify program compatibility, and so on.

The above has been presented with particular reference to mobile phones, and the porting of java applications on these phones. It goes without saying that the invention is not limited to these devices, nor to this type of language, and encompasses all cases where a port of a generic code is necessary on a large number of electronic devices.

In addition, it will be appreciated that the variants described above can be combined with each other as much as do this little. The exhaustive list of these combinations was not listed here for the sake of clarity, and not because they were not considered.

Finally, many modifications will appear to those skilled in the art, such as:

the possibility of directly classifying the list of keywords by port criticality in the parser,

- the possibility of classifying the list of keywords by porting criticality before starting to establish the Tel Lst Arr array,

- the possibility of limiting the number of phone lists, which then forces to boost the code, - etc.

Those skilled in the art will of course consider other similar modifications in their scope, which remain in the spirit of the invention.

Claims

claims

An adaptive configuration device, comprising: a storage memory (4), with code identifiers and parameter data mapping code identifiers and electronic product identifiers, a working memory (6), itself to receive one or more lists of electronic product identifiers, a parser (8), able to browse computer pre-program code to extract a list of code identifiers, a requestor (10), arranged to determine in the parameter data storage memory corresponding to a given electronic product identifier and code identifier, a comparator (12), arranged to define a similarity value between input parameter data, a driver (14), arranged for:

* calling the parser (8) with computer pre-program code data received as input to establish a list of work code identifiers;

for each list of electronic product identifiers received in the working memory (6), and for at least some of the code identifiers of the list of work code identifiers: repetitively calling the requestor (10) with each identifier in the list of electronic product identifiers and with the current code identifier, for establishing a list of parameter data, maintaining a correspondence with the list of electronic product identifiers; repetitively calling the comparator (12) with the data of the parameter data list to determine one or more new lists of electronic product identifiers which have similarity values between them which satisfy a chosen criterion, and replace in the working memory (6) the list of electronic product identifiers by the new electronic product identifier list (s).

2. Device according to claim 1, characterized in that the requestor (10) and the comparator (12) are called repetitively for code identifiers of the list of work code identifiers for which a criticality criterion is established.

3. Device according to claim 1 or 2, characterized by the code of the list of work code identifiers for which a criticality criterion is not established, the driver (14) is further arranged to repeatedly call the requestor (10). ) with each identifier in the electronic product identifier list and with the current code identifier, for storing a list of parameter data, maintaining a correspondence with the list of electronic product identifiers.

4. Device according to one of the preceding claims, characterized in that the pre-program code is compiled into a plurality of program codes, from the plurality of lists of electronic product identifiers established, and data of corresponding code parameters.

5. Device according to claim 4, characterized in that, for each of the identifiers of a given list, a single program code is compiled.

6. Device according to one of the preceding claims, characterized in that the pre-program code is java code.

An adaptive configuration method, comprising: a. receiving one or more lists of electronic product identifiers, with preprogram computer code data; b. calling a parser with said preprogram computer code data to establish a list of work code identifiers; vs. define a current work code identifier; d. define a list of current electronic product identifiers; e. deriving from a storage memory a list of parameter data, in correspondence with the current electronic product identifier list and the current code identifier; f. repetitively comparing the data of the parameter data list, to determine one or more new lists of electronic product identifiers whose parameter data satisfy a selected criterion; boy Wut. replace the list of current electronic product identifiers with the new electronic product identifier list (s); h. repeat steps d. to g. until all electronics have been processed; i. repeat steps c. at h. until all work code IDs have been processed.

The method of claim 7, wherein step c. includes: c 1. defining a current work code identifier; c2. determining a criticality associated with the current work code identifier; c3. if the criticality determined in step c2. does not respect a selected criticality criterion, repeat step c 1.

The method of claim 7, wherein step c. includes: c 1. defining a current work code identifier; c2. determining a criticality associated with the current work code identifier; fl. if the criticality determined in step c2. does not respect a selected criticality criterion, storing said list of parameter data in correspondence with the current electronic product identifier list and the current code identifier; f2. otherwise, repeatedly comparing the data of the parameter data list, to determine one or more new lists of electronic product identifiers whose parameter data satisfy a selected criterion.