Server-to-device secure data exchange transactions

This application is a continuation of U.S. Non-Provisional patent application Ser. No. 17/676,328 entitled “Dynamic Account Status Indicator Via Server-To-Device Secure Data Exchange,” filed Feb. 21, 2022, which claims the benefit of and priority to U.S. Provisional Patent App. No. 63/181,861 entitled “Dynamic Account Status Indicator Via Server-To-Device Secure Data Exchange,” filed Apr. 29, 2021, and also claims the benefit of and priority to U.S. Provisional Patent App. No. 63/152,581 entitled “Server-To-Device Secure Data Exchange,” filed Feb. 23, 2021, each of which is incorporated herein by reference in its entirety.

The present disclosure relates generally to server-to-device secure data exchange. More specifically, aspects of the present disclosure relate to methods, systems and computer-readable media embodying computer-executable instructions for provisioning of dynamic account status indicators via server-to-device secure data exchange. In some arrangements, the dynamic account status indicators may be related to financial accounts.

Individuals use smart computing devices (e.g., smart phones, laptops, etc.) to access bank account information and perform banking activities. Individuals may also use applications provided by entities different from the bank to perform financial analytics, apply for loans, initiate automated fee disputes, etc. Such applications typically require authorization to access user data at a financial institution. Authorization typically includes a user name and password (or other credentials) provided by the user. The credentials are typically stored by the applications, which may compromise account security.

Various embodiments described herein relate to systems, methods, and/or non-transitory computer-readable media structured to perform server-to-device secure data exchange using a device access token. In an embodiment, a smart device receives, from a requestor entity provided to the smart device, an account data provisioning request for an account. Based on the account data provisioning request, an account identifier for the account is determined. In some arrangements, the account identifier comprises or is associated with a device access token. Based on the device access token, a data element associated with the account is determined. In some embodiments, the data element is accessible to the requestor entity only if it is not access-restricted based on the device access token. Based on the data element, an executable graphic rendering instruction is generated. The executable graphic rendering instruction is executed, which includes generating and displaying, on a user interface of the smart device, a dynamic account status indicator relating to the account.

These and other features, together with the organization and manner of operation thereof, will become apparent from the following detailed description and the accompanying drawings.

Various embodiments described herein relate to systems, methods, and non-transitory computer-readable media structured to perform server-to-device secure data exchange using a device access token. As will be appreciated, the present disclosure provides various technical improvements and/or solves specific technical problems. For example, one of skill will recognize a technical problem of having multiple, different authentication protocols to a service provider computing system for each of the various applications provided to a smart device. Multiple authentication protocols expose both the applications and the provider computing system to security vulnerabilities, including code injection, user impersonation, interception of data in transit, interception of data at rest, etc. The present disclosure relates to one authentication protocol implemented by a component of a smart device for multiple (potentially unrelated) applications provided thereto. Furthermore, data can be provisioned to a particular smart device without being routed via computing entities that maintain the smart device and/or third-party computing applications installed on the smart device.

As another example, one of skill will recognize a technical problem of allowing various applications to communicate without user intervention. The present disclosure enables a smart device to engage in secure data exchange directly with a service provider computing system by automatically managing secure authenticated sessions and provisioning data via the use of tokens, APIs, and/or SDKs.

As another example, one of skill will recognize a technical problem of minimizing processing overhead and network bandwidth consumption associated with authenticated session creation and management. For example, applications that are required to provide login credentials every time they make a data request generate additional network traffic. The present disclosure enables on-demand data provisioning without requiring separate authentication each time a particular application requests data from a service provider computing system.

Referring to, depicted is a block diagram of an example computer-implemented systemstructured to perform server-to-device secure data exchange, according to some arrangements. In operation, the computer-implemented systemis structured to facilitate various secure data exchange operations (also referred to herein as “transactions”), such as data receipt, transmission, query, storage, analytics, etc.

