USPatent applicationPatented

Duplicate check detection

Granted 17 Dec 2013 · 1 office action

Application· this page
13/722,576
filed 20 Dec 2012
Publication
Not published
not published
Patent
US 8,611,635
granted 17 Dec 2013

Life of the application

7 dated events
⤢ drag to zoom2014201620182020202220242026202820302032ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

Images from checks may be compared with each other to detect a twice-deposited or represented check. An image of a check may be parsed into regions or tiles, for example. In an implementation, values for regions or tiles over a predetermined area (e.g., an area from a character in the magnetic ink character recognition (MICR) line at the bottom of the check to the dollar sign symbol) may be compared. In an implementation, a virtual overlay of two check images may be performed and a correlation may be determined.

Description

10 parts
›CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patent application Ser. No. 12/137,051, filed Jun. 11, 2008, the entirety of which is hereby incorporated by reference herein.

›BACKGROUND

Currently, a user may deposit a check in a financial services institution either electronically using scanning and imaging techniques or physically by presenting the check at the financial services institution. Fraud occurs when a user presents the same check twice for deposit (e.g., once electronically and once physically, twice electronically, etc.). This may be referred to as check representment.

It is difficult to detect a check that is represented or deposited twice by a user. Conventional techniques used to detect a represented or twice-deposited check rely on matching a deposit amount entered by the user when electronically depositing a check and a deposit amount obtained through character recognition technologies for a physically deposited check. Additional techniques compare magnetic ink character recognition (MICR) lines and/or account numbers.

›SUMMARY

Images from checks may be compared with each other to detect a twice-deposited or represented check. An image of a check may be parsed into regions or tiles, for example.

In an implementation, values for regions or tiles over a predetermined area (e.g., an area from a character in the magnetic ink character recognition (MICR) line at the bottom of the check to the dollar sign symbol) may be compared.

In an implementation, a virtual overlay of two check images may be performed and a correlation may be determined.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

›BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the embodiments, there are shown in the drawings example constructions of the embodiments; however, the embodiments are not limited to the specific methods and instrumentalities disclosed. In the drawings:

FIG. 1 is a block diagram of an implementation of a system in which example embodiments and aspects may be implemented;

FIG. 2 is a block diagram of an implementation of a system that may be used to detect duplicate checks;

FIG. 3 is a diagram of a check showing various features that may be used in duplicate check detection;

FIG. 4 is a diagram of a check showing regions or tiles that may be used in duplicate check detection;

FIG. 5 is an operational flow of an implementation of a method that may be used in duplicate check detection;

FIG. 6 is an operational flow of another implementation of a method that may be used in duplicate check detection;

FIG. 7 is an operational flow of another implementation of a method that may be used in duplicate check detection;

FIG. 8 is an operational flow of another implementation of a method that may be used in duplicate check detection; and

FIG. 9 is a block diagram of an example computing environment in which example embodiments and aspects may be implemented.

›DETAILED DESCRIPTION · 1 of 6

FIG. 1 is a block diagram of an implementation of a system in which example embodiments and aspects may be implemented. The system 100 may include a user 105 and an institution 130 , which may be any type of entity capable of processing checks and/or providing funds associated with checks. For example, the institution 130 may be a retail bank, an investment bank, an investment company, a regional branch of the Federal Reserve, a clearinghouse bank and/or a correspondent bank. A representative 135 of the institution 130 may provide assistance as described further herein.

The user 105 may be an individual who owns an account 165 that may be held at the institution 130 . The account 165 may be any type of account such as a loan, a savings account, a checking account, a brokerage account, and the like. Although only one account 165 is shown, it is contemplated that the user 105 may have any number of accounts held at the institution 130 . The user 105 may deposit a check 110 in the account 165 at the institution 130 either electronically or physically. The financial institution 130 may process and/or clear the check 110 . An example check 110 is described with respect to FIG. 3 .

