Firmware management

Aspects of the subject disclosure provide a card reader for receiving payment card information at a mobile point-of-sale terminal. In some implementations, a reader of the subject technology can include a memory, a conditioning module and a 3.5 mm audio plug including an audio bus that is configured for insertion into a headphone port of a host device, such as a smart phone or tablet computer. Implementations of the subject technology also include a microprocessor configured to perform operations for determining whether a newer firmware version is available for the card reader or whether a download of such a firmware needs to be completed, and in response to determining such a download is needed, performing a download of the firmware via the audio plug during periods of inactivity.

BACKGROUND

The proliferation of mobile computing devices (such as smart phones and tablet computers, etc.), has spurned development of various attachable hardware devices to provide expanded functionality. One such example is an attachable magnetic card reader device, used for reading credit or debit card information to facilitate the receipt and processing of payments. Some such reader devices can be physically and communicatively coupled to an associated mobile device using a standard 3.5 mm audio plug when inserted into the headphone port of the mobile device (e.g., smart phone). For conventional card reader devices, only unidirectional (reader device to mobile device) communication is typically supported. As such, conventional card reader devices often lack the ability to receive information from the mobile computing device, including instructions for implementing software or firmware updates.

DETAILED DESCRIPTION

The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the technology can be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description, which includes specific details for the purpose of providing a more thorough understanding of the subject technology. However, it will be clear that the subject technology is not limited to the specific details set forth herein and may be practiced without these specific details. In some instances, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

As noted above, conventional card reader devices are generally restricted to unidirectional communication over audio connections and are only capable of sending signals to a host computing device. Accordingly, once such card reader devices are manufactured, there is generally no means to update the functionality of the card reader device without disassembling the card reader device and replacing components therein. In some conventional card reader device implementations, these card reader devices can include a processor and memory storing firmware for causing the processor to control operation of the card reader device. In these cases, even though the processor could theoretically be configured to perform additional functions by updating the software or firmware stored in the memory of the card reader device, conventional card reader device implementations do not provide any means to facilitate such updating.

In particular, since the audio ports of conventional card reader devices are generally configured for unidirectional communications from the reader to a host computing device, the audio ports are not available providing updates to the card reader device. In some instances, a second non-audio connection port (e.g., universal serial bus or the like) may be provided for purposes of communicating with the host computing device to perform such updates. However, since such an update scheme relies on a connection configuration significantly different from the normal connection configuration between the card reader device and the host computing device, this complicates the update process for the average user. Moreover, this type of configuration requires that the average user actively determine whether or not an update exists and taking appropriate steps to perform the update thereafter. As a result, many users fail to update their card reader devices, out of ignorance or convenience, and continue to operate their card reader devices with older software or firmware versions. This not only results in the users not being able to take advantage of new features for the card reader device, but can also result in errors during payment processes.

The subject technology addresses the foregoing problem by providing a bidirectional reader system, as well as an upgrade method in which firmware data for operating a processor of the reader device is incrementally transferred to a reader device, without interruption to the user. In various implementations, the reader device is configured to exchange data (i.e., send and receive data) with a host computing device. In certain implementations, the host computing device can be a smart phone or tablet device and the reader device can engage in bidirectional communications via left or right audio channel buses of one or more audio connection ports, such as a standard 3.5 mm audio plug. Using one (or both) busses, firmware data can be incrementally saved to a memory partition resident on the reader device, without the need for user involvement. After a complete firmware version has been transferred to the reader, the upgraded firmware can be authenticated and implemented in the reader device, again without the need for user involvement. In other words, the updating process of the reader device is invisible to the user.

Although the present technology at times will be described with respect to a reader device implemented as a magnetic stripe card reader device with an audio plug and a host computing device implemented as a smartphone or tablet device with a corresponding audio jack, the present technology is not limited in this regard. First, the present technology can be utilized with any other type of connection between the reader device and the host computing device. Second, the host computing device is not limited to any particular type of computing device. Thus, the host computing device can also be any other type of computing device with audio and non-audio connection ports and networking capabilities, including, but not limited to, netbook computers, laptop computers, desktop computers, games consoles, set top boxes, or the like.

