SYSTEM AND METHOD FOR REAL-TIME MESSAGE DISPLAY DECISIONING

TECHNICAL FIELD

The present disclosure relates to network communications and, in particular, to systems and methods for real-time message display decisioning.

BACKGROUND

Graphical user interfaces are used to display data. The data may be received from two or more systems and as such the graphical user interface may display data that is inconsistent or contradictory.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application and in which:

FIG. 1 is a schematic diagram illustrating an operating environment of an example embodiment;

FIG. 2A is a high-level schematic diagram of an example computing device;

FIG. 2B is a schematic block diagram showing a simplified organization of software components stored in memory of the example computing device of FIG. 2A;

FIG. 3 shows, in flowchart form, an example method for delivering message objects to a recipient entity across multiple channels;

FIG. 4 shows, in flowchart form, an example method for managing a queue of message objects for transmission to a recipient entity;

FIG. 5 shows, in flowchart form, an example method for managing a queue of message objects based on user interaction detected across multiple channels;

FIG. 6 shows, in flowchart form, an example method for configuring a message object for transmission to a recipient entity;

FIG. 7 shows, in flowchart form, an example method for real-time message display decisioning;

FIG. 8 shows, in flowchart form, another example method for real-time message display decisioning; and

FIG. 9 shows, in flowchart form, an example method for updating one or more data fields of a message object prior to displaying the message object.

Like reference numerals are used in the drawings to denote like elements and features.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

In an aspect there is provided a computing system, comprising a processor; a communications module coupled to the processor; and a memory coupled to the processor, the memory storing instructions that, when executed, configure the processor to authenticate a session associated with a data record; receive, via the communications module and from a server, a first message object; analyze metadata of the first message object to identify one or more display rules associated with the first message object; determine, based on one or more elements displayed on a user interface associated with the authenticated session, that the one or more elements satisfy the one or more display rules; and responsive to determining that the one or more elements satisfy the one or more display rules, display the first message object on the user interface associated with the authenticated session.

In one or more embodiments, the instructions, when executed, further configure the processor to receive, from the server, a second message object; analyze metadata of the second message object to identify one or more display rules associated with the second message object; determine, based on the one or more elements displayed on the user interface associated with the authenticated session, that the one or more elements do not satisfy the one or more display rules; and responsive to determining that the one or more elements do not satisfy the one or more display rules, cancel the second message object.

In one or more embodiments, when cancelling the second message object, the instructions, when executed, further configure the processor to send, via the communications module and to the server, a signal indicating that the second message object is to be removed from a set of message objects.

In one or more embodiments, determining, based on one or more elements displayed on the user interface associated with the authenticated session, that the one or more elements do not satisfy the one or more display rules includes comparing the one or more elements displayed on the user interface to the one or more display rules and determining that the one or more elements displayed on the user interface are inconsistent with the first message object.

In one or more embodiments, determining, based on one or more elements displayed on the user interface associated with the authenticated session, that the one or more elements satisfy the one or more display rules includes comparing the one or more elements displayed on the user interface to the one or more display rules and determining that the one or more elements displayed on the user interface are consistent with the first message object.

In one or more embodiments, the one or more elements displayed on the user interface are associated with one or more external systems.

In one or more embodiments, the one or more elements displayed on the user interface include real-time or near real-time data associated with the data record.

In one or more embodiments, the data record is associated with a resource account.

In one or more embodiments, the first message object is generated in response to detection of a trigger condition associated with the data record.

In one or more embodiments, the first message object includes metadata identifying at least one data field of the first message object for updating prior to displaying the first message object on the user interface.

In another aspect there is provided a computer-implemented method, comprising authenticating a session associated with a data record; receiving, from a server, a first message object; analyzing metadata of the first message object to identify one or more display rules associated with the first message object; determining, based on one or more elements displayed on a user interface associated with the authenticated session, that the one or more elements satisfy the one or more display rules; and responsive to determining that the one or more elements satisfy the one or more display rules, displaying the first message object on the user interface associated with the authenticated session.

In one or more embodiments, the method further comprises receiving, from the server, a second message object; analyzing metadata of the second message object to identify one or more display rules associated with the second message object; determining, based on the one or more elements displayed on the user interface associated with the authenticated session, that the one or more elements do not satisfy the one or more display rules; and responsive to determining that the one or more elements do not satisfy the one or more display rules, cancelling the second message object.

In one or more embodiments, the one or more elements displayed on the user interface are associated with one or more external systems.

In one or more embodiments, the one or more elements displayed on the user interface include real-time or near real-time data associated with the data record.

In one or more embodiments, the first message object is generated in response to detection of a trigger condition associated with the data record.

According to another aspect there is provided a non-transitory computer readable storage medium comprising processor-executable instructions which, when executed, configure a processor to authenticate a session associated with a data record; receive, via a communications module and from a server, a first message object; analyze metadata of the first message object to identify one or more display rules associated with the first message object; determine, based on one or more elements displayed on a user interface associated with the authenticated session, that the one or more elements satisfy the one or more display rules; and responsive to determining that the one or more elements satisfy the one or more display rules, display the first message object on the user interface associated with the authenticated session.

