Patent Description:
A user can access devices that interface with transaction systems for initiating authenticated transactions. The transaction system and/or the corresponding device can require user authentication prior to initiating the transaction. For example, a Point-of-Sale (POS) device can require user authentication for payment transactions initiated by a customer of the POS terminal. A Point-of-Sale device is a device that can process transactions, such as payments, from a buyer to a seller for ordered items and/or services. The user can provide a signature, a unique code, and/or other credentials at the POS terminal to initiate the authentication process. However, often the authentication process at the POS device is not strong enough to deter fraudulent uses. Thus, the transaction systems can incur losses from not being able to accurately determine fraudulent users.

<CIT> discloses a method for identity verification that employs biometric technology. Positioned at the center of the system is a stylus with a number of biometric properties or their combination or with one or more metric sensors, while the customer uses the stylus to sign his/her name. The identity verification system is used at point-of-sale terminals to access a computer network, in applications involving pen-based computers and smart-pens, and for e-commerce. Each participant carries on his/her person a device that includes an encrypted biometric for reference purposes to gain access to the system. Processing is simplified to make a "MATCH" or "NO MATCH" decision.

The present embodiments may be better understood, and numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. The scope of the invention is set out in the appended claims.

A user, e.g., a customer, can access authentication devices to initiate transactions at a transaction system. The transaction system can require user authentication, such as via the authentication device, prior to initiating the transaction. A Point-of-Sale (POS) device can implement authentication functionality of the authentication device. The POS device can process transactions, such as payments, from a buyer to a seller for items and/or services offered by the merchant and requested by the customer. The transaction can be any type of commerce transaction or other transaction that requires authentication, such as contracts, property transfers, loans, among others. The transaction can be for a software service (e.g., a software-as-a-service (SaaS)) that can be provided to customer. The customer can provide a signature, a unique code, and/or other credentials at the POS device to initiate the authentication process. The methods described herein provide a robust authentication process at the POS device to determine and deter fraudulent uses. Although this description refers to using POS devices, other authentication devices can be used. For example, the authentication device can be used during buyer's access to an on-line authentication system, i.e., not at a physical store.

The transaction system can provide an easier and more secure method for authenticating access to transactions initiated at remote devices. The method can be implemented by a POS device (or another device that receives user input and determines user authentication) that includes an input device for accepting user input. The POS device can be accessed by the customer initiating a transaction. The customer can use a pointing device (such as a stylus device and/or a digital pen) to provide the user input at the input device, such as at a touch screen of the POS device. The POS device can receive the user input that includes an authenticating input and encoded data. The POS device can also receive authentication data for authenticating the customer for using the pointing device for initiating of the transaction.

The authenticating input can be provided for authenticating the customer for the transaction. The authenticating input can be a textual input such the customer's signature, or another type of manual entry made by the customer using the pointing device. The POS device can also access encoded data that is embedded, by the pointing device, in the user input. The encoded data can be provided as a sequence of symbols and/or a pattern. The encoded data can be a type of a key, a token, and/or an authenticating identifier that is provided for authentication of the customer by the POS device. The POS device can determine a correlation between the authentication data and the encoded data. The POS device can then determine, based on the correlation and the authenticating input, authentication of the user for initiating of the transaction at the POS device.

Therefore, the methods described herein allow a user to use an pointing device to provide several authentication elements to the POS device for an easier and more secure method for authenticating a user for initiating transactions. The pointing device can provide the authenticating user input (e.g. as used by the customer) as well as encoded data that is embedded into the user input. These authentication elements, along with the authentication data, can be used by the POS device to quickly authenticate the customer for initiating of the transaction at the POS device. The following description, and associated Figures, illustrates various embodiments directed to the ideas listed above.