The user 105 may communicate with the institution 130 by way of a communications network such as an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a public switched telephone network (PSTN), a cellular network, a voice over Internet protocol (VoIP) network, and the like. The user 105 may also communicate with the institution 130 by phone, email, instant messaging, facsimile, postal mail, and the like.

When the institution 130 receives the check 110 for processing and clearing, the institution 130 may compare an image of the check 110 or one or more portions of an image or images of the check 110 with one or more images or portions of an image or images of checks that had been previously received by the institution 130 , described further herein. The comparison may be used to determine whether the check 110 has already been presented to the institution 130 for processing and clearing.

In an implementation, an image of a first check may be compared with an image of a predetermined check (e.g., a “control” or “ideal” check) to generate a first result, and an image of a second check may be compared to the image of the control ideal check to generate a second result. The two results may be compared to determine whether the first check and the second check are duplicates. If the two results are identical or similar above a predetermined threshold, then it may be determined that the first check and the second check are duplicates.

FIG. 2 is a block diagram of an implementation of a system that may be used to detect duplicate checks. An institution system 205 is associated with the institution 130 and may include a user interface module 220 , a duplicate detection engine 221 , and a data source access engine 224 . The user interface module 220 may generate and format one or more pages of content 219 as a unified graphical presentation that may be provided to a user computing device 107 or a representative computing device 137 as an output from the duplicate detection engine 221 . In an implementation, the page(s) of content 219 may be provided to the user computing device 107 and/or the representative computing device 137 via a secure website 218 associated with the institution system 205 . An example computing device is described with respect to FIG. 9 .

In an implementation, the institution system 205 may use an image generator 222 , comprising a scanner for example, to generate a digital image (also referred to herein as an image) of the check 110 . The scanner may be a generic device for capturing images or a sequence of images at a time or over a period of time, and may include processing multiple frames of the image if the image is comprised of multiple frames over a set period of time. The digital image may be used to create a digital image file for use by the financial institution 130 to process the check 110 and or other checks that may be received for processing and/or clearance.

For example, after receiving the check 110 , the institution system 205 may use a device such as the scanner and/or one or more computing device(s) 206 for example, to convert the check 110 into a digital image file by making a digital image of the front and/or back of the check 110 and storing the digital image(s) in a digital image file.

The computing device(s) 206 may be integral with the device used to make the digital image and/or the digital image file or separate from the device used to make the digital image and/or the digital image file. An example computing device is described with respect to FIG. 9 . It is contemplated that any device that is capable of generating a digital image may be used to make a digital image of the check 110 . Additional devices that may be used in the generation of a digital image file include a digital camera, a photocopier, a fax machine, and the like, for example.

The institution 130 may use any known image processing software or other application(s) to obtain the relevant data (described further herein) of the check 110 from the digital image. The institution 130 may determine whether the data retrieved from the check is duplicative of the data of another check previously received by the institution 130 .

For example, the financial institution 130 may include any combination of systems and sub-systems such as electronic devices including, but not limited to, computers, servers, databases, or the like. The electronic devices may include any combination of hardware components such as processors, databases, storage drives, registers, cache, random access memory (RAM) chips, data buses, or the like and/or software components such as operating systems, database management applications, or the like.

The duplicate detection engine 221 has access to data, files, and documents pertaining to the user 105 as well as any other data, files, and documents that may be useful in detecting duplicate checks that are currently stored by the financial institution 130 as well as external data, files, and documents.

›DETAILED DESCRIPTION · 2 of 6

The institution system 205 has the ability to retrieve information from one or more data sources 229 via a data source access engine 227 . Data pertaining to the user 105 and/or the user account 165 and/or processing and clearing of a check may be retrieved from data source(s) 229 and/or external data sources. The retrieved data may be stored centrally, perhaps in storage 208 . Other information may be provided to the institution system from the user 105 and/or the representative 135 .

Data source(s) 229 may contain data, metadata, email, files, and/or documents that the institution system 205 maintains pertaining to the user 105 , such as personal data such as name, physical address, email address, etc. and financial data such as credit card numbers and checking account numbers. Such data may be useful for detecting duplicate checks. The institution system 205 may access this information when processing or clearing a check to determine if a check has already been presented for deposit.

