Patent Grant
11762646
Merchants may conduct transactions for items and services with customers. During a transaction between a merchant and a customer, the merchant can use a point-of-sale (POS) device to input information associated with the transaction. For example, the merchant can input information describing items that the customer is acquiring from the merchant, respective prices of each of the items, and payment information of a payment instrument being used by the customer. The POS device can then send a request to a payment service to process the payment instrument for a price of the transaction.
In some instances, the POS device may be connected to a separate electronic device that customers can use to input payment information of payment instruments during transactions. For instance, a customer may input payment information into the electronic device, which can then send the payment information to the POS device for authorization. However, when a POS device is connected to such a separate electronic device, security problems can arise with regard to stealing of sensitive information, such as the payment information. For instance, software may be loaded on the POS device, such as when the POS device is updated, that steals the sensitive information.
The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.
This application describes, in part, techniques for securely updating a point-of-sale (POS) system that includes at least a merchant-facing device and a buyer-facing device. The POS system can include a merchant user interface (UI) presented on a merchant-facing display and a customer UI presented on a customer-facing display. In some instances, the merchant UI can be displayed on a display of a merchant device (also referred to as a first merchant device or the merchant-facing device), while the customer UI can be displayed on a display of a customer device (also referred to as a second merchant device or the customer-facing device). In such instances, the merchant device and the customer device can be operably connected via a wired connection (also referred to as a physical connection) and/or a wireless connection (also referred to as a network connection).
In some instances, the POS system may update software using a cloud-based system, such as a payment system. For instance, the merchant device may include first software that the merchant device executes during transactions with customers, where the first software provides the merchant device with at least first POS functionality, such as receiving information associated with the transactions. Additionally, the customer device may include second software that the customer device executes during the transactions with the customers, where the second software provides the customer device with at least second POS functionality, such as receiving payment information from the customers. Moreover, the customer device may include a secure enclave, such as a secure payments enclave, that includes third software that the customer device executes when conducting the transactions with the customers.
To securely update the software, the merchant device can communicate with the payment system via a network connection. For instance, the merchant device can send, via the network connection, the payment system both an identifier associated with the merchant device and an indication of a current version of the first software included (e.g., executing) on the merchant device. In response, the payment service can identify the merchant device using the identifier. For instance, the payment service can compare the identifier associated with the merchant device to a database of stored identifiers to identify the merchant device. The payment service can then determine, based on the indication of the current version of the first software, that the merchant device can update the first software.
For instance, the payment service may store a software update for POS systems. The software update can include an updated version of the first software, an updated version of the second software, and/or an updated version of the third software. When the payment service receives the indication of the current version of the first software from the merchant device, the payment service can compare the current version of the first software to the updated version of the first software within the software update to determine that the merchant device includes a previous version of the first software. Based on the determination, the payment service can send the merchant device the software update via the network connection. In some instances, the payment service sends the software update to the merchant device using hypertext transfer protocol (HTTP). In other instances, other types of techniques may be used.
The merchant device can receive the software update from the payment service and store the software update in response. In some instances, the merchant device stores the entire software update while in other instances, the merchant device stores only a portion of the software update (e.g., the updated version of the second software and/or the updated version of the third software). The merchant device can further use the updated version of the first software included in the software update to update the first software on the merchant device. In some instances, in response to updating the first software, the merchant device can reboot in order to apply the update to the merchant device.
After updating the first software, the merchant device can cause the customer device to update the second software stored on the customer device. For instance, the merchant device may detect, via a physical connection, a connection to the customer device. In response, the merchant device may send, via the physical connection, a message to the customer device that requests information associated with a current version of the second software included on the customer device. The customer device can receive the message from the merchant device and send, via the physical connection, the merchant device an indication of the current version of the second software. Using the indication, the merchant device can determine if the second software included on the customer device requires an update.
For instance, the merchant device can compare the current version of the second software to the updated version of the second software included in the stored software update to determine if the customer device includes a previous version of the second software or the updated version of the second software. In some instances, based on determining that the customer device includes the updated version of the second software, the merchant device can refrain from sending the customer device the software update. However, in some instances, based on determining that the customer device includes the previous version of the second software, the merchant device can send the customer device the software update via the physical connection, which causes the customer device to update the second software.
In some instances, before sending the customer device the software update, the merchant device first causes the customer device to reboot in an update mode. For instance, the merchant device can cut the power to the customer device via the physical connection. The merchant device can then cause the customer device to reboot in the update mode which, in some instances, can include causing the customer device to boot without loading the operating system of the customer device. While the customer device is in the update mode, the merchant device can send the software update to the customer device, which the customer device can use to update the second software. In some instances, updating the second software includes performing a flash update by overwriting the second software on the customer device with the updated version of the second software from the software update. After updating the second software, the customer device can reboot into a payments mode, which allows the customer device to once again receive payment information from customers.
In some instances, the customer device can then update the third software within the secure payments enclave. The third software can include software stored by one or more microcontrollers included in the secure payments enclave, such as firmware, system software, application software, or the like. Additionally, the third software can also include software being stored by a touch controller included in the secure payments enclave, such as firmware, system software, application software, or the like.
To update the third software, the customer device can compare a current version of the software included in the one or more microcontrollers to an updated version of the software included in the software update for the one or more microcontrollers. Based on the comparison, if the customer device determines that the current version of the software includes the updated version of the software from the software update, the customer device refrains from applying an update to the one or more microcontrollers. However, based on the comparison, if the customer device determines that the current version of the software includes a previous version of the software, the customer device updates the software included in the one or more microcontrollers using the software update.
For instance, the customer device can cause the secure payments enclave to enter an update mode of operation. In some instances, while in the update mode of operation, the secure payments enclave is only operable to receive updates from the customer device. The customer device can then update the software included in the one or more microcontrollers using the updated version of the software from the software update. In some instances, updating the software can include performing a flash update of the software on the one or more microcontrollers. After the update, the customer device can cause the secure payments enclave to once again enter a payments mode of operation in which the customer device can receive input from customers.
In some instances, the customer device can perform a similar process to update the software included in the touch controller. For instance, the customer device can compare a current version of the software included in the touch controller to an updated version of the software included in the software update for the touch controller. Based on the comparison, if the customer device determines that the current version of the software includes the updated version of the software from the software update, the customer device refrains from applying an update to the touch controller. However, based on the comparison, if the customer device determines that the current version of the software includes a previous version of the software, the customer device updates the software included in the touch controller using the software update.
For instance, the customer device can cause the secure payments enclave to enter an update mode of operation. As discussed above, in some instances, while in the update mode of operation, the secure payments enclave is only operable to receive updates from the customer device. The customer device can then update the software included in the touch controller using the updated version of the software from the software update. In some instances, updating the software can include performing a flash update of the software on the touch controller. After the update, the customer device can cause the secure payments enclave to once again enter a payments mode of operation in which the customer device can receive input from customers.
By performing the techniques described herein, the POS system is capable of securely updating software using the payment service. For instance, and as described herein, the software update received from the payment service may be encrypted using a software key, which is then encrypted using a device key that is associated with the merchant device. By receiving such an encrypted software update, the merchant device can ensure that the software update is from a secure payment service (e.g., not from an unsecure third-party system). Additionally, the merchant device and the customer device may perform a verification process (described below) in order to ensure that the customer device securely updated the second software on the customer device.
Additionally, by performing the techniques described herein, the POS system is capable of updating the customer device even when the customer device does not include a network connection to connect with the payment service (and/or does not include any type of wireless connection). For instance, the first merchant device can receive, within the software update, the updated version of the second software for the customer device. The merchant device can then cause the customer device to update the second software via the physical connection between the merchant device and the customer device.
As used in herein, a merchant device (e.g., the first merchant device 112, the second merchant device 114, or a merchant system which includes both the first merchant device 112 and the second merchant device 114) may comprise any sort of mobile or non-mobile devices (e.g., electronic device(s)) that include instances of application(s) that execute on the respective merchant device. The application(s) may provide POS functionality to the merchant devices to enable the merchant 102 (e.g., owners, employees, etc.) to at least accept payments from the customer(s) 104. In some types of businesses, the merchant devices may correspond to a store or other place of business of the merchant 102, and thus, may be a fixed location that typically does not change on a day-to-day basis. In other types of businesses, however, the location of the merchant devices may change from time to time, such as in the case that the merchant 102 operates a food truck, is a street vendor, is a cab driver, etc., or has an otherwise mobile business, e.g., in the case the merchant 102 sells items at buyer's homes, places of business, and so forth. In either of the examples above, the place of business of the merchant 102 may be referred to as a physical establishment 116.
Additionally, as used herein, a merchant 102 (also referred to as an “entity”) may include any business engaged in the offering of items (e.g., goods) or services for acquisition by customer(s) 104. Actions attributed to a merchant 102 may include actions performed by owners, employees, or other agents of the merchant 102, and thus no distinction is made herein unless specifically discussed. In addition, as used herein, a customer 104 may include any entity that acquires items or services from a merchant 102, such as by purchasing, renting, leasing, borrowing, licensing, or the like. Hereinafter, items and/or services offered by merchants 102 may be referred to solely as items. Thus, a merchant 102 and a customer 104 may interact with each other to conduct a transaction in which the customer 104 acquires an item from a merchant 102, and in return, the customer 104 provides payment to the merchant 102.
As used herein, a transaction may include a financial transaction for the acquisition of items and/or services that is conducted between customer(s) 104 and the merchant 102. For example, when paying for a transaction, a customer 104 can provide the amount that is due to the merchant 102 using cash or other payment instrument 110 (e.g., a debit card, a credit card, a stored-value or gift card, a check, through an electronic payment application on a device carried by the customer 104, or the like). For instance, as discussed above, the customer 104 can interact with the second merchant device 114 to process the transaction, such as by inputting (e.g., manually, using a magnetic card reader or an RFID reader, etc.) identifiers (e.g., payment information, such as a card number, account number, or any other account information) associated with the payment instrument 110. For example, a payment instrument 110 of the customer 104 may include one or more magnetic strips for providing card and customer information when swiped in a card reader. In other examples, the payment instrument 110 may include other types of payment cards may be used, such as smart cards having a built-in memory chip that is read by the second merchant device 114 when the card is “dipped” into the reader, a radiofrequency identification tag, or so forth.
During a transaction between a merchant 102 and a customer 104, the merchant 102 may input transaction information describing the transaction into the first merchant device 112, such as an amount of payment received from the customer 104, the item(s)/service(s) 106 acquired by the customer 104, a time, place and date of the transaction, a card network associated with the payment instrument 110, an issuing bank of the payment instrument 110, a name of the customer 104, and so forth. The first merchant device 112 can then receive the payment information from the second merchant device 114 via a connection 118, which may be encrypted, and send the transaction information along with the payment information to the payment service 108 over a network 120, either substantially contemporaneously with the conducting of the transaction (in the case of online transactions) or later when the first merchant device 112 is in the online mode (in the case offline transactions).
The payment service 108 may include one or more processors 122 and memory 124, which may store an operating system 126, a payment processing module 128, an identification module 130, an update module 132, an encryption/decryption module 134, and databases(s) 136. The payment processing module 128 may function to receive the information regarding the transaction from the first merchant device 112 and attempt to authorize the payment instrument 110 used to conduct the transaction. The payment processing module 128 may then send an indication of whether the payment instrument 110 has been approved or declined back to the first merchant device 112.
Generally, when a customer 104 and a merchant 102 enter into an electronic payment transaction, the transaction is processed by electronically transferring funds from a financial account associated with the customer 104 to a financial account associated with the merchant 102. As such, the payment processing module 128 may communicate with one or more computing devices of a card network (or “card payment network”) 138, e.g., MasterCard®, VISA®, over the network 120 to conduct financial transactions electronically. The payment processing module 128 can also communicate with one or more computing devices of one or more banks 140, processing/acquiring services, or the like over the network 120. For example, the payment processing module 128 may communicate with an acquiring bank, and/or an issuing bank, and/or a bank maintaining customer accounts for electronic payments.
An acquiring bank may be a registered member of a card association (e.g., Visa®, MasterCard®), and may be part of a card payment network. An issuing bank may issue payment instrument(s) 110 to customer(s) 104, and may pay acquiring banks for purchases made by customer(s) 104 to which the issuing bank has issued the payment instrument(s) 110. Accordingly, in some examples, the computing device(s) of an acquiring bank may be included in the card payment network and may communicate with the computing devices of a card-issuing bank to obtain payment. Further, in some examples, a customer 104 may use a debit card instead of a credit card, in which case, the bank computing device(s) of a bank corresponding to the debit card may receive communications regarding a transaction in which the customer 104 is participating. Additionally, there may be computing devices of other financial institutions involved in some types of transactions or in alternative system architectures, and thus, the foregoing are merely several examples for discussion purposes.
In the example environment 100 of
For instance, the first merchant device 112 can send, via the network(s) 120, the payment service 108 a message that includes an identifier associated with the first merchant device 112, which is represented by message 146. In some instances, the identifier can include a serial number, hardware identification, or any other identifier that the payment service 108 can use to identify the first merchant device 112. The first merchant device 112 can also send, via the network(s) 120, a message that indicates a current version of the first software being executed by the first merchant device 112, which is represented by message 148. The payment service 108 can then use the identifier and the indication of the current version of the first software to send the first merchant device 112 a software update 142.
For instance, the payment service 108 can utilize the identification module 130 to identify the first merchant device 112. In some instances, the identification module 130 identifies the first merchant device 112 by comparing the identifier received from the first merchant device 112 to a database of identifier(s) 150 that the payment service 108 stores for various merchant devices (e.g., other first merchant devices associated with other merchants). In some instances, each of the identifier(s) 150 within the database may be associated with a respective merchant device, and may identify the respective merchant device by serial number, hardware identification, or the like. As such, the identification module 130 can match the identifier received from the first merchant device 112 to one of the identifier(s) 150 stored in the database to identify the first merchant device 112.
The payment service 108 may then utilize the update module 132 to determine whether there is an update available for the first merchant device 112. For instance, the update module 132 may compare the current version of the first software executing on the first merchant device 112 to the latest version of the first software that the payment service 108 has stored within the software update(s) 142. In some instances, a version of software can include a unique version name, a unique version number, or other indicator that indicates a unique state of the software. As such, the update module 132 can compare the current version of the first software, which may include a first version name and/or first version number, to the most recent version of the first software from the software update(s) 142, which can include a second version name and/or second version number, to determine if the current version of the first software includes the most recent version of the first software.
For example, the current version of the first software may indicate that the first merchant device 112 is executing version 1.1 of the first software. The payment service 108 may store a software update 142 that includes version 1.2 of the first software. The update module 132 can thus compare the current version of the first software executing on the first merchant device 112 to the updated version of the first software within the software update 142 to determine that the first merchant device 112 can update the first software to version 1.2.
Based on determining that the first merchant device 112 can update the first software, the payment service 108 can send a message that includes the software update 142 to the first merchant device 112 via the network(s) 120, which is represented by message 152. In some instances, the payment service 108 sends the software update 142 to the first merchant device 112 using HTTP. In other instances, the payment service 108 can send the first update 142 to the first merchant device 112 using some other type of communications protocol.
In some instances, the payment service 108 first utilizes the encryption/decryption module 134 to encrypt the software update 142 before sending. For instance, the payment service 108 may store key(s) 154 (e.g., encryption keys), where a respective one of the key(s) 154 includes a device key 154 associated with a respective merchant device. As such, using the identity of the first merchant device 112, the encryption/decryption module 134 can retrieve the device key 154 associated with the first merchant device 112.
The encryption/decryption module 134 can then encrypt the software update using a software key 154 in order to generated an encrypted software update 142. In some instances, the software key 154 includes a generic key that the payment service 108 uses to encrypt the software update 142 before sending the software update 142 to any merchant device. The payment service 108 can then encrypt the software key 154 using the device key 154 associated with the first merchant device 112 to generate an encrypted software key 154. The payment service 108 can then send, via the network(s) 120, the encrypted software key 154 along with the encrypted software update 142 to the first merchant device 112, which is represented by message 156.
As discussed herein, processor(s) (e.g., processor(s) 122, processor(s) 202, processor(s) 214, etc.), may comprise one or more processors or processing cores. For example, the processor(s) can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. In some cases, the processor(s) may be one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) can be configured to fetch and execute computer-readable processor-executable instructions stored in the memory.
Additionally, as discussed herein, memory (e.g., memory 124, memory 212, memory 222, etc.) may be an example of tangible non-transitory computer storage media and may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information such as computer-readable processor-executable instructions, data structures, program modules or other data. The memory may include, but is not limited to, RAM, ROM, EEPROM, flash memory, solid-state storage, magnetic disk storage, optical storage, and/or other computer-readable media technology. Further, in some cases, devices, such as merchant device(s), the payment service 108, a customer device, or the like, can access external storage, such as RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store information and that can be accessed by the processor(s) directly or through another computing device or network. Accordingly, the memory may be computer storage media able to store instructions, modules or components that may be executed by the processor(s). Further, when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and signals per se
To facilitate communication via communications channels, communication interface(s) (e.g. network interface(s) 158, network interface(s) 204, network interface(s) 216, etc.) can facilitate communications within a wide variety of networks and protocol types. Such networks and protocol types can include wired networks (e.g., Ethernet, DOCSIS, DSL, Fiber, universal serial bus (USB), etc.), which may also be referred to as physical connections, and wireless networks (e.g., WLAN, GSM, CDMA, 802.11, Bluetooth, Wireless USB, cellular, satellite, the Internet, etc.), which may also be referred to as network connections. In some instances, communication interface(s) 216 of the second merchant device 114 may only be include one or more of the wired networks. For instance, the first merchant device 112 and the second merchant device 114 may communicate via a physical connection, such as through a USB connection.
The I/O interface 208 and the I/O interface 220 can include peripheral input devices, such as a keyboard, a mouse, a pen, a game controller, a voice input device, a touch input device, a gestural input device, or any other device capable of receiving input. The input may include input events, e.g., a merchant or a customer touching or simulating a touch by placing a finger in proximity to a respective display (e.g., a presence-sensitive display), or by using a keyboard or other input mechanism. In various examples, the input may comprise a series of input events related to processing transactions via the first software and the second software, such as processing payment for goods and/or services.
The memory 212 of the first merchant device 112 includes an operating system 226, a downloader module 228, an encryption/decryption module 230, a software update module 232, a device update module 234, first software 236, key(s) 238 (e.g., encryption keys), preference(s) 240, the software update 142, and the identifier 146. The first merchant device 112 can utilize the downloader module 228 to receive the software update 142 from the payment service 108. For instance, as described in detail with regard to
After receiving the software update 142, in instances where the software update 142 is encrypted, the first merchant device 112 can utilize the encryption/decryption module 230 to decrypt the software update 142. For instance, the encryption/decryption module 230 can retrieve the encrypted software key 238 sent from the payment service 108 along with the encrypted software update 142. The encryption/decryption module 230 can then use a local version of the device key 238, which can be similar to the device key 154 used by the payment service 108 to encrypt the encrypted software key 238, to decrypt the encrypted software key 238. After decrypting the software key 238, the encryption/decryption module 230 can decrypt the software update 142 using the software key 238.
The first merchant device 112 can then utilize the software update module 232 to update the first software 236 on the first merchant device 112. As described herein, the first software 236 can include any type of software that can be updated on the first merchant device 112, such as firmware, system software, application software, or the like. To update the first software 236, the software update module 232 can retrieve the updated version of the first software from the software update 142 and update the first software 236 using the updated version. After updating the first software 236, the first merchant device 112 can reboot to finish the updating process.
As discussed above, the first merchant device 112 can further cause the second merchant device 114 to update second software 244 stored on the second merchant device 114. As described herein, the second software 244 can include any type of software that can be updated on the second merchant device 114, such as firmware, system software, application software, or the like. To cause the second merchant device 114 to update the second software 244, the first merchant device 112 can utilize the device update module 234 to send a message to the second merchant device 114 that requests a current version of the second software 244 stored on the second merchant device 114 via the connection 118. In some instances, the device update module 234 sends the message in response to detecting the connection 118 with the second merchant device 114. For example, the device update module 234 may send the message, after the first merchant device 112 reboots, when the second merchant device 114 is already connected to the first merchant device 112. For another example, the device update module 234 may send the message in response to the second merchant device 114 being connected to the first merchant device 112 after the reboot.
The first merchant device 112 can then receive, via the connection 118, a message from the second merchant device 114 that includes an identifier 242 associated with the second merchant device 114 (e.g., a serial number, hardware identification, or any other identifier that the first merchant device 112 can use to identify the second merchant device 114) and an indication the current version of the second software 244 that is stored on the second merchant device 114. Based on receiving the message, the device update module 234 can use a similar technique as described above with regard to the update module 132 to determine if the second merchant device 114 includes a previous version of the second software 244.
For instance, the device update module 234 can compare the current version of the second software 244 stored on the second merchant device 114, which may include a first version name and/or first version number, to the updated version of the second software 244 from the software update 142, which can include a second version name and/or second version number. Based on the comparison, the device update module 234 can determine if the current version of the second software 244 stored on the second merchant device 114 should be (and/or is required to be) updated.
For instance, if the device update module 234 determines that the second merchant device 114 already includes the updated version of the second software 244 (e.g., the first version name and/or first version number matches the second version name and/or second version number), then the device update module 234 can refrain from sending the software update 142 to the second merchant device 114. However, if the device update module 234 determines that the second merchant device 114 includes a previous version of the second software 244 (e.g., the first version name and/or first version number matches the second version name and/or second version number), then the device update module 234 can determine to update the second merchant device 114.
To update the second merchant device 114, the device update module 234 can cause the second merchant device 114 to switch from a first mode of operation (e.g., a payments mode) in which the second merchant device 114 operates when conducting transactions with customers, to a second mode of operation (e.g., an emergency download mode, also referred to as an update mode) for updating the second merchant device 114. In some instances, the second merchant device 114 enters the second mode of operation by not booting the operating system 246 during the booting process. In some instances, the device update module 234 causes the second merchant device 114 to switch to the second mode of operation by rebooting the second merchant device 114. For instance, the device update module 234 can cut the power to the second merchant device 114, send a signal to the second merchant device 114 to enter the second mode of operation, and then turn the power back on to the second merchant device 114. The device update module 234 then sends the software update 142, and/or a portion of the software update 142, such as second version of the second software 244 and/or the third version of the third software, to the second merchant device 114.
For example, as discussed above, in some instances, the connection 118 can include a USB connection between the first merchant device 112 and the second merchant device 114. In such instances, the device update module 234 can cut the power to the second merchant device 114, turn on a pin of the USB connection that causes the second merchant device 114 to enter the second mode of operation, and then turn the power back on. In response, the second merchant device 114 can reboot in the second mode of operation. For instance, in the second mode of operation, the second merchant device 114 may not boot the operating system 246 on the second merchant device 114, but enter an emergency download mode. Based on the second merchant device 114 operating in the emergency download mode, the device update module 232 then sends the software update 142 to the second merchant device 114.
As shown, the memory 222 of the second merchant device 114 includes the operating system 246, a software update module 248, an enclave update module 250, the identifier 242, the second software 244, and the software update 142. The second merchant device 114 can utilize the software update module 248 to update the second software 244 on the second merchant device 114. To update the second software 244, the software update module 248 can retrieve the updated version of the second software from the software update 142 and update the second software 244 using the updated version. After updating the second software 244, the second merchant device 114 can reboot to finish the updating process. For instance, the second merchant device 114 can reboot back into the first mode of operation.
In some instances, updating of the second software 244 on the second merchant device 114 includes a flash update of the second software 244 on the second merchant device 114. For instance, the second merchant device 114 can overwrite the second software 244 on the second merchant device 114 with the updated version of the second software 244 from the software update 142. In some instances, the first merchant device 112 causes the flash update by sending the software update 142 to the second merchant device 114 via the connection 118.
In some instances, the first merchant device 112 and/or the second merchant device 114 can utilize one or more verification techniques to verify that the second merchant device 114 was securely updated. For instance, the second merchant device 114 can generate a hash and/or a table of hashes that are based on the software update 142 that the first merchant device 112 sends to the second merchant device 114, and then send the hash and/or the table of hashes to the first merchant device 112. In response, the first merchant device 112 can check the hash and/or the table of hashes to verify that only data that the first merchant device 112 sent to the second merchant 114 is what the second merchant device 114 received and used to update the second software 244. For instance, the first merchant device 112 can compare the hash and/or table of hashes to the software update 142 stored on the first merchant device 112.
In some instances, the second merchant device 114 can utilize the enclave update module 250 to update software in the secure enclave 224. For instance, upon reboot of the second merchant device 114, the enclave update module 250 can check current versions of third software stored within the secure enclave 224. In some instance, the third software can include both software being executed by the microcontroller(s) 252, which can include firmware, system software, application software, or the like. The third software can also include software being executed by the touch controller 254, which can include firmware, system software, application software, or the like. The enclave update module 250 can then update the software stored on the microcontroller(s) 252 when the software does not include an updated version of the software from the software update 142, and/or the enclave update module 250 can update software stored on touch controller 254 when the software does not include an updated version of the software from the software update 142.
For instance, the enclave update module 250 can compare a current version of the software stored on the microcontroller(s) 252, which can include a first version name, a first version number, or the like, to an updated version of software within the software update 142 for the microcontroller(s) 252, which can include a second version name, second version number, or the like. Based on the comparison, if the enclave update module 250 determines that the current version of the software matches the updated version of the software, such that the first version name, the first version number, or the like matches the second version name, the second version number or the like, then the enclave update module 250 refrains from applying an update to the microcontroller(s) 252. However, based on the comparison, if the enclave update module 250 determines that the current version of the software does not match the updated version of the software, such that the first version name, the first version number, or the like does not match the second version name, the second version number or the like, then the enclave update module 250 updates the software stored on the microcontroller(s) 252 using the software update 142.
For instance, the enclave update module 250 can cause the secure enclave 224 to enter an update mode of operation. In some instances, while in the secure mode of operation, the secure enclave 224 is only operable to receive updates from the enclave update module 250. The enclave update module 250 can then update the software stored on the microcontroller(s) 252 using the updated version of the software for the microcontroller(s) 252. In some instances, updating the software can include performing a flash update of the software on the microcontroller(s) 252. For instance, the enclave update module 250 can overwrite the software on the microcontroller(s) 252 with the updated version of the software from the software update 142. After the update, the secure enclave 224 can one again enter a payments mode in which the second merchant device 114 can receive input, such as customers.
In some instances, when the secure enclave 224 includes more than one microcontroller 252, the enclave update module 250 can send the software update to one of the microcontrollers 252, which then can pass the update to the one or more other microcontrollers 252. In such instances, each of the microcontrollers 252 can then be updated by performing a flash update using the updated version of the software from the software update 142.
Additionally, the enclave update module 250 can compare a current version of the software stored on the touch controller 254, which can include a first version name, a first version number, or the like, to an updated version of software within the software update 142 for the touch controller 254, which can include a second version name, second version number, or the like. Based on the comparison, if the enclave update module 250 determines that the current version of the software matches the updated version of the software, such that the first version name, the first version number, or the like matches the second version name, the second version number or the like, then the enclave update module 250 refrains from applying an update to the touch controller 254. However, based on the comparison, if the enclave update module 250 determines that the current version of the software does not match the updated version of the software, such that the first version name, the first version number, or the like does not match the second version name, the second version number or the like, then the enclave update module 250 updates the software stored on the touch controller 254 using the software update 142.
For instance, the enclave update module 250 can cause the secure enclave 224 to enter an update mode of operation. As discussed above, in some instances, while in the secure mode of operation, the secure enclave 224 is only operable to receive updates from the enclave update module 250. The enclave update module 250 can then update the software stored on the touch controller 254 using the updated version of the software for the touch controller 254. In some instances, updating the software can include performing a flash update of the software on the touch controller 254. For instance, the enclave update module 250 can overwrite the software on the touch controller 254 using the updated version of the software from the software update 142. After the update, the secure enclave 224 can one again enter a payments mode in which the second merchant device 114 can receive input, such as customers.
In some instances, the enclave update module 250 updates the touch controller 254 while the second merchant device 114 is rebooting. In some instances, the enclave update module 250 updates the touch controller 254 right after the second merchant device 114 finishes booting up. Still, in some instances, the enclave update module 250 updates the touch controller contemporaneously with the updating of the microcontroller(s) 252.
As also illustrated in
Furthermore, the secure enclave 224 of the second merchant device 114 includes a reader 256. In some instances, the reader 256 may include an EMV slot that can read payment information from a memory chip in a payment card. In some instances, the reader 256 can include an NFC antenna for reading payment information from an electronic device. Still, in other instances, the reader 256 may include a read head for reading a magnetic strip of a payment card. In either of the instances above, the reader 256 may include encryption technology for encrypting the information read from the magnetic strip. Before sending the information to the first merchant device 112.
As described herein, a display (e.g., the display 206, the display 218, etc.) may employ any suitable display technology. For example, the display may be a liquid crystal display, a plasma display, a light emitting diode display, an OLED (organic light-emitting diode) display, an electronic paper display, or any other suitable type of display able to present digital content thereon. In some examples, the display may have a touch sensor associated with the display to provide a touchscreen display configured to receive touch inputs for enabling interaction with a graphic interface presented on the display. Accordingly, implementations herein are not limited to any particular display technology.
It should be noted that, in some instances, the first merchant device 112 can use the same processes described above with one or more other merchant devices that are similar to the second merchant device 114 (i.e., other buyer-facing devices). For instance, the first merchant device may detect a connection with a third merchant device via the physical connection, receive a current version of the second software stored on the third merchant device, and determine whether to cause an update to the second software. In some instances, if the first merchant device 112 determines that the current version of the second software includes the updated version of the second software from the software update, then the first merchant device 112 refrains from updating the third electronic device. However, in some instances, if the first merchant device 112 determines that the current version of the second software includes a previous version of the second software, then the first merchant device 112 can cause the third merchant device to update the second software.
At 302, a payment service 108 stores a software update. For instance, the payment service 108 may store a software update for merchant systems, where a merchant system includes at least a first merchant device 112 (e.g., a merchant-facing device) and a second merchant device 114 (e.g., a customer-facing device). The software update can thus include an update for first software executing on the first merchant device 112, an update for second software executing on the second merchant device 114, and/or an update for third software executing within a secure enclave of the second merchant device 114.
At 304, the first merchant device stores first software. For instance, the first merchant device 112 may include the merchant-facing device and execute first software that provides the first merchant device 112 with POS functionality. In some instances, the POS functionality can allow the first merchant device 112 to receive information from a merchant during a transaction between the merchant and a customer. For instance, the merchant can input information indicating at least one or more items being purchased by the customer and a cost associated with the one or more items.
At 306, the first merchant device 112 sends an identifier associated with the first merchant device 112 to the payment service 108. For instance, the first merchant device 112 can send the payment service 108 an identifier, such as a serial number, hardware identification, or the like. In some instances, the first merchant device 112 sends the identifier to the payment service 108 via network(s) 120.
At 308, the payment service 108 receives the identifier associated with the first merchant device 112 and at 310, the payment service 108 identifies the first merchant device 112 using the identifier. For instance, the payment service may store a database of identifiers associated merchant devices. The payment service 108 can thus search the database using the identifier associated with the first merchant device 112 to identify the first merchant device 112. For instance, the payment service 108 can match the identifier associated with the first merchant device 112 with one of the identifiers within the database.
At 312, the first merchant device 112 sends an indication of a current version of the first software to the payment service 108 and at 314, the payment service 108 receives the indication of the current version of the first software from the first merchant device 112. In some instances, the first merchant device 112 may send the indication based on receiving a message requesting the current version of the first software from the payment service 108. In some instance, the first merchant device 112 may send the indication based on the first merchant device 112 connecting to the payment service 108 via the network(s) 120. Still, in some instances, the first merchant device 112 may send the indication based on a lapse of a set time period. For instance, the first merchant device 112 may send an indication of the current version of the first software every day, week, month, or the like.
At 316, the payment service 108 determines that the first merchant device 112 can be updated. For instance, the payment service 108 can compare the current version of the first software executing on the first merchant device 112 to the updated version of the first software from the software update. Based on the comparison, the payment service 108 can determine that the first merchant device 112 is executing a previous version of the first software (i.e., a version before the updated version of the first software). In response, the payment service 108 can determine that the first merchant device 112 can be updated.
At 318, the payment service 108 sends the software update to the first merchant device 112 and at 320, the first merchant device 112 receives the software update from the payment service 108. For instance, based on determining that the first merchant device 112 can be updated, the payment service 108 can send, via the network(s) 120, the software update to the first merchant device 112. In some instances, the first merchant device 112 first sends the payment service 108 a message requesting the software update before the payment service 108 sends the first merchant device 112 the software update. In some instances, the payment service 108 sends an encrypted version of the software update along with a software key for decrypting the software update. In such instances, the software key can be encrypted with a device key that is associated with the first merchant device 112.
At 322, the first merchant device 112 stores the software update and at 324, the first merchant device 112 updates the first software using the software update. For instance, the first merchant device 112 can store in the software update in memory. In some instances, the first merchant device 112 stores the entire software update. In some instances, the first merchant device 112 stores a portion of the software update. For instance, the first merchant device 112 may store the second version of the second software and the third version of the third software. The first merchant device 112 can then update the first software executing on the first merchant device 112 using the updated version of the first software from the software update.
At 326, the first merchant device reboots and at 328, the first merchant device 112 detects a connection with a second merchant device 114. For instance, after updating the first software, the first merchant device 112 can reboot in order to finish the updating process on the first merchant device 112. The first merchant device 112 can detect the connection with the second merchant device 114 via a physical connection. In some instances, the first merchant device 112 detects the connection after rebooting. In some instances, the first merchant device 112 detects the connection based on a merchant connecting the second merchant device 114 to the first merchant device 112.
At 330, the first merchant device 112 sends a request for a current version of second software executing on the second merchant device 114 and at 332, the second merchant device 114 receives the request for the current version of the second software. For instance, the second merchant device 114 may include second software that the second merchant device 114 executes to provide the POS functionality of the second merchant device 114. For instance, the second software can provide the second merchant device 114 with functionality to receive input associated with payment information from customers. Based on detecting the connection with the second merchant device 114, the first merchant device 112 can send, via the physical connection, the second merchant device 114 a message requesting the current version of the second software.
At 334, the second merchant device 114 sends an indication of the current version of the second software to the first merchant device 112 and at 336, the first merchant device 112 receives the indication of the current version of the second software from the second merchant device 114. For instance, based on receiving the request from the first merchant device 112, the second merchant device 114 can send, via the physical connection, the first merchant device 112 a message that indicates the current version of the second software executing on the second merchant device 114.
At 338, the first merchant device 112 determines to update the second merchant device 114. For instance, the first merchant device 112 can compare the current version of the second software executing on the second merchant device 114 to the updated version of the second software from the software update. Based on the comparison, the first merchant device 112 can determine that the second merchant device 114 is executing a previous version of the second software (i.e., a version before the updated version of the second software). In response, the first merchant device 112 can determine to update the second merchant device 114.
At 340, the first merchant device 112 causes the second merchant device 114 to reboot in an update mode and at 342, the second merchant device 114 reboots in the update mode. For instance, the first merchant device 112 can cause the second merchant device to lose power. In some instances, the first merchant device 112 can then turn a pin on within the physical connection that causes the second merchant device 114 to reboot in the update mode, and then turn the power back on to the second merchant device 114. In response, the second merchant device 114 can reboot in the update mode. In some instances, rebooting in the update mode can include the second merchant device 114 not booting the operating system.
At 344, the first merchant device 112 sends at least a portion of the software update to the second merchant device 114 and at 346, the second merchant device 114 receives the at least the portion of the software update. For instance, based on the second merchant device 114 being in the update mode, the first merchant device 112 can send, via the physical connection, the second merchant device 114 the software update and/or at least a portion of the software update. If the first merchant device 112 only sends a portion of the software update, the portion can include the second version of the second software and the third version of the third software.
At 348, the second merchant device 114 updates the second software using the at least the portion of the software update and at 350, the second merchant device 114 reboots in a payments mode. For instance, the second merchant device 114 can use the second version of the second software from the software update to update the second software on the second merchant device 114. In some instances, the update can include a flash update in which the second merchant device 114 overwrites the second software on the second merchant device 114 with the updated version of the second software from the software update. In response to updating the second software, the second merchant device 114 can then reboot in the payments mode so that the second merchant device 114 can once again receive payment information from customers.
In some instances, during and/or after the second merchant device 114 reboots into the payments mode, the second merchant device 114 can use the software update to update a secure enclave on the second merchant device 114. Such a process is described in detail below with regard to
At 404, the first merchant device 112 sends, to a payment service 108 via a network connection, an indication of a first version of the first software. For instance, the first merchant device may determine that the first version of the first software is executing on the first merchant device 112 and, in response, send an indication of the first version of the payment service 108. In some instances, the first merchant device 112 may send the indication based on receiving a message requesting the current version of the first software from the payment service 108. In some instance, the first merchant device 112 may send the indication based on the first merchant device 112 connecting to the payment service 108 via the network(s) 120. Still, in some instances, the first merchant device 112 may send the indication based on a lapse of a set time period.
At 406, the first merchant device 112 receives, via the network connection, a software update from the payment service 108, the software update including at least a second version of the first software and a second version of second software. For instance, based on sending the payment service 108 the indication of the first version, the first merchant device 112 can receive the software update from the payment service 108. The payment service 108 may send the software update based on determining that the first version of the first software is a previous version of the first software.
At 408, the first merchant device 112 stores the software update and at 410, the first merchant device 112 updates the first software using the second version of the first software. For instance, based on receiving the software update, the first merchant device 112 can store the software update in memory. The first merchant device 112 can then use the second version of the first software that is included in the software update to update the first software executing on the first merchant device 112 to the second version. In some instances, the first merchant device 112 then reboots in order to finish the process of updating the first software.
At 412, the first merchant device 112 detects, via a physical connection, a connection with an electronic device. For instance, the first merchant device 112 can detect the connection with a second merchant device 114 that executes the second software in order to provide the second merchant device 114 with POS functionality. The first merchant device 112 can detect the connection with the second merchant device 114 via a physical connection. In some instances, the first merchant device 112 detects the connection after rebooting. In some instances, the first merchant device 112 detects the connection based on a merchant connecting the second merchant device 114 to the first merchant device 112.
At 414, the first merchant device 112 sends, to the electronic device via the physical connection, a request for a current version of second software included on the electronic device. For instance, based on detecting the second merchant device 114, the first merchant device 112 can send a message to the second merchant device 114 that request the current version of the second software. The first merchant device 112 can send the message to the second merchant device 114 via the physical connection.
At 416, the first merchant device 112 receives, from the electronic device via the physical connection, an indication that the electronic device includes a first version of the second software. For instance, based on sending the message, the first merchant device 112 can receive a message back from the second merchant device 114 that indicates that the second merchant device 114 is includes the first version of the second software. The first merchant device 112 can receive the message via the physical connection.
At 418, the first merchant device 112 determines that the electronic device includes a previous version of the second software. For instance, the first merchant device 112 can compare the first version of the second software that the second merchant device 114 includes to the second version of the second software from the software update. Based on the comparison, the first merchant device 112 can determine that the second merchant device 114 includes a previous version of the second software.
At 420, the first merchant device 112 causes, via the physical connection, the electronic device to reboot in an update mode. For instance, based on determining that the second merchant device 114 is executing a previous version of the second software, the first merchant device 112 can cause, via the physical connection, the second merchant device 114 to reboot in an update mode in which the second merchant device 114 can be updated.
At 420, the first merchant device 112 sends, via the physical connection, at least the second version of the second software to the electronic device. For instance, the first merchant device 112 can send, via the physical connection, the second version of the second software to the second merchant device 114. In response, the second merchant device 114 can perform a flash update in order to update the second software executing on the second merchant device 114. The second merchant device 114 can then reboot back into a payments mode after updating the second software.
At 504, the second merchant device 114 receives, from an electronic device via a physical connection, a request for a current version of the software and at 506, the second merchant device 114 sends, to the electronic device via the physical connection, an indication of the first version of the software. For instance, based on having a connection with a first merchant device 112, the second merchant device 114 can receive a message from the first merchant device 112 requesting the current version. In response, the second merchant device 114 can send a message to the first merchant device 112 indicating that the second merchant device 114 is executing the first version of the software.
At 508, the second merchant device 114 reboots in an update mode. For instance, the second merchant device 114 may lose power and as such turn to an off mode. The second merchant device 114 may then once again receive power and in response, reboot. While rebooting, the second merchant device 114 may determine that a pin associated with the physical connection is flipped and based on the determination, reboot in the update mode. To reboot in the update mode, the second merchant device 114 may not boot the operating system of the second merchant device 114.
At 510, the second merchant device 114 receives, from the electronic device via the physical connection, a software update and at 512, the second merchant device 114 updates the software using the software update. For instance, the second merchant device 114 may receive the software update while in the update mode, where the software update includes a second version of the software. The second merchant device 114 can then perform a flash update by overwriting the first version of the software executing on the second merchant device 114 with the second version of the software from the software update.
At 514, the second merchant device 114 reboots in a payments mode. For instance, based on updating the software, the second merchant device 114 can reboot in order to complete the process of updating the software on the second merchant device 114. In some instances, the second merchant device 114 can reboot in a payments mode in which the second merchant device 114 can receive input from customers.
At 516, the second merchant device 114 can check a current version of software included in a touch controller. For instance, the second merchant device 114 can determine the current version of the software executing in the touch controller, where the touch controller is located in a secure enclave of the second merchant device 114. The second merchant device 114 can then determine, using the software update, that the current version of the software includes a previous version of the software. For instance, the second merchant device 114 can determine that the software update includes a newer version of the software by comparing the current version of the software to the version of the software within the software update.
At 518, the second merchant device 114 updates the software executing in the touch controller using the software update. For instance, the second merchant device 114 can cause the secure enclave to operate in an update mode. The second merchant device 114 can then cause a flash update of the software in the touch controller using the updated version of the software that is included in the software update. After updating the software in the touch controller, the second merchant device 114 can cause the secure enclave to again operate in a payments mode.
At 520, the second merchant device 114 can check a current version of software included in one or more microcontrollers. For instance, the second merchant device 114 can determine the current version of the software executing in the one or more microcontrollers, where the one or more microcontrollers are located in the secure enclave of the second merchant device 114. The second merchant device 114 can then determine, using the software update, that the current version of the software includes a previous version of the software. For instance, the second merchant device 114 can determine that the software update includes a newer version of the software by comparing the current version of the software to the version of the software within the software update.
At 522, the second merchant device 114 updates the software executing in the one or more microcontrollers using the software update. For instance, the second merchant device 114 can cause the secure enclave to operate in the update mode. The second merchant device 114 can then cause a flash update of the software in the one or more microcontrollers using the updated version of the software that is included in the software update. After updating the software in the touch controller, the second merchant device 114 can cause the secure enclave to again operate in a payments mode.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.
This application claims priority to and is a continuation of U.S. patent application Ser. No. 15/636,356, filed on Jun. 28, 2017, and issued as U.S. Pat. No. 10,949,189 on Mar. 16, 2021, the entire contents of which are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3128349 | Boesch et al. | Apr 1964 | A |
| 4776003 | Harris | Oct 1988 | A |
| 4860336 | D'Avello et al. | Aug 1989 | A |
| 5221838 | Gutman et al. | Jun 1993 | A |
| 5351296 | Sullivan | Sep 1994 | A |
| 5388155 | Smith | Feb 1995 | A |
| 5408513 | Busch, Jr. et al. | Apr 1995 | A |
| 5714741 | Pieterse et al. | Feb 1998 | A |
| 5729591 | Bailey | Mar 1998 | A |
| 5740232 | Pailles et al. | Apr 1998 | A |
| 5838773 | Eisner et al. | Nov 1998 | A |
| 5850599 | Seiderman | Dec 1998 | A |
| 5867795 | Novis et al. | Feb 1999 | A |
| 5940510 | Curry et al. | Aug 1999 | A |
| 6010067 | Elbaum | Jan 2000 | A |
| 6098881 | Deland, Jr. et al. | Aug 2000 | A |
| 6144336 | Preston et al. | Nov 2000 | A |
| 6234389 | Valliani et al. | May 2001 | B1 |
| 6278779 | Bryant et al. | Aug 2001 | B1 |
| 6360362 | Fichtner et al. | Mar 2002 | B1 |
| 6481623 | Grant et al. | Nov 2002 | B1 |
| 6886742 | Stoutenburg et al. | May 2005 | B2 |
| 6990683 | Itabashi | Jan 2006 | B2 |
| 7003316 | Elias et al. | Feb 2006 | B1 |
| 7066382 | Kaplan | Jun 2006 | B2 |
| 7083090 | Zuili | Aug 2006 | B2 |
| 7163148 | Durbin et al. | Jan 2007 | B2 |
| 7210627 | Morley et al. | May 2007 | B2 |
| 7363054 | Elias et al. | Apr 2008 | B2 |
| 7398922 | Hayashi | Jul 2008 | B2 |
| 7424732 | Matsumoto et al. | Sep 2008 | B2 |
| 7433452 | Taylor et al. | Oct 2008 | B2 |
| 7591425 | Zuili et al. | Sep 2009 | B1 |
| 7673799 | Hart et al. | Mar 2010 | B2 |
| 7810729 | Morley, Jr. | Oct 2010 | B2 |
| 7896248 | Morley, Jr. | Mar 2011 | B2 |
| 8086531 | Litster et al. | Dec 2011 | B2 |
| 8126734 | Dicks et al. | Feb 2012 | B2 |
| 8265553 | Cheon et al. | Sep 2012 | B2 |
| 8397988 | Zuili | Mar 2013 | B1 |
| 8498213 | Gnanasekaran et al. | Jul 2013 | B2 |
| 8542583 | Gnanasekaran et al. | Sep 2013 | B2 |
| 8588075 | Gnanasekaran et al. | Nov 2013 | B2 |
| 8593965 | Rongong et al. | Nov 2013 | B2 |
| 8599691 | Gnanasekaran et al. | Dec 2013 | B2 |
| 8767561 | Gnanasekaran et al. | Jul 2014 | B2 |
| 8792354 | Gnanasekaran et al. | Jul 2014 | B2 |
| 8797877 | Perla et al. | Aug 2014 | B1 |
| 9020853 | Hoffman et al. | Apr 2015 | B2 |
| 9264889 | Choi-Grogan et al. | Feb 2016 | B2 |
| 9268555 | Djabarov et al. | Feb 2016 | B2 |
| 9411574 | Kostadinov et al. | Aug 2016 | B2 |
| 9489496 | Wysocki et al. | Nov 2016 | B2 |
| 9543653 | Han et al. | Jan 2017 | B2 |
| 9608909 | Bharadwaj et al. | Mar 2017 | B1 |
| 9672028 | Vopni et al. | Jun 2017 | B1 |
| 9679286 | Colnot et al. | Jun 2017 | B2 |
| 9830141 | Cairns et al. | Nov 2017 | B2 |
| 9916737 | Osmon et al. | Mar 2018 | B2 |
| 9934014 | Diebolt et al. | Apr 2018 | B2 |
| 10050347 | Wei | Aug 2018 | B2 |
| 10572695 | Guise et al. | Feb 2020 | B1 |
| 10579989 | Binder et al. | Mar 2020 | B1 |
| 10635820 | Gallinghouse et al. | Apr 2020 | B1 |
| 20020091633 | Proctor | Jul 2002 | A1 |
| 20020153414 | Stoutenburg et al. | Oct 2002 | A1 |
| 20030076263 | Hassan-Zade et al. | Apr 2003 | A1 |
| 20030135418 | Shekhar et al. | Jul 2003 | A1 |
| 20030154414 | von Mueller et al. | Aug 2003 | A1 |
| 20030183691 | Lahteenmaki et al. | Oct 2003 | A1 |
| 20040012875 | Wood | Jan 2004 | A1 |
| 20040041911 | Odagiri et al. | Mar 2004 | A1 |
| 20040059682 | Hasumi et al. | Mar 2004 | A1 |
| 20040159699 | Nelson et al. | Aug 2004 | A1 |
| 20040167820 | Melick et al. | Aug 2004 | A1 |
| 20040204082 | Abeyta | Oct 2004 | A1 |
| 20050097015 | Wilkes et al. | May 2005 | A1 |
| 20050108444 | Flauaus et al. | May 2005 | A1 |
| 20050109841 | Ryan et al. | May 2005 | A1 |
| 20050236480 | Vrotsos et al. | Oct 2005 | A1 |
| 20060032905 | Bear et al. | Feb 2006 | A1 |
| 20060049255 | von Mueller et al. | Mar 2006 | A1 |
| 20060190611 | Miyazaki et al. | Aug 2006 | A1 |
| 20060223580 | Antonio et al. | Oct 2006 | A1 |
| 20070028120 | Wysocki | Feb 2007 | A1 |
| 20070051809 | Takahashi et al. | Mar 2007 | A1 |
| 20070067833 | Colnot | Mar 2007 | A1 |
| 20070121507 | Manzalini et al. | May 2007 | A1 |
| 20070168300 | Quesselaire et al. | Jul 2007 | A1 |
| 20070194104 | Fukuda et al. | Aug 2007 | A1 |
| 20070198436 | Weiss | Aug 2007 | A1 |
| 20080091617 | Hazel et al. | Apr 2008 | A1 |
| 20080204195 | Diorio et al. | Aug 2008 | A1 |
| 20090037284 | Lewis | Feb 2009 | A1 |
| 20090070583 | von Mueller et al. | Mar 2009 | A1 |
| 20090112768 | Hammad et al. | Apr 2009 | A1 |
| 20090164326 | Bishop et al. | Jun 2009 | A1 |
| 20100057620 | Li et al. | Mar 2010 | A1 |
| 20100243732 | Wallner | Sep 2010 | A1 |
| 20110078435 | Krieger et al. | Mar 2011 | A1 |
| 20110110232 | Abraham et al. | May 2011 | A1 |
| 20110110381 | Atkinson et al. | May 2011 | A1 |
| 20120094599 | Takeyama | Apr 2012 | A1 |
| 20120257523 | Kastur et al. | Oct 2012 | A1 |
| 20130249740 | Shedletsky | Sep 2013 | A1 |
| 20130260680 | Tsai | Oct 2013 | A1 |
| 20130300453 | Carapelli et al. | Nov 2013 | A1 |
| 20130309966 | Aldana et al. | Nov 2013 | A1 |
| 20130343186 | Gnanasekaran et al. | Dec 2013 | A1 |
| 20140056147 | Gnanasekaran et al. | Feb 2014 | A1 |
| 20140086054 | Rongong et al. | Mar 2014 | A1 |
| 20140148095 | Smith et al. | May 2014 | A1 |
| 20140150056 | Williams | May 2014 | A1 |
| 20140173579 | McDonald | Jun 2014 | A1 |
| 20140208786 | Billman et al. | Jul 2014 | A1 |
| 20140273830 | Wong et al. | Sep 2014 | A1 |
| 20140317614 | Djabarov et al. | Oct 2014 | A1 |
| 20140375481 | McNicoll | Dec 2014 | A1 |
| 20150048163 | Senior | Feb 2015 | A1 |
| 20150052512 | Kostadinov et al. | Feb 2015 | A1 |
| 20150077361 | Seo et al. | Mar 2015 | A1 |
| 20150178064 | Cairns et al. | Jun 2015 | A1 |
| 20150230081 | Choi-Grogan | Aug 2015 | A1 |
| 20150235204 | Wallner | Aug 2015 | A1 |
| 20150303994 | Dhayni | Oct 2015 | A1 |
| 20150339649 | Pi Farias | Nov 2015 | A1 |
| 20160006123 | Li et al. | Jan 2016 | A1 |
| 20160028157 | Kim et al. | Jan 2016 | A1 |
| 20160054989 | Diebolt et al. | Feb 2016 | A1 |
| 20160079802 | Choi et al. | Mar 2016 | A1 |
| 20160111770 | Choi et al. | Apr 2016 | A1 |
| 20160182127 | Karandikar et al. | Jun 2016 | A1 |
| 20160218432 | Pope et al. | Jul 2016 | A1 |
| 20160275478 | Li et al. | Sep 2016 | A1 |
| 20160306616 | Fomppo | Oct 2016 | A1 |
| 20160308587 | Lee et al. | Oct 2016 | A1 |
| 20160323428 | Kim et al. | Nov 2016 | A1 |
| 20170323537 | Lim et al. | Nov 2017 | A1 |
| 20170357961 | Bidar et al. | Dec 2017 | A1 |
| 20180005224 | Binder et al. | Jan 2018 | A1 |
| 20180063004 | Uppunda et al. | Mar 2018 | A1 |
| 20180068300 | Saeed et al. | Mar 2018 | A1 |
| 20180198190 | Leem | Jul 2018 | A1 |
| 20190004785 | Kelley et al. | Jan 2019 | A1 |
| 20210065159 | Bidar et al. | Mar 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 2324402 | Jun 2002 | AU |
| 1630988 | Jun 2005 | CN |
| 1928885 | Mar 2007 | CN |
| 102468872 | May 2012 | CN |
| 202261429 | May 2012 | CN |
| 102709686 | Oct 2012 | CN |
| 103905073 | Jul 2014 | CN |
| 204009927 | Dec 2014 | CN |
| 105075143 | Nov 2015 | CN |
| 109314545 | Feb 2019 | CN |
| 109644021 | Apr 2019 | CN |
| 20320080 | Apr 2004 | DE |
| 0 895 203 | Feb 1999 | EP |
| 1260947 | Nov 2002 | EP |
| 1 874 014 | Jan 2008 | EP |
| 2736178 | May 2014 | EP |
| 2 812 744 | Feb 2002 | FR |
| 2 812 745 | Feb 2002 | FR |
| 2 834 156 | Jun 2003 | FR |
| H09231285 | Sep 1997 | JP |
| 2000-030146 | Jan 2000 | JP |
| 2000-276539 | Oct 2000 | JP |
| 2001-222595 | Aug 2001 | JP |
| 2002-074507 | Mar 2002 | JP |
| 2002-123771 | Apr 2002 | JP |
| 2002-279320 | Sep 2002 | JP |
| 2002-352166 | Dec 2002 | JP |
| 2002-358285 | Dec 2002 | JP |
| 2003-108777 | Apr 2003 | JP |
| 2003-281453 | Oct 2003 | JP |
| 2003-308438 | Oct 2003 | JP |
| 2004-054651 | Feb 2004 | JP |
| 2004-062733 | Feb 2004 | JP |
| 2004-078553 | Mar 2004 | JP |
| 2004-078662 | Mar 2004 | JP |
| 2004-199405 | Jul 2004 | JP |
| 4248820 | Apr 2009 | JP |
| 10-1999-0066397 | Aug 1999 | KR |
| 10-1999-0068618 | Sep 1999 | KR |
| 200225019 | Mar 2001 | KR |
| 10-2003-0005936 | Jan 2003 | KR |
| 10-2003-0005984 | Jan 2003 | KR |
| 10-2003-0012910 | Feb 2003 | KR |
| 200333809 | Nov 2003 | KR |
| 10-2004-0016548 | Feb 2004 | KR |
| 100447431 | Aug 2004 | KR |
| 200405877 | Jan 2006 | KR |
| 100649151 | Nov 2006 | KR |
| 10-2007-0107990 | Nov 2007 | KR |
| 100842484 | Jun 2008 | KR |
| 2284578 | Sep 2006 | RU |
| 201105089 | Feb 2011 | TW |
| 1998012674 | Mar 1998 | WO |
| 2000011624 | Mar 2000 | WO |
| 2000025277 | May 2000 | WO |
| 2001086599 | Nov 2001 | WO |
| 2002033669 | Apr 2002 | WO |
| 2002043020 | May 2002 | WO |
| 2002082388 | Oct 2002 | WO |
| 2002084548 | Oct 2002 | WO |
| 2003044710 | May 2003 | WO |
| 2003079259 | Sep 2003 | WO |
| 2004023366 | Mar 2004 | WO |
| 2006131708 | Dec 2006 | WO |
| 2017214349 | Dec 2017 | WO |
| 2018005468 | Jan 2018 | WO |
| 2019005386 | Jan 2019 | WO |
| Entry |
|---|
| Manuel Mendonca et al.; Secure Application Updates on Point of Sale Devices; ICETE; 8 pages; retrieved on May 1, 2023 (Year: 2004). |
| English Language Translation of Second Office Action received for Chinese Patent Application No. 201780035862, dated May 13, 2021. |
| Martha E. Haykin et al., “Smart Card Technology: New Methods for Computer Access Control,” NIST Special Publication 500-157, Sep. 1988. |
| “MSP430x1xx Family User's Guide,” (including 2016 correction sheet at 2), Texas Instruments Inc., 2006. |
| Negron, J., “[Technical Blueprint] Windows 10 Co-Management with SCCM & Workspace ONE,” VMware End-User Computing Blog, dated Apr. 16, 2018, Retrieved from the Internet URL: http://aponewsletter.blogspot.com/2018/04/technical-blueprint-windows-10-co.html, pp. 1-9. |
| Spegele, Joseph Brain., “A Framework for Evaluating Application of Smart Cards and Related Technology Within the Department of Defense,” Naval Postgraduate School, Jan. 1995. |
| Stephen A. Sherman et al., “Secure Network Access Using Multiple Applications of AT&T's Smart Card,” AT&T Technical Journal, Sep./Oct. 1994. |
| “Software Update Server,” Technology Brief, Retrieved from the Internet URL: https://www.apple.com/server/docs/Software_Update_Server_TB_v10.4.pdf, pp. 1-3 (Jun. 16, 2005). |
| Huth C. et al., “Secure Software Update and IP Protection for Untrusted Devices in the Internet of Things Via Physically Unclonable Functions”, The First IEEE International Workshop on Security, (2016), pp. 1-6. |
| Gupta H. et al., “Onboarding and Software Update Architecture for IoT Devices”, IEEE, (2019), pp. 1-11. |
| Non-Final Office Action dated Mar. 29, 2018, for U.S. Appl. No. 15/248,071, of Uppunda, K.K.K., et al., filed Aug. 26, 2016. |
| Non-Final Office Action dated Apr. 19, 2018, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Non-Final Office Action dated Jul. 25, 2018, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Final Office Action dated Oct. 25, 2018, for U.S. Appl. No. 15/176,589, of of Bidari, E., et al., filed Jun. 8, 2016. |
| Final Office Action dated Nov. 5, 2018, for U.S. Appl. No. 15/248,071, of Uppunda, K.K.K., et al., filed Aug. 26, 2016. |
| Final Office Action dated Jan. 4, 2019, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Final Office Action dated Sep. 2, 2020, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Advisory Action dated Jan. 7, 2019, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Notice of Allowance dated Jan. 18, 2019, for U.S. Appl. No. 15/197,720, of Binder, J., et al., filed Jun. 29, 2016. |
| Non-Final Office Action dated Mar. 14, 2019 for U.S. Appl. No. 15/636,356, of Kelley, J. filed Jun. 28, 2017. |
| Non-Final Office Action dated Mar. 25, 2019, for U.S. Appl. No. 15/248,071, of Uppunda, K.K.K., et al., filed Aug. 26, 2016. |
| Non-Final Office Action dated Apr. 19, 2019, for U.S. Appl. No. 15/428,071, of Guise M., et al., filed Feb. 8, 2017. |
| Non-Final Office Action dated Jun. 24, 2019, for U.S. Appl. No. 16/397,836, of Binder, J., et al., filed Apr. 29, 2019. |
| Non-Final Office Action dated Jun. 25, 2019, for U.S. Appl. No. 15/721,663, of Gallinghouse, D., et al., filed Sep. 29, 2017. |
| Non-Final Office Action dated Jun. 28, 2019, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Non-Final Office Action dated Jul. 15, 2019, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Notice of Allowance dated Oct. 22, 2019, for U.S. Appl. No. 15/428,071, of Guise M., et al., filed Feb. 8, 2017. |
| Notice of Allowance dated Oct. 10, 2019, for U.S. Appl. No. 16/397,836, of Binder, J., et al., filed Apr. 29, 2019. |
| Notice of Allowance dated Nov. 6, 2019, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Notice of Allowance dated Dec. 23, 2019, for U.S. Appl. No. 15/721,663, of Gallinghouse, D., et al., filed Sep. 29, 2017. |
| Final Office Action dated Jan. 3, 2020, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Advisory Action dated Mar. 16, 2020, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Non-Final Office Action dated Mar. 16, 2020, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Non-Final Office Action dated May 8, 2020, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Examination Report for European Patent Application No. 17739748.6, dated Jan. 16, 2020. |
| Intention to Grant received for European Patent Application No. 17737959.1, dated Jul. 4, 2019. |
| Intention to Grant received for European Patent Application No. 17737959.1, dated Nov. 6, 2019. |
| Decision to Grant received for European Patent Application No. 17737959.1, dated Nov. 21, 2019. |
| Office Action received for European Patent Application No. 17739748.6, dated Jul. 7, 2020. |
| Notice of Allowance dated Jul. 31, 2020, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Corrected Noticeof Allowability dated Aug. 28, 2020, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Notice of Allowance dated Oct. 20, 2020, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Notice of Allowance dated Nov. 16, 2020, for U.S. Appl. No. 15/636,356, of Kelley, J., et al., filed Jun. 28, 2017. |
| Corrected Notice of Allowability dated Dec. 2, 2020, for U.S. Appl. No. 15/176,589, of Bidari, E., et al., filed Jun. 8, 2016. |
| Office Action received for Chinese Patent Application No. 201780035862, dated Dec. 2, 2020. |
| Office Action received for Chinese Patent Application No. 201780040833.2, dated Dec. 22, 2020. |
| International Search Report and Written Opinion for International Application No. PCT/US2016/050036, dated Nov. 29, 2016. |
| International Search Report and Written Opinion for International Application No. PCT/US2017/039466, dated Oct. 5, 2017. |
| International Search Report and Written Opinion for International Application No. PCT/US2017/036473, dated Oct. 13, 2017. |
| International Search Report and Written Opinion for International Application No. PCT/US2018/034773, dated Aug. 10, 2018. |
| Brinkmann, M., “Windows 10 Update Delivery Optimization explained,” Windows, dated Aug. 17, 2016, Retrieved from the Internet URL: https://web.archive.org/web/20161110094241/https://www.ghacks.net/2016/08/17/windows-10-update-delivery-optimization/, pp. 1-6. |
| “Connection of Terminal Equipment to the Telephone Network,” FCC 47 CFR Part 68, Retrieved from the URL: http://www.tscm.com/FCC47CFRpart68.pdf, on Sep. 24, 2019 Oct. 1, 1999 Edition. |
| “EMBEDDED FINancial transactional IC card READer,” Retrieved from the URL: https://cordis.europa.eu/project/rcn/58338/factsheet/en. |
| “FLEX-M24LR04E 45 mm×75 mm flexible antenna reference board for the M24LR04E-R Dual Interface EEPROM,” ST Microelectronics, published Jul. 2, 2012, Retrieved from the Internet URL : http://www.st.com/content/ccc/resource/technical/document/data_brief/2d/55/62/05/58/fd/42/e2/DM00058583.pdf/files/DM00058583.pdf/jcr:content/translations/en.DM00058583.pdf, on Sep. 26, 2017, pp. 1-3. |
| Geethapriya Venkataramani and Srividya Gopalan., “Mobile phone based RFID architecture for secure electronic payments using RFID credit cards,” 2007 IEEE, (ARES'07). |
| “Guideline for the Use of Advanced Authentication Technology,” FIPS 190, Sep. 28, 1994. |
| “Identification cards—Recording technique—Part 4—Location of read-only magnetic tracks—Track 1 and 2,” ISO/IEC 7811-4:1995, International Organization for Standardization, Aug. 1995. |
| Jerome Svigals., “The Long Life and Imminent Death of the Mag-stripe Card,” IEEE Spectrum, vol. 49, Issue 61, Jun. 2012. |
| “Magensa's Decryption Services and MagTek's MagneSafe™ Bluetooth Readers Selected by eProcessing Network to Implement Secure Customer Card Data with Mobile Devices,” Retrieved from the URL: https://www.magnensa.net/aboutus/articles/eProcessing—rev1.pdf Apr. 14, 2008. |
| Office Action received for European Patent Application No. 17739748.6, dated May 10, 2021. |
| Notice to Grant received for Chinese Patent Application No. 201780040833.2, dated May 20, 2021. |
| Number | Date | Country | |
|---|---|---|---|
| 20210255848 A1 | Aug 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15636356 | Jun 2017 | US |
| Child | 17201367 | US |
