HK1102502B - Mobile ticketing - Google Patents

Abstract

Information, such as ticket information is encoded, for transmission of the encoded information to a device that candisplay the encoded information as visible alphanumeric characters. Original information is converted into a binary format then separated into x bit binary words, where x is the same as a maximum number of bits data required by every data character in a pre-determined data character map. The binary words are formed into a sequence of characters using a data character map. Special marker characters are inserted into the sequence. The special characters demarcate the sequence into sets of characters separated by one or more special marker characters. Line feed command characters are also inserted. The encoded information is transmitted to a client device that displays it as a rectangular array of characters bounded by the special marker characters.

Description

Mobile ticketing

Technical Field

The present invention relates to software and methods for encoding alphanumeric (alphanumerical) information, and in particular, to software and methods for wireless transmission that can be scanned and decoded at the user end.

Background

The invention is described with reference to transmitting an alphanumeric code to a user device, such as a mobile telephone, having a viewable area adapted to display alphanumeric characters. Encoding, transmission, Optical Character Recognition (OCR) techniques and data recovery techniques particularly suited for reading and interpreting displayed alphanumeric codes are also described. It will be appreciated that such user devices are not limited to mobile telephones. Likewise, the invention may be used in ticketing applications, but is not limited to this field of application.

It is estimated that the mobile ticketing industry will scale to $ 400 billion by 2009. There is a clear market need for mobile ticketing technology that spans a variety of industries and applications, including air and transportation, ticketing providers, sports stadiums, movie theaters, and entertainment venues, retail, and so forth. Mobile ticketing would greatly reduce the cost of ticket fulfillment as well as the cost of queuing. By 9 months 2004, mobile devices used globally over 17 billion. Paper bills and plastic bills, coupons and cards are issued each year in hundreds of billions.

There have been many attempts by technical providers to implement mobile ticketing as such a solution. A known solution is to use a methodology of encoding information into a bar code pattern to be transmitted to the mobile device. A common bar code pattern may be a one-dimensional, i.e. a common vertical bar code, or a two-dimensional. Unfortunately, these solutions are not device or carrier independent. Although organizations such as enhanced information services (EMS) and Multimedia Messaging Services (MMS) use published standard protocols to send these codes, the fact remains that different user devices simply cannot handle the transmitted information equally when interpreting and displaying the codes.

These inconsistencies in the graphic carrier have resulted in prior art wireless based ticket codes (a) not reaching the telephone, (b) reaching but not being interpreted, or (c) being capable of being interpreted but not scanned. As mobile devices become more complex, the pixel size of the mobile phone display screen decreases, particularly for individual barcodes, which effectively prevents it from being transferred to a set of new and old mobile devices and allows it to be displayed consistently and stably.

There are many more simple solutions on the market by transmitting information such as the ticket code as plain text to the user device, which is then read and entered into the keyboard manually. However, this process can be awkward, time consuming, expensive, and not entirely reliable.

Disclosure of Invention

One object of the disclosed technology is to solve the above-mentioned problems by encoding the information into proprietary developed "N-code". N-code is a series of alphanumeric characters specifically encoded into a string that is easy to transmit, compile and optically scan at the receiving terminal since the displayed information is plain text, the method and technique enables all mobile devices that can support information delivery to be used in mobile ticketing and other similar and related applications.

In one embodiment, the disclosed technique is implemented such that end-to-end encoding to decoding is achieved by first creating a unique alphanumeric character geometry from the original serial number, ticket or card information, which is then transmitted to the mobile device using the protocol employed by the network (e.g., GSM). The displayed alphanumeric code is then scanned using a standard optical capture device (e.g., a CCD) or a Firewire camera. Such alphanumeric codes are captured and processed using a combination of proprietary image processing algorithms and published algorithms, with the processed image being converted into alphanumeric guesses by an optical character recognition engine (OCR) before the proprietary decoding algorithms are finally applied to accurately obtain the original ticket or card information.

Drawings

FIG. 1 shows a schematic diagram of a user device display for two types of N-codes;

FIG. 2 shows a schematic diagram of a user device display for one type of N-code;

FIG. 3 shows a flow diagram for assembling N-code from raw data;

FIG. 4 shows a flow chart of how an image on a user device is prepared for OCR processing;

FIG. 5 shows a flowchart of how the output of the OCR process is used to make the best guess about the N-code;

FIG. 6 shows a flow chart of how the coordinates of an actual character are derived;

FIG. 7 is a diagram illustrating the use of best-estimated coordinates for each character to obtain a data character value;

FIG. 8 shows a flow chart of N-code decoding; and

FIG. 9 shows a flow diagram of an overview of N-code processing;

FIG. 10 illustrates a mapping between smaller and larger data lengths;

FIG. 11 illustrates a scanning device having bar code display, remote control display, and printing features; and

fig. 12 shows the structure and control flow of an end-to-end mobile ticketing services bureau.

Detailed Description