In some implementations, a memory of the reader device contains multiple storage volumes, areas, partitions, sections, or slots. These can be defined physically or logically. Each of these volumes can be utilized for storing different sets of software for operating the reader device. For example, these volumes can include a boot loader volume and one or more different firmware volumes. The boot loader software in the boot loader volume can be configured to access the stored firmware volumes and boot the reader using a most recent or most stable one of the firmware versions for the reader device. The boot loader can also be configured to perform security tasks including, but not limited to: verifying security/authenticity of a firmware, determining firmware completeness, and identifying a relative versions for the firmware volumes (e.g., to distinguish between newer and older firmware volumes). In some implementations the boot loader volume is stored in a “locked” mode to inhibit potential modification or tampering. For example, a switch or other control can be provided on the reader device so that the portion of the memory associated with the boot loader is placed in a read-only configuration. Alternatively or in combination with such a switch, the boot loader volume can be secured by a password, keys, or the like so that changes to the boot loader volume are allowed only when the appropriate credentials are provided.

Based on the foregoing, an update/upgrade scheme utilizing incremental or background downloading of the software or firmware for the reader device can be provided in accordance with the present technology. For example, in one implementation of the present technology, a memory of the reader device can include a boot loader volume and two firmware volumes (e.g., “Volume A” and “Volume B”). In operation, when the reader device boots, the boot loader can access one of Volumes A and B with a complete and most up-to-date firmware version and boot the reader device using that firmware version. Concurrently, the reader device can be configured to obtain, via the audio plug and the host computing device, an updated version of firmware, if available, for the reader device. Transfer or downloading of such new firmware data can be performed incrementally via the audio plug and without interruption to the user. As used herein, the term “incremental downloading” of firmware or software refers to downloading of such firmware or software on a piecewise basis, such as during periods of inactivity between the reader device and the host computing device. As such, the new data can be gradually uploaded to Volume B without requiring a consistent connection to the source of the firmware or software. Once the updated version of the firmware is available in Volume B, the reader device can be rebooted using the updated version. The techniques described herein therefore provide at least three advantages over conventional firmware or software update/upgrade methods. First, no behavioral changes (or even user interactions) are required on the part of the user. For example, there is no need for the user to wait to take special precautions during updating or to prompt the user (e.g., no need to display a “please do not unplug your reader” message or the like). Second, since the reader stores multiple firmwares, the reader is always in a usable state with the older firmware. Third, updates/upgrades can be performed without concern of the transient nature of the connection. For example, a conventional reader may undergo various unplug/plug cycles, which may even cause the reader to reset or lose some of its state information. In contrast, since the newer firmware is not applied until completely downloaded, the reader's operation is unaffected by the unplug/plug cycles.

The present disclosure contemplates that more than two firmwares may be stored on a reader device at one time. That is, under certain circumstances, several “roll backs” of the firmware may be necessary. For example, certain firmware versions can require specific versions of an application on the host computing device. Thus, the firmware can “roll back” through the various versions until a compatible firmware for the application is found.

Aspects of the present technology also provide for configuring the reader device to identify and track various metrics related to reader device performance. For example, in certain configurations, the reader device can include a combination of software and hardware components to handle errors and problems. These can include crashing handling software or firmware routines for managing crash events and logging relevant information. Such logged errors can include, for example, credit or debit card read errors, communication errors, or any other issues at the reader device. These reports can then be used to make determinations as to whether an uploaded firmware has errors or issues. Further, “watchdog” circuitry can be utilized to detect and handle problems during operation using a particular firmware version (e.g., applying a hardware reset in the event of an infinite loop). In cases where new firmware updates are deemed problematic, these software and hardware components can be used by the boot loader to determine whether to “roll back” to an older firmware version such that the reader boots from the previous partition.

