Electrically erasable and programmable memory that allows data update without prior erasure of the memory

[0002] This is a continuation of application Ser. No. 08/565,645, filed Nov. 29, 1995, now abandoned.

[0003] The present invention pertains to the field of memories. More particularly, this invention relates to an apparatus and a method for allowing data update in an electrically erasable and programmable memory without prior erasure of the memory.

[0004] One type of prior art nonvolatile memory is a flash Erasable and electrically Programmable Read-Only Memory (“flash EPROM”). A typical flash EPROM has the same array configuration as a standard Electrically Programmable Read-Only Memory (“EPROM”) and can be programmed in similar fashion as EPROM. Once programmed, the entire contents of the flash EPROM can be erased by electrical erasure in one relatively rapid operation. A high erasing voltage is made available to the sources of all the cells in the flash EPROM or in one block of the flash EPROM simultaneously. This results in a full array erasure or block erasure. The flash EPROM or the erased block of the flash EPROM may then be reprogrammed with new data.

[0005] Flash EPROMs differ from conventional Electrically Erasable Programmable Read Only Memory (“EEPROMs”) with respect to erasure. Conventional EEPROMs typically use a select transistor for individual cell erasure control. Flash EPROMs, on the other hand, typically achieve much higher density with single transistor cells. As described above, during the erasure of the flash EPROM, a high voltage is supplied to the sources of all memory cells in a memory array or a block of the memory array simultaneously. This results in a full array erasure or block erasure.

[0006] For a prior art single bit flash EPROM, a logical “one” means that few, if any, electrons are stored on a floating gate associated with a bit cell. A logical “zero” means that many electrons are stored on the floating gate associated with the bit cell. Erasure of the flash EPROM causes a logical one to be stored in each bit cell. Each single bit cell of the flash EPROM cannot be overwritten from a logical zero to a logical one without a prior erasure. Each single bit cell of that flash EPROM can, however, be written from a logical one to a logical zero, given that this entails simply adding electrons to a floating gate that contains the intrinsic number of electrons associated with the erased state.

[0007] One disadvantage of the flash EPROM, however, is that each single bit cell cannot be overwritten from the logical zero to the logical one without a prior erasure. Another disadvantage of the flash EPROM is that it must be erased—i.e., reset to the logical one state—in large blocks or in a manner that erases the entire device.

[0008] Another disadvantage of the flash EPROM is that there is a finite limit on the number of erase and write cycles for the flash EPROM before the flash EPROM will fail.

[0009] The limitations with respect to overwriting and erasure associated with the flash EPROMs have, in certain instances, limited the usefulness of the flash EPROMs.

[0010] One of the features of the present invention is to allow an electrically erasable and programmable memory to emulate a random access memory (RAM).

[0011] Another feature of the present invention is to provide an arrangement that allows a block-erasable nonvolatile memory to have byte alterability feature.

[0012] A further feature of the present invention is to provide apparatus and a method for updating data stored in an electrically erasable and programmable nonvolatile memory without a prior erasure of the memory.

[0013] Described hereinafter is a processor-implemented method for updating a datum stored in a nonvolatile memory, bits of which cannot be overwritten from a first logical state to a second logical state without a prior erasure of the memory. The method includes the step of accessing a first storage location in the memory that stores a first version of the datum. A status field of the first storage location is checked to determine whether the first version of the datum has been superseded. If the status field of the first storage location indicates that the first version of the datum has not been superseded, then a most recent version of the datum is stored in a second storage location of the memory. An address of the second storage location is written into a next location address field of the first storage location. The status field of the first storage location is then written to indicate that the first version of the datum has been superseded such that the datum is updated without the prior erasure of the memory.

[0014] An apparatus for storing a datum is also described that includes a processor and a nonvolatile memory having a first and a second processor-allocated storage location, each including memory cells that cannot be overwritten from a first logical state to a second logical state without a prior erasure of the memory. The first processor-allocated storage location further includes a data field that stores a version of the datum, a status field indicating whether the version of the datum stored in the data field has been superseded by an updated version of the datum stored in the second storage location of the memory, and a next pointer field that stores an address of the second processor-allocated storage location that stores the updated version of the datum such that the datum is updated in the memory without the prior erasure of the memory.

[0015] The present invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