In one or more embodiments, the processor-executable instructions, when executed, further configure the processor to receive, from the server, a second message object; analyze metadata of the second message object to identify one or more display rules associated with the second message object; determine, based on the one or more elements displayed on the user interface associated with the authenticated session, that the one or more elements do not satisfy the one or more display rules; and responsive to determining that the one or more elements do not satisfy the one or more display rules, cancel the second message object.

Other example embodiments of the present disclosure will be apparent to those of ordinary skill in the art from a review of the following detailed descriptions in conjunction with the drawings.

In the present application, the term “message object” refers broadly to any data object that contains at least one target message. The target message that is associated with a message object may, for example, be a reminder, an alert, an announcement, an offer, or the like. In some cases, a message object may be a notification which may be a visual, audible, and/or haptic notification. A message object may be formatted for outputting in a particular medium, such as an electronic device or service. For example, a message object may be an instant message, a personal message (i.e., direct messages), a text message, an email, a pop-up window, a selectable user interface element, an in-app message (e.g., push notifications), a voice recording, or the like.

In the present application, the term “and/or” is intended to cover all possible combinations and sub-combinations of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, and without necessarily excluding additional elements.

In the present application, the phrase “at least one of . . . or . . . ” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements.

FIG. 1 illustrates an exemplary computing environment 100 consistent with certain disclosed embodiments. As shown in FIG. 1, the computing environment 100 may include a client device 110, a resource server 150, a database 151 associated with the resource server 150, a message management system 170, and a network 120 connecting one or more of the components of computing environment 100.

As illustrated, a resource server 150 (which may also be referred to as a server computing system) and client device 110 communicate via the network 120. In at least some embodiments, the client device 110 may be a computing device. The client device 110 may take a variety of forms including, for example, a mobile communication device such as a smartphone, a tablet computer, a wearable computer (such as a head-mounted display or smartwatch), a laptop or desktop computer, or a computing device of another type. The client device 110 may be associated with a client entity (e.g., an individual, an organization, etc.) having resources that are managed by or via the resource server 150. For example, the resource server 150 may be a financial institution server and the client entity may be a customer of a financial institution operating the financial institution server. The client device 110 may store software instructions that cause the client device 110 to establish communications with the resource server 150.

The resource server 150 may track, manage, and maintain resources, make lending decisions, and/or lend resources to a client entity associated with the client device 110. The resources may, for example, be computing resources, such as memory or processor cycles. In at least some embodiments, the resources may include stored value, such as fiat currency, which may be represented in a database. For example, the resource server 150 may be coupled to a database 151, which may be provided in secure storage. The secure storage may be provided internally within the resource server 150 or externally. The secure storage may, for example, be provided remotely from the resource server 150. For example, the secure storage may include one or more data centers. The data centers may, in some embodiments, store data with bank-grade security.

The database 151 may include data records for a plurality of accounts and at least some of the data records may define a quantity of resources associated with the client entity. For example, the client entity may be associated with an account having one or more data records in the database 151. The data records may reflect a quantity of stored resources that are associated with the client entity. Such resources may include owned resources and, in at least some embodiments, borrowed resources (e.g., resources available on credit). The quantity of resources that are available to or associated with the client entity may be reflected by a balance defined in an associated data record such as, for example, a bank balance.

In at least some embodiments, the database 151 may store various types of information in connection with customers of a business entity that administers the resource server 150. For example, the database 151 may store customer profile data and financial account data associated with customers. The customer profile data may include, without limitation, personal information of registered customers, authentication credentials of the customers, account identifying information (e.g., checking account, savings account, revolving credit line, etc.), and information identifying services (e.g., banking services, investment management services, etc.) and/or programs that are offered to the customers by the business entity. The financial account data may include, in some embodiments, portfolio data relating to portfolios of investments that are held by customers. A customer's portfolio data may include, for example, information identifying actual positions held by the customer in various securities, information identifying a “virtual” portfolio composed of simulated positions held by the customer in various securities, and “watch lists” specifying various securities that are monitored by the customer.

The business entity associated with the resource server 150 may provide services that are accessible to the client entity. For example, the business entity may provide account management services, financial transaction services, and investment management services for the client entity. In at least some embodiments, the resource server 150 may be configured to provide a user interface that allows client devices 110 to access the services offered by the business entity. By way of example, the resource server 150 may be configured to provide a website or web-based portal which can be accessed via the client devices 110. The website (or portal) may include web content corresponding to various services offered by the business entity, and the resource server 150 may provide the web content for display on the client devices 110. As another example, the resource server 150 may be associated with software that can be installed and/or run on the client devices 110. The resource server 150 may, for example, implement the server-side backend of a mobile application (e.g., a mobile banking application) that provides users access to services offered by the business entity.

A message management system 170 is provided in the computing environment 100. The message management system 170 provides services for managing messages that are transmitted between devices and systems of the computing environment 100. In particular, the message management system 170 may be configured to generate, send, receive, convert, and store messages (and more generally, message objects). The message management system 170 may handle message-related services on behalf of one or more computing systems that are communicably connected to the message management system 170. For example, one or more remote or external computing systems may request the message management system 170 to perform various message-related actions (e.g., message generation and transmission).

In some embodiments, the message management system 170 may be implemented by a computing system that manages and/or has access to user accounts. For example, a computing system that manages resource accounts, such as the resource server 150, may implement the message management system 170. In particular, the features and functions of the message management system 170 may be provided by a resource server. The resource server may offer services relating to management of messages in connection with user accounts that are managed by the resource server. While FIG. 1 illustrates the resource server 150 and the message management system 170 as being conceptually distinct, in some embodiments, they may be represented as the same computing system.