As shown in fig. 1, a method of encoding information or "raw data" that is otherwise stored in paper barcodes and magnetic strips such as on tickets, cards and tickets, into a moving alphanumeric string geometry 10 ("N-code") is presented. Such an alphanumeric string is readily wirelessly transmitted to all mobile devices supporting information transfer for purposes such as admission, identification, subscriber profile identification, etc., and thus can be optically scanned and reliably decoded back to the original encoded information. In one example of fig. 1, nine to fifteen bits of information are transmitted as the information that results in 3 lines of text 10. Each line of text has two groups 15 of four or five alphanumeric characters, each line of text being defined by a special marker 16. The groups are separated by the same special marker 16 (here the symbol "═ h"). In another example of fig. 1, 16 to 18 bits of information are transmitted as information to produce 3 lines of text 11. Each line of text has two groups 17 of five characters, each line of text being delimited by a special marker and the groups being separated by a distinct separate special marker (here the symbol "═"). "is considered to be distinctive because it is less likely to be visually confused with other characters. Alternatively, other similar methods may be used to exploit the uniqueness of some alphanumeric character's geometry to determine the identification form of the N-code for efficient optical processing. These forms include alternating patterns such as alternating between upper case to lower case and upper case in characters that are consecutive along a row (e.g., aBcDdYoG), well-known patterns such as using a predetermined sequence of multiple characters (e.g., b57-z82-p45-), and sensitively-positioned character mapping (mapping) in which the characters used for mapping are a function of the x and y coordinates in the row and column of each character itself. As an example of character mapping for sensitive positioning, one mapping rule may be that the third row of characters should contain only capital letters between M and Z (e.g., first row 29183902, second row addcedpqz, third row MNPZZQRM). These similar methods are all designed to create geometry in the raw captured N-code image so that the decoding system can use the geometry as a clue to locate the code and decode the image. This unique approach to applying alphanumeric geometry is a key component in creating a coding and decoding alphanumeric data system that has satisfactory scan reliability and commercial deployment speed requirements.

As shown in fig. 2, the user display 22 shows the special characters 20 in the transmitted encoded character set that are easily recognizable as indicia in a rectangular display geometry so that the image capture and processing algorithms can more efficiently recognize and decode the image. In this example, the alphanumeric character "20" is used as the boundary character. Groups 23 of four other characters, such as alphanumeric characters, are positioned between the spaced apart border symbols 20. Such displayed information may include non-encoded interpretation text 21 positioned outside of the target area defined by the special characters 24 positioned at the 4 corners.

As shown in fig. 3, the method entails converting information represented in the form of an original n-bit ticket code 30 into a binary format 31 by utilizing a disclosed bit-based redundancy algorithm. One suitable algorithm is the Reed Solomon (Reed Solomon) algorithm, but this is not mandatory. For example, the ticket code 123456789012345 would be converted to binary: 00000100100010000110000011011101111101111001 which is now a 47 bit binary number. Since the original data is 15 bits, it will be converted into N-code information as shown in fig. 2.

A typical N-code contains 24 data characters of 5 bits. In this example, the N-code may carry a total of 24 × 5 ═ 120 bits of information. This 47-bit binary number is converted to a 120-bit number 32 using Reed Solomon's bit-based data redundancy. This number is then divided into 24 consecutive 5-bit packets 33, each 5-bit will now form a 5-bit binary word, and each of these binary words is mapped into a 5-bit data character by means of a character mapping table 34. Note that the number of binary bits per word does not exceed the number of bits required for any character in the mapping table 34.

The latter 5-bit character map is one suitable character map for a 5-bit character. (the power of 5 of 2, i.e. 32 characters, is contained in this mapping table):

< AB C D E F G H J K L M N O P Q S T U V W X Z2345679 Note that where the characters I, R, 0, 1 and 8 have been removed, errors in scanning and decoding may occur because of their similarity to other characters. Note that the 5 bits and specific character sets described above are not mandatory for the present invention, and they are only examples. Thus, a 5-bit word with a value of 01010 will map to the 11 th character in the group (01010 ten in decimal). Considering "0" as the first character, 01010 will transform to the 11 th, which will be "K". In this example, all characters are capital letters.

With this method, a 120-bit string will be encoded into:

6WJ5E5CG＜5PT3LKVXEVN5OS4

this unprocessed character sequence is divided into three lines of characters 35, each line being divided by a beginning double equal sign 36 and an ending double equal sign 37. Each row is divided in half by a single equal sign "38. Into which line feed commanders are inserted as needed to provide the final display geometry. Thus, and as suggested by FIGS. 1 and 2, the resulting N-code will be:

＝＝6WJ5＝E5CG＝＝

＝＝＜5PT＝3LKV＝＝

＝＝XEVN＝5OS4＝＝

this N-code is now ready for transmission. Note that any interpreted text before and after the N-code will eventually be ignored by the data capture software due to the use of the boundary character "═". In the following example, the initial and final lines "Start N-Code" and "Admission Ticket" will eventually be ignored by the client decoding process.

Start N-Code

＝＝6WJ5＝E5CG＝＝