<FIG> is a system diagram illustrating embodiments of a system for facilitating authentication via a pointing device for secure transactions. In an overview of a system diagram <NUM>, a POS device <NUM> includes a display <NUM>. The POS device <NUM> also hosts a POS application <NUM> that can authenticate the customer for initiating a transaction at the POS device. The POS device <NUM> can communicate with an authentication server <NUM> that aids with the authentication process. The POS device <NUM> can receive input from a pointing device <NUM>, and determine whether to authenticate the user based on this input. The POS device <NUM> can communicate with the transaction system <NUM> that processes the transaction. The POS device <NUM> can be a terminal, a mobile POS, and/or a mobile device that can be used to initiate customer transactions once the customer is authenticated. The POS device <NUM> can receive authentication elements from the pointing device, a user device <NUM>, and/or other devices. Based on the authentication elements, the POS device <NUM> can determine, locally via the POS application <NUM> and/or via communicating with the authentication server <NUM>, authentication of the customer.

The POS application <NUM> can be an application, hosted by the POS device <NUM>, that facilitates transactions between the customer and the merchant. The POS application <NUM> can receive and process customer transactions. The POS application <NUM> can locally authenticate the user and/or the pointing device <NUM> for the transaction, or can communicate with the authentication server <NUM> to perform this authentication. The POS application <NUM> can communicate with the transaction system <NUM> to complete the transaction. The POS application <NUM> can be a stand-alone application, or a client functionality accessed via a web browser. The POS application <NUM> can be used to authenticate the customer to access the user account at the transaction system <NUM>. In some embodiments, the POS application <NUM> can authenticate the customer for the transaction that is processed off-line, i.e., without communicating with the transaction system <NUM>.

The authentication server <NUM> can receive information (such as one or more authentication elements) from the POS device <NUM>, and provide authentication determination to the POS device <NUM>. The authentication server <NUM> can provide customer information to the POS device <NUM>. The transaction system <NUM> can be an open-loop or a closed-loop transaction system. In either implementation, the transaction system <NUM> can process the transaction using the authentication indication_(e.g., whether the customer has been authenticated at the POS device <NUM> based on the authentication elements).

The POS device <NUM> can communicate with the transaction system <NUM> to initiate the transaction. The transaction can be for purchase of a product and/or service that is offered by the merchant. The transaction can be for a transfer of funds between a user account at the transaction system <NUM> and another account (such as at the transaction system <NUM> or at another system). The transaction can be for initiating a software service (e.g., a software-as-a-service (SaaS)) that can be provided to the user device <NUM> by the transaction system <NUM>. The transaction system <NUM> may require the authentication from the POS device <NUM> prior to processing of the transaction.

The POS device <NUM> can receive authentication data from the pointing device <NUM> or the user device <NUM>, where the authentication data is an authentication element. The authentication data can be implemented as a user name of the customer. The authentication data can be implemented as an authentication token that maps, such as at an authentication server <NUM>, to a user name and/or password for the customer. The authentication data can be implemented as a key that authenticates the customer for using the pointing device <NUM> at the POS device <NUM>. The authentication data can indicate that the pointing device <NUM> is associated with the user device <NUM>, where the user device is a trusted device. The authentication data can be implemented as a key that authenticates the customer for using the pointing device <NUM> at the POS device <NUM>. The authentication data can be implemented as a verification code, such as a one-time code, for confirming identity of the customer.

The POS device <NUM> includes a display <NUM> that can implement an input device that can receive user input in addition to being able to displaying images and/or text. The input device of the POS device <NUM> can be implemented by a trackpad and/or other touch-based interfaces. For example, the display <NUM> can be implemented by a touchscreen that can receive user input. The user input can be processed to determine one or more authentication elements used for authentication of the customer.

In some embodiments, the POS device <NUM> can receive the authentication data from the pointing device <NUM>. The authentication data can indicate that the pointing device <NUM> received the authentication data from the user device <NUM>, thus providing another authentication element to the POS device <NUM>. For example, the authentication data can include timestamps and/or device specific information like device identifier, profile and other digital fingerprints indicating that the authentication data originated at the user device <NUM> and then was transmitted to the pointing device <NUM>. Transmission of the authentication data from the user device <NUM> to the pointing device <NUM> can be triggered by the user device <NUM> being in close proximity (e.g., within a certain predefined distance) with the POS device <NUM> and/or with the pointing device <NUM>. The pointing device <NUM> can transmit the authentication data to the POS device <NUM> responsive to determining that the pointing device <NUM> is in close proximity (e.g., within a certain predefined distance) of the POS device <NUM>.