The message management system 170 may generate messages for transmission. In some embodiments, messages may be generated based on automated analysis of input data for the message management system 170. The input data may be data obtained from one or more remote computing systems. For example, the message management system 170 may be configured to generate messages based on automated analysis of user account data that is obtained from account management servers. In particular, the message management system 170 may access account data for specific users and algorithmically generate messages for presenting to the users based on their account data.

The client device 110, the resource server 150, and the message management system 170 may be in geographically disparate locations. Put differently, the client device 110 may be remote from one or more of the resource server 150 and the message management system 170. As described above, the client device 110, the resource server 150, and the message management system 170 may be computing systems.

The network 120 is a computer network. In some embodiments, the network 120 may be an internetwork such as may be formed of one or more interconnected computer networks. For example, the network 120 may be or may include an Ethernet network, an asynchronous transfer mode (ATM) network, a wireless network, or the like.

FIG. 2A is a high-level operation diagram of an example computing device 105. In some embodiments, the example computing device 105 may be exemplary of one or more of the client device 110, the resource server 150, and the message management system 170. The example computing device 105 includes a variety of modules. For example, as illustrated, the example computing device 105, may include a processor 200, a memory 210, an input interface module 220, an output interface module 230, and a communications module 240. As illustrated, the foregoing example modules of the example computing device 105 are in communication over a bus 250.

The processor 200 is a hardware processor. Processor 200 may, for example, be one or more ARM, Intel x86, PowerPC processors, or the like.

The memory 210 allows data to be stored and retrieved. The memory 210 may include, for example, random access memory, read-only memory, and persistent storage. Persistent storage may be, for example, flash memory, a solid-state drive, or the like. Read-only memory and persistent storage are a computer-readable medium. A computer-readable medium may be organized using a file system such as may be administered by an operating system governing overall operation of the example computing device 105.

The input interface module 220 allows the example computing device 105 to receive input signals. Input signals may, for example, correspond to input received from a user. The input interface module 220 may serve to interconnect the example computing device 105 with one or more input devices. Input signals may be received from input devices by the input interface module 220. Input devices may, for example, include a touchscreen input, keyboard, trackball, or the like. In some embodiments, all or a portion of the input interface module 220 may be integrated with an input device. For example, the input interface module 220 may be integrated with one of the aforementioned example input devices.

The output interface module 230 allows the example computing device 105 to provide output signals. Some output signals may, for example, allow provision of output to a user. The output interface module 230 may serve to interconnect the example computing device 105 with one or more output devices. Output signals may be sent to output devices by output interface module 230. Output devices may include, for example, a display screen such as, for example, a liquid crystal display (LCD), a touchscreen display. Additionally, or alternatively, output devices may include devices other than screens such as for example a speaker, indicator lamps (such as for, example, light-emitting diodes (LEDs)), and printers. In some embodiments, all or a portion of the output interface module 230 may be integrated with an output device. For example, the output interface module 230 may be integrated with one of the aforementioned example output devices.

The communications module 240 allows the example computing device 105 to communicate with other electronic devices and/or various communications networks. For example, the communications module 240 may allow the example computing device 105 to send or receive communications signals. Communications signals may be sent or received according to one or more protocols or according to one or more standards. For example, the communications module 240 may allow the example computing device 105 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Evolution Data Optimized (EVDO), Long-term Evolution (LTE) or the like. Additionally, or alternatively, the communications module 240 may allow the example computing device 105 to communicate using near-field communication (NFC), via Wi-Fi (™), using Bluetooth (™) or via some combination of one or more networks or protocols. Contactless payments may be made using NFC. In some embodiments, all or a portion of the communications module 240 may be integrated into a component of the example computing device 105. For example, the communications module may be integrated into a communications chipset.

Software comprising instructions is executed by the processor 200 from a computer-readable medium. For example, software may be loaded into random-access memory from persistent storage of memory 210. Additionally, or alternatively, instructions may be executed by the processor 200 directly from read-only memory of memory 210.

FIG. 2B depicts a simplified organization of software components stored in memory 210 of the example computing device 105. As illustrated these software components include an operating system 280 and application software 270.

The operating system 280 is software. The operating system 280 allows the application software 270 to access the processor 200, the memory 210, the input interface module 220, the output interface module 230 and the communications module 240. The operating system 280 may be, for example, Apple iOS™, Google Android™, Linux, Microsoft Windows™, or the like.

The application software 270 adapts the example computing device 105, in combination with the operating system 280, to operate as a device performing particular functions. In some embodiments, the application software 270 may include a resource management application. The resource management application may, for example, be a personal banking application that enables users to perform various actions for managing their bank accounts using a personal computing device (e.g., laptop, mobile phone, etc.).

Reference is made to FIG. 3, which shows, in flowchart form, an example method 300 for delivering message objects to a recipient entity. The operations of method 300 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 300 may be implemented by a server (such as the message management system 170 of FIG. 1) that is configured to handle message-related services for one or more computing systems. As a specific and non-limiting example, a server that manages or has access to data records associated with a plurality of user accounts may implement the method 300 for processing messages in connection with the user accounts.

