embodiments of the present invention is generally related to lexing and parsing sequences of characters . in particular , some embodiments of the present invention are related to improving the efficiency of some existing lexer and parser . for instance , referring to the foregoing example of processing the character sequence “ am 02 ”, the procession down the right - hand initials branch in fig5 represents wasted processing since the branch effectively dies once it is recognized that it is not possible to proceed past state 3 . of itself , such an isolated example is not problematic . however , in real life applications , the number of different token types that the lexer 10 can ascribe to the same lexeme ( character string ) can be large . for example , in the phrase “ let &# 39 ; s meet at 8 . 30 ”, the character ‘ 8 ’ could be output as 10 tokens each having the lexeme ‘ 8 ’ and a respective one of the token types : digit number ip_block phone_block hours minutes street_number day_number month_number year_number thus , the parser 20 must process the lexeme as ten different tokens . similarly , the characters ‘ 30 ’ could be output as seven tokens each having the lexeme ‘ 30 ’ and a respective one of the token types : consequently , the parser 20 has to process the second lexeme as seven different tokens according to the conventional approach . thus , using the grammar time := hours minutes , in order to detect the time “ 8 . 30 ” from the sequence of characters , the parser 20 must investigate a branch for each of the token types for the first lexeme together with each of the token types of the second lexeme — a total of 70 ( 10 × 7 ) branches . however , in order to detect the time , only one branch will be correct and 69 of the branches will be dying branches . further , when it is recognized that some types of data to be detected may comprise three or more token types , it becomes apparent not only that many branches need to be provided , but more importantly that processing through the parsing tree will throw up a huge number of dying branches . these dying branches represent wasted processing time . although the lexer 10 acts entirely as intended and outputs precisely the correct tokens , the possibility of ascribing a large number of token types to each lexeme can be detrimental to the efficiency of the parser 20 . moreover , it is possible to take advantage of the fact that the lexer 10 and the parser 20 are specifically designed to operate together and can be adapted to each other &# 39 ; s requirements . for example , unlike prior art lexers , it is not necessary for the lexer 10 to make a final decision as to the token type or token types of any particular lexeme . in the foregoing example , the lexer 10 was fed the characters ‘ am ’ and output two tokens each having the lexeme am and a respective one of the token types initials and meridian . effectively , the token types can be represented in a venn diagram , with each token type representing a circle , as shown in fig6 . in this example , the token type initials intersects with the token type meridian and , due to this intersection , to the conventional approach ascribes to a lexeme falling in this intersection both token types . this allows the parser 20 to check whether the function of the lexeme is to act as the class initials or the class meridian . however , in at least certain embodiments of the present invention , it is recognized that the lexer 10 and parser 20 can be less formal and that the token types need not be allocated on a one - to - one basis with the functions that the lexemes can carry out . specifically , the lexer 10 may not have to decide which particular function each lexeme has in order for the parser 20 to detect data . rather , in at least certain embodiments of the present invention , a third “ mixed ” token type is used instead to indicate that the lexeme may have any one of a plurality of different functions . thus , in the present example , as shown in fig7 , three token types are provided — m , mi and i . the token type m means the lexeme has the function of meridian ( and not initials ); the token type i means the lexeme has the function of initials ( and not meridian ); and the token type mi means that the lexeme can have the function of either initials or meridian . accordingly , when confronted with a lexeme such as am , which may have either the function initials or the function meridian , instead of ascribing both token types initials and meridian to the lexeme , the lexer 10 ascribes the lexeme am with the token type mi , meaning that it can have either the function initials or the function meridian and outputs a single token , according to some embodiments of the present invention . using a different terminology , a lexeme / token having such a “ mixed ” token type may be called a “ proto - lexeme .” such a “ mixed token type ” may similarly be called a “ proto - token type .” with this ability to output proto - lexemes having mixed token types , it also becomes possible for the lexer 10 to further designate other lexemes as definitively having a single function . such lexemes and single - function token types may also be termed proto - lexemes and proto - token types . accordingly , the prefix “ proto ” is indicative of a token , token type or lexeme output by a lexer 10 according to the present invention . thus , the single character ‘ a ’ by itself can be designated as a proto - lexeme having proto - token type m ( meridian and not initials ), and a sequence such as ‘ pq ’ can be output as a lexeme having proto - token type i ( initials and not meridian ). accordingly , it will be apparent that the lexer 10 is able to ascribe a greater number of types to a lexeme — in this example , three proto - token types , instead of two normal token types . however , in this example , it ascribes only a single proto - token type to a lexeme , whereas a prior art lexer could ascribe multiple , different token types to the same lexeme . continuing with this example , a decision tree for a corresponding lexer 10 of the present invention is shown in fig8 . at the start state s , it is determined whether the first character is an ‘ a ’ or a ‘ p ’ and , if it is , processing proceeds to state 1 . if there are no more letters , processing is finished at that state and the sequence is determined to form a token having lexeme a or p and token type m — that is , the lexeme has the meridian function without a possibility of having the initials function . however , if there are more characters in the sequence and the next character in the sequence is an ‘ m ’, processing proceeds to state 2 , where the sequence is determined to form a token having lexeme am or pm and token type mi — that is , a mixed token type in which the lexeme can have either the meridian or initials functions . the condition ! m at state 1 means “ not m ”. accordingly , if there is different character after a or p , processing proceeds to state 3 and the sequence is determined to form a token having lexeme a or p followed by another letter and token type i — that is , the lexeme has the initials function without a possibility of having the meridian function . it will be evident from the right - hand branch in the figure how the lexer 10 will output other sequences of two letter words as a token having token type i . in some embodiments , the parser 20 is tailored to act in tandem with the lexer 10 to handle such proto - lexemes . an example of a modified decision tree for the parser 20 in this example is shown in fig9 . in particular , an additional branch is provided at the start state s to cope with the mixed token type mi . if , for example , the sequence a 02 is entered into the lexer 10 , it forwards to the parser 20 three tokens having the respective token types m , digit , digit . operating on this , the parser 20 follows the right - hand branch of the decision tree in fig9 following the route s , 5 , 6 , 7 and detects a 02 as a time . if the sequence aq 023 is entered into the lexer 10 , it forwards to the parser 20 four tokens having the respective token types i , digit , digit , digit . operating on this , the parser 20 follows the left - hand branch of the decision tree in fig9 following the route s , 1 , 2 , 3 , 4 and detects aq 023 as a bug identification code . however , if the sequence am 02 is entered into the lexer 10 , it forwards to the parser 20 three tokens having the respective token types mi , digit , digit . operating on this , the parser 20 follows the middle branch of the decision tree in fig9 following the route s , 8 , 9 , 0 . at state 0 , there are no more tokens in the sequence matching the available condition so the reduction for state 0 is used . accordingly , am 02 is detected as a time . moreover , if the sequence am 023 is entered into the lexer 10 , it forwards to the parser 20 four tokens having the respective token types mi , digit , digit , digit . operating on this , the parser 20 again follows the middle branch of the decision tree in fig9 following the route s , 8 , 9 , 0 . at state 0 , a further token in the sequence matches the available condition so the processing proceeds to state 4 . accordingly , am 023 is detected as a bug identification code . by contrast , if the sequence aq 02 is entered into the lexer 10 , it forwards to the parser 20 three tokens having the respective token types i , digit , digit . operating on this , the parser 20 follows the left - hand branch of the decision tree in fig9 following the route s , 1 , 2 , 3 . at state 3 , there are no more tokens in the sequence matching the available condition . however , as state 3 is represented by a dotted circle , processing cannot finish at this state and neither a time nor a bug identification code is detected . as will be clear from the foregoing simple example , a branch from the start state s is provided for the mixed token type . accordingly , irrespective of whether the lexeme is a normal lexeme or proto - lexeme , it can be processed using a single path . effectively , there is only one path processing a proto - lexeme and it is no longer necessary to process multiple paths for a single lexeme . thus , the parser 20 does not process any dying branches for the proto - lexeme . in this way , sequences of characters such as e - mails can be scanned considerably more quickly . it can also be noted that while the lexer 10 does not make any definitive decision on whether the lexeme am has the function meridian or initials , no such decision is made by the parser 20 either . instead , it is enough to determine whether the lexeme has a mixed token type in order to detect whether a time or a bug identification code is present . in many real life applications , the number of different token types that the prior art lexer 10 can ascribe to the same lexeme can be large . for example , in the phrase “ let &# 39 ; s meet at 8 . 30 ”, the character ‘ 8 ’ was output as ten tokens each having the lexeme ‘ 8 ’ and a respective one of the 10 token types : digit number ip_block phone_block hours minutes street_number day_number month_number year_number similarly , the characters ‘ 30 ’ were output as seven tokens each having the lexeme ‘ 30 ’ and a respective one of the seven token types : however , in the present invention , a token space similar to that illustrated in fig7 could be constructed . the token type for each lexeme could be a proto - token type that represents a single function exclusively , such as proto digit , or a mixed proto - token type , which represents that the lexeme can have two or more functions . for example , one mixed proto - token type for the character ‘ 8 ’ could indicate that it has either a digit or number function ; another mixed proto - token type could indicate that it has a digit , number , hours or minutes function ; and another mixed proto - token type could even indicate that it has any one of the ten possible functions . the precise proto - token types available will depend on the various conjunctions of the sets in a token space diagram similar to the venn diagram shown in fig7 . thus , instead of providing the parser 20 with 17 ( 10 + 7 ) tokens to parse in 70 ( 10 × 7 ) combinations , as in the prior art , the lexer 10 of the present invention would output two proto - lexemes each with one proto - token type . as a result , the amount of work needed to be done by the parser 20 is dramatically reduced and hence , the speed of detecting data in a block of text is significantly increased . indeed , in many real life implementations , the speed of data detection has been more than doubled using some embodiments of the present invention . note that that some embodiments of the present invention require an increased complexity in the vocabulary of the lexer 10 and the grammar of the parser 20 , with a consequent increase in storage capacity required to store them . however , it has been found that , in some embodiments , the increase in storage capacity required is approximately only 25 % starting from a requirement for 3 . 6 mb for a system according to the prior art in order to achieve a more than two fold increase in scanning speed . in general , the greater the number of patterns in the system , the smaller the increase in proportional terms . in some embodiments , the lexer 10 ascribes to all tokens a proto - token type — that is , a token type indicating that the lexeme falls in a single category of data , or one of a plurality of categories of data . however , the present invention may also be used in a mixed form with the prior art in some embodiments . that is , a lexer 10 may ascribe a proto - token type to most , only a few or even only one of the tokens it outputs . in this case , the other tokens may be processed in the same way as the prior art — that is , more than one token type can be ascribed to the same lexeme . in such cases , the speed of processing may be reduced but the storage requirements for the lexer 10 and parser 20 may also be reduced . moreover , in this case it would be necessary to set up a parser that would accept both some “ lexemes ” and some “ proto - lexemes ” as an input . however , this would have to be done carefully : one part of the token space venn diagram would be converted to a proto - lexeme partitioning , while the other part would remain unchanged . therefore , some strings would be lexemized , while some would be proto - lexemized . some embodiments of the present invention may also be used in a mixed form in which two or more proto - token types are ascribed to the same lexeme . in this case , it would be possible , for example , to ascribe both a mixed proto - token type such as such an arrangement takes advantage of the above concept of reducing dying branches , but reduces the complexity of the lexer 10 and parser 20 and reduces the requirements for storage space . embodiments of the present invention have a wide variety of applications . for example , it may be used in scanning e - mails and blocks of text , such as those created in word processing packages . moreover , it can be used in any application where sequences of characters are processed , such as in compilers and interpreters . embodiments of the present invention may be implemented using any suitable apparatus . such an apparatus may include , but is not limited , to data processing machines and devices such as laptop or notebook computers , other user and server computers , and mobile communications devices , such as mobile telephones , personal digital assistants and so forth . as an example , fig1 shows an arrangement comprising a user computer 30 , a notebook computer 40 , and a cell phone 60 , where one , some or all devices may have a processor 1 adapted to operate in accordance with the present invention . in the present example , at least the notebook computer 40 and the cell phone 60 have such a processor 1 . a first user may compose a message and send it by e - mail to a second user . the second user may retrieve the message over the internet 70 using his notebook computer 40 . upon retrieval of the message , an application embodying one embodiment of the present invention may automatically scan the message to detect whether it includes predetermined data , such as a time , a date , a name , an address and so forth . on detection of a time and a date , the application may notify the second user and provide him with the option of updating his calendar . similarly , on detection of names , addresses , phone numbers and so forth , the application may notify the second user and provide him with the option of updating his address book . in addition , the second user may retrieve the message using his mobile phone 60 via the internet 70 and a telecommunications base station 50 . again , an application embodying the present invention may detect predetermined data and provide the option of updating the user &# 39 ; s records with the detected data . it is also conceived that the present invention may be embodied using two or more different devices in some embodiments . for example , one device could carry out the lexing function and the other the parsing function . the present invention may also be used to extract data included in mobile phone messages , such as sms text messages and mms messages , in some embodiments . the present invention may also be embodied in software causing a data processing device to carry out the invention , as well as in computer - readable media on which such software is stored . moreover , the present invention may be embodied in dedicated hardware or general - purpose hardware . some embodiments of the present invention can relate to an apparatus for performing one or more of the operations described herein . this apparatus may be specially constructed for the required purposes , or it may comprise a general - purpose computer selectively activated or reconfigured by a computer program stored in the computer . such a computer program may be stored in a machine ( e . g . computer ) readable storage medium , such as , but is not limited to , any type of disk including floppy disks , optical disks , cdroms , and magnetic or optical disks , read only memories ( roms ), random access memories ( rams ), erasable programmable roms ( eproms ), electrically erasable programmable roms ( eeproms ), flash memory , magnetic or optical cards , or any type of media suitable for storing electronic instructions , and each coupled to a bus . fig1 shows one example of a data processing system , such as a computer system , which may be used with the present invention . note that while this figure illustrates various components of a data processing system , it is not intended to represent any particular architecture or manner of interconnecting the components as such details are not germane to the present invention . it will also be appreciated that network computers , personal digital assistants ( pdas ), cellular telephones , handheld computers , special purpose computers , entertainment systems and other data processing systems and consumer electronic devices which have fewer components or perhaps more components may also be used with the present invention . the system of this figure may , for example , be a macintosh computer from apple , inc . in some embodiments , the computer system 151 may be used as a server computer system or as a client computer system or as a web server computer system . it will be appreciated that such a computer system may be used to perform many of the functions of an internet service provider , such as isp 105 . the computer system 151 interfaces to external systems through a modem or network interface 169 . it will be appreciated that the modem or network interface 169 may be considered part of the computer system 151 . this network interface 169 may be an analog modem , an isdn modem , a cable modem , a token ring interface , a satellite transmission interface ( e . g . “ direct pc ”), or other interfaces for coupling a digital processing system to other digital processing systems . the computer system 151 includes a processor 153 which may be a conventional microprocessor , such as a motorola powerpc microprocessor or an intel pentium microprocessor . memory 155 is coupled to the processor 153 by the bus 157 . memory 155 may be dynamic random access memory ( dram ) and may also include static ram ( sram ). the bus 157 couples the processor 153 to the memory 155 and also to mass memory 163 and to display controller 159 and to the i / o ( input / output ) controller 165 . display controller 159 controls in the conventional manner a display on the display device 161 which may be a crt or a liquid crystal display device . the input / output devices 169 may include a keyboard , disk drives , printers , a scanner , a digital camera , and other input and output devices , including a mouse or other pointing device . the display controller 159 and the i / o controller 165 may be implemented with conventional well known technology . the mass memory 163 is often a magnetic hard disk , an optical disk , or another form of storage for large amounts of data . some of this data is often written , by a direct memory access process , into memory 155 during execution of software in the computer system 151 . it will be appreciated that the computer system 151 is one example of many possible computer systems , which have different architectures . for example , macintosh or wintel systems often have multiple busses , one of which may be considered to be a peripheral bus . network computers may also be considered to be a computer system , which may be used with the present invention . network computers may not include a hard disk or other mass storage , and the executable programs are loaded from a network connection into the memory 155 for execution by the processor 153 . a web tv system , which is known in the art , may be considered to be a computer system according to the present invention , but it may not include certain features shown in fig1 , such as certain input or output devices . a cell phone having a suitable display and a processor and memory may also be considered to be a digital processing system or a computer system , which may be used with the present invention . a typical computer system will usually include at least a processor , memory , and a bus coupling the memory to the processor . it will also be appreciated that the computer system 151 is typically controlled by an operating system , which includes a file management system , such as a disk operating system , which is part of the operating system . a machine - readable medium includes any mechanism for storing or transmitting information in a form readable by a machine ( e . g ., a computer ). for example , a machine readable medium includes read only memory (“ rom ”); random access memory (“ ram ”); magnetic disk storage media ; optical storage media ; flash memory devices ; electrical , optical , or other form of storage systems . it will be apparent from this description that aspects of the inventions may be embodied , at least in part , in software . that is , the techniques may be carried out in a computer system or other data processing system in response to its processor or processing system executing sequences of instructions contained in a memory , such as ram , etc . in various embodiments , hardwired circuitry may be used in combination with the software instructions to implement the present inventions . thus , the techniques are not limited to any specific combination of hardware circuitry and software , nor to any particular source for the instructions executed by the data processing systems . the foregoing description has been given by way of example only and it will be appreciated by a person skilled in the art that modifications can be made without departing from the spirit and scope of the present invention .