[0016] FIG. 1 shows a block diagram of a flash EPROM;

[0017] FIG. 2 shows the memory map of the memory array of the flash EPROM of FIG. 1;

[0018] FIG. 3A shows a data storage system having the flash EPROM of FIGS. 1 and 2 and a processor for executing an application program to read and write data to and from the flash EPROM in accordance with one embodiment of the present invention;

[0019] FIG. 3B shows the data structure of a block of the memory array of the flash EPROM of FIGS. 1 and 2 in accordance with one embodiment of the present invention;

[0020] FIG. 3C shows how parameters are updated and stored in a block of the flash EPROM that has the data structure of FIG. 3B;

[0021] FIG. 4 shows a flow chart of a write process of the application program in accordance with one embodiment of the present invention;

[0022] FIG. 5 shows in flow chart diagram form a read process of the application program in accordance with one embodiment of the present invention;

[0023] FIG. 6 shows in flow chart diagram form a block transfer process of the application program in accordance with one embodiment of the present invention;

[0024] FIGS. 7A and 7B show an initialization process of the application program in accordance with one embodiment of the present invention;

[0025] FIG. 8 is a table that lists a combination of block status of two blocks during initialization.

[0026] FIG. 1 is a block diagram of a flash EPROM 10. Flash EPROM 10 implements a data storage and update structure that allows data to be updated without prior erasing the memory in accordance with one embodiment of the present invention.

[0027] Flash EPROM 10 can be used in any kind of computer systems or data processing systems. The computer system can be a personal computer, an embedded engine control system used in a machine or automobile, a notebook, a laptop, a personal assistant, a minicomputer, a workstation, a mainframe, a multiprocessor computer, or any other type of computer system. In addition, the system in which flash EPROM 10 is used can be a printer, a cellular phone, a modem, a digital answering system, or any other data storage system.

[0028] Flash EPROM 10 includes a memory array 11 and row and column decoders 13 and 14 coupled to memory array 11. Column decoder 14 is coupled to memory array 11 via a column gating circuit 12.

[0029] Flash EPROM 10 also includes a memory controller circuit 15. Controller circuit 15 controls the memory operations of flash EPROM 10. The memory operations of flash EPROM 10 include read, programming, and erasure operations. Controller circuit 15 receives addresses from external circuitry (not shown) via address pins 19. Controller circuit 15 also receives the data to be written to memory array 11 from the external circuitry and sends the data read from memory array 11 to the external circuitry via data pins 18. Data pins 18 also supply the device operation commands to controller circuit 15. Controller circuit 15 can be implemented by any known flash EPROM memory control circuit.

[0030] Controller circuit 15 receives four control signals via their respective pins. These control signals are a chip enable control signal {overscore (CE)}, an output enable control signal {overscore (OE)}, and a write enable control signal {overscore (WE)}. These control signals are also known in the art and will not be described in more detail below.

[0031] The V_PPpin receives the program/erase power supply voltage V_PPfor flash EPROM 10. The V_CCpin receives the device power supply voltage for flash EPROM 10 and V_SSis ground.

[0032] Memory array 11 includes a number of blocks (not shown in FIG. 1), each can be electrically erased. In one embodiment, the blocks of memory array 11 are organized as bit line blocks. This is done by arranging bit lines of memory array 11 into groups. In another embodiment, the blocks of memory array 11 are organized as word line blocks. This is done by arranging word lines of memory array 11 into groups.

[0033] Each block of memory array 11 includes a number of floating gate memory cells, each of which can be electrically programmed from a logical “one” state to a logical “zero” state. Each of the memory cells, however, cannot be electrically programmed from the logical zero state to the logical one state. The memory cells of memory array 11 or of one block of memory array 11 can be electrically erased from the logical zero state to the logical one state. In other words, each of the memory cells in memory array 11 or a block of the memory array cannot be overwritten from the logical zero state to the logical one state without a prior erasure operation of the entire memory array 11 or the block.

[0034] FIG. 2 shows a memory map 24 of memory array 11 of flash EPROM 10 of FIG. 1. As can be seen from FIG. 2, memory map 24 shows that memory array 11 includes a code block 28, two parameter blocks 26 and 27 and a number of main blocks 25 through 25n.Code block 28 typically stores program codes that require the least updating. Parameter blocks 26 and 27 typically store frequently updated parameters. Main blocks 25-25nstore other program codes or data.