The duplicate detection engine 221 may include a region/tile generator 223 and a comparator 224 . The region/tile generator 223 may generate regions and/or tiles based on images of checks. The regions and/or tiles of multiple checks may be compared by the comparator 224 . As described further herein, the regions and/or tiles may be used in the detection of duplicate checks.

The region/tile generator 223 may receive data from the image generator 224 , the user computing device 107 , the representative computing device 137 , and/or may access data in the data source(s) 229 and/or the external data source(s) in generating regions and/or tiles for use in duplicate check detection. After retrieving or otherwise receiving the data from the various sources, the region/tile generator 223 may use tools and applications, for example, to generate regions and/or tiles for subsequent analysis.

The representative computing device 137 may provide access to a system which is coupled to the institution system 205 . A system may be configured to format and transmit a graphical user interface to the representative 135 , and through the graphical user interface provide the representative 135 the ability to interact with information that may be maintained, requested, and/or provided by the institution system 205 .

A user access system may be communicatively coupled to the duplicate detection engine 221 and may be configured to send machine-readable instructions to the duplicate detection engine 221 .

As mentioned above, the institution system 205 may provide a unified graphical presentation output. The unified graphical presentation may be transmitted to the user access system. In an implementation, the unified graphical presentation is combined with other materials and transmitted to the representative 135 . In an implementation, the unified graphical presentation is received by the user access system and transmitted directly to the representative 135 without the inclusion of any other materials.

The user access system may be implemented as a web server in an implementation. The user access system, through the use of any suitable interactive web technology, provides an interactive experience to the user 105 and/or the representative 135 through which access to check processing and clearing data and status and related data can be accomplished. Any technology that provides interactivity through a web browser is considered to be within the scope of the present discussion and may include, without limitation, Hyper-Text Mark-Up Language (HTML), Dynamic HTML (DHTML), JavaScript, and Ajax.

The institution system 205 may comprise one or more computing devices 206 . The computing device(s) 206 may have one or more processors 207 , storage 208 (e.g., storage devices, memory, etc.), and software modules 209 . The computing device(s) 206 , including its processor(s) 207 , storage 208 , and software modules 209 , may be used in the performance of the techniques and operations described herein.

Examples of software modules 209 may include modules that may be used in conjunction with scanning a check 110 , receiving an image of the check 110 , retrieving data pertaining to previously processed checks, generating web page content for display, and receiving instructions from a representative, for example. While specific functionality is described herein as occurring with respect to specific modules, the functionality may likewise be performed by more, fewer, or other modules. An example computing device and its components are described in more detail with respect to FIG. 9 .

FIG. 3 is a diagram of a check 110 showing various features that may be used in duplicate check detection. The check 110 may comprise a MICR line 310 , a signature line 312 , a courtesy amount line 314 following a dollar sign (“$”) 316 , and a legal amount line 318 . As described further herein, a line 320 may be determined between two features, such as a character 322 on the MICR line 310 and the dollar sign 316 . A coordinate 325 is shown. As described further herein, the features, the line, and the coordinates may be used in duplicate check detection. It is contemplated that any points, coordinates, features, or regions of interest on the checks may be used with the techniques described herein.

FIG. 4 is a diagram of a check 110 showing regions or tiles 410 that may be used in duplicate check detection. As described further herein, in some implementations, an image of the check 110 may be parsed into regions or tiles 410 . The regions or tiles of two checks may be compared with each other to determine a similarity between the two checks.

FIG. 5 is an operational flow of an implementation of a method 500 that may be used in duplicate check detection. At operation 505 , an image of a first check may be received, e.g., by remote or electronic deposit, or the first check may be received by physical deposit and an image of the first check may be generated. At operation 510 , the image of the first check may be stored in storage.

›DETAILED DESCRIPTION · 3 of 6