＝＝＜5PT＝3LKV＝＝

＝＝XEVN＝5OS4＝＝

Admission Ticket

N-codes of the type described above may be wirelessly transmitted over the air to mobile devices via a particular network protocol, such as SMPP, SS7, or SMTP. This takes advantage of the existing network infrastructure of the network carrier. Since it is plain text, such content will arrive unchanged, and since it is designed for human-eye reading, such content will be displayed highly consistently in different mobile devices. Some mobile devices display double wrapping as a single line, while some other devices display double wrapping as double wrapping. Double wrapping must be eliminated before transmission to ensure that the image is single line spaced. The double row spaced N-code is not scannable.

Once received and displayed by the user device, the N-code is captured by an image capture device, such as a digital camera or video camera. Such a device preferably provides a light source that emulates the illumination of "cloudy weather", which is actually a diffuse light source, in order to minimize the bright spots or "hot spots" of illumination caused by direct light sources on the image captured by the display screen of the user device (telephone or personal information terminal, etc.). These spots may obscure parts of the image.

The frame rate and data capture speed must be fast enough to transmit color images of the mobile phone display. Such a capture device optionally has a motion detection subroutine to trigger the capture device to take a still "picture" on the display of the stationary mobile phone once it is determined that the mobile phone is truly stationary or is moving within an acceptable range that satisfies the concept of being stationary. Without this option, the software would instead be used to determine whether the phone has arrived and become stationary via video feed. This type of image processing software library is widely disclosed and is readily available and executable.

The present invention applies statistical and mathematical algorithms to convert color images captured by various types of mobile phone displays available on the market into black and white images that are easily decoded into textual guesses by common optical character recognition machines (OCR).

As shown in FIG. 4, the method uses one or more of the following sub-methods to achieve the desired results.

Removing skew 41 is accomplished from the skew data collected from the center 50% of the image. 50% is not the only value that works, and adjacent values also work, but 50% has been found to be appropriate. This step takes into account small skew fluctuations due to people not placing the phone vertically downwards. The skewed image 42 of the display is corrected 43. Global contrast processing 44 ensures that image 45 contains the maximum global contrast. If the gray histogram (obtained by temporarily converting the image to gray, plotting the gray frequency on the (y) axis against the actual gray value on the (x) axis) does not span the full length of the (x) axis, the contrast is increased until it spans the full length. Another alternative image enhancement technique is local contrast processing 46. This decomposes the complete image 47 into a plurality of local regions 48. For an image of 1280 × 960 pixels, a suitable decomposition size is 50 × 50 square pixels, although other similar region sizes have also been found suitable. The size of these regions is less important than the local treatment in that region.

This is accomplished by sampling all of the regions to determine the static standard deviation of the color values in each region and adding them to the table of values. For the above pixel sizes, there are 520 standard deviation values from 520 regions. The values are then sorted in descending order with the highest standard deviation value at the highest point (which represents each 50 x 50 squared local contrast) and the lowest value at the lowest point. Thereafter, for the 45 th percentile of the lowest point (bottom 45% of the square of the contrast), they are "wiped" with white. The value of this 45 th percentile is neither fixed nor absolute, but has been found to be suitable. Similar results would be returned for adjacent values. It was found that due to the color difference between the text characters and the background of the phone display screen, the area with valid N-codes will almost always fall in the 55 th percentile of the highest contrast.

To maintain the high 55 th percentile inside each local area, the method increases the contrast of a specific color, but is preferably performed separately for the 3 color channels (red, green and blue). This gives an area where a significant improvement in N-code text contrast is found. If the 520 standard deviation sample data shows a specific difference in the values of the normal distribution, this can be selectively used to further remove unwanted portions of the image by maintaining only the bin regions, as compared to the bin distribution. This result is converted to a high contrast black and white image 50 by increasing the black and white contrast with the standard color. This image 50 is now ready for transmission for processing by an OCR engine (engine).

As shown in FIG. 5, the method applies a conventional OCR engine 51 to the monochrome composite image 50 to obtain "text guess" statistics 52. For each guessed character, such statistics include confidence, character guess, x and y coordinates, x and y dimensions, and other data that may be needed. This may be stored in memory as a table of statistics 53.

The method uses text guess statistics as input for one or more proprietary "code-location" algorithms 55 to make best guesses 56 on the underlying N-codes 57. Any of the following sub-methods may be used. One sub-method is to eliminate invalid characters, i.e., characters that are not part of the character transformation, from the OCR recognition character table so that the OCR algorithm can recognize only valid code characters without spending time processing the invalid characters. This can help optimize the accuracy and performance of the OCR engine. The boundary marker 20 may be set first by guessing the probability of the character 53 and the output amount of coordinates. In the example described previously, the marker would be equal "═ h". Once it is found within the results set 53, the following sub-method can be used to find the most likely rectangular area 58 in which the N-code is located.