FIG. 1illustrates a conceptual block diagram of hardware components of a reader device100configured for bi-directional communication and incremental firmware updates, according to some aspects of the subject technology. Reader device100includes microcontroller110, memory120, digital-to-analog converter (DAC)130, analog-to-digital converter (ADC)140, conditioning module150, media interface160, and power supply170.

As illustrated, microcontroller110is coupled to memory120, DAC130and ADC140. Additionally, microcontroller110is coupled to conditioning module150, via audio input channel115, as well as media interface160, either directly or via ADC140. In turn, ADC140is coupled to conditioning module150, via audio output channel105. Via DAC130, audio input channel115, ADC140, and audio output channel105, the reader device100can engage in bidirectional communications with the host computing device using audio signaling, i.e., carrier waves representing audio.

Audio signaling received on audio input channel115can be simultaneously provided to microcontroller110and conditioning module150. Audio signaling received by the microcontroller110can be used to provide voltage information to the conditioning module so that the conditioning module parameters can be tuned to provide proper voltage offsets for the received audio signals via conditioning control line152. In this way, the microcontroller110can “listen” to the received audio signal while adjusting conditioning parameters in order to standardize the received signals before digital conversion and further processing are performed. Conditioning module150can be configured to clamp incoming audio signals to eliminate negative voltage components. In certain aspects, an analog output of microcontroller110is provided to an ADC (e.g., ADC130), and digital information about the received signal is output to conditioning module150.

It is understood that reader device100can be implemented using various other hardware components and/or configurations, and is not limited to the architecture depicted inFIG. 1.

Microcontroller110can be implemented using a general-purpose processor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, gated logic, discrete hardware components, or a combination of the foregoing.

Memory120can include various types of memories, including working memory in the form of random-access memory (RAM)122and read-only memory (ROM)124. Additionally, various types of memory can be utilized in place of, or in addition to, memory120. For example, the one or more sequences of instructions for operating the reader device100can be stored as the bootloader software or firmware in a ROM112within microcontroller110or in the ROM124within memory120. One or more sequences of instructions can also be software stored and read from another storage medium, such as the flash memory array, or received from the host computing device (e.g., a mobile device such as a smart phone or tablet computing device) via a host interface. ROM, storage mediums, and flash memory arrays represent examples of machine or computer readable media storing instructions/code executable by microcontroller110. Machine or computer readable media may generally refer to any medium or media used to provide instructions to microcontroller110, including both volatile media, such as dynamic memory used for storage media or for buffers within microcontroller110, and non-volatile media, such as electronic media, optical media, and magnetic media.

Audio output channel105and audio input channel115can form a portion of an audio bus or connector, such as a standard 3.5 mm audio plug (not shown) or other audio connector type. In some implementations, audio input channel115can include multiple audio input channels, such as a left-audio input channel and a right-audio input channel.

Media interface160can form a device, or portion thereof, for reading media located on credit cards, debit cards, or objects to obtain payment information. In some implementations, the media interface160can be configured to read information from a physical storage medium, such as magnetic storage media (e.g., magnetic stripe media), optical storage media (e.g., barcodes or patterns), radio-frequency identification (RFID) storage devices, and integrated circuit card media (e.g., smart chip technologies), to name a few. Alternatively or in addition to the capability of reading such passive media, the media interface160can also be configured in some implementations to provide a wireless or wireline interface for interacting with other devices to provide such payment information.

Note that some basic components of a system supporting bidirectional communications have been provided, the disclosure turns to a more detailed description of the methodology for managing firmware use and updates in accordance with the present technology. In particular,FIG. 2shows a flowchart of steps in an exemplary method200for performing firmware management in accordance with the present technology.

Method200begins at step202with the booting of the reader device. In particular, the microcontroller110is powered up and invokes the boot loader from the boot loader volume. In some implementations, the boot-up process can begin when the audio plug or other connector on the reader device is coupled to a corresponding jack or port on the host computing device. Accordingly, the method200encompasses within step202a process of detecting the coupling of the audio plug or connector. For example, signals from the host computing device can be detected. Alternatively, the detection can encompass detecting a change in the electrical characteristics associated with the audio plug or detector. Regardless of the detection method, the microcontroller can then can obtain the boot loader from memory and cause it to run. Thereafter at step204, the boot loader can cause the microcontroller110determine what is the latest version of firmware available. For example, metadata identifying the versions associated with the various stored firmware versions can be compared. Such a comparison can include comparing date information, version information, or any other information specified in the boot loader for identifying different versions of firmware, including a combination of various types of information (e.g., date and version).