A message management system monitors account activity for one or more user accounts. More particularly, the message management system monitors data record operations for data records associated with user accounts. The user accounts may, in at least some embodiments, be resource accounts storing (or defining) certain quantities of resources across one or more data records. A data record operation may be an operation for creating, accessing, reviewing, modifying, or deleting one or more data records. Examples of data record operations may include user-initiated changes to account or data record settings, transfers of certain quantities of resources, requests for certain quantities of resources, transactions (e.g., credit/debit transactions) in connection with resources of the account or data record, and the like. The message management system may be configured to directly monitor data record operations for data records associated with the user accounts, or obtain data record operations data from another system, such as an account management server. For example, the message management system may request to obtain, from an account management server, account data for one or more resource accounts, such as account balance and historical transactions data.

In operation 302, the message management system detects a trigger condition associated with a data record based on the monitoring of data record operations. In some embodiments, a trigger condition may be detected in real-time, for example, based on continuous monitoring. In particular, a data record operation in connection with a specific data record and a trigger condition associated with the data record may be detected concurrently, or substantially concurrently, by the message management system. For example, the message management system may determine that a detected data record operation causes or results in a defined trigger condition being satisfied.

In some embodiments, a trigger condition may be detected based on automated analysis of account data associated with the user accounts. By way of example, the message management system may identify, based on analysis of historical transactions data, one or more patterns of data record operations (e.g., recurring transactions) in connection with a particular data record. A trigger condition may be detected if the message management system determines that certain historical data record operations for the data record represent an identifiable pattern.

Various different trigger conditions may be defined by the message management system. In some embodiments, the trigger conditions may relate to the type of data record operations. For example, a definition of a trigger condition may identify certain types of data record operations. If the message management system determines that a type of a detected data record operation is one of the identified operations associated with a trigger condition, the message management system may determine that the trigger condition is satisfied. Examples of operation types include, but are not limited to: resource transfers, requests for resources, credit transactions, debit transactions, activation and deactivation of data records, adding or modifying personal information associated with the data record, recurring operations, etc.

In some embodiments, the trigger conditions may relate to certain defined rules in connection with data record operations. By way of example, a definition of a trigger condition may identify a type of data record operation and one or more rules (e.g., thresholds, ranges, etc.) for evaluating the data record operations. If the message management system detects a data record operation of a type identified by a trigger condition, the message management system may determine whether the trigger condition is satisfied based on evaluating the defined rules associated with the trigger condition. For example, if an account balance associated with a data record exceeds or falls below a defined threshold as a result of a particular data record operation, the message management system may determine that a trigger condition is satisfied.

More generally, trigger conditions may be defined in terms of a combination of variables relating to account data for a user account. Account data may include, among others, data record operations history (e.g., historical transactions data), account balance, personalization and preference data, account status, user settings, and the like. In at least some embodiments, the definition of a trigger condition may specify an account data item, one or more variables (e.g., type, range, threshold, etc.) associated with the account data item, and rules concerning the one or more variables. A trigger condition may be detected if the message management system determines that the defined rules associated with the trigger condition are satisfied.

The defined trigger conditions for a data record and/or user account may be stored in memory that is accessible by the message management system. In particular, definitions of one or more trigger conditions may be stored in association with specific data records and/or user accounts.

In response to detecting a trigger condition, the message management system generates a first message object for the data record, in operation 304. The first message object is a data object containing a target message that relates to the data record. In addition to the target message, the first message object may indicate information relating to delivery of the first message object and/or display of the first message object. For example, the first message object may identify a channel for communication by which the first message object is to be delivered to an intended recipient. The channel may, for example, be a specific personal device (e.g., a mobile phone, a tablet computer, a laptop, smart speakers, etc.) that is used for accessing the data record.

The first message object is also associated with one or more defined rules for evaluating the first message object prior to delivery of the first message object to the intended recipient. The first message object may also be associated with one or more defined rules for evaluating the first message object after delivery of the first message object to the intended recipient. As will be explained in greater detail below, the one or more defined rules may be evaluated at a specific point in time by the message management system to determine whether the first message object should be delivered to the intended recipient at that time and/or may be evaluated to determine whether the first message object should be displayed.

In some embodiments, the first message object may include metadata that identifies the one or more defined rules. The metadata for the first message object may indicate, at least, definitions of rules for evaluating the first data object prior to its delivery to a recipient and/or after its delivery to the recipient.

In at least some embodiments, the first message object may be generated by the message management system for delivery to the intended recipient at a point in time that is later than the time of generation of the first message object. That is, the first message object may not be delivered to the intended recipient immediately after it is generated. Instead, the first message object may be delivered at a later opportunity for interaction with the intended recipient. The message management system may generate and automatically store the first message object such that it is ready for delivery to the intended recipient at a future point in time. In particular, the first message object may be stored in memory at a first point in time and delivered to the intended recipient at a second point in time, later than the first point in time, when the intended recipient accesses the data record. By generating message objects in advance for eventual delivery to a recipient, message objects that are highly relevant to the recipient may be identified and delivered in real-time when interaction with the recipient is detected.

In operation 306, the message management system stores the first message object in memory. The first message object is stored in association with a set of one or more message objects for the data record. More specifically, the message management system may maintain a set of message objects that includes one or more message objects containing target messages for delivery to the intended recipient. The set of message objects may be stored in memory, and the first message object may be stored together with the message objects of the set.