As shown, the computer-implemented systemincludes a service provider computing system, a smart device provider computing system, a smart device, and a third-party computing system. These systems are communicatively coupled to one another via the network, which enables the systems to electronically exchange data.

As a general overview, the service provider computing systemis structured to facilitate financial services provided by a financial institution to a user of the smart device. For example, the service provider computing systemcan be managed and/or operated by a bank, credit union, insurance company, and the like. The user of the smart devicemay have various financial accounts at the financial institution, such as a checking account, a savings account, a money market account, a mortgage or another loan account, a credit card account, etc.

The smart devicemay include any suitable electronic device, such as a smart phone, a tablet, a laptop, a desktop, a smart TV, a virtual assistant (e.g., a virtual assistant embodied as a smart speaker), an immersive reality device (e.g., a headset), a smart watch, etc. The smart devicemay be communicatively coupled to a smart device provider computing system. The smart device provider computing systemmay be managed or operated by a manufacturer, vendor, and/or service provider that manufactures, distributes and/or services the smart device(e.g., Apple©, Google©, Samsung©, etc.). The smart device provider computing systemmay be structured to provide software, drivers, security services, and/or other device management items to the smart devicein order to maintain the operation and functionality of the smart device. In some arrangements, the smart device provider computing systemincludes an app store, and a user may cause the smart deviceto download applications therefrom. The applications may include third-party applications provided by the third-party computing system(e.g., QuickBooks®, Yodlee®, etc.), as described further herein. As used herein, the term “third-party” refers to an entity that is separate and independent from the entity that operates the service provider computing systemand/or the smart device provider computing system.

In operation, the user of the smart devicemay utilize the smart deviceto access various services provided by the financial institution via the service provider computing system, as described further herein. Further, the user of the smart devicemay allow third-party applications associated with the third-party computing systemto access, via a control circuit provided to the smart device, the user's account at the financial institution in order to retrieve historical data for analysis and/or aggregation and/or to perform other functions.

As shown, the service provider computing systemincludes circuitry to support server-to-device secure data exchange operations, such as token management, authenticated session management, and/or secure server-to-device data transfer. The service provider computing systemis shown to include various special purpose circuits, such as server token manager circuit, server authentication manager circuit, and server data manager circuit. These circuits may retrievably store items, such as data, code, executable files, markup files, configuration files, tokens, and the like in a server secure vault.

The special purpose circuits (e.g., the server token manager circuit, server authentication manager circuit, and/or server data manager circuit) may include at least one processorand memory. The processormay be implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. The memorymay include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memorymay include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memorymay include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memorymay be communicatively coupled to the processorand include computer code or instructions for executing one or more processes described herein.

The server token manager circuitis structured to execute computer-based operations for managing device access tokens in a server-to-device secure data exchange ecosystem. The computer-based operations may include device enrollment management, application enrollment management, token lifecycle management, token expiration, token validation, and the like.

As used herein, a “device access token” is structured to uniquely identify a particular smart deviceto the service provider computing system, which enables an enrolled smart deviceto securely send and receive data in a server-to-device secure data exchange ecosystem. A device access token may include a device identifier, a financial account identifier, a user identifier for the smart device provider computing system, an application identifier, a timestamp, and/or other elements sufficient to authenticate a device and/or an application. One or more elements of each of the device identifier, financial account identifier, user identifier, and/or application identifier may be included. A device identifier may include a model number, a serial number, a Wi-fi address (e.g., MAC address, Bluetooth device address), an international mobile equipment identifier (IMEI), a mobile equipment identifier (MEID), an integrated circuit card identifier (e.g., subscriber identification module (SIM) card identifier), etc. A financial account identifier may include a hash of a financial account number or an otherwise obscured financial account number in whole or in part. A user identifier may include, for example, a social networking handle, an e-mail address, a phone number, a user's user name for the service provider computing system, a user's user name for the smart device provider computing system, and/or a user's user name for the third-party computing system. An application identifier may include, in whole or in part, an application name, an application instance identifier, an installation and/or last update timestamp for a particular application instance, etc. In some arrangements, these items may be converted to a string and concatenated to form a device access token. In some arrangements, the device access token is a mark-up language file (e.g., an XML file) where each particular data element is identified by a unique tag. In some arrangements, the device access token is a quick response (QR) code or another machine-readable optical label displayable via a display screen of the smart device(e.g., for troubleshooting, for sharing with secondary smart device(s), etc.).