Once the latest version of firmware has been identified at step204, a determination can be made at step206as to whether or not the latest version should be loaded. In particular, at step206, a determination is made as to whether the latest firmware version is available for use. In particular, information regarding the download or build status (usability information) of a firmware version can be compared to usability criteria in order to determine whether or not the version is available or ready for the reader device to use. The present disclosure contemplates that there may be various reasons as to why a firmware version may be unavailable for use by the reader device. Accordingly, there may be one or more usability criteria that need to be considered. For example, in some cases, the firmware download process may simply be incomplete. In other cases, the error logging process may have resulted in the firmware as being flagged due to numerous errors during previous operation of the reader device. In still other configurations, the download process for the firmware may be complete, but the reader device may be unable to authenticate the keys or signatures associated with the firmware. However, the present technology is not limited in this regard and other criteria may be considered in making the decision as to whether or not a firmware is available for use. If the latest firmware version is available for use at step206, the method200can proceed to step208. Otherwise, the method proceeds to step210.

At step208, the boot loader can complete the boot process with the latest firmware version. In some implementations, as shown inFIG. 2and as discussed above, an error logging process can be implemented. Thus, during or after the completion of the boot process, the reader device can be configured to monitor for errors. This can be performed by “watchdog” or crash handling components or subroutine implemented in the microcontroller or other element of the reader device. In some cases, the errors are simply logged. In other cases, the occurrence of an error can cause the reader device to take additional actions. For example, if an error is detected at step212during or after the completion of the boot process, the method can proceed to step214.

At step214, the error log can be reviewed to determine if too many errors have occurred. For example, the number of errors can be compared to error criteria. These criteria can be associated with a total number of errors overall or a number of errors of certain types. For example, there can be provided a threshold value for such errors. In the event these criteria are met at step214, the firmware can be flagged at step216as unavailable and the reader device can be rebooted at step218so that a previous firmware version is used instead. The present disclosure contemplates that if the reader device is currently engaged in a payment activity, the reboot process could be deferred until the activity is completed or paused for other reasons.

In the event that a previous firmware version is used (step210), no errors are detected (step212) or the error criteria is not yet met (step214), the method200can proceed to step220to begin or complete the firmware download process. First at step220, a determination is made as to whether the reader device is currently capable or ready to begin downloading updated firmware. In the case of audio signals, the bandwidth is generally limited. Therefore, if the reader is currently engaged in payment activities, it would be undesirable to interrupt such activities to perform firmware downloads. Accordingly, the reader device can repeat step220until the reader device is ready.

Once the reader device is ready at step220, the method proceeds to step222to determine whether a new version of the firmware, with respect to the currently running version, is available. This can encompass sending a request via the host computing device to an update server for information on new version and comparing this information to information regarding the currently stored firmwares. This step can also encompass determining whether a download needs to be completed (in the case of a previous partial download) or redone (in the case of firmwares with errors). If no update is available, then the method repeats steps220and222until such an update is available or the reader device is restarted.

If a new version is available (or a download of the new version needs to be completed or redone), the method can proceed to step224to download the latest firmware. As noted above, the download at step224can be performed incrementally or piecewise during periods of inactivity of the reader device. That is, during periods in which the reader device is not in communication with the host computing device for processing a transaction or performing so other primary function. Thereafter, completion of the download of the firmware can be detected at step226. If the download is complete at step226, the method can proceed to step218to reboot the reader device so that the newly downloaded firmware is used. Otherwise, the additional portions of the firmware are downloaded by repeating steps220-226.