In some embodiments, the user device <NUM> can periodically transmit current authentication data (e.g., a current and valid version of the authentication data) to the pointing device <NUM>. In some embodiments, the user device <NUM> can communicate the authentication data to the POS device <NUM> directly, i.e., without relaying the authentication data through the pointing device <NUM>. The user device <NUM> can trigger this direct communication based a determination that the user device <NUM> is in close proximity with the POS device <NUM> and/or with the pointing device <NUM>.

The pointing device <NUM> can be implemented by a stylus and/or a digital pen. The pointing device <NUM> can be used to draw or make selections at an input device of the POS device <NUM>, such as the display <NUM> that uses a touch screen. The pointing device <NUM> can be implemented by a glove or another wearable (as shown at <NUM>) that can provide input to the input device of the POS device <NUM>. In some embodiments, the pointing device <NUM> can be associated with the POS device <NUM>. In other embodiments, the pointing device <NUM> can be associated with the customer, such as with user of the user device <NUM>.

The pointing device <NUM> can host a device application <NUM> that can be configured to generate the encoded data. The device application <NUM> can provide the encoded data in the user input at the input device. The device application <NUM> can provide the encoded data responsive to detecting that the user is using the pointing device <NUM> to provide the authenticating input and/or that the pointing device <NUM> is in proximity of the POS device <NUM>. While the pointing device <NUM> is used by the user to provide user input <NUM> at the input device of the POS device <NUM>, the device application <NUM> can provide the encoded data <NUM> embedded in the authenticating input <NUM>. In some embodiments, the device application <NUM> can provide the encoded data responsive to receiving a handshake signal (if handshake communication is being used) from the POS device <NUM>. The device application <NUM> can establish the handshake communication between the pointing device <NUM> and the POS device <NUM>. The handshake signal can indicate that the pointing device is to provide the encoded data during application of the user input.

The input device can be implemented as a resistive touchscreen, a capacitive touchscreen, an acoustic wave touchscreen, and/or a photosensitive screen. Although the examples described herein refer to touchscreens, a touchpad can be used instead. In some embodiments, the input device can be implemented via an augmented reality or virtual reality input system. In some embodiments, the encoded data can be provided to the input device using a modulation of the input signal using the same technique as input device accesses the authenticating input. Thus, for capacitive touchscreens, the encoded data can be provided as a modulation of the electrical signal provided to the input device. In other embodiments, the encoded data can be provided using another technique via the same input device. For example, the authenticating input can be provided via a capacitive input capability of the input device, and the encoded data can be provided via a modulated pressure (i.e., for a resistive input capability of the input device). In some embodiments, the input device can be used for handshake communication with the pointing device <NUM>. During the handshake communication, the input device can provide the handshake signal via the appropriate input type to the pointing device <NUM>.

The input device can be implemented as a resistive touchscreen. Depending on the implementation of the resistive touchscreen, the user input can be accessed by the input device by detecting contact between electrically resistive layers or via another resistive touchscreen signal acquisition technique. The user can use the pointing device <NUM> to provide user input, such as by drawing the authenticating input on the resistive touchscreen. The pointing device <NUM> can generate and provide the encoded data in the user input. For example, the pointing device <NUM> can generate the encoded data as a sequence of pulses (and/or other types of non-continuous signals) in the user input. The sequence of pulses can be provided, for example, via a writing tip of the pointing device <NUM>. The writing tip can be used to modulate an actual pressure applied to the resistive touchscreen during application, by the pointing device <NUM>, of the user input. For example, the device application <NUM> can modulate up and down movement of the writing tip to modulate the actual pressure and to provide the sequence of pulses.

The input device can be implemented as a capacitive touchscreen. Variations of the capacitive touchscreen can include surface capacitance technique, projected capacitance technique, mutual capacitance technique, and/or self-capacitance, among others. Depending on the implementation of the capacitive touchscreen, the user input can be accessed by measuring a distortion of an electrostatic field of the capacitive touchscreen, such as by measuring a change in capacitance. Similarly as discussed above, the user can use the pointing device <NUM> to provide the user input by drawing the authenticating input on the capacitive touchscreen. Similar to for other types of touchscreens, the pointing device <NUM> can generate and provide the encoded data in the user input as a sequence of pulses (or other types of non-continuous signals) in the user input.