[0035] FIG. 2 shows one embodiment of arranging memory array 11 into blocks. Alternatively, memory array 11 may include more or fewer than two parameter blocks and more than one code block, but the number of parameter blocks in memory array 11 need to be symmetrical (i.e., paired).

[0036] The codes stored in code block 28 include a flash EPROM updating application program that, in combination with structures in parameter blocks 26 and 27, implements one embodiment of the present invention. The updating application program updates parameters stored in parameter blocks 26 and 27 without prior erasing blocks 26 and 27. The updating application program is executed by an external processor 61 (see FIG. 3A) when flash EPROM 10 is connected to processor 61 to form a data storage and management system 60.

[0037] As can be seen from FIG. 3A, processor 61 is connected to flash EPROM 10 via buses 63 through 65. Processor 61 includes a RAM buffer 62. Alternatively, RAM buffer 62 can be an individual RAM chip connected to but separated from processor 61. Processor 61 is also connected to other circuits (not shown). This means that data storage and management system 60 can be part of a control or processing system (not shown).

[0038] Processor 61 can be any known processor or microcontroller. In one embodiment, processor 61 is a general purpose processor. In another embodiment, processor 61 is a memory controller. In one embodiment, processor 61 and flash EPROM 10 reside on a single semiconductor substrate. In another embodiment, processor 61 does not reside on the same semiconductor substrate as flash EPROM 10.

[0039] Before processor 61 starts to read or write parameters from or to flash EPROM 10, processor 61 loads the updating application program from code block 28 (see FIG. 2) of flash EPROM 10 into RAM buffer 62 through the read operation of flash EPROM 10. Processor 61 then executes the updating application program from RAM buffer 62 to read from and/or write to flash EPROM 10. The updating application program is described in more detail below, also in conjunction with FIGS. 4 through 8.

[0040] Referring back to FIG. 2, in order for the updating application program to update parameters stored in parameter blocks 26 and 27 without a prior erasure of each of the blocks, each of parameter blocks 26 and 27 is structured to include a block header, a first instance jump table, and a parameter entry structure in accordance with one embodiment of the present invention. These structures in each of parameter blocks 26 and 27 help the updating application program to update parameters stored in blocks 26 and 27 without a prior erasure of the blocks. FIG. 3B shows the structures within a parameter block 30, which will be described in more detail below. Parameter block 30 can be either parameter block 26 or 27 of FIG. 2.

[0041] Referring to FIG. 3B, parameter block 30 includes a jump table section 31 and parameter entry section 32 located adjacent to jump table section 31. Jump table 31 includes a block header 31aand a number of location offset entries, each having one word length. Block header 31astores information regarding the block. Each of the location offset entries in jump table 31 stores an offset address of a parameter entry that stores the first instance of a parameter in parameter entry section 32. The offset address indicates the offset position of that parameter entry from a start address of parameter entry section 32 of block 30. As can be seen from FIG. 3B, the start address points at parameter entry 32a.FIG. 3B only shows two location offset entries 31band 31c.

[0042] FIG. 3B also shows the structure of block header 31a.As can be seen from FIG. 3B, block header 31 a includes a status field 40, a checksum field 41 and a block number field 42. In one embodiment, status field 40 is one byte long. Each of checksum field 41 and block number field 42 is half byte long. Status field 40 is used to indicate the status of block 30. Because status field 40 includes eight bits that can be individually written from the logical one state to the logical zero state, status field 40 can be written eight times to indicate eight different block status of block 30. A table is shown below that lists different status values of status field 40 and their corresponding status definitions.

[0043] Initially (i.e., after block 30 has been erased), status field 40 stores the “FF” value (i.e., all the bits of status field 40 are at logical one level). Then the user can write to status field 40 by individually programming one bit at a time without erasing status field 40. As can be seen from the above Table, when the user changes the status value of status field 40 from “FF” to “7F”, block 30 is indicated as receiving data from another parameter block during a block transfer operation or from the external circuit. When the value of status field 40 is changed to “3F” from “7F”, it indicates that block 30 currently holds valid data. This status value will not change until the storage space of the block is filled up and all valid parameters are transferred to another block, at which time the value is changed to “1F” from “3F”. By this arrangement, the status value stored in status field 40 can be changed without prior erasing the block.

