Abstract: Systems and techniques for monitoring, predicting and/or alerting for short-term oxygen support needs of patients are presented. A system can include a data collection component that receives multimodal patient data for a patient having a respiratory condition in association with monitoring and treating the respiratory condition in real-time, the multimodal patient data comprising at least physiological data regarding physiological parameters tracked for the patient over a period of time, and current oxygen support data regarding a current oxygen support mechanism of the patient.

Abstract: Alternative service access with operations including determining that a system has met a plurality of criteria, including the system having a battery level below a threshold, identifying a merchant, generating an authentication token for authorizing a payment using a payment provider, and sending the authentication token to the payment provider.

Abstract: A token issuance system receives a first purchase request for at least one of a good or a service from a merchant at a merchant location. The system generates a payment token based on the purchase request such that the payment token is associated with a proximity condition. The system then determines that a location of a user device that is associated with the purchase request satisfies the proximity condition. In response to the determining that the location of the user device that is associated with the purchase request satisfies the proximity condition, the system provides the payment token to the merchant.

Abstract: Systems and methods for active application of secondary transaction instrument tokens in transaction processing systems are provided. A transaction processing server receives a transaction request identifying a request to authorize a transaction using a first transaction instrument and a first token processing engine issues the transaction request with a first transactable token associated with the first transaction instrument for use by a first remote entity to authorize the first transaction instrument. The transaction processing server receives a transaction request failed message and actively routes a non-transactable token from the first token processing engine to a second token processing engine.

Abstract: Systems and methods for providing a payment system includes processing, by a first payment service provider device, a payment request received from a user device and associated with a first funding instrument. A payment request failed message associated with the payment request is received. A second funding instrument associated with a second payment service provider device is retrieved. First sub-payment request of the payment request associated with the second funding instrument is processed and a first sub-payment successful message associated with the first sub-payment request is obtained. The payment request is determined to be successful based on the first sub-payment successful message. A payment request successful message is provided to the user device indicating that the payment request was successful.

Abstract: There are provided systems and methods for shared cryptogram generation during multi-party digital token processing. A service provider, such as an electronic transaction processor for digital transactions, may require tokenized data in order to protect sensitive or secure data, such as payment card data during electronic transaction processing. In this regard, the service provider may tokenize the data, which may require a cryptogram for validation of a corresponding digital token. The cryptogram may be generated based on input from multiple participants to the transaction, where a length of the cryptogram may be determined based on a risk score for the transaction. Each transaction participant may be assigned one or more slots or values in the cryptogram to provide based on the risk score and other rules for cryptogram generation. Each participant may provide corresponding portions, where the service provider may generate and backwards update the participants of the cryptogram.

Abstract: A method includes receiving, by a payment provide server of a payment provider from a point-of-sale (POS) device associated with a first merchant at a merchant location, a checkout request for a first user to purchase one or more items sold by the first merchant. The method further includes accessing an account of the first user with the payment provider based on authentication information included in the checkout request and identifying a previously stored payment token that is associated with the account of the first user, the previously stored payment token indicating one or more additional items for potential purchase. Further, the method includes in response to the identifying, transmitting instructions to the POS device that cause the POS device to display a request for the first user to add at least one of the one or more additional items for potential purchase for checkout at the merchant location.

Abstract: Cached data is obtained from a device. The cached data includes data saved on the device in response to electronic searches or electronic messaging performed by a user using the device. A determination is made, at least in part via the cached data, regarding an intended use context associated with the electronic searches or the electronic messaging. Using the intended use context, a confidence level is determined. In response to the determined confidence level meeting or exceeding a predefined threshold, a transaction involving the user is automatically executed, or an electronic communication is automatically sent on behalf of the user.

Abstract: There are provided systems and methods for measuring tap pressure on mobile devices to automate actions. A computing device, such as a mobile smart phone, may include a touch screen interface that may accept touch inputs. A touch input may include a presence and location of the touch input on the touch screen interface. Additionally, the computing device may detect a pressure or force applied to the touch screen interface with the touch input. The computing device may include a payment application, where the touch input may be received during use of the payment application. The pressure of the touch input may further define the input for the payment application. For example, a touch input with a first pressure may cause a first process to be initiated, while a second pressure may cause a second process to be initiated.

Abstract: A mempool of a miner of a blockchain system is accessed. The mempool contains at least a first transaction and a second transaction. A determination is made that the first transaction and the second transaction are related to each other. In response to the determination, the first transaction and the second transaction are linked. The linking of the first and second transactions comprises aggregating data associated with the first transaction and the second transaction into an aggregated data set. The aggregated data set is written into a single block of the blockchain system.

Abstract: There are provided systems and methods for a network cache of device input for redundancy during device inoperability. A device may detect that the device is in danger of failure, for example, if a battery is low on the device, the device is damaged, or the device may lose network connectivity. On detection of such a condition, the device may request that a server that performs electronic transaction processing establish or trigger a mode that allows for caching of transaction data as input for the transaction data is entered to a device, which may be done by sending signaling to the server indicating the condition that affects the device's operability. The server may then cache input for the transaction data. If the device fails prior to approving and completing electronic transaction processing, the server may use the cached data to generate a digital ledger for another entity.