The server authentication manager circuitis structured to execute computer-based operations for authenticating smart devicesin a server-to-device secure data exchange ecosystem. The server authentication manager circuitmay receive, from a particular smart device, an electronic message that includes a request for data access and a device access token. The server authentication manager circuitmay parse one or more device identifiers from the device access token. The server authentication manager circuitmay cross-reference the one or more device identifiers to the device identifier(s) previously stored in the server secure vaultin order to determine whether a particular device has been previously enrolled. The server authentication manager circuitmay compare various parsed items from the device access token to verify that a particular enrolled smart deviceis not being spoofed (e.g., impersonated) by an unauthorized device. For example, the server authentication manager circuitmay parse a SIM card identifier and a MAC address or a Bluetooth device address from a device access token and determine that a device is unauthorized if a known SIM card identifier is accompanied by a new MAC address or a Bluetooth device address, likely indicative of the SIM card having been removed from a previously authorized smart deviceand installed on a different device. In another example, the server authentication manager circuitmay parse, from the device access token or from Internet traffic information associated with the request (e.g., from a header, footer, payload, or metadata properties of the packets of data received at the service provider computing systemin connection with the request for data), the source network identifier and compare the identifier to a list of previously stored known access networks for a particular smart device. The network identifier can include an IP address, a subnet, a service set identifier (SSID) for a wireless network, or another suitable identifier. In yet another example, the service provider computing systemmay receive a geographical location identifier (e.g., a set of coordinates) from the smart deviceand may compare the geographical location identifier to a set of previously known locations for the smart device.

As part of authenticating a particular smart device, the server authentication manager circuitmay also receive (e.g., as part of a device access token, as a separate element in an electronic message, or in a separate electronic message) an application identifier for an application provided to the smart device. As used herein, the term “provided to” refers to an application that includes functionality accessible to a user via the smart device. In some arrangements, the application is installed on the smart device. In some arrangements, the application is executing on the smart device(e.g., via a browser). In some arrangements, the application is accessible at the smart devicevia an emulator or a similar application delivery framework (e.g., Citrix®, Azure®, etc.), and is installed on and/or executing on a remote computing system relative to the smart device. A particular application may have an associated set of access permissions and/or restrictions that allow the application to perform certain specific functions and/or access specific data provided by the service provider computing system. The server authentication manager circuitmay cross-reference the application identifier to the application identifier(s) and the corresponding restriction(s) previously stored in the server secure vaultin order to determine whether a particular application provided to the smart devicehas been previously enrolled and before retrieving and transmitting the requested data back to the smart devicefor use by the application.

As part of authenticating a particular smart device, the server authentication manager circuitmay perform lifecycle-related checks on the received device access token. For instance, the server authentication manager circuitmay access a timestamp (e.g., a token creation time, a token expiration time, a token last used time) previously stored in the server secure vaultto determine if the received device access token is valid and/or if the user of the smart deviceneeds to complete an additional authentication process. For example, if a predetermined amount of time (e.g., one day, seven days, thirty days, never before used, etc.) has passed since a particular device access token was last used, the server authentication manager circuit may generate and cause the smart deviceto provide to the user (e.g., in a display form, in an audible form) a prompt requesting the user's login credentials, biometric information, and/or authorization to proceed.