At some point, at operation 515 , an image of a second check may be received, e.g., by remote or electronic deposit, or the second check may be received by physical deposit and an image of the second check may be generated. At operation 520 , the image of the second check may be stored in storage. In an implementation, a gray scale image of each check may be captured, and for each image, the gray scale image may be converted to a binary image with adequate thresholding or other binarization method.

The images of the first check and the second check may be compared to determine if they are duplicates, in which case it may be determined that the same check has been represented or deposited twice. At operation 525 , one or more features on the images of the checks may be isolated. The feature(s) on the checks may be compared with each other at operation 530 to determine if the checks are duplicates. Any comparison technique(s) may be used. If the checks are determined to be duplicates or similar enough to exceed a predetermined threshold, then the user and/or a representative may be advised at operation 535 , and funds pertaining to the second check may not be released at operation 540 . Otherwise, the check is accepted and the funds may be released.

In an implementation, a batch type process may be used. In such a case, funds for a check may be dispersed immediately. If a duplicate check is detected later in the batch process, a hold on the account may be applied or funds may be removed from the account that was previously credited.

In an implementation, one or more specified regions of the image of a check may be stored in storage for future comparison (e.g., the image region contained within the boundaries of the first MICR character and the dollar sign). This may save future processing time in finding this region for comparison and duplicate check detection. The regions may be stored in a database and search on, for example, by MICR and routing number to determine if there are any preprocessed checks to compare. This may be done as a batch process or in real time, for example.

FIG. 6 is an operational flow of an implementation of a method 600 that may be used in duplicate check detection. After the images of the first and second checks are received using processing that may be similar to operations 505 - 520 described above with respect to the method 500 , the images may be deskewed and a location such as a coordinate of a first feature (e.g., a character of the MICR line) of each image may be obtained at operation 625 . Any known deskewing technique(s) may be used. A location of a second feature of each image (e.g., the dollar sign) may be obtained at operation 630 . Any technique(s) such as optical character recognition (OCR) may be used to obtain the features.

Regions or tiles around the features on each image may be determined at operation 635 . Alternatively or additionally, regions or tiles around a line (e.g., the line 320 described with respect to FIG. 3 ) between the coordinates of the two features on each image may be determined. One or more angles may be determined with respect to an edge or corner of the check image or the line, for example. The angles may be used in region or tile determination. A center point of the check image may be determined and used in region or tile determination. In an implementation, the images may be parsed into virtual squares or regions of interest, such as in a tile formation. In an implementation, the regions or tiles may be determined and analyzed around the center of the line of sight between the first character of the MICR line and the dollar sign symbol. This is an area that likely will not change when a check is represented.

Values for each region or tile may be determined at operation 640 . Any technique for associating a value to a region or tile may be used. Mathematical functions, such as wavelets, Fourier analysis, etc., may be used to link a relational value to each region or tile on each image. Image wavelet theory may be used by obtaining a frequency of each region or tile and using a Fourier domain analysis. It is contemplated that histograms may be obtained of the regions, tiles, or images, and used in the analysis.

The frequencies analyzed, e.g. in wavelets, may be used in comparison with the frequencies acquired in an image to be compared. A histogram of frequencies counted may be generated and it may be determined if histogram comparisons of frequencies may be related. An implementation of a frequency analysis may include an analysis of the top frequencies detected or top frequencies selected for comparison by a magnitude of the frequencies.

At operation 645 , the values for each region or tile on one image may be compared with the values for each region or tile on the other image. Any comparison technique(s) may be used as well as any thresholding technique(s).

If the checks are determined to be duplicates or the values are similar enough to exceed a predetermined similarity threshold at operation 650 , then the user and/or a representative may be advised and funds pertaining to the second check may not be released at operation 660 . Otherwise, it may be concluded at operation 670 that the checks are not duplicates and funds may be released.

FIG. 7 is an operational flow of another implementation of a method 700 that may be used in duplicate check detection. After the images of the first and second checks are received using processing that may be similar to operations 505 - 520 described above with respect to the method 500 , the images may be deskewed and parsed into regions or tiles at operation 725 .