The first sub-method utilizes the smallest x and y coordinate values from all equal signs adjusted by the x and y size of the equal signs to determine the top left corner 59 of the best estimated N-code position. The second sub-method uses the largest x and y coordinate values from all equal signs adjusted by the x and y size of the equal signs to determine the bottom right corner of the best estimated N-code position. The third sub-method uses the per-line occurrence rate of characters in an efficient N-code character transformation to determine the most likely 3 lines of text composed of N-codes. Using a combination of the first, second and third sub-methods described immediately above, the most likely N-code location can be determined by the x and y coordinates, including but not limited to determining whether the first and second sub-methods have returned an erroneous marker character that is not contained within the matching rectangular area, such as using the third sub-method.

As shown in fig. 6, the rectangular target area 60 is determined by using the "═" mark as explained above. The method then divides the rectangular area into 6 sub-sections 65 using the marker 61 positioned in the middle of the code and the equally sized 3-way vertical split 62, 63, 64. If the middle marker is not present, the center of the rectangle 60 can be used as the best estimate.

As shown in FIG. 7, the method then subdivides each of the 6 rectangles 65 to obtain a map (shown as an "X") of the best estimated coordinates for each expected N-code character. The next step is to apply the output data containing all of the guesses made by the OCR engine to these best guess coordinates ("X") to obtain the closest match 71 which takes note of the difference between the guessed character and the best estimated X, y coordinates for each character (see figures 5 and 6). These closest matches will be used for the final decoding.

As shown in fig. 7, if such an algorithm is not good enough that there is a truly sufficiently accurate guess for a character, it will utilize a blank character (the designation in fig. 8 is underlined with the "_" character). This is determined by the distance and the limit value of the possibility. Blank characters mean "known errors" and require less correction, which will thus aid the overall decoding process.

As shown in FIG. 8, the exemplary method presented herein converts the best guess 80 into a binary code format 83, and then uses bit-based data correction and restoration 84 for the binary form of the best candidate N-code guess string 80 to determine the original code 81, with the requirements 85 for the checksum of the code being satisfied to ensure that the final guess for the original code 81 is valid code. If the result 81 fails the checksum test, the method will attempt to re-sample the image using a mathematical algorithm at a different sampling resolution and retry the process without capturing another image. For example, if the original image is sampled and captured at 400 points per inch, the mathematical algorithm is again used to sample at the 500 points per inch and the method described above is again applied. This most likely returns the correct code 81 with the correct checksum.

If it fails again, instead of re-sampling, the scanning device returns the wrong audio or video signal to the telephone that the user scanned, which would result in another manual scan being attempted. It is statistically highly unlikely that this will fail again, since there is usually enough fluctuation in illumination and positioning to return to a positive scan and decode.

The flow chart of fig. 9 depicts an overview of all of the methodologies described above. In general, the N-code is derived from ticket codes, number recognition or other original information using bit-based redundancy in character transformation. The N-code is proposed for transmission 92 by using particularly helpful OCR character transformations and special markers. The N-code is preferably transmitted 93 wirelessly without changing its content. In the preferred embodiment, the double wrapping is removed. The N-code is received by the user device and displayed in a manner that can be optically scanned 94. Special lighting may be required. The displayed image is processed 95 using correction algorithms for imaging, which may include removing offsets, performing mathematical and statistical operations on contrast and color, and converting to a final black and white image. The black and white image is operated on by OCR engine 96 to return the character data, best statistical guesses of character positions, and statistical information of other numerical values. The output of the OCR engine is then operated on by a code location method (including various submethods) 97 to determine the best guess N-code string. The correction algorithm 98 is used to convert the best guess string into the final N-code, thereby resulting in the reproduction of the original numerical value or data. The algorithm is preferably checked for completeness of the result.

In addition, the present technology provides a method for providing a backup identification and authentication of the N-code using a paper print version of the N-code in the event that the mobile device fails to scan. If not, the image captured by the phone cannot be read by the scanning device, but is still readable by a human operator who can bring the phone to a manually operated counter. This may be the result of, for example, a damaged screen of the telephone. A staff member operating the counter manually can type in the visible part of the N-code using a keyboard and appropriate software will reproduce the N-code and output a paper print of the N-code. The owner of the mobile device can then change to use the new paper print version and scan it as if the code were on the display of the mobile phone.

If none are able to be scanned, so that the image captured by the phone cannot be read by the scanning device, and also by a human operator, the owner of the mobile device may carry his/her own identification to the manually operated counter. The owner can simply inform his/her mobile phone number and provide his/her personal identification so that the system can use the mobile phone number to recover the N-code of the deactivated mobile device and print out a paper print similar to part a) above without having to physically read the onboard code.

As shown in fig. 10, in some embodiments, methods associated with the present technology may support more than the amount of data that an N-code may typically contain (where "amount of data" is the length or number of bits of ticket data that need to be decoded). For example, in a particular implementation, an N-code may encode 12 digits of data 101, but the ticket code requirement is for 20 digits 102. In some examples, for example, there may be a "window" of time (e.g., 4 weeks) to gradually produce a preparation for a sporting event and not require each individual 20-bit permutation. This solution requires 12-bit data 101 to be mapped (e.g., in real-time) to 20-bit data 102 located on the server side to efficiently meet the needs.