Abstract: There are provided systems and methods for parent level token issuance for asynchronous data processing based on device trust levels. Two devices may interact enough that they develop a trust rating between the two devices that the devices are trusted for transaction processing and resolution. In order to provide asynchronous transaction processing without requiring a token service provider or transaction processor, a parent level token may be issued to the devices by a token service provider based on the trust rating. The devices may receive child level tokens from the parent token, while the parent token is stored by the transaction processor. The child level tokens may allow the devices and transaction processor to trust the devices to process and resolve transaction processing without availing the token service provider for token issuance.

Abstract: A communication channel merging system detects that a first communication session that is provided via a first communication channel between a first user and a first service provider is concurrent with a second communication session that is provided via a second communication channel between the first user and a second service provider. The system then generates a user score based on information associated with the first and second communication sessions and determines that the user score satisfies a condition that causes the first and second communication sessions to be merged into a merged communication session. The system generates a first channel score for the first communication channel and a second channel score for the second communication channel and determines based on those channel scores that the first communication channel should provide the merged communication session. The system directs the merged communication session to be provided on the first communication channel.

Abstract: There are provided systems and methods for automated data tokenization through networked sensors. A network of data sensors may detect that a user is likely to engage in electronic transaction processing with a merchant device, for example, based on an action performed by the user and/or with a user device. One or more of the sensors may connect with the user's device and retrieve financial data from the device and/or data necessary to issue a token to the device for transaction processing. The sensor may perform a background process to issue the token to the device, and once onboarded, may store the token to the user's device and/or the merchant device that the user is likely to interact with for transaction processing. The token may be limited in use by location and/or amount, or may be used to fully onboard the user with the token service provider.

Abstract: Systems and methods for transaction management include receiving, from a user device associated with a user, a transaction request and receiving, through a network in a token form, user information associated with the user while the user is accessing transaction information from the user device. The user information comprises data associated with an action by user or a biometric of the user captured by the user device. Based on data associated with the transaction request, a delay in processing the transaction request due to a transaction rule is determined, and then based on the user information, a user interaction indicator associated with the transaction is determined. A transaction management action associated with the transaction is performed based on the user interaction indicator.

Abstract: There are provided systems and methods for a network cache of device input for redundancy during device inoperability. A device may detect that the device is in danger of failure, for example, if a battery is low on the device, the device is damaged, or the device may lose network connectivity. On detection of such a condition, the device may request that a server that performs electronic transaction processing establish or trigger a mode that allows for caching of transaction data as input for the transaction data is entered to a device, which may be done by sending signaling to the server indicating the condition that affects the device's operability. The server may then cache input for the transaction data. If the device fails prior to approving and completing electronic transaction processing, the server may use the cached data to generate a digital ledger for another entity.

Abstract: Systems and methods for active application of secondary transaction instrument tokens in transaction processing systems are provided. A transaction processing server receives a transaction request identifying a request to authorize a transaction using a first transaction instrument and a first token processing engine issues the transaction request with a first transactable token associated with the first transaction instrument for use by a first remote entity to authorize the first transaction instrument. The transaction processing server receives a transaction request failed message and actively routes a non-transactable token from the first token processing engine to a second token processing engine.

Abstract: Methods and systems are presented for facilitating sharing of tokens among different funding accounts linked to a digital wallet application to improve the computer resource efficiency of the mobile device. When a first funding account is linked to the digital wallet application is received, a token management system may determine whether a set of tokens have already been issued and stored on the mobile device for another related funding account. The token management system may cause a token service provider server to abort generating additional tokens for the first funding account. Instead, the token management system may modify characteristics of one or more of the set of tokens existed on the mobile device, to enable the one or more existing tokens to be usable in electronic payment transactions in association with the first funding account or the second funding account.

Abstract: There are provided systems and methods for parent level token issuance for asynchronous data processing based on device trust levels. Two devices may interact enough that they develop a trust rating between the two devices that the devices are trusted for transaction processing and resolution. In order to provide asynchronous transaction processing without requiring a token service provider or transaction processor, a parent level token may be issued to the devices by a token service provider based on the trust rating. The devices may receive child level tokens from the parent token, while the parent token is stored by the transaction processor. The child level tokens may allow the devices and transaction processor to trust the devices to process and resolve transaction processing without availing the token service provider for token issuance.

Abstract: Systems, computer-implemented methods, apparatus, and/or computer program products that facilitate implementation of child tokens for improved transaction data storage and/or implementation of reduced transaction information payloads for quicker computerized payment processing are provided. In various embodiments, a system can comprise a scanner component that can scan a financial instrument during a current transaction, thereby extracting financial instrument data associated with the current transaction. In various instances, the system can further comprise a logging component, that can identify in an electronic transaction log a first data entry that corresponds to a previous transaction. In various cases, the first data entry can list previous financial instrument data associated with the previous transaction, and the previous financial instrument data can match the current financial instrument data.