[0044] Alternatively, status field 40 is only written once from the “FF” value to the “3F” value to indicate block 30 stores data (i.e., is a valid block). In this case, status field 40 either indicates that block 30 is an erased block (i.e., stores the “FF” value) or a valid block (i.e., stores the “3F” value). This technique is used to ensure that recovery is possible by knowing the latest operation of the block in the event of power loss.

[0045] Block number field 42 stores the sequential number of parameter block 30 within the parameter blocks of flash EPROM 10. As described above in connection with FIG. 2, flash EPROM 10 includes two parameter blocks 26 and 27. Therefore, the sequential number stored in field 42 indicates whether the block is a first parameter block or a second parameter block. This allows the updating application program to access the parameter blocks 26 and 27 in order in accordance with their sequential numbers. When used with the value stored in checksum field 41, the sequential number stored in block number field 42 also enables the system to determine the validity of status field 40 of the block. Checksum field 41 stores the complement value of the sequential number stored in block number field 42. When the value stored in field 41 is exclusive ORed with the value stored in field 42 to be equal to a predetermined value (i.e., FF), it indicates that block 30 is a valid block. If not, it indicates that block 30 does not contain valid data even if the status value stored in status field 40 indicates otherwise. This also allows data corruption of block 30 by removal of system power during the erasure operation of block 30 to be detected. Block 30 is a corrupted block when power supply is removed from flash EPROM 10 during erasure of block 30.

[0046] Jump table 31 includes an array of entries the number of which depends on the number of parameters the user can store in block 30. In one embodiment, jump table 31 includes 256 entries. This means that parameter entry section 32 of block 30 can store 256 parameters though it can store several instances of each parameter until all storage space in this section of the block is used up. If the value of an offset entry is “FF” (i.e., all the bits of the entry are logically high), that entry has not yet been written and the corresponding parameter has not yet been stored in parameter block 30. If the value of a location offset entry is not equal to “FF”, then the entry has been written and the value stored indicates the offset location into parameter entry section 32 of the block at which the first instance (or version) of the parameter is stored. Updates of that parameter can then be conducted in block 30 through the parameter entry structure and the updating application program (both will be described in more detail below) without the prior erasure of block 30 before the updates.

[0047] Alternatively, block 30 does not have location offset entries in jump table 31. In this case, only block header 31aand parameter entries 32 exist in parameter block 30. When this occurs, the user can access the parameter entry that stores the first instance of a parameter using the physical address of that parameter. The physical address of a parameter always points to the parameter entry that stores the first instance of the parameter.

[0048] Because memory cells of flash EPROM 10 cannot be overwritten from the logical zero state to the logical one state without a prior erasure of the memory, each of the parameter entries in parameter entry section 32 of block 30 cannot store an updated version of a parameter once that parameter entry has been written with a prior version (or instance) of the parameter. An erasure operation is required for block 30 before that parameter entry is capable of storing the updated version of the parameter.

[0049] In order for a parameter stored in block 30 to be updated without prior erasing the block, a new parameter entry is required to store the updated version of the parameter. The new parameter entry storing the updated version is also required to link to the parameter entry that stores the to-be-superseded version of the parameter. In doing so, a linked list of parameter entries can be established for the parameter throughout updates of the parameter (see FIG. 3C). For example, as can be seen from FIG. 3C, when the version of parameter 10 stored in parameter entry 66 is to be superseded by a newer version of the parameter, the newer version of parameter 10 is stored in parameter entry 67 which is the next available parameter entry in parameter entry section 32.

[0050] In addition, parameter entry 66 is then marked to indicate that particular version of the parameter has been superseded by the newer version stored in parameter entry 67. This therefore causes each of the parameter entries in parameter entry section 32 to have certain structure. FIG. 3B shows the structure of each of the parameter entries in parameter entry section 32.

[0051] As can be seen from FIG. 3B, each parameter entry includes a status field (i.e., status field 50), a parameter value field (i.e., parameter value field 51), and a next pointer address field (i.e., field 53). In addition, each parameter entry may also include a field storing data regarding the size of the parameter entry (i.e., size field 52). The size field 52 is typically required when each parameter entry has a variable size. When each parameter entry in parameter block 30 has the same size, the size field 52 is not needed in each parameter entry.