As part of authenticating a particular smart device, the server authentication manager circuitmay work in concert with the smart deviceto manage secure authorized sessions. A secure authorized session may establish time boundaries for processing a particular data request from an authenticated device. For example, the server authentication manager circuitmay receive, together or separately from the device access token, a session identifier for a secure authorized session established by the smart devicefor the purpose of data transmission. If the server authentication manager circuitis unable to validate the device access token and/or application, the server authentication manager circuitmay transmit an electronic message to the smart device. The electronic message may include the session identifier and instructions to the smart deviceto terminate the secure authorized session. The authentication manager circuitmay also be structured to receive electronic messages from the smart deviceindicating that a particular secure authenticated session has been terminated, in which case the requested data will not be transmitted to the smart device.

The server data manager circuitis structured to execute computer-based operations for data provisioning to smart devicesin a server-to-device secure data exchange ecosystem. After a device access token is verified and as long as a secure authenticated session between the service provider computing systemand the smart deviceis active, the server data manager circuitmay be structured to retrieve and/or provide the data requested by a particular smart device. The server data manager circuitmay also execute the requested functionality, such as initiate a dispute, request a fee waiver, disable a particular card, etc. Based on the application identifier, the service provider computing systemmay also access and apply application-specific restrictions in the server secure vault, as discussed further herein.

To carry out its operations, server data manager circuitmay be structured to determine a financial account identifier of the user. In some arrangements, the server data manager circuitmay parse the financial account identifier from the data request message received from the smart device. In some arrangements, the server data manager circuitmay parse the financial account identifier from the device access token received from the smart device. To improve security of user data, the financial account identifier may be encoded for provisioning and storage by the smart deviceby, for example, generating a hash of a financial account number or otherwise obscuring the financial account identifier in whole or in part. The server data manager circuitmay apply a decoding algorithm and/or cross-reference the received encoded financial account identifier to a list previously stored in the server secure vaultin order to determine the actual account identifier. In some arrangements, the server data manager circuitmay receive a user identifier for the smart device provider computing system(e.g., Apple© ID, Google® user name, Samsung® ID, etc.) and determine the actual account identifier(s) for the user's financial account(s) based on the user identifier for the smart device provider computing system.

The service provider computing systemis communicatively coupled to the smart device provider computing system, smart device, and third-party computing systemvia network. To communicate via the network, the service provider computing systemincludes a network circuit. The network circuitmay be used to establish connections with other computing devices by way of the network. The network circuitmay include program logic that facilitates connection of the service provider computing systemto the network. In some arrangements, the network circuitmay include any combination of a wireless network transceiver (e.g., a cellular modem, a Bluetooth transceiver, a Wi-Fi transceiver) and/or a wired network transceiver (e.g., an Ethernet transceiver). For example, the network circuitmay include an Ethernet device such as an Ethernet card and machine-readable media such as an Ethernet driver configured to facilitate connections with the network. In some arrangements, the network circuitincludes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network circuitincludes cryptography capabilities to establish a secure or relatively secure communication session in which data communicated over the session is encrypted.

Although not shown in, it is understood that device provider computing system, smart device, and/or third-party computing systemmay include network interfaces for long-, medium- or short-range communication substantially similar to the network circuitas described above.

The networkmay include a local area network (LAN), a wide area network (WAN), a telephone network, such as the Public Switched Telephone Network (PSTN), a wireless link, an intranet, the Internet, or combinations thereof. The networkcan enable communication between various nodes. In some arrangements, data flows through the networkfrom a source node to a destination node as a flow of data packets, e.g., in the form of data packets in accordance with the Open Systems Interconnection (OSI) layers. A flow of packets may use, for example, an OSI layer-4 transport protocol such as the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP), or the Stream Control Transmission Protocol (SCTP), transmitted via the networklayered over an OSI layer-3 network protocol such as Internet Protocol (IP), e.g., IPv4 or IPv6. The networkis composed of various network devices (nodes) communicatively linked to form one or more data communication paths between participating devices. Each networked device includes at least one network interface for receiving and/or transmitting data, typically as one or more data packets. An illustrative networkis the Internet; however, other networks may be used. The networkmay be an autonomous system (AS), i.e., a network that is operated under a consistent unified routing policy (or at least appears to from outside the AS network) and is generally managed by a single administrative entity (e.g., a system operator, administrator, or administrative group).