Once the validity period expires, the 12 bits of data can then be effectively deleted and thus reused for mapping in other periods. This continual updating of the 12-bit data source allows digits of smaller data amounts to be continually mapped into larger data groups.

If the transfer of the ticket needs to be performed, tracked and audited, a more complex mapping table 103 is required. When an owner of a ticket wants to transfer a valid ticket to others, once it is transferred out, the code mapping mechanism is required to deactivate the original owner's ticket and issue new valid tickets to the new owner that the original owner cannot use. This process is implemented by issuing a new valid ticket code 104 to the new owner while disabling the original ticket code with the valid status flag 105. The time of transfer is stored in the timestamp field 106. If the ticket is transferred multiple times, the process will repeat to record the number of transfers in the timestamp field 106 and the sample value in the data record 107, allowing for an adequate audit trail of transfers. This mapping table may optionally contain personal information, personal identity and payment details to provide a comprehensive mobile ticket transfer tracking system. This assignment-enabled availability may be implemented in availability service 1215 located in fig. 12. At the same time, all of these new and old ticket records are mapped to the same underlying original ticket code 108 from the original ticket issuer.

Another embodiment integrates the scanning and identification of N-codes into an existing paper-based scanning system without software or hardware integration by converting the user displayed N-code into a visually displayed barcode 115, as shown in fig. 11, the barcode 115 appearing as a paper barcode but displayed on an auxiliary screen 110 connected to the N-code scanning device. The auxiliary display screen may be physically separated 116 from the N-code scanning device 117 and connected to the scanning device 117 by a flexible wire 111 or wireless connection 112. In this way, the bar code on the screen can be effectively scanned by existing paper-based scanning devices. This allows existing scanning systems to identify the N-code at the retail or entry point without any physical integration with the system. If the secondary display screen is a touch screen, the touch screen layer would need to be removed to eliminate any excessive refraction that could result in some type of scanning device not being able to recognize the bar code displayed on the screen.

This method of establishing an N-code data format as a standard for the digital encoding of tickets and cards for mobile devices may provide compatibility for all other modes of transmission including, but not limited to, internet, wireless internet, MMS, 3G, GPRS, WiFi, WiMax, Bluetooth, NFC (near field communication) technology and RFID (radio frequency identification) in addition to the SMPP protocol for SMS (short message service). Short message service is currently the most popular network transport for N-code data format transmission, but as different network technologies prevail, such scanning devices, in addition to preserving the N-code data format to provide cross-industry consistency, forward and backward compatibility, can be continuously upgraded to support different types of transmission technologies.

For transmission technologies such as internet, 3G, GPRS, Wi-Fi, WiMax and Bluetooth, this N-code data format is simply transmitted over these network transmissions, similar to the transmissions in SMPP. Such N-code strings may be transmitted in a 3G network by means of e-mail, or as data packets in Wi-Fi or Bluetooth, for example. The contents of this N-code data format are not changed by the network technology and thus can be scanned by a display screen of a receiving device or printed on paper for scanning.

For field test technologies, such as NFC and RFID, where the client device contains an identification tag wirelessly identifiable by the scanning device, the identification code of such a device is then converted into a ticket or card number located on the server side, and this N-code data format is also used to store ticket information on the identification tag, or to store ticket and card information on the server side, or to identify the ticket information within the user interface of the mobile device itself. This provides a continuity of user experience between the SMPP borne N-code ticket and the NFC borne or RFID borne ticket.

In the user-side device that will support it, the user will benefit by creating an electronic or graphic "folder" structure (a hierarchical file structure using graphic symbols) that can be used to store N-code mobile ticket and card information in separate areas for easy retrieval and management by the user of the mobile device. For example, the user may graphically or otherwise select "my short message service info" to read general information and "my mobile ticket" to be used only for ticket discovery. This also means that mobile tickets can be easily found and are not easily accidentally deleted. Likewise, separate folders or subfolders may be created for use as different types of ticket folders. For example, "authentic and" unreliable "tickets or" reusable tickets & cards "or" disposable tickets "may each be stored in separate folders.

Any of the disclosed methods may be implemented with PIN-code secure access for certain types of tickets or folders. For example, a certain ticket or a mobile carrier card may need to be encrypted. To open that folder or ticket, the PIN code established by the user needs to be entered into the phone. Such a PIN is recognized, or not, and acted upon by software on the user device. This will prevent anyone from accessing those encrypted tickets or cards, even if someone gains illegal access to the mobile device.

In some embodiments, such transmissions of mobile tickets and displays like these may include originating telephone numbers, originating contact names, content of messages, such information not within the scope of the N-code portion. This provides a more convenient way for a user of the mobile device to find the relevant ticket for scanning.