For capacitive touchscreens, the sequence of pulses can be provided via the writing tip of the pointing device <NUM> that modulates an electrical connection between the user's hand holding the pointing device <NUM> and the writing tip of the pointing device <NUM> that makes contact with the capacitive touchscreen. The pointing device <NUM> can modulate the connection between the user's hand and the writing tip via a relay (or another device). The device application <NUM> can, for example, control the relay to break the connection to provide the sequence of pulses at the capacitive touchscreen.

Similar techniques can be used by the pointing device to provide the sequence of pulses (or other types of non-continuous signals) in the user input for other types of input devices. For AR implementation, the input device can detect (e.g., via cameras and/or other sensors) the user input as provided by a gesture provided by a user using (e.g., by wearing or holding) the wearable device <NUM>. The input device can determine the authenticating input from the user input. The wearable device <NUM> can generate and provide the encoded data in the gesture provided by the user, such as via visual indicators (e.g., lights) of the wearable device <NUM>. Images of these gestures and/or visual indicators can be acquired by the input device.

In some embodiments, the user device is a scanner or a camera that acquires an image of a physical medium (such as paper) where the user input is affixed. For example, the pointing device <NUM> can be a pen, pencil, marker, or another tool that transfers ink (and/or another liquid or paste for coloring a surface of the physical medium) to a surface of the physical medium. The pointing device <NUM> can provide the user input to the physical medium, where the user input includes the encoded data and the authenticating input. The pointing device <NUM> can provide the encoded data in the authenticating input by generating the sequence of pulses (and/or other types of non-continuous signals) in the user input, where the user input can physically attached and/or engraved on the surface of the physical medium. The user device can then acquire an image of this physical input, and perform image analysis on the acquired image to determine the authenticating input and the encoded data.

The pointing device <NUM> can determine a window of time (referred to as a data application time window) during which the encoded data can be provided at the user input. The pointing device <NUM> can determine the data application time window based on an average amount of time the user (or a collection of users) take to provide the authenticating input. The pointing device <NUM> can determine the data application time window based on a length (e.g., in characters) of the user's first and last name. The pointing device <NUM> can determine, based on the data application time window, a size of the encoded data, and a rate of transfer of the encoded data at the user input, an actual data application duration.

The pointing device <NUM> can provide the encoded data during the actual data application duration, which can be a portion of the data application time window. In some embodiments, the pointing device <NUM> can repeat the provisioning of the encoded data during the entire data application time window. For example, if the entire data application time window is <NUM> second and the actual data application duration is <NUM>, then the pointing device <NUM> can provide the encoded data several times (e.g., <NUM> or fewer times) during the data application time window. If the actual data application duration is longer than the data application time window, the pointing device <NUM> may indicate to the user (such as via haptic feedback, visual feedback, and/or auditory feedback), that the entire encoded data is not transferred. In this case, the user may be prompted to leave the pointing device <NUM> in contact (such as by providing additional authenticating text) with the input device of the POS device <NUM> until the pointing device <NUM> transfers, via the input device, any remaining encoded data to the POS device <NUM>.

In some embodiments, the pointing device <NUM> can be pre-configured to provide the user input via one of multiple techniques which can include resistive touchscreens and capacitive touchscreens. The pointing device <NUM> can determine the type of input device used by the POS device <NUM>. The pointing device <NUM> can then provide the encoded data based on the type of the input device. For example, for an input device with a resistive touchscreen, the pointing device <NUM> can provide the user input by modulating a resistive signal. Thus, both the authenticating input and the encoded data can be provided to the input device using appropriate input type. In some embodiments, the pointing device <NUM> can determine to provide the authenticating input using a first input type, and the encoded data using another input type. In some embodiments, the pointing device <NUM> can be used for handshake communication that uses the appropriate input type with the input device. The pointing device <NUM> can also receive pulses from the input device via the appropriate input type, which can be different from what is used for the authenticating input and/or the encoded data.