The networkmay be composed of multiple connected sub-networks or AS networks, which may meet at one or more of: an intervening network (a transit network), a dual-homed gateway node, a point of presence (POP), an Internet eXchange Point (IXP), and/or additional other network boundaries. The networkcan be a local-area network (LAN) such as a company intranet, a metropolitan area network (MAN), a wide area network (WAN), an inter network such as the Internet, or a peer-to-peer network, e.g., an ad hoc Wi-Fi peer-to-peer network. The data links between nodes in the networkmay be any combination of physical links (e.g., fiber optic, mesh, coaxial, twisted-pair such as Cat-5 or Cat-6, etc.) and/or wireless links (e.g., radio, satellite, microwave, etc.).

The networkcan include carrier networks for mobile communication devices, e.g., networks implementing wireless communication protocols such as the Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Time Division Synchronous Code Division Multiple Access (TD-SCDMA), Long-Term Evolution (LTE), or any other such protocol including so-called generation 3G, 4G, 5G, and 6G protocols. The networkcan include short-range wireless links, e.g., via Wi-Fi, BLUETOOTH, BLE, or ZIGBEE, sometimes referred to as a personal area network (PAN) or mesh network. The networkmay be public, private, or a combination of public and private networks. The networkmay be any type and/or form of data network and/or communication network.

The networkcan include a network interface controller that can manage data exchanges with devices in the networkvia a network interface (sometimes referred to as a network interface port). The network interface controller handles the physical and data link layers of the Open Systems Interconnection (OSI) model for network communication. In some arrangements, some of the network interface controller's tasks are handled by one or more processing circuits. In various arrangements, the network interface controller is incorporated into the one or more processing circuits, e.g., as circuitry on the same chip.

In some arrangements, the network interface controller supports wireless network connections and an interface is a wireless (e.g., radio) receiver/transmitter (e.g., for any of the IEEE 802.11 Wi-Fi protocols, near field communication (NFC), BLUETOOTH, BLUETOOTH LOW ENERGY (BLE), ZIGBEE, ANT, or any other wireless protocol). In various arrangements, the network interface controller implements one or more network protocols such as Ethernet.

Referring now to, depicted is a block diagramof an example smart devicestructured to facilitate server-to-device secure data exchange, according to some arrangements. In operation, the smart deviceis structured to facilitate various secure data exchange operations, such as data receipt, transmission, query, storage, analytics, etc.

As shown in a simplified view, the smart deviceincludes hardware, operating system, and applications. The operating systemis shown to include a kernel, a core services circuit, and a control circuit. The control circuitcan be a special purpose circuit structured to facilitate server-to-device secure data exchange between the smart deviceand/or a secondary smart deviceand the service provider computing systemof. It is understood that the control circuitmay be implemented, in whole or in part, as part of the operating systemand/or as one or more of the applications. Further, the control circuitmay be structured to include various hardwarecomponents described further herein.

As shown, hardwareincludes a processor, memory, a secure element, an input/output (I/O) circuit, a communications circuit, and a sensor. The processormay be implemented as a general-purpose processor, an application specific integrated circuit (ASIC), one or more field programmable gate arrays (FPGAs), a digital signal processor (DSP), a group of processing components, or other suitable electronic processing components. The memorymay include one or more devices (e.g., RAM, ROM, Flash memory, hard disk storage) for storing data and/or computer code for completing and/or facilitating the various processes described herein. The memorymay include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memorymay include database components, object code components, script components, or any other type of information structure for supporting the various activities and information structures described herein. The memorymay be communicatively coupled to the processorand include computer code or instructions for executing one or more processes described herein.