[0052] In one embodiment, status field 50 is one byte long and each of parameter value field 51 and next pointer address field 52 is one word (i.e., two bytes) long. Alternatively, when each of parameter entries is of variable size, the length of parameter value field 51 may vary while other fields of the parameter entry remain fixed.

[0053] Status field 50 of each parameter entry stores the status value that indicates status of the parameter entry. A table is shown below that lists different status values of status field 50 and their corresponding definitions.

[0054] As can be seen from Table II above, when the status field of a parameter entry stores the “FF” value, it indicates that the parameter entry is an erased entry and has not been used to store a parameter. When the parameter entry is used to store a parameter, its status field is then written with the “7F” value. This is accomplished by programming the most significant bit of the status field to logical zero. When the parameter value stored in the parameter entry is to be updated with a newer version of the parameter, the status field of that parameter entry is again written with the value “3F” to indicate that the parameter value stored in the corresponding parameter value field is being updated. This write operation of the status field is accomplished by programming the second most significant bit of the status field to logical zero. When the newer version of the parameter has been stored in an unused parameter entry, the status field of this parameter entry is then written with the “1F” value to indicate that the parameter value stored in this parameter entry has been superseded. Again, this write is accomplished by programming the next most significant bit of the status field to logical zero.

[0055] The next pointer address field (i.e., field 53) of a parameter entry stores the address of the next parameter entry (or instance) that stores the newer version of the parameter. When the status field of a parameter entry is changed to the superseded status value, the next pointer address field of that parameter entry stores the address of the next parameter entry that stores the updated version of the parameter. For example and as can be seen from FIG. 3C, when the version of parameter 10 stored in parameter entry 67 updates the version of the parameter stored in parameter entry 66, the next pointer address field (not shown in FIG. 30) of parameter entry 66 stores the address of parameter entry 67. Parameter entry 67 retains a default condition (i.e., FF value) in its next pointer address field, indicating that this entry stores the most recent version of the parameter. In doing so, the parameter entries that store different versions of the same parameter can be linked together such that the parameter entry that stores the most recent version of the parameter can be found through the link and the parameter can be updated usually at any time without prior erasing the block.

[0056] As described above, FIGS. 4 through 8 show various processes of the updating application program for updating parameters in the parameter blocks of flash EPROM 10 having structures described above in connection with FIGS. 2 and 3B-3C. As described above, the updating application program and the structures described above for the parameter blocks implement one embodiment of the present invention.

[0057] Referring now to FIG. 4, the write process of the updating application program starts at step 70. FIG. 4 shows how the updating application program updates a parameter stored in a parameter entry of a block of flash EPROM 10.

[0058] At step 71, a parameter is received with its parameter number. Each parameter has its own parameter number and the parameter number of a parameter distinguishes the parameter from other parameters. At step 72, the status field of the block header of a block is checked. As described above, flash EPROM 10 includes two parameter blocks. Therefore, the updating application program needs to be set to check the block header of one of the two blocks first. Here, the updating application program is set to check the block with the lowest block number first. Alternatively, the updating application program can be set to check the status field of the parameter block with the highest block number first.

[0059] At step 73, it is determined if the value obtained from the status field of the block header of the block is equal to the “3F” value (i.e., whether the block is valid). If so, the process goes to step 77. If not, the process proceeds to step 74 to find a next available block.

[0060] At step 74, the status field of the block header of the next block is checked. At step 75, the value obtained from the status field of the next block is determined to find out if it is equal to “3F”. If so, the process proceeds to step 77. If not, the process ends at step 76.

[0061] At step 77, it is determined if there is any unused parameter entry (i.e., erased parameter entry) in the block. If the answer is no, then step 78 is performed at which the block transfer operation is performed to transfer the most recent version of each of the parameters to the other block. FIG. 6 shows the process of the block transfer operation, which will be described in more detail below. The process then goes to step 79.

[0062] If, at step 77, it is determined that there is at least one unused parameter entry in the block, then step 79 is performed. At step 79, it is determined if the parameter has a location offset entry in the jump table. If the answer is no (i.e., the parameter has not been stored in the block before an this is the first instance of the parameter to be stored in the block), then step 80 is performed to store the parameter in the allocated unused parameter entry. In addition, the offset address of that parameter entry is then stored in an offset entry of the jump table at step 80. In doing so, the jump table contains the address pointing to the parameter entry that stores the first instance of the parameter. The process then goes to step 85.

