Payment Terminal Firmware Updates with Compressed Resume Blocks
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Payment terminals located at remote locations often require firmware updates but have infrequent network connectivity, making traditional network-based updates challenging.
Innovation Solution
A method for updating firmware in payment terminals involves generating a firmware manifest, compressing update blocks, and using offset tables to efficiently transmit and decompress updates over a network, ensuring complete and secure installation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If firmware updates are transmitted over network to remote payment terminals, then update capability is improved, but transmission time and data loss risk worsen due to infrequent connectivity
Solution Approach 1:
The firmware update is divided into multiple blocks that are transmitted sequentially over the network. Each block can be independently received and processed, allowing the payment terminal to accumulate updates during infrequent network connections without requiring all data to be transmitted in a single session. This segmentation enables progress to be saved and resumed, reducing the impact of transmission time losses.
Solution Approach 2:
The system generates a manifest file that describes the complete firmware update structure and stores it locally at the payment terminal before actual transmission begins. This preliminary preparation allows the terminal to understand the update requirements in advance and prepare reception buffers and processing logic, so when network connectivity becomes available, the actual data transmission can proceed more efficiently without delays.
2Adaptability or versatility
If firmware updates are transmitted over network to remote payment terminals, then update capability is improved, but data integrity worsens due to potential transmission failures
Solution Approach 1:
The system implements feedback mechanisms where the payment terminal sends acknowledgment signals to the server after successfully receiving and validating each firmware block. The server uses this feedback information to determine whether to retransmit any blocks that were not successfully received or corrupted, ensuring data integrity without requiring complete retransmission of the entire firmware update.
Solution Approach 2:
The manifest file is generated and validated in advance to verify the complete firmware update structure, checksums, and block sequencing before transmission begins. This preliminary verification ensures that the terminal has the correct expectations for the incoming data and can validate each block against the manifest, detecting and rejecting corrupted data before it compromises the update integrity.
3Speed
If firmware updates are delivered via physical memory devices, then transmission speed is improved, but operational complexity worsens due to manual intervention requirements
Solution Approach 1:
The system enables automated firmware updates where the payment terminal autonomously checks for available updates, downloads the appropriate firmware blocks, validates them against the manifest, and installs them without requiring manual intervention from operators. The terminal self-manages the update process, including handling partial failures and resuming transmissions, thereby eliminating the complexity of manual physical media deployment while maintaining fast update speeds.
4Reliability
If complete firmware updates are transmitted each time, then update completeness is improved, but data redundancy worsens when resuming interrupted transmissions
Solution Approach 1:
The system tracks which firmware blocks have been successfully received and installed by maintaining a record in the payment terminal. When a transmission is interrupted and needs to be resumed, the terminal uses this feedback information to identify only the blocks that were not successfully received, requesting and receiving only those specific blocks from the server. This eliminates data duplication by avoiding retransmission of already-installed firmware sections.
Solution Approach 2:
The firmware update is segmented into discrete blocks with individual tracking, allowing the system to resume transmission from the exact point of interruption. The manifest file includes metadata about block sizes, positions, and completion status, enabling the terminal to calculate precisely which segments need retransmission. This segmentation approach ensures update completeness while minimizing data redundancy by transmitting only the necessary remaining blocks.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
It may be determined that a payment reader requires a firmware update, which may be transmitted to the payment reader as compressed firmware update blocks. The payment reader may receive a first portion of set of the compressed firmware update blocks. The payment reader may decompress the first portion and determine a partial firmware offset associated with the first portion. If the firmware update is incomplete, the payment reader may transmit that partial firmware offset to a second device. Based on this partial of firmware offset and an offset table that associates compressed firmware offsets with decompressed firmware offsets, the payment reader receive a second portion of compressed firmware update blocks to send to the payment reader. The payment reader may determine that entire update has been received and update its firmware.