In a particular embodiment, a customer premises device such as a mobile phone will automatically detect an N-code ticket introduced to the phone. By analyzing the content of the message, the mobile device can recognize such an N-code ticket and thereby process it differently from information that does not contain an N-code. For example, it may send a notification signal "new ticket received" instead of notifying the user of "new information" and store the ticket in the above ticket folder structure, either automatically or by user prompt. Further, such a reminder may allow the user to decide where to place the ticket, whether it should be placed in a "spent ticket folder," "reusable ticket folder," or "encrypted ticket folder," etc. Also, in view of ease of recovery and revocation of a delete, a delete ticket can be handled differently from a delete plain telegram. These features can be fully implemented in the "ticket holder" client software component 1210, which is internal to all mobile ticket service organizations shown in detail in fig. 12.

This technique can use the non-N-code portion of the ticket information for value-added purposes, if desired. One normal length SMS message is 160 characters in length, meaning that in addition to the N-code, other content to be transmitted to the mobile device can be used on the remaining sequence of 125 characters, depending on the format of the N-code. For example, the information comprising the N-code may comprise help information such as: please retain this information and attend if allowed. If lost, the short message service 04111-N code is sent. It may contain branding information from the supplier such as "X brand cinema N-code ticket". It may contain third party advertisements such as: why did not get X brand iced tea on the way to the movie theatre? ". Alternatively, the mobile ticketing services bureau can obtain intelligence of specific consumption behaviors that can be used to deliver targeted advertising on information that is useful to the user and paid for by the advertiser. Alternatively, the ticket may be delivered as or carrying MMS (multimedia messaging service) content to contain additional audio or video information that provides a richer advertising experience for the user of the mobile device.

In some examples of such techniques, a wireless and or legacy network may be established between the central control server and the N-code scanning device used, so that the central centralized server may remotely modify the software located on the scanning device for periodic upgrades and diagnostics. For example, scanning devices may be set to pass back images that they cannot decode, or they may be set to periodically look for software or operating system upgrades. The scanning device may also be set to perform an automatic restart or a self-recovery in order to reduce the required support to a minimum.

Another embodiment provides an end-to-end N-code mobile ticketing service, as shown in fig. 12. Such services may provide ticketing services to all mobile devices, such as mobile telephone handsets, Personal Digital Assistants (PDAs) and pagers, which have text display means and preferably software components to apply the above-described N-code encoding and decoding processes. Referring to fig. 12, the following paragraphs describe the components of such a system and their interaction in a preferred short-time flow control manner. This ticket-seller portal 1201 is a WAP or internet web portal that provides the end user with a method of selecting from a range of N-code tickets for sale. As shown (display screen 1202 of the mobile device), such tickets are sorted and the end user selects the desired N-code ticket through the directory system. The end user is provided with a payment option including direct payment or credit card payment as part of the mobile network operating bill. Such a ticket portal is configured to use the J2EE service application of the available payment clearing service. Once the portal is operated by the mobile telecommunications operator, the identity of the paying end user can be obtained by checking the mapping of the device address to the identity of the end consuming user.

A WAP enabled mobile phone handset 1202 used by a user accesses a ticket sales portal 1201WAP services. Alternatively, the ticket sales portal 1201 internet service may be accessed by the user via a personal computer or other HTTP protocol enabled device. Alternatively, the user may also be physically present at a physical point of sale, such as a movie theater ticket office or a travel agency, where a sales assistant accesses the ticket sales portal on behalf of the user. Such services may be integrated with ticket issuance databases 1207 and mobile ticket transformations 103 to deliver ticket sales from a secondary market, i.e., second-hand ticket sales.

The user's mobile handset 1202 accesses the ticket sales portal 1201 using WAP protocols 1203 (such as GPRS or W-CDMA) spread over the cellular transport bearer. Alternatively, HTTP or other service transport protocols may be used throughout wired or wireless bearer and communication networks.

A request to issue 1204 an N-code ticket is transmitted by the portal 1201 to the ticket issuing service 1205. This request is a SOAP/XML web services request that is securely transported over a wired network using TLS with TCP/IP. Alternative protocols spread over other bearer and network infrastructures, such as CORBA or other RPC protocols, may be used. Such requests include the identity of the user operating such an entry 1201, the identification of the ticket required to generate the N-code ticket, the textual identifier of the ticket service and the point in time or validity of the ticket for entry to the ticket location.

The ticket issuing service 1205 verifies the authenticity of the request 1204 and the current contract and financial status of the user operating such sales portal 1201. If the transaction is validated, the N-code ticket is issued to the end user by generating the N-code string from request 1204 by the N-code encoding method described above.

A record 1206 of such issued N-code tickets is entered into a database 1207 of valid issued N-code tickets.

The issued ticket database 1207 is a relational database containing tables containing indicia representing sales agent identity, end user identity and mobile phone number, ticket event, date of issue, and status of issue. This issue status indicates pending issue, issue complete, require reissue, reissue complete, cancel request, validate complete, require resale, resale complete. The resale status of the ticket enables the user to offer the resale ticket by means of a private sales or internet auction address, such as the E-Bay service. The process of reissuing, canceling and reselling a ticket can be readily implemented by those skilled in the art. The invalidation of sold tickets and validation of purchased tickets at the validation server 1215 due to ticket code transformation codes is described in detail in the previous implementation and is described by the mapping table 103.