At operation 730 , a virtual overlay of the check images may be created, aligning them on position, magnitude, and/or angles that may be obtained from the images (e.g., using techniques described with respect to the method 600 ). At operation 735 , the regions or tiles of one image may be correlated to the regions or tiles of the other image, e.g., around the center of the line from the first character of the MICR line to the dollar sign. The regions or tiles may be compared region by region or tile by tile. Each comparison may have a correlation score between zero and one (or 100 percent). The correlations and numbers of correlations may be compared to predetermined thresholds and each region or tile of an image may be considered to “pass” or “fail” in a comparison with the corresponding region or tile on another image. In an implementation, “pass” may refer to the regions or tiles that have a low correlation score and thus may be considered dissimilar, and “fail” may refer to the regions or tiles that have a high correlation score and thus may be considered similar.

›DETAILED DESCRIPTION · 4 of 6

The amount of correlation is considered at operation 740 to determine if a similarity threshold is exceeded. If there is a high correlation and a large number of correlations that are a value close to one (or 100 percent) (or there are a high percentage of “fails”), then it may be concluded at operation 750 that the images are similar enough to be considered duplicates, and thus the checks are duplicates. The user and/or a representative may be advised at operation 760 , and funds pertaining to the second check may not be released. Otherwise, it may be concluded at operation 770 that the images are not duplicates, and thus the checks are not duplicates and funds may be released.

Alternative or additional to using features from the front of the check in the detection of duplicate checks, features from the back of the check may be used. For example, on the back of the check, one of more letters of the word “endorse” may be used as a reference point from which to parse regions or tiles, such as those regions or tiles that may contain portions of an endorsing signature. Those regions or tiles on the two checks may be compared to each other in the detection of duplicate checks, using techniques described herein for example.

FIG. 8 is an operational flow of another implementation of a method 800 that may be used in duplicate check detection. Images may be analyzed, e.g., when initially received, and may stored for further analysis at a later time. At operation 810 , an image of a check is received. At operation 820 , an analysis of the image may be performed, e.g., using techniques described herein. At operation 830 , it may be determined if there is a match between the received image and a stored image. If there is a match, the check corresponding to the received image may not be accepted and the user may be advised at operation 835 . If there is no match, the check corresponding to the received image may be tentatively accepted at operation 840 , and the user may be advised. In an implementation, a hold (e.g., a 24 hour hold, etc.) may be placed on the check at operation 850 before funds can be withdrawn. The results of the analysis may be stored at operation 860 .

At a later time (e.g., overnight, at a particular time, etc.), at operation 870 , the results may be retrieved. A further analysis may be performed on the received image at operation 875 , e.g. using techniques described herein and/or a representative associated with the institution system. The further analysis may be more detailed than the previous analysis. In an implementation, the further analysis may be performed only if no match had been determined at operation 830 .

At operation 880 , a determination may be made whether or not to accept the check based on the further analysis. If the check is to be accepted, the user may be advised and the funds associated with the check may be released at operation 885 (e.g., a hold on the funds may be removed). If the check is not to be accepted, the user may be notified at operation 835 .

In an implementation, a comparison of two images of checks may be based on comparing extracted pseudo-random features from the images. Features of the image may be selected to demark the region of interest, and may include the dollar sign, the start of the MICR line, and the end of the signature. A fixed number of small regions may be selected and their binary representation as features may be used. It is noted that not all regions may have equal significance in identifying the duplicity of a check. Depending on the angle of capture and content, for example, some regions may be considered better candidates for determining duplication. A number of features n may be selected, and a random number k of those features may be stored, where k<n. For a comparison, a previous image may supply the k features to be used in a comparison. A new image may be stored with a random selection from its n features. A duplicate may be determined using a distance metric between the features. Significant areas of the check may be those containing identifying information on the payee and those areas using less image correction. If features are used from areas that may use correction, then a weighting factor can be applied to allow a statistical margin of error.