In some arrangements, the memoryis included in, at least in part, or is communicatively coupled to the secure element. The secure elementcan be a removable or built-in hardware and/or software circuit structured to securely store data and/or securely host applicationson the smart device. Further, in some arrangements, the secure elementmay store executables for invocation by the various circuitry included in the core services circuit, control circuit, and/or applications. Further, in some arrangements, the secure elementmay include a dedicated or shared memory space for execution of these various processes (e.g., by the kerneland/or by the control circuit). The secure element can be implemented as an embedded computer chip, a removable SIM card, a system-on-a-chip (SoC), or similar. In some arrangements, the secure elementincludes a co-processor additional to the processor. In some arrangements, the secure elementincludes or is communicatively coupled to a near-field communications (NFC) controller, such as the communications circuit. More generally, the communications circuitmay include a transceiver suitable for short-, medium- or long-range communication, such as a wireless network transceiver (e.g., a cellular modem, a Bluetooth transceiver, a Wi-Fi transceiver, an NFC transceiver, etc.).

The I/O circuitincludes suitable input/output ports and/or uses an interconnect bus for interconnection with a local display (e.g., a liquid crystal display, a touchscreen display) and/or keyboard/mouse devices (when applicable), or the like, serving as a local user interface for programming and/or data entry, retrieval, or other user interaction purposes. As such, the I/O circuitmay provide an interface for the user to interact with various applications. For example, the I/O circuitmay include a keyboard, a keypad, a mouse, joystick, a touch screen, a microphone, a biometric device (e.g., a fingerprint sensor), a virtual reality headset, smart glasses, and the like. As another example, the I/O circuitmay include, but is not limited to, a television monitor, a computer monitor, a speaker, and so on. In some arrangements, the I/O circuitincludes a camera suitable for taking photographic images and/or scanning QR codes using the smart device.

The sensormay include circuitry and/or a transceiver suitable for collecting and/or outputting various data. For example, the sensormay be a global positioning system (GPS) transceiver configured to detect a geographical location (e.g., latitude and longitude) of smart devicein real or near-real time by using triangulation based on the coordinates of one or more cellular towers received by the smart devicevia the communications circuit.

As shown, the operating systemincludes a kernel, a core services circuit, and a control circuit. The kernelis structured to work in conjunction with the core services circuit. Accordingly, the kernelcan include a dedicated space in the memoryfor executing various processes managed by the core services circuit. These processes can include, for example, process management, file management, networking, user interface management, driver management for connected devices, and the like. The executables for these and similar services may be stored in the memoryand invoked, monitored, and terminated by the core services circuit. In some arrangements, the kerneland/or the core cervices circuitmay include kernel extension executables for the control circuit(i.e. the control circuitmay be included in the kerneland/or the core cervices circuitat least in part.)

The control circuitis a special purpose circuit structured to facilitate server-to-device secure data exchange operations. In some arrangements, the control circuitmay receive requests and/or provide data to the applications. As shown, the applicationscan include a service provider application, a device-native application, and a third-party application. The service provider applicationmay be, for example, a mobile banking application structured to exchange data with the service provider computing system. The service provider applicationmay include various functionality, such as account lookup, balance lookup, transaction history lookup, etc. for a financial account of a user. Accordingly, the information related to the financial account of the user may be accessible via the smart device. The device-native applicationmay be developed and/or provided to the smart deviceby an operator of the smart device provider computing system, and may include an Internet browser, a camera control application, a telephone control application, an app store application, a control application for the secondary smart device, and the like. The third-party applicationmay be developed and/or provided by an operator of the third-party computing system. The third-party application may be independently downloaded by a user of the smart deviceor may be provided via an app store application managed by the smart device provider computing system(e.g., the device-native application). The third-party applicationmay be configured to access the user's account at the financial institution in order to retrieve historical data for analysis and/or aggregation and/or to perform other functions (e.g., automated fee disputes, underwriting, etc.).