<FIG> is a flow diagram illustrating embodiments of operations for facilitating authentication via a pointing device for secure transactions. The method of <FIG> is described with reference to the systems and components described in <FIG> (for illustration purposes and not as a limitation). The example operations can be carried out by the POS application <NUM>.

Beginning with <NUM>, the POS application receives authentication data. With reference to <FIG>, the POS application <NUM> can receive the authentication data from the pointing device <NUM>. In some cases the pointing device <NUM> can be associated with the user and/or the user device <NUM> (e.g., the pointing device <NUM> is owned by the user and/or is a part of the user device <NUM>, and/or is configured to directly communicate with the user device <NUM>, where the user device <NUM> is a trusted device). In these cases, the pointing device <NUM> can transmit the authentication data, to the POS device <NUM>, responsive to determining that the pointing device <NUM> is within a communication distance of the POS device <NUM>. The pointing device <NUM> can transmit the authentication data to the POS device <NUM> via a short-range communication protocol, such as Bluetooth Low Energy (BLE) or Near Field Communications (NFC), among others.

In some cases, the pointing device <NUM> can be associated with the POS device <NUM> (e.g., the pointing device <NUM> is configured to directly communicate with the POS device <NUM>). In these cases (i.e., where the pointing device <NUM> is a trusted device), the user device <NUM> can transmit the authentication data responsive to determining that the user device <NUM> is within a communication distance of the POS device <NUM> and/or the pointing device <NUM>. The user device <NUM> can transmit the authentication data to the POS device <NUM> and/or the pointing device <NUM> via the short-range communication protocol, such as BLE or NFC.

At <NUM>, the POS application receives authenticating input, for a transaction at the POS device, via a user input provided via a pointing device at an input of the POS device. With reference to <FIG>, the POS application <NUM> can receive the user input via the input device of the POS device, such as via the touchscreen functionality of the display <NUM>. In some embodiments, the user input can be received via a physical medium, such as paper. The POS application <NUM> can acquire an image of the user input from the physical medium. The POS application <NUM> can then perform image analysis on the acquired image to determine the authenticating input and the encoded data.

In some embodiments, the POS application <NUM> can communicate with the authentication server <NUM> to validate the authentication data for the pointing device <NUM>. Responsive to determining validation of the authentication data by the authentication server <NUM>, the POS application <NUM> can communicate, to the pointing device <NUM> and/or to the user device <NUM>, an enabling indication for enabling generation of the encoded data in the user input by the pointing device <NUM>. In some embodiments, the POS application <NUM> can establish a handshake communication between the pointing device <NUM> and the POS device <NUM>. The handshake communication can be communicated between the input device and the pointing device <NUM>, such as via the touchscreen functionality of the display <NUM>. For example, the POS application <NUM> can transmit a handshake signal, via the input device of the POS device, to the pointing device <NUM>. The handshake signal can include the enabling indication for triggering the device application <NUM> to generate the user input during application of the authenticating input.

In some embodiments, the POS application <NUM> can determine a required level of authentication for the transaction. The POS application <NUM> can determine the required level of authentication based on certain characteristics of the transaction, such as whether an amount of funds of the transaction is larger than a certain threshold, a type of the transaction, whether the recipient (e.g., the merchant) and/or the customer (e.g., that is initiating the transaction) is known to have transaction risks, among others. The POS application <NUM> can, responsive to a determination that the required level of authentication is above an authentication threshold, communicate to the pointing device an enabling indication. The enabling indication can be for enabling generation of the encoded data corresponding to the required level of authentication in the user input.

At <NUM>, the POS application accesses encoded data embedded in the user input. With reference to <FIG>, the POS application <NUM> can access the encoded data <NUM> in the user input. The POS application <NUM> can access the encoded data based on a type of the input device and/or how the encoded data is provided in the user input. Discussion of some embodiments of accessing the encoded data is provided below with reference to <FIG>.

At <NUM>, the POS application determines a correlation between the authentication data and the encoded data. The correlation can indicate whether the authentication data and the encoded data are both associated with the same user. For example, the correlation can be implemented as a confidence value indicating a likelihood that both of these authentication elements are associated with the same user. With reference to <FIG>, the POS application <NUM> can determine whether the correlation value is greater than a certain correlation threshold.

In some embodiments, determining the correlation includes determining that the authentication data received at <NUM> is an incomplete token, and that the encoded data includes another portion of the complete token. Thus, the complete token can be determined by the POS application, from the incomplete token (e.g., a first portion of the complete token) and the encoded data (e.g., a second portion of the complete token). The POS application <NUM> can then determine the user authentication based on the complete token.

At <NUM>, the POS application determines, based on the correlation and the authenticating input, whether the user is authenticated. It is noted that if, based on the correlation at <NUM>, that the user is not authenticated, the POS application <NUM> may not analyze the authenticating input. In some embodiments, at <NUM> the POS application <NUM> can analyze input characteristics of the user input to determine whether the input characteristics match user characteristics associated with the user. The input characteristics can indicate how the user input is being provided to the input device via the pointing device <NUM>, and can depend on a type of input device being used, as well as types of sensors being available at the pointing device <NUM> and/or at the input device.

For example, the pointing device <NUM> can include sensors such as a gyroscope, an accelerometer, a temperature sensor, a fingerprint sensor, and/or a pressure sensor, among others. The input characteristics can indicate a speed at which the user input is being provided, a pressure at which the pointing device <NUM> is being pressed onto a surface of the input device, a pressure at which the pointing device <NUM> is being held by the user, an angle at which the pointing device <NUM> is being held by the user while providing the user input, among others. The input characteristics can also indicate biometric characteristics (which can be measured by the pointing device <NUM>) of the user, such as the user's body temperature, the user's fingerprint, among others.

The POS application <NUM> can determine a potential user based on the authentication data, the authenticating input <NUM>, and/or the encoded data <NUM>. The user characteristics for the potential user can be accessed by the POS application <NUM> locally at the POS device <NUM> and/or by communicating with the authentication server <NUM>. The POS application <NUM> can then compare the input characteristics to the user characteristics and determine whether any different in values of the characteristics is within acceptable limits (e.g., as previously determined, such as based on the authentication level). The POS application <NUM> can then determine user authentication based on determination of whether the input characteristics match the user characteristics. In some embodiments, the POS application <NUM> can analyze signature characteristics of the authenticating input to determine whether the signature characteristics match user signature characteristics associated with the user as determined based on the authentication data. The POS application <NUM> can determine the user authentication based on a determination that the signature characteristics match the user signature characteristics.

In some embodiments, where the pointing device is associated with the user device <NUM> (and is thus not a trusted device of the POS device <NUM>), the POS application <NUM> can determine whether the pointing device <NUM> is on a blacklist associated with fraudulent devices. For example, the POS application <NUM> can access a local database, and/or communicate with the authentication server <NUM>, to determine whether the pointing device <NUM> (such as by using the authentication data, a reference number of the pointing device <NUM>, or some identifying characteristic of the pointing device <NUM>) is a suspected fraudulent device. Similar determination can be made by the POS application <NUM> for cases where the pointing device is associated with the POS device <NUM>, and is thus a trusted device. In these cases, the POS application <NUM> can determine whether the user device <NUM> is on a blacklist associated with fraudulent devices. The POS application <NUM> can then determine user authentication if the appropriate device is not on a blacklist.

At <NUM>, the POS application determines whether the transaction is authorized. The POS application <NUM> can determine, based on authentication of the user of <NUM>, whether the transaction is authorized. The POS application <NUM> can communicate with the transaction system <NUM> to determine authorization for the transaction. With reference to <FIG>, the POS application <NUM> can determine whether the transaction is authorized for the user at the POS device <NUM>. If the POS application determines that the transaction is authorized, flow continues at <NUM>. Otherwise, flow continues at <NUM>. At <NUM>, the POS application performs another authorization procedure, i.e., one that does not rely on user authentication at the POS device <NUM>. After <NUM>, the flow continues at <NUM>. At <NUM>, the transaction is processed. In some embodiments, the transaction system <NUM> processes the transaction and returns processing results. In some embodiments, once the user is authenticated at <NUM>, the POS application <NUM> can transmit, to the transaction system <NUM>, authentication indication indicating whether the customer has been authenticated at the POS device <NUM> based on the authentication elements. The transaction system <NUM> can then perform the elements <NUM>-<NUM>.