Randomizing the features used for comparison may provide further security. Consider an example of extracting five features from an image. Three features (e.g., features 1, 3, and 5) may be randomly selected and stored. When a new image is supplied, the five features may be extracted, but only features 1, 3, and 5 may be compared to the previous image's features to check for duplication. When the new image is to be stored, three of the five features may be randomly picked for storage.

Although the examples described herein may refer to comparing images of checks and detecting duplicate checks, it is contemplated that any negotiable instruments may be compared to determine duplicates. Additionally, any images may be compared for similarity using the techniques described herein.

Exemplary Computing Arrangement

FIG. 9 shows an exemplary computing environment in which example embodiments and aspects may be implemented. The computing system environment is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality.

Numerous other general purpose or special purpose computing system environments or configurations may be used. Examples of well known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, personal computers (PCs), server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, mainframe computers, embedded systems, distributed computing environments that include any of the above systems or devices, and the like.

Computer-executable instructions, such as program modules, being executed by a computer may be used. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Distributed computing environments may be used where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules and other data may be located in both local and remote computer storage media including memory storage devices.

›DETAILED DESCRIPTION · 5 of 6

With reference to FIG. 9 , an exemplary system for implementing aspects described herein includes a computing device, such as computing device 900 . In its most basic configuration, computing device 900 typically includes at least one processing unit 902 and system memory 904 . Depending on the exact configuration and type of computing device, system memory 904 may be volatile (such as RAM), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 9 by dashed line 906 .

Computing device 900 may have additional features and/or functionality. For example, computing device 900 may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in FIG. 9 by removable storage 908 and non-removable storage 910 .

Computing device 900 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computing device 900 and include both volatile and non-volatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media.

Computer storage media include volatile and non-volatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. System memory 904 , removable storage 908 , and non-removable storage 910 are all examples of computer storage media. Computer storage media include, but are not limited to, RAM, ROM, Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computing device 900 . Any such computer storage media may be part of computing device 900 .

Computing device 900 may also contain communication connection(s) 912 that allow the computing device 900 to communicate with other devices. Communication connection(s) 912 is an example of communication media. Communication media typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. The term computer-readable media as used herein includes both storage media and communication media.

Computing device 900 may also have input device(s) 914 such as a keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 916 such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length here.

Computing device 900 may be one of a plurality of computing devices 900 inter-connected by a network. As may be appreciated, the network may be any appropriate network, each computing device 900 may be connected thereto by way of communication connection(s) 912 in any appropriate manner, and each computing device 900 may communicate with one or more of the other computing devices 900 in the network in any appropriate manner. For example, the network may be a wired or wireless network within an organization or home or the like, and may include a direct or indirect coupling to an external network such as the Internet or the like.

It should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an application programming interface (API), reusable controls, or the like. Such programs may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language and it may be combined with hardware implementations.

Although exemplary embodiments may refer to utilizing aspects of the presently disclosed subject matter in the context of one or more stand-alone computer systems, the subject matter is not so limited, but rather may be implemented in connection with any computing environment, such as a network or distributed computing environment. Still further, aspects of the presently disclosed subject matter may be implemented in or across a plurality of processing chips or devices, and storage may similarly be effected across a plurality of devices. Such devices might include PCs, network servers, and handheld devices, for example.

›DETAILED DESCRIPTION · 6 of 6

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims as granted

18 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

5 codes
IPC · International Patent Classification
Section G — Physics
  • G06K9/00
  • G06Q40/00
USPC · US Patent Classification
382/139382/175235/379

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJan 2013Apr 2013Jul 2013Oct 2013Jan 2014USPTOApplicantNon-final rejectionResponse after non-final
USPTOApplicanthover for detail · click to open
Pendency
1.0 y
362 days filing → grant
Office actions
1
non-final + final
Responses
1
no RCE
Examiner
Seyed Azarian
art unit 2667 · TC 2600
Citations: 947 back · 102 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20182020202220242026202820302032Owner 1
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock