Patent Publication Number: US-2017372304-A1

Title: Systems, devices and methods for remote authentication of a user

Description:
TECHNICAL FIELD 
     The present disclosure generally relates to identification of user data, including but not limited to remote verification of user identification. 
     BACKGROUND 
     Online transactions have become a daily occurrence for many people and have also created opportunities for new online services and accounts. For example, it is now common for a consumer to browse online product and service offerings, select, place an order, and pay for a product and/or a service in a transaction that is substantially all online. However, online transactions may be vulnerable to security breaches and various forms of fraud. 
     In particular, one of the problems with a typical online transaction is that it circumvents signature and identification verification protocols that are available during an in-person transaction. For example, during a typical online transaction, a merchant provides an order form that requires a consumer to enter personal data such a name, a billing address, a telephone number, and credit card information. The consumer enters and sends the data requested by the form over the internet, and the merchant verifies that the credit card information is valid and that the card can be charged the payment amount. The card verification is usually conducted over a proprietary billing center verification network, such as the VisaNet network. However, the personal data and the credit card information provided by the consumer may have been acquired illicitly by the alleged consumer. Neither the merchant nor the billing center is able to reliably verify that the individual providing the personal data and credit card information is the true authorized user of the credit card. 
     By contrast, during an in-store transaction, a sales clerk can request a signed picture identification in order to verify that the person tendering the credit card is the true authorized user of the credit card. The sale clerk can then compare the signatures on the credit card and the sales slip against the signature on the picture identification, and also verify that the consumer is the same person shown on the picture identification. Moreover, the possibility that picture identification may be requested serves as a potential deterrent against using an illicitly acquired payment instrument during an in-store transaction. 
     SUMMARY 
     Systems, methods and devices described herein enable improved identity verification during online transactions. As such, after considering this discussion, and particularly after reading the section entitled “Detailed Description” one will understand how the features of various implementations are used to enable identity verification of account holders of credit card, debit cards, and other payment instruments during online transactions. For example, in some implementations, systems, methods and devices are operable to compare one or more encoded and/or encrypted images of facial features obtained upon activation of the payment instrument or security measures with one or more encoded and/or encrypted images of facial features obtained during a subsequent online transaction to verify that the individual offering the payment instrument as a form of payment is the true and authorized user of the payment instrument. Additionally and/or alternatively, a voice print record and/or location information may be combined with the use of the encoded and/or encrypted images to provide additional security. Additionally and/or alternatively, images of signatures, electronic signatures and/or other biometric information may be combined with the use of the encoded and/or encrypted images to provide additional security. 
     Some implementations include a computer-implemented method of verifying an online financial transaction. In some implementations the method includes receiving an encoded facial image data value associated with an online financial transaction using a payment instrument, the encoded facial image data including at least a portion of an encoded facial image; encoding at least a portion of an authenticated facial image to produce a verification encoded facial image value; determining whether the received encoded facial image data value and the verification encoded facial image value match; and, providing an authorization indicator in response to the determination. 
     In some implementations, the authorization indicator indicates that the online financial transaction cannot be authorized in response to determining that the received encoded facial image data value and the verification encoded facial image value do not match; and the authorization indicator indicates that the online financial transaction is authorized in response to determining that the received encoded facial image data value and the verification encoded facial image value match. 
     In some implementations, the method also includes initiating a remedial process in response to determining that the received encoded facial image data value and the verification encoded facial image value do not match. 
     In some implementations, the method also includes receiving a transaction request; and transmitting a request for the encoded facial image data value associated with the online financial transaction in response to receiving the transaction request, wherein the request includes an encoding indicator that directs a client device how to encode the facial image data. In some implementations, the transaction request is received from a merchant application server. In some implementations, the encoding indicator indicates which portions of the facial image data to encode. In some implementations, the encoding indicator indicates the type and level of encoding and/or encryption to use when encoding the facial image data to encode. In some implementations, the encoding indicator includes a pseudo-randomly generated component for a respective online transaction, and the encoding indicator indicates that said pseudo-randomly generated component should be included in the encoding of the facial image data. In some implementations, encoding at least a portion of the authenticated facial image data comprises encoding according to the encoding indicator. 
     In some implementations, the method also includes checking the timestamp of the received encoded facial image data value. In some implementations, encoding includes an irreversible compression of selected portions of facial image data. 
     Some implementations include a computer-implemented method of verifying an online financial transaction. In some implementations, the method includes receiving facial image data associated with an online financial transaction using a payment instrument, the facial image data including at least a portion of a full face image; encoding the received facial image data to produce an encoded candidate facial image data value; encoding at least a portion of an authenticated facial image to produce a verification encoded facial image value; determining whether the encoded candidate facial image data value and the verification encoded facial image value match; and providing an authorization indicator in response to the determination. 
     Some implementations include a verification server system to verify an online financial transaction. In some implementations, the verification server system includes a processor; and a memory including instructions, that when executed by the processor cause the device to: receive an encoded facial image data value associated with an online financial transaction using a payment instrument, the encoded facial image data including at least a portion of an encoded facial image; encode at least a portion of an authenticated facial image to produce a verification encoded facial image value; determine whether the received encoded facial image data value and the verification encoded facial image value match; and provide an authorization indicator in response to the determination. 
     Some implementations include a verification server system to verify an online financial transaction. In some implementations, the verification server system includes means for receiving an encoded facial image data value associated with an online financial transaction using a payment instrument, the encoded facial image data including at least a portion of an encoded facial image; means for encoding at least a portion of an authenticated facial image to produce a verification encoded facial image value; means for determining whether the received encoded facial image data value and the verification encoded facial image value match; and means for providing an authorization indicator in response to the determination. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       So that the present disclosure can be understood in greater detail, a more particular description may be had by reference to the features of various implementations, some of which are illustrated in the appended drawings. The appended drawings, however, illustrate only some example features of the present disclosure and are therefore not to be considered limiting, for the description may admit to other effective features. 
         FIG. 1  is a block diagram of an example client-server environment. 
         FIG. 2  is a block diagram of an example implementation of a client system. 
         FIG. 3  is a block diagram of an example implementation of a server system. 
         FIG. 4  is a flowchart representation of a server system method. 
         FIG. 5  is a flowchart representation of a server system method. 
         FIG. 6  is a flowchart representation of a client device method. 
     
    
    
     In accordance with common practice the various features illustrated in the drawings may not be drawn to scale. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may not depict all of the components of a given system, method or device. Finally, like reference numerals may be used to denote like features throughout the specification and figures. 
     DETAILED DESCRIPTION 
     Numerous details are described herein in order to provide a thorough understanding of the example implementations illustrated in the accompanying drawings. However, the invention may be practiced without these specific details. And, well-known methods, procedures, components, and circuits have not been described in exhaustive detail so as not to unnecessarily obscure more pertinent aspects of the example implementations. 
       FIG. 1  is a block diagram of an example client-server environment  100 . While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the implementations disclosed herein. To that end, the client-server environment  100  includes a billing center  150 , a retailer/merchant (or service provider)  140 , a third party verification service provider  160 , a mobile phone operator  122  (i.e. wireless carrier), an internet service provider  120 , and a communications network  104 . Each of the billing center  150 , the retailer  140 , the third party verification service provider  160 , the mobile phone operator  122 , the internet service provider  120  are capable of being connected to the communication network  104  in order to exchange information with one another and/or other devices and systems. Additionally, the mobile phone operator  122  and the internet service provider  120  are operable to connect client devices to the communication network  104  as well. For example, a smartphone  102  is operable with the network of the mobile phone operator  122 , which includes for example, a base station  122   a.  Similarly, for example, a laptop computer  103  (or tablet, desktop, workstation or the like) is connectable to the network provided by the internet service provider  120 , which is ultimately connectable to the communication network  104 . Moreover, while  FIG. 1  only includes one of each of the aforementioned devices and systems, those skilled in the art will appreciate from the present disclosure that any number of such devices and/or systems may be provided in a client-server environment, and particular devices may be altogether absent. In other words, the client-server environment  100  is merely an example provided to discuss more pertinent features of the present disclosure. 
     The communication network  104  may be any combination of wired and wireless local area network (LAN) and/or wide area network (WAN), such as an intranet, an extranet, including a portion of the internet. It is sufficient that the communication network  104  provides communication capability between client devices and servers. In some implementations, the communication network  104  uses the HyperText Transport Protocol (HTTP) to transport information using the Transmission Control Protocol/Internet Protocol (TCP/IP). HTTP permits a client device to access various resources available via the communication network  104 . However, the various implementations described herein are not limited to the use of any particular protocol. 
     The retailer  140 , for example, includes an online customer sales application server  141  and a database  142 . In some implementations, the retailer  140  includes a local customer sales application, such as a point-of-sale terminal within a department store. The retailer  140  may be an online service provider (e.g. a gambling website, a social networking website, a dating website, etc.) or a retailer of real and/or digital goods (e.g. clothing, music, etc.). 
     In some embodiments, the billing center  150  is associated with at least one credit company associated with a credit card, a debit card or other payment instrument. The billing center  150  may be a computerized system holding information relating to client accounts, billing conditions and history, transactions history, and personal and other details of each of clients and of each credit card associated with the billing center  150 . To that end the billing center  150  includes a verification server  151  and a database  152 . The billing center  150  may be associated with one or more credit companies, enabling the retrieval of data from one or more third party databases (not shown) including such information. As described in greater detail below with reference to  FIG. 5 , in order to execute and/or authorize transactions, the verification server  151  retrieves data from the database  152  to check authorization of a transaction according to predefined authorization rules followed by the billing center  151 . 
     In some embodiments, the third party verification service provider  160  is configured to operate as a supplemental verification service provided in addition to any verification processes carried out by the billing center  150 . To that end, the third party verification service provider  160  includes a verification server  161  and a database  162 . 
     As discussed below in greater detail with reference to  FIG. 2 , client devices, such as the computer  103  and smartphone  102 , include a display and a digital camera. A mobile application is operated at least in part by the client device. In some embodiments, the client devices  102  and  103  are enabled to communicate with the billing center  150 , the third party verification service provider  160 , and the retailer  140 . For example, the computer may include at least one of an Ethernet enabled network adapter or interface, a WiFi enabled network adapter or interface, cable modem, DSL modem, a cellular wireless device, or the like. 
     In operation, a user may use a client device  102 / 103  to access the online customer sales application server  141  provided by the retailer  140 . In order to make a purchase through the online customer sales application, the camera associated with the client device is used to obtain at least one image of the credit card and a picture of the user offering the credit card for payment purposes, which is processed according to one of the various methods described below. 
       FIG. 2  is a block diagram of an example implementation of a client device (e.g. smartphone  102  or laptop  103 ) discussed above with reference to  FIG. 1 . While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the implementations disclosed herein. To that end, the client device  102 / 103  includes one or more processing units (CPU&#39;s)  202 , one or more network or other communications interfaces  208 , memory  206 , a digital camera  209 , and one or more communication buses  204  for interconnecting these and various other components. The communication buses  204  may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components. The memory  206  includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory  206  may optionally include one or more storage devices remotely located from the CPU(s)  202 . The memory  206 , including the non-volatile and volatile memory device(s) within the memory  206 , comprises a non-transitory computer readable storage medium. 
     In some implementations, the memory  206  or the non-transitory computer readable storage medium of the memory  206  stores the following programs, modules and data structures, or a subset thereof including an operating system  216 , a network communication module  218 , and a verification processing module  231 . 
     The operating system  216  includes procedures for handling various basic system services and for performing hardware dependent tasks. 
     The network communication module  218  facilitates communication with other devices via the one or more communication network interfaces  208  (wired or wireless) and one or more communication networks, such as the internet, other wide area networks, local area networks, metropolitan area networks, and so on. 
     The verification processing module  231  is configured to cooperate with instructions sent from a verification server (e.g. verification server  151 ), as discussed below with reference to  FIG. 6 . To that end, the verification processing module  231  includes an image processing module  210  and an optional voice and location data verification module  211 . The image processing module  210  facilitates the capture and encoding of image data requested by the verification server. To that end, the image processing module  210  includes a set of instructions  210   a  and heuristics and metadata  210   b.  Similarly, the voice and location data verification module  211  facilitates the capture and encoding of voice and location data requested by the verification server. To that end, the voice and location data verification module  211  includes a set of instructions  211   a  and heuristics and metadata  211   b.    
       FIG. 2  also shows, for example, a schematic image of a credit card  220  and a facial image of a user  230 . The facial image  230  includes multiple windows isolating specific portions of the facial image that may be encoded and/or encrypted individually or in combination with one another. For example, the facial image  230  includes a first window F, which includes substantially all of the facial features of a user. In other examples, windows A, B and S are used to isolate the eyes, mouth and nose areas, respectively. 
       FIG. 3  is a block diagram of an example implementation of a verification server system (e.g. verification server  161 ). While certain specific features are illustrated, those skilled in the art will appreciate from the present disclosure that various other features have not been illustrated for the sake of brevity and so as not to obscure more pertinent aspects of the implementations disclosed herein. To that end, the server system  151 / 161  includes one or more processing units (CPU&#39;s)  302 , one or more network or other communications interfaces  308 , memory  306 , and one or more communication buses  304  for interconnecting these and various other components. The communication buses  304  may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components. The memory  306  includes high-speed random access memory, such as DRAM, SRAM, DDR RAM or other random access solid state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory  306  may optionally include one or more storage devices remotely located from the CPU(s)  302 . The memory  306 , including the non-volatile and volatile memory device(s) within the memory  306 , comprises a non-transitory computer readable storage medium. In some implementations, the memory  306  or the non-transitory computer readable storage medium of the memory  306  stores the following programs, modules and data structures, or a subset thereof including an operating system  316 , a network communication module  318 , a verification processing module  301 , and a user information database  303 . 
     The operating system  316  includes procedures for handling various basic system services and for performing hardware dependent tasks. 
     The network communication module  318  facilitates communication with other devices via the one or more communication network interfaces  308  (wired or wireless) and one or more communication networks, such as the internet, other wide area networks, local area networks, metropolitan area networks, and so on. With further reference to  FIG. 1 , the network communication module  318  may be incorporated into the front end server  134 . 
     The verification processing module  301  is configured to drive the verification process described herein, and described in greater detail with reference to  FIGS. 4 and 5 . To that end, the verification processing module  301  includes an image processing module  310 , an optional voice and location data verification module  211 , and an instrument verification module  312 . The image processing module  310  directs the capture and encoding of image data. To that end, the image processing module  310  includes a set of instructions  310   a,  and heuristics and metadata  310   b.  Similarly, the voice and location data verification module  311  directs the capture and encoding of voice and location data. To that end, the voice and location data verification module  311  includes a set of instructions  311   a  and heuristics and metadata  311   b.  The instrument verification module  312  performs the verification process and handles the remedial measures necessary when a potential fraud is detected. To that end, the instrument verification module  312  includes a set of instructions  312   a  and heuristics and metadata  312   b.    
     The user information database  303  includes user data such as facial image data  331 , voice print data  332 , location data  333  and payment instruments  334  associated with each user. In some implementations, the various types of data are indexed by known users and suspected defrauders. For example, the facial image data  331  includes data for a first user  331   a  and an N th  user  331   n.    
       FIG. 4  is a flowchart representation of a server system method. In some implementations, the method is performed by a server system in order to collect personal data and enable authentication of subsequent online financial transactions. For example, with reference to  FIG. 1 , the method may be implemented on the verification servers  151  and/or  161  as a verification server software application. To that end, the method includes receiving a set-up request from a user via a client device ( 4 - 1 ). In some implementations, the set-up request is received when a payment instrument, such as a credit card or debit card, is activated by a user for the first time. Typically, credit cards and debit cards are sent to users in the mail. Upon receiving a credit card or debit card a user must call a billing center or the like to activate the card. During the activation process, the user can be routed to a secure website or call-center to register and/or activate the enhanced identity verification process described herein. Additionally and/or alternatively, in some implementations the enhanced identity verification process described herein may be delivered by a third party service, such as for example, the third party verification service provider  160  illustrated in  FIG. 1 . As such, the set-up request may be received after the payment instrument has been activated for the first time. 
     In response to receiving a set-up request, the method includes transmitting an authentication request to the client device ( 4 - 2 ). The authentication request indicates that the user must provide some form of authentication data that is likely only known to the user, such as a social security number (or the like), data of birth, a password, a street address, a previously provided verification code, a telephone number, the name/description of an image included in the request, answers to security questions, etc. Additionally and/or alternatively, the authentication request may also seek biometric information, such as a fingerprint scan or retina scan. Accordingly, the method includes receiving authentication information ( 4 - 3 ), and determining if the authentication information is correct or valid ( 4 - 4 ). 
     If the authentication information is not valid (“No” path from  4 - 4 ), the method includes taking remedial action or stopping the process altogether ( 4 - 5 ). For example, in some implementations a remedial action includes at least one of re-sending the original authentication request, sending a different authentication that includes a request for different or related authentication information, sending a message that indicates that the user should call a call-center representative, and automatically connected the user with a call-center representative. Additionally and/or alternatively, the process may stop in response to determining that the authentication information is not valid because the user has provided invalid authentication data more than a threshold number of times. Additionally and/or alternatively, the process may stop in response to determining that the authentication information is not valid because the current user is accessing the verification server from a device that is located in a geographic location that the actual user is unlikely to be. For example, location data can be determined by inspecting IP addresses or routing information received along with set-up request, or even coordinated embedded in an image when it was captured by a smartphone. 
     On the other hand, if the authentication information provided by the user via the client device is valid (“Yes” path from  4 - 4 ), the method includes transmitting a request for an image of the user to the client device ( 4 - 6 ), and subsequently receiving the requested image from the client device ( 4 - 7 ). 
     Digital pictures, especially those taken with digital cameras included in smartphones, often include a timestamp indicating when the picture was taken, and may also include the coordinates of the location where the picture was taken. As such, as an optional measure, the method includes determining if the timestamp of the received image is valid ( 4 - 8 ). In other words, the method includes inspecting the data field included in the received image file to determine whether or not the image was taken within a time period proximate to the current process (e.g. 1-2 minutes). If the timestamp is not valid (“No” path from  4 - 8 ), the method includes taking remedial action or stopping the process altogether ( 4 - 9 ). For example, in some implementations a remedial action includes at least one requesting another image at least one more time. Additionally and/or alternatively, the first rejected image and any subsequent images may be compared to determine if there are any abnormalities or other signs of fraud on the process. 
     On the other hand, if the timestamp is valid (“No” path from  4 - 8 ), the method includes storing the image as associated with a particular payment instrument ( 4 - 10 ). As discussed in greater detail below, the stored image can be used to create new user-specific authentication data on-the-fly during an online transaction process. 
       FIG. 5  is a flowchart representation of a server system method. In some implementations, the method is performed by a verification server system in order to enable authentication of an online financial transaction using previously stored image data of true authorized users. For example, with reference to  FIG. 1 , the method may be implemented on the verification servers  151  and/or  161  as a verification server software application. To that end, the method includes receiving a transaction request with credit card information ( 5 - 1 ). The transaction request may originate from an online order for the purchase of some product or service. For example, with reference to  FIG. 1 , a user via the client device  102 , may have selected and offered to pay for a product offered by the retailer  140  using credit card information. In turn, the online sales application server  141  transmits the transaction request to one of the verification servers  151  or  161  depending on whether the verification process is supported by the billing center  150  or the third party verification service provider  160 . 
     In response to receiving the transaction request, the method includes transmitting a request for encoded or encrypted facial image data of the purchaser and an encoding indicator to the client device ( 5 - 2 ). In some implementations, the encoding indicator provides a set of instructions or selection to the client device that indicates which portions of the facial image data to encode and transmit. For example, with further reference to  FIG. 2 , the verification server may request a combination of facial features selected in a pseudo-random fashion to be encoded together (e.g. an image of the eyes A and mouth B, or the whole face F, or just the nose). Additionally and/or alternatively, the encoding indicator also signals what type and level of encoding or encryption to use on the facial image data. In some implementations, the type and level of encoding or encryption includes an irreversible compression of the selected portions of facial image data, which results in a unique or near unique image data value that can be transmitted to the verification server for comparison with a corresponding server generated value. Additionally and/or alternatively, the encoding indicator includes a pseudo-randomly generated component for each online transaction, such as a pseudo-randomly generated number or the like, which may be included in the encoding process to further enhance security of the transaction. 
     Subsequently, the method includes receiving the encoded/encrypted image data ( 5 - 3 ). As an optional measure, the method includes determining if the timestamp of the received encoded image data is valid ( 5 - 4 ). In other words, the method includes inspecting the data field included in the received encoded image file to determine whether or not the image was taken within a time period proximate to the current process (e.g. 1-2 minutes). If the timestamp is not valid (“No” path from  5 - 4 ), the method includes taking remedial action or stopping the process altogether ( 5 - 5 ). For example, in some implementations a remedial action includes at least one requesting another image at least one more time. Additionally and/or alternatively, the first rejected image and any subsequent images may be compared to determine if there are any abnormalities or other signs of fraud on the process. Additionally and/or alternatively, in some implementations a remedial action includes connecting the user with a call center representative. 
     On the other hand, if the timestamp is valid (“Yes” path from  5 - 4 ), the method includes generating verification image value from a stored image associated with the true authorized user according to the encoding indicator transmitted to the client device ( 5 - 6 ). In other words, server generated verification image value includes user-specific authentication data that is created on the on-the-fly during each online transaction process through the generation and use of pseudo-random encoding indicators. 
     Subsequently, the method includes comparing the received encoded image data to the server generated verification image value in order to determine if the two values match ( 5 - 7 ). In some implementations, the matching process is not fault-tolerant, and precise matching is preferred. If the received encoded image data and the server generated verification image value do not match (“No” path from  5 - 7 ), the method includes taking remedial action or stopping the process altogether ( 5 - 8 ). 
     On the other hand, if the received encoded image data and the server generated verification image value match one another (“Yes” path from  5 - 7 ), the method optionally includes checking the location data associated with the received encoded image data ( 5 - 9 ), before authorizing the transaction. For example, location data can be determined by inspecting IP addresses, routing information received along with a set-up request, or even coordinated embedded in an image when it was captured by a smartphone. 
     If the location data is suspect (“Yes” path from  5 - 9 ), the method includes taking remedial action or stopping the process altogether ( 5 - 11 ). For example, if the location data indicates that the purchase is being attempted in a geographic location that the true authorized user has not made a purchase from in the past or is unlikely to be in based on recent transactions the current transaction would be denied. On the other hand, if the location data is not suspect (“No” path from  5 - 9 ), the method includes providing an indication that the transaction is authorized ( 5 - 10 ). For example, with reference to  FIG. 1 , one of the verification servers  151  or  161  transmits a verification indicator to the online sales application server  141 . 
       FIG. 6  is a flowchart representation of a client device method. In some implementations, the method is performed by a client device (e.g. smart-phone, tablet, laptop, personal computer, etc.) in order to facilitate authentication of an online financial transaction. For example, with reference to  FIG. 1 , the method may be implemented on at least one of the two client devices  102  and  103  as a part of an online commerce client application. To that end, the method includes transmitting a transaction request ( 6 - 1 ). In other words, the user has selected a product or service using the client device, and has proceeded to tender payment using a payment instrument such as a credit card or debit card. Subsequently, the method includes receiving a request for encoded or encrypted facial image data of the purchaser and an encoding indicator ( 6 - 2 ). As noted above, in implementations, the encoding indicator provides a set of instructions or selection to the client device that indicates which portions of the facial image data to encode and transmit. For example, with further reference to  FIG. 2 , the verification server may request a combination of facial features selected in a pseudo-random fashion to be encoded together (e.g. an image of the eyes A and mouth B, or the whole face F, or just the nose). Additionally and/or alternatively, the encoding indicator also signals what type and level of encoding or encryption to use on the facial image data. In some implementations, the type and level of encoding or encryption includes an irreversible compression of the selected portions of facial image data, which results in a unique or near unique image data value that can be transmitted to the verification server for comparison with a corresponding server generated value. Additionally and/or alternatively, the encoding indicator includes a pseudo-randomly generated component for each online transaction, such as a pseudo-randomly generated number or the like, which may be included in the encoding process to further enhance security of the transaction. 
     The method includes prompting the user to take one or more pictures using a camera associated with the client device ( 6 - 3 ). For example, a picture is taken with an integrated camera included in a smartphone or a web-cam peripheral device connectable to a desktop computer or laptop. If multiple pictures are taken, the picture with the best image quality is preferably selected. The method includes selecting at least a portion of the image to encode or encrypt based on the received encoding indicator ( 6 - 4 ), and then encoding the selected portion(s) ( 6 - 5 ). The method includes transmitting the encoded value with the timestamp of the image and optionally a location indicator (other than merely an IP address) to the verification server ( 6 - 6 ). And to complete the transaction, the method includes receiving an authentication result ( 6 - 7 ), which may in some implementations merely include an indication that the transaction was completed successfully. 
     It will also be understood that, although the terms “first,” “second,” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, which changing the meaning of the description, so long as all occurrences of the “first contact” are renamed consistently and all occurrences of the second contact are renamed consistently. The first contact and the second contact are both contacts, but they are not the same contact. 
     The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the claims. As used in the description of the embodiments and the appended claims, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof 
     As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in accordance with a determination” or “in response to detecting,” that a stated condition precedent is true, depending on the context. Similarly, the phrase “if it is determined [that a stated condition precedent is true]” or “if [a stated condition precedent is true]” or “when [a stated condition precedent is true]” may be construed to mean “upon determining” or “in response to determining” or “in accordance with a determination” or “upon detecting” or “in response to detecting” that the stated condition precedent is true, depending on the context.