<FIG> is a diagram illustrating embodiments of authenticating input and associated encoded data. The input device of the POS device <NUM> can access the user input <NUM> and determine the authenticating input <NUM> and the encoded data <NUM>. <FIG> illustrates steps of analysis of the user input <NUM> (of <FIG>) by showing initial user input 116A as initially accessed by the input device of the POS device <NUM>, and also processed user input 116B as being processed (e.g., by the POS application <NUM>) for the encoded data <NUM>. As discussed above, the authenticating input <NUM> and the encoded data can be used as authentication elements by the POS application <NUM>.

As shown in the initial user input 116A, the authenticating input <NUM> can be implemented by a user signature. However, other textual and/or non-textual identifying inputs can be provided via the authenticating input <NUM> by the pointing device <NUM>. For example, the authenticating input <NUM> can include a certain non-textual input that is unique to the user. The authenticating input <NUM> can be input, via the pointing device <NUM>, as one or more lines (which themselves can be provided via a sequence of pulses for the embedded data, as discussed below).

As shown in the processed user input 116B, the embedded data <NUM> can be implemented as a sequence of pulses (or other types of non-continuous signals) that are embedded in the authenticating input <NUM>. The embedded data <NUM> can, for example, be implemented using various length pulses, such as Morse code, for indicating information. The embedded data <NUM> can be implemented using pulses that indicate data using binary code, ternary code, or other type of communication that can be represented by altering continuity, intensity, and/or frequency of an underlying signal (which is the authenticating input <NUM> in this case).

In some embodiments, depending on the actual data application duration and on the data application time window, the embedded data <NUM> may include multiple repetitions of the actual embedded data segments. For example, if the actual data application duration is <NUM> times longer than the data application time window, then the encoded data <NUM> can include <NUM> actual embedded data segments. The encoded data <NUM> can also include headers and other data structures for error correction and data parity.

<FIG> is a diagram illustrating embodiments of encoded data that is embedded in user input. The POS application <NUM> can determine, from the encoded data <NUM>, at least a portion of input data <NUM> that can correspond to a key, a token, and/or authenticating identifier that can be used as an authenticating element for authenticating the customer. <FIG> illustrates an example where the POS application <NUM> can process the encoded data <NUM> to determine the input data <NUM>. For example, the POS application <NUM> can process the binary code of the encoded data <NUM> to determine the input data <NUM>.

<FIG> also illustrates embodiments where the POS application <NUM> determines that the encoded data <NUM> corresponds to a first portion <NUM> of the complete token, and that the second portion <NUM> of the complete token is received via other means (such as via the authentication data). In some embodiments, the POS application <NUM> can determine that the second portion <NUM> includes an error correction portion of the encoded data <NUM>, which can be used to determine whether the first portion <NUM> was transmitted properly and/or without errors. The POS application <NUM> can then use the error correction portion <NUM> to correct the errors of the first portion <NUM>.

<FIG> is a timing diagram illustrating operations for facilitating authentication via a pointing device for secure transactions. As shown by <FIG>, the device application <NUM> communicates with the user device <NUM>. The device application <NUM> also communicates with the POS application <NUM>. The communications of <FIG> can be performed over one or more communication networks. Portions of the timing diagram of <FIG> correspond to the flow diagram of <FIG>.

At <NUM>, the user device <NUM> can determine that it is within a close proximity (e.g., a certain predefined distance) of the pointing device <NUM>. At <NUM>, the user device <NUM> can communicate authentication data to the device application <NUM>. At <NUM>, the device application <NUM> can process the authentication data. At <NUM>, the device application <NUM> can generate encoded data. At <NUM>, the device application <NUM> can provide the encoded data to the POS application <NUM> via the user input, when the pointing device <NUM> is used to apply the user input at the input device of the POS device <NUM>. At <NUM>, the POS application <NUM> can access the encoded data (as well as the authenticating input) that is provided via the user input.

