Patent Publication Number: US-11392912-B1

Title: Image processing

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 16/502,489, filed Jul. 3, 2019, pending, which is a continuation of U.S. application Ser. No. 14/879,868 (now U.S. Pat. No. 10,373,136), filed Oct. 9, 2015 pending, which is a continuation of U.S. application Ser. No. 13/327,478 (now U.S. Pat. No. 9,159,101), filed Dec. 15, 2011, which is a continuation of U.S. application Ser. No. 13/301,433, filed Nov. 21, 2011, abandoned, which is a continuation of U.S. application Ser. No. 11/877,307, filed Oct. 23, 2007, abandoned, each of which are hereby incorporated by reference herein in their entirety. This application is related by subject matter to the following commonly assigned applications, the entirety of which are hereby incorporated by reference herein: U.S. patent application Ser. No. 11/877,335, U.S. patent application Ser. No. 11/877,367, U.S. patent application Ser. No. 11/877,382, and U.S. patent application Ser. No. 11/877,404, each filed on Oct. 23, 2007, and each entitled “Systems And Methods For Obtaining An Image Of A Check To Be Deposited”. 
    
    
     BACKGROUND 
     A check is a negotiable instrument. Formally, a check is an order that a “drawer” (the party who writes the check, and from whose bank account the money is to be drawn) issues to a “drawee bank” (the bank at which the drawer&#39;s money is located), and the order instructs the drawee bank to pay a “payee” (the party to whom the check is written). A check is negotiated by the payee&#39;s presenting the check to the drawee bank. The presentment process is normally initiated by the payee&#39;s bank, which presents the check to the drawee bank when the payee deposits the check with his or her bank. 
     Presentment of a check is normally done through the Federal Reserve or a commercial banking system. Traditionally, the mechanism by which this presentment occurs is by tendering the paper check through the banking system. The paper check is physically transmitted to the drawee bank, which either accepts and pays the paper check upon receipt, or declines payment and returns the paper check. Technological and legal developments, such as procedures set forth in the Check-21 law, allow images of checks (sometimes referred to as “substitute checks”) to be presented electronically without presentment of a paper copy. Thus, starting the presentment process may involve collecting an image of the check rather than obtaining the original paper check. Check scanners have traditionally been available to read the Magnetic Ink Character Recognition (MICR) line at the bottom of the check, and this information can be used for presentment. However, it is possible to present an ordinary image of a check, where the image is collected with ordinary image scanning equipment. 
     A customer can take the paper check to a bank for deposit and have the bank scan the check to obtain an image. However, it is also possible to collect the image of the check from the customer who is depositing the check. 
     SUMMARY 
     An image of a check to be presented for payment can be collected from a banking customer using the customer&#39;s scanning equipment. The customer can scan the check into one or more files (e.g., one file for the front, a second file for the back). The files can then be uploaded to a server operated by the customer&#39;s bank, and the images contained in the files can be presented through the banking system for payment by the drawee bank. 
     The customer&#39;s bank may operate software, such as software provided on a web site, that guides the customer through the process of obtaining the check images. For example, the customer may visit the bank&#39;s web site, and the web site may instruct the customer to obtain images of both sides of the check, may instruct the customer how to position the check in the scanner, may instruct the customer as to what image format and/or resolution to use, etc. The web site may also guide the user through the process of delimiting the boundary of the check, such as by identifying a corner of the check. The bank&#39;s software can also perform certain verifications on the check, such as verifying the check against legibility and/or size standards, verifying that there is an endorsement on the back of the check, verifying that the amount of money written on the check matches the amount that the customer has indicated in a deposit request, etc. 
     This summary is provided to introduce a selection of concepts in a simplified form that are further described 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 
         FIG. 1  is a diagram of a user interface that requests that a depositor enter an amount of a deposit. 
         FIG. 2  is a diagram of a user interface that requests that a depositor provide an image of a first side of a check. 
         FIG. 3  is a diagram of a user interface that requests that a depositor provide an image of a second side of a check. 
         FIG. 4  is a flow diagram of an example process whereby an image of a check is received and presented for payment. 
         FIG. 5  is a diagram of an example user interface in which a user marks a boundary of a check. 
         FIG. 6  is a flow diagram of various stages that can be performed after an image of a check is received by a bank from a depositor. 
         FIG. 7  is a block diagram of an example environment in which checks may be deposited and presented. 
         FIG. 8  is a block diagram of an example computing environment in which example embodiments and aspects may be implemented. 
     
    
    
     DETAILED DESCRIPTION 
     A web site can guide a user through the process of collecting images of a check to be deposited. In some cases, the web site can provide software, such as a browser-executable applet, that drives the process of collecting images by operating the customer&#39;s scanner. For example, after the customer enters an amount of a check to be deposited, the software provided on the web site can instruct the user to place the check in the scanner bed and to click a button when ready. The software can then cause the scanner to be started, can collect the image in an appropriate format and resolution, and can then upload the image for deposit. The software can repeat the process for both sides of the check, in order to obtain images of the front and the back. 
     Having the web site drive the image-collection process may be simple for the customer (e.g., the bank depositor who uses the web site), since the customer may not have to address issues such as what to name the file, what format or resolution to use. Having the web site drive the process also may avoid, for the customer, the process of identifying particular files to be uploaded. However, certain permissions may be used in order to allow the web site&#39;s software to operate the scanner. Scanners are normally operated by a device driver, such as a TWAIN driver. For security reasons, the driver may require certain certificates to be used before allowing a program to operate the scanner that the driver controls. Since users often transparently download programs to run in their web browsers without realizing that they are downloading programs, programs such as applets, scripts, etc., that run in web browsers often present a particular security risk, and a driver may require such a program to obtain a certificate before it allows the program to control the scanner. Each scanner (or the scanners within a brand-mate family), may have its own driver. The drivers may be different for different operating environments—e.g., the same scanner may use a different driver depending on whether it is being operated from an environment based on one of the WINDOWS operating systems, an environment based on one of the operating systems used in APPLE computers, an environment based on a version of the LINUX operating system, etc. Each driver may use different certificates. Moreover, the different environments may use various different environment-specific technologies to allow the scanner to be controlled from a remote web server. Since the bank that operates the web site does not know what scanning equipment or operating environment its customer will be using, it may need to obtain a large number of certificates, and may need to interface with a large number of different technologies, to support a large number of scanner-environment combinations, in order to allow its software to control scanners for a variety of customers. 
     At present, most consumers use computers whose environment is based on one of the WINDOWS operating systems. Thus, it may make sense from a cost-benefit perspective, for a bank to obtain the certificates to operate a wide variety of scanners in environments based on the WINDOWS operating systems, and to support the technology that allows the scanner to be controlled within that environment. However, it may not make sense from a cost-benefit perspective for the bank to obtain the certificates to operate lesser-used scanners, or scanners in environments other than those based on the WINDOWS operating systems. Thus, an alternative mechanism for obtaining an image of the check may be used. One example of such a mechanism is to have the customer scan an image of the check (or separate images of the front and back of the check) into a file, and then upload the file(s) to the bank&#39;s server for presentment through a banking system. 
     Turning to the drawings,  FIGS. 1, 2, and 3  show examples of user interfaces that could be presented to a user in order to obtain a deposit amount and the appropriate check images. These user interfaces could be presented through a web site—e.g., by delivering to a depositor&#39;s computer or other machine, web pages that cause these user interfaces to be displayed on the depositor&#39;s browser. However, these user interfaces could be presented using any mechanism. 
     In  FIGS. 1-3 , the depositor is asked to enter an amount of a check to be deposited, and is then asked to provide scanned images of the front and back of the check. Thus, in  FIG. 1 , user interface  100 , the depositor is requested to enter the amount of a check to be deposited into box  102 . This amount can be entered in the form of text. When the depositor has entered the amount of the check to be deposited, the depositor may click button  104 , indicating that he or she is “finished.”  FIG. 1  shows an example in which the depositor is requested to enter an amount of a single check to be deposited. However, the depositor could also be given a set of boxes to enter an arbitrary number of checks, or could be asked to enter an aggregate amount of a deposit covering several checks, or could be asked for an amount of a deposit in any other way. 
       FIG. 2  shows user interface  200 , which requests that the depositor enter a name of a file containing an image of the front of the check to be deposited. The name, and optionally the path, of the file can be entered into box  202 . When the depositor has entered the name of the file, he or she can click button  204  to indicate that he or she is “finished” entering the name. The name can be entered either by the depositor typing the name as text into box  202 . Or, as another example, the depositor can be presented with a file navigation user interface  206 . The depositor may click button  208  (“browse”) to access file navigation user interface  206 . File navigation user interface  206  may show the depositor&#39;s local and/or network folder structure, and allow the depositor to navigate through folders and files to obtain the name of the file containing the image. When the depositor has selected the name of the file, the name (or name and path) of the file may appear in box  202  as if the depositor had typed the name (or name and path). User interface  200  could also include information and/or instructions for the depositor about the rules that govern the nature of the image to be provided—e.g., text could be displayed or communicated in user interface  200  that advises the depositor as to the format of the image to be provided (e.g., JPEG), the resolution of the image (e.g., 200 dpi), other parameters (e.g., turning on grayscale for the scan), etc. As another example, the depositor could be shown examples of “good” and “bad” scans—e.g., an image could be shown to the depositor indicating an example of scan that would be accepted, and another image could be shown to the depositor indicating an example of a scan that would not be accepted. A scan that would not be accepted might be shown as being smudged, or crooked, or obscured in some manner. There are a variety of reasons for which a scan might not be accepted, and examples demonstrating any one or more of these reasons could be shown to the depositor. 
       FIG. 3  shows user interface  300 , which is similar to user interface  200  but asks the depositor to enter the name of a file containing an image of the back of the check instead of the front. Like user interface  200 , user interface  300  may have a box  302  into which the depositor can enter the name of the file containing the appropriate image, a button  304  that the depositor can click when he or she is finished entering the file name, a browse button  306  that the depositor can use to access a file navigation user interface similar to that shown in  FIG. 2  and previously discussed. Additionally user interface  300  may inform and/or instruct the depositor as to issues concerning format, resolution, other parameters, etc. 
       FIG. 4  is a flow diagram of an example process whereby an image of a check is received and presented for payment. It is noted that the process of  FIG. 4 , as well as the process discussed subsequently in connection with  FIG. 5 , are both described, by way of example, with reference to a web server that interacts with a depositor by communicating through a network with a browser running on the depositor&#39;s machine. However, these processes may be carried out in any system, and are not limited to the scenarios described. Moreover, these flow diagrams show examples in which stages of a process are carried out in a particular order, as indicated by the lines connecting the blocks, but the various stages shown in these diagrams can be performed in any order, or in any combination or sub-combination. 
     At  402 , an amount of a check to be deposited is received. For example, a user interface (such as user interface  100 , shown in  FIG. 1 ) may be used to ask a depositor for the amount of a check to be deposited. As previously noted, the depositor may be given the opportunity to enter an amount of a single check, a list of amounts for plural checks, an aggregate total amount of plural checks, etc. At least one such amount is received at  402 . 
     At  404 , a name of a file that contains an image of the front side of the check is received. For example, a user interface (such as user interface  200 , shown in  FIG. 2 ) may be used to obtain the name (or name and path) of a file that contains an image of the check. The user may have already scanned the check and placed the image in a file, or the user can be instructed to scan the check (or a side of the check) at the time that the file name is to be received. The file whose name is entered may be uploaded to a server, such as a web server operated by the bank with which the check is to be deposited. 
     At  406 , a name of a file that contains an image of the back side of the check is received. For example, a user interface (such as user interface  300 , shown in  FIG. 3 ) may be used to obtain the name (or name and path) of a file that contains an image of the check. As with  404 , the user may already have scanned the check into an image file, or can be instructed to do so. The file whose name is entered may be uploaded to a server, such as a web server operated by the bank with which the check is to be deposited. 
     At  408 , the boundaries the check are received. For example, the user may be asked to draw a boundary on the image to indicate which part of the image is the check, and which part is merely background due to the fact that amount of area scanned is generally larger than a check. One way to obtain an indication of the location of this boundary is to ask the user to scan the check by placing the top and left edges of the check directly abutting the top and left sides of the scanner bed. Thus, the top and left edges of the boundary of the check are defined by the edges of the scanning sight. Presuming that the check is a rectangle, the bottom and right edges that define the remaining portion of the boundary can be indicated by a single point in the bottom, right corner of the check. An example of this technique is shown in  FIG. 5 . 
       FIG. 5  shows a check  502 , which has been scanned. Sight  504  indicates the area that has been scanned, and it can be seen that left edge  508  and top edge  510  of check  502  abut the left and top edges of the scan sight. By placing a marker (such as dot  506 ) in the right, bottom corner of the check, the rectangular boundary of the check is defined. Thus, it can be determined from the position of the marker which portion of sight  504  contains an image of a side of check  502 , and which portion contains background. The portion that contains the image can later be used to present the check for payment through a banking system. It is noted that the marker can be positioned through various mechanisms. For example, a web server that implements the process of collecting a deposit request and check images from a depositor can download software (e.g., a plug-in, an applet, a script, etc.) that executes in the depositor&#39;s browser and allows the depositor to position a marker such as dot  506  with a pointing device, such as a mouse, trackpad, etc. This program could be used to place the marker on the image before the image is uploaded to the bank&#39;s server. As another example, the bank&#39;s server could receive the image, and then send a copy or modified version of the image back to the depositor&#39;s web browser to be operated on the program. For example, after the upload of the image, the bank&#39;s web server could cause a new window to be opened with a page containing the image, and a script, applet, plug-in, etc., that allows the depositor to place the marker. Any mechanism to allow the depositor to place the marker could be used. 
     Returning to  FIG. 4 , certain types of verifications may be performed (at  410 ) on the check images that have been received. For example, the images could be verified to determine they are in an acceptable format, at an acceptable resolution, or that the amount of the check shown on the front of the check matches the amount stated by the depositor, or that the back of the check contains an endorsement, or that the check complies with size standards (or other standards) according to applicable law such as the Check-21 law. In one example, the system may check that the images are in the JPEG format, or that the images are at least 200 dpi in resolution, or that the capture of the image preserves grayscale. Resolution and/or grayscale can be addressed as part of the process of verifying that the image is in an acceptable format, or compliance with resolution and grayscale parameters could be checked separately. A comparison of the amount of the check as stated by the depositor with the amount written on the check can be performed by using optical character recognition (OCR) on the check to determine the amount that it states. Or, as another example, the check could be examined by a human and compared with the amount entered by the depositor. Similarly, the presence of an endorsement on the image of the back of the check could be detected using OCR (or some other type of image processing), or could be evaluated by a human. 
     At  412 , the images of the front and back of the check are presented for payment through a banking system. For example, a banking system such as the Federal Reserve or a commercial banking system may operate a server to which these images can be provided, and the images can be presented to the drawee bank through such system. An example of a banking system is shown in  FIG. 7 , and is discussed subsequently. 
       FIG. 6  shows an example of various stages that can be performed after an image of a check is received by a bank from a depositor. For example, when images of a check are from a depositor by the bank&#39;s web server, certain processing can be performed on the image to prepare the check for presentment through a banking system.  FIG. 6  shows examples of stages of such processing. It should be noted that  602 ,  604 , and  606 , as shown in  FIG. 6 , provide additional detail of features that are discussed previously in connection with  410  in  FIG. 4 . 
     At  602 , the files containing the image may be evaluated to determine whether they are in an appropriate format. For example, features of the images, such as file format (e.g., JPEG, GIF, TIF, etc.) may be evaluated. In one example, the depositor may be instructed to upload the images in JPEG format, and an image may be rejected if the evaluation at  602  determines that the image is in a different format. Additional features that may be evaluated include resolution of the image, the presence of grayscale, compliance with legal standards such as Check-21, etc. 
     At  604 , a verification may be performed to determine that the amount of money written on the check corresponds to the amount of the check reported by the depositor. For example, the image of the front of the check can be evaluated by an OCR process, read by a human, etc., and this amount can be compared to the amount of the deposit as entered by the depositor. 
     At  606 , the image of the back of the check may be evaluated to determine the presence of an endorsement. For example, an OCR process, or other type of image processing, may be performed to determine whether the image contains an endorsement. Or the image can be given to a human to evaluate for the presence of an endorsement. 
     At  608 , the images of the check may be converted to an appropriate format for presentment through a banking system. For example, the banking system may impose certain standards such as file format, headers, metadata, etc. The images may be modified and/or packaged to comply with these standards prior to presentment of the check images through a banking system. 
       FIG. 7  shows an example environment in which checks may be deposited and presented. Depositor  702  may be a customer of financial institution  712 . Financial institution  712  may, for example, be a bank, but could also be any other type of financial institution, such as an investment company, an insurance company, etc. Depositor may operate a computer  704 , which may be located at depositor  702 &#39;s residence, but could also be located in any other place. Computer  704  may be connected to image capture device  706 , which may be a scanner, camera, etc. Computer  704  may be connected to other machines through network  708 . The Internet is an example of network  708 , although computer  704  could be connected to other machines through any network. 
     One example of a machine that computer  704  could be connected to through network  708  is server  710 , which, in this example, is a server operated by depositor  702 &#39;s financial institution  712 . Server  710  may operate software that implements a web site, and depositor  702  may use that web site to interact with financial institution  712 , for example by tendering checks for deposit into an account with financial institution  712  through the web site. As previously discussed, one way that a depositor could tender a check for deposit is to provide scanned images of the check and to upload the images to a web site associated with a bank. If depositor  702  uses image capture device  706  to scan images of a check, and then uses a browser running on computer  704  to upload such images to server  710  through network  708 , then this scenario would be one example of the subject matter described herein. However, the subject matter described herein encompasses other scenarios. 
     Financial institutions  716  and  718  are financial institutions such as banks, investment companies, insurance companies, etc. They may also include a clearinghouse or a national central bank (such as the Federal Reserve or a branch thereof). Financial institutions  712 ,  716 , and  718  may communicate with each other via a network  714 . Network  714  may be a publicly-accessible network, such as the Internet, but also may be a private network. For example, financial institutions  712 ,  716 , and  718  may have security issues when they communicate with each other that do not apply to ordinary communications, and thus network  714  may provide security features that network  708  does not. However, network  714  could be any type of network. 
     Account  722 , in the example of  FIG. 7  is an account that depositor  702  maintains at financial institution  712 . Depositor  702  may be in possession of a check that is drawn against account  724  maintained at financial institution  718  (in which case financial institution  718  is the drawee). Depositor  702  may deposit the check into account  722  by delivering the check to financial institution  712 , where such delivery may be in the form of physical delivery of the original paper check, sending an image of the check, etc. Upon receipt of the check (whether in paper form, image form, or otherwise), financial institution  712  may clear the check by presenting the check through a banking system, such as banking system  720 . Presentment of the check may be made directly to drawee financial institution  718 , or could be made to an intermediary financial institution, such as a branch of the Federal Reserve, a correspondent bank, a clearinghouse, etc. The intermediary bank can be a government actor (as in the case of the Federal Reserve in the United States, or the central bank of another country), or it could be a commercial actor, such as a correspondent bank or clearinghouse. 
     In one example, the check is cleared by presenting the check to financial institution  716 , which may, for example, be a regional branch of the Federal Reserve, along with a request for payment. Financial institutions  712  and  718  may each have accounts at financial institution  716 . Financial institution  712  may create a substitute check using an image provided by depositor  702 , and may present the substitute check to financial institution  716 . Upon receiving the substitute check, financial institution  716  may identify financial institution  718  as the drawee bank—e.g., by using the nine-digit routing number that is normally printed on checks in the United States. Financial institution  716  may then present the substitute check to financial institution  718  and request that the check be paid. If financial institution  718  agrees to honor the check, then financial institution  716  may then settle the check by debiting funds from an account of financial institution  718  and crediting funds to an account of financial institution  712 . 
     It will be appreciated that the preceding examples are for illustration, and not limitation. For example, financial institution  718  may have a relationship with financial institution  712 , and financial institution  712  may use this relationship to clear the check directly with financial institution  718 , while bypassing the Federal Reserve, other national central bank, or clearinghouse. In addition, accounts  722  and  724  could be held at the same financial institution  712 , in which case the check may be cleared internally. 
     The subject matter described herein may be implemented through the use of a computer system, or other type of device that has some computing mechanism(s).  FIG. 8  shows an example 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 previously-described 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. 
     With reference to  FIG. 8 , an example system for implementing aspects described herein includes a computing device, such as computing device  800 . In its most basic configuration, computing device  800  typically includes at least one processing unit  802  and memory  804 . Depending on the exact configuration and type of computing device, memory  804  may be volatile (such as random access memory (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. 8  by dashed line  806 . 
     Computing device  800  may have additional features/functionality. For example, computing device  800  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. 8  by removable storage  808  and non-removable storage  810 . 
     Computing device  800  typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computing device  800  and includes both volatile and non-volatile media, 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 includes volatile and non-volatile, 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. Memory  804 , removable storage  808 , and non-removable storage  810  are all examples of computer storage media. Computer storage media includes, but is 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 accessed by computing device  800 . Any such computer storage media may be part of computing device  800 . 
     Computing device  800  may also contain communications connection(s)  812  that allow the device to communicate with other devices. Communications connection(s)  812  is an example of communication media. Communication media typically embodies 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 includes 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 includes 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  800  may also have input device(s)  814  such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s)  816  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. 
     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 API, reusable controls, or the like. Such programs are preferably 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 combined with hardware implementations. 
     Although example 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 personal computers, network servers, and handheld devices, for example. 
     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 previously. Rather, the specific features and acts described previously are disclosed as example forms of implementing the claims.