Any of the applicationsmay be configured, via the control circuit, to access the user's financial data at the financial institution associated with the service provider computing system. As such, the technical problem of enhancing data security is solved by device-based authentication such that the control circuitcan bypass the smart device provider computing systemin providing data from the smart deviceto applicationsnot managed by the financial institution (e.g., in providing data to the device-native applicationand/or the third-party application) and/or to the secondary smart device. Furthermore, the server-to-device secure data exchange infrastructure managed by the control circuitin concert with the service provider computing systemallows for minimization or significant reduction of the amount of private data (e.g., personally identifiable information (PII)) stored on the smart device. Furthermore, tokenization of confidential account information prevents the applicationsfrom locally accessing and/or storing account identifiers of a user. As described further herein, account restrictions may further define the type of data, functionality, and/or data uses allowable for each application.

As shown, the control circuitincludes a device token manager circuit, a device authentication manager circuit, an authorized session manager circuit, a device data manager circuit, and a device secure vault. In operation, the control circuitworks in concert with the service provider computing systemto facilitate the enrollment of the smart device, secondary smart device, and/or particular applicationsin the server-to-device secure data exchange ecosystem. Further, the control circuitallows a user of the smart deviceto provide authorized account access settings for the applications. Further, the control circuitallows the applicationsand/or the secondary smart deviceto initiate transactions (e.g., data downloads, queries, funds transfer requests, etc.) from the smart device.

The device token manager circuitis structured to execute computer-based operations for managing device access tokens in a server-to-device secure data exchange ecosystem. The computer-based operations may include device enrollment management, application enrollment management, token lifecycle management, token expiration, token validation, and the like, as described relative to.

The device authentication manager circuitis structured to execute computer-based operations for authenticating smart devicesin a server-to-device secure data exchange ecosystem. The device authentication manager circuitmay receive, via a GUI rendered on the smart device, a smart device identifier.

In some arrangements, the smart deviceis the device associated with the smart device identifier, and the user or an applicationattempts to access and receive data at the smart device. In some arrangements, a first smart device(e.g., a mobile device, a tablet, a laptop, a desktop, etc.) is a full-functionality device that includes the functionality of the control circuitsufficient to perform the functions described herein. A secondary smart device(e.g., a virtual assistant, a smart watch, an immersive reality device) may be designated by a user as an authorized device for receiving at least some of the data provided via server-to-device secure data exchange. The secondary smart devicemay be associated with an application(e.g., a fob issued by a financial institution may be associated with the service provider application, a virtual assistant device may be associated with a device-native applicationthat controls the virtual assistant device, and/or an internet-of-things device, such as a smart home component, may be associated with a third-party application, etc.). In this case, the device authentication manager circuitmay receive, at the smart device, a secondary device identifier related to the secondary smart device, and, upon prompting a user to approve a proposed secure data exchange transaction, may retrieve a corresponding token stored in the device secure vaulton a secure element. In some arrangements, the requesting applicationis also identified, and the application identifier may be separately retrieved or may be included in a particular device access token.

After receiving a device identifier, the device authentication manager circuitmay generate and transmit the device access token and/or the application identifier to the server authentication manager circuitof the service provider computing device, which may retrieve and provide the requested data. According to various embodiments, the device authentication manager circuitand/or the server authentication manager circuitmay apply the relevant restrictions prior to providing the data to the requesting computing device and/or application.

As part of authenticating a particular smart deviceor secondary smart devicefor a particular data request, the authorized session manager circuitmay initiate and manage a secure authorized session (e.g., a secure time-limited communications session between the smart deviceand the service provider computing device). The authorized session manager circuitmay generate a session identifier for a secure authorized session established by the smart devicefor the purpose of data transmission between a requestor device (e.g., smart device) and/or requestor applicationand the service provider computing device. In some arrangements, the secure authorized session is established after validating the request at the smart device(e.g., after verifying that a device access token exists and is not expired, and that the applicable access restrictions are met). In some arrangements, only some or none of the foregoing operations are performed at the smart device, such that the server authentication manager circuitperforms further token validation, as described above, and causes the authorized session manager circuitto terminate the secure communications session if the appropriate server-side checks performed by the service provider computing systemhave failed.