[0063] If, at step 79, it is determined that the parameter has an entry in the jump table, then step 82 is performed at which the parameter entry that stores the most recent version of the parameter is first located through the offset address stored in the offset entry of the jump table. This is done by obtaining the offset address stored in the offset entry to locate the parameter entry that stores the first instance of the parameter. Then the next pointer address field of that parameter entry is accessed to obtain the address of the parameter entry that stores the next version of the parameter. The process is repeated until the parameter entry that stores the most recent version of the parameter is located. Then the status of that parameter entry (i.e., the one that stores the most recent version of the parameter) is changed to indicate that the parameter is being updated (i.e., “3F”). The newer value of the parameter is then stored in the allocated unused parameter entry at step 83. Meanwhile, the next pointer field of the parameter entry that stores the then most recent version of parameter prior to the newer value is written to store the address of the parameter entry that stores the newer value of the parameter. This ensures that the latest version of the parameter stored can be accessed through the next pointer link. In addition, this ensures updates of the parameter without prior erasing the memory. At step 84, the status field of the parameter entry that stores the then most recent version of the parameter prior to the newer value is written with the “1F” value to indicate that the parameter value stored in that parameter entry has been superseded by the newer value. The process then proceeds to step 85, at which it is determined if any newer parameter value is to be stored in the block. If so, the process returns to step 77. If not, the process ends at step 76.

[0064] FIG. 5 shows the process of reading a parameter from the parameter blocks by the updating application program. As can be seen from FIG. 5, the process starts at step 90. At step 91, a parameter number is received. At step 91a,the parameter number is checked to see if it is a valid parameter number. At step 92, the offset entry in the jump table for that parameter number is located. At step 93, it is determined if the value stored in that offset entry is “FF”. If the answer is yes, it means that the parameter has never been stored in the block and the process ends at step 101 through step 94. If the answer is no, then the process moves to step 95 at which the offset value in the offset entry is obtained. Then the physical address of the parameter entry that stores the first instance of the parameter is obtained at step 96 by combining the offset value with the start address of the parameter entry section of the block. The parameter entry is accessed by the physical address and the status field of the addressed parameter entry is checked to determine if the parameter value stored in that parameter entry is valid at steps 97 and 98. If, at step 98, it is determined that the status is not valid, then step 99 is performed at which the next pointer field of the addressed parameter entry is accessed to obtain the offset address for the next parameter entry that stores an updated version of the parameter. The process then returns to step 96.

[0065] If, at step 98, it is determined that the status of the parameter entry is valid, then step 100 is performed to access the parameter value field of that parameter entry for the most recent parameter value of that parameter. The process then ends at step 101.

[0066] FIG. 6 shows the process of the block transfer operation performed by the updating application program. As can be seen from FIG. 6, the process starts at step 110. At step 111, the block having a valid status in its block header is located for the block transfer. At step 112, it is determined whether the new block (i.e., receiving block) is an erased block. If not, the block undergoes the erasure operation at step 113. At step 114, the new block that is receiving data has its status changed to “7F” (i.e., receiving data). At step 115, the updating application program executes the read parameter process shown in FIG. 5 to read a first parameter from the valid block and executes the write parameter process shown in FIG. 4 to write that parameter into the new block. Then step 116 is performed to determine if there are more parameters for transfer. If so, step 115 is repeated. If not, the process goes to step 117 at which the status of the new block is changed to valid (i.e., “3F”) and the status of the transferring block is changed to transfer complete (i.e., “1F”). The process then ends at step 118.

[0067] FIGS. 7A-7B and 8 show the initialization process of the updating application program when flash EPROM 10 of FIGS. 1-3C is powered on from its power off state. FIG. 8 shows different combinations of status of two parameter blocks (i.e., blocks 26 and 27) at the power up. FIG. 7A shows the initialization process and FIG. 7B shows the complete block transfer subroutine of the initialization process of FIG. 7A. As can be seen from FIG. 7A, the complete block transfer subroutine is called at steps 156 and 158.

[0068] In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.