|Publication number||US7860834 B2|
|Application number||US 10/873,173|
|Publication date||Dec 28, 2010|
|Filing date||Jun 23, 2004|
|Priority date||Jun 23, 2003|
|Also published as||CA2530395A1, CA2530395C, EP1642204A2, EP1642204B1, EP2273361A1, EP2273361B1, US8341113, US20040267833, US20110093841, WO2004114130A2, WO2004114130A3|
|Publication number||10873173, 873173, US 7860834 B2, US 7860834B2, US-B2-7860834, US7860834 B2, US7860834B2|
|Inventors||Evyatar Meller, Sharon Peleg|
|Original Assignee||Evyatar Meller, Sharon Peleg|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (6), Non-Patent Citations (2), Referenced by (16), Classifications (16), Legal Events (8)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This invention relates to creating compact updating versions of content stored in a storage device.
U.S. Pat. No. 6,546,552 discloses a method for generating a compact difference result between an old program and a new program. Each program including reference entries that contain reference that refers to other entries in the program. The method includes the steps of scanning the old program and for each reference entry perform steps that include replacing the reference of the entry by a distinct label mark, whereby a modified old program is generated. There is further provided the step of scanning the new program and for each reference entry perform steps that include replacing the reference of the entry by a distinct label mark, whereby a modified new program is generated. There is still further provided the step of generating the specified difference result utilizing directly or indirectly the modified old program and modified new program.
There is a need in the art to provide for a new method and system for updating versions of content stored in a storage device.
The present invention provides A method for generating a compact update package between an old version of content and a new version of content, comprising:
The present invention further provides a method for updating an old version of content giving rise to a new version of content, comprising:
generating said new version including applying said conversion element to the modified version stipulated in (iii)(a).
Yet still further the invention provides a method generating an update package for allowing updating versions of content stored in a storage device, the update package allows updating an old version of said content to a new version thereof, the method comprising:
setting integer shift rules for allowing modification of said reference item in accordance with said modification shifts.
The invention still further provides a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for generating a compact update package between an old version of content and a new version of content, comprising:
Yet still further the invention provides a program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for updating an old version of content giving rise to a new version of content, comprising:
By another aspect the invention provides a system for generating a compact update package between an old version of content and a new version of content, comprising:
Yet still further the invention provides a system for updating an old version of content giving rise to a new version of content, comprising:
In order to understand the invention and to see how it may be carried out in practice, a preferred embodiment will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:
It should be noted that the system 101 illustrated in
Therefore, hereinafter the term “content” will be used instead of “program”. In the same way, the term “storage device” will be used instead of the cellular telephones' memory devices in
In order to update content stored in the storage devices, update packages are generated and stored in the server and transmitted to the storage devices or to other devices coupled therewith.
It should be noted that a storage device can be associated with an embedded device. The embedded device can, for example, be a member in a group that includes, e.g., cellular telephones and/or consumer electronic devices. Alternatively, the storage device can be associated with a computer.
It is noted that the update package 201 can be generated in accordance with methods known per se to those versed in the art. Similarly, the ways to apply this update package in order to update the old version 202 to the new version 203 are also known.
It should also be noted that an update package is sometimes referred to as “delta file”, “difference file” or shortly as “delta” or “difference”, wherein the delta is a collections of modifications occurring while updating an old version to a new version. Thus, a person versed in the art can appreciated that an update package can be a delta file or alternatively, it can include a delta file and perhaps additional information.
The old version 202 includes a block 204 of five items, each item can be the size of at least one word, the size of one or more bytes, or any other applicable measurement. The block 204 is followed by a second block 205 of, e.g., five hundred items. Next, the old version 202 includes an item 206 that includes at least a reference (such as a pointer) to a certain item 207 in the second block 205. Items including at least one reference are referred to, hereinafter, as “reference items”. For example, a reference item 206 can include an instruction associated with an absolute reference to 207, such as “jump to the absolute address of item 207”.
It should be appreciated that if the content represented by the old and new versions (such as 202 and 203) is a computer program, for example, a block can represent a program function, as known to those versed in the art.
Reference item 206 is followed by another reference item 208, including a reference to a different item 209 in the second block 205. The reference item 208 is followed by other reference items, all include references to items within the second block 205, the last of them is reference item 210. Whilst not shown in the figure, according to the example there are, e.g. one hundred reference items between reference item 206 and reference item 210.
It is appreciated that the old version 202 can include also non-reference items, i.e., items that include no reference. The item 211 is an example to a non-reference item. Unless specifically noted, the term “item” refers, hereinafter, both to reference and non-reference items.
In addition, the old version 202 can include reference items to other items that are not included in the old version 202, i.e., references to items being external to the content. For example, if the old version represents a computer program that is loaded to a computer's RAM (Random Access Memory) during execution, such a reference item can refer to another item that is stored in an area of the RAM which is outside the area used to store the program.
Hereinafter, reference items that include at least a reference to an item included in the content are referred to as “explicit reference items”, while reference items that include at least a reference to an item that is external to the content are referred to as “implicit reference items”.
Although not shown in
The update package 201 is adapted to modify the old version 202 of the content, generating a new version 203 of the content. An update process operates in accordance with the update package 201 to generate this new version 203.
One difference between old version 202 and new version 203 in the example, is the absence of block 204 from the new version 203, where the second block 205 shifts backwards and occupies the block 204 on the storage device. According to the example, block 204 includes five items, and therefore the second block 205 shifts five items backwards. It can be appreciated, thus, that further to block 205's shift backwards, all the items included therein are shifted correspondingly (by five items). Such is the case, e.g., also with items 207 and 209 (and their corresponding items 207′ and 209′ in the new version). It is noted that item 206 includes a reference to item 207. After shifting item 206 backwards to generate item 206′, this item still references item 207, i.e., it references the address of 207 in the old version. It is required to replace the content of item 206′ so it will reference item 207′ in its new location in the new version.
It should be noted that the content of the non-reference item 211 that includes no reference and the content of the implicit reference item 213 do not require modification in this case, although their location is also shifted up by five items. It should also be noted that throughout the description, examples applied to explicit reference items are also applicable with reference to implicit reference items, unless specifically noted otherwise.
Reverting now to the update package 201, it includes commands for updating the old version 202 to the new version 203. It should be considered that in the current example commands are illustrated as string characters representing one or more operation to be performed by updating the old content (such as “copy”, “replace” etc.). However, other ways to represent commands are also applicable, such as using operation codes (shortly referred to as op-codes), wherein each command has a predetermined op-code assigned to it. In addition, sometimes commands are represented by alternative ways to those illustrated in 201. For example, a “replace” command can be represented by an insert command, where the inserted content replaces the existing content.
As shown, the first command included in package 201 is to delete five items, thereby deleting the first five items in 102, being block 204. Next, the update package includes a command to copy five hundreds items to the beginning of the new version, thereby shifting the block 205 five items backwards, giving rise to block 205′.
After copying block 205, prima facie it would be required to copy items 206, 208, . . . , 210, while shifting their location five blocks up, giving rise to the corresponding items 206′, 208′, . . . , 210′. However, as explained before, the included references of items 206′, 208′, . . . , 210′ needs to be updated to reference 207′, 209′, . . . instead of 207, 209, . . . . That is, these reference items or at least part of them need to be replaced. Instead of copying a reference item and then replacing it by a shifted reference, it is possible to replace the item on the first hand, saving the copy operation. The update package 201 includes therefore a hundred replacement commands, one for each reference item 206, 208, . . . , 210, for replacing them by a reference to the corresponding shifted item (206′, 208′, . . . 210′).
Following the hundred replacement commands, the update package 201 includes a copy command that copies the seventy terminating items 212 to follow the replaced hundred reference items in the new version 203, i.e., the seventy items (including item 211 and 213 that gives rise to items 211′ and 213′) shifted five items backwards in the new version 203.
A person versed in the art can appreciate that the update package 201 in the example above includes, amongst others, a hundred replacement commands wherein each command includes a replacing item. That is, the update package 201 includes a hundred replacing items. Bearing in mind that update packages can be transferred over limited bandwidth communication lines, such as internet or mobile (cellular) networks, reducing the size of update packages would be beneficial.
Thus, unlike the existing method in the art for generating and applying update packages, the invention discloses other methods that can produce more efficient update packages, or “compact update packages” as referred to hereinafter. One embodiment for generating such efficient update packages is referred to, hereinafter, as ‘integer notation embodiment’, wherein this embodiment generates ‘integer shift rules’. The background for explaining integer shift rules is exemplified below, with reference to
It should be appreciated that according to some embodiments of the invention it is possible to use integer values for representing items in the old and new content (202 and 203 respectively). It can be appreciated that items are data stored on a storage device such as disk or memory. If the size of an item is four bytes, it is possible to visualize the data stored in an item as an integer number occupying the four bytes.
It should be noted that any item, including non-reference items, can be represented by integers as well, and therefore int(211), for example, is the integer representation of item 211.
Reverting now to
Alternatively, it is possible to view the whole integer as indicative of the referenced item. According to this example, if item 206 includes the instruction “jump to item 207” then the integer 0x0B9DF785 can be considered as ind(207), unlike the previous embodiment, where only 0x9DF785 was considered as the indicative value. It should be appreciated that there may be another reference item (although not shown in
It can be further appreciated that indicative values can be any part of (including the whole) an integer representation of an item. Also, the example referred to a four-byte size of an item. This size was used here (and will be used again below) only as an example, and any applicable item size can be used. Note also that representing numbers as integers is only a non limiting example; and other known per se number representations are applicable.
Bearing in mind that an item (including a reference item and/or a non-reference item) can be represented by an integer value, and reverting back to
A person versed in the art can appreciate that 402 is equivalent to portion 401, wherein the replacement commands are expressed using the integer notation, in accordance with one embodiment of the invention. When using the integer notation, there are two integers associated with each replacement command. The two integers are referred to, hereinafter, as an “integer replacement pair”. One integer in an integer replacement pair is referred to as a “pre-modification integer” (representing the item in the old version) and the second is a “post-modification integer” (representing the item in the new version).
Looking at the integer replacement pairs for the explicit reference items in the old version 202, i.e., looking at the integer replacement pairs in 402, it is possible to see that the integer values reflect the shift of the referenced items. For example, it is possible to view the integer replacement pair <int(208), int(208′)>, when items 208 and 208′ references items 209 and 209′ respectively. If the item 209 was originally located at address 0x9DF785, wherein the size of an item is four bytes, then after shifting the content of item 209 five items backward (i.e., 20 bytes backward) to yield item 209′, this item 209′ will be located at address 0x9DF771. Bearing in mind that the least significant bytes of the reference item include a value indicative of the referenced item's address, it can be understood that the least significant bytes of the integer representing reference item 208 are 0x9DF785 (that is, item 208 references item 209), and the least significant bytes of the reference item 208′ are 0x9DF771 (i.e., item 208′ references item 209′). The difference between the two integers comprising together an integer replacement pair reflects, therefore, the shift that is performed while updating old version 202 to new version 203. This difference is referred to, hereinafter, as “modification difference”. Modification difference is represented by diff together with the integer modified, such as diff(208).
Thus, instead of associating a pre-modification integer and a post-modification integer in an integer replacement pair, it is possible to associate a pre-modification integer or a post-modification integer with a modification difference. A pair associating a pre-modification integer together with a modification difference is referred to, hereinafter, as “integer shift pair”.
The description with reference to
In the old version, block 504 follows block 503. Six items (505, 506, 507, 508, 509 and 510) are marked within block 504. The addresses where the items begin are marked, hereinafter, as addr(item), e.g., addr(505), addr(506) and addr(507) etc. The blocks 508, 509 and 510 are explicit reference items. The item 509 references item 507, and items 508, 510 reference items 511 and 512 respectively. It is noted that items 511 and 512 are part of the old version, and are located forward to block 504. Thus, the explicit reference items 508, 509 and 510, include values indicative of addr(511), addr(507) and addr(512) respectively.
In the new version 502 the block 504′ corresponds to block 504. As expected, the block 504′ is shifted backwards by size(503). The items 505′, 506′, 507′, 508′, 509′ and 510′ correspond to items 505, 506, 507, 508, 509 and 510 respectively. Like block 504′, the items 505′, 506′, 507′, 508′, 509′ and 510′ are also shifted backwards by s size(503).
Following block 504 the old version 501 includes a block 513 having one item 514 marked therewith. The item 514 is an explicit reference item that references item 506, i.e., the reference item 514 includes a value indicative of the address addr(506). In the new version, block 513′ corresponds to block 513 and item 514′ corresponds to item 514. However, a new block 515 of one or more items is inserted into block 513′, before item 514′. That is, size(513′)>size(513). According to this example, size(515) is smaller than the size(503) and therefore it can be appreciated that item 514′ is shifted backwards by (size(503)−size(515)).
Back to the old version 501, there is a third block 516 following block 513. Five items are marked within this block, specifically these are items 517, 518, 519, 511 and 512. Items 517 and 518 are explicit reference items referencing items 519 and 505, that is, items 517 and 518 include values indicative of the referenced items 519 and 505 or, in other words, indicative of addr(519) and addr(505) respectively.
In the new version, block 516′ corresponds to block 516. Likewise, items 517′, 518′, 519′, 511′ and 512′ correspond to items 517, 518, 519, 511 and 512 respectively. Following the insertion of block 515 to block 513′ it can be appreciated that the items in clock 516′ are shifted backwards by (size(503)−size(515)) items.
The example of
It should be noted that the example provided with reference to
It should also be noted that the size of an item is non-limited as well, but hereinafter, the size of an item in the content illustrated in
A person versed in the art can appreciate that for updating the old version 501 to new version 502, according to one embodiment it is possible to copy block 504 and a first portion of block 514 to the new version, insert the new block 515, and then copy the second portion of block 514 together with blocks 516 and 517 to the new version. However, as was already explained with reference to
Having provided a background discussion of the integer notation embodiment (with reference to
Turning now to
It was further explained, with reference to
It should be noted that the modification difference in an integer shift pair is indicative of the referenced item's shift, and not of the reference item's shift.
In 604 the same portion of the update package is illustrated, where the modification commands are sorted according to the modification differences. It should be noticed that the sorted portion 604 includes two groups. One group includes commands for modifying int(509), int(514) and int(518), wherein the modification difference is size(503). The second group includes commands for modifying int(508), int(510) and int(517), wherein the modification difference is (size(503)−size(515)).
It should be recalled that an integer or part thereof is indicative of a referenced item's address. It should also be considered that while updating a reference item the reference needs to be modified regardless of the op-code or any other information being associated with it. Therefore, in an integer shift pair, instead of referring to an integer it is possible to refer to the value indicative of the referenced item, or to ‘ind(referenced item)’. A pair of ind(referenced item) and its associated modification difference is referred to, hereinafter, as an “indicative shift pair”.
It should be noted that although not shown in
For example, a referenced item's address is 0x5F8B23. Four reference items reference this item by designating its address. The first has an op-code 0xA2, the second has an op-code 0x0F and the third, 0x1B. The forth reference item has an op-code similar to the first (i.e., 0xA2). If the indicative value is represented by the three least significant bytes then all four reference items will be represented as ind(0x5F8B23). On the contrary, when the whole integer is used as an indicative value, there will be three different indicative values representing the four reference items. The first and the forth reference items will be presented as ind(0xA25F8B23), the second will be represented as ind(0x0F5F8B23), and the third as ind(0x1B5F8B23).
Reverting back to
Seeing that the two groups exist also in 605, it is possible to sort each group internally according to the ind(referenced item), and consequently generating 606. Instead of having three modification commands for modifying reference items having values indicative of items in block 504, it is possible to generate one composite modification command to update all the values indicative of items in block 504 to reflect a shift of size(503). In other words, if a reference item includes a value indicative of an item that is between 505 and 507, included, this value should be modified to reflect a shift of size(503). In the same way, instead of having three modification commands for modifying reference items having values indicative of items in block 516, it is possible to generate one composite modification command to update all the values indicative of items in block 516 to reflect a shift of (size(503)−size(515)). In other words, if a reference item includes a value indicative of an item that is between 511 and 519, included, this value should be modified to reflect a shift of (size(503)−size(515)), as illustrated in 607. Such a composite modification command is referenced, hereinafter, as an integer shift rule. That is, 607 demonstrates two integer shift rules that can be applied in order to update the explicit reference items in the example of
Thus, it can be appreciated that the portion 607, using integer shift rules is equivalent to portion 601, using replacement commands. Yet, portion 607 includes only two integer shift rules, instead of six replacement commands that are included in 601. Hence the update package including portion 607 is equivalent to an update package including portion 601. If the space required for storing an integer shift rule is smaller than the space required for storing its equivalent replacement commands, it is possible to reduce the size of an update package by using the equivalent integer shift rule.
The reduction in the update package size can be significant. Considering, for example, a non limiting application of updating version of software on cellular telephones, an integer shift rule can sometimes save even tens of thousands replacement commands.
It should also be noted that instead of using integer shift rules, any numeral shift rule can apply as well, therefore, hereinafter, the term ‘numeral shift rule’ is used.
After converting the replacement pairs to integer replacement pairs the integer replacement pairs are converted (705) to be integer shift pairs, by associating the pre-modification integers together with their modification difference, a stage that was previously exemplified with reference to
After sorting, the pre-modification integers in the integer shift pairs are replaced (707) by the respective referenced items' indicative values to form indicative shift pairs, a stage exemplified before with reference to
If there are groups including more than one indicative shift pairs having the same modification difference, the indicative shift pairs in a group can be joined (710) to form a numeral shift rule indicating the first and last referenced items' indicative values in the group and the modification difference characterizing them, as was previously exemplified with reference to
It is noted that sometimes further optimizations are applicable. For example, if there are two numeral shift rules having the same modification difference, wherein the last referenced item's indicative value of the first rule and the first referenced item's indicative value of the second rule are close enough, the two rules can be joined to form one joined numeral shift rule. The joined numeral shift rule indicates the first referenced items' indicative value of the first numeral shift rule and the last referenced items' indicative value of the second numeral shift rule, together with the modification difference that characterizes them. It should be noted that when two non-adjusting numeral shift rules are joined, the numeral shift rule (or indicative shift pairs) between them are swallowed by the joined rule, and therefore their pre-modification reference items are susceptible to erroneous update (that is, they may be updated to reflect an erroneous shift).
It should be noted that the invention is not bound to the specific sequence of operation and manner of obtaining the integer shift rules as described in
In addition, the embodiments illustrated so far reduce the size of an update package by using numeral shift rules, thus generating a compact update package. It is noted that in those cases using different terminologies to describe an update package such as “delta” or “difference” of “diff”, the compact update package could be named also, e.g., “compact difference results”.
According to a different embodiment, sometimes content can be accompanied by associated descriptive data referred to, hereinafter, as ‘meta-data’. Common forms for providing meta-data are symbol tables, debug tables and linker map used to describe computer programs. However, meta-data is not limited to computer programs and other types of content can have meta-data as well. It should also be noted that associated meta-data can be separated from the content, for example by storing it in a different file or by storing it in a database. Alternatively, the meta-data can be stored as part of the content, as applicable to the case.
When generating an update package intended to update an old version of content to a new version thereof, if meta-data is associated with the content, it is possible to use the meta-data in order to encode modifications to references as will be explained below with reference to
The example and description of
The old version 901 includes four blocks (905, 906, 907 and 708), their respective start addresses are addr(905), addr(906), addr(907) and addr(908). In the new version, a new block 909 of at least one item was added to block 905, thus generating the corresponding block 905′. It can be appreciated that the size of block 905′ is thus bigger than the size of the block 905 by size(909). In addition, unless additional insertions of items to the content or deletions of items from the content further occur during the update process, items forward to the new block 909 are expected to shift forward by size(909).
Forward to block 905′, block 906′ corresponds to block 906, block 907′ corresponds to block 907 and block 908′ corresponds to block 708. A new block 910 of one or more items is inserted also into block 907′. The size of this new block is size(910). Thus, item forward to the new item 910 are shifted forward by (size(909)+size(910)).
In the old version, block 906 includes at least three explicit reference items 911, 912 and 913, referencing items 914, 915 and 916 correspondingly. The referenced item 914 is in block 908, the referenced item 915 is in block 907, and the referenced item 916 is in block 906. In addition, block 908 includes at least one explicit reference item 917 that references item 918. Like the referenced item 915, the referenced item 918 is also in block 907.
The meta-data 9A01 in association with the old version 901 describes the four blocks, their respective start address and their length. The meta-data 9A02 in association with the new version 902 describes the blocks included therein. By comparing meta-data 9A01 with meta-data 9A02 it can be demonstrated that the start address of block 905′ in this case is similar to this of block 905 of the old version. However, the start address of block 906′ equals to (addr(906)+size(909)). Likewise, the start address of block 907, when compared to the start address of block 907 of the old version also reflects a shift of size(909), that is, addr(907′)=addr(907)+size(909). On the other hand, the start address of block 908′ demonstrates a shift of (size(909)+size(910)), that is, addr(908′)=addr(908)+size(909)+size(910).
Whereas the description how to obtain reference shift rules will be described below with respect to the specific example of
It can be appreciated that reference shift rules can be generated in accordance with the difference table 1000. If a reference item references another item in block 906′ for example, and following the information in the difference table, it is possible to appreciate that in the new version its corresponding reference item should be modified to reflect a shift of size(909) in the referenced items location. In the same way if a second reference item references another item in block 908′, it is possible to appreciate that in the new version its corresponding reference item should be modified to reflect a shift of size(909)+size(910) in the referenced items location.
Generally speaking, the difference table reflects therefore reference shift rules. For example, for each referenced item in block 906′ the characteristic shift is size(909). In the same way for each referenced item in block 907′ the characteristic shift is also size(909) whereas for each referenced item in block 908′ the characteristic shift is size(909)+size(910).
It is possible to determine whether a reference item references another item in a certain block in accordance with the blocks' start address and length as indicated in the difference table. Therefore a reference shift rule may be represented by the exemplary notation “Modify<addr(referenced block), size(referenced block)>, shift”.
In the example of
Yet, sometimes, as is known per se, the meta-data does not describe one or more blocks of the content. See for example,
Nevertheless, following the description of the numeral shift rules with reference to
For each block described in the difference table a reference shift rule is being generated (1304). Next reference shift rules referring to adjacent blocks are joined. It should be noted that the invention is not bound to the specific sequence of operation and manner of obtaining the reference shift rules as described in
It should also be noted that the notation used to describe a reference shift rules is non binding and other notations are applicable as well. For example, instead of designating the first item and the length of the block or blocks covered by the rule (in other words, a “section”), it is possible to designate the first and the last items in the section. Note that the latter applies also to numeral shift rules described with reference to
The description above describes embodiments for generating numeral and reference shift rules for updating references in reference items during update of an old version to a new version. It should be noted that the invention is not bound by the specific numeral shift rules and reference shift rules described above. More generally, the term “shift rule” refers to updating of reference items to reflect the shift of reference items in the new version.
Hereinafter, a ‘conversion element’ is the term used to refer to a collection of shift rules associated with an update package. That is, a conversion element can include at least one numeral shift rule, and/or at least one reference shift rule, and/or any other shift rule that can be applied while updating an old version to a new version. Thus, according to the description above, a person versed in the art can appreciate that an update package that contains at least one conversion element is a compact update package.
When applying a conversion element to an old version, it should be appreciated that sometimes reference items can be updated erroneously. For example, consider the example illustrated in
According to an embodiment of the invention referred to, hereinafter, as “one modified” embodiment of the invention and it is possible to apply the conversion element including the reference shift rules of 1001 of
Generally speaking, it is possible to appreciate that while the complete diff detects all the variations that exist between the old and the new versions, including for example, replacement pairs (i.e., shifted explicit reference items as explained above) and other variations such as inserted items and deleted items, the modified diff detects substantially less replacements together with possibly erroneous replacement pairs and together with the other variations. Thus, modified delta is smaller in size compared to the complete delta.
Yet, the modified delta together with the conversion element can constitute together an update package that can update the old version and create a new version thereof. Such an output package, constituted of at least one conversion element and a modified delta, is referred to, hereinafter as a “composite update package”, unlike a “simple update package” that includes a complete delta and no conversion element. Bearing in mind that the conversion element can be smaller in size compared to its equivalent replacement commands, the resulting composite update package is usually smaller in size compared to the simple update package known per se. Therefore, a composite update package is considered hereinafter as a compact update package. According to an embodiment of the invention a compact update package includes at least a conversion element and a modified delta associated therewith.
It is appreciated that by applying the conversion element, and afterwards the modified diff associated with it (“forward conversion order” or in other words, “forward update indicator”) in a compact update package, a new version will be generated wherein items that were erroneously modified by the conversion element will be replaced by the modified delta and amended in a way that their proper content in the new version is received (the procedures for applying update packages are discussed in detail below). However it should be noted that sometimes the modified diff should be applied before the conversion element referred to hereinafter as “backward conversion order”. Backward conversion order shall be explained in detail below.
Yet, it can be illustrated that instead of joining the modified delta to the conversion element to form a compact update package, it is possible to extract additional conversion elements from the modified delta, contributing to the previous conversion element or generating an additional conversion element to be associated together with the previous one and with a delta to form an even smaller compact update package. Thus, another embodiment of the invention, referred to as an “iterations embodiment” is described below, with reference to
In the new version 1402, the blocks 1403′ and 1404′ correspond to blocks 1403 and 1404, while the items 1405′, 1406′, 1407′, 1408′, 1409′, 1410′, 1411′, 1412′, 1413′, 1414′ and 1415′ correspond to items 1406, 1407, 1408, 1409, 1410, 1411, 1412, 1413, 1414 and 1415 respectively. At least one item 1416 was inserted into block 1403′, thus enlarging its size by size(1416), and at least one item 1417, of size(1417) was inserted into block 1404′ backwards to item 1405′.
It should be noted that the content of reference items 1405, 1411 and 1414 are substantially identical, and therefore the content of the corresponding reference items 1405′, 1411′ and 1414′ are substantially identical as well. Similarly, the content of 1406, 1412 and 1414 are substantially identical, and therefore the content of the corresponding reference items 1406′, 1412′ and 1414′ are substantially identical as well.
The items 1405′, 1406′, . . . , 1410′ are explicit reference items, whose content was modified (i.e., their referenced items were shifted) in the new version compared to the old version. The same applies also to the explicit reference items 1411′, 1412′, 1413′ and 1414′. Yet, a diff utility known per se can not recognize that item 1417 is a new item inserted into the new version 1402 while items 1405′, 1406′, . . . , 1410′, . . . are shifted items, and therefore, the diff utility erroneously detects that item 1417 replaces item 1405. Further on the diff utility identifies that item 1415′ is identical to item 1415 (and therefore a copy thereof), and synchronizes to detect (correctly, this time) that item 1411′ replaces item 1411 and so on.
Thus, following a complete diff, a complete delta is generated, indicating (partially erroneously) the following:
Based on this complete delta a conversion element is generated, for example in accordance with the methods illustrated in
Recalling that items 1405, 1411 and 1414 are substantially identical (and so are their corresponding items), as well as items 1406, 1412 and 1414 that are substantially identical (and so are their corresponding items too), and upon detecting that 1411′ replaces 1411 and that 1413′ replaces 1413, the conversion element can estimate that 1405 should be replaced by 1405′. Similarly, by detecting that 1412′ replaces 1412 and 1414′ replaces 1414, the conversion element can estimate that 1406 should be replaced by 1406′.
This conversion element is applied to the old version 1401, generating modified version 1418. It should be noted that the conversion element modified (or converts) several items in the old version, but it does handle any other variation such as deleting and/or inserting items. Therefore, the modified version 1418 is not shifted in relation to the old version 1401.
According to the one modified embodiment of the invention, a modified diff can be utilized, comparing between the modified version 1418 and the new version 1402. The resultant modified delta would recognize the insertion of additional elements, deletion of others and replacement of the rest (amongst are the items 1407, 1408, 1409 and 1410 that where not handled by the conversion element. This modified delta, together with the conversion element, will serve as the basis for generating the compact update package.
Alternatively, according to the iterations embodiment of the invention, instead of generating a compact update package, the modified delta should serve as a basis for generation of additional new conversion elements, for example in accordance with the methods illustrated in
Whereas the iterations embodiment will be describe in general terms below with respect to the flow chart of
Upon start, the method described receives at least an old and a new version of the content to be updated, and meta-data, if available. The two versions and the meta-data serve as the basis for the generation (1501) of a conversion element and for determining (1502) the initial delta size, wherein it can be appreciated that initially the compound conversion element is identical (1503) to the conversion element generated in 1501. The conversion element is applied (1504) to the old version, generating a modified version thereby. Next a modified delta is generated (1505) while utilizing a modified diff on the modified and new version, and the modified delta serves as a basis for generation (1506) of a new conversion element. The size of this new conversion element is determined (1507).
The new conversion element is merged (1508) into the compound conversion element. The size of the new conversion element is determined (1509) and the size of the modified delta (1510).
If the size of the compound conversion element together with the delta size is smaller than the size of the new conversion element together with the size of the modified delta (1511) the new conversion element becomes the conversion element (1512), the delta size becomes the new delta size (1513) and the new conversion element is applied to the modified version (1514) creating a new modified version thereby. Returning to 1505 a new modified delta is created.
However, if on 1511 it is determined that the size of the conversion element together with the size of the modified delta is equal or larger than the size of the compound conversion element together with the delta size, an update package is generated (1515) on the basis of the compound conversion element and the modified delta. Alternatively, on 1511 the stop criterion is met if the compact update package is larger than the compact update package generated in the previous iteration.
It should be appreciated that the iterations embodiment can operate also in the backward conversion order, that is the complete diff is applied between the old version and the new version for generating an initial conversion element, wherein the modified version is created by applying the conversion element on the new version. Next a modified delta is generated between the old version and the modified version for generating a new conversion element and so on.
An update package is marked to indicate the conversion order in accordance with the update package was generated.
It should be noted that the invention is not bound to the specific sequence of operation and manner of generating the update package as described in
Having described the generation of an update package in accordance with various non-limiting embodiments of the invention, there follows a description of using the update package for updating an old version giving rise to a new version. By way of non-limiting example the update package is transmitted through a wireless communication medium and received by cellular telephone device. The cellular telephone device includes a processor configured to process the so received updated package and to update an old version of program and/or data stored therein giving rise to a new version that is stored and operable in the cellular telephone device.
Bearing this in mind, attention is drawn to
After obtaining a compact update package (1601) the conversion element included therein is extracted (1602).
If the update package includes a forward update indicator, as detected on 1603, the conversion element is applied (1604) to the old version, generating a modified version. Then the modified delta is extracted (1605) from the update package and applied (1606) to the modified version. On the other hand, if it is found on 1603 and 1607 that the update package includes a backward update indicator, the modified delta is first extracted (1605) and applied (1606) to the old version generating a modified version on which the conversion element is then applied (1608). In both cases the result is the new version.
It will also be understood that the system according to the invention may be a suitably programmed computer. Likewise, the invention contemplates a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.
The present invention has been described with a certain degree of particularity, but those versed in the art will readily appreciate that various alterations and modifications may be carried out, without departing from the scope of the following claims:
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5752039 *||Mar 22, 1994||May 12, 1998||Ntt Data Communications Systems Corp.||Executable file difference extraction/update system and executable file difference extraction method|
|US5832520 *||Nov 22, 1996||Nov 3, 1998||Miller, Call, Plauck And Miller||Automatic file differencing and updating system|
|US6546552||Aug 18, 1999||Apr 8, 2003||Red Bend Ltd.||Difference extraction between two versions of data-tables containing intra-references|
|US6748584||Dec 29, 1999||Jun 8, 2004||Veritas Operating Corporation||Method for determining the degree to which changed code has been exercised|
|US6925467 *||May 13, 2002||Aug 2, 2005||Innopath Software, Inc.||Byte-level file differencing and updating algorithms|
|EP0752794A2||Jun 17, 1996||Jan 8, 1997||Fujitsu Limited||Cross-connect device for optical networks|
|1||Baker, B.S. et al. "Compressing Differences of Executable Code", WCSSS'99 ACM Sigplan Workshop on Compiler Support for System Software Inst., pp. 1-10, 1999.|
|2||Hunt, J.J. et al. "An Empirical Study of Delta Algorithms", Software Configuration Management. ICSE SCM Workshop, pp. 49-66, 1996.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8407688 *||Nov 27, 2007||Mar 26, 2013||Managelq, Inc.||Methods and apparatus for storing and transmitting historical configuration data associated with information technology assets|
|US8612971||Oct 17, 2006||Dec 17, 2013||Manageiq, Inc.||Automatic optimization for virtual systems|
|US8752045||Nov 27, 2007||Jun 10, 2014||Manageiq, Inc.||Methods and apparatus for using tags to control and manage assets|
|US8762980 *||Sep 9, 2010||Jun 24, 2014||Symantec Corporation||Rolling incremental updates|
|US8832691||Jun 7, 2012||Sep 9, 2014||Manageiq, Inc.||Compliance-based adaptations in managed virtual systems|
|US8839246||May 3, 2013||Sep 16, 2014||Manageiq, Inc.||Automatic optimization for virtual systems|
|US8850433||Jun 7, 2012||Sep 30, 2014||Manageiq, Inc.||Compliance-based adaptations in managed virtual systems|
|US8924917||Mar 20, 2013||Dec 30, 2014||Manageiq, Inc.||Methods and apparatus for storing and transmitting historical configuration data associated with information technology assets|
|US8949825||Oct 17, 2006||Feb 3, 2015||Manageiq, Inc.||Enforcement of compliance policies in managed virtual systems|
|US8949826||Nov 27, 2007||Feb 3, 2015||Managelq, Inc.||Control and management of virtual systems|
|US9015703||Nov 27, 2007||Apr 21, 2015||Manageiq, Inc.||Enforcement of compliance policies in managed virtual systems|
|US9038062||Nov 27, 2007||May 19, 2015||Manageiq, Inc.||Registering and accessing virtual systems for use in a managed system|
|US9043275||May 14, 2012||May 26, 2015||International Business Machines Corporation||Data synchronization using string matching|
|US9052978 *||Jul 24, 2013||Jun 9, 2015||Oracle International Corporation||Applying hot fixes for metadata customizing user interactions based on a software program deployed in multiple versions|
|US9086917||Oct 17, 2006||Jul 21, 2015||Manageiq, Inc.||Registering and accessing virtual systems for use in a managed system|
|US20150033216 *||Jul 24, 2013||Jan 29, 2015||Oracle International Corporation||Applying hot fixes for metadata customizing user interactions based on a software program deployed in multiple versions|
|U.S. Classification||707/638, 717/169, 717/168, 707/609, 717/172, 717/170|
|International Classification||G06F9/445, H03M7/30, G06F7/00, G06F9/44|
|Cooperative Classification||G06F8/68, H03M7/30, G06F8/665|
|European Classification||H03M7/30, G06F8/68, G06F8/665|
|Jun 23, 2004||AS||Assignment|
Owner name: RED BEND LTD., ISRAEL
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MELLER, EVYATAR;PELEG, SHARON;REEL/FRAME:015510/0621
Effective date: 20040617
|Mar 12, 2007||AS||Assignment|
Owner name: PLENUS II, LIMITED PARTNERSHIP,ISRAEL
Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161
Effective date: 20070312
Owner name: PLENUS II (D.C.M.), LIMITED PARTNERSHIP,ISRAEL
Free format text: LIEN;ASSIGNOR:RED BEND LTD.;REEL/FRAME:018993/0161
Effective date: 20070312
|Apr 16, 2009||AS||Assignment|
Owner name: MUSTANG MEZZANINE FUND LP,ISRAEL
Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:022551/0826
Effective date: 20090407
Owner name: RED BEND LTD.,ISRAEL
Free format text: RELEASE OF LIENS;ASSIGNORS:PLENUS II, LIMITED PARTNERSHIP;PLENUS II (D.C.M.), LIMITED PARTNERSHIP;REEL/FRAME:022552/0037
Effective date: 20090407
|Sep 20, 2010||AS||Assignment|
Owner name: MUSTANG MEZZANINE FUND LP, ISRAEL
Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:025008/0297
Effective date: 20100916
|May 31, 2011||CC||Certificate of correction|
|Aug 22, 2012||AS||Assignment|
Owner name: MUSTANG MEZZANINE FUND LP, ISRAEL
Free format text: SECURITY AGREEMENT;ASSIGNOR:RED BEND LTD.;REEL/FRAME:028831/0963
Effective date: 20120725
|Jun 19, 2014||FPAY||Fee payment|
Year of fee payment: 4
|Mar 4, 2015||AS||Assignment|
Owner name: RED BEND LTD., ISRAEL
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:MUSTANG MEZZANINE LP;REEL/FRAME:035083/0471
Effective date: 20150226