As part of authenticating a particular smart deviceor secondary smart devicefor a particular data request, the authorized session manager circuitmay terminate a particular secure authorized session according to predetermined criteria. For example, a secure authorized session may be terminated at the smart deviceif no response is received from the service provider computing systemwithin a predetermined amount of time (e.g., 15 sec., 30 sec., etc.), if the size of an inbound data transmission exceeds a predetermined threshold (e.g., 5 MB, 10 MB, etc.), if a user device enters inactive or shutdown mode, if a code injection attempt is detected as described below, etc.

The device data manager circuitis structured to execute computer-based operations for data requests to the service provider computing systemfrom requestor application(s)at the smart device. The device data manager circuitmay provide (e.g., access, retrieve from memoryand/or secure element) an API and/or SDK comprising executables for invocation by requestor application(s). The executable(s) may be selectively tagged (e.g., in a configuration file implemented as a mark-up language file, such as XML, and stored in memoryand/or on secure element) with permission labels corresponding to restrictions. Accordingly, the device data manager circuitmay provide to the requestor application(s)only the allowable executables for permissible (non-restricted) function calls. In some arrangements, the application(s)include the appropriate parameters for the executables (e.g., “retrieve.exe” parametrized with an account identifier, amount(s), date range(s) for transactions to retrieve, etc.). In some arrangements, the device data manager circuitreceives the parameter arguments from the application(s)and constructs the parametrized function calls in order to prevent errors in execution and minimize the possibilities for code injection. If a valid command is not detected or cannot be constructed, the device data manager circuitmay cause the authorized session manager circuitto terminate the corresponding secure authenticated session.

The device data manager circuitis structured to execute computer-based operations for data provisioning to requestor application(s)at the smart device. The device data manager circuitmay receive the requested data from the service provider computing device, and may make the data available to the requestor application(s). In some arrangements, when a requestor applicationis an intermediary for processing data requests from the secondary smart device, the device data manager circuitmay transmit the requested data set directly to the secondary smart device, which may perform post-processing of the received data thereon and/or provide the results to the user.

Referring now to, depicted is a component diagram of an example graphical user interface (GUI)of the smart deviceof, the GUI structured to facilitate smart deviceenrollment in server-to-device secure data exchange, according to some arrangements. As shown, a user may provide login credentials (e.g., a user nameand a password) for the service provider computing systemvia a data input control (e.g., a text box) of the GUI and then actuate the log in control(e.g., a button). Upon receiving the login credentials, the service provider computing systemmay transmit an electronic message to the smart device, causing the smart deviceto generate and display an enroll smart device user interface. The enroll smart device user interfaceprovides a front-end to allow the user to interact with the control circuitof the smart device. For example, a list of smart devicesmay be generated and provided to the user. The list of smart devicesmay include smart devices associated with the user, either previously enrolled or known to be associated with the user (e.g., by determining the secondary smart deviceslocally paired to the smart devicevia Bluetooth or similar, by scanning a QR code provided by a particular secondary smart device, by receiving and decoding an NFC token from a particular secondary smart deviceat the smart device, etc.).

For each selected smart deviceor secondary smart devicein the list of smart devices, the user can use the select accounts controlto specify financial accounts to which the selected smart deviceor secondary smart deviceshould have access. Upon detecting a user interaction with a generate token control, the device token manager circuitof the smart devicemay generate a device access tokenfor the selected device and/or selected account. An example device access tokenmay include one or more device identifiers, financial account identifiers, and/or financial account type (checking, savings, credit card, etc.) identifiers, as shown. The device access token may be stored by the device token manager circuitin device secure vault, which may be stored in the memoryand/or secure elementof the smart device.