The N-code ticket 1208 is transmitted to the mobile device 1209. Such a mobile device 1209 is typically the same device as the phone 1202. This N-code ticket is transmitted as an SMS/GSM short message. Alternatively, tickets may be transmitted using other messaging and mail protocols, such as EMS, Nokia Smart messaging, MMS or POP3, and other wireless bearer carriers, such as 1x-RTT/CDMA, W-CDMA, Wi-Fi, Bluetooth, or even optical bearer carriers such as IrDA or wired bearer carriers, such as USB, or proprietary protocols for special devices such as Blackberry wireless mail.

The mobile phone handset 1209 having a short message service function receives a short message service message containing the encoded N-code ticket. The mobile handset preferably contains a ticket holder 1210 that stores a ticket that has been identified as an N-Code ticket by an initial "Start N-Code" string. Alternatively, the information may be identified as an N-code ticket using a string of other format features such as a put-or-mark. A mobile phone handset that is not capable of executing a ticket folder typically stores the message in a built-in short message service inbox or other similar message store.

Ticket clip 1210 is an integral part of mobile device 1209. The ticket folder stores N-code tickets indexed by ticket event type and point in time or completion period. The ticket holder provides a user interface that enables an end user to browse through stored tickets by presenting a menu of tickets commanded by time type or finalization period. The ticket folders preferably present the tickets in increasing order of time so that the next ticket event that the end user is about to attend is displayed at the very top of the catalog for presentation to the ticket scanning device 1213 for access. This ticket folder is implemented as a Java MIDP operation executing on mobile device 1209, rather than using other operating platforms, such as BREW or Symbian/C + +. Such a ticket holder also enables the end user to cancel, delete or resell selected tickets. These functions are performed by the ticket holder transmitting a request to the ticket issuing service 1205 by way of a cellular wireless GPRS or other bearer circuit. These interactions are not shown in fig. 12 for the purpose of avoiding over-complication. Those skilled in the art can readily implement these N-code ticket based functions as a key to querying and changing database 1207 records. The functional features of these folders are described in detail in the above embodiments as illustrative "folder" structures that enable the efficient management of N-code tickets on a user device.

After receiving the N-code ticket, and prior to locating the ticket location or service, the end user invokes the user interface 1211 of the ticket holder function 1210 on the mobile phone handset 1209 to present the selected ticket. Typically this is the top most note displayed in chronological order. This function causes the ticket to be displayed on the mobile device display screen. Alternatively, in the case where the mobile device does not support a ticket holder, the end user is required to select the appropriate N-code short message from a short message service inbox or similar message store.

When the end user desires access to a ticket kiosk or service, he presents a mobile device display 1212 with an N-code ticket in front of a ticket scanning device in the field of view of the image sensor used by the ticket scanning device 1213. This bill scanner 1213 panel provides a graphical display showing the proper placement of the mobile device.

Such ticket scanning device 1213 implements the decoding function of the N-code ticket as described in detail previously in this disclosure. Such ticket scanning devices provide a user feedback audio to indicate that the information located on the mobile device display 1212 has been successfully scanned. Such ticket scanning device attempts to authorize access by the following step 1214-1216 described below. If the ticket is successfully scanned, a user feedback audio is emitted to indicate a successful scan. If the scanning process determines that the ticket is invalid, information indicating the reason for the failure is displayed to the end user. The ticket scanning device can selectively indicate a notification signal or send notification information to a manager of the ticket location.

To validate that the scanned N-code ticket is valid, such ticket scanner 1213 submits a request to the ticket validation service 1215 before authorizing access to the ticket site or service. The authentication request is a SOAP/XML web services request transmitted securely using TLS and TCP/IP protocols. Such a request is transmitted over a wired local area network Wi-Fi network connection. Alternatively, other network protocols, bearer bearers and infrastructures may be used. Such ticket scanning apparatus can be configured to efficiently receive formatted N-code tickets if a validation request cannot be made due to a network outage or other malfunction. In this case, the authentication request is stored by the scanning device, and authentication is performed as soon as the failure is cleared.

To ensure that the validation request 1214 is transmitted by the authorized ticket scanner 1213, such ticket validation service 1215 validates the validation request 1214. The authentic request results in checking 1216 the ticket database 1207. In the event that such a check confirms that a valid N-code ticket has been presented, the scanning service indicates this in terms of its recovery of the scanning device 1213. If the check determines that the ticket entry is invalid, a negative indication and code indicating the reason for the failure is provided to reply to the scanning device 1213.

