ON-DEVICE processing typically requires a native SDK (Software Development Kit) or a ready-to-use plugin component that is used within another mobile application. All processing happens on the mobile device using device’s resources (CPU, memory, storage) without dependency, network connectivity or need to send/receive any data. Processing is typically very fast and takes a few seconds or less. Tools are typically more limited in functionality and capabilities and accuracy of OCR due to a more restricted processing environment. These tools are OS-specific and a unique versions is needed for iOS, Android and other well-known platforms. Typical platforms are:

OFF-DEVICE processing typically requires network or Internet connection to send the image to be processed on a backend server or a Cloud resource where a ready-to-use plugin component runs. All processing happens on the backend server using server’s resources (CPU, memory, storage). Processing of the actual image may be fast, but the addition of network transfers and uploads/downloads adds some seconds to processing, which needs to be accommodated in the design of user experience to prevent long waits. Tools are typically more advanced in functionality due abundance of processing power and thus capabilities of processing technologies such as AI (Artificial Intelligence) and ML (Machine Learning). These tools are typically powerful platforms that run on standard Windows or Linux platforms.

MRZ (Machine Readable Zone) is a specially formatted strategically-placed set of characters on documents that have MRZ. Not all, but many document types have this area, especially Passports. The zone, the font of characters used to print the data, the formatting and positioning of data within each line – everything is designed for machine recognition. Performing specialized OCR (Optical Character Recognition) on this area produces fast and highly accurate data recognition and data capture results. Since MRZ is limited in size and length, not all data generally available on ID is available from MRZ, but essential data is available.

PDF417 (2D barcode) is a specialized bacrcode available on many ID types. For example, since after 2009, PDF417 barcode is available on all United States driver licenses, Canada ID documents, and many Mexico INE cards. Performing specialized BCR (Bar Code Recognition) is very fast and efficient. PDF417 is a widely known open standard.

This data storage structure can pack hundreds of characters so typically all information available on an ID visually plus additional metadata can be included and extracted from a single barcode. Example:

Some IDs contain both MRZ and PDF417 data for redundancy and applicability across different processing techniques:

OCR (Optical Character Recognition) is a time-proven technology to convert image-based pictures of characters into digital text. It is based on machine vision and patterns recognition much like a human eye, so it does not require any special formatting – a normal human-readable text can be recognized. Performing generic or specialized OCR on different types of IDs can be done successfully, and can produce relatively fast and quite accurate data recognition and data capture results. OCR is prone to errors from heavy backgrounds obscuring and mixing with the text, so frequently a powerful image pre-processing and cleanup techniques are used to improve and prepare images for OCR.

⦁ OCR with Generic Text Parsing process is used to extract meaningful information from text returned from OCR. In this case any returned text is programmatically “searched” for expected data elements.
Example:
⦁ Find the text label “DOB:”
⦁ Find data type MM/DD/YYYY next to label
⦁ Conclude finding field type DOB
This search can be done without placement information, i.e. on the whole document, which makes this approach format-independent. Redundant search can be used to improve data finding in less-than-perfect scenarios, such as when DOB label could not be recognized because of OCR errors or heavy background, yet the date in format MM/DD/YYYY where the year starts with “19xx” (to filter out other dates such as expiration date or issue date) can still be found successfully.

⦁ OCR with Template-based Data Extraction process is used to extract meaningful information from text returned from OCR using specific knowledge of formatting and positioning of data. In this case any returned text is programmatically matched against a known “template” and then specifically “searched” for expected data elements specific to that template.
Example:
⦁ Find the markings to detect “California Driver License”, i.e. Classify the document and apply appropriate layout template
⦁ Find the text label “DOB:” on the 3rd line and left side of ID
⦁ Find data type MM/DD/YYYY next to label1, below another label0, and above another label2
⦁ Conclude finding field type DOB
This search is done with placement information, i.e. in specific areas, which makes this approach more accurate. But this approach requires creation and management of layout templates.

In the below example, even though a templated approach was used for California Driver License, it is visible that the captured text has both template-based errors (wrong data was captured) as well as OCR errors (some characters were recognized incorrectly)