Patent Application
20140032709
1. Field of the Invention
The present invention generally relates to delivering information to a mobile platform. More particularly, to systems, methods, and computer program products for sending information to a mobile device.
2. Related Art
Mobile devices, e.g. mobile phones and tablets, have become multidimensional tools capable of accomplishing a variety of tasks. No longer confined to merely making and receiving phone calls, mobile devices are capable of accessing email, the Internet, and remote networks. Recent advances in mobile devices have now allowed consumers to turn to their mobile devices to make purchases, resulting in a burgeoning mobile commerce environment.
In a mobile commerce environment, a user can use their mobile device to browse, compare, buy, and review products and services. Despite the rise of mobile commerce, merchants are constantly seeking new ways to reach current and potential customers. Still today, typical merchant environments are only equipped to reach out to customers by sending them coupons, specials, and advertisements by email. These methods, however, are out of place in mobile commerce.
Merchants using existing means of electronic communication, such as electronic mail (email), short message service (SMS), or Twitter messages (tweets), have several drawbacks. A traditional email system is designed to retain emails indefinitely, thus, necessitating the active involvement of the recipient. If the recipient does not actively manage their inbox by periodically “cleaning out” unwanted emails, then the number of unwanted emails can quickly overwhelm the inbox. The tediousness of this task is one reason the public has a developed a negative opinion of emails which are solely for the purposes of solicitation or advertisement, now commonly referred to as “junk” emails or “spam.” Many email service providers have developed complex algorithms which filter incoming emails to eliminate those which are solicitations and/or advertisements. Thus, from a merchant's point of view, email is sometimes seen as an unreliable system for communicating with current and potential customers, since the emails may in fact never reach the customer or be summarily deleted.
Furthermore, the proliferation of viruses and malware embedded in emails have made the public wary of opening an email from an untrusted source, further increasing the likelihood that the email will not be read. Still further, distributing information via email requires the merchant to maintain large databases of users, which must be constantly updated with acquired or purchased information, increasing the cost of engaging the consumer.
Since merchant emails are likely to go unread, there is a tendency to place as much information as possible into an email, in the hope that if it is read, the customer may act on one of the inducements, thereby generating a return on the investment in advertising. This strategy, however, can backfire as the customer suffers an “information overload” and chooses instead to delete the email. While SMS messages and Tweets limit the amount of information presented to the customer, these limitations also restrict the ability of the merchant to communicate with the customer.
The present invention provides apparatuses, methods, and computer readable mediums for receiving a feed message from an external party system.
In one embodiment, an apparatus is constructed to receive a feed message from an external party system. The apparatus includes a memory, and a communication unit configured to receive at least one feed message from a mobile network. The at least one feed message includes message content provided by an external party system and one or more sets of instructions. The apparatus also includes a processor configured to: cause a display unit, which can receive one or more input commands, to display the message content, generate a plurality of message acknowledgments, including any one of: (i) a received message acknowledgment when the at least one feed message is received by the communication unit, (ii) a viewed message acknowledgment when the message content is displayed on the display unit, and (iii) an operated message acknowledgment when the one or more sets of instructions are executed in accordance with the one or more input commands received by the display unit, or a combination thereof, and store one or more of the plurality of message acknowledgments in the memory. The processor is further configured to synchronize with a remote server and transmit to the remote server the one or more message acknowledgments stored in the memory.
In another embodiment, a method of receiving a feed message and transmitting information related thereto. The method includes receiving, generating, storing, and transmitting steps. In the receiving step, at least one feed message from a mobile network is received, wherein the at least one feed message includes message content provided by an external party system and one or more sets of instructions. One or more message acknowledgments are generated, in the generating step, including any one of: a received message acknowledgment when the at least one feed message is received, a viewed message acknowledgment when the message content is displayed, and an operated message acknowledgment when the one or more sets of instructions are executed in accordance with one or more received input commands, or a combination thereof. The one or more message acknowledgments are stored in a memory in the storing step, and transmitted to a remote server in the transmitting step.
In yet another embodiment, a non-transitory computer readable storage medium stores a computer program for causing a computer to execute a method of receiving a feed message and transmitting information related thereto. The method comprises receiving, generating, storing and transmitting steps. In the receiving step, at least one feed message from a mobile network is received, wherein the at least one feed message includes message content provided by an external party system and one or more sets of instructions. One or more message acknowledgments are generated, in the generating step, including any one of: a received message acknowledgment when the at least one feed message is received, a viewed message acknowledgment when the message content is displayed, and an operated message acknowledgment when the one or more sets of instructions are executed in accordance with one or more received input commands, or a combination thereof. The one or more message acknowledgments are stored in a memory in storing step, and transmitted to a remote server in the transmitting step.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings.
As shown in
The mobile wallet 124 allows a user to conduct transactions using the mobile device 102. These transactions may be, for example, contactless transactions at a point of sale (POS) (or “check-out”) terminal. To facilitate these transactions, the mobile device 102 is configured to store various pieces of information including digital instruments such as, for example, credit, offer, and loyalty card information. This information may be stored in the secure element 210, which is provided with security measures to prevent unauthorized access of the user's information, such as data encryption. The user may interact with the mobile wallet 124 via the input unit or the display unit 208, as described above.
The CLF 212 allows the mobile device 102 to communicate with nearby devices, such as a Near Field Communications (NFC) chip or a contactless reader, without physically connecting to the device via, e.g., a wire. The mobile wallet 124 controls the operation of the mobile device hardware, including the CLF 212, the secure element 210 and the communication unit 206 in order to conduct the contactless transactions. To execute a transaction, a user simply has to bring the mobile device 102 within range of the object to which communication is desired (not shown) so that the CLF 212, the secure element 210, and the communication unit 206 may operate to effectuate the transaction. The mobile device 102 may communicate using the International Standards Organization (ISO) 7816 commands and NFC ISO 14443 protocol.
The communication unit 206 allows the mobile device 102 to wirelessly connect to an external object or device. The communication unit 206 may be configured to connect to a wireless local area network (WLAN), e.g. a WLAN based on, for example, the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, i.e. “Wi-Fi,” or other types of communication networks such as a cellular data network or mobile satellite communications. With respect to the latter two categories, the specific type of wireless communication network may be dictated by the type of network the MNO 114 operates. In that regard, the communication unit 206 may contain one module, or radio, to communicate over one or more communication networks, or include multiple modules which communicate over multiple communication networks. In addition, the mobile device 102 may be configured to include a wired communication unit, e.g. an Ethernet unit, which allows the mobile device 102 to communicate with external devices. The wired communication unit is communicatively connected to an auxiliary input such as, for example, a Universal Serial Bus (USB) connection, mini-USB connection, micro-USB connection, Firewire connection, Lightning connection, or the like.
The memory 204 may store one or more applets, applications, or commerce widgets (collectively referred to as “commerce widgets” hereinafter), which are program instructions for executing one or more operations associated with a service provider. A commerce widget may be associated with one or more digital instruments (e.g., a credit card, payment/loyalty card, coupon, and/or offers) stored in the memory 204 or the secure element 210, and used by the mobile wallet 102 to execute corresponding transactions or enable a user to interact in a manner provided by the service provider. If a commerce widget is stored on the secure element 210, then the mobile wallet 102 is configured to communicate with the secure element 210 to access and use the commerce widgets stored therein. The memory 204 stores feed messages received from the wallet server 106. As will be discussed further below, the feed messages are tied to the mobile wallet 124 and are displayed therein. Therefore, to a user of the mobile device 102 the received feed messages appear stored in the mobile wallet 124. The feed messages can, therefore, be considered to be delivered to the mobile wallet 124 and stored therein.
As noted above, the mobile device 102 communicates with the wallet platform 104. The wallet platform 104 includes the wallet server 106 which is external to the mobile device 102 and constructed to manage the mobile wallet 124. The wallet server 106 includes a processor 302, memory 304, and a communication unit 306. The wallet server memory 304 contains program instructions which, when executed by the processor 302, cause the wallet server 106 to perform the functions described herein. The wallet server 106 can modify the contents of the mobile wallet 124 and can also add additional commerce widgets to the mobile device 102. The wallet server 106 also functions to handle communications between the mobile device 102 and external parties, such as the service provider systems 114, 116, and 118 shown in
As will be discussed in further detail below, the wallet server 106 also stores feed messages from the service provider systems 114, 116, and 118 prior to delivering the feed messages to the mobile wallet 124. The wallet server 106 may also be accessed by a user via the Internet 122, thereby allowing the user to read, interact with, or delete feed messages which are awaiting delivery to their mobile wallet 124. The wallet server 106 also tracks the state of the feed message on the mobile wallet 124.
The ESB 112 systems manage interactions between external parties, such as the service provider systems 114, 116, and 118, and the mobile device 102, and provides the service provider systems 114, 116, and 118 a mechanism to efficiently and securely communicate with the mobile device 102, without the need to directly connect to it. Thus, in a system where a plurality of mobile devices are present and desired to be communicated with, the ESB 112 provides an efficient portal for the service provider. As noted above,
As noted above, the wallet server 106 includes a memory 304 which is configured to store a plurality of databases which respectively store entries corresponding to: each message source which participates in the feed messaging system 100 (wallet server message source database 308), messages generated by the message sources (wallet server message database 310), message subscriptions corresponding to the mobile wallet 124 (wallet server message subscription database 312), and message states of feed messages destined for the mobile wallet 124 (wallet server message state database 314). The memory 304 also stores an Application Program Interface (API) module 316.
The wallet server message source database 308 stores a plurality of entries corresponding to each message source which participates in the feed messaging system 100. As shown in Table 1 below, each entry in the wallet server message source database 308 is a table comprised of a plurality of fields which serve to identify the message source. Each of these fields will be discussed in detail below.
When a new message source is added to the feed messaging system 100, the feed messaging system 100 automatically assigns the message source a message source ID T100. Once a message source is added to the wallet server message source database 308, the message source takes on a status of active or discontinued in accordance with instructions provided by the service provider system 114, 116, and 118. The service provider system 114, 116, and 118 may have a plurality of message sources stored in the wallet server message source database 308 with some being active while others are inactive. Thus, the service provider systems 114, 116, and 118 may communicate with the wallet server 106 via the web portal 126 to change the status of a given message source from active to discontinued, or vice versa.
The “Message Source Type” field T104 denotes the type of message source, i.e., whether the source of the messages is a merchant, issuer, MNO, or the feed messaging system 100. The “Message Source Nature” field T106 stores a value indicating whether the message source is categorized as mandatory, default, or optional. Mandatory message sources are automatically subscribed to when the mobile wallet 124 is activated, and cannot later be unsubscribed from. Default message sources are also automatically subscribed to when the mobile wallet 124 is activated, but may later be unsubscribed to by the user. Optional message sources are not automatically subscribed from when the mobile wallet 124 is activated, but may be subscribed to, as discussed below, at a later time by the user. The “Message Source Name” field T108 stores a value which identifies the service provider 114, 116, and/or 118 associated with the message source. For example, if the message source is associated with a bank named “Acme Federal Credit Union” then this field would be populated with “Acme Federal Credit Union.” The “Message Source Description” field T110 provides a description of the message source, or the service provider to which it is associated. The “Full Logo” field T112 is populated with a full size image associated with the message source and is displayed with an “activity log” type feed message. The “Partial Logo” field T114 is populated with a smaller image of the logo associated with the message source and is displayed when the feed message type is a notification or an offer, as will be discussed below.
Once the mobile wallet 124 is activated on the feed messaging system 100, the user may subscribe to various message sources provided by the service provider systems 114, 116, and 118. When the user of the mobile wallet 124 subscribes to a message source, the subscription is recorded in the wallet server message subscription database 312. As shown in Table 2 below, each entry in the wallet server message subscription database 312 is a table with a plurality of fields.
The “Message Subscription ID” field T200 is a unique identification generated by the feed messaging system 100 once the message subscription is generated. The “Message Subscription Status” field T202 indicates whether the subscription is presently active or discontinued. While a user may unsubscribe from default and optional message sources at any time, the wallet server 106 maintains a record of those message subscriptions in the wallet server message subscription database 312. As will be discussed below, this information is relevant to a consumer profile of the user. The “Message Source Name” field T204 is populated with the name of the entity associated with the message source. Like above, if the message source for a given message subscription is “Acme Federal Credit Union,” this field would be populated with “Acme Federal Credit Union.” The “Wallet ID” field T208 is populated with the specific identification assigned to the mobile wallet 124 when the mobile wallet 124 is activated. The “Creation Time Stamp Field” field T210 is populated with the date (and optionally the time) on which the message subscription is generated. The “Discontinue Time Stamp” field T212 is populated with the date (and optionally the time) on which the message subscription is cancelled. Of course, if the message subscription is not discontinued, then this field would remain unpopulated.
As described above, the feed messaging system 100 is designed to deliver feed messages to the mobile wallet 124. A feed message is a communication from an external party to the user via the mobile wallet 124. The feed message contains text information, but may also contain images and program code as well. The feed message may be a notification, an offer, or activity log. In general, a notification is distinguished from an offer or an activity log, because it contains information of an event external to the operation of the feed messaging system 100 which is not an offer to purchase an item. As an example, a notification feed message may be a notice of a balance in a checking account. An offer is an inducement to the user to engage in commerce, e.g., a coupon for the purchase of an item. An activity log message notifies the user of an activity related to the mobile wallet 124, e.g. notification that a purchase has been completed.
When a service provider system 114, 116, or 118 calls an API to create a feed message, a corresponding feed message is generated in the wallet server 106 in accordance with the information provided thereto, and stored in the wallet server message database 310. As shown in Table 3, each entry in the wallet server message database 310 is a table comprising a plurality of fields populated with corresponding values that comprise the feed message.
As shown in Table 3, each feed message is assigned a unique message ID T300 by the feed message system 100 when generated. The “Message Status” field T302 indicates whether the feed message is presently active, discontinued, or expired. As noted above, the feed message can be an offer, which the service provider can discontinue or set to expire after a certain period of time. If the service provider chooses an expiration time, then that value is entered into the “Expiration Time Stamp” field T316. To discontinue the offer the service provider system 114, 116, and 118 may use the web portal 126 and the ESB 112 interacts with the wallet server 106 and the changes the value in the “Message Status” field to discontinued. As previously discussed, the feed message may correspond to a notification, offer, or an activity log, and the value in the “Message Type” field T304 is entered accordingly. The name of the message source (or service provider who sent the message) is entered in the “Message Source Name” field T306. The “Message Source ID” field T308 is populated by a value corresponding to the message source's ID on the feed messaging system 100. The “Message External Reference ID” field T310 allows for the service provider sending the feed message to provide a reference identification value for their internal system.
The “Message Body” field T312 is where the body of the message that is being sent is entered. The body is typically a block of text written and entered by the service provider corresponding to the message source. The maximum length of a string of characters and spaces which can be entered in the “Message Body” field is predetermined by the feed messaging system administrator. While the maximum string length could be any number, in one embodiment the maximum is set to 134. One of the advantages of limiting the string length to 134 characters, is that the user is not overwhelmed by the amount of information being presented. As a result, there is a greater likelihood that the feed message will be read, and possibly acted upon.
A service provider may choose to have its feed message delivered immediately, or the service provider can designate a certain time for the feed message to be delivered by entering an appropriate value in the “Scheduled Delivery Time Stamp” field T318. This allows the service provider to create and store a feed message on the wallet server 106 at a convenient time, and then have the message delivered at a later time.
In one embodiment, the mobile device 102 performs a wide array of functions including, for example, making a telephone call, opening a commerce widget stored in the secure element 210 or the memory 204, or opening a web browser and loading a webpage. The “Message Logo Action ID” T320 field is populated with an action ID corresponding to a desired action. For example, if the service provider system 114, 116, and 118 would like a commerce widget stored on the mobile device 102 to be opened and run when the body of the message is clicked, this field is populated with the value “Load Commerce Widget.” If the service provider would like the mobile device 102 to dial a specific telephone number or open a web browser and load a specific webpage, the field is populated with the values “Call Number” and “Open Link,” respectively.
Of course, each of these actions requires specific programming for their respective executions. Accordingly, the “Body Action Parameter” field T326 is populated with the specific set of instructions or parameters which, when executed by the processor 102 in conjunction with the memory 204, cause the corresponding action identified in the “Body Action ID” field T324 to be performed. The service provider system 114, 116, and 118 provides these parameters or instructions when the feed message is generated.
The service provider system 114, 116, and 118 may also configure the feed message to display a full or partial logo, which corresponds to the service provider, when the message is displayed on the display unit 208 of the mobile device 102. Whether a full logo or a partial logo is displayed may be set corresponding to the type of message. For example, if the value in the “Message Type” field T304 is “Activity Log,” then a full logo is displayed, as opposed to a partial logo if the value in the “Message Type” T304 field is either “Offer” or “Notification.”
The wallet server 106 also includes a Mobile Wallet Message State database 314 which tracks the relationship between the mobile wallet 124 and the feed message. As shown in Table 4, each entry in the Mobile Wallet Message State 314 database is a table comprising a plurality of fields.
The “Wallet Message State ID” field T400 is populated with a value that is automatically generated by the wallet server 106 once the feed message is delivered to the mobile device 102. The “Message External Reference ID” field 410 is populated with the service provider's message ID of the feed message that is delivered to the mobile device 102, i.e., the value in the Message External Reference ID field T310 in the Wallet Server Message Database Table (Table 3). The “Message Status” field T420 indicates the status of the feed message on the mobile device 102. There are four possible values for this field: sent for delivery, delivered, viewed, and operated. Sent for delivery means that the feed message has been sent from the wallet server 106 to the mobile device 102, but the wallet server 106 has not yet received confirmation that the feed message has been delivered. Upon receiving such confirmation, this value is changed to “delivered.” If and when the user elects to view the feed message, the value is changed from “delivered” to “viewed,” when the mobile device 102 next synchronizes with the wallet server 106. If the user elects to execute an action contained within the feed message, such as the “Body Action,” then this value is changed from “viewed” to “operated” when the mobile device 102 next synchronizes with the wallet server 106. Time stamps corresponding to when the feed message is delivered, viewed (if at all), and operated (if at all), are stored in the respective “Delivery Time Stamp” field T440, “View Time Stamp” T450, and “Operation Time Stamp” field T460.
The mobile device 102 on which the mobile wallet 124 operates is also configured to include a plurality of databases in the secure element 210 or in the memory 204, including a Mobile Wallet Message Source Database and a Mobile Wallet Message Database. Each entry in the Mobile Wallet Message Source Database is a table with a plurality of entries as shown and described below in Table 5.
The fields for each entry in the Mobile Wallet Message Source Database are the same as those in the Wallet Server Message Source database on the wallet server 106, shown in Table 1 and described above.
Each feed message received by the mobile wallet 124 is stored in a database on the mobile device 104, with each entry in the database being a table populated by the fields shown in Table 6. The fields shown in Table 6 are substantially the same as those shown in Table 3, with the exception of the field designated “Message Download Timestamp” field T630 which is populated with a value corresponding to when the feed message is downloaded to the mobile wallet 124. The values in the Mobile Wallet Message Database may be updated based upon events which occur or the passage of time. For instance, if the feed message is set to expire after a certain period of time, then once that period elapses the “Message Status” field T615 is updated to reflect that the feed message has expired, the next time the mobile wallet 124 synchronizes with the wallet server 106.
As noted above, service provider systems 114, 116, and 118 interact with the feed messaging system via the web portal 126. The web portal 126 allows the service provider systems 114, 116, and 118 to call various Application Program Interfaces (API), shown below in Table 7, which are stored on the wallet server 106.
As shown in
As indicated in Table 10, the service provider system 114, 116, and 118 need only provide the message type, message source name, and the body of the message to create a new feed message. The remaining fields shown in Table 10 are optional. In step S404, the wallet server 106 creates the new feed message and assigns it a message ID. The wallet server 106 then returns the message ID and the operation status to the service provider via the ESB 112, in steps S406 and S408. The operation status indicates whether the feed message was generated successfully. If the wallet server 106 fails to create the feed message, then instead of the message ID, the wallet server 106 will return an error code corresponding to the error along with the operation status. The wallet server 106 stores a database of error codes, shown in Table 9, and generates the appropriate error code based on an automated analysis.
In S604 the wallet server 106 processes the add message source request and, if the request is successfully executed, returns the Message Source ID of the generated message source and an operation status indicating that the operation was a success. If, however, an error occurs, the mobile wallet 124 returns an operation status indicating that the message source was not successfully added and a corresponding error code generated by an internal analysis conducted by the wallet server 106.
As shown in Table 11, the Message Delivery Report includes the unique identification of the mobile wallet 124 to which the feed message is destined, in addition to the present status of the message. As discussed above, the feed message may be in one of five possible states: Not Delivered, Sent for Delivery, Delivered, View, and Operated. Additionally, the Message Delivery Report may include various timestamps corresponding to when the feed message was delivered, viewed, and operated.
As discussed above, a user interacts with the feed messaging system 100 via the mobile wallet 124. More specifically, the user inputs commands via the input unit or the display unit 208 of the mobile device 102. In general, the commands may be classified into two categories: wallet server interaction and feed message interaction.
With respect to wallet server interaction, Table 12 below shows a plurality of APIs stored on the wallet server 106 which are exposed to the mobile wallet 124.
While the user may call any of the APIs shown in Table 14, the mobile wallet 124 is also configured to perform automatic enrollment into any message source which is designated “Mandatory” or “Default” when the mobile wallet 124 is activated. This initial synchronization is shown in
Upon receipt of the update subscription request, the wallet server 106 generates a new entry in the Wallet Server Message Subscription Database 312 and populates that entry with a generated Message Subscription ID and with the information contained in the Update Subscription Request.
Of course, the user may choose to add message subscriptions after the initial synchronization, or simply view available messages sources, without subscribing.
To view available message sources, the user calls the “Get New Message Sources For Wallet” API T1200. As shown in
Upon receipt of the list of message sources the user may choose to add one or more message sources. To add a message source, the user calls, via the mobile wallet 124, the “Create Message Subscription” API 1210. As shown in
The user may also choose to discontinue one or more default and optional message subscriptions at any time after the mobile wallet 124 is activated.
A user may also choose to manually retrieve feed messages for the mobile wallet 124 at any time by calling the “Get New Messages for Wallet” API T1230. This process is also automatically executed at regular intervals in order to keep the mobile wallet 124 current. If the mobile wallet 124 determines that the mobile device 102 is unavailable to retrieve feed messages at one of the regular intervals, due to, for instance, the mobile device 102 being used by another program, the operation may be delayed until a time when the mobile device 102 is available.
In step S1400 of
Returning to
The acknowledgment message is one vehicle by which the wallet server 106 is informed of the operations which are carried out on the mobile wallet 124 by the user. For instance, when a feed message is received a corresponding message acknowledgment is generated which includes the message ID T1400 of the feed message, the message status T1410, and a timestamp T1420 indicating when the feed message was received. The message acknowledgment is stored on the memory 204 of the mobile device. When the feed message is viewed or operated, corresponding message acknowledgments are also generated and stored on the memory 204 of the mobile device 102.
As noted above, the feed message includes a message body T625, and may also include a logo which is a full logo T655 and/or a partial logo T660 depending on the type of feed message. When the user interacts with the message body T625 or the logos T655 and T660, a specific operation may be performed in accordance with the values stored in Message Logo Action ID field T635 and the Body Action ID field T645 of the feed message. The specific programming instructions for those operations are included in the Logo Action Parameters field T640 and Body Action Parameters field T650.
At the top of the display screen 1600 is a bar 1602 which shows basic information relating to the status of the mobile device 102. Below that is a graphic bar 1604 which contains an image 1606 corresponding to the operator of the feed messaging system 100, a directory icon 1608, and an information icon 1610. The directory icon 1608, when designated, returns a display screen showing a directory of service providers. The information icon 1610 when designated returns additional information about the elements shown on the display screen 1600. Below the graphic bar 1604 is a feed message type bar 1612 which includes a feed tab 1614 and an important tab 1616. The feed tab 1614 contains feed messages from message sources which are designated as “Default” or “Optional.” The important tab 1616 contains feed messages from message sources which are designated as “Mandatory.” In parentheses next to both the word “feed” and “important” are the number of messages respectively corresponding to each tab. As the user views each feed message, these numbers are updated accordingly. The feed button 1632 may also include a number 1640 indicating the number of feed messages which have not been read.
Below the feed message type bar 1612 is a feed message display area 1618 in which the feed messages are displayed. When the feed tab 1614 is designated, the feed messages corresponding to the “Default” and “Optional” message sources are displayed in the feed message display area 1618. Similarly, when the important tab 1616 is designated, feed messages corresponding to the “Mandatory” message sources are displayed in the feed message display area 1618.
The feed message display area 1618 may be configured to display one or more feed messages. The user may configure the mobile wallet 124 to display the feed messages at a font size and type of their choosing. In one embodiment, when the user touches the feed message display area 1618 and swipes their finger in an up or down direction, the feed messages are scrolled accordingly. In one embodiment, each feed message includes a selectable box 1620 for selecting the feed message, an image 1622 corresponding to the message source, an excerpt 1624 of the message body content, and a timestamp 1626 showing when the feed message was received. The image 1622 may be either the full logo T655 or the partial logo T660 contained in the feed message.
Below the feed message display area 1618 is a navigational bar containing navigation icons 1630, 1632, 1634, and 1636 which allow the user to change the display screen. When the user designates the “Home” icon 1630, then the display unit 208 displays a home screen for the mobile wallet 124 (not shown). When the user designates the directory icon 1634, the display unit 208 displays the directory of service providers. When the user designates the “More” icon 1636, the display unit 208 display additional content as dictated by the mobile wallet 124.
As discussed above, the body content of the feed message may be associated with the programming instructions. In one embodiment, if the body content is associated with programming instructions, then a chevron 1638 will appear next to the excerpt 1624. The user may then contact the area 1700 of the feed message corresponding to the body content, and swipe to the right to execute the associated programming instructions, as shown in
If the user designates a feed message for viewing, by tapping on the body content of the feed message, listed under the feed message tab 1614, then the display unit 208 displays the corresponding feed message, as shown in
If the user designates the “important” tab 1616, then the display unit 208 displays a display screen 1900 as shown in
When a user designates an image 1622 associated with a particular feed message, the mobile wallet 124 filters the remaining feed messages and returns only those feed messages associated with the message source corresponding to that image. The display unit 208 then changes the display screen to show the filtered results, as shown in
As discussed above, the message body T625 and the logo T655 and/or T660 may each be associated with programming content provider by the service provider in the body action parameters field T650 and the logo action parameters field T640. This programming may be able to call any function which can be realized by the mobile device 102, including, e.g., dialing a telephone number, opening a widget stored in the memory 204 or the secure element 210, or opening a web browser and loading a web page.
As discussed above, the wallet platform 104 also includes a consumer profile server 108. The consumer profile server 108 contains a processor and a memory, the memory storing one or more programs for generating and updating consumer profiles. As discussed above, the mobile device 102 periodically returns information regarding which messages have been received, viewed, and operated. From this information, the program in the consumer profile server 108 generates a profile for each mobile wallet 124. The program may also use information regarding which messages were not viewed or deleted in generating the consumer profiles. The consumer profiles are available to the service provider systems 114, 116, and 118 via the web portal 126 and the ESB 112, thus providing the service providers with information regarding the consumer's tendencies.
The computer 2300 may include without limitation a processor device 2310, a main memory 2325, and an interconnect bus 2305. The processor device 2310 may include without limitation a single microprocessor, or may include a plurality of microprocessors for configuring the computer 2300 as a multi-processor system. The main memory 2325 stores, among other things, instructions and/or data for execution by the processor device 2310. The main memory 2325 may include banks of dynamic random access memory (DRAM), as well as cache memory.
The computer 2300 may further include a mass storage device 2330, peripheral device(s) 2340, portable non-transitory storage medium device(s) 2350, input control device(s) 2380, a graphics subsystem 2360, and/or an output display interface 2370. For explanatory purposes, all components in the computer 2300 are shown in
The portable storage medium device 2350 operates in conjunction with a nonvolatile portable storage medium, such as, for example, a compact disc read only memory (CD-ROM), to input and output data and code to and from the computer 2300. In some embodiments, the software for storing information may be stored on a portable storage medium, and may be inputted into the computer 2300 via the portable storage medium device 2350. The peripheral device(s) 2340 may include any type of computer support device, such as, for example, an input/output (I/O) interface configured to add additional functionality to the computer 2300. For example, the peripheral device(s) 2340 may include a network interface card for interfacing the computer 2300 with a network 2320.
The input control device(s) 2380 provide a portion of the user interface for a user of the computer 2300. The input control device(s) 2380 may include a keypad and/or a cursor control device. The keypad may be configured for inputting alphanumeric characters and/or other key information. The cursor control device may include, for example, a handheld controller or mouse, a trackball, a stylus, and/or cursor direction keys. In order to display textual and graphical information, the computer 2300 may include the graphics subsystem 2360 and the output display 2370. The output display 2370 may include a cathode ray tube (CRT) display and/or a liquid crystal display (LCD). The graphics subsystem 2360 receives textual and graphical information, and processes the information for output to the output display 2370.
Each component of the computer 2300 may represent a broad category of a computer component of a general and/or special purpose computer. Components of the computer 2300 are not limited to the specific implementations provided here.
Software embodiments of the example embodiments presented herein may be provided as a computer program product, or software, that may include an article of manufacture on a machine accessible or machine readable medium having instructions. The instructions on the non-transitory machine accessible machine readable or computer-readable medium may be used to program a computer system or other electronic device. The machine or computer-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks or other type of media/machine-readable medium suitable for storing or transmitting electronic instructions. The techniques described herein are not limited to any particular software configuration. They may find applicability in any computing or processing environment. The terms “computer-readable”, “machine accessible medium” or “machine readable medium” used herein shall include any medium that is capable of storing, encoding, or transmitting a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methods described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, unit, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating that the execution of the software by a processing system causes the processor to perform an action to produce a result.
Portions of the example embodiments of the invention may be conveniently implemented by using a conventional general purpose computer, a specialized digital computer and/or a microprocessor programmed according to the teachings of the present disclosure, as is apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure.
Some embodiments may also be implemented by the preparation of application-specific integrated circuits, field programmable gate arrays, or by interconnecting an appropriate network of conventional component circuits.
Some embodiments include a computer program product. The computer program product may be a storage medium or media having instructions stored thereon or therein which can be used to control, or cause, a computer to perform any of the procedures of the example embodiments of the invention. The storage medium may include without limitation a floppy disk, a mini disk, an optical disc, a Blu-ray Disc, a DVD, a CD or CD-ROM, a micro-drive, a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory, a flash card, a magnetic card, an optical card, nanosystems, a molecular memory integrated circuit, a RAID, remote data storage/archive/warehousing, and/or any other type of device suitable for storing instructions and/or data.
Stored on any one of the computer readable medium or media, some implementations include software for controlling both the hardware of the general and/or special computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the example embodiments of the invention. Such software may include without limitation device drivers, operating systems, and user applications. Ultimately, such computer readable media further includes software for performing example aspects of the invention, as described above.
Included in the programming and/or software of the general and/or special purpose computer or microprocessor are software modules for implementing the procedures described above.
While various example embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It is apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein. Thus, the disclosure should not be limited by any of the above described example embodiments, but should be defined only in accordance with the following claims and their equivalents.
In addition, it should be understood that the figures are presented for example purposes only. The architecture of the example embodiments presented herein is sufficiently flexible and configurable, such that it may be utilized and navigated in ways other than that shown in the accompanying figures.
Further, the purpose of the Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the example embodiments presented herein in any way. It is also to be understood that the procedures recited in the claims need not be performed in the order presented.
This application claims priority to U.S. Provisional Application Nos. 61/675,947 and 61/676,227 filed Jul. 26, 2012, the contents of which are herein incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61675947 | Jul 2012 | US | |
| 61676227 | Jul 2012 | US |