The set of message objects may be maintained using any one of various suitable data structures. In at least some embodiments, the message objects of the set may be maintained in a queue associated with the data record. The message objects of the set may be arranged in a particular order in the queue. More generally, the set may be associated with a defined order for the one or more message objects. The order may, for example, be an order of expected delivery of the message objects. For example, the order may define, for each of the one or more message objects of the set, a delivery priority associated with the message object. The message management system may deliver message objects of the first according to their assigned order (for example, in the queue).

As message objects are generated and stored in memory, the message management system continues to monitor data record operations associated with the data record. In particular, the message management system monitors access operations for accessing the data record. In operation 308, the message management system detects a data record operation. For example, the message management system may determine that a user has initiated an authenticated session to access the data record using a personal computing device or a data terminal equipment. Determining that the user has initiated the authenticated session may require determining that the user has logged in using, for example, a username and password. Other user actions, such as booting up or powering on of a device (e.g., smart speakers), input of data, navigation of a user interface, and the like, in connection with the data record may be identified as data record operations. The message management system may itself detect user actions associated with the data record or, alternatively, it may be notified of user actions by another computing system, such as an account management server.

In operation 310, the message management system retrieves, from the memory, at least one message object of the first set. The message management system selects one of the message objects of the first set and retrieves the selected message object from the memory. The selected message object may include metadata indicating a particular access channel as a compatible channel. The message management system may select a message object that can be delivered via the access channel when user interaction (e.g., a data record operation) is detected on the access channel.

In operation 312, the message management system causes the at least one message object to be delivered to the recipient entity. In some embodiments, the at least one message object may be formatted for delivery (e.g., display, playback, etc.) by the message management system. The formatted message object may then be transmitted to a suitable device/system for the intended recipient to access the message object. The message object selected for delivery may take various formats such as a reminder, an alert, an offer (e.g., a product or service offer), and the like. Alternatively, the selected message object may be transmitted to a device/system as-is, and the formatting of the message object may be performed on the client side.

Reference is made to FIG. 4, which shows, in flowchart form, an example method 400 for managing a queue of message objects for transmission to a recipient entity. The operations of method 400 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 400 may be implemented by a server (such as the message management system 170 of FIG. 1) that handles message-related services for one or more computing systems.

The operations of method 400 may be performed as part of, or in addition to, method 300 of FIG. 3. In particular, the operations of method 400 may be included as part of a process for managing a queue of message objects that are generated by a message management system based on automated analysis of account data for a user account.

In operation 402, the message management system determines a time of intended delivery for a message object. When a message object is generated based on automated analysis of account data, it may include a data field for identifying when delivery of the message object to a recipient is intended. The data field may be included with, for example, the metadata of the message object. For example, the message object may indicate a specific date and time when the message object is to be delivered. Alternatively, the message object may define one or more rules (e.g., deliver at the next opportunity for user interaction, deliver before a certain defined event, etc.) concerning delivery of the message object to the intended recipient, and not a specific time. In at least some embodiments, message objects may include timestamps that indicate when the message objects were generated by the message management system. The time stamp may be included with, for example, the metadata of the message object. In particular, each message object may have an associated timestamp comprising date and time information. In this way, the message objects that are stored (e.g., in a queue) for subsequent delivery to the intended recipient may be ordered chronologically based on timestamp information.

In operation 404, the message management system obtains historical account access data for the user account. The historical account access data includes data relating to access operations for one or more data records associated with the user account. For example, the historical account access data may indicate frequency, times, and type of access operation for each of the data records associated with the user account. The historical account access data may represent a user's interest level in connection with the data records. This interest level may, in turn, have a high correlation to the user's preference for receiving messages that relate to the respective data records. In particular, the historical account access data may affect which message objects are generated or added to the queue of message objects for the user account, and it may affect an ordering of message objects in the queue.

In operation 406, the message management system assigns, to each message object, a priority for the message object based on, at least, timestamp information, time of intended delivery, and the historical account access data associated with the message object. In some embodiments, the priority for message objects may be determined based on a weighted average of the factors of timestamp, intended delivery time, and historical account access data. That is, each of the factors may be assigned a weight representing the factor's importance in deriving the priority for a message object. The priority for a message object may be represented as, for example, a numerical value (i.e., a value within a range), a rank, or the like, such that direct comparison of the priorities of message objects can be conducted by the message management system.

In operation 408, the message objects that are generated by the message management system are added to the queue of message objects associated with the user account in accordance with the respective assigned priority. In particular, the order in which the message objects are arranged in the queue may be determined based on the respective priorities associated with the message objects. For example, a message object having a high priority (i.e., high relative priority value) may be arranged to be closer to the front of the queue than another message object having a lower priority. The order of the queue may be significant, as the selection of message objects for delivery to the intended recipient may proceed according to the queue order. Message objects may be selected, for example, on a first-in-first-out (FIFO) basis from the queue and processed.

In some embodiments, the message management system may remove or determine not to add to the queue those message objects having low priority. For example, a threshold priority level may be defined, and any message objects having a priority value that is lower than the threshold level may be removed from the queue (or not added to the queue at all).

Reference is made to FIG. 5, which shows, in flowchart form, an example method 500 for managing a queue of message objects based on user interaction. The operations of method 500 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 500 may be implemented by a server (such as the message management system 170 of FIG. 1) that handles message-related services for one or more computing systems.