To authorize access to a ticket site or service, the database 1216 of issued tickets is queried using the SQL query language to ensure that the N-code ticket is authentic, i.e., its status has not been revoked or resell, and it has not been used to gain access. If the ticket passes these checks, the status of the ticket is updated as the scan is completed, indicating that the ticket has been used. In addition, the timestamp and ticket scanning device identity may be stored in order to track incoming transactions. The ticket scanning device may also optionally use its image capture capability to capture, in conjunction with capturing the ticket, other types of image information, such as identification documents, such as a driver's license, photo identification card or passport, or additional marking information, such as a label or bar code from a good, a signature, such as a signature on a check, or a person requesting access captured using another digital camera. Such images and other additional information may be transmitted to the verification service 1215 and stored in this database 1216.

If the ticket scanner 1213 determines that the N-code ticket is valid, it provides a signal 1217 to the winding rod or other access mechanism to indicate that access to the ticket event or service is authorized.

Note that the system shown in fig. 12 may use alternating framing of an encoded ticket as described on the display of mobile device 1209. In this case, the use of the "+" character enables a more accurate estimation of the lateral character position. As shown, the last line of the code is marked with a combination of "+" and "-" signs to enable possible extension of the code. This last line of discriminative framing also enables the pre-processed image to determine, when presented to the scanning device, that the screen is to be inverted and simple pixels changed based on the vertical image are performed before the light character is identified.

The system with its component elements 1201 to 1217 detailed in fig. 12 allows for a forward upgrade to other types of near field ticket identification technologies that may be used when implementing the method detailed in the above embodiments of the present disclosure with respect to standardizing the N-code data format for mobile ticketing, including optical methods such as bar codes, audio, or radio such as RFID and NFC.

Although the present invention has been described with reference to specific details, these should be understood as exemplary and not as limitations on the scope of spirit of the invention.

Claims (20)

1. A method for encoding information and transmitting the encoded information to a device capable of displaying the encoded information as visible alphanumeric characters, comprising the steps of:

converting the n-bit information into a binary format;

dividing the binary format into x-bit binary words, wherein x is the same as the maximum number of bits of data required for each data character in a predetermined data character mapping table;

converting the x-bit binary word into a character sequence by using the data character mapping table;

inserting special markers into the sequence to distinguish the sequence into character groups separated by one or more special markers;

inserting one or more special markers at the beginning and end of the sequence; and

line feed command symbols are inserted into the sequence prior to transmission.

2. The method of claim 1, wherein x is 4 or 5.

3. The method of claim 1, wherein the data character mapping table excludes one or more alphanumeric characters from visual confusion with other characters.

4. The method of claim 1, wherein the special marker is a symbol ═ symbol.

5. The method of claim 1, wherein the line feed commander divides the sequence into portions that are visually displayed upon receipt by a user device to be two or more lines of equal length.

6. The method of claim 5, wherein each row starts and ends with one or more special markers.

7. The method of claim 5, wherein each row is subdivided by one or more special markers.

8. Scanning apparatus for reading a visual code and acquiring data from a captured image, comprising:

an image capture device;

an optical character recognition engine that takes as input an image from the image capture device and takes as output a guess of the character and a position for each character from a geometric display of the character;

software for identifying a rectangular target area based on a special marker appearing in the output;

means for subdividing the target area into a plurality of groups having a predetermined size and a predetermined position to establish expected character position values;

software for combining the character guesses and character positions from the optical character recognition engine with the expected character position values to obtain a best guess result;

software for converting the best guess result to binary; and

one or more modules for applying a data correction or recovery technique to the binary to achieve a goal of obtaining data.

9. The scanning device of claim 8, further comprising a divergent light source for minimizing portions of light in the captured image.

10. The scanning device of claim 8, further comprising software for skew removal of the captured image.

11. The scanning device of claim 8, further comprising a printer for providing a print pattern of the data.

12. The scanning device of claim 8 further comprising an auxiliary display on which said data is displayable.

13. The scanning device of claim 12, wherein the auxiliary display is physically separate from but functionally connectable to the scanning device.

14. Method for decoding visual characters into original information data, comprising the steps of:

capturing an image of a user display;

applying an optical character recognition engine to the image, the engine taking as output character guesses and the position of each character;

identifying a target region from a special marker present in the output;

obtaining a character string from characters in the target area;

converting the character string into a binary system; and

data correction or recovery techniques are applied to the best guess to obtain the data.

15. The method of claim 14, further comprising the steps of:

subdividing the target area into a plurality of groups having a predetermined size and a predetermined position to establish predetermined character position values;

combining the character guesses and character positions from the optical character recognition engine with the predetermined character position values to obtain a best guess for the character string.

16. The method of claim 14, wherein the string is an alphanumeric string.

17. The method of claim 14, wherein,

obtaining the character string further includes comparing the character guesses and character positions from the optical character recognition engine to an expected character position value mapping table to obtain a best guess.

18. The method of claim 14, further comprising the steps of:

the decoded original information data is mapped to generate data having a data length greater than the decoded original information data.

19. The method of claim 14, further comprising the steps of:

characters that are outside the target region, albeit as part of the transmission, are not decoded.

20. The method of claim 14, wherein the target region is predetermined to be rectangular,

it comprises two or more equal lines of characters and is delimited by said special marker.