fig1 shows in a flowchart a computer enabled process for creating integrity verification information so as to protect a computer file or part thereof in accordance with the invention . this process itself would be embodied in computer software , for instance using whatever computer language is used by the other application software being run on the host device such as other drm code . it is assumed at step 10 that the information to be protected ( a message which is data or computer code for instance ) is pre - existing . at 12 , the information is conventionally rendered into numerical ( digital , typically binary ) form ; this would correspond in one embodiment to rendering the alphanumeric source code of a computer program into compiled binary form . this process is applied to the compiled code , in its binary form . the tool ( program ) used to generate the integrity information takes the binary code file as input , and some debugging information or a link map to know where each part of the alphanumeric code is located in the binary code . for example , assume a media player program is composed of the following source code files : gui . c ( source code for the visual effects ) io . c ( source code for file / network interactions ) drm . c ( source code to handle decryption of content ) decoder . c ( source code to actually decode audio / video data ) the compiler / linker takes all those source code files as input and generates files player . exe and player . map . file player . exe contains the generated program in its binary form , player . map contains a link map , generated by the linker which tells where each part of the code is located in memory or in the binary . note that instead of the map file , one could also use debugging information generated by the compiler , embedded in the binary usually . now , assume the designer does not care if the input / output code or the gui ( graphical user interface ) code is modified , but does care if the drm code or the decoder code is , since that is much more important from a security standpoint . the designer creates two rules , the first one is to checksum ( or hash ) any code that belongs to the file drm . c , and the second one is to checksum ( or hash ) any code that belongs to the file decoder . c . here the rule is based on the file name , but it could also be based on the function name . for example , a rule could be to checksum only the function “ foo ” in the file drm . c . rules are based on the filename , or the function names . a rule can also be a regular expression that will match several filenames of several function names . the tool generating the integrity information parses the player . exe file , and helped by the map file or the debugging information , it identifies all the part of the code that need to be checksummed or hashed . for example , if the map files says that function “ foo ” in file drm . c is mapped at address 0x10000 and is 144 bytes long , the generating tool will parse the player . exe file locate those 144 bytes and will checksum them . another useful rule is to limit the maximum length of the portion to be subject to the checksum or hash , to enhance performance ( reducing processing time ). at 16 , the selected binary information ( e . g ., a file ) is partitioned into portions ( blocks , but not of fixed length ), and a first portion here designated pi is selected . the length of each portion is set to vary . hence both the selection of which portions ( or files ) are to be subject to the remainder of the process , and the length of each portion as determined at 18 , are decided by the person performing the process ( typically a computer software engineer ), according to some predetermined criteria or rules . note that the length of each portion varies , in some hard to predict way , to make it difficult to “ crack ” by hackers . the length of each portion is defined as some number of bits ( or bytes or other convenient unit ), here designated li . next at 20 , those li bits of portion pi are accessed . in 24 , the predetermined checksum or hash function is applied to all the li bits of pi , to calculate the checksum or hash value ci . next at 26 , an integrity verification ( iv ) file is created with a number of entries , one for each portion pi . each entry ( or ‘ tuple ’ or vector in computer nomenclature ) has three parts ( fields ): the address in the memory of the beginning of pi , the length li of pi , and the checksum or hash value ci . then at 28 , the value of i is incremented , and the process reentered at step 12 , until the entire message / code file has been so processed . thus the integrity verification file consists of all the concatenated iv vectors , which file then is stored . note that software ( code ) takes two main forms : source code , which is the alpha - numeric form as written by programmers and which is intelligible to people , and binary or object code , which is the compiled form of the source code and actually executed by a computer or processor . since as described above , the human programmer decides which code portions are to be provided with integrity verification , he makes that decision based on the source code version , but the integrity verification process then must be applied to the binary version . thereby , in accordance with the invention , a mapping between the source and binary code is provided , as part of the above process . there are several ways to do this , but exemplary well known methods use a link map or debugging symbols , which show explicitly where each part of the source code has been linked in the binary code . the programmer can use a map file or debugging information . the map file is generated by the linker ( id or link . exe for example ) and is stored on the computer hard disk usually . it is not created by the integrity verification tool . the map is only used for debugging purposes usually , and is not used by the compiler . most of the time it is not used at all , and linkers usually do not generate one by default . using it , software engineers can identify where in the source code a fault occurred for example . function initsharedglobals , at offset 0x009f86e0 in the text section of the binary is located at address 0x6e9f96e0 and is part of the stdplayerroutines . c [ pp ] file , compiled in the stdplayer sub module . function drawstatusstuff , at offset 0x009f9470 in the text section of the binary is located at address 0x6e9fa470 and is part of the stdplayerroutines . c [ pp ] file , compiled in the stdplayer sub module . if debugging information is used instead of the link map , then the same kind of deductions can be performed by parsing it . the debugging information can be embedded in the binary code or in a separate file ( for respectively , for instance , the apple mac and other operating systems or the windows operating system ). for each platform , the debugging information has a well known format ( pdb for windows , dwarf or stabs for the mac os ). the debugging information is generated by the compiler , whereas the link map is generated by the linker . the entity that carries out the process of fig1 is itself software code ; so obviously it must be kept absolutely secure from hackers , and so typically would only be provided to those people entrusted with establishing security of the associated code , such as the drm . the selection of the rules as to which code files or portions are subject to the fig1 process may be arbitrary ; for instance , the person using the process may decide to use it only for the more critical parts of the drm . the associated apparatus which carries out the fig1 process ( typically a combination of conventional computer hardware and software elements ) is shown in fig2 and is typically part of a conventional computer , used by the programmer or software engineer who is rendering the integrity verification on software code . fig2 ( like fig3 ) is of course only exemplary of a suitable apparatus . the message / code storage 30 is typically non - volatile memory such as a disk drive or flash memory resident in a conventional computer , the other conventional components of which are not shown for simplicity . note the message / code storage 30 generally does not contain any source code . at this point , it only contains the binary code form of the program , with a link map or debugging symbols . the source code is not needed to generate the iv file . the source code is only needed by the programmer to create the rules that will be used by the iv tool . storage 30 thus holds for instance the compiled ( binary ) code for which the programmer wants to provide integrity verification , and as pointed out this may be other data ( a message ) instead of code . portion selector 32 is logic which downloads a first part pi of the code from storage 30 , under particular rules or decisions provided by the programmer . the rules or programmer also indicate the length li of each portion or block to be operated on , by means of portion length selector 36 . the relevant portion pi , of length li , is then held in portion buffer 40 , and loaded into checksum / hash calculator 46 to provide the checksum / hash value ci . value ci is then loaded into the ci field of iv entry ( tuple or vector ) buffer 48 , the other fields of which are similarly loaded with values li and the beginning address in storage 30 of portion pi . then , the entire contents of buffer 48 are loaded in the iv file store 50 , concatenated with all such earlier determined iv vectors . fig3 shows the complementary process and apparatus as carried out in for instance a media player or other type of playback apparatus ( such as a computer , cell phone , or pda ) as part of the drm scheme when the player is operating to play or download content subject to the present integrity verification protection . hence fig3 illustrates what would typically be carried out by a combination of relevant parts of the drm code with the hardware conventionally present in the playback apparatus , the other parts of which are conventional and not illustrated . note that the drm code typically also includes many other protective features and aspects which are not shown , such as the conventional cryptographic protection mentioned above . in fig3 , the playback apparatus includes a message ( or code ) storage 60 , typically non - volatile memory , holding the protected code , for instance drm code in compiled form . associated with this is a storage 62 for the iv file . the contents of storage 62 are of course provided from storage 50 in fig2 . when the relevant code in storage 60 is to be executed , it is conventionally downloaded to e . g . random access memory associated with the processor which actually executes the code . at the same time , the first entry in iv file storage 62 is loaded into iv tuple ( vector ) buffer 64 , with the three fields for each entry ( vector ) as in fig2 . portion selector logic 68 reads the first two fields which are the address and length value li , and proceeds to access message storage 60 to extract the code ( of course , in compiled or binary form ) form located beginning at that address and the next li bits from storage 60 . this downloaded code is then loaded in to portion buffer 70 , and transferred to checksum / hash calculator 74 which carries out the same operation as calculator 46 in fig2 , to determine the value ci . this value ci is then loaded into checksum comparator 76 , to be compared with the other value ci provided from buffer 64 . if the values of ci match , the integrity of the code portion is verified , and the code is executed ; if the match fails , the code has been tampered with , so execution is prevented . as well known in the computer field , a binary file may be subject to relocation in memory . for example , assume that software libraries a and b are both designed to load at particular address , and are both position dependent . as well known , position dependent means that the addresses are absolute in computer memory , not relative to a start address . a library in this context means a collection of subprograms used in modular fashion . typically a library includes helper code and data . if a particular program is using both libraries a and b at the same time , then one of them must be moved in terms of its memory address . in order to move it , the host device &# 39 ; s operating system must modify the code of the moved library dynamically . this of course would alter the computed checksum / hash value , hence it would cause the iv match to fail . to avoid this , the verification process of fig3 is made to be relocation aware ; so it includes a conventional step ( not shown ) that detects if such a relocation has taken place . if yes , the binary code is by a conventional step restored back to its original form before computing the checksum / hash value . this disclosure is illustrative and not limiting ; further modifications will be apparent to one skilled in the art in light of this disclosure , and are intended to fall within the scope of the appended claims .