The operations of method 500 may be performed as part of, or in addition to, method 300 of FIG. 3. In particular, the operations of method 500 may be included as part of a process for managing a queue of message objects that are generated by a message management system based on automated analysis of account data for a user account.

In operation 502, the message management system detects a message object handling action by a recipient entity. A message object handling action is an action that is performed by the recipient when presented with a message object. Typically, a recipient may dismiss message objects that are not of interest and interact with those message objects that are of interest. For example, if a message object, such as a notification, offer, announcement, alert, etc., is presented to a recipient, the recipient may perform an action to either dismiss the message object (e.g., closing a pop-up window, muting future alerts, or the like) or initiate a certain task (e.g., opening an app, generating a suitable response, etc.) in connection with the message object. A dismiss action with respect to a message object may be taken as an indicator that the recipient is not interested in the target message associated with the message object. On the other hand, a user action for engaging with a message object may be taken as an indicator that the recipient is interested in the target message associated with the message object.

A message object handling action by the intended recipient may thus have implications for the generation and/or management of message objects. In operation 504, the message management system identifies message objects of the queue to update based on the detected message object handling action. In at least some embodiments, the message management system may identify the message object (“first message object”) that is directly affected by the message object handling action and determine one or more message objects of the queue that are related to the first message object. A message object may provide relationship data indicating its relationship to one or more other message objects. For example, a message object may include metadata identifying one or more related message objects.

In operation 506, the message management system updates or removes the identified message objects from the queue. For example, if the detected handling action is a dismiss action of a message object, the related message objects may be removed from the queue to avoid presenting the recipient with duplicate information. Alternatively, one or more of the related message objects may be updated based on the detected handling action. For example, if the recipient takes an action to indicate that they want to be presented with the target message again (e.g., a reminder), the time of intended delivery associated with one or more of the related message objects may be updated to reflect a time selected by the recipient. As another example, the delivery priorities for the related message objects may be updated. That is, the priorities assigned to each of the related message objects may be modified based on the detected handling action.

In some embodiments, delivery of a message object may itself cause the related message objects in the queue to be updated. For example, upon detecting that one of the message objects of the queue is delivered to the intended recipient, the message management system may identify the related messages (e.g., based on metadata for the message object) and modify a delivery priority associated with each of the identified related message objects. The priorities of the related message objects may, for example, be lowered to reflect that the target message has already been delivered once to the intended recipient.

Reference is made to FIG. 6, which shows, in flowchart form, an example method 600 for configuring a message object for transmission to a recipient entity. The operations of method 600 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 600 may be implemented by a server (such as the message management system 170 of FIG. 1) that is configured to handle message-related services for one or more computing systems.

The operations of method 600 may be performed as part of, or in addition to, method 300 of FIG. 3. In particular, the operations of method 600 may be included as part of a process for managing a queue of message objects that are generated by a message management system based on automated analysis of account data for a user account.

As described above, the message management system may generate message objects that are pre-populated with target messages. The message objects are generated some time prior to actual delivery to the intended recipient and stored in memory. For example, the message objects may be added to a queue associated with the user account. Certain data that is intended for presentation in the message object may change after the message object is added to the queue.

In particular, change in data associated with a message object prior to delivery to the intended recipient may render the message object irrelevant or not suitable (e.g., information in the target message is incorrect).

In at least some embodiments, message objects may be evaluated against one or more display rules prior to delivery to the intended recipient. The display rules may include pre-delivery display rules and post-delivery display rules. The pre-delivery display rules may include a rule that is to be evaluated in real-time to determine whether the message object should be delivered, or whether another message object of the queue should be selected for delivery. The post-delivery display rules may include a rule that is to be evaluated in real-time to determine whether the delivered message object should be displayed. It will be appreciated that the operations of method 600 are performed prior to delivery and as such the pre-delivery display rules are evaluated.

In operation 602, the message management system identifies display rules for a message object. In some embodiments, the display rules for a message object may be determined when the message object is first generated, and the display rules may be stored in association with the message object. For example, a message object may include metadata that includes definition of one or more display rules.

In operation 604, the message management system determines whether the account data for the user account satisfies the one or more display rules associated with the message object. In particular, the message management system may identify variables associated with the relevant display rules and obtain, in real-time, values of the identified variables based on the account data. The display rules may then be evaluated using real-time account data information, and the message management system can determine the suitability of delivering the message object to the intended recipient based on the evaluation.

If the display rules are determined to be satisfied, the message management system identifies variable data fields associated with the message object, in operation 608. The variable data fields may be data fields that are intentionally unfilled or that are subject to be changed in real-time prior to delivery of the message object. In some embodiments, the target message of a message object may include text that is tagged with a variable. For example, the text may include a variable identifier to indicate where a variable is being used. The variable informs the message management system that real-time account data should be obtained and used to replace the variable in the target message prior to delivery of the message object.

In operation 610, the message management system determines current values of the variables based on the account data, and in operation 612, the message management system updates the message object based on the current values of the variables. In particular, the current values of the variables may be used to replace information in the target message associated with the message object.

If, on the other hand, the display rules are determined to be not satisfied, the message management system determines whether to update or remove the message object from the queue, in operation 606. For example, a message object whose display rules are not satisfied at the time of expected delivery may be removed from the queue or modified to indicate that the message object is not currently relevant based on the account data for the user account (e.g., assigning a lower priority to the message object).

