Dynamic account status indicator via server-to-device secure data exchange

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. 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.

TECHNICAL FIELD

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.

BACKGROUND

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.

SUMMARY

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.

DETAILED DESCRIPTION

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 toFIG.1, depicted is a block diagram of an example computer-implemented system100structured to perform server-to-device secure data exchange, according to some arrangements. In operation, the computer-implemented system100is 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 system100includes a service provider computing system102, a smart device provider computing system104, a smart device106, and a third-party computing system108. These systems are communicatively coupled to one another via the network113, which enables the systems to electronically exchange data.

As a general overview, the service provider computing system102is structured to facilitate financial services provided by a financial institution to a user of the smart device106. For example, the service provider computing system102can be managed and/or operated by a bank, credit union, insurance company, and the like. The user of the smart device106may 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 device106may 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 device106may be communicatively coupled to a smart device provider computing system104. The smart device provider computing system104may be managed or operated by a manufacturer, vendor, and/or service provider that manufactures, distributes and/or services the smart device106(e.g., Apple, Google, Samsung, etc.). The smart device provider computing system104may be structured to provide software, drivers, security services, and/or other device management items to the smart device106in order to maintain the operation and functionality of the smart device106. In some arrangements, the smart device provider computing system104includes an app store, and a user may cause the smart device106to download applications therefrom. The applications may include third-party applications provided by the third-party computing system108(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 system102and/or the smart device provider computing system104.

In operation, the user of the smart device106may utilize the smart device106to access various services provided by the financial institution via the service provider computing system102, as described further herein. Further, the user of the smart device106may allow third-party applications associated with the third-party computing system108to access, via a control circuit provided to the smart device106, 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 system102includes 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 system102is shown to include various special purpose circuits, such as server token manager circuit120, server authentication manager circuit122, and server data manager circuit124. These circuits may retrievably store items, such as data, code, executable files, markup files, configuration files, tokens, and the like in a server secure vault126.

The special purpose circuits (e.g., the server token manager circuit120, server authentication manager circuit122, and/or server data manager circuit124) may include at least one processor130and memory132. The processor130may 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 memory132may 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 memory132may include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory132may 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 memory132may be communicatively coupled to the processor130and include computer code or instructions for executing one or more processes described herein.

The server token manager circuit120is 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 device106to the service provider computing system102, which enables an enrolled smart device106to 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 system104, 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 system102, a user's user name for the smart device provider computing system104, and/or a user's user name for the third-party computing system108. 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 device106(e.g., for troubleshooting, for sharing with secondary smart device(s)106, etc.).

The server authentication manager circuit122is structured to execute computer-based operations for authenticating smart devices106in a server-to-device secure data exchange ecosystem. The server authentication manager circuit122may receive, from a particular smart device106, an electronic message that includes a request for data access and a device access token. The server authentication manager circuit122may parse one or more device identifiers from the device access token. The server authentication manager circuit122may cross-reference the one or more device identifiers to the device identifier(s) previously stored in the server secure vault126in order to determine whether a particular device has been previously enrolled. The server authentication manager circuit122may compare various parsed items from the device access token to verify that a particular enrolled smart device106is not being spoofed (e.g., impersonated) by an unauthorized device. For example, the server authentication manager circuit122may 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 device106and installed on a different device. In another example, the server authentication manager circuit122may 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 system102in 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 device106. 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 system102may receive a geographical location identifier (e.g., a set of coordinates) from the smart device106and may compare the geographical location identifier to a set of previously known locations for the smart device106.

As part of authenticating a particular smart device106, the server authentication manager circuit122may 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 device106. As used herein, the term “provided to” refers to an application that includes functionality accessible to a user via the smart device106. In some arrangements, the application is installed on the smart device106. In some arrangements, the application is executing on the smart device106(e.g., via a browser). In some arrangements, the application is accessible at the smart device106via 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 device106. 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 system102. The server authentication manager circuit122may cross-reference the application identifier to the application identifier(s) and the corresponding restriction(s) previously stored in the server secure vault126in order to determine whether a particular application provided to the smart device106has been previously enrolled and before retrieving and transmitting the requested data back to the smart device106for use by the application.

As part of authenticating a particular smart device106, the server authentication manager circuit122may perform lifecycle-related checks on the received device access token. For instance, the server authentication manager circuit122may access a timestamp (e.g., a token creation time, a token expiration time, a token last used time) previously stored in the server secure vault126to determine if the received device access token is valid and/or if the user of the smart device106needs 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 device106to 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 device106, the server authentication manager circuit122may work in concert with the smart device106to 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 circuit122may receive, together or separately from the device access token, a session identifier for a secure authorized session established by the smart device106for the purpose of data transmission. If the server authentication manager circuit122is unable to validate the device access token and/or application, the server authentication manager circuit122may transmit an electronic message to the smart device106. The electronic message may include the session identifier and instructions to the smart device106to terminate the secure authorized session. The authentication manager circuit122may also be structured to receive electronic messages from the smart device106indicating that a particular secure authenticated session has been terminated, in which case the requested data will not be transmitted to the smart device106.

The server data manager circuit124is structured to execute computer-based operations for data provisioning to smart devices106in 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 system102and the smart device106is active, the server data manager circuit124may be structured to retrieve and/or provide the data requested by a particular smart device106. The server data manager circuit124may 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 system102may also access and apply application-specific restrictions in the server secure vault126, as discussed further herein.

To carry out its operations, server data manager circuit124may be structured to determine a financial account identifier of the user. In some arrangements, the server data manager circuit124may parse the financial account identifier from the data request message received from the smart device106. In some arrangements, the server data manager circuit124may parse the financial account identifier from the device access token received from the smart device106. To improve security of user data, the financial account identifier may be encoded for provisioning and storage by the smart device106by, 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 circuit124may apply a decoding algorithm and/or cross-reference the received encoded financial account identifier to a list previously stored in the server secure vault126in order to determine the actual account identifier. In some arrangements, the server data manager circuit124may receive a user identifier for the smart device provider computing system104(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 system104.

The service provider computing system102is communicatively coupled to the smart device provider computing system104, smart device106, and third-party computing system108via network113. To communicate via the network113, the service provider computing system102includes a network circuit134. The network circuit134may be used to establish connections with other computing devices by way of the network113. The network circuit134may include program logic that facilitates connection of the service provider computing system102to the network113. In some arrangements, the network circuit134may 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 circuit134may include an Ethernet device such as an Ethernet card and machine-readable media such as an Ethernet driver configured to facilitate connections with the network113. In some arrangements, the network circuit134includes the hardware and machine-readable media sufficient to support communication over multiple channels of data communication. Further, in some arrangements, the network circuit134includes cryptography capabilities to establish a secure or relatively secure communication session in which data communicated over the session is encrypted.

Although not shown inFIG.1, it is understood that device provider computing system104, smart device106, and/or third-party computing system108may include network interfaces for long-, medium- or short-range communication substantially similar to the network circuit134as described above.

The network113may 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 network113can enable communication between various nodes. In some arrangements, data flows through the network113from 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 network113layered over an OSI layer-3 network protocol such as Internet Protocol (IP), e.g., IPv4 or IPv6. The network113is 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 network113is the Internet; however, other networks may be used. The network113may 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 network113may 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 network113can 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 network113may 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 network113can 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 network113can 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 network113may be public, private, or a combination of public and private networks. The network113may be any type and/or form of data network and/or communication network.

The network113can include a network interface controller that can manage data exchanges with devices in the network113via 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 toFIG.2, depicted is a block diagram200of an example smart device106structured to facilitate server-to-device secure data exchange, according to some arrangements. In operation, the smart device106is 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 device106includes hardware201, operating system202, and applications208. The operating system202is shown to include a kernel203, a core services circuit204, and a control circuit206. The control circuit206can be a special purpose circuit structured to facilitate server-to-device secure data exchange between the smart device106and/or a secondary smart device240and the service provider computing system102ofFIG.1. It is understood that the control circuit206may be implemented, in whole or in part, as part of the operating system202and/or as one or more of the applications208. Further, the control circuit206may be structured to include various hardware201components described further herein.

As shown, hardware201includes a processor210, memory212, a secure element214, an input/output (I/O) circuit216, a communications circuit218, and a sensor219. The processor210may 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 memory212may 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 memory212may include non-transient volatile memory, non-volatile memory, and non-transitory computer storage media. The memory212may 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 memory212may be communicatively coupled to the processor210and include computer code or instructions for executing one or more processes described herein.

In some arrangements, the memory212is included in, at least in part, or is communicatively coupled to the secure element214. The secure element214can be a removable or built-in hardware and/or software circuit structured to securely store data and/or securely host applications208on the smart device106. Further, in some arrangements, the secure element214may store executables for invocation by the various circuitry included in the core services circuit204, control circuit206, and/or applications208. Further, in some arrangements, the secure element214may include a dedicated or shared memory space for execution of these various processes (e.g., by the kernel203and/or by the control circuit206). 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 element214includes a co-processor additional to the processor210. In some arrangements, the secure element214includes or is communicatively coupled to a near-field communications (NFC) controller, such as the communications circuit218. More generally, the communications circuit218may 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 circuit216includes 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 circuit216may provide an interface for the user to interact with various applications208. For example, the I/O circuit216may 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 circuit216may include, but is not limited to, a television monitor, a computer monitor, a speaker, and so on. In some arrangements, the I/O circuit216includes a camera suitable for taking photographic images and/or scanning QR codes using the smart device106.

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

As shown, the operating system202includes a kernel203, a core services circuit204, and a control circuit206. The kernel203is structured to work in conjunction with the core services circuit204. Accordingly, the kernel203can include a dedicated space in the memory212for executing various processes managed by the core services circuit204. 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 memory212and invoked, monitored, and terminated by the core services circuit204. In some arrangements, the kernel203and/or the core cervices circuit204may include kernel extension executables for the control circuit206(i.e. the control circuit206may be included in the kernel203and/or the core cervices circuit204at least in part.)

The control circuit206is a special purpose circuit structured to facilitate server-to-device secure data exchange operations. In some arrangements, the control circuit206may receive requests and/or provide data to the applications208. As shown, the applications208can include a service provider application230, a device-native application232, and a third-party application234. The service provider application230may be, for example, a mobile banking application structured to exchange data with the service provider computing system102. The service provider application230may 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 device106. The device-native application232may be developed and/or provided to the smart device106by an operator of the smart device provider computing system104, 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 device240, and the like. The third-party application234may be developed and/or provided by an operator of the third-party computing system108. The third-party application may be independently downloaded by a user of the smart device106or may be provided via an app store application managed by the smart device provider computing system104(e.g., the device-native application232). The third-party application234may 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 applications208may be configured, via the control circuit206, to access the user's financial data at the financial institution associated with the service provider computing system102. As such, the technical problem of enhancing data security is solved by device-based authentication such that the control circuit206can bypass the smart device provider computing system104in providing data from the smart device106to applications208not managed by the financial institution (e.g., in providing data to the device-native application232and/or the third-party application234) and/or to the secondary smart device240. Furthermore, the server-to-device secure data exchange infrastructure managed by the control circuit206in concert with the service provider computing system102allows for minimization or significant reduction of the amount of private data (e.g., personally identifiable information (PII)) stored on the smart device106. Furthermore, tokenization of confidential account information prevents the applications208from 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 application208.

As shown, the control circuit206includes a device token manager circuit220, a device authentication manager circuit222, an authorized session manager circuit223, a device data manager circuit224, and a device secure vault226. In operation, the control circuit206works in concert with the service provider computing system102to facilitate the enrollment of the smart device106, secondary smart device240, and/or particular applications208in the server-to-device secure data exchange ecosystem. Further, the control circuit206allows a user of the smart device106to provide authorized account access settings for the applications208. Further, the control circuit206allows the applications208and/or the secondary smart device240to initiate transactions (e.g., data downloads, queries, funds transfer requests, etc.) from the smart device106.

The device token manager circuit220is 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 toFIG.3-5.

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

In some arrangements, the smart device106is the device associated with the smart device identifier, and the user or an application208attempts to access and receive data at the smart device106. In some arrangements, a first smart device106(e.g., a mobile device, a tablet, a laptop, a desktop, etc.) is a full-functionality device that includes the functionality of the control circuit206sufficient to perform the functions described herein. A secondary smart device240(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 device240may be associated with an application208(e.g., a fob issued by a financial institution may be associated with the service provider application230, a virtual assistant device may be associated with a device-native application232that 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 application234, etc.). In this case, the device authentication manager circuit222may receive, at the smart device106, a secondary device identifier related to the secondary smart device240, and, upon prompting a user to approve a proposed secure data exchange transaction, may retrieve a corresponding token stored in the device secure vault226on a secure element214. In some arrangements, the requesting application208is 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 circuit222may generate and transmit the device access token and/or the application identifier to the server authentication manager circuit122of the service provider computing device102, which may retrieve and provide the requested data. According to various embodiments, the device authentication manager circuit222and/or the server authentication manager circuit122may apply the relevant restrictions prior to providing the data to the requesting computing device and/or application208.

As part of authenticating a particular smart device106or secondary smart device240for a particular data request, the authorized session manager circuit223may initiate and manage a secure authorized session (e.g., a secure time-limited communications session between the smart device106and the service provider computing device102). The authorized session manager circuit223may generate a session identifier for a secure authorized session established by the smart device106for the purpose of data transmission between a requestor device (e.g., smart device106) and/or requestor application208and the service provider computing device102. In some arrangements, the secure authorized session is established after validating the request at the smart device106(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 device106, such that the server authentication manager circuit122performs further token validation, as described above, and causes the authorized session manager circuit223to terminate the secure communications session if the appropriate server-side checks performed by the service provider computing system102have failed.

As part of authenticating a particular smart device106or secondary smart device240for a particular data request, the authorized session manager circuit223may terminate a particular secure authorized session according to predetermined criteria. For example, a secure authorized session may be terminated at the smart device106if no response is received from the service provider computing system102within 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 circuit224is structured to execute computer-based operations for data requests to the service provider computing system102from requestor application(s)208at the smart device106. The device data manager circuit224may provide (e.g., access, retrieve from memory212and/or secure element214) an API and/or SDK comprising executables for invocation by requestor application(s)208. 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 memory212and/or on secure element214) with permission labels corresponding to restrictions. Accordingly, the device data manager circuit224may provide to the requestor application(s)208only the allowable executables for permissible (non-restricted) function calls. In some arrangements, the application(s)208include 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 circuit224receives the parameter arguments from the application(s)208and 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 circuit224may cause the authorized session manager circuit223to terminate the corresponding secure authenticated session.

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

Referring now toFIG.3, depicted is a component diagram of an example graphical user interface (GUI)300of the smart device106ofFIG.2, the GUI structured to facilitate smart device106enrollment in server-to-device secure data exchange, according to some arrangements. As shown, a user may provide login credentials (e.g., a user name302and a password304) for the service provider computing system102via a data input control (e.g., a text box) of the GUI and then actuate the log in control306(e.g., a button). Upon receiving the login credentials, the service provider computing system102may transmit an electronic message to the smart device106, causing the smart device106to generate and display an enroll smart device user interface310. The enroll smart device user interface310provides a front-end to allow the user to interact with the control circuit206of the smart device106. For example, a list of smart devices312may be generated and provided to the user. The list of smart devices312may 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 devices240locally paired to the smart device106via Bluetooth or similar, by scanning a QR code provided by a particular secondary smart device240, by receiving and decoding an NFC token from a particular secondary smart device240at the smart device106, etc.).

For each selected smart device106or secondary smart device240in the list of smart devices312, the user can use the select accounts control314to specify financial accounts to which the selected smart device106or secondary smart device240should have access. Upon detecting a user interaction with a generate token control316, the device token manager circuit220of the smart device106may generate a device access token320for the selected device and/or selected account. An example device access token320may include one or more device identifiers322, financial account identifiers324, and/or financial account type (checking, savings, credit card, etc.) identifiers326, as shown. The device access token may be stored by the device token manager circuit220in device secure vault226, which may be stored in the memory212and/or secure element214of the smart device106.

Referring now toFIG.4, depicted is a component diagram of an example graphical user interface (GUI)330of the smart device106ofFIG.2, the GUI structured to allow a user to manage authorized account access settings via the smart device106, according to some arrangements. The GUI330is structured to provide to a user a list of account-level restrictions334selectable and configurable to fine-tune the level of granularity in account access. For example, the user may utilize account restriction controls336to specify operations that are allowable for the control circuit206of the smart device106to initiate for users and/or third-party applications. The account restriction controls336may include, for example, whether a physical and/or virtual card associated with a particular account can be turned on/off (e.g., activated/deactivated for financial and/or non-financial transactions) using server-to-device authentication, whether specific transaction data can be received using server-to-device authentication, whether disputes can be automatically initiated using server-to-device authentication, etc. The application restriction controls338further allow users to apply different account restriction controls336to specific applications. For example, a user may allow a greater scope of functionality to the service provider application230relative to the third-party application234. In another example, a user may allow a higher level of functionality if a particular application208is a trusted application. In some arrangements, the restrictions can be stored and applied locally on the smart device106before initiating a secure authorized session with the service provider computing system102. In some arrangements, the restrictions can be stored and applied by the service provider computing system102. In some arrangements, the restrictions can be included in device access tokens320and parsed from the device access tokens320before being applied. In some arrangements, the restrictions can be stored in a markup-language file and applied to select and/or parametrize only allowable function calls from an API or SDK library, which may be retrievably stored in the device secure vault226of the smart device106, in the server secure vault126of the provider computing system102, or in another suitable location.

Referring now toFIG.5, depicted is a component diagram of an example graphical user interface (GUI)340of the smart device106ofFIG.2, the GUI structured to allow a user to manage application settings for applications208provided to the smart device106, according to some arrangements.

As shown, the user can further restrict various applications208provided to the smart device106by defining specific restrictions348(access and/or data use levels) for each combination of a particular application344and account restriction controls346. For example, the user may specify that a particular application344can receive transaction data (an example account restriction control346) only when the sensor219(e.g., a GPS sensor) provides data to the smart device106and/or to the service provider computing system102that indicates that a user is within a predetermined radius of a predetermined geographical location, within a particular geofenced area, etc. In another example, the user may specify that a particular application344can receive transaction data (an example account restriction control346) only for transactions that meet a particular threshold, fall in a particular date range, have a particular transaction descriptor, etc. In another example, the user may specify that a particular application344can receive transaction data (an example account restriction control346) only for specific uses. For example, in some arrangements, an application208may be restricted from storing a data set, may be allowed to receive only summary data, may be allowed to receive only de-identified data that excludes PII, etc.

Referring now toFIG.6, depicted is a flowchart of an example method350to facilitate smart device106and/or application208enrollment in server-to-device secure data exchange, according to some arrangements. As a brief overview, the method350includes operations to enroll a smart device106and/or application208to securely send and receive data in a server-to-device secure data exchange ecosystem. The application208may be any of a service provider application230, a device-native application232, and/or a third-party application234.

At352, a smart device selection is received via a user interface provided on a display screen of the smart device106. In some arrangements, the smart device selection refers to the smart device106(i.e., when the smart device106is initially enrolled in server-to-device data exchange). In some arrangements, the smart device selection refers to a secondary smart device240, which the user is configuring for enrollment in the server-to-device data exchange ecosystem via a previously enrolled smart device106. At354, an additional selection of a specific application208may be received at the smart device106. At356, an additional selection of a specific financial account may be received at the smart device106. At358, a device access token is generated at the smart device106and/or at the service provider computing system102. The device access token may include a device identifier, a financial account identifier, a user identifier for the smart device provider computing system104, an application identifier, a timestamp, and/or other elements sufficient to authenticate a device and/or an application. At358, the device access token is retrievably stored. In some arrangements, the device access token is retrievably stored in the device secure vault226, which may be included in the memory212and/or secure element214of the smart device106. In some arrangements, the device access token is retrievably stored in the server secure vault126of the service provider computing system102. At363, various user selections related to authorized account access settings and/or account restrictions, as described above, are received at the smart device106. As described above, the authorized account access settings may be stored on the smart device106and/or on the service provider computing system102.

Referring now toFIG.7, depicted is a flowchart of an example method370to facilitate a transaction using the smart device106and/or a secondary smart device240in server-to-device secure data exchange, according to some arrangements. As a brief overview, the method370includes operations to allow a smart device106and/or the secondary smart device240to perform secure data exchange using a previously stored device access token. Any of the previously enrolled applications208(a service provider application230, a device-native application232, and/or a third-party application234) may engage in server-to-device secure data exchange, subject to the appropriate restrictions set using the control circuit206of the smart device106.

At372, a secure authorized session between the smart device106and the service provider computing system is established as described relative toFIGS.1and2. These operations may be performed contemporaneously or sequentially, in any suitable order, relative to receiving a transaction request from a particular application208. For example, in some arrangements, an authorized secure session is automatically created for an active application208before said application208generates a request for a transaction. In some arrangements, an authorized secure session is created after the transaction request is received at the smart device106and/or after the transaction request is validated, at376, at the smart device106and/or at the service provider computing system102.

As part of validating the transaction request at376, the smart device106may identify a requestor application208using an application name, an application instance identifier, an installation and/or last update timestamp for a particular application instance, etc. The smart device106may retrieve a previously stored device access token corresponding to the application208and verify that the token is valid (e.g., the token is not expired, the token was created after the installation and/or last update timestamp for the application208, etc.). The smart device106may further retrieve previously stored restrictions associated with the application208and/or the device access token and apply the restrictions to the request and/or transmit the restrictions to the service provider computing system102for application of the restrictions. Applying the restrictions may include, for example, scrubbing (validating) and/or constructing allowable function calls using an API or SDK for performing the relevant transaction (e.g., for accessing the relevant data, for invoking the relevant functionality, etc.) Applying the restrictions may further include determining, based on the request, a specific account identifier associated with the transaction and validating that the account is on a list of specific accounts or subaccounts for which the requested transaction is allowed.

At380, the smart device106receives an electronic response message from the service provider computing system102. The response message may include a data set generated by the service provider computing system102in response to the request. At382, the received data set is provided to the requestor application208.

Referring now toFIG.8, depicted is a component diagram of an example graphical user interface (GUI)340of the smart device106ofFIG.2. The GUI340is structured to allow a user to manage application settings802for use of dynamic account status indicators816with account data provisioning requests. As a general overview, dynamic account status indicators816may be associated with financial accounts and structured to enable differentiated dynamic presentation of account attributes to the user of the smart device106via the GUI340. The differentiated dynamic presentation systems and methods described herein solve a technical problem of customizing account presentation based on confidential account-related data without providing the confidential account-related data to the requestor entity and/or by ensuring that the requestor entity has authorization to access the confidential account-related data on a particular smart device106. According to various embodiments, the requestor entity may be a digital wallet application. In such embodiments, the dynamic account status indicators may cause a graphical representation of a payment account (e.g., a payment card image) to change (e.g., change color or design, change an opacity, change a shape, etc.) or have information or graphics overlaid on top of the representation (e.g., text overlaid on top of the payment card image).

Accordingly, one or more applications provided to the smart device106may include digital wallet features. For example, any of the service provider application230, device-native application232, or third party application234may be structured to allow the user of the smart device106to generate, manage, and/or use digital identities for the user's real-world financial accounts (e.g., a checking account, a savings account, a brokerage account, a credit card account, a rewards account, etc.). In some arrangements, such as when the service provider application230is a digital wallet application, the entity that provides, manages, or administers the financial account also provides, manages, or administers the digital wallet application. In some arrangements, such as when the device-native application232and/or third party application234is a digital wallet application, the entity that provides, manages, or administers the financial account is different from the entity that provides, manages, or administers the digital wallet application. For example, the operator of the device-native application232may also provide a pre-installed or downloadable device-native digital wallet application. In some arrangements, the device-native digital wallet application may be downloadable from the smart device provider computing system104via an app store provided by the operator of the smart device provider computing system104. In another arrangement, the digital wallet application may be provided and/or downloadable from the third-party computing system108.

The digital identities of the financial accounts may include various account attributes, such as account identifiers, account numbers, PIN code(s), login credentials, expiration dates, current balances, transaction history, credit limits, remaining available spend, daily cash withdrawal limits, daily purchase limits, card enabled/disabled indicators, reward points usage conditions, rewards points balances, geographical restrictions on use, etc. In some embodiments, the account attributes are replacement values used to obscure actual values, and a cross-reference structure that maps these values may be stored on or off the smart device106. In some embodiments, the cross-reference structure may include one or more device access tokens generated for the account. In some embodiments, the account attributes are tokenized values generated, for example, as hashes of the respective actual values according to suitable hashing algorithms. In some embodiments, at least some attributes of the digital identities are stored in the memory212and/or on the secure element214of the smart device106. In some embodiments, at least some attributes of the digital identities are stored remotely relative to the smart device106—for example, on data storage media associated with the service provider computing system102, such as the server secure vault126.

Various attributes of digital identities may be used to enable differentiated dynamic presentation of account attributes to the user of the smart device106via the GUI340. In an example use case, a quick glance indicator (also sometimes referred to as a dynamic account status indicator) may be associated with a digital identity of a financial account and rendered via the GUI340. According to various embodiments, the quick glance indicator may comprise a card image or another graphics- and/or text-based informational representation entity rendered via the GUI340. In some embodiments, the quick glance indicator may include one or more properties associated with account data and/or with the card image or another informational representation entity. The property may include a particular value or range of values for color and/or opacity such that, for example, when an account balance reaches a predetermined threshold, the color and/or opacity of the informational representation entity are set to a specified value. The property may include a particular value or range of values for location-specific use. For example, a particular card may be enabled or disabled for use in specified geographical locations, at specified merchants, etc. The property may further include a binary enabled/disabled indicator.

In an example arrangement ofFIG.8, the dynamic account status indicator settings804, identified by the header802, can be pre-defined by the service provider computing system102. The control circuit206of the smart device106may retrieve the settings from the server secure vault126via a query, API call, SDK function call, or another suitable electronic data request message. The dynamic account status indicator settings804may be retrievably stored relative to identifier(s) or data regarding a particular requestor entity (e.g., relative to an application instance identifier for a digital wallet application).

The dynamic account status indicator settings804may be further editable by the user of the smart device106. For example, as shown, the user may specify how various account data items (account type, balance, credit limit, daily limit, transaction data, rewards data, etc.) should be used to generate the quick glance indicator. For each item shown at804, the user may further modify or define the criteria810, such as the amount812, percentage814, indicator value816, card status818, etc. In an example use case, the user may, for example, specify that if an account balance is at or above the amount812(e.g., $4,800), the indicator value816is set to “red” and the card status818is set to “off” (e.g., disabled) such that the card cannot be used for further purchases. As a result, the quick glance indicator for the corresponding digital identity may include a displayable card image that is colored red and has an “X” over it to indicate that the card is not available for use, as shown inFIG.9. The user may use the next control820to define another set of parameters—for example, if the account balance is at or above $3,000, the indicator value816is set to “yellow”, if the account balance is at or below $1,000, the indicator value816is set to “green”, etc. In some embodiments, the threshold amounts are evaluated relative to the credit limit if the account is a credit account. In some embodiments, the threshold amounts are evaluated relative to the available balance of funds if the account is a deposit account. Further, in various embodiments, percentage814thresholds defined relative to the daily limit, account balance, or the credit limit can be used instead or in addition to amount812thresholds. In some embodiments, the GUI340allows the user to navigate to an account management website or application provided by the service provider computing system102. Accordingly, the user may define or modify the settings shown according toFIG.8via the banking website or application.

One of skill in the art will appreciate that the term “card”, as used herein, may be used interchangeably with the term “account”. Accordingly, the digital wallet application may include a digital identity for a virtual account that does not have a corresponding physical card.

In operation, the quick glance indicator is dynamically generated when a particular requestor entity provides a request for account data to the smart device106. For example, the smart device106may receive an account data provisioning request from a digital wallet application when the user of the smart device106opens and/or activates the digital wallet application or attempts to perform a transaction. The request may include an actual or obscured account identifier. For example, the requestor entity may retrieve and include in the request a previously stored account identifier, which may be part of a digital identity for an account. The smart device106may determine a device access token based on the requestor entity and/or the account identifier. In some embodiments, the smart device106may parse the request into one or more data items (e.g., account balance, credit limit), verify, based on the device access token, that these data items are not access-restricted for the requestor entity, access retrievably stored dynamic account status indicator settings804, retrieve the relevant data items, apply the dynamic account status indicator settings804to the data items, and generate a displayable quick glance indicator. The displayable quick glance indicator may be rendered on the smart device106. In some embodiments, the data items are not persisted (not stored in non-volatile memory) on the smart device106, which improves data security. Furthermore, once the displayable quick glance indicator is generated and rendered in response to a particular data request, the smart device106may be structured to clear its cache or otherwise discard the data from its transitory memory.

Referring now toFIG.9, depicted is a component diagram of an example graphical user interface (GUI)340of the smart device106ofFIG.2. The GUI340is structured to facilitate account data provisioning operations using dynamic account status indicators, according to some arrangements. In some arrangements, the user may navigate to the GUI340from the display screen shown inFIG.8. In some arrangements, the user may navigate to the GUI340by accessing the digital wallet application on the smart device106. In some arrangements, the user may navigate to the GUI340when performing a financial transaction, for example, responsive to bringing the smart device106in proximity to a merchant's or another funds recipient's device, or more generally, the third-party computing system108, and activating an NFC communications interface, a Bluetooth communications interface, or another suitable communications interface.

As shown according to an example embodiment, the GUI340is structured to include one or more informational representation entities that correspond to one or more digital identities of the user's accounts. In some embodiments, the one or more digital identities are accessible via a digital wallet application. As shown, in the example arrangement, the user of the smart device106has three accounts, each represented by a respective card image910,920, or930. As shown according to an example embodiment, each of the card images910,920, or930is rendered as an image of a payment card; however, any suitable displayable entity comprising an image, text, and/or computer-executable instructions (e.g., navigation controls, data access controls, etc.) can be used.

As shown, an example card image910is associated with a dynamic account status indicator919and a navigable control structured to retrieve and display further information912and/or932. In some embodiments, the dynamic account status indicator919may define a set of properties for the card image910. The set of properties may be populated when the dynamic account status indicator919is generated. The dynamic account status indicator919may be programmatically bound to the card image910as an attribute, as a navigable reference (e.g., hyperlink) to a markup-language file (e.g., an XML file), or using another suitable method. In some embodiments, the dynamic account status indicator919is a record set retrieved responsive to a query, an API function call, and/or an SDK function call, or via another suitable electronic messaging interface. In some embodiments, the dynamic account status indicator919may exist only in volatile memory of the smart device106.

In operation according to an example use case, the user accesses a digital wallet application on the smart device106via the GUI340. The user is presented with a first card image910for a first account, a second card image920for a second account, and a third card image930for a third account. The user may wish to use one or more of the respective accounts to perform a funds transfer transaction (e.g., to make a purchase at a store).

As shown, the first account is disabled and unavailable for use. The user may tap, click or otherwise interact with the first card image910to activate a navigation control. The navigation control may be structured to provide further information912regarding the data items that caused the dynamic status indicator919to be generated for the first account. For example, as shown according to the dynamic status indicator919, the user may have used the user interface ofFIG.8to disable the account and set the color of the card image to red when the balance exceeds $4,800 relative to the credit limit. As shown according to further information912, the user's current account balance912is $4,900 relative to the credit limit of $5,000. As shown, in some embodiments, the user may interact with the disable card control918to make the account available for use despite the restrictions.

To generate and render the first card image910, when the user accesses the GUI340via the digital wallet application, the digital wallet application, also sometimes referred to as a requestor entity, generates a request for data sufficient to generate and render the first card image910for the user's account. The smart device106retrieves, from the secure element214or memory212, a device access token based on the requestor entity and/or the account identifier included in the request. The smart device106accesses retrievably stored dynamic account status indicator settings (defined, for example, as described in reference toFIG.8) for the user's account. The smart device106retrieves the relevant data items (here, the account balance912and account limit914) and applies the dynamic account status indicator settings to the data items. Applying the settings to data items may include various suitable operations, such as value comparisons to thresholds, enabling or disabling accounts for use, enabling or disabling geographical restrictions, etc. Accordingly, the smart device106generates the dynamic status indicator919.

Further, the smart device106may implement access controls for the data items, which may include confidential account-related information. For example, in some embodiments, the smart device106may verify, based on the device access token and according to the control settings described in relation toFIGS.3-5, that the data items, such as the balance914and credit limit916, are not access-restricted for the requestor entity. If not access-restricted, the smart device106may provide further information in an electronic response message directly to the requestor entity (e.g., the digital wallet application). If items are access-restricted, the smart device106may generate and display a pop-up message not accessible or modifiable by the requestor entity to show further information912. Accordingly, in some embodiments, the requestor entity may be provided by the smart device106only with the dynamic status indicator919, which may be sufficient to define the appearance of the card image910without revealing confidential account-related information.

As shown, the second account is enabled and available for use. The second account, corresponding to the second card image920, may be selected by the user to complete the transaction. In some embodiments, the second account is automatically selected as a payment method for the transaction if other accounts are unavailable for use or are in a “yellow” or “red” state. More generally, the digital wallet application may be structured to automatically select, as a payment method, an account that is the best candidate for use relative to other accounts of the user (e.g., “green” vs. “yellow”, “yellow” vs. “red”, etc.).

As shown, the third account is disabled and unavailable for use. The user may tap, click or otherwise interact with the third card image930to activate a navigation control. The navigation control may be structured to provide further information932. Here, in an example use case, further information932may include a digital map934. The digital map934may include an indication of Merchant A location934aand the user's current location934b. The user's current location may correspond to the current location of the smart device106determined using a GPS transceiver or another type of sensor219associated with the smart device106. The dynamic status indicator generated for the third account may include a location use restriction that prevents the third account from being used at Merchant A (e.g., if the smart device106is within a predetermined distance from Merchant A). Accordingly, further information932may include a notification936explaining why the third account is unavailable for use. Further information932may also include a disable card control938, and, in some embodiments, the user may interact with the disable card control918to make the account available for use despite the restrictions.

Referring now toFIG.10, depicted is a flowchart of an example method1000to facilitate account data provisioning operations using dynamic account status indicators, according to some arrangements. As a brief overview, the method1000includes operations to enable a smart device106to facilitate the generation and rendering, on a user interface of the smart device106, of account information according to a dynamic account status indicator. Example embodiments of dynamic account status indicators are described in relation toFIGS.8and9. The operations of method1000may be performed by the service provider computing system102, smart device provider computing system104, smart device106, and/or third-party computing system108.

At1002, the smart device106receives an account data provisioning request. The account data provisioning request may be generated by any of the service provider application230, device-native application232, or third-party application234provided to the smart device106. The account data provisioning request may include an account identifier. In some embodiments, the account identifier is associated with a device access token. The device access token is unique to the smart device and/or a combination of a smart device, particular financial account of a user, and application instance identifier for the requestor entity (or another suitable identifier for the requestor entity, such as its associated computing system102,104or108). In some embodiments, the account identifier is a device access token. In some embodiments, the account identifier is an actual account identifier value of the financial account. In some embodiments, the account identifier obscures or replaces the actual account identifier. In some embodiments, the requestor entity is a digital wallet application and the account identifier is associated with the application and retrievably stored in the memory212of the smart device106and/or in memory associated with the requestor computing system, such as any of the systems102,104, or106. In some embodiments, the account identifier is received by the requestor entity via a function call from an API or SDK library made available by the service provider computing system102to the requestor entity.

At1004, the smart device106(e.g., the control circuit206) may extract the account identifier from the electronic request message and, based on the extracted account identifier, determine the corresponding device access token. To determine the device access token, the smart device106may also extract from the electronic request message an application instance identifier for the application that generated the function call, or another suitable identifier for the requestor entity. An example device access token320is described in relation toFIG.3. The device access token may be stored in the memory212and/or secure element214of the smart device106. In some embodiments, the smart device106may tokenize and/or detokenize the account identifier and/or application instance identifier received from the requestor entity to generate values in a format consistent with that of the device access token. The smart device106may then retrieve the retrievably stored device access token, based on the received values, from the memory212and/or secure element214.

At1006, smart device106(e.g., the control circuit206) may identify an access-controlled data element sufficient to generate a dynamic account status indicator. The smart device106may access (e.g., in the memory212, secure element214, and/or via a function call to the service provider computing system102) the dynamic account status indicator settings804, which may include the criteria810as described in relation toFIG.8. The smart device102may determine, based on the retrieved settings and/or criteria, which confidential data elements associated with a user's financial account are needed to generate the dynamic account status indicator. For example, if the settings and/or criteria call for displaying a graphical representation of the account in a particular color based on the account balance, the corresponding confidential data elements may include the account balance.

The smart device102may determine, based on the device access token and the control restrictions described relative toFIGS.3-5, whether the requestor entity is authorized to receive the confidential data element. If the requestor entity is authorized to receive the confidential data element, the smart device106may provide the data element to the requestor entity, and the operations1008and1010may be performed by the requestor entity at least in part. If the requestor entity is not authorized to receive the data element, the operations1008and1010may be performed by the control circuit206. In some embodiments, however, the control circuit206may be structured to delegate some aspects of the operations1008and/or1010to the requestor entity if these aspects do not involve receiving confidential data by the requestor entity. For example, the control circuit206may generate parametrized function calls for rendering card images and provide the same to the requestor entity for execution on the smart device106.

At1008, the smart device106(e.g., the control circuit206) may generate an executable graphic rendering instruction. In some embodiments, the executable graphic rendering instruction is a function call structured to generate the definitions for user interface elements ofFIG.9, such as the card image910. As described in relation toFIG.9, the card image910may have a dynamic account status indicator919associated therewith. The smart device106may populate the dynamic account status indicator919properties or data items with appropriate values determined based on the retrieved settings and/or criteria. For example, if the account balance indicates that a card should be shown in red (or otherwise marked to visually, audibly, or haptically indicate a restriction or a lack of a restriction such as, for example, sounding a particular tone or combination of tones corresponding to a particular alert level) and disabled for use, the smart device106may populate the relevant dynamic account status indicator919properties with appropriate values. Accordingly, the output of operations1008may include an executable instruction (e.g., an .exe file). The executable instruction may comprise a static or dynamic reference to a previously stored image file (e.g., a card image file) and the dynamic account status indicator919properties that customize the appearance and/or functionality of the previously stored image file. In some arrangements, the smart device106provides the executable instruction to the requestor entity for execution at1010. As will be appreciated, in such arrangements, the executable instruction may not include any confidential account information but rather includes the dynamic account status indicator919. In some arrangements, however, the smart device106may retrieve (e.g., via a function call to the service provider computing system102) previously stored further information regarding the account and may provide the same to the requestor entity.

At1010, the requestor entity generates and displays the requested card image modified according to the dynamic account status indicator919. In some embodiments, the requestor entity executes the executable instruction received at1008. In some embodiments, the executable instruction is a response to the function call made by the requestor entity at1002. The output of the operations at1010may be a graphical user interface rendered on the smart device106and comprising at least one card image, such as the card image910shown inFIG.9.

It should be understood that no claim element herein is to be construed under the provisions of 35 U.S.C. § 112 (f), unless the element is expressly recited using the phrase “means for.”

The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory).

Alternatively or additionally, the one or more processors may be structured to perform or otherwise execute certain operations independent of one or more co-processors. In other example embodiments, two or more processors may be coupled via a bus to enable independent, parallel, pipelined, or multi-threaded instruction execution. Each processor may be provided as one or more general-purpose processors, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), or other suitable electronic data processing components structured to execute instructions provided by memory. The one or more processors may take the form of a single core processor, multi-core processor (e.g., a dual core processor, triple core processor, quad core processor, etc.), microprocessor, etc. In some embodiments, the one or more processors may be external to the apparatus, for example the one or more processors may be a remote processor (e.g., a cloud based processor). Alternatively or additionally, the one or more processors may be internal and/or local to the apparatus. In this regard, a given circuit or components thereof may be disposed locally (e.g., as part of a local server, a local computing system, etc.) or remotely (e.g., as part of a remote server such as a cloud based server). To that end, a “circuit” as described herein may include components that are distributed across one or more locations.