Abstract:
The present invention relates to a code bearer, a data-coding device and a method for coding data onto a bearer, provided for manual reading of a first code followed by an input of the first code to a machine, said bearer comprising at least one numerical data field comprising the first code as a series of multiple figures. A second code is generically provided specifying the numerical data field with the first code through modulo arithmetic with a predetermined base, represented by at least one symbol accomplished through compressing each series of multiple figures in the at least one data field. The symbols are concatenated in a predetermined pattern for entering into the machine, wherein enhanced readability of the first code through the symbol pattern applied for the first code is accomplished, thus providing an aid for facilitated, protected and error-minimized input of data belonging to the first code into the machine/apparatus.

Description:
TECHNICAL FIELD  
         [0001]    The present invention pertains to a code bearer, a data-coding device and a method for coding of data onto a bearer for accomplishing a facilitated, secured and error-minimized entering of data into a machine.  
         BACKGROUND ART  
         [0002]    Huge amounts of data are daily being entered and processed electronically through networks for data or telecommunication such as the Internet. This data can, among other things, include different economic transactions, both on personal and corporate levels and related to such as payment orders, stock broking affairs, transfer of economic funds and the like. Online bookings and reservations, for example for travel and accommodation purposes and different registrations for membership purposes and such as online purchasing of goods and services and the like also contributes to the bulk of data continuously being exposed and processed on these networks.  
           [0003]    The security and safe keeping of the online data is then of the utmost importance and a lot of effort and money is being put on minimizing the risk for unauthorized tampering of protected data over networks through a variety of security solutions. Errors can also occur due to mishandling when people are entering and processing data electronically if the wrong data is input. For example a person wanting to electronically pay an invoice might have to fill in 5 fields of data online, totaling as much as 50 characters in all to be entered correctly for achieving a payment in accordance to prerequisites.  
           [0004]    In the year 2000 for example, well over 800 million payment order transactions where carried out on the Swedish market alone. The error rate for online payments in Sweden is typically about 1-1.5% and would probably not be much less in other countries. This results in high billing and invoicing costs. Some lobbyists are claiming that the total billing and invoicing cost amounts to about SEK 250 due to all the erroneous payments being made.  
           [0005]    Furthermore problems arise when money due on a certain account at a certain date is electronically misplaced and maybe lost, transferred to an unknown account instead. Invoice providers may “unnecessarily” send out payment reminders with or without a penalty fee for delayed payment of their outstanding invoices. Payment providers as a consequence thereof may have to pay the same invoice twice and also with an extra fee for delayed payment. The extra time and effort involved with correcting such errors due to mishandling of data continuously contributes to both unnecessary expenses and irritations for individuals as well as corporations. The correctional activities involved are perceived as quite tedious and may sometimes also be very stressful for the people assigned to carry them out.  
           [0006]    There seems to be a need for a more protected and facilitated way of entering secure data electronically for the purpose of avoiding problems mentioned above.  
         SUMMARY OF THE DISCLOSED INVENTION  
         [0007]    The present invention relates to a code bearer, a data-coding device and a method for coding of data onto a bearer. The invention thus enables for protected data to be easily handled in electronic environments incorporating an enhanced level of security against tampering by unauthorized entities.  
           [0008]    A purpose of the invention is to provide an aid to facilitate the entering of data sequences electronically, e.g. to a machine such as a computerized device, to a network for data or telecommunication or the like.  
           [0009]    Another purpose of the invention is to provide enhanced security when utilizing protected data electronically in environments where data is susceptible to be scanned and intercepted by unwanted entities for exploitation.  
           [0010]    Yet another purpose of the invention is to provide a means for an error-minimized entering of data electronically, for reducing unnecessary correctional efforts and costs originating from the mishandling of electronic information.  
           [0011]    To achieve aims and objectives the present invention provides a code bearer provided for manual reading of a first code followed by an input of the first code to a machine, said bearer comprising at least one numerical data field comprising the first code as a series of multiple figures. The code bearer is characterized in that it is provided a second code generically specifying the numerical data field with the first code through modulo arithmetic with a predetermined base, represented by at least one symbol accomplished through compressing each series of multiple figures in the at least one data field into the at least one symbol representing the series of multiple figures through the utilized base in the modulo arithmetic. The symbols are concatenated in a predetermined pattern for entering into the machine, wherein enhanced readability of the first code through the symbol pattern applied for the first code is accomplished, thus providing an aid for facilitated, protected and error-minimized input of data belonging to the first code into the machine.  
           [0012]    In one embodiment of the code bearer according to the present invention, it is a piece of code-imprinted material.  
           [0013]    In another embodiment of the code bearer according to the present invention, it is an electronic device connected to a display.  
           [0014]    In yet another embodiment of the code bearer according to the present invention, it is an invoice or a bill.  
           [0015]    In yet an embodiment of the code bearer according to the present invention, the comprised data fields contain data referring to at least one of account payable, account type, amount, due date of payment and reference number.  
           [0016]    In an embodiment of the code bearer according to the present invention, the date during the 21 st  century is determined by:  
           [0017]    DATE=(yy*12+mm−1)*31+dd−1  
           [0018]    0≦DATE≦37199 days.  
           [0019]    In another embodiment of the code bearer according to the present invention, DATE is set to 0 for denoting a NULL entry of a date.  
           [0020]    In embodiments of the code bearer according to the present invention, the code is implemented with a set of predefined account numbers minimizing the number of bits required and the account numbers are specified in a list of the most frequently occurring account numbers in each of two different payment systems utilized.  
           [0021]    In a further embodiment of the code bearer according to the present invention, it is a receipt.  
           [0022]    In yet a further embodiment of the code bearer according to the present invention, it is a receipt for a purchase of a product or service.  
           [0023]    In other embodiments of the code bearer according to the present invention, it is a receipt for a registration of a travel, accommodation or membership.  
           [0024]    In yet other embodiments of the code bearer according to the present invention, it is a credit card, a membership card, a driver&#39;s licence, a passport, an id-card or a social security card.  
           [0025]    In an additional embodiment of the code bearer according to the present invention, the machine is a computerized device with a screen.  
           [0026]    In still one embodiment of the system according to the present invention, the machine is a handheld computerized device with a display such as a PDA, a cellular telephone or the like.  
           [0027]    In other embodiments of the code bearer according to the present invention the machine is connected to a network for data or telecommunication.  
           [0028]    In a further embodiment of the code bearer according to the present invention, the predetermined pattern is a number of symbols provided in blocks.  
           [0029]    In another embodiment of the code bearer according to the present invention, the coding scheme is reversed for decoding the second code back into the first code again upon entering the second code into the machine.  
           [0030]    In one other embodiment of the code bearer according to the present invention, the second code is substantially shorter than the first code.  
           [0031]    In still another embodiment of the code bearer according to the present invention, the first code substantially comprises numerals.  
           [0032]    In still a further embodiment of the code bearer according to the present invention, the second code comprises letters from at least one alphabet, numerals or a combination of letters and numerals.  
           [0033]    In yet an additional embodiment of the code bearer according to the present invention, the second code comprises an error detection symbol.  
           [0034]    In yet one more embodiment of the code bearer according to the present invention, the error detection symbol is accomplished through adhering all the symbols in the second code through the modulo arithmetic with a predetermined base.  
           [0035]    In yet further embodiments of the code bearer according to the present invention, an additional coding scheme is used for additional compression of the second code, multiple payment orders are summarized into a single code by an extension of the second code and the second code is computer readable through a scanning means.  
           [0036]    The present invention further sets forth a data-coding device for generating a second code from a first code on a code bearer, said bearer comprising at least one numerical data field comprising the first code as a series of multiple figures. The device further comprises:  
           [0037]    means for providing the second code via generically specifying the numerical data field with the first code through modulo arithmetic with a predetermined base;  
           [0038]    means for compressing each series of multiple figures in the at least one data field into at least one symbol;  
           [0039]    means for concatenating said symbols in a predetermined pattern for entering into a machine; and  
           [0040]    wherein enhanced readability of the first code through the symbol pattern applied for the first code is accomplished, thus providing an aid for facilitated and error-minimized input of data connected to the first code into the machine.  
           [0041]    In one embodiment of the data-coding device according to the present invention, it further comprises a printing means for printing the second code onto the bearer.  
           [0042]    In another embodiment of the code bearer according to the present invention, it further comprises a decoder means for decoding the second code into the first code upon entering the second code into the machine.  
           [0043]    In yet another embodiment of the data-coding device according to the present invention, it further comprises a field identifying means for identifying length-dynamic data fields and length static data fields.  
           [0044]    In a further embodiment of the data-coding device according to the present invention, multiple length-dynamic data fields are arranged to be concatenated into a single length-dynamic data field.  
           [0045]    In yet a further embodiment of the data-coding device according to the present invention, the length-dynamic data field is arranged to be positioned first when the length-dynamic and length-static data fields are concatenated.  
           [0046]    In an alternative embodiment of the data-coding device according to the present invention, length-static data fields are concatenated when no length-dynamic data fields are identified.  
           [0047]    The present invention further also sets forth a method for providing a code to a bearer, said bearer comprising at least one numerical data field comprising the first code as a series of multiple figures. The method further comprises the steps of:  
           [0048]    providing a second code generically specifying the alphanumerical data field with the first code through modulo arithmetic with a predetermined base;  
           [0049]    compressing each series of multiple figures in the at least one data field into the at least one symbol representing the series of multiple figures through the utilized base in the modulo arithmetic;  
           [0050]    concatenating said symbols in a predetermined pattern for entering into the machine;  
           [0051]    wherein enhanced readability of the first code through the symbol pattern applied for the first code is accomplished, thus providing an aid for facilitated, protected and error-minimized input of data connected to the first code into the machine.  
           [0052]    In one embodiment of the method according to the present invention, the second code is printed onto the bearer.  
           [0053]    In another embodiment of the method according to the present invention, the second code is provided electronically onto the bearer.  
           [0054]    In a further embodiment of the method according to the present invention, the coding scheme is reversed for the second code to be decoded into the first code subsequent to entering the second code into the machine.  
           [0055]    In still a further embodiment of the method according to the present invention, the decoded data is extracted onto the fields of an electronic copy of the code bearer provided on a screen of the machine and in correspondence to the data fields of the original code bearer.  
           [0056]    In yet another embodiment of the method according to the present invention, length-dynamic data fields and length static data fields are identified.  
           [0057]    In yet a further embodiment of the method according to the present invention, all length-dynamic data fields are concatenated into a single length-dynamic data field.  
           [0058]    In still one embodiment of the method according to the present invention, the symbols from a length-dynamic data field are positioned first for the concatenation. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0059]    Henceforth reference is had to the attached figures for a better understanding of the present invention and its examples and embodiments, wherein:  
         [0060]    [0060]FIG. 1 illustrates a flowchart  100 , describing steps for identifying a coding scheme, according to one embodiment of the present invention;  
         [0061]    [0061]FIG. 2 schematically illustrates an invoice  200  with data fields containing data to be coded for subsequent electronic entering into a machine/apparatus, according to one embodiment of the present invention. 
     
    
     LEGEND  
       [0062]    A handheld computerized device can be a laptop computer, a PDA or the like comprising cellular radio equipment or a WAP telephone device etc.  
         [0063]    An open network for data communication can be the WWW or other like open networks, Intranet etc.  
         [0064]    Data Part: The final code represents a set of data. A data part is simply one of these.  
         [0065]    Data Field: At some stage during computation of the code sequence all information will be represented in a single sequence consisting of parts or “slots” each representing a data part. Such a “slot” is called a data field. A data field can be of dynamic length or not. If the final code for example where to reference a payment order, a data field representing an amount of a payment is typically length-dynamic since (in theory) any amount is possible. However a data field representing an account type is typically not length-dynamic.  
         [0066]    Code Table: Each data field has its corresponding code table that specifies all possible values of each data part.  
         [0067]    Order of Data Fields: In general it is possible to specify a code sequence as is but from a practical perspective it is sometimes more efficient to use a different “language”. If for instance the code were expressed in binary digits, i.e., 0 and 1, to use a hexadecimal representation would require fewer digits. There are more hexadecimal digits than binary digits but the code sequence would get shorter. If, in this example, the total number of binary digits would not be evenly dividable by four, a few i.e. one to three binary zeros would be automatically added to the beginning. Since the dynamic data field can&#39;t have a most significant digit of value zero and since the static data field very well can, it is required to place the dynamic data field first in the code sequence to be able to parse the sequence when decoding.  
       DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS  
       [0068]    The present invention relates to a code bearer, a data-coding device and a method for coding of data onto a bearer for accomplishing a facilitated, secured and error-minimized entering of data into a machine/apparatus.  
         [0069]    The invention aims at providing enhanced means for accomplishing a simplified and safe entering of secure data electronically with minimized risk of erroneous data being entered, through providing a scheme for coding of the data for example for use over networks for data or telecommunication such as the Internet, corporate Intranets and the like. In situations where there is a need for a safe, simple and error-minimized utilization of data, such as for online payments of invoices, where secure information like PIN codes, personal identification numbers, or social security numbers, numbers of personal bank accounts and such secure data need to be exposed electronically, the requirement of attaining a certain degree of safety for the like activities is essential for practicality and functionality reasons.  
         [0070]    There is also the aspect of filling in electronic invoices or performing online registrations, bookings or purchases with the wrong data where the consequences could become apparent at a later time with extra costs and troubles consequently following with an initial mishandling of the data. Also, data such as credit card codes and numbers have to be protected from interception and unauthorized exploitation over digital networks, at banking machines or wherever these numbers and codes are exposed, for payment or withdrawal of money.  
         [0071]    It is becoming evermore popular to perform online payments, online bookings of travel and accommodation, online purchasing of products and services, economic transactions including stock broking online, online distribution of information either directly to individual recipients according to database stored individual information or through mass distribution etc, over electronic networks due to their innate ability to handle enormous amounts of data with lightning speed and on a worldwide scale. Problems relating to such online activities originates as mentioned earlier in keeping secluded information protected from unauthorized usage and also in minimizing of erroneous entering of data. For example, for online payments, when filling in an invoice electronically there could be as much as 50 characters or more altogether in a number of fields on the electronic invoice, which all have to be filled out correctly lest the online payment will fail. The same problem applies when, for example, referring to a booking of a flight over the Internet, where series of data fields often have to be correctly filled out, partly with secure information, in order to accomplish the booking according to request. There is also a mistrust among many users towards giving out personal codes over open networks and the like and many persons are tired of the often long series of data needing to be entered for accomplishing what is desired.  
         [0072]    Moreover the data, for example, on a flight ticket purchased from a certain travel agency, could be summarized and coded directly onto the ticket for facilitating the inputting of the ticket data, for example at an airport on departure. Thereby enabling homogeneous procedures for checking in passengers for example at airports, independent of the tickets appearance, which can differ quite significantly between different travel agencies thus allowing for such activities to be performed faster, smoother and with minimized risk for erroneous handling of the data.  
         [0073]    The coding scheme of the present invention therefore defines a universal language to generically specify specific data.  
         [0074]    The following paragraphs provide background information for one of the preferred embodiments of the present invention relating to online payment of invoices and bills.  
         [0075]    Given a specific payment transfer several parties typically are involved. The payment process originates from a transaction or deal between two parties, the service provider and the customer. Following this transaction the service provider generates a database of accounts receivables and due payments. Typically this is done in an automated billing process. The service provider orders a third party to manage the invoicing process with the information in the database of due payments. The invoicing party formats the database according to the local payment infrastructure systems and standards and generates and sends the proper invoice to each specific customer. In general some customers have ordered a “direct debit” transfer in which case the invoicing party (not necessarily the same one) orders a withdrawal of the amount from a prescribed account. A transfer agent typically does this withdrawal, possibly after a formal accept from the customer by mail or by electronic means. The invoice received by the customer (not using a direct debit transfer) contains relevant specifications from the service provider and a formal payment order. The payment order in this particular example specifies the five following data fields:  
         [0076]    Account payable.  
         [0077]    Account type.  
         [0078]    Amount.  
         [0079]    Due date of payment.  
         [0080]    Reference number unique to the service provider.  
         [0081]    Wherein the reference number gives the service provider a unique reference to the specific invoice once the amount has been transferred in order to handle missing or erroneous payments.  
         [0082]    The customer submits the payment order to his or hers payment agent either physically, e.g. by mail, through a teller machine or a customer representative, or electronically. In all these cases the five data fields specified above needs to be properly handed over to the payment agent. As of today there are several solutions addressing the need of error free transfer of this information. To mention a few:  
         [0083]    The payment order can be read electronically by an “optical character recognition” (OCR) system. These are typically highly expensive and do often need a manual back up for unreadable orders.  
         [0084]    The reference number usually contains a “check sum” in order to warn the person keying the number into the specific system if any mistakes are made. It is also customary to include a digit representing the total number of digits of the reference number.  
         [0085]    The specific system can access a database of accounts payable hence giving reference to the service provider corresponding to the account payable keyed by the customer or its representative.  
         [0086]    When the customer has handed over the payment order to the transfer agent the amount due is withdrawn from an account of the customer&#39;s choice. The transfer agent subsequently collects the payment orders submitted by its customers and sends them to a “clearing house”, which manages the total of all transfers from all its participating transfer agents to the account of the service provider. During this process there are additional steps in which the five data fields mentioned above are read from the payment orders.  
         [0087]    The solution according to a preferred embodiment of the present invention aims to bridge the crucial step between man and machine when the five data fields are entered into a desired subsystem. In its design, the following concerns are addressed as design conditions:  
         [0088]    Even though there are logical foundations to all five data fields they essentially don&#39;t exhibit any logical structure to the person entering them. At least not in the cases of the account and reference numbers.  
         [0089]    Even though it is clear that all five data fields are necessary to specify any given payment order it is more logical to represent each order by a single data field.  
         [0090]    In general the five data fields contain a total of up to 50 digits. It can be quite time-consuming and tedious to enter them into a computer.  
         [0091]    Part from the reference number and the account number there are no error detecting features present.  
         [0092]    On most European markets there are typically two competing clearing houses, each of these with an account number system of their own. It is quite common that customers confuse these account types and hence the amount is paid to the wrong account. I.e., the same account number represents two different accounts, one in each system.  
         [0093]    The solution according to one preferred embodiment of the invention is to summarize all the information of the five data fields in a single code sequence, which is significantly shortened and much easier to remember and express for a user. This sequence, in one embodiment consists of a series of 32 different symbols, which can be alphanumerical, specifically the alphabet and decimal digits with the letters O and I as well as the digits 1 and 0 omitted. The reason not to use these is to not cause any confusion because of their similarities. See Table 1 below for an example of a code alphabet. The symbols are taken from a 32 base in a modulo mathematics.  
         [0094]    The invoicing party through using the coding alphabet encodes the data corresponding to the payment order into a code and includes this in the payment order by printing it on the invoice or preferably on the payment order. When the information in the payment order needs to be referenced the code can be used given that the receiving system can translate it to the corresponding five data fields of the payment order. Two examples of such “translation” systems are described below.  
         [0095]    [0095]FIG. 1 illustrates a flowchart  100 , describing steps for identifying a coding scheme, according to one embodiment of the present invention. The coding sequences initiates with defining a relevant set of data parts  110  on the bearer. A data field and a code table for each data part in the defined set are then defined  120 . Any length-dynamic data fields are identified  130 . When only one length-dynamic data field have been identified, concatenating all data fields then forms the code and a dynamic data field is then placed first  150 . In case more than one length-dynamic data field have been identified, all dynamic data fields are concatenated into a single dynamic data field  140  before proceeding to  150 . Adjacent data fields can in this case be separated with a symbol representing N in base N+1, where N is the largest base of the code tables of the adjacent dynamic data fields. A decision can be made whether or not to compress the final code  160 . A further decision can then be made whether or not to encrypt the final code  170 . A decision can also be made whether or not to express the final code in a specific base  180 .  
         [0096]    [0096]FIG. 2 illustrates a payment order  200  according to a preferred embodiment of the invention containing five data fields  210 ,  220 ,  230 ,  240 ,  250  of decimal digits of a structure exemplified in Table 2 below. Table 2 defines a data field account type, however this property is understood in FIG. 2 as being “postgiro” and the reference  220  here refers to a control number of the amount payable. This data field, “control number of the amount payable”, is not present in table 2, but can be calculated after decoding in this embodiment of the invention.  
         [0097]    In one embodiment of the present invention, all the account information in the five fields  210 ,  220 ,  230 ,  240 ,  250  is summarized into one single code sequence. Two examples of methods for accomplishing this are described below, Example 1 and Example 2. The information in the above five fields are typically of different structure depending on local conditions on different markets. The coding scheme can be implemented with regards to locally prevailing differences. It is still necessary to observe the design conditions mentioned above.  
       EXAMPLE 1  
       [0098]    The first step in forming the code for a payment order  200  is to express the due date of payment with the code symbol alphabet, for example according to Table 1. Based on the observation that to specify a date in this context there is no need to use as many as eight decimal digits. That many digits gives a span of a total of 108 days (or more conservatively 10 000 years, roughly 4*10 6  days) but for payments there are practical considerations to observe.  
         [0099]    Given the assumption that there is no need to specify a date later (or any day earlier) than 100 years from Jan. 1, 2000 for a payment order there is only a need to specify one date out of all in 100 years. Moreover the billing and invoicing systems that generates the due date of payments are currently already generating valid dates, i.e., there are no dates with months between 13 and 99 or dates 32 to 99. Hence there is no need in the encoder of the present invention to validate a date. The encoding can alternatively also be preceded with a proper validation of all dates.  
         [0100]    A date in the code is expressed by forming a “21 st  century” with each month containing 31 days. This gives a span of 100*12*31=37 200 days as opposed to 10 8  days.  
         [0101]    An implementation of the encoder makes use of dynamic evolution of the encoding scheme. If there is a need in the future to, for example, start the date calculation from a later date than Jan. 1, 2000, this value can simply be reset in a software resource file.  
         [0102]    Given a specific due date of payment on the form (during the 21 st  century)  
         20 yy.mm.dd  
         [0103]    where  
         [0104]    0≦yy≦99 (or 88 as seen below)  
         [0105]    1≦mm≦12  
         [0106]    1≦dd≦31  
         [0107]    Form the number  
         [0108]    DATE=(yy*12+mm−1)*31+dd−1  
         [0109]    0≦DATE≦37199  
         [0110]    The code makes use of the base-32 digit system, for example according to Table 3 below. Base 2 and 11 are included for convenience.  
         [0111]    To calculate the code for the due date of payment, the number DATE is expressed in base 32 given by the symbol sequence in Table 3. This is the same as converting to base 2 and perform a table look up in blocks of five bits to find the corresponding base-32 symbol sequence (similar to the usual binary to hexadecimal conversion). Since 32 3 =32 768 it is possible to discriminate all dates between Jan. 1, 2000 and Feb. 1, 2088 with three base-32 digits. As opposed to eight decimal digits used in the currently utilized scheme for payment orders. As described above, this span of dates is dynamic. To denote a “NULL” entry, i.e., no specified date in the payment order issued, DATE=0 is used.  
         [0112]    In order to ensure uniqueness, the function DATE (yy, mm, dd) needs to be “one-to-one” on at least Z ([0,88], [1,12], [1,31]).  
         [0113]    The second step in forming the code for a payment order is to form the decimal and base-11 hybrid number as, for example, shown in Table 4 below. The number 10 in base 11, Δ, is used as a separator in order to be able to parse the information when decoding. The final code segment is the base-32 equivalent of the base-11 intermediate number.  
         [0114]    If it is desirable to represent a payment order with one, two or all three of the (number) fields blank it is possible to omit the corresponding number. It is sometimes customary to issue payment orders with, e.g., no amount specified, for example tax payment orders issued by the IRS.  
         [0115]    The final code is then the concatenation of the DATE (always three base-32 digits), the above code segment and a final check sum of the previous digits modulus 32, which structure and code are exemplified in Tables 5 and 6 below.  
       EXAMPLE 2  
       [0116]    In order to minimize the resulting, final, code sequence there are some special features of the local payment market to observe:  
         [0117]    There are two similar payment systems, “PostGirot” and “Bankgirot”.  
         [0118]    It is unlikely that payment orders with due dates of payment extending one year in advance are issued.  
         [0119]    The majority of all payments are made to a few service providers.  
         [0120]    To utilize these three features the following types are defined:  
         [0121]    Account Type Bit  
         [0122]    Date Series  
         [0123]    Account Compression Bit  
         [0124]    Frequently Occurring Account Numbers  
         [0125]    General Account Numbers  
         [0126]    Check Sum and Date Series  
         [0127]    Account Type Bit:  
         [0128]    This is a binary digit where the value 0 (zero) denotes account type PostGirot and 1 (one) denotes Bankgirot.  
         [0129]    Date Series:  
         [0130]    This type can be either A or B. A date series is a list of 256 consecutive (however not necessarily adjacent) “possible” dates. A date is said to be “possible” if it is possible to order a payment on that specific date. Weekends and public holidays are not “possible” dates. Note that a year approximately contains 250 “possible” dates and that they are all known in advance.  
         [0131]    In this exemplifying method the “Date Series” type alternates between A and B with one overlapping date. This overlapping preserves the ability to specify a “NULL” date, i.e., a payment order with no due date of payment specified.  
         [0132]    Through this, all future dates can be referenced.  
         [0133]    Account Compression Bit:  
         [0134]    In order to minimize the number of bits required specifying an account number it is possible to implement the coding scheme with a set of predefined account numbers. It is for example efficient to use a list of the 128 most frequently occurring account numbers in each of the two different payment systems locally utilized. An account number in this set can be referenced with seven (7) binary bits. The type then has to be specified elsewhere.  
         [0135]    The “Account Compression Bit” is a binary digit where the value 1 (one) denotes usage of the set of account numbers above. The value 0 (zero) denotes that account numbers are specified as is.  
         [0136]    To form the code according to this example, different methods will be used depending on whether the account number is in the predefined account number set described above or not.  
         [0137]    Frequently Occurring Account Numbers:  
         [0138]    For the “Frequently Occurring Account Numbers”, the hybrid number is formed as depicted in Table 7 below and similarly as in Example 1. The first part is already binary (essentially base 32) but the latter needs to be converted from hybrid decimal and base 11 to base 32 before being concatenated with the first part below.  
         [0139]    General Account Numbers:  
         [0140]    The “General Account Numbers” is formed similarly as the “Frequently Occurring Account Numbers” above, and an example for forming the number is shown in table 8 below.  
         [0141]    Check Sum and Date Series:  
         [0142]    To be able to specify the different date series two different check sum algorithms are used (both sums are modulus 32). CA denotes “date series”=A and C B  denotes “date series”=B. (These series are of length 256 with one overlapping date.)  
         [0143]    C A =Σa n  over all base-32 digits a  
         [0144]    C B =Σ(−1) n a n  over all base-32 digits a  
         [0145]    Either of these two (base-32) numbers is finally concatenated to the code segment depending on which date series is used.  
         [0146]    Additional Compression:  
         [0147]    For additional compression it is possible, in both of the examples described above, to use an additional compression of the final base-32 (binary) number. For example, a “Lempel-Ziv” coding scheme could be used.  
         [0148]    The resulting, near optimal, Lempel-Ziv table can be implemented in an encoder and a decoder, i.e., its comprised tree structure is not to be contained in the code sequence.  
         [0149]    In an embodiment of the present invention, an ISO-standardized international reference to a specific account number can be implemented enabling to include additional extensions in the account number data field in order to reference international payment orders. This would also require an additional feature to the code scheme to be able to denote the currency type.  
         [0150]    In some cases there are relations between different payment orders. For instance a customer can receive a collection of monthly payment orders. An extension of the coding scheme according to the present invention can summarize all the payment order data to a single code sequence if desired.  
         [0151]    The total compression of the number of required digits to be able to uniquely specify a payment order will roughly be 50 percent.  
         [0152]    By using a representation in base 32 the compression of a base-l 1 number will be  
         [0153]    ln 11/ln 32≈0.69  
         [0154]    However, in expressing the due date of payment there will be a reduction by several digits and the separating Δ&#39;s will require additional digits.  
         [0155]    In the advent of mobile Internet access in general and of hand-held devices in particular there will probably be a future need to be able to swiftly specify a payment order on a hand-held device. With the code scheme according to the present invention this issue is by all means thoroughly addressed.  
         [0156]    To additionally increase the ease of referencing a payment order, the code can be expressed in blocks of three digits. A typical code sequence would then look like the following:  
         [0157]    GR4 S6B 83U DFK EVY  
         [0158]    The structural form of a code sequence in accordance to one embodiment of the present invention is exemplified in Table 9 with reference to Table 10. The use of compression or encryption has not been yet decided in this example.  
         [0159]    The code sequence can alternatively be distributed in a 2-dimensional grid or in a 3-dimensional lattice.  
         [0160]    Means mentioned in the present description can be software means, hardware means or a combination of both.  
         [0161]    The present invention has been described with non-limiting examples and embodiments. It is the attached set of claims that describe possible embodiments for a person skilled in the art.  
                                             TABLE 1                       Code Alphabet                                    A   B   C   D   E   F           G   H   —   J   K   L           M   N   —   P   Q   R           S   T   U   V   W   X           Y   Z   —   2   3   4           5   6   7   8   9   —                      
 
         [0162]    [0162]                           TABLE 2                                   Data Field   Length                           Account payable   Approx. 10 decimal digits           Account type   One decimal digit 1             Amount   Approx. 10 decimal digits           Due date of   8 decimal digits           payment           Reference   Up to 25 decimal digits 2             number                                                
         [0163]    [0163]                                                                 TABLE 3                                   Base   2   10   11   32                                        Number   0 0000   0   0   A               0 0001   1   1   B               0 0010   2   2   C               0 0011   3   3   D               0 0100   4   4   E               0 0101   5   5   F               0 0110   6   6   G               0 0111   7   7   H               0 1000   8   8   J               0 1001   9   9   K               0 1010   10   Δ   L               0 1011   11   10   M               0 1100   12   11   N               0 1101   13   12   P               0 1110   14   13   Q               0 1111   15   14   R               1 0000   16   15   S               1 0001   17   16   T               1 0010   18   17   U               1 0011   19   18   V               1 0100   20   19   W               1 0101   21   1Δ   X               1 0110   22   20   Y               1 0111   23   21   Z               1 1000   24   22   2               1 1001   25   23   3               1 1010   26   24   4               1 1011   27   25   5               1 1100   28   26   6               1 1101   29   27   7               1 1110   30   28   8               1 1111   31   29   9                        
         [0164]    [0164]                                                                                   TABLE 4                                   Account   Account               Reference           Type   Number   Separator   Amount   Separator   Number                                    Hybrid   decimal   decimal   Δ   decimal   Δ   decimal           digit   number       number       number            Intermediate   Base-11 number       Code   Base-32 number       Segment                    
         [0165]    [0165]                                 TABLE 5                           Final Code                        Check sum modulus           Date   Code segment   32                       3 base 32 digits   Base 32 number   1 base 32 digit                        
         [0166]    [0166]                                                                               TABLE 6                               Account   Account               Reference   Check       Date   Type   Number   Separator   Amount   Separator   Number   Sum               2002-03-14   0 3     8200040   Δ   183900   Δ   30603101012 4                      DATE   Intermediate Base-11 Number               819 5     08200040Δ183900Δ306031010                    Code Segment                    A3V   HR5YY79ERX9P   F                    Final Concatenation               A3VHR5YY79ERX9PF                                    
         [0167]    [0167]                                       TABLE 7                           Account   Account Type   Account Number           Reference       Date   Compression Bit   Bit   Reference   Amount   Separator   Number                   8 binary bits   1 binary bit 6     1 binary bit   7 binary bits   decimal   Δ (base 11)   decimal                       number       number                                    
         [0168]    [0168]                                           TABLE 8                           Account   Account   Account               Reference       Date   Compression Bit   Type Bit   Number   Separator   Amount   Separator   Number                   8 binary bits   1 binary bit 7     1 binary bit   decimal   Δ (base   decimal   Δ (base   decimal                   number   11)   number   11)   number                            
         [0169]    [0169]               TABLE 9                                                                                  
         [0170]    [0170]                           TABLE 10                                       DDF   Dynamic Data Field           S   Separator           n   Number of Dynamic Data               Fields           DF   Data Field           m   Number of Data Fields