At <NUM>, the POS application <NUM> can determine a correlation between the authentication data and the encoded data. At <NUM>, the POS application <NUM> can communicate the correlation with the authentication server <NUM>. At <NUM>, the authentication server <NUM> can determine, based on the communication, authentication of the user of the pointing device <NUM>. At <NUM>, the authentication server <NUM> can communicate with the POS application <NUM>. At <NUM>, the POS application can determine whether the customer is authenticated based at least on analysis of the three authentication elements. At <NUM>, the POS device can then communicate indication of the user authentication to the transaction system <NUM> for processing of the transaction.

It should be understood that <FIG> and the operations described herein are examples meant to aid in understanding embodiments and should not be used to limit embodiments or limit scope of the claims. Embodiments may perform additional operations, fewer operations, operations in a different order, operations in parallel, and some operations differently. For example, one or more elements, steps, or processes described with reference to the diagrams of <FIG> may be omitted, described in a different sequence, or combined as desired or appropriate.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, a software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "module" or "system. " Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible and/or non-transitory medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Computer program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

The computer program code may execute (e.g., as compiled into computer program instructions) entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.

Aspects of the present disclosure are described with reference to flow diagram illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flow diagram illustrations and/or block diagrams, and combinations of blocks in the flow diagram illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flow diagrams and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flow diagram and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flow diagrams and/or block diagram block or blocks.

<FIG> is a block diagram of an exemplary embodiment of an electronic device <NUM> including a communication interface <NUM> for network communications. The electronic device can embody functionality to implement embodiments described in <FIG> above. In some implementations, the electronic device <NUM> may be a laptop computer, a tablet computer, a mobile phone, a powerline communication device, a smart appliance (PDA), a server, and/or one or more another electronic systems. For example, a user device may be implemented using a mobile device, such as a mobile phone or a tablet computer. For example, a payment system may be implemented using one or more servers. The electronic device <NUM> can include a processor unit <NUM> (possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The electronic device <NUM> can also include a memory unit <NUM>. The memory unit <NUM> may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media. The electronic device <NUM> can also include the bus <NUM> (e.g., PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus, AHB, AXI, etc.), and network interfaces <NUM> can include wire-based interfaces (e.g., an Ethernet interface, a powerline communication interface, etc.). The communication interface <NUM> can include at least one of a wireless network interface (e.g., a WLAN interface, a Bluetooth interface, a WiMAX interface, a ZigBee interface, a Wireless USB interface, etc.), In some implementations, the electronic device <NUM> may support multiple network interfaces - each of which is configured to couple the electronic device <NUM> to a different communication network.

The memory unit <NUM> can embody functionality to implement embodiments described in <FIG> above. In one embodiment, the memory unit <NUM> can include one or more of functionalities for facilitating authentication via a pointing device for secure transactions. Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processor unit <NUM>. For example, some functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor unit <NUM>, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated in <FIG> (e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor unit <NUM>, the memory unit <NUM>, the network interface <NUM> and the communication interface <NUM> are coupled to the bus <NUM>. Although illustrated as being coupled to the bus <NUM>, the memory unit <NUM> may be coupled to the processor unit <NUM>.

While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the present disclosure is not limited to them. In general, techniques for facilitating authentication via a pointing device for secure transactions as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.

Claim 1:
A method for authenticating access to remote devices, the method comprising:
receiving (<NUM>) authentication data for authenticating a user for using a pointing device (<NUM>) at a Point-of-Sale, POS, device (<NUM>) for initiating of a transaction;
establishing a handshake communication between the pointing device (<NUM>) and the POS device (<NUM>);
transmitting a handshake signal to the pointing device (<NUM>) via the handshake communication;
receiving (<NUM>), via a touch screen (<NUM>) of the POS device (<NUM>), user input that includes an authenticating input and encoded data, the user input provided via the pointing device (<NUM>) at the touch screen (<NUM>), the authenticating input for authenticating the user for the transaction, the encoded data being embedded in the authenticating input based on the handshake signal via a modulation of an input signal for the authenticating input;
accessing (<NUM>) the authenticating input to determine the encoded data that is embedded in the authenticating input;
determining the encoded data from the modulation of the input signal for the authenticating input;
determining (<NUM>) a correlation between the authentication data and the encoded data; and
determining (<NUM>), based on the correlation and the authenticating input, an authentication for initiating the transaction by the user at the POS device (<NUM>).