As described above, the message management system may cause at least one message object to be delivered to the recipient entity. For example, in operation 312 described herein, the message management system sends at least one message object to the recipient entity. The recipient entity may receive the at least one message object and may perform real-time message display decisioning to determine whether or not to display the at least one message object.

Reference is made to FIG. 7 which shows, in flowchart form, an example method 700 of real-time display decisioning. The operations of method 700 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 700 may be implemented on the client side by a client device (such as client device 110 of FIG. 1).

In operation 710, the client device authenticates a session associated with a data record. In this embodiment, the client device authenticates the session by receiving input of authentication credentials. The client device sends the authentication credentials to the message management system where the authentication credentials are analyzed to ensure the authentication credentials are valid and to identify the data record.

Responsive to authenticating the session associated with the data record, the client device displays a graphical user interface that includes one or more elements. The one or more elements may include display data and/or message objects associated with the data record. For example, the one or more elements may display data such as an account balance, account name, account status, account transaction types, transaction amounts, merchant category codes of transactions, types of accounts, a number of accounts, customer holdings within accounts, account trade counts, account settings, etc. The message objects such as recommendations, notifications, etc. associated with displayed data.

The data and message objects may be generated by one or more systems and the one or more systems may be external to the message management system. For example, the account balance displayed on the graphical user interface may be provided by the resource server 150 (FIG. 1) which is a system that is external to the message management system 170. It will be appreciated that the one or more systems that are external to the message management system may include external systems that are associated with the same financial institution as the message management system or may be external systems that are associated with a third party.

The graphical user interface may display multiple elements generated by multiple systems. For example, the graphical user interface may display a first and a second element generated by a first external system and may display a third element generated by a second external system.

In operation 720, the client device receives, from a server, a first message object.

In this embodiment, the first message object is sent from the message management system. For example, at operation 312 described herein, the message management system sends at least one message object to the client device. In this embodiment, the at least one message object is the first message object.

As mentioned, the first message object may indicate information relating to delivery or display of the first message object. For example, the first message object may include metadata identifying one or more display rules associated with the first message object.

In operation 730, the client device analyzes metadata of the first message object to identify one or more display rules associated with the first message object.

The one or more display rules include post-delivery display rules that relate to the display of the first message object on the client device. In this embodiment, the one or more display rules define criteria that indicate whether or not the first message object is to be displayed on the client device.

In one or more embodiments, the display rules may be associated with ensuring that the first message object does not contradict information presented by the one or more elements displayed on the user interface. For example, one or more display rules may define criteria related to “saving”. As such, if one or more of the elements displayed on the user interface are related to “spending” then it may be determined that the criteria is not satisfied, as “saving” and “spending” are contradictory to one another.

In one or more embodiments, the display rules may be associated with ensuring that the first message object does not repeat information or does not present redundant information with respect to information presented by the one or more elements displayed on the user interface. For example, one or more display rules may define criteria related to “receiving electronic statements” (as opposed to receiving physical statements printed on paper). As such, if one or more of the elements displayed on the user interface indicate that the user has requested that they receive their statements electronically then it may be determined that the criteria is not satisfied as displaying information related to receiving electronic statements would be redundant.

In one or more embodiment, when it is determined that the criteria is not satisfied as displaying the message of the message object would be redundance, the client device may send a signal to the message management system. The signal may cause the message management system to perform one or more operations to update the data record. For example, based on the one or more elements displayed (which may be from one or more external systems) it may be determined that the user has requested that they receive their electronic statements electronically. As such, the message management system may update one or more settings associated with the data record to indicate that the user would like to receive their statements electronically and this may be done automatically without any input from the user.

In one or more embodiments, the display rules may be associated with ensuring that a displayed account balance is less than a threshold. For example, the display rules may define that the first message object should be displayed only if the displayed account balance is less than $5000. As such, if one or more of the elements displayed on the user interface displays an account balance that is less than $5000 it may be determined that the criteria is satisfied.

In operation 740, the client device determines, based on one or more elements displayed on a user interface associated with the authenticated session, that the one or more elements satisfy the one or more display rules.

In operation 750, responsive to determining that the one or more elements satisfy the one or more display rules, the client device displays the first message object on the user interface associated with the authenticated session. The first message object may be displayed such that the target message is displayed.

In this embodiment, when it is determined that the one or more elements satisfy the one or more display rules, the client device displays the target message of the first message object on the display screen thereof. For example, the first message object may be a notification and as such the target message may be displayed such that it overlays a portion of the user interface currently being displayed on the display screen. As another example, the target message of the first message object may be displayed as an element on the user interface.

In one or more embodiments, the target message of the first message object may include one or more selectable options. For example, the target message may indicate “Do you want to move $500 from your chequing account to your savings account?” and may include a selectable option that, when selected, indicates that the user would like to move $500 from their chequing account to their savings account. Responsive to selection of the selectable option, the client device may send a signal indicating selection of the selectable option to the message management system where it may be processed and sent to the resource server. The resource server may then perform operations to transfer $500 from the chequing account to the savings account.

Reference is made to FIG. 8 which shows, in flowchart form, another example method 800 of real-time display decisioning. The operations of method 800 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 800 may be implemented on the client side by a client device (such as client device 110 of FIG. 1).