The present disclosure also contemplates that in some instances, a new version of the firmware may be available prior to completion of the downloading of a previous version. Therefore, in some configurations, the incomplete version may be deleted or overwritten by the newer version. Alternatively, the reader device can allow the download of the incomplete version to be completed prior to beginning the download of a newer version.

The present disclosure further contemplates that in some instances several updated versions of a firmware may be available in a short amount of time. In most configurations, a first-in, first-out (FIFO) policy can be utilized to store newer firmware versions in favor of older firmware versions. However, it is desirable to ensure that at least one stable version of the firmware is available at the device. Accordingly, in some implementations, the download process can be deferred based on an age or use criteria. For example, consider the case of a reader device with storage capacity for two firmwares. After a first firmware update is downloaded to the reader device with an original firmware and a second firmware update becomes available shortly thereafter, it may be undesirable to overwrite the original firmware too soon. Rather, it may be useful to test the first firmware update to ensure it is stable in the event the second firmware update is unstable. Thus, download of the second firmware update can be delayed or deferred until the first firmware update meets a use or age criteria and is not yet flagged as being associated with errors. Further, in the case where the first firmware update is flagged, the reader device can temporarily ignore the FIFO policy and overwrite the unstable first firmware update instead of the stable original firmware. Accordingly, at least one stable version of firmware persists on the reader device.

The present disclosure additionally contemplates that the check at step222can result in the identification of a preferred firmware for the reader device. In some cases, the preferred firmware is simply the newest or latest version available. However, in other cases, an older version can be preferred for various reasons. For example, there may have been issues identified with the newer version. In another example, an older version can be preferred based on the application on the host computing device. Thus, rather than attempting to download the newest version, the preferred version can be downloaded instead.

FIGS. 3A and 3Billustrates an example reader300according to some embodiments of the subject technology. As illustrated, reader300includes a housing310that is coupled to an audio plug320(e.g., a 3.5 mm audio plug).

Housing310contains the hardware components and circuitry of reader300, as illustrated with respect to the example ofFIG. 1. Additionally, housing310includes a slot315through which a payment card, such as a credit or debit card, may be swiped. Passage of a magnetic stripe of the payment card past a read head (e.g., media interface160contained in housing310) can enable payment information to be received via the read head. The resulting signal provided by the read head is typically an analog signal that must be digitized e.g., using ADC140, before the resulting digital information is provided to microcontroller110.

Different types of information can be read from a magnetic stripe, depending on implementation. For example, user and payment card account information can be read from track 1 and track 2 of the magnetic stripe, respectively. However, in other implementations, any track (or combination of tracks) may be read from the magnetic stripe, including any combination, or all of tracks 1, 2 and 3.

As illustrated, body portion310is physically and communicatively coupled to audio plug320, which can be removably inserted into a headphone port of a host device, such as a smart phone, personal computer, tablet device, or the like. As discussed above with respect toFIG. 1, audio plug320forms part of an audio bus that includes left and right audio output channels (via left/right contacts322,324), an audio input channel (via microphone contact326), and a ground connection (via ground contact328). Once audio plug320is inserted into the compatible jack of a host device, such as a smartphone, bi-directional communication between reader300and the host is enabled e.g., via the left/right audio output channels and audio input channel, using the methods and systems discussed above.

Although the reader illustrated inFIG. 3can accept payment cards containing a magnetic stripe (e.g., using a read head), it is understood that the reader can be configured to receive other types of payment cards, and accordingly can contain additional or different hardware and/or software modules than those described above with respect toFIG. 1. For example, housing310can include a read head (in the form of a dip slot) for accepting integrated circuit cards, such as those conforming to the Europay, Mastercard, and Visa (EMV) standard. Such a read head can be incorporated into slot315or in separate slot (not shown) in housing310.

Once successful bidirectional communication has been established between the reader and its host, the reader can be used to facilitate a payment transaction, for example between a merchant and a buyer using a magnetic payment card.

FIG. 4depicts a conceptual environment in which a reader of the subject technology can be used to facilitate a financial transaction between a buyer and a merchant. Although the diagrams depict components as functionally separate, such depiction is merely for illustrative purposes. It will be apparent that the components portrayed in this figure can be arbitrarily combined or divided into separate software, firmware and/or hardware components. Furthermore, it will also be apparent that such components, regardless of how they are combined or divided, can execute on the same host or multiple hosts, and wherein multiple hosts can be connected by one or more networks.

In the example ofFIG. 4, the system includes a mobile device400, a reader401connected to mobile device400, a decoding engine410, a user interaction engine420, and a transaction engine430, all running on mobile device400. Additionally, the system may also include one or more of a user database440, a product or service database450, a transaction database460, and a firmware database470all coupled to the transaction engine430. Thus, to perform firmware updates in accordance with the present technology, the transaction engine430can invoke an update routine to retrieve updated firmwares and associated information from firmware database470.

As used herein, the term engine refers to software, firmware, hardware, and/or other components used to effectuate a purpose. The engine will typically include software instructions that are stored in non-volatile memory (also referred to as secondary memory). When the software instructions are executed, at least a subset of the software instructions is loaded into memory (also referred to as primary memory) by a processor. The processor then executes the software instructions in memory. The processor may be a shared processor, a dedicated processor, or a combination of shared or dedicated processors. A typical program will include calls to hardware components (such as I/O devices), which typically requires the execution of drivers. The drivers may or may not be considered part of the engine, but the distinction is not critical.

As used herein, the term database is used broadly to include any known or convenient means for storing data, whether centralized or distributed, relational or otherwise.

In the example ofFIG. 4, mobile device400to which reader401is connected can be, but is not limited to, a cell phone, such as Apple's iPhone, other portable electronic devices, such as Apple's iPod Touches, Apple's iPads, and mobile devices based on Google's Android operating system and any other portable electronic device that includes software, firmware, hardware, or any combination capable of at least receiving the signal, decoding if needed, exchanging information with a transaction server to verify the buyer and/or seller's account information, conducting the transaction, and generating a receipt. Typical components of mobile device400can include but are not limited to persistent memories like flash ROM, random access memory like SRAM, a camera, a battery, LCD driver, a display, a cellular antenna, a speaker, a Bluetooth circuit, and WiFi circuitry, where the persistent memory may contain programs, applications, and/or an operating system for the mobile device.

In some implementations, a system is provided with transaction engine430running on mobile device400. In response to a financial transaction between a buyer and a seller, mobile device400accepts information selected including but not limited to information from financial transaction or information pertaining to financial transaction card used by the buyer in the transaction. Additionally, a financial transaction device can be utilized, Non-limiting examples of financial transaction devices include but are not limited to a, wristband, RFID chip, cell phone, biometric marker and the like. At least a portion of this information is communicated with a third party financial institution or payment network to authorize the transaction.

Payment confirmation can be made with a communication channel of the buyer's choice. As non-limiting examples, confirmation of payment can be an electronic notification in the form selected from at least one of, email, SMS message, tweet (message delivered via Twitter), instant message, communication within a social network and the like. In response to the transaction, a confirmation is made that the buyer is authorized to use the financial transaction card. In certain implementations, a confirmation can be provided that indicates a sufficiency of funds available to the buyer.

In the example ofFIG. 4, reader401is configured to read data encoded in a magnetic strip of a card being swiped by a buyer and send a signal that corresponds to the data read to mobile device400. However, as discussed above, reader401may be configured to received various payment card types, including but not limited to IC cards that can be provided to reader401using a dip slot.

The size of reader401can be miniaturized to be portable for connection with mobile device400. For example, the size of card reader401can be miniaturized to an overall length of less than 1.5″. In addition, the miniaturized card reader401is also designed to reliably read the card with minimum error via a single swipe by counteracting vendor specific filtering done by mobile device400. Note that this broad overview is meant to be non-limiting as components to this process are represented in different embodiments.

Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, any other optical or magnetic media. The computer-readable media can store a computer program that is executable by at least one processing unit, such as a microcontroller, and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.