In operation 810, the client device authenticates a session associated with a data record. Operation 810 is generally identical to operation 710 described herein.

In operation 820, the client device receives, from a server, a second message object.

In this embodiment, the second message object is sent from the message management system. For example, at operation 312 described herein, the message management system sends at least one message object to the client device. In this embodiment, the at least one message object is the second message object.

As mentioned, the second message object may indicate information relating to delivery or display of the second message object. For example, the second message object may include metadata identifying one or more display rules associated with the second message object.

In operation 830, the client device analyzes metadata of the second message object to identify one or more display rules associated with the second message object.

The metadata of the second message object is analyzed in a manner similar to that described herein with reference to operation 730.

In operation 840, the client device determines, based on one or more elements displayed on a user interface associated with the authenticated session, that the one or more elements do not satisfy the one or more display rules.

In this embodiment, the client device inspects the one or more elements displayed on the user interface to determine whether or not the elements satisfy the one or more display rules. For example, the client device may analyze a particular element displayed on the user interface and determine that the particular element is a message indicating that the user has excess funds and requesting that the user transfer the excess funds from a chequing account to a savings account. The one or more display rules may indicate that the first message object relates to indicating that the funds of the account are going to be deficient for upcoming bill payments and requesting that the user transfer funds from the savings account to the chequing account. As such, the client device may determine that the one or more elements do not satisfy the display rules. Put another way, by analyzing the metadata of the second message object it may be determined that displaying the second message object would cause the graphical user interface to display elements that are inconsistent with one another. Since this is likely to confuse the user, the client device may decide that the second message object is not to be displayed.

In operation 850, responsive to determining that the one or more elements do not satisfy the one or more display rules, the client device cancels the second message object.

In this embodiment, when it is determined that the one or more elements do not satisfy the one or more display rules, the client device cancels the second message object. To cancel the second message object, the client device may simply remove the second message object and thus the second message object is not displayed on the client device. In one or more embodiments, the client device may send a signal to the message management system 170 indicating that the second message object does not satisfy the one or more display rules and/or indicating that the second message object is to be removed from a set of message objects.

The operations of methods 700 and 800 described herein are performed by the client device to make a determination as to whether the received message object should be displayed. Since the message objects include metadata identifying one or more display rules associated with therewith, the client device is able to inspect one or more elements currently being displayed on the user interface to make a real-time or near real-time decision as to whether or not to display the message object. Further, since the one or more elements displayed on the user interface may be associated with one or more external systems, the client device is able to obtain real-time or near real-time data without sending separate signals requesting data from the one or more external systems. As a result, the reliance on computing and network resources is reduced.

The real-time or near real-time data may further be used by the client device to update one or more data fields of the message object prior to displaying the message object on the user interface. Reference is made to FIG. 9 which shows, in flowchart form, an example method 900 of updating one or more data fields of a message object prior to displaying the message object. The operations of method 900 may be performed by one or more processors of a computing system such as, for example, the processor 200 (FIG. 2A) of a suitably configured instance of the example computing device 105 (FIG. 2A). In at least some embodiments, the method 900 may be implemented on the client side by a client device (such as client device 110 of FIG. 1).

The operations of method 900 may be performed as part of, or in addition to, method 700 of FIG. 7. In particular, the operations of method 900 may be included as part of a method for real-time message display decisioning. For example, the operations of method 900 may be performed responsive to determining that the one or more elements satisfy the one or more display rules and prior to displaying the message object on the user interface.

In operation 910, the client device identifies one or more data fields to be updated prior to displaying the message object on the user interface (operation 910). In this embodiment, the message object may be the first message object.

The client device may analyze the metadata to identify the one or more data fields to be updated. The data fields may be data fields that are intentionally unfilled or that are subject to be changed or updated in real-time prior to display of the message object. In some embodiments, the target message of a message object may include text that is tagged with a variable. For example, the text may include a variable identifier to indicate where a variable is being used. The variable identifier informs the client device that real-time data should be obtained from one or more elements being displayed on the user interface and used to replace the variable prior to display of the message object.

In operation 920, the client device determines current values from the one or more elements displayed on the user interface and in operation 930, the client device updates the message object based on the current values of the variables. In particular, the current values of the variables may be used to replace information in the target message associated with the message object.

In operation 940, the client device displays the updated target message of the first message object. The target message may be displayed in a manner similar to that of operation 750 of method 700.

By obtaining current values of the variables from the one or more elements displayed on the user interface, real-time or near real-time data is obtained by the client device to update the message object prior to display. In this manner, the client device is able to obtain and update the target message of the message object using real-time or near real-time data without sending separate signals requesting data from the one or more external systems. As a result, the reliance on computing and network resources is reduced.

The various embodiments presented above are merely examples and are in no way meant to limit the scope of this application. Variations of the innovations described herein will be apparent to persons of ordinary skill in the art, such variations being within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments including a sub-combination of features which may not be explicitly described above. In addition, features from one or more of the above-described example embodiments may be selected and combined to create alternative example embodiments including a combination of features which may not be explicitly described above. Features suitable for such combinations and sub-combinations would be readily apparent to persons skilled in the art upon review of the present application as a whole. The subject matter described herein and in the recited claims intends to cover and embrace all suitable changes in technology.

SYSTEM AND METHOD FOR REAL-TIME MESSAGE DISPLAY DECISIONING

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims