WO2008082794A2 - Location based service for directing ads to subscribers - Google Patents

Location based service for directing ads to subscribers Download PDF

Info

Publication number
WO2008082794A2
WO2008082794A2 PCT/US2007/083987 US2007083987W WO2008082794A2 WO 2008082794 A2 WO2008082794 A2 WO 2008082794A2 US 2007083987 W US2007083987 W US 2007083987W WO 2008082794 A2 WO2008082794 A2 WO 2008082794A2
Authority
WO
WIPO (PCT)
Prior art keywords
subscribers
information
ads
subscriber
transaction
Prior art date
Application number
PCT/US2007/083987
Other languages
French (fr)
Other versions
WO2008082794A3 (en
Inventor
Lee C.S. Crawford
Original Assignee
Crawford Lee C S
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/559,438 external-priority patent/US20070112741A1/en
Application filed by Crawford Lee C S filed Critical Crawford Lee C S
Publication of WO2008082794A2 publication Critical patent/WO2008082794A2/en
Publication of WO2008082794A3 publication Critical patent/WO2008082794A3/en
Priority to US12/967,040 priority Critical patent/US8260725B2/en
Priority to US13/560,969 priority patent/US20120289208A1/en
Priority to US13/560,971 priority patent/US20120289209A1/en
Priority to US13/586,839 priority patent/US8571999B2/en
Priority to US13/943,751 priority patent/US9129304B2/en
Priority to US13/943,748 priority patent/US9147201B2/en
Priority to US13/943,742 priority patent/US9129303B2/en
Priority to US13/969,561 priority patent/US20140108540A1/en
Priority to US13/969,560 priority patent/US20140108539A1/en
Priority to US14/846,982 priority patent/US10064004B2/en
Priority to US16/114,170 priority patent/US11070935B2/en
Priority to US17/305,513 priority patent/US20220070609A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29Geographical information databases
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/52User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail for supporting social networking services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/20Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel
    • H04W4/21Services signaling; Auxiliary data signalling, i.e. transmitting data via a non-traffic channel for social networking applications

Definitions

  • Location based services refer generally to services that provide information to a user in relation to the location of the user. At the present time, location based services are relatively pedestrian in nature and provide relatively simple information.
  • An example of a known location based service is a "weather" service in which the user's zip code is provided to the service (e.g., through a conventional HTML webpage, a WAP or other cellular phone interface, etc.) through a network and the service responds by communicating the current weather conditions and the forecast for several days.
  • Other known location based services provide "social" applications such as allowing users to determine each other's locations, receive notification when a friend comes within a predetermined distance, and similar operations.
  • Another type of location based services are generally referred to as "McDonalds finders" that provide search results in a map form (e.g., searching for specific locations of restaurants/stores within a given distance of the user).
  • Other location based services have proposed delivering various types of "advertising” (e.g., when a user arrives at an airport, various ads can be delivered to the user's cellular phone).
  • advertising location based services are quite simplistic and do not possess any appreciable intelligence for selecting advertisements beyond the location of the user.
  • system for providing one or more location based services comprises: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to: (i) store location information for subscribers associated with the one or more wireless devices; (ii) process the location information using data defining known activities associated with predetermined locations; (iii) create or maintain one or more logs of information for each respective subscriber, each log containing information indicating activities of the subscribers; and (iv) select ads for communication to the subscribers, the selection of ads comparing ad selection parameters against activity information stored in the logs.
  • the activities identified in the logs are defined in a hierarchical manner.
  • the logs identify when an activity has been completed.
  • the logs indicate completion of financial transactions with merchants.
  • the server for LBS services comprises: one or multiple databases storing information identifying subscribers of one or several LBS applications, wherein the one or multiple databases identifies groups of subscribers that have been detected to be located in close physical proximity on multiple occasions; one or multiple databases for storing advertisements to subscribers; code for determining whether subscribers are currently clustering based upon location information pertaining to subscribers; and code for selecting and communicating advertisements to subscribers based on locations of the subscribers, wherein the code for selecting and communicating determines selects ads for subscribers depending upon whether subscribers have been determined to be clustering.
  • a method comprises the operations performed by the one or more first programs, by the one or more second programs, and/or the LBS applications.
  • a method of providing a location based service comprises: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information, by one or more software programs, to identify activity of subscribers at merchant locations; maintaining a respective profile, by one or more software programs, for each of the plurality of subscribers that reflects norm shopping activity for the respective subscriber; comparing information pertaining to current or recent shopping activity, by one or more software programs, for each subscriber of the plurality of subscribers against information stored in the profile of the respective subscriber; selecting ads, by one or more software programs, for each subscriber of the plurality of subscribers in relation to the comparing; and communicating, by one or more software programs, the selected ads to plurality of wireless devices belonging to the plurality of subscribers.
  • LBS location based service
  • each profile comprises one or more activity norm parameters for a plurality of merchant types.
  • each shopping behavior profile stores information related to a number of purchases typically conducted by the respective subscriber, wherein the selecting compares a number of recent purchases made by the respective subscriber against information stored in the respective subscriber's shopping behavior profile to select ads for communication to the respective subscriber.
  • FIGURE 1 depicts a system in which multiple LBS applications provide location based services to multiple subscribers and in which advertisements can be directed to the multiple subscribers using multiple types of information according to one representative embodiment.
  • FIGURE 2 depicts a block diagram of a subscriber device adapted for delivery of advertisements according to one representative embodiment.
  • FIGURE 3 depicts a flowchart for identifying clustering according to one representative embodiment.
  • FIGURE 4 depicts a flowchart for processing cluster data according to one representative embodiment.
  • FIGURE 5 depicts a flowchart for utilizing cluster information according to one representative embodiment.
  • FIGURE 6 depicts a flowchart for utilizing cluster information according to another representative embodiment.
  • FIGURES 7-14 depict activity norm summary information that can be compiled or calculated for use in selecting ads to communicate to subscribers according to some representative embodiments.
  • FIGURES 15-17 depict respective flowcharts for processing activity information and/or financial transaction information to generate respective norm parameters for storage in subscriber profiles according to some representative embodiments.
  • FIGURES 18 and 19 depict activity norm profiles and for different merchant types according to some representative embodiments.
  • FIGURE 20 depicts activity norm analysis that cross-correlates selected financial transaction behavior to other subscriber behavior.
  • FIGURE 21 depicts activity norm analysis that cross-correlates selected activities and/or sub-activities to financial transactions according to one representative embodiment.
  • FIGURE 1 depicts a system in which multiple LBS applications and other applications 101 provide location based services to multiple subscribers 104 and in which advertisements can be directed to the multiple subscribers 104 using multiple types of information.
  • Applications 101 may include one Or more social network application such as the social network applications described in APPENDIX B.
  • Applications 101 may include one or more search applications such as the search applications described in APPENDIX C.
  • LBS applications 101 there are preferably a plurality of LBS applications 101 (executed one or more servers or other suitable platforms) that provide location based services to subscribers 104.
  • LBS applications 101 can provide conventional location based services such as map/navigation services, weather services, local merchant search services, etc.
  • the LBS applications 101 can further include financial or shopping location based services as described in U.S. Provisional Patent Application No. 60/736,252, filed Nov. 14, 2005, 60/759,303, filed 01/17/2006 and 60/773,852, filed 02/16/2006, which are all incorporated herein by reference in their entirety.
  • LBS applications 101 can include "social" LBS applications or gaming LBS applications that facilitate different types of subscriber interaction.
  • LBS applications 101 receive location information that is indicative of the current location of subscribers 104 and communicate LBS information to the subscribers 104 according to the location information either upon request by the subscribers 104 or automatically depending upon the nature/purpose of the particular LBS application 101.
  • the application data is preferably communicated through Internet 102 and a wireless network 103 (e.g., a cellular network) to subscribers 104.
  • the subscriber devices 104 can be any type of suitable wireless device (e.g., cellular phones, "smartphones," wireless e-mail devices, wireless capable PDAs, etc.) that possess the ability to determine their approximate current location or communicate through a network that enables the approximate location to be determined.
  • LBS applications 101 also communicate with LBS gateway/web service 105.
  • subscribers 104 communicate their current location to LBS gateway/web service 105.
  • subscribers 104 communicate their activation of an LBS application to LBS gateway/web service 105.
  • Gateway/web service 105 then intermediates communication between the selected LBS application(s) 101 and the respective subscribers 104.
  • subscribers 104 can access multiple LBS applications through the same source.
  • subscribers 104 only need to communicate their current location to the same destination which is then available to any LBS application 101 as appropriate.
  • LBS gateway/web service 105 provides such gateway services, the gateway services are not critical to all embodiments.
  • LBS applications 101 can report to web service 105 (i) the current location of subscribers 104 to web service 105 as subscribers 104 utilize their respective applications and (ii) when a respective subscriber 104 accesses an application and ceases use of the application (if applicable).
  • Gateway/web service 105 maintains a log of locations where subscribers 104 visited in DB 107. Also, LBS application 101 maintains a log of interaction with or access to particular LBS applications 101. Additionally, gateway/web service 105 preferably maintains a log of financial transactions completed by various LBS subscribers as identified by financial LBS applications 101 (e.g., a budget LBS application, a fraud monitoring LBS application, etc.) and communicated to gateway/web service 105.
  • financial LBS applications 101 e.g., a budget LBS application, a fraud monitoring LBS application, etc.
  • Gateway/web service 105 utilizes the location information, LBS application interaction information, and/or financial information to infer the activities performed by the subscribers and the current activity being performed by the subscribers.
  • the logs of activities for subscribers and current activities being performed are stored in DB 107.
  • the logs of activities enable more accurate selection of ads, incentives, offers, etc. to be directed to subscribers as will be discussed below.
  • the following activities and sub-activities are defined: (i) commuting; (ii) work; (iii) school; (iv) dining - (a) fast food; (b) casual;...fine dining; (v) entertainment - (a) movie; (b) music venue;...bar; (vi) sports/recreation - (a) health club; (b) golf; (c) athletic complex/fields;...gaming; (vii) shopping - (a) groceries; (b) gas; (c) clothing, shoes, accessories; (d) home decoration; (e) home improvement;...sports equipment; (viii) social; (ix) traveling/vacation, etc.
  • activities and sub-activities are by way of example and any other activities and/or sub-activities could be additionally or alternatively employed.
  • the activities need not be mutually exclusive in that a single subscriber could be engaged in multiple activities at the same time.
  • the information can be encoded in any suitable ontology.
  • a hierarchical classification of the types of locations could be formulated.
  • specific merchants are defined within the hierarchical framework within shopping related activities.
  • An example branch in such a hierarchical framework could be RETAIL: shopping: big-box store: TARGET®: grocery section.
  • any such hierarchical descriptors assignable to locations that indicate the nature of the activity being undertaken by a subscriber may be employed.
  • many of the activities and sub- activities are related to activities at physical locations (e.g., specific locations, specific merchants, etc.).
  • a current activity of a subscriber can be inferred from the type of LBS application 101 that the subscriber is accessing. For example, if a subscriber is utilizing a navigation LBS application and the subscriber has not reached their destination, it may be inferred that the subscriber is commuting. If a subscriber is utilizing a social application, certain activities (work, school, etc.) can be eliminated while other activities can possess a greater probability (e.g., dining, entertainment, etc.). Accordingly, when gateway/web service 105 attempts to infer the current activity of a subscriber, gateway/web service 105 identifies the LBS applications 101 that are currently active for the subscriber.
  • gateway/web service 105 utilizes information in DB 106 to infer the activity of the user.
  • DB 106 correlates specific locations to one or several specific activities.
  • DB 106 can be constructed by "mapping" the addresses or coordinates of residential areas, retail districts, schools, health care facilities, sports/athletic facilities, etc. to the particular activities that are customary to those types of locations.
  • DB 106 includes information at several geospatial "resolution" levels.
  • DB 106 comprises geo- coordinates or other spatial information that define (i) various retail districts at a higher level, (ii) specific malls, strip-malls, stand-alone stores, etc.
  • sub-store locations the specific goods or specific service provided can be identified. By maintaining a log of the locations visited by a subscriber and the amount of time spent at the locations, the activities of a user can be estimated.
  • Sub-store locations can be determined utilizing any number of mechanisms and/or algorithms. For example, a GPS receiver could be employed provided the GPS receiver possesses sufficient antenna gain and sufficient reception within the store. Alternatively, many retail locations utilize multiple WiFi access points. The particular ID's of the WiFi access points that are detectable and/or the relative signal strength of the WiFi access points can be utilized for a intra-store location determination.
  • sub- store locating functionality can be utilized to ascertain whether a subscriber has made a purchase at a particular merchant. For example, if a subscriber has spent an amount of time near a location where a cash-register is known to be present and the subscriber leaves the store after being at that location, it may be inferred that the subscriber has made a purchase at that store.
  • Financial information captured by financial related LBS applications 101 can be used to augment the identification of subscriber activities.
  • the applications monitor user accounts for the completion of transactions (e.g., credit or debit card transactions).
  • transactions e.g., credit or debit card transactions.
  • the activity can be more closely estimated. For example, if a user is located within a mall and the user previously purchased items at a clothing store, the specific current shopping activity can be inferred to include clothing shopping even though the user may temporarily depart from stores containing such items.
  • transaction information may signal that a particular activity has been completed by the user.
  • logs can be reviewed by advertisers, although the specific identity of subscribers are preferably not reviewable. In alternative embodiments, the logs are not actually reviewable by advertisers. Instead, the logs are merely maintained in DB 107 and advertising parameters are compared against the information in the logs to direct advertisements.
  • activity norms and financial norms are calculated by observing subscriber behavior over a period of time.
  • the term "norm" parameter refers to a parameter that is indicative of a general level or average for the particular subscriber.
  • the typical period between grocery shopping e.g., in days
  • the typical day(s) for grocery shopping the average amount spent
  • the range of amounts spent the standard deviation of amounts spent
  • the type of stores in which grocery shopping occurs, etc. can be compiled from location information and financial information obtained by LBS applications.
  • the typical day(s) for shopping, the average amount spent, the standard deviation of amounts spent, the number of transactions per shopping event, the average amount of time spent shopping at a particular retail location and/or per day, the types of stores visited, etc. can be compiled, the types of items purchases (if known), etc. can be compiled.
  • correlation between activities can be compiled. For example, it may be observed that a particular subscriber may routinely engage in a "dining (fast food)" activity after engaging in "recreation - sports complex” activity. Subscriber activity and/or financial norms are then compared against subscriber's more recent activities for the purpose of ad selection.
  • advertisers upload ads into ad DB 109 through ad server 108.
  • the advertisers specify any specific ad parameters for association with their various ads.
  • the ad parameters are compared by ad server 108 against subscriber information and the activity information and norm information in DB 107.
  • the respective ad(s) are communicated to those subscribers by ad server 108.
  • Any other ad selection criteria can be employed. For example, the ads of certain advertisers can be prioritized based upon purchased ad placements.
  • the payment for placement of ads may include payments to prioritize ad placement according to any ad parameter discussed herein or in the related APPENDICES. For example, payments for ad placements may occur according to purchasing norm parameters, clustering parameters, shopping timing parameters, etc. which are discussed below.
  • the payments for ad placements may also utilize any such parameters in combination or in combination with other subscriber data. For example, an advertiser may pay for ad placements for subscribers that typically spend greater than $200 per shopping trip, shop at a specific type of retail establishment, and that fit a given demographic profile. All such combination of ad parameters are contemplated according to some representative embodiments.
  • Subscriber device 200 is shown that is adapted for delivery of advertisements according to one representative embodiment.
  • Subscriber device 200 can be any suitable wireless device, such as a cellular phone, that is capable of executing software instructions.
  • the software instructions on subscriber device 200 preferably include multiple LBS applications 203.
  • the local LBS applications 203 contact remote LBS applications 101 to deliver the application location based information to the subscriber.
  • Subscriber device 200 further includes LBS agent 201.
  • LBS agent 201 preferably manages or intermediates the communication of location LBS applications 203 with remote LBS applications 101.
  • LBS agent 201 preferably forwards location information to the appropriate LBS applications 101 at times defined by the respective applications.
  • LBS agent 201 receives messages from LBS applications 101 and forwards the messages to the respective local LBS applications 203 as appropriate.
  • LBS agent 201 simplifies the implementation of LBS applications 203 and prevents conflict or difficulties in the execution of local LBS applications 203.
  • LBS agent 201 can manage updates to any LBS functionality that is common to all LBS applications 203 or one or several specific LBS applications 203.
  • Subscriber device 200 further comprises software for presenting ads to subscribers in an efficient manner.
  • subscriber device 200 comprises ticker software application 204 and ad detail menu application 205.
  • some ads are communicated to LBS agent 201 of subscriber device 200 using SMS messaging.
  • the SMS messages preferably detail how the ad is to be presented to the subscriber.
  • the SMS messages detail whether the ad is to be placed into a ticker, for how long, and what particular text is to be displayed in the ticker.
  • a ticker generally refers to a scrolling stream of characters on a screen of the wireless device (e.g., that mimics a "ticker-tape" in electronic form).
  • LBS agent 201 provides the appropriate information to ticker software application 204 to display to the user when the user reviews the screen of subscriber device 200 (e.g., when the subscriber opens his/her phone).
  • the SMS messages preferably detail information to be placed in a menu type form that provides a more detailed presentation of ads for subscriber review.
  • a hyperlink can be included for user selection that causes browser application 206 to download the corresponding content.
  • "digital coupons" are communicated to subscriber devices 104 through the ad selection functionality of ad server 108 and ad DB 107.
  • the digital coupons are preferably implemented by use of a digital image encoded according to a digital rights management (DRM) scheme.
  • the digital image can display the "coupon" details, such as product/store/location/purchase conditions, the amount of the coupon, etc.
  • the digital image preferably includes a "code” (e.g., an alphanumeric string) that authenticates the validity of the coupon.
  • a subscriber wishes to use a digital coupon
  • the user can present the screen of the subscriber device 104 displaying the digital coupon to a clerk of a merchant.
  • a merchant that has previously agreed to accept such digital coupons can enter the code into the merchant's POS device during a transaction.
  • the merchant's system can then determine the validity of the coupon in real-time by communicating the code to a suitable server.
  • the merchant's POS device can suitably adjust the transaction total.
  • the merchant's system can use the code to obtain settlement of the coupon amount at a later appropriate time using the code.
  • the DRM functionality can be used for several purposes in the digital coupon process.
  • the DRM functionality ties the digital coupon to a specific subscriber device 104, i.e., the digital image is not decrypted by other subscriber devices.
  • location information can be encoded within the DRM rules. For example, spatial coordinates and a radius distance can be defined such that the digital image is only decrypted by the DRM software when the user is within the area defined by the spatial coordinates and the radius distance (to ensure that the coupon is only presented at desired retail locations/merchants, etc.). That is, the DRM software accesses the current location of the subscriber device 104 and selectively decrypts the digital image by comparing the current location to the location rules defined in the DRM license associated with the digital coupon.
  • a short "ad” of several seconds is incorporated with a digital coupon.
  • the promotional video is played.
  • the digital image containing the coupon information is then displayed.
  • the DRM license can contain a DRM rule that causes the video to be deleted upon review for the purpose of minimizing the memory usage of the digital coupon over time.
  • Some representative embodiments can provide a number of advantages. For example, by maintaining a database of sub-locations within specific stores and the types of goods at those sub-locations, intelligent selection of ads for delivery to subscribers can occur. For example, in ordinary e-advertising and LBS advertising, it is most likely never useful to communicate an advertisement for an inexpensive, somewhat common-place food item. That is, the ad will have a very low probability of affecting the subscriber's purchasing activities.
  • FIGURES 7-14 depict activity norm summary information 700, 800, 900, 1000, 1100, 1200, 1300, and 1400 that can be compiled or calculated for use in selecting ads to communicate to subscribers according to some representative embodiments.
  • FIGURE 7 depicts activity summary profile 700 according to one representative embodiment.
  • Activity summary profile 700 stores information that indicates the amount of time spent by a subscriber for a plurality of activities. Also, the information is provided in a hierarchical manner. Specifically, the amount of time is shown for various sub-activities. As shown in FIGURE 7, for ACTIVITY 1, the average amounts of time spent for ACTIVITY 1 per day of the week (Sunday through Saturday) are represented by parameters Vl -V7. The standard deviations for the amounts of time spent for ACTIVITY 1 per each day of the week are represented by parameters sl-s7.
  • the average amounts of time spent per week and per month for ACTIVITY 1 are represented by parameters V8 and V9 and the standard deviations for time spent per week and per month are represented by s8 and s9.
  • average amounts of time and standard deviations are shown for SUB ACTI VITIE S, i.e., (V'l-V'9, s'l-s'9) for a first sublevel activity and (V"l-V"9, s"l-s"9) for a second sublevel activity. Any suitable number of subactivities and levels of subactivities could be so provided. As shown in FIGURE 7, this type of information is repeated for a plurality of activities (through "ACTIVITY W).
  • FIGURE 8 depicts activity probability profile 800 according to one representative embodiment.
  • Activity probability profile 800 is defined for one day of the week (i.e., Sunday). Preferably, similar profiles (not shown) are defined for other days of the week.
  • Profile 800 defines the probability that a subscriber will engage in a particular activity within a given time frame. For example, the probability that the subscriber will engage in ACTIVITY 1 between 5am and 6am is defined by the parameter Pl.
  • the probabilities for the other hours of the day for ACTIVITY 1 are defined by parameters P2-P24. Probabilities for hierarchical subactivities are shown in parameters P25-P48 and P49-P72. Probabilities are preferably defined for a plurality of activities throu ⁇ gbh L ACTIVITY N.
  • FIGURE 9 depicts shopping activity profile 900 according to one representative embodiment.
  • Profile 900 comprises relatively high level shopping summary information.
  • Profile 900 comprises the average amounts of time spent shopping per each day of the week, per week, and per month in parameters X1-X9. The standard deviations for these times are shown in parameters xl-x9.
  • the shopping frequencies for these time periods are represented by parameters F1-F9.
  • the shopping frequency represents the average number of discrete shopping trips taken by the subscriber for the respective time period.
  • the standard deviations for the shopping frequency for these periods are represented by parameters fl-f9.
  • the average amounts of time per shopping trip are represented by parameters T1-T9 for these time periods with the standard deviations represented by parameters tl-t9.
  • the average amounts of time spent shopping per shopping location (e.g., MALL X, MALL Y,...MALL Z, etc.) is shown for a plurality of locations for these time periods.
  • the locations are preferably retail locations in which there are multiple merchant stores in relatively close proximity such as a mall or retail district.
  • LOCATION 1 the average amounts of time for the various time periods are represented by parameters L1-L9 with the standard deviations represented by parameters 11-19.
  • the average numbers of stores visited by retail location for the time periods for LOCATION 1 are represented by parameters SL1-SL9 with the standard deviations represented by parameters sll-sl9. Similar parameters are defined for a plurality of locations (as shown through LOCATION Z).
  • FIGURE 10 depicts merchant type shopping profile 1000 according to one representative embodiment.
  • Profile 1000 preferably stores average amounts of time spent shopping for a plurality of merchant types (e.g., clothing retailers, electronics retailers, bookstores, big-box retailers, grocery retailers, etc.).
  • the standard deviations are defined (denoted by the "s" prefix).
  • the amounts of time and standard deviations are preferably calculated or compiled for each day of the week, per week, and per month time periods.
  • average amounts of time and standard deviations are defined for sub-store locations or departments for various merchant types.
  • Such information is preferably compiled or calculated for a plurality of merchant types (shown as MERCHANT TYPE 1 through MERCHANT TYPE X).
  • FIGURE 11 depicts merchant shopping profile 1100 according to one representative embodiment.
  • Profile 1100 stores the same type of information as profile 1000 except the information pertains to specific merchants as opposed to types of merchants.
  • FIGURE 12 depicts shopping purchase profile 1200 according to one representative embodiment.
  • Profile 1200 stores average numbers of purchases per shopping trip (parameters NPl-I through NP 1-9) and average amounts spent per shopping trip (parameters DPl-I through DP 1-9) for each day of the week, per week, and per month time frames. The standard deviations for these values are also given (parameters sNPl-1 through sNPl-9 and sDPl-1 through sDPl-9). Average numbers and amounts of purchases for locations are defined (LOCATION 1 through LOCATION N) as shown in parameters NP-Ll-I through NP- Ll-9...
  • Standard deviations are also defined for the locations for these time frames as shown in parameters sNP-Ll-1 through sNP-Ll-9...sNP-LN-l through sNP-LN-9 and sDP-Ll-1 through sDP-Ll-9...sDP-LN-l through sDP-LN-9.
  • FIGURE 15 depicts a flowchart for processing shopping activity information for a respective subscriber to generate profile information according to one representative embodiment.
  • activity information is retrieved for the last 6 months in a preferred embodiment (although any other suitable length of time could be selected).
  • the activity information is preferably retrieved from pre-existing activity logs according to one embodiment. Alternatively, location based information could be retrieved and correlated to activities in conjunction with the norm building process.
  • total time is calculated for each activity (and subactivity) per day of week, per week, per month.
  • the total amounts of time are divided by the numbers of each of days of the week, the number of weeks, and the number of months for the selected period of time. The values are stored in one or more profile(s).
  • the number of times that each activity (subactivity) was performed in various time periods is calculated.
  • the numbers of times for each activity/subactivity are divided by the total numbers of each of the days of the week in the selected period of time and the resulting values are stored in one or more profile(s).
  • the number of times that the subscriber went shopping over the selected period and for each day of week are calculated.
  • the calculated numbers of times are divided by the number of months, the number of weeks, and the number of days, respectively. The resulting values are stored in one or more profile(s).
  • FIGURE 16 depicts a flowchart for processing shopping activity information for a respective subscriber to generate profile information according to one representative embodiment.
  • activity log information is retrieved for last 6 months (or any other suitable period of time).
  • the total amount of time spent shopping over the selected period of time is calculated.
  • the total amount of time for the selected period for each day of the week is also calculated.
  • the calculated values are divided by the numbers of each day of the week, number of weeks, number of months in the selected period of time and the resulting values are stored in one or more profiles to generate the average amounts of time spent shopping per day of week, per week, and per month.
  • the standard deviations for the various time periods are calculated and stored in one or more profiles.
  • the calculation of averages and standard deviations for the time is repeated for a plurality of shopping locations or respective retail locations in which multiple merchants are present.
  • the calculated values are stored in one or more profile(s).
  • the calculation of averages and standard deviations are repeated for each merchant type and sub-store location.
  • the calculated values are stored in one or more profile(s).
  • the calculation of averages and standard deviations are repeated for each merchant and sub-store location.
  • the calculated values are stored in one or more profile(s).
  • an individual shopping trip refers to a period of time where a subscriber was substantially continuously engaged in a shopping activity.
  • the average amounts of time spent shopping per shopping trip per each day of week, per week, and per month are calculated and the standard deviations are calculated.
  • the numbers of times that the subscriber went shopping over the selected period and for each day of week over the selected period are calculated.
  • the calculated values are divided by the number of months, the number of weeks, the number of each day of the week in the selected period of time and the resulting values are stored in one or more store in one or more profiles.
  • FIGURE 17 depicts a flowchart for processing financial activity information for a respective subscriber to generate profile information according to one representative embodiment.
  • transaction information is retrieved for last 6 months or any other suitable period of time.
  • the total numbers of purchases for each day of week and total number of purchases are calculated.
  • the total dollar amounts of purchases are calculated for each day of the week and total dollar amount of purchases over the selected period of time are calculated.
  • the calculated values (from 1702 and 1703) are divided by the numbers of each day of the week, the number of weeks, and the number of months within the selected period to calculate the average values to be stored in the one or more profile(s).
  • the standard deviations for respective time periods are calculated and stored in one or more profiles.
  • the calculations are repeated to calculate the averages and standard deviations for the various time periods for each shopping trip.
  • the calculated values are stored in one or more profile(s).
  • the calculations are repeated for each shopping location.
  • the calculated values are stored in one or more profile(s).
  • the calculations are repeated for each merchant type.
  • the calculations are repeated for each merchant.
  • the calculated values are stored in one or more profile(s).
  • FIGURES 18 and 19 depict example activity norm profiles 1800 and 1900 for different types of merchants according to some representative embodiments.
  • Norm profiles 1800 and 1900 are preferably compiled by monitoring activity information as determined using LBS data and financial information for the respective subscriber. Any number of similar profiles can be defined for other types of shopping or spending activities.
  • some profiles are created and maintained for each subscriber, although not every profile need be created and maintained for each subscriber as some subscribers may not sufficiently engage in the respective activity for the information to be useful.
  • Norm profile 1800 depicts activity norm data for "FAST FOOD DINING.” Norm profile 1800 depicts the percentage of times that the subscriber engages in the activity at the respective times (by breakfast, lunch, and dinner) for each day of the week and the average amount spent at each respective time when the subscriber decides to engage in the activity. It may be observed that at certain times the subscriber dines with other parties, such as members of the subscriber's family, while at other times the subscriber dines alone (compare breakfast on Sunday with lunch on Wednesday). Profile 1800 further details percentages of purchases by restaurants and restaurants types. For example, profile 1800 indicates that the subscriber dines at restaurant A 35% of time when the subscriber decides to engage in fast food dining. Profile 1800 further indicates that the subscriber dines at a restaurant of type A 45% of the time when the subscriber decides to engage in fast food dining.
  • Norm profile 1800 preferably indicates other activities that are correlated to fast food dining. For example, norm profile 1800 indicates that when the subscriber is engaged in a "work - traveling" activity, the subscriber engages in fast food dining 76% of the time (during or shortly thereafter the work-traveling activity). Also, norm profile 1800 indicates that when the subscriber is or recently has engaging in a "shopping mall” activity, the subscriber engages in fast food dining 44% of the time (during or shortly thereafter the shopping mall activity).
  • specific ads can be directed to a subscriber at an appropriate time. Specifically, the ads might be able to reach the subscriber before the subscriber has made a decision to engage in a specific activity or to go to a specific merchant.
  • Norm profile 1900 is similar to norm profile 1800 except that norm profile 1900 includes norm parameters relevant to clothing shopping, clothing merchants, and clothing merchant types (e.g., young -women's retailer, designer retailer, discount retailer, etc.). Profile 1900 includes additional information.
  • norm profile 1900 preferably includes a parameter that indicates that the number of clothing-related purchases that the subscriber typically makes per shopping trip.
  • Norm profile 1900 may also include information indicative of the typical goods or type of goods purchased by the subscriber (e.g., if the information is made available by the retailers in connection with coupon, discount, or payment settlement processes).
  • Profile 1900 also preferably includes information that relates a correlation between other financial considerations and the purchase of clothing.
  • Profile 1900 indicates that there is an increased probability of 50% of clothing purchases immediately after deposits into a financial account of the subscriber (e.g., when a paycheck or other funds are deposited in the account). Also, there is an increase in the average amount of said purchases immediately after deposits of 70%. It is seen, for this subscriber, that clothing purchases are highly correlated to available funds and, accordingly, the selection of ads for this subscriber should also depend upon the deposit of funds into the subscribers account (e.g., in terms of timing of the deposits and the amounts of the deposits).
  • Profile 1900 indicates decreased probability of 20% immediately after out of budget expenses.
  • Profile 1900 further indicates a decreased average amount of purchase immediately after out of budget expenses of 50%.
  • expenses may be categorized by analyzing the financial activity of a subscriber to assign expenses/payments to various categories. See APPENDIX A. Significant deviations (e.g., greater than 20%, 30%, ..50%, or any suitable dollar amount) from typical expenses for a significant budget category may indicate that the subscriber is currently experiencing financial difficulty or unexpected expenses. For some subscribers, such unexpected expenses may cause the subscribers to curtail certain other purchases. By correlating such unexpected expenses to purchasing behavior, subscriber reaction to subsequent unexpected expenses may be predicted and ad selection modified in response thereto. Accordingly, such information can be obtained and stored in subscriber profiles according to some representative embodiments for the purpose of ad selection for subscribers.
  • FIGURE 20 depicts activity norm analysis that cross-correlates selected financial transaction behavior to other subscriber behavior.
  • deviations in typical expenditures e.g., deviations exceeding 10%, 20%, 30%, and 40% of typical discretionary or other spending
  • Such deviations may be performed to identify unexpected expenses or significant purchases that may impact other purchasing decisions of the subscriber.
  • changes in purchasing behavior after identified deviations are identified for multiple shopping / spending categories in terms of probabilities of purchases and amounts of purchases.
  • changes in probabilities and amounts of purchases are stored in profiles for the various identified deviations (if any).
  • FIGURE 21 depicts a flowchart to identify correlations between purchasing behavior of a subscriber and various activities performed by the subscriber according to one representative embodiment.
  • an activity and/or subactivity of subscriber is selected for analysis.
  • occurrences of selected activity / subactivity in activity logs for a suitable time period e.g., six months
  • a logical comparison is made to determine whether the selected activity / subactivity has been performed greater than x number of times within the period of time. If so, the process flow proceeds to 2104. If not, the process flow proceeds to 2107.
  • transaction types that have occurred at least y% of the time that the actitivy / subactivity was performed by subscriber are identified (e.g., clothing purchases, payments for dining, payments for various forms of entertainment, etc.). A suitable percentage of the time may be 50% according to one embodiment (although any other suitable percentage could be employed for other embodiments).
  • identified transaction types and % for each type of financial transaction are stored in one or more profile(s).
  • the information stored in DB 107 is utilized to analyze and detect the collective activities of subscribers.
  • clustering of subscriber activity is detected.
  • clustering refers to multiple subscribers engaging in a common activity or activities within the relatively same geographical location. Clustering of such individuals could be detected over time by repeatedly observing the close proximity in the locations of such individuals. That is, because the same subscribers are observed in very close physical proximity on multiple occasions, some type of relationship is believed to exist between such subscribers. Specifically, their repeated presence together is not a mere accident.
  • clustering is not limited to any particular type of relationship. Clustering may occur in many contexts, e.g., family activities, gatherings of friends, business meetings, etc.
  • Clustering provides valuable insight into the expected behavior of subscribers and especially commercial behavior.
  • the detection of clustering provides a valuable mechanism to direct various types of advertising to such subscribers.
  • the advertising may take the form of direct ads sent to wireless devices of the subscribers, e-mail advertisements, web page advertisements, etc.
  • the communication of ads may occur while the clustering is taking place or may occur at a later time. The communication may occur before the clustering takes place. That is, it may be possible to predict a clustering event (e.g., the specific subscribers have been observed to cluster at the same approximate time/day, etc.) based on prior subscriber behavior. In such a case, delivery of the ads may occur immediately before the estimated time of the predicted clustering event as an example.
  • a family may decide to go to a mall on a weekend day. It is quite common for multiple members of the family to possess their own cellular phones. Perhaps, each parent and each teenager in the family would possess their own cellular phone or other wireless device. Assuming that each family members' wireless device possesses a suitable LBS application that reports the respective subscriber's location to an LBS application or LBS gateway, the clustering of the family members can be detected. For example, when the family members initially enter the mall, the family members' respective GPS data may be very similar. That is, the LBS applications of their wireless devices may report substantially similar location information. Also, as each family member enters the mall, the GPS reception may fade at substantially the same time (which can be communicated to an LBS application or gateway).
  • the family members may initially separate to frequent each family member's favorite stores. However, the family members may gather back together to eat lunch or dinner together. Also, the purchases of the family members may be quite different when the family members are together as opposed to when the family members go shopping individually. For example, when a family is found to be clustering, purchasing may be skewed towards the children or teenagers of the family. If the parents are found to cluster without the children, a different set of purchasing behavior could be expected. Likewise, if each individual were determined to be shopping alone, the purchasing behavior again may be different. Further, shopping in the context of peers or friends can exhibit another set of purchasing norms. Additionally, the individual making the purchases may be different depending upon the presence of other individuals.
  • a parent may decide to go to a particular establishment for a meal for the family which would not be chosen by any individual on their own.
  • the type of ads for meals should depend upon whether the clustering is taking place and the members of the current cluster. Also, it would be beneficial to identify the party that is most likely to make the purchasing decision.
  • FIGURE 3 depicts a flowchart according to one representative embodiment.
  • LBS information is accessed from one or several databases for prior locations of a selected subscriber as logged in the database(s).
  • the database(s) is/are queried for other subscribers that were present at substantially the same location as the selected subscriber at substantially the same time.
  • a logical comparison is made to determine whether there are one or more subscribers that were repeatedly present at the same location as the selected subscriber.
  • step 304 it is determined whether there are additional subscribers to analyze. If not, the process flow proceeds to step 305 to quit. If there are, the process flow returns to step 301 to select another subscriber.
  • step 303 determines that there are one or more subscribers that were repeatedly present at the same location as the selected subscriber.
  • step 306 a suitable database update is completed to indicate that the selected subscriber exhibits clustering activity.
  • the database update may include indicating the identifiers of other subscribers with which the subscriber tends to cluster.
  • step 307 the activities, associated financial transactions, etc. associated with the common locations are identified for the selected subscriber are identified.
  • step 308 one or more databases are updated to indicate the type(s) of locations, type(s) of common activities and transaction data associated with the selected subscriber's clusters.
  • step 304 determine whether there are additional subscribers for the cluster analysis process.
  • FIGURE 4 depicts a flowchart for processing cluster data according to one representative embodiment.
  • a cluster of subscribers multiple subscribers that have been repeated observed within close proximity of each other
  • activity information and financial information e.g., transaction details
  • step 403 the transactions by individuals in the cluster are categorized (if not already so processed).
  • step 404 the member(s) of the cluster that are likely to pay for various transactions during clustering are determined.
  • step 405 the types of goods and/or services that exhibit an increased or decreased probability of purchase are determined for the subscribers of the cluster.
  • step 406 the types of goods and/or services that exhibit a change in probability when the individuals are not clustering are identified.
  • step 407 the types of goods that exhibit a change in probability before and after clustering are determined for the subscribers of the cluster.
  • step 408 the activities that exhibit a change in probability (increase or decrease) in conjunction with the clusterin 1 gB are identified.
  • step 409 the information pertaining to the clustering is stored in a suitable database or databases.
  • FIGURE 5 depicts a flowchart for utilizing cluster information according to one representative embodiment.
  • a request e.g., an HTTP transaction to a suitable LBS advertising web server application
  • LBS advertiser e.g., an HTTP transaction to a suitable LBS advertising web server application
  • a suitable web page is provided to the LBS advertiser that preferably includes interactive elements to enable the LBS advertiser to view subscriber information and to direct advertisements to suitable subscribers.
  • cluster information is included within the subscriber information for provision to the LBS advertiser.
  • the LBS subscriber may be allowed to click on a graphical element within the web page that represents a given subscriber.
  • subscriber information may be presented (e.g., an activity log, transaction information, activity norms, financial transaction norms, etc.).
  • the LBS advertiser is provided information that indicates whether the subscriber is current "clustering" and, if so, with which other subscribers.
  • the nature of the clustering is preferably identified (e.g., family clustering, peer clustering, business clustering, etc.). Also, information that identifies the types of transactions or activities that exhibit increased or decreased probability are preferably provided. By providing such information, the LBS advertiser can more effectively identify desirable subscribers for ads and/or selected more appropriate ads for the subscribers.
  • FIGURE 6 depicts another flowchart for utilizing cluster information according to one representative embodiment.
  • advertising parameters are received (which may include one or more clustering parameter values).
  • the advertising parameters define the desired recipients of one or more directed advertisements (e.g., as will be delivered to subscriber wireless devices).
  • directed advertisements e.g., as will be delivered to subscriber wireless devices.
  • tag-encoded parameters could be used as part of a desired LBS advertising effort to direct advertisements to subscribers: ⁇ LOCATION>STONEBRIAR MALL ⁇ /LOCATION> AND ⁇ CLUSTERING> TRUE ⁇ /CLUSTERTNG> AND
  • ads are communicated by a suitable LBS advertising platform to subscribers according to the received parameters.
  • the direction of the ads may directly depend upon the defined clustering parameters/data provided in the received parameters. For example, an advertiser may direct that advertisements are only to be sent to members of a cluster that make purchasing decisions for meals among other advertising parameters in addition to providing non-clustering advertising parameters.
  • the ad parameters may be defined in terms of any of the clustering information discussed herein or any other suitable clustering information.
  • the advertiser may provide more general advertising parameters and automated subscriber selection algorithms can select the most probable subscribers to respond based upon the clustering information.
  • the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks.
  • the program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium.
  • the "computer readable medium” may include any medium that can store or transfer information.
  • Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • the code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
  • Payment for a transaction using such cards follows a relatively simple process.
  • the respective card is "swiped" through or by a reader of a "point-of- sale” device that reads account information from the card.
  • the point-of-sale system communicates the account information, transaction amount, merchant information, and other information to a payment server.
  • the payment server communicates within a payment system to clear the transaction.
  • another server (the "payor" server) associated with the financial institution responsible for the account associated with the cards processes the financial transaction information. Specifically, the payor server determines whether sufficient funds are available in the identified account for the transaction. If so, the payor communicates a transaction approval.
  • a transaction denial is communicated back through the payment system to the original server and to the point-of-sale system.
  • the actual funds are transferred from the account associated with the card to the merchant's account (possibly through other accounts of financial intermediaries).
  • third parties i.e., parties other than the individual responsible for the underlying accounts
  • a third party possesses the ability to incur substantial charges (up to a credit limit for credit accounts) or spend the entire available funds (for deposit type accounts).
  • Stored value cards offer some degree of usefulness for providing cards to third parties to limit the transactions of the third parties.
  • the stored value cards are typically limited to one or more specific merchants and only store a limited amount of funds at any given time.
  • FIGURE 1 depicts a system for managing financial accounts, defining budget limits for such accounts, for processing transactions for the accounts according to such limits, communicating transaction and budget information to card holders and account holders, and communicating advertisements to card holders and account holders according to one representative embodiment.
  • Financial accounts or other types of payment accounts can be created utilizing any known or later development manner. For example, an individual may simply enter a bank and open a checking account and receive a debit card to allow debit transactions to occur from the account. Alternatively, an individual may open an account over the Internet 104 via a web browser 113. Any suitable type of account may be utilized according to some representative embodiments from credit card accounts, savings and checking accounts, money market accounts, stored-value accounts, pre-paid card accounts, etc.
  • account database 114 such as account holder information and account balance information.
  • card holder information is also stored.
  • account holder means an individual who opens, controls, or manages an account and card holder refers to an individual that uses a card to pay for transactions.
  • the card holder can be, but need not be, the same individual as the account holder.
  • multiple cards could be issued for a single account and information for multiple card holders could be entered into the database.
  • the account information may also include contact information (e.g., cell phone numbers, e-mail addresses) for the account holders and the card holders to communicate transaction and budget information to the account and/or card holders.
  • account holders can set budgets (using their browsers 113 to communicate with web server 105) that delineate how users wish to spend their funds or how the users wish to limit how other card holders spend funds (optionally according to hierarchical categories).
  • the budget information is stored in database 109.
  • the transactions using their personal accounts e.g., their banks accounts, credit card accounts, etc.
  • Transaction information e.g., merchant ID, merchant location, transaction amount, time, etc.
  • Such information is preferably stored as transactions are completed.
  • such information is preferably processed to identify various types of purchasing norms and patterns to facilitate selection of ads for communication to account and card holders.
  • the account holders can be taken through a series of pages in a progressive manner (e.g., through a "budget wizard") to enter budget information.
  • Example categories and subcategories can include the following: EATING OUT/MEALS: (i) breakfast; (ii) lunch; (iii) dinner; (iv) misc. (v) total: ENTERTAINMENT: (i) movies; (ii) sports; (iii) live events;... total: EDUCATION: (i) books; (ii) supplies ...total : MEDICAL:.. HOUSEHOLD EXPENSES/GROCERIES: CLOTHING... DISCRETIONARY.
  • any additional budget categories can be defined.
  • Account holders can be given the option of defining only gross amounts for top-level categories or, going forward and defining the specific amounts for various subcategories.
  • any number of user defined budget categories or subcategories could be defined if desired.
  • the users are preferably given the option of defining the budget period for the various categories and/or subcategories.
  • the default option is preferably a monthly budget period for common expenses, e.g., groceries. Weekly budget expenses could be defined, as examples, for work-week lunch expenses, entertainment expenses, etc..
  • account holders can identify specific permitted merchants for one or more budget categories. Also, account holders can be given the ability to select specific merchant locations for specific budget categories. For example, a map of an area in which the card holders is expected to conduct most transactions can be presented via the account holder's web browser 113. Specific categories or types of merchants within the area can be identified on the map for selection by the account user for a specific budget category. Thereafter, the card holder would only be permitted to conduct transactions for the specific budget category at the selected merchants/locations.
  • such functionality may be implemented by storing a database of merchant identifiers (as defined for use in a payment system) and correlating the merchant identifiers to more detailed merchant information (e.g., merchant name or other merchant metadata). Also, for each merchant entry, merchant type information can be stored in the database.
  • Transactions may begin in the ordinary manner in which credit card information, debit card information, stored-value card information is obtained from a card holder via a point-of-sale devices/merchant devices 103.
  • Merchants 103 communicate transaction information (e.g., account number, transaction information, merchant ID, etc.) through payment system 102.
  • the bank server 101 responds to the transaction information by communicating approvals or disapprovals, debiting/charging user accounts, transferring funds within the payment system, etc.
  • the transaction approvals or denials depend upon the budget information stored in database 109. Specifically, if a series of prior transactions cause a card holder to reach a budget limit for a particular budget category, a subsequent transaction would be denied for that budget category.
  • bank server 101 is described, server 101 need not be chartered bank.
  • Bank server 101 can be any server that processes financial transactions and could be managed by credit unions, brokerage firms, or any suitable financial entity permitted access to payment system 102 as examples.
  • Bank server 101 preferably communicates transaction information to web server 105 (e.g., through the Internet 104). Either bank server 101 or web server 105 may initiate the communication to obtain the transaction information.
  • selected transaction information is stored in database 109.
  • each transaction is categorized according to one or several budget categories upon being stored in database 109 (e.g., a field in the database is filled with a value corresponding to the respective budget category).
  • budget category as stored in database 109.
  • a message can be sent (e.g., via SMS messaging) to the account holder's wireless device 106 and/or the card holder's wireless device 107 indicating the transaction amount, the amount of expended funds for the budget category, remaining available funds for the category, and/or the like.
  • the account holder can be informed of the financial activity of the card holder.
  • the card holder can have near constant awareness of how the card holder's activities conform to the budget limits.
  • Such information may be communicated by server 105 as an example.
  • Server 105 preferably obtains the location information of users.
  • a JAVATM MIDlet client application is stored and executed on each user wireless devices (e.g., their cellular phones) 106 and 107.
  • the client application obtains information that is indicative of the current location of the respective wireless device and communicates the information (e.g., with a time stamp) to server 105 through cellular infrastructure 108 and/or the Internet 104.
  • the information is communicated in an SMS message.
  • the information can be encrypted or otherwise obscured to maintain the privacy of the user.
  • GPS coordinates are communicated to server 105 that identify the precise location of the device 106/107 at a particular moment in time.
  • AGPS assisted GPS
  • the wireless device 106/107 communicate cell ID information (e.g., the identifier of the current cell in the wireless system serving the respective wireless device). The cell ID information can be used to look-up the location of the serving cell which, in many urban cases, is "relatively" close to the wireless device (e.g., within one mile or closer).
  • Server 105 stores the location information and time information in location DB 112.
  • transaction information associated with a credit card transaction includes an identifier of the merchant and the merchant location (e.g., a particular merchant store).
  • the merchant location can be correlated to a merchant address.
  • the merchant address can then be compared against the location of the card holder's cellular phone 107 at the time that the transaction occurred. If the address does not match the location of the cellular phone 107, it is possible that an unauthorized person used the card or card account to make the purchase.
  • some amount of tolerance is provided to the comparison to account for a lack of complete precision in the location information (e.g., when a cell ID is used) or in the merchant location information.
  • a suitable message is sent to the card holder's wireless device 107 and/or to the account holder's wireless device 106.
  • the message is sent as an SMS message to a particular port.
  • the client MIDlet is registered to process SMS messages on the port and communicates the possible fraud to the user.
  • the client MIDlet preferably presents the information to the user and prompts the user to input whether the transaction is actually fraudulent. If the user indicates that the transaction is fraudulent, the client MIDlet can give the user one or several options. One option may include automatically initiating a call to the fraud number associated with the user's bank for the user to report the fraud.
  • the budget/transaction processing can occur in conjunction with a system that enables the user to control which transactions are approved or denied by bank server 101.
  • a MIDlet is stored on the user's cellular phone. The MIDlet is accessed when the user wishes to "activate” the user's card account for a particular type of transaction (e.g., for "everyday” transactions, "gas” transactions, "eating-out” transaction, "entertainment” transactions, etc.). Also, at any point in time, the MIDlet preferably provides the user with updated budget information (i.e., the current budget limit, available funds, projected over-budget or under-budget amounts, etc.) for the various budget categories.
  • updated budget information i.e., the current budget limit, available funds, projected over-budget or under-budget amounts, etc.
  • the MIDlet is preferably customized to the individual user (e.g., the ordering of transaction options in its user interface and the particular categories of transaction options for selection within the user interface are adapted for the specific user). Also, the MIDlet preferably is given a private key to digitally sign its messages to authenticate the origin of the messages.
  • the customized MIDlet is preferably customized at an appropriate server and downloaded to the user's cellular phone when the user sets-up his/her account for management.
  • the MIDlet communicates an "activation" message to a server associated with the user's account.
  • the account is then temporarily activated to approve transactions subject to the selected category (e.g., for thirty minutes or any other suitable amount of time).
  • the transaction information is compared against the limitations associated with the selected category. For example, if the merchant identifier in the transaction information is consistent with the selected category, the transaction is approved. If not, the transaction information is denied.
  • the card holders and/or account holders are given the option of receiving advertisements, offers, incentives, etc. according to a "location based services" (LBS) scheme.
  • LBS location based services
  • ad server 110 receives ads from advertisers via the Internet 104 and stores those ads in ad database 111.
  • target audience parameters are associated with the ads to define which subscribers should receive the ads.
  • the ads are communicated to such users in a manner that is dependent upon the current location of the users. For example, a user can go to a specific mall and request communication of current offers/incentives etc. that are applicable at that mall. The user can make such a request using a WAP browser on the wireless device 107 as an example.
  • the WAP request may include the current location of the cellular phone 107.
  • a MIDlet application on the wireless device 107 may automatically download such ads for presentation to the card holder.
  • the location enables the selection by ad server 110 of incentives/offers from the particular merchants at the mall to be identified.
  • the transaction information and/or budget information can be further utilized by server 110 to sort and/or pair down the advertisements, incentives, offers, etc. to those that are more likely to be relevant to the particular card holder.
  • ad server 110 communicates the ads (e.g., by WAP transaction processing, MMS messaging, etc.) to the wireless device 107.
  • budget information and transaction information stored in database 109 can be used to communicate targeted advertisements to users either to web browsers 113 or cellular phones 106 and/or 107 as examples.
  • users can be given the option of receiving such advertisements/offers. Users that select the option will receive advertisements/offers that correspond to their particular needs in view of the purchases and budgets.
  • various coupons/incentives can be sent to such a user to enable the user to reduce the user's grocery expenses.
  • the sponsors of the coupons/incentives benefit by steering the user to their products and/or stores and generating customer loyalty to their brands.
  • a user when a user is underbudget, various offers/incentives for discretionary purchases can be sent to the user. Also, the user's transaction history can be used to select such discretionary items that are likely to be interesting to the user.
  • targeted advertisements/incentives/offers can be sent to the user related to the purpose of the savings fund. For example, a user can define a SAVINGS category into which any amount or, perhaps, unused funds are deposited. The user can defined a purpose for such an account. When advertisers have offers that correspond to the purpose of the account and approximately match the amount of funds in the account, their advertisements can be communicated.
  • the communication of the advertisements/incentives/offers can occur according to a "location based services" (LBS) scheme.
  • LBS location based services
  • information is communicated to users in a manner that is dependent upon the current location of the users. For example, a user can go to a specific mall and request communication of current offers/incentives etc. that are applicable at that mall. The user can make such a request using a WAP browser on their cellular phone 106 or 107 as an example.
  • the user can manually input their location (e.g., by "typing” or by selection from a menu or other graphical control), the location can be inferred by reference to the current cell of the wireless system that is serving the cellular phone 106 or 107, or the cellular phone can itself determine the location (e.g., using assisted GPS functionality).
  • the location enables the selection of incentives/offers from the particular merchants at the mall to be identified.
  • the budget and transaction information can be further utilized to sort and/or pair down the incentives/offers/ads to those that are more likely to be appropriate or most relevant to the particular user.
  • databases and servers are discussed herein, the databases and servers can be implemented on common computing platforms or split among different platforms as desired.
  • a specific computing architecture is not critical for all embodiments. Any implementation may be utilized so long as the appropriate transaction processing and/or advertisement selection occurs.
  • FIGURE 2 depicts a flowchart for establishing a budget for management of one or several financial accounts and/or payment cards according to one representative embodiment.
  • the process of FIGURE 2 is implemented using suitable computer platforms (e.g., a personal computer of an account number and a server platform) and suitable software code executed by those platforms.
  • the code may include the browser application code (e.g., Internet Explorer, Firefox, etc.), web server code (e.g., APACHE and custom PERL scripts for processing HTTP transactions), and the HTML or other browser executable code (as executed by the browser itself or through a "plug-in") communicated from the server to the account holder's computing platform.
  • a suitable communication connection is preferably established between the platforms such as through one or more of the following a local area network, the Internet, a wireless network, a telephony network, and other communication network.
  • a communication connection is established between an account holder's browser and a suitable server (e.g., server 105) that supports the budget creation process.
  • the communication connection may be established using conventional processing, such as TCP/IP connections using secure socket layer (SSL) communication, HTTP transactions, authentication (e.g., user ID, password, etc.), and/or the like.
  • SSL secure socket layer
  • step 202 one or more web page(s) are presented to account holder using the account holder's web browser via communication between the server and the web server.
  • step 203 in conjunction with the presentation of the web pages, input is received from the account holder in web page forms defined by the web page(s) communicated to the account holder's web browser.
  • the web page forms allow the user to create and/or modify budget rules. For example, the account holder may select predefined budget categories or create user specific budget categories. For the selected/created budget categories, the account holder can select predefined limitations and/or define user specific limitations. Also, "default" limitations can be associated with the predefined budget categories and the account holder may modify those limitations.
  • the limitations may define time of day and day of week restrictions.
  • a budget category for "EATING OUT/MEALS: LUNCH (WORK WEEK)" may be created and a time restriction of 10:30 - 2:30 and a day of week restriction of Monday - Friday could be defined for such a category.
  • budget categories For example, transactions for a GROCERY/HOUSEHOLD NEEDS category could be restricted to GROCERY STORE and BIG-BOX RETAILER merchant types. More specific merchant restrictions could be applied to budget categories. For example, geographical limitations could be defined. For example, merchant stores within a specific geographical area or areas (e.g., defined by city, zip codes, area selected from a map in a user interface, etc.) may be defined as the only acceptable locations for transactions with one or more budget categories. Additionally, to the extent that the account holder wishes to do so, only specific merchants may be permissible for one or more budget categories such as a specific big-box retailer or a specific grocery retailer.
  • geographical limitations could be defined. For example, merchant stores within a specific geographical area or areas (e.g., defined by city, zip codes, area selected from a map in a user interface, etc.) may be defined as the only acceptable locations for transactions with one or more budget categories. Additionally, to the extent that the account holder wishes to do so, only specific merchants may
  • activation rules are applied to one or more budget categories. Such activation rules preferably require the account holder and/or the card holder to "activate” (as will be discussed below) a budget category before transactions will be approved during transaction processing for the category. For example, “ELECTRONIC PURCHASES,” “CLOTHING PURCHASES,” and “INTERNET PURCHASES) categories may be defined. These categories could be defined as normally inactive. If a transaction were attempted at an electronic retailer, at a clothing retailer, at a Internet payment web service, the transaction would be denied. However, when such purchases are deemed appropriate or necessary, the account holder (or possibly the card holder) may communicate with the server to activate the appropriate budget category.
  • the activation rules may identify which categories must be active for transaction approval. Also, the activation rules may specify who is allowed to activate the categories (e.g., the account holder only or the account holder and the card holder). The activation rules may also specify how long the budget categories remain active after activation.
  • Per transaction limits could be defined for one or more budget categories. Transaction limits could be defined to limit a total dollar amount per transaction or to limit a number of transactions within a given period of time for one or more budget categories.
  • product restrictions could be defined. For example, certain stored value card systems (as implemented by various retailers) allow access to data identifying the products and/or services being purchases. Budget categories may restrict transactions to permit only certain products, services, or types of products or services.
  • Rules can be defined for left-over funds or for over-budget transactions. For example, if a transaction exceeds a budget limit may a predefined amount, the transaction may be approved if permitted by an over- budget rule or may be alternatively denied. If some amount of over-budget spending is permitted, rules may be defined to address such over-budget spending such as reducing the available funds from another budget category (in the current budget period or in another budget period) or reducing the available funds for the same budget category for the next budget period.
  • the over-budget rules may also specify whether a more general budget category or another budget category could be employed for a transaction if a specific budget category limit is exceeded. For example, if a card holder exceeds a budget limit for MEALS: LUNCHES (WORK WEEK), it may be permitted (by decision of the account holder or by default) to pay for a transaction using a more general category "MEALS" or a general budget category "DISCRETIONARY SPENDING.” Alternatively, if a card holder exceeds a budget limit for an "ENTERTAINMENT" budget category, the account holder may define a rule prohibiting completion of payments for entertainment transactions using more general categories. [0037] In step 203, the data input by the account holder is communicated to the budget server (e.g., using conventional HTTP transactions over a secure socket layer connection).
  • the budget server e.g., using conventional HTTP transactions over a secure socket layer connection.
  • step 204 the budget information is stored in a suitable database or databases or other data store for subsequent use.
  • the account holder is preferably given the option of deciding whether advertising is communicated in conjunction with the transaction information and the information is communicated to the server. Also, if the account holder may enter contact information for communicating budget information (step 206). For example, the account holder may enter the telephone number of the account holder's wireless device and the telephone number of the card holder's wireless device for receiving text messages of budget information as transactions are completed. Also, advertising may be sent via MMS messaging or other suitable communication means to such wireless devices.
  • FIGURE 3 depicts a flowchart for processing a financial transaction according to one representative embodiment.
  • the process of FIGURE 3 is implemented using suitable computer platform and suitable computer code executed by that platform.
  • the platform or server is adapted to communicate within a payment system and to perform the various authentication protocols associated therewith.
  • the server differs from known payment system servers in regard to the logic that server employs to decide whether to approve or deny a given transaction.
  • transaction information is received for approval or denial of a transaction within a payment system.
  • the transaction information may include account number, transaction amount, merchant id, store location, time information, etc.
  • product information may be included within the transaction information.
  • step 302 budget information is retrieved from a suitable database using the account number identified in the transaction information.
  • step 303 one or more budget categories matching the transaction information are identified. The time of day and day of week may also be used to identify the budget categories appropriate for the transaction. Alternatively, the card holder could have explicitly selected the budget category (before the transaction occurs) by "activating" a specific budget category for one or more purchases.
  • the "best" budget category is selected (or the "next" best depending upon whether one or more budget categories have already been examined).
  • the "best” or next “best” category refers to the level of specificity of the category. For example, the most specific matching sub-category of multiple hierarchical categories is preferably selected first and then more general categories are selected later.
  • the following categories could be applicable to pay for a meal purchased by a card holder: (i) EATING OUT/MEALS: dinner; (ii) EATING OUT/MEALS: misc.; and (iii) DISCRETIONARY.
  • the categories would be analyzed in that order (i.e., (i)-(iii)) due to the level of generality of those categories.
  • the level of generality is preferably defined by default for the predefined categories.
  • the account holder is preferably given the ability to define the level of generality relative to other categories during the budget creation process (see FIGURE 2).
  • step 305 a logical comparison is made to determine whether the respective budget category is active (if an activation rule is defined for the budget category). If so, the process flow proceeds to step 306. If not, the process flow proceeds to step 309.
  • step 306 a logical comparison is made to determine whether the transaction satisfies merchant, location, transaction, and/or product limitations for respective category. If so, the process flow proceeds to step 307. If not, the process flow proceeds to step 309.
  • step 307 a logical comparison is made to determine whether sufficient funds are currently available for the respective budget category (it may also be considered whether there are actually sufficient funds or credit available in the underlying account).
  • the amount of funds necessary for the comparison in regard to the budget category preferably depends upon whether funds (although not all the funds necessary for the transaction) were available for a prior category. For example, a transaction may involve a $50 amount. If $30 is available in a first budget category, thereafter the logical comparison in step 307 will determine whether $20 is available in another category (or split among multiple other categories). If so, the process proceeds to step 311 for approval of the transaction. If not, the process flow proceeds to step 308.
  • step 308 a logical comparison is made upon the basis of any over- budget rules. If an over-budget rule permits the card holder to go over the transaction by the excess of the transaction amount (or a reduced amount, see step 307) over the currently available funds for the budget category, the process flow proceeds to step 311 for transaction approval. If an over-budget rule prohibits any overage for the budget category, the process flow proceeds to step 310 for transaction denial. If "roll-over" to another budget category is allowed, the process flow proceeds to step 308 to step 309.
  • step 309 a logical comparison is made to determine whether another budget category is possible for the transaction. If so, the process flow returns to step 304. If not, the process flow proceeds to step 310 for transaction denial.
  • a transaction denial occurs by communicating a transaction denial message pursuant to the protocols of the respective payment system. Thereafter, the denial will be communicated back to the merchant and the card holder will have to pay using some other funds or forgo the transaction entirely.
  • a transaction approval occurs by communicating a transaction approval pursuant to protocols of the payment system.
  • step 312 the financial account linked to the card account is debited or charged for the transaction amount.
  • An electronic transfer of funds between accounts by various financial institutions/entities may occur immediately upon transaction approval (or the transfer may occur subsequently at the end of the business day or at another suitable time as customary within the payment system).
  • step 313 the amount of available funds for the various budget categories are reduced according to how the funds were allocated during the transaction processing.
  • step 314 updated transaction information is communicated (e.g., to the account holder and/or the card holder).
  • SMS messages are sent to the account holder and the card holder that indicate the amount of the transaction amount, the budget category/categories involved, and the amount of remaining funds for the budget category/categories.
  • Over-budget information or projected over-budget information may be included.
  • budget information is communicated using SMS messaging according to some embodiments, any other messaging may occur (e.g., via e- mail or via on a web page accessed at a later time, etc.).
  • an update message can be sent an SMS message as follows: lunches weekly amount: $45; spent $20; remaining: $25; projected over: $5 (in some embodiments, projected amounts can be provided after a plurality of purchases are made or the projected amount exceeds some threshold).
  • an update message can be sent to the user in an SMS message as follows: lunches weekly amount: $45; spent $25; remaining $20.
  • a message can be sent as follows: lunches weekly amount: $45; spent: $50; $5 removed from Entertainment to equal $45. It shall be appreciated that these messages are by way of example only.
  • FIGURE 4 depicts a flowchart for managing financial transactions associated with one or more card accounts according to one representative embodiment.
  • the process of FIGURE 4 is implemented using suitable platforms (e.g., a cellular phone and a server platform) and suitable software code executed by those platforms.
  • step 401 a communication connection is established between an account holder's wireless device and server using conventional mechanisms.
  • a MIDlet is distributed to the account holder's cellular phone or other wireless device. The MIDlet then conducts the communication between the cellular phone and the server and receives input from the account holder to obtain account management data.
  • step 402 the account holder is permitted to authorize or prohibit over- budget transactions.
  • step 403 the account holder is permitted to change budget limits associated with one or more budget categories.
  • step 404 the account holder is permitted to activate or inactive budget categories.
  • FIGURE 5 depicts a flowchart for managing financial transactions associated with one or more card accounts according to one representative embodiment.
  • the process of FIGURE 5 is implemented using suitable platforms (e.g., a cellular phone and a server platform) and suitable software code executed by those platforms.
  • step 501 a communication connection is established between a card holder's wireless device and a suitable server.
  • step 502 the card holder is permitted to select budget category for one or more subsequent purchase(s).
  • step 503 the card holder is permitted to activate budget category/categories (depending upon how the account holder has configured the account).
  • FIGURE 6 depicts a flowchart for managing budget limits according to one representative embodiment.
  • the process of FIGURE 6 is implemented using a suitable server platform and suitable software code executed by the server.
  • step 601 budget categories with left-over funds or over-budget amounts for budget period are identified.
  • step 602 roll-over rule(s) for the category/categories are retrieved as provided by the account holder or provided by default.
  • step 603 budget category limit(s) are modified for same or other budget category/categories according to roll-over rule(s).
  • the card holder may decide not to spend all of the available funds within the MEALS category, i.e., the card holder spends an amount for this category less than the defined budget limit.
  • the account holder may have defined a rule to permit the left over amount to be assigned to a DISCRETIONARY budget category. Accordingly, the DISCRETIONARY budget category is increased at the end of the budget period for the MEALS category.
  • advertisements are selected in terms of the budget information of account holders and/or card holders (such as any of the budget or financial information discussed above).
  • ads can be selected for communication depending upon the budget limits set for account holders and/or card holders.
  • ads can be selected in relation to over-budget or under- budget considerations (actual or projected over/under budget amounts) and/or in regard to the amount of any such over-budget or under-budget occurrence.
  • ads can be selected upon the basis of the remainder of unspent funds within one or more budget categories.
  • ads can be selected in regard to a per transaction limit defined for a budget category.
  • Ads can be selected in regard to the defined merchant information for budget categories. Alternatively, ads can be selected in regard to merchant information identified in the transaction information stored in a history of transactions by a card holder in one or more appropriate databases. Ads can be selected in regard to when/whether a card holder has made a purchase within a given category. For example, it may make little sense to send an ads for a certain type of grocery item, if the card holder has already made a purchase at a grocery store that day.
  • Such analysis can take into account other purchase history information (such as the typical number of transactions for a category within a given amount of time) and/or comparing such information against observed purchasing behavior. For example, if a card holder frequency spends more than $200 (at one or more merchants) when shopping for clothes and the card holder has been observed to have only spent $75 (at one or more merchants), it may be appropriate to send ads to that user. Specifically, based prior purchasing behavior, it is highly probable that the card holder will spend additional funds on clothing within a very short period of time. Accordingly, that card holder is a valuable candidate to target for the receipt of ads that attempt to direct the card holder to make purchase of specific products or at specific merchants.
  • a histogram is applied to analyze such purchasing patterns in which the percentile of purchases falling within various dollar ranges are maintained.
  • Historical timing of purchases can be utilized for the selection of ads. For example, certain discretionary purchases (clothing, entertainment, etc.) may be made more frequently by a card holder at a certain times of the month, certain days, certain times of day, etc. Alternatively, certain purchases may occur relative to certain defined events, e.g., the deposit of funds within an account (e.g., near payday where an automatic deposit of funds occurs).
  • Other purchase history information can be selected for the selection of ads. For example, if a card holder usually follows up a large transaction amount in a given category with a smaller transaction amount, such an observation can be utilized for ad selection. For example, if a card holder usually picks an inexpensive lunch the day after purchasing an expensive meal, such information can be utilized to select appropriate ads.
  • the budget and financial information can be selected in combination any other suitable information such as demographic information, product preferences, etc.
  • the budget and financial information is combined with location based information to select ads for communication.
  • the location of a card holder is obtained through location information associated with the card holder's wireless device (e.g., his/her cellular phone). Such information is used in conjunction with other appropriate information to communicate ads to the card holder. For example, different ads would be selected depending upon whether the card holder is at a clothing retailer at a mall versus at a big-box hardware store. Also, the timing of ads may depend upon such location information (e.g., when the card holder initially arrives at a given location, how long the card holder has been at a location, and when the card holder leaves a given location).
  • FIGURE 7 depicts a flowchart for communication ads to subscribers according to one representative embodiment.
  • the process of FIGURE 7 is implemented using a suitable server platform and suitable software code executed by the server.
  • ads are received from advertisers with target audience parameters.
  • the target audience parameters may include demographic information. Also, the target audience parameters may include various budget, financial, or past purchase history information, etc. as discussed above.
  • an LBS server preferably, identify when subscribers enter geographical location.
  • ads are identified for geographical area associated with the various subscribers, where the ads are selected to match the parameters of the ads to the various subscribers.
  • the most valuable ads are selected for and communicated to subscribers upon the basis of financial, budget, historical purchasing data, etc.
  • the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks. Any type of suitable code or software may be utilized from machine code, complied software, interpreted software, browser executable code (HTML, JAVA script, FLASH code, etc), "JAVA” variants, PYTHON scripts, and/or the like.
  • the program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium.
  • the "computer readable medium” may include any medium that can store or transfer information.
  • Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • the code segments may be downloaded via computer networks such as the Internet, an intranet, etc.
  • FIG. 1 A first figure.
  • CORRESPONDENCE ADDRESS CS. LEE CRAWFORD 12132 TERRAZZO LANE FRISCO, TX 75035 APPENDIX B
  • Location based services refer generally to services that provide information to a user in relation to the location of the user. At the present time, location based services are relatively pedestrian in nature and provide relatively simple information.
  • An example of a known location based service is a "weather" service in which the user's zip code is provided to the service (e.g., through a conventional HTML webpage, a WAP or other cellular phone interface, etc.) through a network and the service responds by communicating the current weather conditions and the forecast for several days.
  • Other known location based services provide "social" applications such as allowing users to determine each other's locations, receive notification when a friend comes within a predetermined distance, and similar operations.
  • Another type of location based services are generally referred to as "McDonalds finders" that provide search results in a map form (e.g., searching for specific locations of restaurants/stores within a given distance of the user).
  • Other location based services have proposed delivering various types of "advertising” (e.g., when a user arrives at an airport, various ads can be delivered to the user's cellular phone).
  • advertising location based services are quite simplistic and do not possess any appreciable intelligence for selecting advertisements beyond the location of the user.
  • Social network applications commonly refer to applications that facilitate interaction of individuals through various websites or other Internet-based distribution of content.
  • concept of a social network originated within the field of sociology as method of modeling social interactions or relationships.
  • individuals, groups, or organizations are represented as nodes within a social network and the relationships between the "nodes" are represented as links between the nodes thereby forming a "network.”
  • Social network applications have knowingly or unknowningly utilized such concepts to facilitate interaction between individuals via the Internet.
  • a specific user can create an account and provide various types of content specific to the individual, such as pictures of the individual, their friends, their family, etc., personal information in text form, favorite music or videos, etc.
  • the content is then made available to other users of the social network application (sometimes limited upon restrictions defined by the respective user).
  • one or more web pages may be defined for each user of the social network application that can be viewed by other users of the social network application.
  • social network applications typically allow a user to define a set of "friends,” “contacts,” or “members” with whom the respective user wishes to repeatedly communicate. Users of a social network application may post comments or other content to portions of each other's web pages.
  • a social network application refers to any application in which users are permitted to create or define accounts in which the users can make personalized content available via the Internet for viewing by other users of the social network application and, in which, users can define, allow, or create contacts or friends within the social network application in which repeated interaction is intended to occur through the social network application.
  • a method for operating a social network application comprises: capturing an image or video using a wireless device by a user of the social APPENDIX B
  • network application communicating the image or video from the wireless device of the user to a social network application server; storing the image or video by the social network application server; identifying a user account by the social network application server in response to communication of the image or video; and modifying data, by the social network application server, associated with the account of the user to automatically post the image or video to a web page of the user to make the image or video available for viewing by other users of the social network application.
  • FIGURE 1 depicts a system for implementing a social network application in which image and/or video data can be communicated between "friends" using a location based service scheme or otherwise according to one representative embodiment.
  • FIGURE 2 depicts a flowchart for creating and/or managing a social network application account according to one representative embodiment.
  • FIGURE 3 depicts a flowchart for communicating image and/or video data between users of a social network application according to one representative embodiment.
  • FIGURE 4 depicts a flowchart for communicating image and/or video data between users of a social network application according to another representative embodiment.
  • Some representative embodiments are directed to a social network application that permits users of the application to communicate image and/or video data using location based service functionality.
  • users of the social network upload image and/or video data to their accounts with the social network application using camera-capable wireless devices (e.g., digital camera enabled cellular phones).
  • location information is associated with the images or videos when transferred to the image/video server.
  • Certain images may be communicated to all or selected members of each user's group of "friends" or “contacts" according to a "location based service” scheme. For example, suppose a first user takes a picture at a nightclub and transfers the picture to the image/video server using their camera phone.
  • the other users may receive communication of the image or video via their cell phones.
  • the image and/or videos are relatively immediately (e.g., within a few minutes) communicated to one or more users who are friends of the first user irrespective of the location of the users.
  • FIGURE 1 depicts system 100 for operating a social network according to one representative embodiment.
  • a user can use their web browser 107 to access a web site served by social network application web server 106 through Internet 108.
  • the user can create an account for sharing personal information, digital content, etc. with other users of the social network application.
  • APPENDIX B
  • the user can define a user ID, password, etc. which can be stored in database (DB) 102.
  • DB database
  • the user can define a web page, upload content, etc. for their personal web page on the social network application, where the appropriate data is stored in DB 102.
  • the user can also allow family members, friends, co-workers, acquaintances, other social network application users, etc. to become “friends" in the social network application as defined by data stored in DB 102.
  • the users can provide appropriate information to facilitate the communication of image and/or video data using wireless devices of the users of the social network application (e.g., a phone number of the wireless device, the e-mail address/user information associated with the user's wireless device, etc.).
  • wireless devices of the users of the social network application e.g., a phone number of the wireless device, the e-mail address/user information associated with the user's wireless device, etc.
  • a JAVATM MIDlet is stored on the user's wireless device to facilitate the communication of the image and/or video data.
  • the user is provided a registration string and the user e-mails the registration string to a predefined e-mail address associated with the social network application. The user's e-mail information is automatically gathered from the registering user's e-mail.
  • a user token can be optionally defined for inclusion within subsequently communicated image or video messages. Only image or video messages from appropriate e-mail addresses containing suitable user information and/or the user token are accepted for posting to a user's web page(s) or communication to other users.
  • Database 102 stores identifiers of the user accounts, the friends of each user, content for each user's web page within the social network application, various user information, user identifiers, user passwords, user cellular phone numbers or e-mail addresses, etc. It shall be appreciated that when the present application discusss a database or server, any suitable computing architecture could be employed. For example, the desired functionality could be duplicated using multiple instances of software and multiple platforms. The various software and platforms could also possess a distributed architecture. Also, DB 102 need not be implemented using a strict database application. Any suitable set of software for storing and managing data could be employed. APPENDIX B
  • the users of the social network application can begin sharing image or video messages.
  • a user can take a picture or a video at a given location.
  • the user can transfer the image to e-mail server 104 or web server 106 as examples.
  • a MIDlet, a script, or another suitable program also is stored on the user's cell phone 110 to facilitate the transfer.
  • the MIDlet preferably allows the user to input metadata (e.g., a text description) to be associated with the image and/or video data. Other data could also be associated with the image or video such as audio data.
  • the MIDlet uses the cell phone functionality to determine the approximate location of the user's cell phone 110 (e.g., using the cell phone's 110 assisted GPS (AGPS) functionality), see e.g., the "location API" published for J2ME.
  • AGPS assisted GPS
  • the CELL-ID is obtained (e.g., using the appropriate API call using a PYTHON script on a Symbian OS- based cellular phones) for the purpose of automatically identifying the approximate location of the user's cell phone 110.
  • the identifiers of "Wi-Fi" hotspots can be obtained for the purpose of identifying the approximate location of the user's device (i.e., the identifiers are used to perform a look-up of the user location against a database that correlates Wi-Fi identifiers to GPS, addresses, ZIP codes, or other coordinates).
  • a "network- location” service is used to determine the location associated with the user's cell phone
  • the user can input the location in a user interface of the MIDlet.
  • the MIDlet Upon receiving/obtaining the information, the MIDlet preferably creates an e-mail or "multi-media message" (MMS) containing the various information (perhaps in encrypted form) with the image as an attachment and communicates the e-mail/MMS
  • MMS multi-media message
  • E-Mail/data server 104 may receive the image and the metadata and stores them in image DB 101. Other users within the social network may subsequently view the APPENDIX B
  • e-mail/data server 104 preferably communicates the image or video to the other users' cellular phones or wireless devices 110.
  • one or several advertisements are preferably sent to the user (and/or recipients of the image/video).
  • the location information is used to select one or several advertisements from advertisements DB 103.
  • the metadata is also used to select the one or several advertisements from DB 103 (e.g., using keyword matching and/or context analysis using the text description supplied by the given user). By utilizing such information, a more effective selection of advertisements can occur.
  • Multiple advertisements can be communicated to the user at a single time. For example, browser-executable files can be communicated to allow the user to browse through multiple ads. Some of the ads in the browser-executable files can be described in text format and some of the ads can be shown with images. Any suitable format for the advertisements may be employed such as SMS messages, MMS messages, etc.
  • a user can communicate an image or video to one or several other "friends" within the social network application on a substantially immediate basis.
  • Images and metadata can be shared in other ways. Users within the social network can view each other's images using their web browsers 107. Also, if desired, users within the social network could access the images via a browser executing on their cellular phone 110.
  • a user can communicate their current location (e.g., through manual data entry, through AGPS functionality of their phone, or automatically through a MIDlet) to obtain recently uploaded images or videos associated with "nearby" locations.
  • images or videos from a first user can automatically be communicated to friends of a first user when the friends arrive at locations where the first user had originally taken the images or videos.
  • the communication of image and/or video data is automatic. Specifically, when a user arrives at a given location, a MIDlet on the user's wireless device APPENDIX B
  • Web server 106 uses the location information to determine whether there are any images or videos from friends of the respective user associated with the current location of the user. If so, web server 106 communicates the images and/or videos to the user. For example, the images and/or videos may "pop-up" for presentation to the user when the user arrives at a specific location.
  • a users can access one or more webpages (e.g., through a typical web browser or, perhaps, a wireless device-specific browser) to view uploaded images from their friends.
  • the webpages preferably organize the images in multiple ways (e.g., by friend, by location, by types, by metadata descriptors, etc.).
  • the user can navigate through a series of links corresponding to the organization of the images and videos to browse through content of interest.
  • the user can submit a query for content of interest (of friends only and/or of other non- friend users) to receive search results from the database of images, videos, and metadata.
  • advertisements are preferably provided along with the images and videos - whether the user browses through the navigation links or submits a search query.
  • a user within the social network may be notified when friends of the user within the social network application are present at the same approximate location for the purpose of allowing the friends to meet each other. For example, suppose a first user of the social network arrives at "Willow Bend" mall. When another user who is a friend of the first user arrives at the mall, the first user can be notified of the arrival of the second user and the second user can be notified of the particular location of the first user (e.g., at store "X"). In one representative embodiment, an image or video message from the other user can be delivered with the notification.
  • AGPS functionality advanced location functionality
  • the location notification functionality can preferably be "turned” on and off by users of the social network application (if the users do not wish to be located at a particular time).
  • the image or video message can be intended for any friend or specifically addressed for an identified "friend” (i.e., it will only be delivered to the identified friend).
  • video or images can be made available for any users within the social network application. For example, when a first user arrives at a location, the user may submit a request to view any recent images or videos uploaded for the user's current location using a MIDlet on the user's wireless device. A number of images or videos from other users (whether friends or not) may then be communicated to the first user. A list of available images or videos can be presented to the first user to permit the first user to select specific content for viewing. Additionally, the first user may submit various search terms to identify images or videos of interest to the first user from all available images or content for the current location of the first user.
  • a user may define various criteria via their account that define the types of videos that the user wishes to receive (whether from friends or otherwise).
  • the social network application will then communicate matching image and/or videos to the user according to the defined criteria as the user goes from location to location.
  • FIGURE 2 depicts a flowchart for creating and/or managing a social network application account according to one representative embodiment.
  • a user accesses social network account creation web page.
  • the user enters e-mail address, creates user id, password, in accordance with typical account creation methods.
  • the user enters an identifier of the user's wireless device (e.g., the telephone number, the ESN/MIN, an e-mail address associated with an account maintained by the service provider of cellular services, etc.).
  • the user creates, uploads, or identifies personalized content for user web page(s) using typical web methods.
  • the user identifies friends with social network application.
  • the user defines access restrictions for user's web page(s).
  • the user can define restrictions that only permit certain users (e.g., only friends, only selected friends, users matching specific (demographic or otherwise) criteria) to view, access, or receive communication of certain types of content. For example, the user may only wish selected friends to receive images and video data via LBS functionality and the social network application will then only communicate such data to those friends.
  • the user downloads a MIDlet to wireless device for accessing social network application (e.g., uploading digital images or video).
  • the user is given instructions in a web page provided by the social network application during the account creation process how to access the MIDlet.
  • the user is preferably given a URL to enter in the browser of the user's wireless device to obtain the MIDlet and instructions upon how to install the URL on his or her phone.
  • the MIDlet may be personalized for the user to make performing different actions within the social network more efficient such as to communicate with specific friends with the social network.
  • a MIDlet may be pre-installed on a commercially available cellular phone or other wireless device and the user need only provide his or her account information (e.g., user ID, password, and/or the like) to make the MIDlet functional with regard to the user's account with the social network application.
  • his or her account information e.g., user ID, password, and/or the like
  • FIGURE 3 depicts a flowchart for communicating image and/or video data between users of a social network application according to one representative embodiment.
  • a user takes an image or video using camera of user's wireless device.
  • location information is associated with image or video.
  • the user enters text description to associate with image or video.
  • the user transfers image or video to social network server using wireless device. This may occur automatically by software on the user's wireless device in some embodiments.
  • the social network server automatically associates received image or video with the user's account (e.g., makes the image or video available on the user's web page(s)).
  • FIGURE 4 depicts a flowchart for communicating image and/or video data between users of a social network application according to another representative embodiment.
  • a social network server receives location information from a wireless device of a user.
  • the server compares location information to location information of stored images or videos.
  • the location information may be information
  • a user could input location information for association with images or videos independently from where the images or videos were taken.
  • location information may be associated with an image or video by entering known GPS coordinates, a street address, or by selecting a region or area on a map interface provided by the social network application.
  • the server selects matching images or videos based upon the sets of location information. Other information may be used for the matching such as any selection criteria provided by the user (e.g., from certain users, certain friends, keywords for matching in associated text descriptions, etc.).
  • the social network server communicates images or videos to the wireless device of user. Additionally or alternatively, the social network server may communicate a list of available images or videos, possibly with thumbnails or short descriptions of the available content. In 405, ads are selected and communicated to users by a suitable server.
  • Representative embodiments can be used for a variety of purposes to facilitate interaction between users of a social network application.
  • a company may implement a social network application to manage employees of the company according to various levels of corporate hierarchies.
  • the distribution of image and/or videos using location based services for such a social network application permits managers of the company to give specific direction and distribute information to employees when the employees are engaged in activities in the field.
  • a "dating" social network application may allow a first user who is seeking to meet new people to leave a video to be distributed to other users of the matching specific criteria for delivery at a specific location where the user is currently located (e.g., at a coffee house, bookstore, nightclub, etc.). Thereby, if any user matching the criteria arrives at the location, the image or video of the first user is
  • the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks.
  • Any type of suitable code or software may be utilized from machine code, complied software, interpreted software, browser executable code (e.g., HTML, JAVA script, FLASH code, etc), "JAVA” variants, PYTHON scripts, and/or the like.
  • the program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium.
  • the "computer readable medium” may include any medium that can store or transfer information.
  • Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • the code segments may be downloaded via computer networks such as the Internet, an intranet, etc.
  • FIG. 3 APPENDIX C
  • the efficiency of search operations using conventional search engines has significantly lessened.
  • a keyword search provided by a user to a search engine can present a very large number of "hits" for a user to traverse.
  • the "hits" may include a large number of documents that contain the keywords in a manner not contemplated by and, typically, in an irrelevant manner to the searching user. Accordingly, the user typically must provide multiple queries in an attempt to locate documents of interest.
  • a method of operating a search engine comprises: initiating a continuous search state from a user; receiving multiple search queries during the continuous search state; and providing search results to the user, wherein the providing filters search results previously presented to the user in response to prior search queries during the continuous search state.
  • FIGURE 1 depicts a web page for initiating a continuous search according to one representative embodiment.
  • FIGURE 2 depicts a response web page for a search engine for a continuous search according to one representative embodiment.
  • FIGURE 3 depicts a web page including search results presented in a manner for user review according to a continuous search according to some representative embodiments.
  • FIGURE 4 depicts a web page after re-sorting operations occur according to one representative embodiment.
  • FIGURE 5 depicts a web page to display stored search results according to one representative embodiment.
  • FIGURE 6 depicts a web page with various prior search terms according to one representative embodiment.
  • Representative embodiments enable a user to search for documents via a search engine over multiple independent or related queries on an efficient basis.
  • some representative embodiments enable a "continuous" search using an Internet search engine to be conducted in which documents can be saved in association across multiple search queries, documents excluded from subsequent query results, documents types of relevance and irrelevance identified for sorting of present and subsequent queries, and/or other such operations spanning multiple search queries.
  • Internet searches can be conducted in an efficient manner.
  • FIGURE 1 depicts web page 100 for initiating a continuous search according to one representative embodiment.
  • Web page 100 includes the typical graphical controls present in search engines to enter information defining a search query.
  • Web page 100 also includes control 150 (e.g., a "button" or, alternatively, a hyperlink) that allows a user to start a continuous search.
  • control 150 e.g., a "button” or, alternatively, a hyperlink
  • button 150 By selecting button 150, the selection is communicated to one of the web servers associated with the search engine via typical HTTP processing.
  • the button allows the user to ability to enter the continuous search mode (i.e., the review or resume prior continuous searches or to start a new continuous search).
  • Web page 200 includes the same controls as web page 100 for defining search query terms.
  • the web query term controls shown in FIGURE 2 are by way of example. Any suitable set of query term controls could be utilized according to representative embodiments.
  • Web page 200 further includes control 210 for entering a name for the continuous search for further identification to the user (assuming the user wishes to start a new continuous search).
  • Web page 200 further includes list 220 having a list of hyperlinks for prior searches (should the user wish to resume or review a prior search). Depending upon the number of saved searches, additional controls (not shown) could be provided to allow the user to review other searches not immediately displayed in web page 200.
  • the search engine stores a "cookie" on the user system to allow the search engine to identify the user for the presentation of the prior searches of the user.
  • the user can enter a user id and/or password via an intermediate web page to allow the user to retrieve and control the user's continuous searches.
  • web pages 100 and 200 could be integrated into a single web page if desired.
  • search results are generated and sorted according to conventional search engine operations.
  • a first web page of search results is communicated to the user.
  • search file(s) are created to save information for the continuous search.
  • the created search file(s) are associated with the user and the search name.
  • web page 300 illustrates search results presented in a manner for user review according to a continuous search according to some representative embodiments.
  • the typical search results information can be provided such as the titles of the web pages, summary information of the web page (perhaps, including a portion of text from the result document containing the keyword(s)), and other such information.
  • the search results can include hyperlinks (shown as 301 and 302) to allow the user to review the particular result documents.
  • the hyperlinks cause the document(s) to be presented in a separate "pop-up" window of the browser.
  • Web page 300 may also include typical controls for navigating the search results (previous page button 321, next page button 322, go to page control 323, etc.)
  • Each of the search results is preferably associated with one or several controls for continuous search operations.
  • the user can store a reference to a web page using store control 311 (which is preferably a "check-box" or "radio" control).
  • store control 311 which is preferably a "check-box" or "radio" control.
  • the user can also cause a particular page to be excluded from subsequent search results using control 312.
  • a particular page can be APPENDIX C
  • Control 313 enables the user to indicate that the respective document is the type of document that the user wishes to review during the continuous search.
  • control 314 enables the user to indicate that the respective document is not the type of document that the user wishes to review during the continuous search.
  • controls 311 - 314 do not operate to transfer information immediately upon selection. Instead, the selections associated with controls 311 - 314 are communicated when one of the page controls 321, 322, or 323 or continuous search buttons 324 - 328. Specifically, when one of these buttons or controls are activated by the user, the page information is communicated to a server of the search engine via conventional HTTP operations. The search engine then updates the continuous search file(s).
  • an identifier of the particular document e.g., the URL, the date associated with the time that the web crawler indexed the URL, etc.
  • each identified document e.g., the HTML page, the associated object/image files, etc.
  • the benefit of storing the identified documents is the search can be reviewed at substantially later dates (e.g., after the original documents have been removed from the Internet or otherwise modified).
  • the identifier(s) of the "excluded" document(s) is/are stored. These stored URLs are preferably used to filter these documents from the results generated from subsequent queries. In alternative embodiments, all of the documents identified in a result page are stored in an "exclude" file for filtering results from subsequent search queries within the continuous search.
  • the URL(s) is/are stored in a search file(s).
  • a similarity metric is calculated for each search result against each of the documents identified using APPENDIX C
  • the similarity metric can be calculated using any suitable known or later developed document comparison algorithm. If a search result document is similar to one or several "this type" previously identified documents, the search result document is given a higher weight for the sorting algorithm. If a search result document is similar to one or several "not this type” previously identified documents, the search result document is given a lower weight for the sorting algorithm.
  • the user can re-sort the current search results using re-sort control 327 as affected by the selection of any of controls 313 and 314.
  • the user can alternatively decide to change the current search terms or enter an entirely new set of search terms using control 326.
  • control 326 Upon selection of control 326, the user can be presented web page 400 as shown in FIGURE 4. Additionally, the user could review the previously presented search terms by selecting control 325. Web page 600 (as shown in FIGURE 6) with various prior search terms 611 could be presented in a pop-up window in response to the selection of control 325. If the user wishes to end or temporarily suspend the continuous search, the user can depress control 328.
  • the user can be taken to a predefined web page (e.g., a "portal page") upon selection of control 328. Also, when the user selects control 328, the state information at the server(s) of the search engine and/or within a cookie on the user system can be modified to reflect the end/suspension of the continuous search.
  • a predefined web page e.g., a "portal page”
  • control 324 If the user wishes to review the stored search results, the user may select control 324. Upon selection, web page 500 as shown in FIGURE 5 can be generated to display stored search results 521. If the user wishes to review the actual document, the user can click on one of the titles and, preferably, the actual document is displayed in a pop-up window. If user can "unstore" the document using control 511 which causes the identifier of the document to removed from the search file(s). Alternatively, the user could choose to "exclude” the document using control 312. Right kind and wrong kind controls 313 and 314 could also be included within web page 500. Depending upon the number of stored results, controls 321, 322, and 323 could be provided to navigate between multiple pages of stored results. The user could return to the current results generated by the most recent search terms using control 531. Also, in one embodiment, APPENDIX C
  • search term(s) 551 associated with each stored result could be shown adjacent to the respective stored search result.
  • Some representative embodiments enable a user to conduct an Internet or other search in a substantially efficient manner.
  • a user can quickly review a number of hits, identifying potentially relevant hits, and store the potentially relevant hits for further review.
  • the user can quickly revise the search without losing the stored hits.
  • the user need not repetitively review information that the user has already seen. Specifically, when additional search results are presented in response to revised search terms or new search terms, hits that were deemed irrelevant need not be re -reviewed by the user.
  • the user can also suspend the search at any point and resume the search at a later time if desired.
  • the stored documents can be cached by the search engine to ensure that the user can retrieve the documents at a later time even if the documents become modified or are removed from their original web servers.
  • the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks.
  • some of the software is implemented using a freely available web server (such as the APACHE web server) and custom PERL scripts for implementing the continuous search functionality.
  • some of the software may be executed on a search user's computing platform and may include machine code, complied software, interpreted software, browser executable code via a "plug-in" or otherwise (e.g., HTML, JAVA script, FLASH code, etc), and/or the like.
  • the program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium.
  • the "computer readable medium” may include any medium that can store or transfer information. Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc.
  • the computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc.
  • the code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
  • FIG. 1 A first figure.
  • FIG. 4 PREVIOUS NEXT GO TO D

Abstract

In one embodiment, a method of providing a location based service (LBS), comprises; receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information, by one or more software programs, to identify specific activities of subscribers at merchant locations from a plurality of predefined set of activities; storing identified activities in a respective activity log for each of the plurality of subscribers; comparing ad parameters against subscriber data, including data stored in the activity logs, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have already completed one or more activities as identified in the respective subscribers' activity logs; and communicating selected ads to wireless devices of the subscribers.

Description

LOCATION BASED SERVICE FOR DIRECTING ADS TO SUBSCRIBERS,
TRANSACTION CARD ACCOUNT CONTROL, SEARCH ENGINE OPERATION,
SOCIAL NETWORK APPLICATION COMMUNICATION, AND OTHER
INVENTIONS
RELATED APPLICATIONS
[0001] Under Patent Cooperation Treaty (PCT) conventions, this application claims priority to (i) U.S. Patent Application Serial No. 11/559,438, filed 14-NOV.-2006; (ii) U.S. Patent Application Serial No. 11/623,832, filed 17-JAN.-2007; (iii) U.S. Provisional Patent Application Serial No. 60/864,807, filed 08-NOV.-2006; and (iv) U.S. Provisional Patent Application Serial No 60/917,638, filed 1 l-MAY-2007. Under 35 U.S. C. § 120, the application is a (i) a continuation-in-part of U.S. Patent Application Serial No. 11/559,438, filed 14-NOV.-2006 (which claims the benefit of U.S. Provisional Application Serial No. 60/736,252, filed 14-NOV.-2005, U.S. Provisional Patent Application Serial No. 60/759,303, filed 17-JAN.-2006 and U.S. Provisional Patent Application Serial No. 60/773,852, filed 16-FEB.-2006); (ii) a continuation-in-part of U.S. Patent Application Serial No. 11/623,832, filed 17-JAN.-2007; (iii) a continuation- in-part of 11/747,286, filed 1 l-MAY-2007; (iv) claims benefit to U.S. Provisional Patent Application Serial No. 60/864,807, filed 08-NOV.-2006; and (v) claims benefit to U.S. Provisional Patent Application Serial No 60/917,638, filed 1 l-MAY-2007; all of the preceding applications are incorporated herein by reference.
BACKGROUND
[0002] Location based services refer generally to services that provide information to a user in relation to the location of the user. At the present time, location based services are relatively pedestrian in nature and provide relatively simple information. An example of a known location based service is a "weather" service in which the user's zip code is provided to the service (e.g., through a conventional HTML webpage, a WAP or other cellular phone interface, etc.) through a network and the service responds by communicating the current weather conditions and the forecast for several days. Other known location based services provide "social" applications such as allowing users to determine each other's locations, receive notification when a friend comes within a predetermined distance, and similar operations. Another type of location based services are generally referred to as "McDonalds finders" that provide search results in a map form (e.g., searching for specific locations of restaurants/stores within a given distance of the user). Other location based services have proposed delivering various types of "advertising" (e.g., when a user arrives at an airport, various ads can be delivered to the user's cellular phone). However, such advertising location based services are quite simplistic and do not possess any appreciable intelligence for selecting advertisements beyond the location of the user.
SUMMARY
[0003] In one embodiment, system for providing one or more location based services, comprises: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to: (i) store location information for subscribers associated with the one or more wireless devices; (ii) process the location information using data defining known activities associated with predetermined locations; (iii) create or maintain one or more logs of information for each respective subscriber, each log containing information indicating activities of the subscribers; and (iv) select ads for communication to the subscribers, the selection of ads comparing ad selection parameters against activity information stored in the logs.
[0004] In another embodiment, the activities identified in the logs are defined in a hierarchical manner. In another embodiment, the logs identify when an activity has been completed. In another embodiment, the logs indicate completion of financial transactions with merchants.
[0005] In one embodiment, the server for LBS services comprises: one or multiple databases storing information identifying subscribers of one or several LBS applications, wherein the one or multiple databases identifies groups of subscribers that have been detected to be located in close physical proximity on multiple occasions; one or multiple databases for storing advertisements to subscribers; code for determining whether subscribers are currently clustering based upon location information pertaining to subscribers; and code for selecting and communicating advertisements to subscribers based on locations of the subscribers, wherein the code for selecting and communicating determines selects ads for subscribers depending upon whether subscribers have been determined to be clustering.
[0006] In another embodiment, a method comprises the operations performed by the one or more first programs, by the one or more second programs, and/or the LBS applications.
[0007] In another embodiment, a method of providing a location based service (LBS), comprises: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information, by one or more software programs, to identify activity of subscribers at merchant locations; maintaining a respective profile, by one or more software programs, for each of the plurality of subscribers that reflects norm shopping activity for the respective subscriber; comparing information pertaining to current or recent shopping activity, by one or more software programs, for each subscriber of the plurality of subscribers against information stored in the profile of the respective subscriber; selecting ads, by one or more software programs, for each subscriber of the plurality of subscribers in relation to the comparing; and communicating, by one or more software programs, the selected ads to plurality of wireless devices belonging to the plurality of subscribers.
[0008] The selects ads can be communicate to wireless devices while the plurality subscribers are conducting current shopping activity. In another embodiment, each profile comprises one or more activity norm parameters for a plurality of merchant types. [0009] In another embodiment, each shopping behavior profile stores information related to a number of purchases typically conducted by the respective subscriber, wherein the selecting compares a number of recent purchases made by the respective subscriber against information stored in the respective subscriber's shopping behavior profile to select ads for communication to the respective subscriber.
[0010] The foregoing has outlined rather broadly certain features and/or technical advantages in order that the detailed description that follows may be better understood. Additional features and/or advantages will be described hereinafter which form the subject of the claims. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the appended claims. The novel features, both as to organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIGURE 1 depicts a system in which multiple LBS applications provide location based services to multiple subscribers and in which advertisements can be directed to the multiple subscribers using multiple types of information according to one representative embodiment.
[0012] FIGURE 2 depicts a block diagram of a subscriber device adapted for delivery of advertisements according to one representative embodiment.
[0013] FIGURE 3 depicts a flowchart for identifying clustering according to one representative embodiment. [0014] FIGURE 4 depicts a flowchart for processing cluster data according to one representative embodiment.
[0015] FIGURE 5 depicts a flowchart for utilizing cluster information according to one representative embodiment.
[0016] FIGURE 6 depicts a flowchart for utilizing cluster information according to another representative embodiment.
[0017] FIGURES 7-14 depict activity norm summary information that can be compiled or calculated for use in selecting ads to communicate to subscribers according to some representative embodiments.
[0018] FIGURES 15-17 depict respective flowcharts for processing activity information and/or financial transaction information to generate respective norm parameters for storage in subscriber profiles according to some representative embodiments.
[0019] FIGURES 18 and 19 depict activity norm profiles and for different merchant types according to some representative embodiments.
[0020] FIGURE 20 depicts activity norm analysis that cross-correlates selected financial transaction behavior to other subscriber behavior.
[0021] FIGURE 21 depicts activity norm analysis that cross-correlates selected activities and/or sub-activities to financial transactions according to one representative embodiment.
DETAILED DESCRIPTION
[0022] Some representative embodiments are directed to systems and methods for monitoring data associated with users of location based services and directing advertisements to the users. [0023] Referring now to the drawings, FIGURE 1 depicts a system in which multiple LBS applications and other applications 101 provide location based services to multiple subscribers 104 and in which advertisements can be directed to the multiple subscribers 104 using multiple types of information. Applications 101 may include one Or more social network application such as the social network applications described in APPENDIX B. Applications 101 may include one or more search applications such as the search applications described in APPENDIX C.
[0024] As shown in FIGURE 1 , there are preferably a plurality of LBS applications 101 (executed one or more servers or other suitable platforms) that provide location based services to subscribers 104. LBS applications 101 can provide conventional location based services such as map/navigation services, weather services, local merchant search services, etc. The LBS applications 101 can further include financial or shopping location based services as described in U.S. Provisional Patent Application No. 60/736,252, filed Nov. 14, 2005, 60/759,303, filed 01/17/2006 and 60/773,852, filed 02/16/2006, which are all incorporated herein by reference in their entirety. LBS applications 101 can include "social" LBS applications or gaming LBS applications that facilitate different types of subscriber interaction. LBS applications 101 receive location information that is indicative of the current location of subscribers 104 and communicate LBS information to the subscribers 104 according to the location information either upon request by the subscribers 104 or automatically depending upon the nature/purpose of the particular LBS application 101. The application data is preferably communicated through Internet 102 and a wireless network 103 (e.g., a cellular network) to subscribers 104. The subscriber devices 104 can be any type of suitable wireless device (e.g., cellular phones, "smartphones," wireless e-mail devices, wireless capable PDAs, etc.) that possess the ability to determine their approximate current location or communicate through a network that enables the approximate location to be determined.
[0025] LBS applications 101 also communicate with LBS gateway/web service 105. In preferred embodiments, subscribers 104 communicate their current location to LBS gateway/web service 105. Also, as subscribers 104 wish to access various LBS applications, subscribers 104 communicate their activation of an LBS application to LBS gateway/web service 105. Gateway/web service 105 then intermediates communication between the selected LBS application(s) 101 and the respective subscribers 104. Thus, subscribers 104 can access multiple LBS applications through the same source. Also, subscribers 104 only need to communicate their current location to the same destination which is then available to any LBS application 101 as appropriate.
[0026] Although LBS gateway/web service 105 provides such gateway services, the gateway services are not critical to all embodiments. In alternative embodiments, LBS applications 101 can report to web service 105 (i) the current location of subscribers 104 to web service 105 as subscribers 104 utilize their respective applications and (ii) when a respective subscriber 104 accesses an application and ceases use of the application (if applicable).
[0027] Gateway/web service 105 maintains a log of locations where subscribers 104 visited in DB 107. Also, LBS application 101 maintains a log of interaction with or access to particular LBS applications 101. Additionally, gateway/web service 105 preferably maintains a log of financial transactions completed by various LBS subscribers as identified by financial LBS applications 101 (e.g., a budget LBS application, a fraud monitoring LBS application, etc.) and communicated to gateway/web service 105.
[0028] Gateway/web service 105 utilizes the location information, LBS application interaction information, and/or financial information to infer the activities performed by the subscribers and the current activity being performed by the subscribers. The logs of activities for subscribers and current activities being performed are stored in DB 107. The logs of activities enable more accurate selection of ads, incentives, offers, etc. to be directed to subscribers as will be discussed below.
[0029] In some embodiments, the following activities and sub-activities are defined: (i) commuting; (ii) work; (iii) school; (iv) dining - (a) fast food; (b) casual;...fine dining; (v) entertainment - (a) movie; (b) music venue;...bar; (vi) sports/recreation - (a) health club; (b) golf; (c) athletic complex/fields;...gaming; (vii) shopping - (a) groceries; (b) gas; (c) clothing, shoes, accessories; (d) home decoration; (e) home improvement;...sports equipment; (viii) social; (ix) traveling/vacation, etc. Of course, these activities and sub-activities are by way of example and any other activities and/or sub-activities could be additionally or alternatively employed. Also, it shall be appreciated that the activities need not be mutually exclusive in that a single subscriber could be engaged in multiple activities at the same time. The information can be encoded in any suitable ontology. For example, a hierarchical classification of the types of locations could be formulated. In one embodiment, specific merchants are defined within the hierarchical framework within shopping related activities. An example branch in such a hierarchical framework could be RETAIL: shopping: big-box store: TARGET®: grocery section. In alternative embodiments, any such hierarchical descriptors assignable to locations that indicate the nature of the activity being undertaken by a subscriber may be employed. Importantly, in some embodiments, many of the activities and sub- activities are related to activities at physical locations (e.g., specific locations, specific merchants, etc.).
[0030] In some embodiments, a current activity of a subscriber can be inferred from the type of LBS application 101 that the subscriber is accessing. For example, if a subscriber is utilizing a navigation LBS application and the subscriber has not reached their destination, it may be inferred that the subscriber is commuting. If a subscriber is utilizing a social application, certain activities (work, school, etc.) can be eliminated while other activities can possess a greater probability (e.g., dining, entertainment, etc.). Accordingly, when gateway/web service 105 attempts to infer the current activity of a subscriber, gateway/web service 105 identifies the LBS applications 101 that are currently active for the subscriber.
[0031] In some embodiments, gateway/web service 105 utilizes information in DB 106 to infer the activity of the user. In general, DB 106 correlates specific locations to one or several specific activities. For example, DB 106 can be constructed by "mapping" the addresses or coordinates of residential areas, retail districts, schools, health care facilities, sports/athletic facilities, etc. to the particular activities that are customary to those types of locations. Additionally, DB 106 includes information at several geospatial "resolution" levels. In some embodiments, DB 106 comprises geo- coordinates or other spatial information that define (i) various retail districts at a higher level, (ii) specific malls, strip-malls, stand-alone stores, etc. within a retail district, (iii) specific stores; and (iv) sub-store locations. In sub-store locations, the specific goods or specific service provided can be identified. By maintaining a log of the locations visited by a subscriber and the amount of time spent at the locations, the activities of a user can be estimated. Sub-store locations can be determined utilizing any number of mechanisms and/or algorithms. For example, a GPS receiver could be employed provided the GPS receiver possesses sufficient antenna gain and sufficient reception within the store. Alternatively, many retail locations utilize multiple WiFi access points. The particular ID's of the WiFi access points that are detectable and/or the relative signal strength of the WiFi access points can be utilized for a intra-store location determination. Also, sub- store locating functionality can be utilized to ascertain whether a subscriber has made a purchase at a particular merchant. For example, if a subscriber has spent an amount of time near a location where a cash-register is known to be present and the subscriber leaves the store after being at that location, it may be inferred that the subscriber has made a purchase at that store.
[0032] Financial information captured by financial related LBS applications 101 can be used to augment the identification of subscriber activities. In such financial related applications 101, the applications monitor user accounts for the completion of transactions (e.g., credit or debit card transactions). Using the merchant information (merchant ID, merchant name, merchant classification, etc.) in the transaction information, the activity can be more closely estimated. For example, if a user is located within a mall and the user previously purchased items at a clothing store, the specific current shopping activity can be inferred to include clothing shopping even though the user may temporarily depart from stores containing such items. Alternatively, transaction information may signal that a particular activity has been completed by the user. For example, if a user makes a purchase at a grocery store that is typical for their weekly grocery purchases, one can conclude that the user will not be conducting further significant grocery shopping for some amount of time. Transaction information can be obtained using the systems disclosed in U.S. Patent Application No. 11/623,832, filed Jan. 17, 2007 which is attached hereto as APPENDIX A.
[0033] As an example of a user log could be given by: 6:00am-8:30am: undefined; 8:30am-9:00am: banking; 9:15am-10:20am: grocery shopping; 12: 15pm- 1:00pm; dining (fast food); l:30pm-2 :00pm: commuting: 2:00pm: begin shopping (clothing): clothing purchase made at 2:35 at young women's depart, of dept. store retailer. In some representative embodiments, logs can be reviewed by advertisers, although the specific identity of subscribers are preferably not reviewable. In alternative embodiments, the logs are not actually reviewable by advertisers. Instead, the logs are merely maintained in DB 107 and advertising parameters are compared against the information in the logs to direct advertisements.
[0034] By providing such a log of activities (previously performed and currently performed), a more intelligent selection of ads for communication to the subscriber can occur. For example, when the grocery shopping activity has been completed, selection of ads for specific grocery items will have relatively little value. Depending upon the purchasing behavior of the subscriber, it may be advantageous to send the subscriber clothing-related advertisements while the subscriber is clothing shopping (even after one or several purchases have been made). Alternatively, if the subscriber has already spent more than the subscriber usually spends as reflected t in the prior purchases, it may not be advantageous to send more clothing advertisements since the subscriber may have already spent their limit and is only currently "browsing," i.e. the probability of further purchases can be estimated as being low.
[0035] In some embodiments, activity norms and financial norms are calculated by observing subscriber behavior over a period of time. For the purpose of this application, the term "norm" parameter refers to a parameter that is indicative of a general level or average for the particular subscriber. For example, for grocery shopping norms, the typical period between grocery shopping (e.g., in days), the typical day(s) for grocery shopping, the average amount spent, the range of amounts spent, the standard deviation of amounts spent, the type of stores in which grocery shopping occurs, etc. can be compiled from location information and financial information obtained by LBS applications. As another example, for clothing-type shopping norms, the typical day(s) for shopping, the average amount spent, the standard deviation of amounts spent, the number of transactions per shopping event, the average amount of time spent shopping at a particular retail location and/or per day, the types of stores visited, etc. can be compiled, the types of items purchases (if known), etc. can be compiled. Also, correlation between activities can be compiled. For example, it may be observed that a particular subscriber may routinely engage in a "dining (fast food)" activity after engaging in "recreation - sports complex" activity. Subscriber activity and/or financial norms are then compared against subscriber's more recent activities for the purpose of ad selection.
[0036] By compiling such information, intelligent selection of ads for subscribers may occur. In preferred embodiments, advertisers upload ads into ad DB 109 through ad server 108. Also, the advertisers specify any specific ad parameters for association with their various ads. The ad parameters are compared by ad server 108 against subscriber information and the activity information and norm information in DB 107. When the information in DB 107 satisfies the ad parameters for particular subscribers, the respective ad(s) are communicated to those subscribers by ad server 108. Any other ad selection criteria can be employed. For example, the ads of certain advertisers can be prioritized based upon purchased ad placements. The payment for placement of ads may include payments to prioritize ad placement according to any ad parameter discussed herein or in the related APPENDICES. For example, payments for ad placements may occur according to purchasing norm parameters, clustering parameters, shopping timing parameters, etc. which are discussed below. The payments for ad placements may also utilize any such parameters in combination or in combination with other subscriber data. For example, an advertiser may pay for ad placements for subscribers that typically spend greater than $200 per shopping trip, shop at a specific type of retail establishment, and that fit a given demographic profile. All such combination of ad parameters are contemplated according to some representative embodiments.
[0037] Referring now to FIGURE 2, subscriber device 200 is shown that is adapted for delivery of advertisements according to one representative embodiment. Subscriber device 200 can be any suitable wireless device, such as a cellular phone, that is capable of executing software instructions. The software instructions on subscriber device 200 preferably include multiple LBS applications 203. The local LBS applications 203 contact remote LBS applications 101 to deliver the application location based information to the subscriber. Subscriber device 200 further includes LBS agent 201. LBS agent 201 preferably manages or intermediates the communication of location LBS applications 203 with remote LBS applications 101. LBS agent 201 preferably forwards location information to the appropriate LBS applications 101 at times defined by the respective applications. Also, LBS agent 201 receives messages from LBS applications 101 and forwards the messages to the respective local LBS applications 203 as appropriate. LBS agent 201 simplifies the implementation of LBS applications 203 and prevents conflict or difficulties in the execution of local LBS applications 203. Also, LBS agent 201 can manage updates to any LBS functionality that is common to all LBS applications 203 or one or several specific LBS applications 203.
[0038] Subscriber device 200 further comprises software for presenting ads to subscribers in an efficient manner. In one embodiment, subscriber device 200 comprises ticker software application 204 and ad detail menu application 205. In preferred embodiments, some ads are communicated to LBS agent 201 of subscriber device 200 using SMS messaging. The SMS messages preferably detail how the ad is to be presented to the subscriber. Preferably, the SMS messages detail whether the ad is to be placed into a ticker, for how long, and what particular text is to be displayed in the ticker. A ticker generally refers to a scrolling stream of characters on a screen of the wireless device (e.g., that mimics a "ticker-tape" in electronic form). LBS agent 201 provides the appropriate information to ticker software application 204 to display to the user when the user reviews the screen of subscriber device 200 (e.g., when the subscriber opens his/her phone). Also, the SMS messages preferably detail information to be placed in a menu type form that provides a more detailed presentation of ads for subscriber review. Also, should a subscriber desire to view additional detail for an ad or download a digital coupon, a hyperlink can be included for user selection that causes browser application 206 to download the corresponding content. [0039] In some embodiments, "digital coupons" are communicated to subscriber devices 104 through the ad selection functionality of ad server 108 and ad DB 107. The digital coupons are preferably implemented by use of a digital image encoded according to a digital rights management (DRM) scheme. The digital image can display the "coupon" details, such as product/store/location/purchase conditions, the amount of the coupon, etc. Also, the digital image preferably includes a "code" (e.g., an alphanumeric string) that authenticates the validity of the coupon. When a subscriber wishes to use a digital coupon, the user can present the screen of the subscriber device 104 displaying the digital coupon to a clerk of a merchant. A merchant that has previously agreed to accept such digital coupons can enter the code into the merchant's POS device during a transaction. The merchant's system can then determine the validity of the coupon in real-time by communicating the code to a suitable server. Upon determining the validity of the coupon, the merchant's POS device can suitably adjust the transaction total. Also, the merchant's system can use the code to obtain settlement of the coupon amount at a later appropriate time using the code.
[0040] The DRM functionality can be used for several purposes in the digital coupon process. In some embodiments, the DRM functionality ties the digital coupon to a specific subscriber device 104, i.e., the digital image is not decrypted by other subscriber devices. Also, in some embodiments, location information can be encoded within the DRM rules. For example, spatial coordinates and a radius distance can be defined such that the digital image is only decrypted by the DRM software when the user is within the area defined by the spatial coordinates and the radius distance (to ensure that the coupon is only presented at desired retail locations/merchants, etc.). That is, the DRM software accesses the current location of the subscriber device 104 and selectively decrypts the digital image by comparing the current location to the location rules defined in the DRM license associated with the digital coupon.
[0041] In some embodiments, a short "ad" of several seconds (e.g., a promotional video) is incorporated with a digital coupon. When a subscriber initially reviews the digital coupon, the promotional video is played. After the promotional video is played, the digital image containing the coupon information is then displayed. The DRM license can contain a DRM rule that causes the video to be deleted upon review for the purpose of minimizing the memory usage of the digital coupon over time.
[0042] Some representative embodiments can provide a number of advantages. For example, by maintaining a database of sub-locations within specific stores and the types of goods at those sub-locations, intelligent selection of ads for delivery to subscribers can occur. For example, in ordinary e-advertising and LBS advertising, it is most likely never useful to communicate an advertisement for an inexpensive, somewhat common-place food item. That is, the ad will have a very low probability of affecting the subscriber's purchasing activities. However, if it is known that a subscriber is standing in a particular grocery aisle of a "big-box" retailer that contains that type of food item according to representative embodiments, communication of such an ad may make economic sense because the probability of the ad being successful in affecting the purchasing behavior is much higher than if the ad were communicated when the subscriber is at another type of location.
[0043] Additionally, by providing a log of activities, selection of ads for subscribers can occur in a much more efficient and effective manner that possible according to conventional LBS applications. That is, subscriber activities provide a more reasoned basis for estimating the appropriateness of an ad for a subscriber than the mere current location of the subscriber. Also, by aggregating data over time and data from multiple sources, the activities of a subscriber can be more accurately inferred. Also, by compiling historical norms, the effectiveness of an advertisement in affecting immediate purchasing behavior can be more readily determined.
[0044] FIGURES 7-14 depict activity norm summary information 700, 800, 900, 1000, 1100, 1200, 1300, and 1400 that can be compiled or calculated for use in selecting ads to communicate to subscribers according to some representative embodiments.
[0045] FIGURE 7 depicts activity summary profile 700 according to one representative embodiment. Activity summary profile 700 stores information that indicates the amount of time spent by a subscriber for a plurality of activities. Also, the information is provided in a hierarchical manner. Specifically, the amount of time is shown for various sub-activities. As shown in FIGURE 7, for ACTIVITY 1, the average amounts of time spent for ACTIVITY 1 per day of the week (Sunday through Saturday) are represented by parameters Vl -V7. The standard deviations for the amounts of time spent for ACTIVITY 1 per each day of the week are represented by parameters sl-s7. The average amounts of time spent per week and per month for ACTIVITY 1 are represented by parameters V8 and V9 and the standard deviations for time spent per week and per month are represented by s8 and s9. In a similar manner, average amounts of time and standard deviations are shown for SUB ACTI VITIE S, i.e., (V'l-V'9, s'l-s'9) for a first sublevel activity and (V"l-V"9, s"l-s"9) for a second sublevel activity. Any suitable number of subactivities and levels of subactivities could be so provided. As shown in FIGURE 7, this type of information is repeated for a plurality of activities (through "ACTIVITY W).
[0046] FIGURE 8 depicts activity probability profile 800 according to one representative embodiment. Activity probability profile 800 is defined for one day of the week (i.e., Sunday). Preferably, similar profiles (not shown) are defined for other days of the week. Profile 800 defines the probability that a subscriber will engage in a particular activity within a given time frame. For example, the probability that the subscriber will engage in ACTIVITY 1 between 5am and 6am is defined by the parameter Pl. Likewise, the probabilities for the other hours of the day for ACTIVITY 1 are defined by parameters P2-P24. Probabilities for hierarchical subactivities are shown in parameters P25-P48 and P49-P72. Probabilities are preferably defined for a plurality of activities throu ΛgbhL ACTIVITY N.
[0047] FIGURE 9 depicts shopping activity profile 900 according to one representative embodiment. Profile 900 comprises relatively high level shopping summary information. Profile 900 comprises the average amounts of time spent shopping per each day of the week, per week, and per month in parameters X1-X9. The standard deviations for these times are shown in parameters xl-x9. The shopping frequencies for these time periods are represented by parameters F1-F9. The shopping frequency represents the average number of discrete shopping trips taken by the subscriber for the respective time period. The standard deviations for the shopping frequency for these periods are represented by parameters fl-f9. The average amounts of time per shopping trip are represented by parameters T1-T9 for these time periods with the standard deviations represented by parameters tl-t9.
[0048] The average amounts of time spent shopping per shopping location (e.g., MALL X, MALL Y,...MALL Z, etc.) is shown for a plurality of locations for these time periods. The locations are preferably retail locations in which there are multiple merchant stores in relatively close proximity such as a mall or retail district. For LOCATION 1, the average amounts of time for the various time periods are represented by parameters L1-L9 with the standard deviations represented by parameters 11-19. Also, the average numbers of stores visited by retail location for the time periods for LOCATION 1 are represented by parameters SL1-SL9 with the standard deviations represented by parameters sll-sl9. Similar parameters are defined for a plurality of locations (as shown through LOCATION Z).
[0049] FIGURE 10 depicts merchant type shopping profile 1000 according to one representative embodiment. Profile 1000 preferably stores average amounts of time spent shopping for a plurality of merchant types (e.g., clothing retailers, electronics retailers, bookstores, big-box retailers, grocery retailers, etc.). Also, the standard deviations are defined (denoted by the "s" prefix). The amounts of time and standard deviations are preferably calculated or compiled for each day of the week, per week, and per month time periods. Also, average amounts of time and standard deviations are defined for sub-store locations or departments for various merchant types. Such information is preferably compiled or calculated for a plurality of merchant types (shown as MERCHANT TYPE 1 through MERCHANT TYPE X). FIGURE 11 depicts merchant shopping profile 1100 according to one representative embodiment. Profile 1100 stores the same type of information as profile 1000 except the information pertains to specific merchants as opposed to types of merchants.
[0050] When financial transactions are monitored and logged, shopping activity norms in terms of purchases are preferably compiled or calculated. FIGURE 12 depicts shopping purchase profile 1200 according to one representative embodiment. Profile 1200 stores average numbers of purchases per shopping trip (parameters NPl-I through NP 1-9) and average amounts spent per shopping trip (parameters DPl-I through DP 1-9) for each day of the week, per week, and per month time frames. The standard deviations for these values are also given (parameters sNPl-1 through sNPl-9 and sDPl-1 through sDPl-9). Average numbers and amounts of purchases for locations are defined (LOCATION 1 through LOCATION N) as shown in parameters NP-Ll-I through NP- Ll-9... NP-LN-I through NP-LN-9 and DP-Ll-I through DP-Ll -9...DP-LN-1 through DP-LN-9. Standard deviations are also defined for the locations for these time frames as shown in parameters sNP-Ll-1 through sNP-Ll-9...sNP-LN-l through sNP-LN-9 and sDP-Ll-1 through sDP-Ll-9...sDP-LN-l through sDP-LN-9. Merchant type purchase profile 1300 (FIGURE 13) and merchant purchase profile 1400 (FIGURE 14) depict similar purchase information (number of purchases, dollar amounts, standard deviations) by merchant types and specific merchants.
[0051] FIGURE 15 depicts a flowchart for processing shopping activity information for a respective subscriber to generate profile information according to one representative embodiment. In 1501, activity information is retrieved for the last 6 months in a preferred embodiment (although any other suitable length of time could be selected). The activity information is preferably retrieved from pre-existing activity logs according to one embodiment. Alternatively, location based information could be retrieved and correlated to activities in conjunction with the norm building process. In 1502, total time is calculated for each activity (and subactivity) per day of week, per week, per month. In 1503, the total amounts of time are divided by the numbers of each of days of the week, the number of weeks, and the number of months for the selected period of time. The values are stored in one or more profile(s).
[0052] In 1504, the number of times that each activity (subactivity) was performed in various time periods (e.g., each hour interval per day of week) is calculated. In 1505, the numbers of times for each activity/subactivity are divided by the total numbers of each of the days of the week in the selected period of time and the resulting values are stored in one or more profile(s). [0053] In 1506, the number of times that the subscriber went shopping over the selected period and for each day of week are calculated. In 1507, the calculated numbers of times are divided by the number of months, the number of weeks, and the number of days, respectively. The resulting values are stored in one or more profile(s).
[0054] FIGURE 16 depicts a flowchart for processing shopping activity information for a respective subscriber to generate profile information according to one representative embodiment. In 1601, activity log information is retrieved for last 6 months (or any other suitable period of time). In 1602, the total amount of time spent shopping over the selected period of time is calculated. Also, the total amount of time for the selected period for each day of the week is also calculated. In 1603, the calculated values are divided by the numbers of each day of the week, number of weeks, number of months in the selected period of time and the resulting values are stored in one or more profiles to generate the average amounts of time spent shopping per day of week, per week, and per month. In 1604, the standard deviations for the various time periods are calculated and stored in one or more profiles.
[0055] In 1605, the calculation of averages and standard deviations for the time is repeated for a plurality of shopping locations or respective retail locations in which multiple merchants are present. The calculated values are stored in one or more profile(s). In 1606, the calculation of averages and standard deviations are repeated for each merchant type and sub-store location. The calculated values are stored in one or more profile(s). In 1607, the calculation of averages and standard deviations are repeated for each merchant and sub-store location. The calculated values are stored in one or more profile(s).
[0056] In 1606, the calculation of averages and standard deviations is repeated for each discrete shopping trip. That is, an individual shopping trip refers to a period of time where a subscriber was substantially continuously engaged in a shopping activity. The average amounts of time spent shopping per shopping trip per each day of week, per week, and per month are calculated and the standard deviations are calculated.
[0057] In 1607, the numbers of times that the subscriber went shopping over the selected period and for each day of week over the selected period are calculated. In 1608, the calculated values are divided by the number of months, the number of weeks, the number of each day of the week in the selected period of time and the resulting values are stored in one or more store in one or more profiles.
[0058] FIGURE 17 depicts a flowchart for processing financial activity information for a respective subscriber to generate profile information according to one representative embodiment. In 1701, transaction information is retrieved for last 6 months or any other suitable period of time. In 1702, the total numbers of purchases for each day of week and total number of purchases are calculated. In 1703, the total dollar amounts of purchases are calculated for each day of the week and total dollar amount of purchases over the selected period of time are calculated. In 1704, the calculated values (from 1702 and 1703) are divided by the numbers of each day of the week, the number of weeks, and the number of months within the selected period to calculate the average values to be stored in the one or more profile(s). In 1705, the standard deviations for respective time periods are calculated and stored in one or more profiles.
[0059] In 1706, the calculations are repeated to calculate the averages and standard deviations for the various time periods for each shopping trip. The calculated values are stored in one or more profile(s). In 1707, the calculations are repeated for each shopping location. The calculated values are stored in one or more profile(s). In 1708, the calculations are repeated for each merchant type. In 1709, the calculations are repeated for each merchant. The calculated values are stored in one or more profile(s).
[0060] FIGURES 18 and 19 depict example activity norm profiles 1800 and 1900 for different types of merchants according to some representative embodiments. Norm profiles 1800 and 1900 are preferably compiled by monitoring activity information as determined using LBS data and financial information for the respective subscriber. Any number of similar profiles can be defined for other types of shopping or spending activities. Preferably, some profiles are created and maintained for each subscriber, although not every profile need be created and maintained for each subscriber as some subscribers may not sufficiently engage in the respective activity for the information to be useful.
[0061 ] Norm profile 1800 depicts activity norm data for "FAST FOOD DINING." Norm profile 1800 depicts the percentage of times that the subscriber engages in the activity at the respective times (by breakfast, lunch, and dinner) for each day of the week and the average amount spent at each respective time when the subscriber decides to engage in the activity. It may be observed that at certain times the subscriber dines with other parties, such as members of the subscriber's family, while at other times the subscriber dines alone (compare breakfast on Sunday with lunch on Wednesday). Profile 1800 further details percentages of purchases by restaurants and restaurants types. For example, profile 1800 indicates that the subscriber dines at restaurant A 35% of time when the subscriber decides to engage in fast food dining. Profile 1800 further indicates that the subscriber dines at a restaurant of type A 45% of the time when the subscriber decides to engage in fast food dining.
[0062] Norm profile 1800 preferably indicates other activities that are correlated to fast food dining. For example, norm profile 1800 indicates that when the subscriber is engaged in a "work - traveling" activity, the subscriber engages in fast food dining 76% of the time (during or shortly thereafter the work-traveling activity). Also, norm profile 1800 indicates that when the subscriber is or recently has engaging in a "shopping mall" activity, the subscriber engages in fast food dining 44% of the time (during or shortly thereafter the shopping mall activity). By providing such correlation information, specific ads can be directed to a subscriber at an appropriate time. Specifically, the ads might be able to reach the subscriber before the subscriber has made a decision to engage in a specific activity or to go to a specific merchant. That is, if only current location data is utilized, "fast food dining" ads might not be selected. Accordingly, the subscriber may make a decision to engage at a specific fast food restaurant before ads are ever communicated to the subscriber. Some embodiments potentially enable ads to be communicated to the subscriber at a relevant time but before the subscribers has made such a decision. Thereby, the "steering" ability of communicated ads according to some embodiments may be relatively high. [0063] Norm profile 1900 is similar to norm profile 1800 except that norm profile 1900 includes norm parameters relevant to clothing shopping, clothing merchants, and clothing merchant types (e.g., young -women's retailer, designer retailer, discount retailer, etc.). Profile 1900 includes additional information. For example, norm profile 1900 preferably includes a parameter that indicates that the number of clothing-related purchases that the subscriber typically makes per shopping trip. Norm profile 1900 may also include information indicative of the typical goods or type of goods purchased by the subscriber (e.g., if the information is made available by the retailers in connection with coupon, discount, or payment settlement processes).
[0064] Profile 1900 also preferably includes information that relates a correlation between other financial considerations and the purchase of clothing. Profile 1900 indicates that there is an increased probability of 50% of clothing purchases immediately after deposits into a financial account of the subscriber (e.g., when a paycheck or other funds are deposited in the account). Also, there is an increase in the average amount of said purchases immediately after deposits of 70%. It is seen, for this subscriber, that clothing purchases are highly correlated to available funds and, accordingly, the selection of ads for this subscriber should also depend upon the deposit of funds into the subscribers account (e.g., in terms of timing of the deposits and the amounts of the deposits).
[0065] Profile 1900 indicates decreased probability of 20% immediately after out of budget expenses. Profile 1900 further indicates a decreased average amount of purchase immediately after out of budget expenses of 50%. In general, expenses may be categorized by analyzing the financial activity of a subscriber to assign expenses/payments to various categories. See APPENDIX A. Significant deviations (e.g., greater than 20%, 30%, ..50%, or any suitable dollar amount) from typical expenses for a significant budget category may indicate that the subscriber is currently experiencing financial difficulty or unexpected expenses. For some subscribers, such unexpected expenses may cause the subscribers to curtail certain other purchases. By correlating such unexpected expenses to purchasing behavior, subscriber reaction to subsequent unexpected expenses may be predicted and ad selection modified in response thereto. Accordingly, such information can be obtained and stored in subscriber profiles according to some representative embodiments for the purpose of ad selection for subscribers.
[0066] FIGURE 20 depicts activity norm analysis that cross-correlates selected financial transaction behavior to other subscriber behavior. In 2001 , deviations in typical expenditures (e.g., deviations exceeding 10%, 20%, 30%, and 40% of typical discretionary or other spending) are identified. Such deviations may be performed to identify unexpected expenses or significant purchases that may impact other purchasing decisions of the subscriber. In 2002, changes in purchasing behavior after identified deviations are identified for multiple shopping / spending categories in terms of probabilities of purchases and amounts of purchases. In 2003, changes in probabilities and amounts of purchases are stored in profiles for the various identified deviations (if any). In 2004, changes in purchasing behavior after deposits into subscriber account(s) in terms of probabilities of purchases and amounts of purchases are analyzed In 2005, changes in probabilities and amounts of purchases are stored in profiles for various deviations. In 2006, changes in purchasing behavior in relation to variation in amounts of deposits into subscriber account(s) in terms of probabilities of purchases and amounts of purchases are analyzed. In 2007, changes in probabilities and amounts of purchases are stored in profiles for various deviations.
[0067] FIGURE 21 depicts a flowchart to identify correlations between purchasing behavior of a subscriber and various activities performed by the subscriber according to one representative embodiment. In 2101, an activity and/or subactivity of subscriber is selected for analysis. In 2102, occurrences of selected activity / subactivity in activity logs for a suitable time period (e.g., six months) are identified. In 2103, a logical comparison is made to determine whether the selected activity / subactivity has been performed greater than x number of times within the period of time. If so, the process flow proceeds to 2104. If not, the process flow proceeds to 2107.
[0068] In 2104, financial transactions within predetermined time period of each occurrence of activity / subactivity are retrieved (e.g., within one, two, or three hours, for example). In 2105, transaction types that have occurred at least y% of the time that the actitivy / subactivity was performed by subscriber are identified (e.g., clothing purchases, payments for dining, payments for various forms of entertainment, etc.). A suitable percentage of the time may be 50% according to one embodiment (although any other suitable percentage could be employed for other embodiments). In 2106, identified transaction types and % for each type of financial transaction are stored in one or more profile(s).
[0069] In 2107, a logical comparison is made to determine whether other activities / subactivities have been performed by the subscriber within the last six months or other selected time period. If so, the process flow returns to 2101 for selection of another activity / subactivity. If not, the process flow ends at 2108.
[0070] In some embodiments, the information stored in DB 107 is utilized to analyze and detect the collective activities of subscribers. In some embodiments, "clustering" of subscriber activity is detected. As used in this application, clustering refers to multiple subscribers engaging in a common activity or activities within the relatively same geographical location. Clustering of such individuals could be detected over time by repeatedly observing the close proximity in the locations of such individuals. That is, because the same subscribers are observed in very close physical proximity on multiple occasions, some type of relationship is believed to exist between such subscribers. Specifically, their repeated presence together is not a mere accident. Alternatively, the relationship between such subscribers could be known using a priori information (e.g., as provided by one or several of the subscribers when opening an account with some web or other application, as defined by a social networking application, etc.). It shall be appreciated that clustering is not limited to any particular type of relationship. Clustering may occur in many contexts, e.g., family activities, gatherings of friends, business meetings, etc.
[0071] Clustering provides valuable insight into the expected behavior of subscribers and especially commercial behavior. Thus, the detection of clustering provides a valuable mechanism to direct various types of advertising to such subscribers. The advertising may take the form of direct ads sent to wireless devices of the subscribers, e-mail advertisements, web page advertisements, etc. The communication of ads may occur while the clustering is taking place or may occur at a later time. The communication may occur before the clustering takes place. That is, it may be possible to predict a clustering event (e.g., the specific subscribers have been observed to cluster at the same approximate time/day, etc.) based on prior subscriber behavior. In such a case, delivery of the ads may occur immediately before the estimated time of the predicted clustering event as an example.
[0072] As an example, a family may decide to go to a mall on a weekend day. It is quite common for multiple members of the family to possess their own cellular phones. Perhaps, each parent and each teenager in the family would possess their own cellular phone or other wireless device. Assuming that each family members' wireless device possesses a suitable LBS application that reports the respective subscriber's location to an LBS application or LBS gateway, the clustering of the family members can be detected. For example, when the family members initially enter the mall, the family members' respective GPS data may be very similar. That is, the LBS applications of their wireless devices may report substantially similar location information. Also, as each family member enters the mall, the GPS reception may fade at substantially the same time (which can be communicated to an LBS application or gateway). Using such close GPS or other location information, their very close proximity to each other can be detected thereby indicating that a clustering event is occurring. Each member of the family may not necessarily be within very close proximity for the entire expedition to the mall. However, during the common activity, the activities of the family members will most likely be inter- dependent in many ways even though the members are not necessarily in very close proximity the entire time.
[0073] For example, the family members may initially separate to frequent each family member's favorite stores. However, the family members may gather back together to eat lunch or dinner together. Also, the purchases of the family members may be quite different when the family members are together as opposed to when the family members go shopping individually. For example, when a family is found to be clustering, purchasing may be skewed towards the children or teenagers of the family. If the parents are found to cluster without the children, a different set of purchasing behavior could be expected. Likewise, if each individual were determined to be shopping alone, the purchasing behavior again may be different. Further, shopping in the context of peers or friends can exhibit another set of purchasing norms. Additionally, the individual making the purchases may be different depending upon the presence of other individuals. For example, a parent may decide to go to a particular establishment for a meal for the family which would not be chosen by any individual on their own. Hence, in such a situation, the type of ads for meals should depend upon whether the clustering is taking place and the members of the current cluster. Also, it would be beneficial to identify the party that is most likely to make the purchasing decision.
[0074] FIGURE 3 depicts a flowchart according to one representative embodiment. In step 301, LBS information is accessed from one or several databases for prior locations of a selected subscriber as logged in the database(s). In step 302, the database(s) is/are queried for other subscribers that were present at substantially the same location as the selected subscriber at substantially the same time. In step 303, a logical comparison is made to determine whether there are one or more subscribers that were repeatedly present at the same location as the selected subscriber.
[0075] If not, the selected subscriber has not been observed to exhibit clustering behavior and the process flow proceeds to step 304 where another logical determination is made. In step 304, it is determined whether there are additional subscribers to analyze. If not, the process flow proceeds to step 305 to quit. If there are, the process flow returns to step 301 to select another subscriber.
[0076] If the logical comparison of step 303 determines that there are one or more subscribers that were repeatedly present at the same location as the selected subscriber, the process flow proceeds from step 303 to step 306. In step 306, a suitable database update is completed to indicate that the selected subscriber exhibits clustering activity. The database update may include indicating the identifiers of other subscribers with which the subscriber tends to cluster. [0077] In step 307, the activities, associated financial transactions, etc. associated with the common locations are identified for the selected subscriber are identified. In step 308, one or more databases are updated to indicate the type(s) of locations, type(s) of common activities and transaction data associated with the selected subscriber's clusters. The process flow proceeds from step 308 to step 304 to determine whether there are additional subscribers for the cluster analysis process.
[0078] FIGURE 4 depicts a flowchart for processing cluster data according to one representative embodiment. In step 401, a cluster of subscribers (multiple subscribers that have been repeated observed within close proximity of each other) is selected (e.g., as identified in one or more databases). In step 402, activity information and financial information (e.g., transaction details) for subscribers in the cluster are retrieved.
[0079] In step 403, the transactions by individuals in the cluster are categorized (if not already so processed). In step 404, the member(s) of the cluster that are likely to pay for various transactions during clustering are determined. In step 405, the types of goods and/or services that exhibit an increased or decreased probability of purchase are determined for the subscribers of the cluster. In step 406, the types of goods and/or services that exhibit a change in probability when the individuals are not clustering are identified. In step 407, the types of goods that exhibit a change in probability before and after clustering are determined for the subscribers of the cluster. In step 408, the activities that exhibit a change in probability (increase or decrease) in conjunction with the clusterin 1gB are identified.
[0080] In step 409, the information pertaining to the clustering is stored in a suitable database or databases.
[0081] FIGURE 5 depicts a flowchart for utilizing cluster information according to one representative embodiment. In step 501, a request (e.g., an HTTP transaction to a suitable LBS advertising web server application) is received from an LBS advertiser.
[0082] In step 502, a suitable web page is provided to the LBS advertiser that preferably includes interactive elements to enable the LBS advertiser to view subscriber information and to direct advertisements to suitable subscribers. In step 503, cluster information is included within the subscriber information for provision to the LBS advertiser. For example, the LBS subscriber may be allowed to click on a graphical element within the web page that represents a given subscriber. In response, subscriber information may be presented (e.g., an activity log, transaction information, activity norms, financial transaction norms, etc.). Within such information, preferably the LBS advertiser is provided information that indicates whether the subscriber is current "clustering" and, if so, with which other subscribers. The nature of the clustering is preferably identified (e.g., family clustering, peer clustering, business clustering, etc.). Also, information that identifies the types of transactions or activities that exhibit increased or decreased probability are preferably provided. By providing such information, the LBS advertiser can more effectively identify desirable subscribers for ads and/or selected more appropriate ads for the subscribers.
[0083] FIGURE 6 depicts another flowchart for utilizing cluster information according to one representative embodiment. In step 601 , advertising parameters are received (which may include one or more clustering parameter values). The advertising parameters define the desired recipients of one or more directed advertisements (e.g., as will be delivered to subscriber wireless devices). For example, the following tag-encoded parameters could be used as part of a desired LBS advertising effort to direct advertisements to subscribers: {<LOCATION>STONEBRIAR MALL</LOCATION> AND <CLUSTERING> TRUE </CLUSTERTNG> AND
(<CLUSTERTNGWITHFAMILY> TRUE </CLUSTERTNGWITHFAMILY} OR <CLUSTERTNGWITHFRIENDS> TRUE </CLUSTERTNGWITHFRIENDS>) AND (<CLUSTERTNGPURCHASER> MEAL </CLUSTERTNGPURCHASER>}. In this case, the ads would be directed to subscribers located within or proximate to "Stonebriar Mall." Also, the subscribers would be required to be clustering before the advertisement(s) associated with these parameters would be delivered. Also, the subscribers would be required to be clustering with family members or friends (as opposed to business purpose clustering). Also, each advertising target would be required by these parameters to be a subscriber within the respective cluster that tends to pay for meals during the clustering of the respective subscribers.
[0084] In step 602, ads are communicated by a suitable LBS advertising platform to subscribers according to the received parameters. The direction of the ads may directly depend upon the defined clustering parameters/data provided in the received parameters. For example, an advertiser may direct that advertisements are only to be sent to members of a cluster that make purchasing decisions for meals among other advertising parameters in addition to providing non-clustering advertising parameters. The ad parameters may be defined in terms of any of the clustering information discussed herein or any other suitable clustering information. Alternatively, the advertiser may provide more general advertising parameters and automated subscriber selection algorithms can select the most probable subscribers to respond based upon the clustering information.
[0085] When implemented in software, the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks. The program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The "computer readable medium" may include any medium that can store or transfer information. Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
[0086] Although representative embodiments and advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
APPENDIX A
NON- PRO VISIONAL UTILITY PATENT APPLICATION IN THE UNITED STATES
PATENT AND TRADEMARK OFFICE
TITLE:
SYSTEMS AND METHODS FOR PROCESSING A FINANCIAL TRANSACTION ACCORDING TO MULTIPLE BUDGET CATEGORIES
INVENTOR: CS. Lee Crawford
Frisco, TX Citizenship: USA
Correspondence Address: CS. Lee Crawford 12132 Terrazzo Lane Frisco, TX 75035 APPENDIX A
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. Patent No. 11/559,438, filed 11/14/2006 (which claims the benefit of U.S. Provisional Application Serial No. 60/736,252, filed Nov. 14, 2005, U.S. Provisional Patent Application No. 60/759,303, filed 01/17/2006 and U.S. Provisional Patent Application No. 60/773,852, filed 02/16/2006); this application also claims the benefit of U.S. Provisional Patent Application No. 60/759,303, filed 01/17/2006 and U.S. Provisional Patent Application No. 60/773,852, filed 02/16/2006, all of which are incorporated herein by reference.
BACKGROUND
[0002] Financial transactions are increasingly completed using various card payment options and cash payments have become somewhat rare for many retail transactions that require more than a nominal amount of funds. For example, the use of credit cards and debits cards have become virtually ubiquitous. Also, so-called "stored value" cards have gained wide-spread acceptance.
[0003] Payment for a transaction using such cards follows a relatively simple process. Typically, the respective card is "swiped" through or by a reader of a "point-of- sale" device that reads account information from the card. The point-of-sale system communicates the account information, transaction amount, merchant information, and other information to a payment server. The payment server communicates within a payment system to clear the transaction. Within the payment system, another server (the "payor" server) associated with the financial institution responsible for the account associated with the cards processes the financial transaction information. Specifically, the payor server determines whether sufficient funds are available in the identified account for the transaction. If so, the payor communicates a transaction approval. Otherwise, a transaction denial is communicated back through the payment system to the original server and to the point-of-sale system. Eventually, the actual funds are transferred from the account associated with the card to the merchant's account (possibly through other accounts of financial intermediaries). [0004] At the current time, providing cards to third parties (i.e., parties other than the individual responsible for the underlying accounts) is problematic. Specifically, a third party possesses the ability to incur substantial charges (up to a credit limit for credit accounts) or spend the entire available funds (for deposit type accounts). Stored value cards offer some degree of usefulness for providing cards to third parties to limit the transactions of the third parties. The stored value cards are typically limited to one or more specific merchants and only store a limited amount of funds at any given time. When the third party depletes the funds associated with a stored value card, the account holder can "replenish" the card if the account holder so desires.
DETAILED DESCRIPTION
[0005] Referring now to the drawings, FIGURE 1 depicts a system for managing financial accounts, defining budget limits for such accounts, for processing transactions for the accounts according to such limits, communicating transaction and budget information to card holders and account holders, and communicating advertisements to card holders and account holders according to one representative embodiment.
[0006] Financial accounts or other types of payment accounts can be created utilizing any known or later development manner. For example, an individual may simply enter a bank and open a checking account and receive a debit card to allow debit transactions to occur from the account. Alternatively, an individual may open an account over the Internet 104 via a web browser 113. Any suitable type of account may be utilized according to some representative embodiments from credit card accounts, savings and checking accounts, money market accounts, stored-value accounts, pre-paid card accounts, etc.
[0007] Preferably, conventional account information is stored in account database 114 such as account holder information and account balance information. In some embodiments, card holder information is also stored. For the purpose of this application, account holder means an individual who opens, controls, or manages an account and card holder refers to an individual that uses a card to pay for transactions. The card holder can be, but need not be, the same individual as the account holder. Additionally, multiple cards could be issued for a single account and information for multiple card holders could be entered into the database. The account information may also include contact information (e.g., cell phone numbers, e-mail addresses) for the account holders and the card holders to communicate transaction and budget information to the account and/or card holders.
[0008] Referring to budget creation, according to one representative embodiment, account holders can set budgets (using their browsers 113 to communicate with web server 105) that delineate how users wish to spend their funds or how the users wish to limit how other card holders spend funds (optionally according to hierarchical categories). The budget information is stored in database 109. The transactions using their personal accounts (e.g., their banks accounts, credit card accounts, etc.) are monitored and compared against the budget categories. Transaction information (e.g., merchant ID, merchant location, transaction amount, time, etc.) is also preferably stored in database 109 for review by account and card holders and for use in selecting ads for communication to such users. Such information is preferably stored as transactions are completed. Also, such information is preferably processed to identify various types of purchasing norms and patterns to facilitate selection of ads for communication to account and card holders.
[0009] In some embodiments, the account holders can be taken through a series of pages in a progressive manner (e.g., through a "budget wizard") to enter budget information. Example categories and subcategories can include the following: EATING OUT/MEALS: (i) breakfast; (ii) lunch; (iii) dinner; (iv) misc. (v) total: ENTERTAINMENT: (i) movies; (ii) sports; (iii) live events;... total: EDUCATION: (i) books; (ii) supplies ...total : MEDICAL:.. HOUSEHOLD EXPENSES/GROCERIES: CLOTHING... DISCRETIONARY.
[0010] Clearly, not all categories are pertinent for all users and need not be defined for all budgets. Also, any additional budget categories can be defined. Account holders can be given the option of defining only gross amounts for top-level categories or, going forward and defining the specific amounts for various subcategories. Additionally, any number of user defined budget categories or subcategories could be defined if desired. Also, the users are preferably given the option of defining the budget period for the various categories and/or subcategories. The default option is preferably a monthly budget period for common expenses, e.g., groceries. Weekly budget expenses could be defined, as examples, for work-week lunch expenses, entertainment expenses, etc..
[0011] In some embodiments, account holders can identify specific permitted merchants for one or more budget categories. Also, account holders can be given the ability to select specific merchant locations for specific budget categories. For example, a map of an area in which the card holders is expected to conduct most transactions can be presented via the account holder's web browser 113. Specific categories or types of merchants within the area can be identified on the map for selection by the account user for a specific budget category. Thereafter, the card holder would only be permitted to conduct transactions for the specific budget category at the selected merchants/locations. In general, such functionality may be implemented by storing a database of merchant identifiers (as defined for use in a payment system) and correlating the merchant identifiers to more detailed merchant information (e.g., merchant name or other merchant metadata). Also, for each merchant entry, merchant type information can be stored in the database.
[0012] Transactions may begin in the ordinary manner in which credit card information, debit card information, stored-value card information is obtained from a card holder via a point-of-sale devices/merchant devices 103. Merchants 103 communicate transaction information (e.g., account number, transaction information, merchant ID, etc.) through payment system 102. The bank server 101 responds to the transaction information by communicating approvals or disapprovals, debiting/charging user accounts, transferring funds within the payment system, etc. The transaction approvals or denials depend upon the budget information stored in database 109. Specifically, if a series of prior transactions cause a card holder to reach a budget limit for a particular budget category, a subsequent transaction would be denied for that budget category. Although bank server 101 is described, server 101 need not be chartered bank. Bank server 101 can be any server that processes financial transactions and could be managed by credit unions, brokerage firms, or any suitable financial entity permitted access to payment system 102 as examples.
[0013] Bank server 101 preferably communicates transaction information to web server 105 (e.g., through the Internet 104). Either bank server 101 or web server 105 may initiate the communication to obtain the transaction information. In some embodiments, selected transaction information is stored in database 109. Preferably, each transaction is categorized according to one or several budget categories upon being stored in database 109 (e.g., a field in the database is filled with a value corresponding to the respective budget category).
[0014] Budget and transaction information is preferably sent to wireless devices 106 of account holders and wireless devices 107 of card holders. For example, a card holder may pay for a transaction using a card. The transaction amount can be added to the expended funds for a particular budget category as stored in database 109. A message can be sent (e.g., via SMS messaging) to the account holder's wireless device 106 and/or the card holder's wireless device 107 indicating the transaction amount, the amount of expended funds for the budget category, remaining available funds for the category, and/or the like. In this manner, the account holder can be informed of the financial activity of the card holder. Also, the card holder can have near constant awareness of how the card holder's activities conform to the budget limits. Such information may be communicated by server 105 as an example.
[0015] Server 105 preferably obtains the location information of users. Specifically, in preferred embodiment, a JAVA™ MIDlet client application is stored and executed on each user wireless devices (e.g., their cellular phones) 106 and 107. The client application obtains information that is indicative of the current location of the respective wireless device and communicates the information (e.g., with a time stamp) to server 105 through cellular infrastructure 108 and/or the Internet 104. In one embodiment, the information is communicated in an SMS message. The information can be encrypted or otherwise obscured to maintain the privacy of the user. In some embodiments, depending upon the capabilities of the wireless devices 106/107, GPS coordinates are communicated to server 105 that identify the precise location of the device 106/107 at a particular moment in time. For example, "assisted" GPS (AGPS) functionality is available in many commercially cellular phones that enables the GPS location to retrieved using an API call that accesses an AGPS chip in the phone. In other embodiments, the wireless device 106/107 communicate cell ID information (e.g., the identifier of the current cell in the wireless system serving the respective wireless device). The cell ID information can be used to look-up the location of the serving cell which, in many urban cases, is "relatively" close to the wireless device (e.g., within one mile or closer). Server 105 stores the location information and time information in location DB 112.
[0016] Additionally, as transaction information and the location information are received by server 105, the two sets of information are compared for discrepancies. Specifically, transaction information associated with a credit card transaction includes an identifier of the merchant and the merchant location (e.g., a particular merchant store). The merchant location can be correlated to a merchant address. The merchant address can then be compared against the location of the card holder's cellular phone 107 at the time that the transaction occurred. If the address does not match the location of the cellular phone 107, it is possible that an unauthorized person used the card or card account to make the purchase. Preferably, some amount of tolerance is provided to the comparison to account for a lack of complete precision in the location information (e.g., when a cell ID is used) or in the merchant location information.
[0017] Upon detection of possible fraud, a suitable message is sent to the card holder's wireless device 107 and/or to the account holder's wireless device 106. In some embodiments, the message is sent as an SMS message to a particular port. The client MIDlet is registered to process SMS messages on the port and communicates the possible fraud to the user. The client MIDlet preferably presents the information to the user and prompts the user to input whether the transaction is actually fraudulent. If the user indicates that the transaction is fraudulent, the client MIDlet can give the user one or several options. One option may include automatically initiating a call to the fraud number associated with the user's bank for the user to report the fraud.
[0018] In some embodiments, the budget/transaction processing can occur in conjunction with a system that enables the user to control which transactions are approved or denied by bank server 101. In some embodiments, a MIDlet is stored on the user's cellular phone. The MIDlet is accessed when the user wishes to "activate" the user's card account for a particular type of transaction (e.g., for "everyday" transactions, "gas" transactions, "eating-out" transaction, "entertainment" transactions, etc.). Also, at any point in time, the MIDlet preferably provides the user with updated budget information (i.e., the current budget limit, available funds, projected over-budget or under-budget amounts, etc.) for the various budget categories. The MIDlet is preferably customized to the individual user (e.g., the ordering of transaction options in its user interface and the particular categories of transaction options for selection within the user interface are adapted for the specific user). Also, the MIDlet preferably is given a private key to digitally sign its messages to authenticate the origin of the messages.
[0019] The customized MIDlet is preferably customized at an appropriate server and downloaded to the user's cellular phone when the user sets-up his/her account for management. In operation, when the user selects one of the options from one or several menus (or other user interface elements), the MIDlet communicates an "activation" message to a server associated with the user's account. The account is then temporarily activated to approve transactions subject to the selected category (e.g., for thirty minutes or any other suitable amount of time). When transaction information is received that originated from a merchant, the transaction information is compared against the limitations associated with the selected category. For example, if the merchant identifier in the transaction information is consistent with the selected category, the transaction is approved. If not, the transaction information is denied.
[0020] In some embodiments, the card holders and/or account holders are given the option of receiving advertisements, offers, incentives, etc. according to a "location based services" (LBS) scheme. In some embodiments, ad server 110 receives ads from advertisers via the Internet 104 and stores those ads in ad database 111. Preferably, target audience parameters are associated with the ads to define which subscribers should receive the ads. In this LBS application, the ads are communicated to such users in a manner that is dependent upon the current location of the users. For example, a user can go to a specific mall and request communication of current offers/incentives etc. that are applicable at that mall. The user can make such a request using a WAP browser on the wireless device 107 as an example. The WAP request may include the current location of the cellular phone 107. Alternatively, a MIDlet application on the wireless device 107 may automatically download such ads for presentation to the card holder. The location enables the selection by ad server 110 of incentives/offers from the particular merchants at the mall to be identified. The transaction information and/or budget information can be further utilized by server 110 to sort and/or pair down the advertisements, incentives, offers, etc. to those that are more likely to be relevant to the particular card holder. Upon selection of the relevant ads, ad server 110 communicates the ads (e.g., by WAP transaction processing, MMS messaging, etc.) to the wireless device 107.
[0021] In some embodiments, budget information and transaction information stored in database 109 can be used to communicate targeted advertisements to users either to web browsers 113 or cellular phones 106 and/or 107 as examples. For example, users can be given the option of receiving such advertisements/offers. Users that select the option will receive advertisements/offers that correspond to their particular needs in view of the purchases and budgets. Suppose a user is overbudget for groceries as an example, various coupons/incentives can be sent to such a user to enable the user to reduce the user's grocery expenses. The sponsors of the coupons/incentives benefit by steering the user to their products and/or stores and generating customer loyalty to their brands.
[0022] Also, suppose a user reviews their expenditures to discover that the user is overbudget and does not immediately know how to reduce their expenditures. The user can invoke a software module to automatically review the user's expenditures and identifies products/services that can reduce the user's expenditures. Similarly, the user may identify budget categories that the user wishes to reduce their expenditures and relevant advertisements/offers/incentives can be sent to such users.
[0023] Likewise, when a user is underbudget, various offers/incentives for discretionary purchases can be sent to the user. Also, the user's transaction history can be used to select such discretionary items that are likely to be interesting to the user. In some embodiments, when a user comes close to completing predefined "savings" for some particular purpose (e.g., as defined for a "vacation" fund), targeted advertisements/incentives/offers can be sent to the user related to the purpose of the savings fund. For example, a user can define a SAVINGS category into which any amount or, perhaps, unused funds are deposited. The user can defined a purpose for such an account. When advertisers have offers that correspond to the purpose of the account and approximately match the amount of funds in the account, their advertisements can be communicated.
[0024] In some embodiments, the communication of the advertisements/incentives/offers can occur according to a "location based services" (LBS) scheme. In LBS applications, information is communicated to users in a manner that is dependent upon the current location of the users. For example, a user can go to a specific mall and request communication of current offers/incentives etc. that are applicable at that mall. The user can make such a request using a WAP browser on their cellular phone 106 or 107 as an example. The user can manually input their location (e.g., by "typing" or by selection from a menu or other graphical control), the location can be inferred by reference to the current cell of the wireless system that is serving the cellular phone 106 or 107, or the cellular phone can itself determine the location (e.g., using assisted GPS functionality). The location enables the selection of incentives/offers from the particular merchants at the mall to be identified. The budget and transaction information can be further utilized to sort and/or pair down the incentives/offers/ads to those that are more likely to be appropriate or most relevant to the particular user.
[0025] Although different databases and servers are discussed herein, the databases and servers can be implemented on common computing platforms or split among different platforms as desired. A specific computing architecture is not critical for all embodiments. Any implementation may be utilized so long as the appropriate transaction processing and/or advertisement selection occurs.
[0026] FIGURE 2 depicts a flowchart for establishing a budget for management of one or several financial accounts and/or payment cards according to one representative embodiment. In preferred embodiments, the process of FIGURE 2 is implemented using suitable computer platforms (e.g., a personal computer of an account number and a server platform) and suitable software code executed by those platforms. For example, the code may include the browser application code (e.g., Internet Explorer, Firefox, etc.), web server code (e.g., APACHE and custom PERL scripts for processing HTTP transactions), and the HTML or other browser executable code (as executed by the browser itself or through a "plug-in") communicated from the server to the account holder's computing platform. Also, a suitable communication connection is preferably established between the platforms such as through one or more of the following a local area network, the Internet, a wireless network, a telephony network, and other communication network.
[0027] In step 201 of FIGURE 2, a communication connection is established between an account holder's browser and a suitable server (e.g., server 105) that supports the budget creation process. The communication connection may be established using conventional processing, such as TCP/IP connections using secure socket layer (SSL) communication, HTTP transactions, authentication (e.g., user ID, password, etc.), and/or the like.
[0028] In step 202, one or more web page(s) are presented to account holder using the account holder's web browser via communication between the server and the web server.
[0029] In step 203, in conjunction with the presentation of the web pages, input is received from the account holder in web page forms defined by the web page(s) communicated to the account holder's web browser. The web page forms allow the user to create and/or modify budget rules. For example, the account holder may select predefined budget categories or create user specific budget categories. For the selected/created budget categories, the account holder can select predefined limitations and/or define user specific limitations. Also, "default" limitations can be associated with the predefined budget categories and the account holder may modify those limitations.
[0030] The limitations may define time of day and day of week restrictions. For example, a budget category for "EATING OUT/MEALS: LUNCH (WORK WEEK)" may be created and a time restriction of 10:30 - 2:30 and a day of week restriction of Monday - Friday could be defined for such a category.
[0031] Merchant type restrictions can be defined for budget categories. For example, transactions for a GROCERY/HOUSEHOLD NEEDS category could be restricted to GROCERY STORE and BIG-BOX RETAILER merchant types. More specific merchant restrictions could be applied to budget categories. For example, geographical limitations could be defined. For example, merchant stores within a specific geographical area or areas (e.g., defined by city, zip codes, area selected from a map in a user interface, etc.) may be defined as the only acceptable locations for transactions with one or more budget categories. Additionally, to the extent that the account holder wishes to do so, only specific merchants may be permissible for one or more budget categories such as a specific big-box retailer or a specific grocery retailer.
[0032] In some embodiments, "activation" rules are applied to one or more budget categories. Such activation rules preferably require the account holder and/or the card holder to "activate" (as will be discussed below) a budget category before transactions will be approved during transaction processing for the category. For example, "ELECTRONIC PURCHASES," "CLOTHING PURCHASES," and "INTERNET PURCHASES) categories may be defined. These categories could be defined as normally inactive. If a transaction were attempted at an electronic retailer, at a clothing retailer, at a Internet payment web service, the transaction would be denied. However, when such purchases are deemed appropriate or necessary, the account holder (or possibly the card holder) may communicate with the server to activate the appropriate budget category. Preferably, for a predefined period of time, transactions for the budget category will be approved. The activation rules may identify which categories must be active for transaction approval. Also, the activation rules may specify who is allowed to activate the categories (e.g., the account holder only or the account holder and the card holder). The activation rules may also specify how long the budget categories remain active after activation.
[0033] Per transaction limits could be defined for one or more budget categories. Transaction limits could be defined to limit a total dollar amount per transaction or to limit a number of transactions within a given period of time for one or more budget categories.
[0034] Also, to the extent product information is available, product restrictions could be defined. For example, certain stored value card systems (as implemented by various retailers) allow access to data identifying the products and/or services being purchases. Budget categories may restrict transactions to permit only certain products, services, or types of products or services.
[0035] Rules can be defined for left-over funds or for over-budget transactions. For example, if a transaction exceeds a budget limit may a predefined amount, the transaction may be approved if permitted by an over- budget rule or may be alternatively denied. If some amount of over-budget spending is permitted, rules may be defined to address such over-budget spending such as reducing the available funds from another budget category (in the current budget period or in another budget period) or reducing the available funds for the same budget category for the next budget period.
[0036] The over-budget rules may also specify whether a more general budget category or another budget category could be employed for a transaction if a specific budget category limit is exceeded. For example, if a card holder exceeds a budget limit for MEALS: LUNCHES (WORK WEEK), it may be permitted (by decision of the account holder or by default) to pay for a transaction using a more general category "MEALS" or a general budget category "DISCRETIONARY SPENDING." Alternatively, if a card holder exceeds a budget limit for an "ENTERTAINMENT" budget category, the account holder may define a rule prohibiting completion of payments for entertainment transactions using more general categories. [0037] In step 203, the data input by the account holder is communicated to the budget server (e.g., using conventional HTTP transactions over a secure socket layer connection).
[0038] In step 204, the budget information is stored in a suitable database or databases or other data store for subsequent use.
[0039] In step 205, the account holder is preferably given the option of deciding whether advertising is communicated in conjunction with the transaction information and the information is communicated to the server. Also, if the account holder may enter contact information for communicating budget information (step 206). For example, the account holder may enter the telephone number of the account holder's wireless device and the telephone number of the card holder's wireless device for receiving text messages of budget information as transactions are completed. Also, advertising may be sent via MMS messaging or other suitable communication means to such wireless devices.
[0040] FIGURE 3 depicts a flowchart for processing a financial transaction according to one representative embodiment. In preferred embodiments, the process of FIGURE 3 is implemented using suitable computer platform and suitable computer code executed by that platform. Preferably, the platform or server is adapted to communicate within a payment system and to perform the various authentication protocols associated therewith. The server differs from known payment system servers in regard to the logic that server employs to decide whether to approve or deny a given transaction.
[0041] In step 301, transaction information is received for approval or denial of a transaction within a payment system. The transaction information may include account number, transaction amount, merchant id, store location, time information, etc. Also, in some embodiments, product information may be included within the transaction information.
[0042] In step 302, budget information is retrieved from a suitable database using the account number identified in the transaction information. [0043] In step 303, one or more budget categories matching the transaction information are identified. The time of day and day of week may also be used to identify the budget categories appropriate for the transaction. Alternatively, the card holder could have explicitly selected the budget category (before the transaction occurs) by "activating" a specific budget category for one or more purchases.
[0044] In step 304, the "best" budget category is selected (or the "next" best depending upon whether one or more budget categories have already been examined). As used herein, the "best" or next "best" category refers to the level of specificity of the category. For example, the most specific matching sub-category of multiple hierarchical categories is preferably selected first and then more general categories are selected later.
[0045] For example, the following categories could be applicable to pay for a meal purchased by a card holder: (i) EATING OUT/MEALS: dinner; (ii) EATING OUT/MEALS: misc.; and (iii) DISCRETIONARY. The categories would be analyzed in that order (i.e., (i)-(iii)) due to the level of generality of those categories. The level of generality is preferably defined by default for the predefined categories. For user created categories, the account holder is preferably given the ability to define the level of generality relative to other categories during the budget creation process (see FIGURE 2). In step 305, a logical comparison is made to determine whether the respective budget category is active (if an activation rule is defined for the budget category). If so, the process flow proceeds to step 306. If not, the process flow proceeds to step 309.
[0046] In step 306, a logical comparison is made to determine whether the transaction satisfies merchant, location, transaction, and/or product limitations for respective category. If so, the process flow proceeds to step 307. If not, the process flow proceeds to step 309.
[0047] In step 307, a logical comparison is made to determine whether sufficient funds are currently available for the respective budget category (it may also be considered whether there are actually sufficient funds or credit available in the underlying account). The amount of funds necessary for the comparison in regard to the budget category preferably depends upon whether funds (although not all the funds necessary for the transaction) were available for a prior category. For example, a transaction may involve a $50 amount. If $30 is available in a first budget category, thereafter the logical comparison in step 307 will determine whether $20 is available in another category (or split among multiple other categories). If so, the process proceeds to step 311 for approval of the transaction. If not, the process flow proceeds to step 308.
[0048] In step 308, a logical comparison is made upon the basis of any over- budget rules. If an over-budget rule permits the card holder to go over the transaction by the excess of the transaction amount (or a reduced amount, see step 307) over the currently available funds for the budget category, the process flow proceeds to step 311 for transaction approval. If an over-budget rule prohibits any overage for the budget category, the process flow proceeds to step 310 for transaction denial. If "roll-over" to another budget category is allowed, the process flow proceeds to step 308 to step 309.
[0049] In step 309, a logical comparison is made to determine whether another budget category is possible for the transaction. If so, the process flow returns to step 304. If not, the process flow proceeds to step 310 for transaction denial.
[0051] In step 310, a transaction denial occurs by communicating a transaction denial message pursuant to the protocols of the respective payment system. Thereafter, the denial will be communicated back to the merchant and the card holder will have to pay using some other funds or forgo the transaction entirely.
[0052] In step 311, a transaction approval occurs by communicating a transaction approval pursuant to protocols of the payment system.
[0053] In step 312, the financial account linked to the card account is debited or charged for the transaction amount. An electronic transfer of funds between accounts by various financial institutions/entities may occur immediately upon transaction approval (or the transfer may occur subsequently at the end of the business day or at another suitable time as customary within the payment system). [0054] In step 313, the amount of available funds for the various budget categories are reduced according to how the funds were allocated during the transaction processing.
[0055] In step 314, updated transaction information is communicated (e.g., to the account holder and/or the card holder). In preferred embodiments, SMS messages are sent to the account holder and the card holder that indicate the amount of the transaction amount, the budget category/categories involved, and the amount of remaining funds for the budget category/categories. Over-budget information or projected over-budget information may be included. Although budget information is communicated using SMS messaging according to some embodiments, any other messaging may occur (e.g., via e- mail or via on a web page accessed at a later time, etc.).
[0056] Several example budget update messages will be provided. Suppose an account holder sets a budget of $45 for week-day lunches. The card holder can utilize a card linked to a suitable account to make the purchases for his/her lunches, which is monitored by the budget server. Suppose on Monday, the card holder purchases a lunch of $10; an update message can be sent to the card holder and/or the account holder in an SMS message as follows: lunches weekly amount: $45; spent: $10; remaining: $35. Suppose on Tuesday, the card holder purchases another lunch of $10; an update message can be sent an SMS message as follows: lunches weekly amount: $45; spent $20; remaining: $25; projected over: $5 (in some embodiments, projected amounts can be provided after a plurality of purchases are made or the projected amount exceeds some threshold). Suppose on Wednesday, the card holder purchases his/her lunch for $5; an update message can be sent to the user in an SMS message as follows: lunches weekly amount: $45; spent $25; remaining $20. Suppose on Thursday the card holder skips lunch and on Friday the card holder purchases a $25 lunch, a message can be sent as follows: lunches weekly amount: $45; spent: $50; $5 removed from Entertainment to equal $45. It shall be appreciated that these messages are by way of example only. Other formats can be used and other information can be included. In some embodiments, multiple categories/subcategories can be communicated at the same time. [0057] FIGURE 4 depicts a flowchart for managing financial transactions associated with one or more card accounts according to one representative embodiment. In preferred embodiments, the process of FIGURE 4 is implemented using suitable platforms (e.g., a cellular phone and a server platform) and suitable software code executed by those platforms.
[0058] In step 401, a communication connection is established between an account holder's wireless device and server using conventional mechanisms. In one specific embodiment, a MIDlet is distributed to the account holder's cellular phone or other wireless device. The MIDlet then conducts the communication between the cellular phone and the server and receives input from the account holder to obtain account management data.
[0059] In step 402, the account holder is permitted to authorize or prohibit over- budget transactions. In step 403, the account holder is permitted to change budget limits associated with one or more budget categories. In step 404, the account holder is permitted to activate or inactive budget categories.
[0060] FIGURE 5 depicts a flowchart for managing financial transactions associated with one or more card accounts according to one representative embodiment. In preferred embodiments, the process of FIGURE 5 is implemented using suitable platforms (e.g., a cellular phone and a server platform) and suitable software code executed by those platforms.
[0061] In step 501, a communication connection is established between a card holder's wireless device and a suitable server. In step 502, the card holder is permitted to select budget category for one or more subsequent purchase(s). In step 503, the card holder is permitted to activate budget category/categories (depending upon how the account holder has configured the account).
[0062] FIGURE 6 depicts a flowchart for managing budget limits according to one representative embodiment. In preferred embodiments, the process of FIGURE 6 is implemented using a suitable server platform and suitable software code executed by the server.
[0063] In step 601, budget categories with left-over funds or over-budget amounts for budget period are identified. In step 602, roll-over rule(s) for the category/categories are retrieved as provided by the account holder or provided by default. In step 603, budget category limit(s) are modified for same or other budget category/categories according to roll-over rule(s).
[0064] For example, in a given week, the card holder may decide not to spend all of the available funds within the MEALS category, i.e., the card holder spends an amount for this category less than the defined budget limit. The account holder may have defined a rule to permit the left over amount to be assigned to a DISCRETIONARY budget category. Accordingly, the DISCRETIONARY budget category is increased at the end of the budget period for the MEALS category.
[0065] Some representative embodiments are directed to communicating various types of electronic ads to users of a system that provides budget or other financial services functionality. In some embodiments, advertisements are selected in terms of the budget information of account holders and/or card holders (such as any of the budget or financial information discussed above). For example, ads can be selected for communication depending upon the budget limits set for account holders and/or card holders. In other embodiments, ads can be selected in relation to over-budget or under- budget considerations (actual or projected over/under budget amounts) and/or in regard to the amount of any such over-budget or under-budget occurrence. In other embodiments, ads can be selected upon the basis of the remainder of unspent funds within one or more budget categories. In some embodiments, ads can be selected in regard to a per transaction limit defined for a budget category.
[0066] Ads can be selected in regard to the defined merchant information for budget categories. Alternatively, ads can be selected in regard to merchant information identified in the transaction information stored in a history of transactions by a card holder in one or more appropriate databases. Ads can be selected in regard to when/whether a card holder has made a purchase within a given category. For example, it may make little sense to send an ads for a certain type of grocery item, if the card holder has already made a purchase at a grocery store that day.
[0067] Such analysis can take into account other purchase history information (such as the typical number of transactions for a category within a given amount of time) and/or comparing such information against observed purchasing behavior. For example, if a card holder frequency spends more than $200 (at one or more merchants) when shopping for clothes and the card holder has been observed to have only spent $75 (at one or more merchants), it may be appropriate to send ads to that user. Specifically, based prior purchasing behavior, it is highly probable that the card holder will spend additional funds on clothing within a very short period of time. Accordingly, that card holder is a valuable candidate to target for the receipt of ads that attempt to direct the card holder to make purchase of specific products or at specific merchants. Alternatively, if the card holder has spent $250, it is less likely that the card holder will make significant purchases and so the value of directing clothing ads to that card holder is reduced at that time. In some embodiments, a histogram is applied to analyze such purchasing patterns in which the percentile of purchases falling within various dollar ranges are maintained.
[0068] Historical timing of purchases can be utilized for the selection of ads. For example, certain discretionary purchases (clothing, entertainment, etc.) may be made more frequently by a card holder at a certain times of the month, certain days, certain times of day, etc. Alternatively, certain purchases may occur relative to certain defined events, e.g., the deposit of funds within an account (e.g., near payday where an automatic deposit of funds occurs).
[0069] Other purchase history information can be selected for the selection of ads. For example, if a card holder usually follows up a large transaction amount in a given category with a smaller transaction amount, such an observation can be utilized for ad selection. For example, if a card holder usually picks an inexpensive lunch the day after purchasing an expensive meal, such information can be utilized to select appropriate ads. [0070] The budget and financial information can be selected in combination any other suitable information such as demographic information, product preferences, etc.
[0071] In some embodiments, the budget and financial information is combined with location based information to select ads for communication. In some embodiments, the location of a card holder is obtained through location information associated with the card holder's wireless device (e.g., his/her cellular phone). Such information is used in conjunction with other appropriate information to communicate ads to the card holder. For example, different ads would be selected depending upon whether the card holder is at a clothing retailer at a mall versus at a big-box hardware store. Also, the timing of ads may depend upon such location information (e.g., when the card holder initially arrives at a given location, how long the card holder has been at a location, and when the card holder leaves a given location).
[0072] FIGURE 7 depicts a flowchart for communication ads to subscribers according to one representative embodiment. In preferred embodiments, the process of FIGURE 7 is implemented using a suitable server platform and suitable software code executed by the server.
[0073] In step 701, ads are received from advertisers with target audience parameters. The target audience parameters may include demographic information. Also, the target audience parameters may include various budget, financial, or past purchase history information, etc. as discussed above. In step 702, an LBS server, preferably, identify when subscribers enter geographical location. In step 703, ads are identified for geographical area associated with the various subscribers, where the ads are selected to match the parameters of the ads to the various subscribers. In step 704, the most valuable ads are selected for and communicated to subscribers upon the basis of financial, budget, historical purchasing data, etc.
[0074] When implemented in software, the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks. Any type of suitable code or software may be utilized from machine code, complied software, interpreted software, browser executable code (HTML, JAVA script, FLASH code, etc), "JAVA" variants, PYTHON scripts, and/or the like. The program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The "computer readable medium" may include any medium that can store or transfer information. Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, an intranet, etc.
[0075] Although representative embodiments and advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
APPENDIX A
Figure imgf000053_0001
FIG. 1
FIG. 2
Figure imgf000054_0001
Figure imgf000055_0001
APPENDIX A
FIG. 4
FIG. 5
ESTABLISH CONNECTION
BETWEEN ACCOUNT ESTABLISH CONNECTION
HOLDER'S WIRELESS BETWEEN CARD
DEVICE AND HOLDER'S WIRELESS
SERVER 401 501 DEVICE AND
SERVER
AUTHORIZE OR PROHIBIT
402 OVER-BUDGET SELECT TRANSACTIONS
502 BUDGET CATEGORY
1 FOR NEXT PURCHASE(S)
CHANGE BUDGET
403 LIMITS
503 ACTIVATE BUDGET CATEGORY/CATEGORIES
ACTIVATE/INACTIVATE BUDGET CATEGORIES 404
Figure imgf000056_0001
APPENDIX B
UTILITY APPLICATION IN THE UNITED STATES PATENT AND TRADEMARK
OFFICE
TITLE:
SOCIAL NETWORK APPLICATION FOR PROCESSING IMAGE OR VIDEO DATA FROM WIRELESS DEVICES OF USERS AND METHODS OF OPERATION
INVENTOR: CS. LEE CRAWFORD
FRISCO, TX CITIZENSHIP: USA
CORRESPONDENCE ADDRESS: CS. LEE CRAWFORD 12132 TERRAZZO LANE FRISCO, TX 75035 APPENDIX B
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. Patent Application Serial No. 11/623,832, filed 01/17/2007, which is a continuation-in-part of U.S. Patent Application Serial No. 11/559,438, filed 11/14/2006 (which claims the benefit of U.S. Provisional Application Serial No. 60/736,252, filed Nov. 14, 2005, U.S. Provisional Patent Application Serial No. 60/759,303, filed 01/17/2006 and U.S. Provisional Patent Application Serial No. 60/773,852, filed 02/16/2006); U.S. Patent Application Serial No. 11/623,832 also claims the benefit of U.S. Provisional Patent Application Serial No. 60/759,303, filed 01/17/2006 and U.S. Provisional Patent Application Serial No. 60/773,852, filed 02/16/2006.
BACKGROUND
[0002] Location based services refer generally to services that provide information to a user in relation to the location of the user. At the present time, location based services are relatively pedestrian in nature and provide relatively simple information. An example of a known location based service is a "weather" service in which the user's zip code is provided to the service (e.g., through a conventional HTML webpage, a WAP or other cellular phone interface, etc.) through a network and the service responds by communicating the current weather conditions and the forecast for several days. Other known location based services provide "social" applications such as allowing users to determine each other's locations, receive notification when a friend comes within a predetermined distance, and similar operations. Another type of location based services are generally referred to as "McDonalds finders" that provide search results in a map form (e.g., searching for specific locations of restaurants/stores within a given distance of the user). Other location based services have proposed delivering various types of "advertising" (e.g., when a user arrives at an airport, various ads can be delivered to the user's cellular phone). However, such advertising location based services are quite simplistic and do not possess any appreciable intelligence for selecting advertisements beyond the location of the user. APPENDIX B
[0003] Social network applications commonly refer to applications that facilitate interaction of individuals through various websites or other Internet-based distribution of content. Originally, the concept of a social network originated within the field of sociology as method of modeling social interactions or relationships. Within such modeling, individuals, groups, or organizations are represented as nodes within a social network and the relationships between the "nodes" are represented as links between the nodes thereby forming a "network."
[0004] Social network applications have knowingly or unknowningly utilized such concepts to facilitate interaction between individuals via the Internet. In most social network applications, a specific user can create an account and provide various types of content specific to the individual, such as pictures of the individual, their friends, their family, etc., personal information in text form, favorite music or videos, etc. The content is then made available to other users of the social network application (sometimes limited upon restrictions defined by the respective user). For example, one or more web pages may be defined for each user of the social network application that can be viewed by other users of the social network application. Also, social network applications typically allow a user to define a set of "friends," "contacts," or "members" with whom the respective user wishes to repeatedly communicate. Users of a social network application may post comments or other content to portions of each other's web pages.
[0005] For the purpose of this application, a social network application refers to any application in which users are permitted to create or define accounts in which the users can make personalized content available via the Internet for viewing by other users of the social network application and, in which, users can define, allow, or create contacts or friends within the social network application in which repeated interaction is intended to occur through the social network application.
SUMMARY
[0006] In one embodiment, a method for operating a social network application, comprises: capturing an image or video using a wireless device by a user of the social APPENDIX B
network application; communicating the image or video from the wireless device of the user to a social network application server; storing the image or video by the social network application server; identifying a user account by the social network application server in response to communication of the image or video; and modifying data, by the social network application server, associated with the account of the user to automatically post the image or video to a web page of the user to make the image or video available for viewing by other users of the social network application.
[0007] The foregoing has outlined rather broadly certain features and/or technical advantages in order that the detailed description that follows may be better understood. Additional features and/or advantages will be described hereinafter which form the subject of the claims. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the appended claims. The novel features, both as to organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIGURE 1 depicts a system for implementing a social network application in which image and/or video data can be communicated between "friends" using a location based service scheme or otherwise according to one representative embodiment.
[0009] FIGURE 2 depicts a flowchart for creating and/or managing a social network application account according to one representative embodiment. APPENDIX B
[0010] FIGURE 3 depicts a flowchart for communicating image and/or video data between users of a social network application according to one representative embodiment.
[0011] FIGURE 4 depicts a flowchart for communicating image and/or video data between users of a social network application according to another representative embodiment.
DETAILED DESCRIPTION
[0012] Some representative embodiments are directed to a social network application that permits users of the application to communicate image and/or video data using location based service functionality. In some embodiments, users of the social network upload image and/or video data to their accounts with the social network application using camera-capable wireless devices (e.g., digital camera enabled cellular phones). In preferred embodiments, location information is associated with the images or videos when transferred to the image/video server. Certain images may be communicated to all or selected members of each user's group of "friends" or "contacts" according to a "location based service" scheme. For example, suppose a first user takes a picture at a nightclub and transfers the picture to the image/video server using their camera phone. When other users of the social network who are "friends" of the first user arrive at the nightclub or any suitable location, the other users may receive communication of the image or video via their cell phones. In other embodiments, the image and/or videos are relatively immediately (e.g., within a few minutes) communicated to one or more users who are friends of the first user irrespective of the location of the users.
[0013] Referring now to the drawing(s), FIGURE 1 depicts system 100 for operating a social network according to one representative embodiment. Initially, a user can use their web browser 107 to access a web site served by social network application web server 106 through Internet 108. The user can create an account for sharing personal information, digital content, etc. with other users of the social network application. APPENDIX B
During creation of the account, the user can define a user ID, password, etc. which can be stored in database (DB) 102. The user can define a web page, upload content, etc. for their personal web page on the social network application, where the appropriate data is stored in DB 102. The user can also allow family members, friends, co-workers, acquaintances, other social network application users, etc. to become "friends" in the social network application as defined by data stored in DB 102.
[0014] Preferably, the users can provide appropriate information to facilitate the communication of image and/or video data using wireless devices of the users of the social network application (e.g., a phone number of the wireless device, the e-mail address/user information associated with the user's wireless device, etc.). In one embodiment, a JAVA™ MIDlet is stored on the user's wireless device to facilitate the communication of the image and/or video data. In another embodiment, during the account creation process, the user is provided a registration string and the user e-mails the registration string to a predefined e-mail address associated with the social network application. The user's e-mail information is automatically gathered from the registering user's e-mail. A user token can be optionally defined for inclusion within subsequently communicated image or video messages. Only image or video messages from appropriate e-mail addresses containing suitable user information and/or the user token are accepted for posting to a user's web page(s) or communication to other users.
[0015] Database 102 stores identifiers of the user accounts, the friends of each user, content for each user's web page within the social network application, various user information, user identifiers, user passwords, user cellular phone numbers or e-mail addresses, etc. It shall be appreciated that when the present application discusss a database or server, any suitable computing architecture could be employed. For example, the desired functionality could be duplicated using multiple instances of software and multiple platforms. The various software and platforms could also possess a distributed architecture. Also, DB 102 need not be implemented using a strict database application. Any suitable set of software for storing and managing data could be employed. APPENDIX B
[0016] After creating an account with the social network application, the users of the social network application can begin sharing image or video messages. A user can take a picture or a video at a given location. The user can transfer the image to e-mail server 104 or web server 106 as examples. In some embodiments, a MIDlet, a script, or another suitable program also is stored on the user's cell phone 110 to facilitate the transfer. The MIDlet preferably allows the user to input metadata (e.g., a text description) to be associated with the image and/or video data. Other data could also be associated with the image or video such as audio data.
[0017] In some embodiments, depending upon the capabilities of the wireless device, the MIDlet uses the cell phone functionality to determine the approximate location of the user's cell phone 110 (e.g., using the cell phone's 110 assisted GPS (AGPS) functionality), see e.g., the "location API" published for J2ME. In other embodiments (e.g., non-AGPS devices operating in GSM networks), the CELL-ID is obtained (e.g., using the appropriate API call using a PYTHON script on a Symbian OS- based cellular phones) for the purpose of automatically identifying the approximate location of the user's cell phone 110. Depending upon the capability of the wireless device the identifiers of "Wi-Fi" hotspots can be obtained for the purpose of identifying the approximate location of the user's device (i.e., the identifiers are used to perform a look-up of the user location against a database that correlates Wi-Fi identifiers to GPS, addresses, ZIP codes, or other coordinates). In alternative embodiments, a "network- location" service is used to determine the location associated with the user's cell phone
110 upon receipt of the e-mail. In an alternative embodiment, the user can input the location in a user interface of the MIDlet.
[0018] Upon receiving/obtaining the information, the MIDlet preferably creates an e-mail or "multi-media message" (MMS) containing the various information (perhaps in encrypted form) with the image as an attachment and communicates the e-mail/MMS
111 using cellular infrastructure 109. In other embodiments, the image and the metadata can be communicated separately. Other communication protocols could be alternatively employed. E-Mail/data server 104 may receive the image and the metadata and stores them in image DB 101. Other users within the social network may subsequently view the APPENDIX B
image/video and selected metadata via their cellular phones 110, their web browsers 107, their e-mail clients (not shown), etc. The metadata may also identify that the user wishes to immediately transfer the image and data to one or more selected friends within the social network. If so, e-mail/data server 104 preferably communicates the image or video to the other users' cellular phones or wireless devices 110.
[0019] When a user transfers an image to the image/video database, one or several advertisements are preferably sent to the user (and/or recipients of the image/video). In preferred embodiments, the location information is used to select one or several advertisements from advertisements DB 103. Additionally, the metadata is also used to select the one or several advertisements from DB 103 (e.g., using keyword matching and/or context analysis using the text description supplied by the given user). By utilizing such information, a more effective selection of advertisements can occur. Multiple advertisements can be communicated to the user at a single time. For example, browser-executable files can be communicated to allow the user to browse through multiple ads. Some of the ads in the browser-executable files can be described in text format and some of the ads can be shown with images. Any suitable format for the advertisements may be employed such as SMS messages, MMS messages, etc.
[0020] As previously mentioned, a user can communicate an image or video to one or several other "friends" within the social network application on a substantially immediate basis. Images and metadata can be shared in other ways. Users within the social network can view each other's images using their web browsers 107. Also, if desired, users within the social network could access the images via a browser executing on their cellular phone 110. In some embodiments, a user can communicate their current location (e.g., through manual data entry, through AGPS functionality of their phone, or automatically through a MIDlet) to obtain recently uploaded images or videos associated with "nearby" locations. For example, images or videos from a first user can automatically be communicated to friends of a first user when the friends arrive at locations where the first user had originally taken the images or videos. In preferred embodiments, the communication of image and/or video data is automatic. Specifically, when a user arrives at a given location, a MIDlet on the user's wireless device APPENDIX B
communicates the location of the wireless device to server 106. Web server 106 uses the location information to determine whether there are any images or videos from friends of the respective user associated with the current location of the user. If so, web server 106 communicates the images and/or videos to the user. For example, the images and/or videos may "pop-up" for presentation to the user when the user arrives at a specific location.
[0021] In some embodiments, a users can access one or more webpages (e.g., through a typical web browser or, perhaps, a wireless device-specific browser) to view uploaded images from their friends. The webpages preferably organize the images in multiple ways (e.g., by friend, by location, by types, by metadata descriptors, etc.). The user can navigate through a series of links corresponding to the organization of the images and videos to browse through content of interest. Alternatively, the user can submit a query for content of interest (of friends only and/or of other non- friend users) to receive search results from the database of images, videos, and metadata. Also, advertisements are preferably provided along with the images and videos - whether the user browses through the navigation links or submits a search query.
[0022] In some embodiments, when user wireless devices contain more advanced location functionality (e.g., AGPS functionality), a user within the social network may be notified when friends of the user within the social network application are present at the same approximate location for the purpose of allowing the friends to meet each other. For example, suppose a first user of the social network arrives at "Willow Bend" mall. When another user who is a friend of the first user arrives at the mall, the first user can be notified of the arrival of the second user and the second user can be notified of the particular location of the first user (e.g., at store "X"). In one representative embodiment, an image or video message from the other user can be delivered with the notification. Also, the location notification functionality can preferably be "turned" on and off by users of the social network application (if the users do not wish to be located at a particular time). The image or video message can be intended for any friend or specifically addressed for an identified "friend" (i.e., it will only be delivered to the identified friend). APPENDIX B
[0023] In some embodiments, video or images can be made available for any users within the social network application. For example, when a first user arrives at a location, the user may submit a request to view any recent images or videos uploaded for the user's current location using a MIDlet on the user's wireless device. A number of images or videos from other users (whether friends or not) may then be communicated to the first user. A list of available images or videos can be presented to the first user to permit the first user to select specific content for viewing. Additionally, the first user may submit various search terms to identify images or videos of interest to the first user from all available images or content for the current location of the first user. In one representative embodiments, a user may define various criteria via their account that define the types of videos that the user wishes to receive (whether from friends or otherwise). The social network application will then communicate matching image and/or videos to the user according to the defined criteria as the user goes from location to location.
[0024] FIGURE 2 depicts a flowchart for creating and/or managing a social network application account according to one representative embodiment. In 201 , a user accesses social network account creation web page. In 202, the user enters e-mail address, creates user id, password, in accordance with typical account creation methods. In 203, the user enters an identifier of the user's wireless device (e.g., the telephone number, the ESN/MIN, an e-mail address associated with an account maintained by the service provider of cellular services, etc.). In 204, the user creates, uploads, or identifies personalized content for user web page(s) using typical web methods. In 205, the user identifies friends with social network application. In 206, the user defines access restrictions for user's web page(s). The user can define restrictions that only permit certain users (e.g., only friends, only selected friends, users matching specific (demographic or otherwise) criteria) to view, access, or receive communication of certain types of content. For example, the user may only wish selected friends to receive images and video data via LBS functionality and the social network application will then only communicate such data to those friends.
10 APPENDIX B
[0025] In 207, the user downloads a MIDlet to wireless device for accessing social network application (e.g., uploading digital images or video). Preferably, the user is given instructions in a web page provided by the social network application during the account creation process how to access the MIDlet. For example, the user is preferably given a URL to enter in the browser of the user's wireless device to obtain the MIDlet and instructions upon how to install the URL on his or her phone. The MIDlet may be personalized for the user to make performing different actions within the social network more efficient such as to communicate with specific friends with the social network. In an alternative embodiment, a MIDlet may be pre-installed on a commercially available cellular phone or other wireless device and the user need only provide his or her account information (e.g., user ID, password, and/or the like) to make the MIDlet functional with regard to the user's account with the social network application.
[0026] FIGURE 3 depicts a flowchart for communicating image and/or video data between users of a social network application according to one representative embodiment. In 301 , a user takes an image or video using camera of user's wireless device. In 302, location information is associated with image or video. In 303, the user enters text description to associate with image or video. In 304, the user transfers image or video to social network server using wireless device. This may occur automatically by software on the user's wireless device in some embodiments. In 305, the social network server automatically associates received image or video with the user's account (e.g., makes the image or video available on the user's web page(s)). In 306, a logical determination is made whether the image or video is for immediate communication (e.g., whether the user wishes the image or video to be sent to specific friends of the user). If so, the social network server communicates the image or video to wireless devices of (selected) users (307). In 308, ads are selected and communicated to users.
[0027] FIGURE 4 depicts a flowchart for communicating image and/or video data between users of a social network application according to another representative embodiment. In 401 , a social network server receives location information from a wireless device of a user. In 402, the server compares location information to location information of stored images or videos. The location information may be information
11 APPENDIX B
that defines where the stored images or videos were originally taken. Alternatively, a user could input location information for association with images or videos independently from where the images or videos were taken. For example, a supervisor may create a video for traveling subordinate employees for viewing by the employees when the employees arrive at a particular location (e.g., a client's office complex). Such location information may be associated with an image or video by entering known GPS coordinates, a street address, or by selecting a region or area on a map interface provided by the social network application. In 403, the server selects matching images or videos based upon the sets of location information. Other information may be used for the matching such as any selection criteria provided by the user (e.g., from certain users, certain friends, keywords for matching in associated text descriptions, etc.). In 404, the social network server communicates images or videos to the wireless device of user. Additionally or alternatively, the social network server may communicate a list of available images or videos, possibly with thumbnails or short descriptions of the available content. In 405, ads are selected and communicated to users by a suitable server.
[0028] Representative embodiments can be used for a variety of purposes to facilitate interaction between users of a social network application. For example, a company may implement a social network application to manage employees of the company according to various levels of corporate hierarchies. In accordance with one representative embodiment, the distribution of image and/or videos using location based services for such a social network application permits managers of the company to give specific direction and distribute information to employees when the employees are engaged in activities in the field.
[0029] As another example, a "dating" social network application may allow a first user who is seeking to meet new people to leave a video to be distributed to other users of the matching specific criteria for delivery at a specific location where the user is currently located (e.g., at a coffee house, bookstore, nightclub, etc.). Thereby, if any user matching the criteria arrives at the location, the image or video of the first user is
12 APPENDIX B
automatically delivered to the other users giving the other users notification that the first user is at the location, is seeking to meet new people, and information about the first user.
[0030] When implemented in software, the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks. Any type of suitable code or software may be utilized from machine code, complied software, interpreted software, browser executable code (e.g., HTML, JAVA script, FLASH code, etc), "JAVA" variants, PYTHON scripts, and/or the like. The program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The "computer readable medium" may include any medium that can store or transfer information. Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, an intranet, etc.
[0031] Although representative embodiments and advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
13 APPENDIX B
Figure imgf000070_0001
USER ACCESSES
201 . SOCIAL NETWORK
ACCOUNT CREATION USER DEFINES ACCESS
WEB PAGE RESTRICTIONS FOR 206
USER'S WEB PAGE(S)
USER ENTERS
202 A. E-MAIL ADDRESS,
USER DOWNLOADS
CREATES USER ID, MIDLET TO
PASSWORD WIRELESS DEVICE
FOR ACCESSING s~ 207
SOCIAL NETWORK APPLICATION
(E.G., UPLOADING
USER ENTERS IDENTIFIER 03- DIGITIAL IMAGES OR VIDEO)
OF USER'S WIRELESS
DEVICE
USER CREATES, UPLOADS, - OR IDENTIFIES PERSONALIZED
CONTENT FOR USER WEB FIG. 2
PAGE(S)
USER IDENTIFIES FRIENDS
WITH SOCIAL NETWORK
APPLICATION APPENDIX B
Figure imgf000071_0001
FIG. 3 APPENDIX C
NON-PROVISIONAL PATENT APPLICATION IN THE UNITED STATES PATENT
AND TRADEMARK OFFICE
TITLE
SEARCH ENGINE PROVIDING PERSISTENT SEARCH FUNCTIONALITY OVER MULTIPLE SEARCH QUERIES AND METHOD FOR OPERATING THE SAME
INVENTOR
CS. LEE CRAWFORD
FRISCO, TX CITIZENSHIP: USA
Correspondence Address: CS. Lee Crawford 12132 Terrazzo Lane Frisco, TX 75035 APPENDIX C
RELATED APPLICATIONS
[0001] The present application claims the benefit of the following provisional patent applications: U.S. Provisional Application Serial No. 60/736,252, filed Nov. 14, 2005, U.S. Provisional Patent Application No. 60/759,303, filed 01/17/2006 and U.S. Provisional Patent Application No. 60/773,852, filed 02/16/2006, all of which are incorporated herein by reference.
BACKGROUND
[0002] A number of search engines exist that provide searching operations to be conducted on documents present on the Internet. However, as the number of documents on the Internet has increased on very substantial basis, the efficiency of search operations using conventional search engines has significantly lessened. Specifically, a keyword search provided by a user to a search engine can present a very large number of "hits" for a user to traverse. Moreover, because of the very large number of documents present on the Internet, the "hits" may include a large number of documents that contain the keywords in a manner not contemplated by and, typically, in an irrelevant manner to the searching user. Accordingly, the user typically must provide multiple queries in an attempt to locate documents of interest.
SUMMARY
[0003] In one embodiment, a method of operating a search engine comprises: initiating a continuous search state from a user; receiving multiple search queries during the continuous search state; and providing search results to the user, wherein the providing filters search results previously presented to the user in response to prior search queries during the continuous search state.
[0004] The foregoing has outlined rather broadly certain features and/or technical advantages in order that the detailed description that follows may be better understood. Additional features and/or advantages will be described hereinafter which form the subject of the claims. It should be appreciated by those skilled in the art that the APPENDIX C
conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the appended claims. The novel features, both as to organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the appended claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIGURE 1 depicts a web page for initiating a continuous search according to one representative embodiment.
[0006] FIGURE 2 depicts a response web page for a search engine for a continuous search according to one representative embodiment.
[0007] FIGURE 3 depicts a web page including search results presented in a manner for user review according to a continuous search according to some representative embodiments.
[0008] FIGURE 4 depicts a web page after re-sorting operations occur according to one representative embodiment.
[0009] FIGURE 5 depicts a web page to display stored search results according to one representative embodiment.
[0010] FIGURE 6 depicts a web page with various prior search terms according to one representative embodiment.
DETAILED DESCRIPTION
[0011] Representative embodiments enable a user to search for documents via a search engine over multiple independent or related queries on an efficient basis. APPENDIX C
Specifically, some representative embodiments enable a "continuous" search using an Internet search engine to be conducted in which documents can be saved in association across multiple search queries, documents excluded from subsequent query results, documents types of relevance and irrelevance identified for sorting of present and subsequent queries, and/or other such operations spanning multiple search queries. By managing search information across multiple searches, Internet searches can be conducted in an efficient manner.
[0012] Some representative embodiments enable a user to enter a "continuous" search through the common search engine web page presented by the search engine. FIGURE 1 depicts web page 100 for initiating a continuous search according to one representative embodiment. Web page 100 includes the typical graphical controls present in search engines to enter information defining a search query. Web page 100 also includes control 150 (e.g., a "button" or, alternatively, a hyperlink) that allows a user to start a continuous search. By selecting button 150, the selection is communicated to one of the web servers associated with the search engine via typical HTTP processing. The button allows the user to ability to enter the continuous search mode (i.e., the review or resume prior continuous searches or to start a new continuous search).
[0013] In response, the search engine generates web page 200 (shown in FIGURE 2) according to one representative embodiment. Web page 200 includes the same controls as web page 100 for defining search query terms. The web query term controls shown in FIGURE 2 are by way of example. Any suitable set of query term controls could be utilized according to representative embodiments. Web page 200 further includes control 210 for entering a name for the continuous search for further identification to the user (assuming the user wishes to start a new continuous search). Web page 200 further includes list 220 having a list of hyperlinks for prior searches (should the user wish to resume or review a prior search). Depending upon the number of saved searches, additional controls (not shown) could be provided to allow the user to review other searches not immediately displayed in web page 200. APPENDIX C
[0014] Preferably, the search engine stores a "cookie" on the user system to allow the search engine to identify the user for the presentation of the prior searches of the user. In an alternative embodiment, the user can enter a user id and/or password via an intermediate web page to allow the user to retrieve and control the user's continuous searches. In an alternative embodiment, web pages 100 and 200 could be integrated into a single web page if desired.
[0015] Assuming the user starts a new continuous search and enters query terms, the query terms and the search name are communicated to a server of the search engine according to conventional HTTP operations. Search results are generated and sorted according to conventional search engine operations. A first web page of search results is communicated to the user. Also, one or several search file(s) are created to save information for the continuous search. The created search file(s) are associated with the user and the search name.
[0016] As shown in FIGURE 3, web page 300 illustrates search results presented in a manner for user review according to a continuous search according to some representative embodiments. The typical search results information can be provided such as the titles of the web pages, summary information of the web page (perhaps, including a portion of text from the result document containing the keyword(s)), and other such information. The search results can include hyperlinks (shown as 301 and 302) to allow the user to review the particular result documents. Preferably, the hyperlinks cause the document(s) to be presented in a separate "pop-up" window of the browser. Web page 300 may also include typical controls for navigating the search results (previous page button 321, next page button 322, go to page control 323, etc.)
[0017] Each of the search results is preferably associated with one or several controls for continuous search operations. For example, the user can store a reference to a web page using store control 311 (which is preferably a "check-box" or "radio" control). The user can also cause a particular page to be excluded from subsequent search results using control 312. In alternative embodiments, a particular page can be APPENDIX C
automatically excluded by merely being included in reviewed results associated with a prior search query in the continuous search process. Control 313 enables the user to indicate that the respective document is the type of document that the user wishes to review during the continuous search. Similarly, control 314 enables the user to indicate that the respective document is not the type of document that the user wishes to review during the continuous search.
[0018] In a preferred embodiment, controls 311 - 314 do not operate to transfer information immediately upon selection. Instead, the selections associated with controls 311 - 314 are communicated when one of the page controls 321, 322, or 323 or continuous search buttons 324 - 328. Specifically, when one of these buttons or controls are activated by the user, the page information is communicated to a server of the search engine via conventional HTTP operations. The search engine then updates the continuous search file(s).
[0019] If the user has selected any search results using a "stored" control 311, an identifier of the particular document (e.g., the URL, the date associated with the time that the web crawler indexed the URL, etc.) is stored in one of the search file(s). In some embodiments, each identified document (e.g., the HTML page, the associated object/image files, etc.) is also stored. The benefit of storing the identified documents is the search can be reviewed at substantially later dates (e.g., after the original documents have been removed from the Internet or otherwise modified).
[0020] When the user selects the exclude control 322 for one or several search results, the identifier(s) of the "excluded" document(s) is/are stored. These stored URLs are preferably used to filter these documents from the results generated from subsequent queries. In alternative embodiments, all of the documents identified in a result page are stored in an "exclude" file for filtering results from subsequent search queries within the continuous search.
[0021] When the user selects one or several of controls 313 and 314, the URL(s) is/are stored in a search file(s). When subsequent results are sorted, a similarity metric is calculated for each search result against each of the documents identified using APPENDIX C
controls 313 and 314. The similarity metric can be calculated using any suitable known or later developed document comparison algorithm. If a search result document is similar to one or several "this type" previously identified documents, the search result document is given a higher weight for the sorting algorithm. If a search result document is similar to one or several "not this type" previously identified documents, the search result document is given a lower weight for the sorting algorithm.
[0022] The user can re-sort the current search results using re-sort control 327 as affected by the selection of any of controls 313 and 314. The user can alternatively decide to change the current search terms or enter an entirely new set of search terms using control 326. Upon selection of control 326, the user can be presented web page 400 as shown in FIGURE 4. Additionally, the user could review the previously presented search terms by selecting control 325. Web page 600 (as shown in FIGURE 6) with various prior search terms 611 could be presented in a pop-up window in response to the selection of control 325. If the user wishes to end or temporarily suspend the continuous search, the user can depress control 328. The user can be taken to a predefined web page (e.g., a "portal page") upon selection of control 328. Also, when the user selects control 328, the state information at the server(s) of the search engine and/or within a cookie on the user system can be modified to reflect the end/suspension of the continuous search.
[0023] If the user wishes to review the stored search results, the user may select control 324. Upon selection, web page 500 as shown in FIGURE 5 can be generated to display stored search results 521. If the user wishes to review the actual document, the user can click on one of the titles and, preferably, the actual document is displayed in a pop-up window. If user can "unstore" the document using control 511 which causes the identifier of the document to removed from the search file(s). Alternatively, the user could choose to "exclude" the document using control 312. Right kind and wrong kind controls 313 and 314 could also be included within web page 500. Depending upon the number of stored results, controls 321, 322, and 323 could be provided to navigate between multiple pages of stored results. The user could return to the current results generated by the most recent search terms using control 531. Also, in one embodiment, APPENDIX C
the search term(s) 551 associated with each stored result could be shown adjacent to the respective stored search result.
[0024] Some representative embodiments enable a user to conduct an Internet or other search in a substantially efficient manner. A user can quickly review a number of hits, identifying potentially relevant hits, and store the potentially relevant hits for further review. The user can quickly revise the search without losing the stored hits. Also, the user need not repetitively review information that the user has already seen. Specifically, when additional search results are presented in response to revised search terms or new search terms, hits that were deemed irrelevant need not be re -reviewed by the user. The user can also suspend the search at any point and resume the search at a later time if desired. Also, the stored documents can be cached by the search engine to ensure that the user can retrieve the documents at a later time even if the documents become modified or are removed from their original web servers.
[0025] When implemented in software, the various elements or components of representative embodiments are the code or software segments adapted to perform the respective tasks. In some embodiments, some of the software is implemented using a freely available web server (such as the APACHE web server) and custom PERL scripts for implementing the continuous search functionality. In some embodiments, some of the software may be executed on a search user's computing platform and may include machine code, complied software, interpreted software, browser executable code via a "plug-in" or otherwise (e.g., HTML, JAVA script, FLASH code, etc), and/or the like. The program or code segments can be stored in a machine readable medium, such as a processor readable medium, or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The "computer readable medium" may include any medium that can store or transfer information. Examples of the computer readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, an erasable programmable ROM (EPROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, Intranet, etc.
[0026] Although representative embodiments and advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure that processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
APPENDIX C
Figure imgf000081_0001
S
100
SEARCH
Figure imgf000081_0005
FIG. 1
PRIOR SEACHES
SEACH NAME SEARCH NAME #1 ALL OF THE WORDS
Figure imgf000081_0002
ME #N
Figure imgf000081_0003
200
SEARCH
Figure imgf000081_0006
FIG. 2
330 New Search Name 300 Current Terms
/
301 Page # 1 TITLE
^" SUMMARY INFO π STORE π EXCLUDE LZ] RIGHT KIND IZ] WRONG KIND ^- 311 V 312 V 313 V-314
302 Page # N TITLE FIG. 3
"X- SUMMARY INFO
□ STORE π EXCLUDE LZI RIGHT KIND LZ] WRONG KIND V. 311 V 312 V. 313 V. 314 N — 323
END SEARCH
Figure imgf000081_0004
328 APPENDIX C
NEW SEARCH NAME
PRIOR SEARCH TERMS ALL OF THE WORDS
PRIOR SEARCH TERMS EXACT PHRASE
SEARCH 20 IL NEW SEARCH NAME
"400
611 600
CLEAR - SEARCH TERM(S) 1
/
N
Figure imgf000082_0001
PAGE M OF N
FIG. 4 PREVIOUS NEXT GO TO D
FIG. 6
551
NEW SEARCH NAME (STORED PAGES)
/ 521 STORED PAGE # 1 : TITLE (SEARCH TERM 1) SUMMARY INFO
□ UNSTORE P EXCLUDE D RIGHT KIND D WRONG KIND
V 51 1 V 312 ^ 313 V 314
551
500
/
522- STORED PAGE # N: TITLE (SEARCH TERM N) SUMMARY INFO
FIG. 5
O UNSTORE P EXCLUDE P RIGHT KIND P WRONG KIND
V 511 V 312 V 313 V 314
321. PAGE M OF N — 323
PREVIOUS NEXT 322 GO TO D
Figure imgf000082_0002

Claims

1. A method of providing a location based service (LBS), comprising: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information, by one or more software programs, to identify specific activities of subscribers at merchant locations from a plurality of predefined set of activities; storing identified activities in a respective activity log for each of the plurality of subscribers; comparing ad parameters against subscriber data, including data stored in the activity logs, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have already completed one or more activities as identified in the respective subscribers' activity logs; and communicating selected ads to wireless devices of the subscribers.
2. The method of claim 1 wherein the predefined set of activities comprises a hierarchical arrangement of activities and sub-activities.
3. The method of claim 1 wherein the storing comprises: identifying times when respective subscribers have completed respective activities.
4. The method of claim 3 wherein the storing comprises: identifying times when respective subscribers have begun respective activities.
5. The method of claim 1 wherein the storing comprises: identifying specific types of merchants that respective subscribers have visited.
6. The method of claim 1 further comprising: monitoring one or more financial accounts to identify transactions made by subscribers; and storing information in activity logs of subscribers that transactions have been completed.
7. A method of providing a location based service (LBS), comprising: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information, by one or more software programs, to identify activity of subscribers at merchant locations; storing the processed location information in a log for each of the plurality of subscribers; receiving or defining ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify one or more activities from a predefined set of specific activities; comparing ad parameters against subscriber data, including data stored in the logs, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have already completed one or more activities associated with the ad parameters; and communicating selected ads to wireless devices of the subscribers.
8. The method of claim 7 wherein the predefined set of activities comprises a hierarchical arrangement of activities and sub-activities.
9. The method of claim 7 wherein the storing comprises: identifying times when respective subscribers have completed respective activities.
10. The method of claim 7 wherein the storing comprises: identifying times when respective subscribers have begun respective activities.
11. The method of claim 7 wherein the storing comprises: identifying specific types of merchants that respective subscribers have visited.
12. The method of claim 7 wherein the processing comprises: comparing location information to information in one or more databases that associate a plurality of activities with sub-store locations within specific merchant stores.
13. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) process the location information, by one or more software programs, to identify specific activities of subscribers at merchant locations from a plurality of predefined set of activities;
(iii) store identified activities in a respective activity log for each of the plurality of subscribers;
(iv) compare ad parameters against subscriber data, including data stored in the activity logs, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have already completed one or more activities as identified in the respective subscribers' activity logs; and (v) communicate selected ads to wireless devices of the subscribers.
14. The system of claim 13 wherein the predefined set of activities comprises a hierarchical arrangement of activities and sub-activities.
15. The system of claim 13 wherein (iii) comprises: identifying times when respective subscribers have completed respective activities.
16. The system of claim 15 wherein (iii) comprises: identifying times when respective subscribers have begun respective activities.
17. The system of claim 13 wherein (iii) comprises: identifying specific types of merchants that respective subscribers have visited.
18. The system of claim 13 the one or more second software programs being further operable to: monitor one or more financial accounts to identify transactions made by subscribers; and store information in activity logs of subscribers that transactions have been completed.
19. The system of claim 13 the one or more second software programs being further operable to: receive or define ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify one or more activities from a predefined set of specific activities; compare ad parameters against subscriber data, including data stored in the logs, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have already completed one or more activities associated with the ad parameters.
20. The system of claim 13 wherein the processing comprises: comparing location information to information in one or more databases that associate a plurality of activities with sub-store locations within specific merchant stores.
21. A method of providing a location based service (LBS), comprising:
(i) receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) processing the location information, by one or more software programs, to identify activities of subscribers at respective locations over a period of time;
(iii) detecting repeated occurrences of first activities performed by respective subscribers in relation to occurrences of second activities by the same respective subscribers;
(iv) storing data for each of the respective subscribers indicative of a propensity of each of said respective subscribers to engage in the respective subscriber's first activity in relation to the respective subscriber's second activity;
(v) detecting subscribers engaging in their respective second activities subsequent to performance of (iv) as identified using the stored data; and
(vi) communicating ads relevant to the respective subscriber's first activity in response to at least the detecting in (v).
22. The method of claim 21 wherein the communicating comprises: communicating some of the ads while the respective subscribers are engaged in their respective first activities.
23. The method of claim 21 further comprising: communicating some of the ads upon or after completion of some of the subscribers' first activities.
24. The method of claim 21 wherein the (iii) detecting comprises: calculating a number of times that a respective subscriber engaged in the subscriber's first activity within a predefined amount of time after engaging in the subscriber's second activity.
25. The method of claim 24 wherein the predefined amount of time is less than three hours.
26. The method of claim 21 wherein, for some of the subscribers, the subscribers' second activities are non-shopping related activities.
27. The method of claim 26 wherein, for some of the subscribers, the subscribers' second activities are traveling-related activities.
28. The method of claim 26 wherein, for some of the subscribers, the subscribers' second activities are sports-related activities.
29. The method of claim 21 further comprising: storing norm transaction amounts for some subscribers that occur for the respective second activities of some subscribers.
30. The method of claim 29 wherein ads selected for the communicating (vi) are selected using at least the norm transaction amounts.
31. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) process the location information, by one or more software programs, to identify activities of subscribers at respective locations over a period of time;
(iii) detect repeated occurrences of first activities performed by respective subscribers in relation to occurrences of second activities by the same respective subscribers;
(iv) store data for each of the respective subscribers indicative of a propensity of each of said respective subscribers to engage in the respective subscriber's first activity in relation to the respective subscriber's second activity;
(v) detect subscribers engaging in their respective second activities subsequent to performance of (iv) as identified using the stored data; and
(vi) communicate ads relevant to the respective subscriber's first activity in response to at least the detecting in (v).
32. The system of claim 31 wherein (vi): communicates some of the ads while the respective subscribers are engaged in their respective first activities.
33. The system of claim 32 wherein (vi): communicates some of the ads upon or after completion of some of the subscribers' first activities.
34. The system of claim 31 wherein (iii) comprises: calculating a number of times that a respective subscriber engaged in the subscriber's first activity within a predefined amount of time after engaging in the subscriber's second activity.
35. The system of claim 34 wherein the predefined amount of time is less than three hours.
36. The system of claim 31 wherein, for some of the subscribers, the subscribers' second activities are non-shopping related activities.
37. The system of claim 36 wherein, for some of the subscribers, the subscribers' second activities are traveling-related activities.
38. The system of claim 36 wherein, for some of the subscribers, the subscribers' second activities are sports-related activities.
39. The system of claim 31 wherein the one or more second software programs are further operable to: store norm transaction amounts for some subscribers that occur for the respective second activities of some subscribers.
40. The system of claim 39 wherein ads selected in (vi) are selected using at least the norm transaction amounts.
41. A method of providing a location based service (LBS), comprising: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing the location information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of time spent by respective subscribers at merchant locations or merchant-type locations; processing recent location information for at least some of the subscribers to track activity across multiple merchants or merchant-types; comparing the processed recent location information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have spent more or less time than time associated with the respective subscribers' norm data; and communicating selected ads to wireless devices of the subscribers.
42. The method of claim 41 wherein the norm data stores data indicative of typical amounts of time spent at a plurality of merchant-types for each subscriber.
43. The method of claim 42 wherein the processing adds time spent at multiple specific merchants for subscribers for merchants of a particular merchant-type.
44. The method of claim 43 wherein the comparing differentiates by omitting selection of some ads for certain merchant-types for subscribers that have spent an amount of time more than indicated in those subscribers' norm data for those merchant- types.
45. The method of claim 41 wherein the norm data stores standard deviation information related to amounts of time spent by subscribers at various merchant locations or merchant-type locations, the comparing analyzing processed recent location information against the standard deviation information.
46. The method of claim 41 wherein the recent location information is limited to location information for a current day.
47. The method of claim 41 wherein the recent location information is limited to location information for respective shopping trips for each subscriber.
48. A method of providing a location based service (LBS), comprising: receiving location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services; processing recent location information for at least some of the subscribers to track activity at merchant locations; receiving or defining ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify timing parameters that identify amounts of time at respective merchant locations for delivery of ads; comparing the processed recent location information for the plurality of subscribers against the ad parameters to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have spent more or less time than time at respective merchant locations compared to times defined in the ad parameters; and communicating selected ads to wireless devices of the subscribers.
49. The method of claim 48 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchants.
50. The method of claim 48 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchant types.
51. The method of claim 48 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchant types.
52. The method of claim4 8 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at a retail location that comprises a plurality of merchants.
53. The method of claim 48 wherein some of the ads parameters pay for placement according to timing parameters that identify amounts of time at respective merchant locations.
54. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive location information by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) process the location information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of time spent by respective subscribers at merchant locations or merchant-type locations;
(iii) process recent location information for at least some of the subscribers to track activity across multiple merchants or merchant-types;
(iv) compare the processed recent location information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have spent more or less time across multiple merchants or merchant-types than time associated with the respective subscribers' norm data; and
(v) communicate selected ads to wireless devices of the subscribers.
55. The system of claim 54 wherein the one or more second software programs are further operable to: receive or define ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify timing parameters that identify amounts of time at respective merchant locations for delivery of ads; the comparing further selecting ads in relation to the ad parameters.
56. The system of claim 55 wherein some of the ads parameters pay for placement according to timing parameters that identify amounts of time at respective merchant locations.
57. The system of claim 54 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchants.
58. The system of claim 54 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchant types.
59. The system of claim 54 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at respective merchant types.
60. The system of claim 54 wherein some of the ad parameters define amounts of time relative to norm parameters that reflect average or typical amounts of time spent by respective subscriber at a retail location that comprises a plurality of merchants.
61. A method of providing a location based service (LBS), comprising: receiving information pertaining to financial transactions completed by a plurality of subscribers; processing the information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of funds spent by respective subscribers at merchants or merchant-types; receiving location information from wireless devices of the plurality of subscribers; processing recent transaction information for at least some of the subscribers to track multiple purchases of each subscriber at respective merchants or merchant types; comparing the processed recent transaction information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by comparing amounts determined by the processed recent transaction information is greater or less than funds associated with the respective subscribers' norm data, the selection of ads further occurring in relation to the received location information; and communicating selected ads to wireless devices of the subscribers.
62. The method of claim 61 wherein the norm data relates typical amounts of funds spent by subscribers using a plurality of hierarchical categories.
63. The method of claim 61 wherein the comparing compares processed recent transaction information for a month-long period of time against the norm data.
64. The method of claim 61 wherein the comparing compares processed recent transaction information for current recent shopping trips.
65. The method of claim 1 wherein the comparing compares processed recent transaction information for a current day.
66. The method of claim 61 wherein the processing the information further comprises: calculating standard deviations for typical amounts of funds spent by respective subscribers at merchants or merchant-types for inclusion within the norm data, wherein the comparing further differentiates in relation to the standard deviation norm data in comparison against the processed recent transaction information.
67. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive information pertaining to financial transactions completed by a plurality of subscribers;
(ii) process the information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of funds spent by respective subscribers at merchants or merchant-types;
(iii) receive location information from wireless devices of the plurality of subscribers;
(iv) process recent transaction information for at least some of the subscribers to track multiple purchases of each subscriber at respective merchants or merchant types;
(v) compare the processed recent transaction information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by comparing amounts determined by the processed recent transaction information is greater or less than funds associated with the respective subscribers' norm data, the selection of ads further occurring in relation to the received location information; and (vi) communicate selected ads to wireless devices of the subscribers.
68. The system of claim 66 wherein the norm data relates typical amounts of funds spent by subscribers using a plurality of hierarchical categories.
69. The system of claim 66 wherein (v) compares processed recent transaction information for a month-long period of time against the norm data.
70. The system of claim 6 wherein (v) compares processed recent transaction information for current recent shopping trips.
71. The system of claim 71 wherein (v) compares processed recent transaction information for a current day.
72. The system of claim 71 wherein (iv) further comprises: calculating standard deviations for typical amounts of funds spent by respective subscribers at merchants or merchant-types for inclusion within the norm data, wherein the comparing further differentiates in relation to the standard deviation norm data in comparison against the processed recent transaction information.
73. The system of claim 71 further comprising: receiving or defining ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify financial parameters that select or identify a set of transactions from a plurality of sets of transaction types and identify or define amounts of funds, wherein (v) further sets subscribers by comparing subscriber data against the ad parameters.
74. A method of providing a location based service (LBS), comprising: receiving information pertaining to financial transactions completed by a plurality of subscribers; processing the information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of funds for a plurality sets of transaction types; receiving or defining ad parameters for selecting subscribers for receipt of ads, wherein at least some of the ad parameters define or identify financial parameters that select or identify a set of transactions from the plurality of sets of transaction types and identify or define amounts of funds; receiving location information from wireless devices of the plurality of subscribers; comparing ad parameters against subscriber data, including data stored in the norm data, to select ads for communication to subscribers, wherein the comparing further selects ads in relation to recent location information from subscribers; and communicating selected ads to wireless devices of the subscribers.
75. The method of claim 74 wherein the plurality of sets of transaction types are organized into hierarchical categories of transaction types.
76. The method of claim 74 wherein the processing the information further comprises: calculating standard deviations for typical amounts of funds spent by respective subscribers at merchants or merchant-types for inclusion within the norm data, wherein the comparing further differentiates in relation to the standard deviation norm data in comparison against processed recent transaction information.
77. The method of claim 74 wherein selection of ads for subscribers further comprises: determining whether subscribers have recently made completed transactions pertaining to the selected set of transactions as identified in the ad parameters.
78. The method of claim 74 wherein norm data defines a typical transaction amount for the selected set of transactions.
79. The method of claim 74 wherein the norm data defines a typical amount spent over a predefined period of time for the selected set of transactions.
80. The method of claim 74 wherein the period of time is a single shopping trip.
81. A method of providing a location based service (LBS), comprising: receiving information pertaining to financial transactions completed by a plurality of subscribers; processing the information over time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical numbers of transaction completed by respective subscribers at multiple merchants, merchant-types, or merchant locations; receiving location information from wireless devices of the plurality of subscribers; processing recent transaction information for at least some of the subscribers to track multiple purchases of each subscriber at merchants, merchant-types, or merchant locations; comparing the processed recent transaction information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have completed more or less transactions than transactions associated with the respective subscribers' norm data, the selection of ads further occurring in relation to the received location information; and communicatin 1gB selected ads to wireless devices of the subscribers.
82. The method of claim 81 wherein the norm data relates numbers of purchases made by subscribers using a plurality of hierarchical categories.
83. The method of claim 81 wherein (v) compares processed recent transaction information for a month-long period of time against the norm data.
84. The method of claim 81 wherein (v) compares processed recent transaction information for current recent shopping trips.
85. The method of claim 81 wherein (v) compares processed recent transaction information for a current day.
86. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive information pertaining to financial transactions completed by a plurality of subscribers;
(ii) process the information over time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical numbers of transaction completed by respective subscribers at multiple merchants, merchant-types, or merchant locations;
(iii) receive location information from wireless devices of the plurality of subscribers;
(iv) process recent transaction information for at least some of the subscribers to track multiple purchases of each subscriber at merchants, merchant-types, or merchant locations;
(v) compare the processed recent transaction information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether respective subscribers have completed more or less transactions than transactions associated with the respective subscribers' norm data, the selection of ads further occurring in relation to the received location information; and
(vi) communicate selected ads to wireless devices of the subscribers.
87. The system of claim 85 wherein the norm data relates numbers of purchases made by subscribers using a plurality of hierarchical categories.
88. The system of claim 85 wherein (v) compares processed recent transaction information for a month-long period of time against the norm data.
89. The system of claim 85 wherein (v) compares processed recent transaction information for current recent shopping trips.
90. The system of claim 85 wherein (v) compares processed recent transaction information for a current day.
91. A method of providing a location based service (LBS), comprising:
(i) receiving location information over a period of time by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) processing the location information to detect that respective subscribers tend to spend time at one or more locations with one or more other specific subscribers;
(iii) storing data indicative of a tendency of each such subscriber to spend time with the subscriber's one or more other specific subscribers;
(iv) detecting whether subscribers are present at locations with one or more specific subscribers identified in the stored data subsequent to performance of (ii) and (iii); and
(v) comparing ad parameters against subscriber data, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers in response to (iv); and
(vi) communicating selected ads to wireless devices of the subscribers.
92. The method of claim 91 wherein the comparing comprises: determining whether a respective subscriber is present with peer subscribers at a given location.
93. The method of claim 91 wherein the comparing comprises: determining whether a respective subscriber is present with family members at a given location.
94. The method of claim 91 wherein the comparing comprises: determining whether a respective subscriber is present with business associates at a given location.
95. The method of claim 91 further comprising: monitoring financial transactions and storing data pertaining thereto for at least some of the subscribers, the stored data pertaining to financial transactions being used for selection of ads.
96. The method of claim 95 wherein the processing further comprises: identifying a subscriber of a group of subscribers that is more likely to pay for selected types of transactions when the group of subscribers are present at a location together.
97. The method of claim 95 wherein the processing further comprises: identifying changes in purchase probabilities for certain goods or services when respective subscribers are present together in respective groups of subscribers.
98. The method of claim 95 wherein the identifying examines changes in probability in relation to specific groups of other subscribers with which a respective subscriber tends to spend time.
99. The method of claim 91 wherein the processing further comprises: identifying types of goods, services, or merchants that are frequented by a respective subscriber when the subscriber is present with a group of other subscribers.
100. The method of claim 91 wherein the ad parameters identify target subscribers in relation to whether the target subscribers are clustering with other subscribers.
101. A system for providing one or more location based services, comprising: one or more first software programs executed on one or more wireless devices, the one or more software programs operable to communicate location information indicative of the location of the one or more wireless devices; one or more servers for receiving location information generated by the one or more software programs, the one or more servers executing one or more second software programs, the one or more second software programs being operable to:
(i) receive location information over a period of time by one or more software programs from a plurality of wireless devices belonging to a plurality of subscribers of one or more location based services;
(ii) process the location information to detect that respective subscribers tend to spend time at one or more locations with one or more other specific subscribers;
(iii) store data indicative of a tendency of each such subscriber to spend time with the subscriber's one or more other specific subscribers;
(iv) detect whether subscribers are present at locations with one or more specific subscribers identified in the stored data subsequent to performance of (ii) and (iii); and
(v) compare ad parameters against subscriber data, to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers in response to (iv); and
(vi) communicate selected ads to wireless devices of the subscribers.
102. The system of claim 101 wherein (v) comprises: determining whether a respective subscriber is present with peer subscribers at a given location.
103. The system of claim 101 wherein (v) comprises: determining whether a respective subscriber is present with family members at a given location.
104. The system of claim 101 wherein (v) comprises: determining whether a respective subscriber is present with business associates at a given location.
105. The system of claim 101 wherein the one or more second software programs being further operable to: monitoring financial transactions and storing data pertaining thereto for at least some of the subscribers, the stored data pertaining to financial transactions being used for selection of ads.
106. The system of claim 105 wherein (ii) comprises: identifying a subscriber of a group of subscribers that is more likely to pay for selected types of transactions when the group of subscribers are present at a location together.
107. The system of claim 105 wherein (ii) comprises: identifying changes in purchase probabilities for certain goods or services when respective subscribers are present together in respective groups of subscribers.
108. The system of claim 105 wherein the identifying examines changes in probability in relation to specific groups of other subscribers with which a respective subscriber tends to spend time.
109. The system of claim 101 wherein (ii) comprises: identifying types of goods, services, or merchants that are frequented by a respective subscriber when the subscriber is present with a group of other subscribers.
110. The system of claim 101 wherein the ad parameters identify target subscribers in relation to whether the target subscribers are clustering with other subscribers.
111. A method for providing and using a customized user interface on a wireless device for controlling transactions using a financial account, comprising: accessing a web server by a subscriber; interacting, by the subscriber, with the web server to define or select one or more transaction categories, the defined or selected one or more transaction categories being used to generate a customized user interface for the subscriber, the customized user interface being installed or configured to execute on a wireless device of the subscriber, wherein the customized user interface provides one or more selection options for each of the defined or selected transaction categories; selecting, by the subscriber, one or more of the selection options to authorize one or more transactions, using one or more respective defined or selected transaction categories, to be completed using the financial account; and using the financial account after the selecting to pay for one or more transactions according to the selected one or more of the selection options.
112. The method of claim 111 wherein the subscriber is required to initiate a transaction within a predefined period of time after selection of an option from the selection options of the customized user interface.
113. The method of claim 111 wherein the using the financial account comprises providing a payment card identifying the financial account to a merchant.
114. The method of claim 111 wherein the customized user interface is installed on the wireless device as an executable script.
115. The method of claim 111 wherein the selecting causes the customized user interface to securely communicate with one or more servers of a financial institution to active one or more defined or selected transaction categories for completion of transactions.
116. The method of claim 115 wherein the customized user interface communicates data pertaining to a current location of the wireless device of the subscriber and immediate subsequent transactions are limited to be originated in an area relative to the current location for the defined or selected transaction categories.
117. The method of claim 111 wherein the interacting further comprises: defining one or more rules for the defined or selected transaction categories.
118. The method of claim 117 wherein the one or more rules define respective budget limits for the defined or selected transaction categories.
119. The method of claim 118 wherein the customized user interface display unspent funds for the defined or selected transaction categories.
120. The method of claim 111 further comprising: receiving, after the selecting is performed, one or more advertisements by the wireless device of the subscriber that are relevant to the selected one or more of the selection options.
121. A method of operating search engine software on one or more servers, comprises: initiating a continuous search state from a user; receiving, in succession, multiple search queries from the user during the continuous search state; and providing search results to the user in succession for the multiple search queries, wherein the providing filters search results previously presented to the user in response to prior search queries during the continuous search state.
122. The method of claim 121 wherein the providing filters results identified by the user for exclusion.
123. The method of claim 121 wherein the providing filters results identified for storage by the user.
124. The method of claim 121 further comprising: receiving identification of one or more specific search results from one or more of the search queries that identifies the one or more specific search results as being relevant to the multiple search queries.
125. The method of claim 121 further comprising: receiving identification of one or more specific search results from one or more of the search queries that identifies the one or more specific search results as being irrelevant to the multiple search queries.
126. The method of claim 125 further comprising: re-sorting search results for presentation to the user, wherein the resorting weights search results differently in response to the received identification of the one or more specific results.
127. The method of claim 121 further comprising: providing a display of terms of the multiple search queries to the user.
128. The method of claim 121 further comprising: storing the multiple search queries; temporarily halting the continuous search state.
129. The method of claim 128 further comprising: providing a list of previously saved continuous state searches.
130. The method of claim 129 further comprising: receiving selection of one of the listed continuous state searches by the user; and resuming the selected continuous state search.
131. A method of conducting search operations, the method being performed by browser-executable code on a user's computing system, the method comprising: receiving first input from the user to initiate a continuous search state; receiving second input, in succession, from the user to define multiple search queries during the continuous search state; displaying search results to the user in succession for the multiple search queries, wherein at some of the displayed sets of search results for respective search queries are filtered to exclude search results previously presented to the user in response to other search queries during the continuous search state.
132. The method of claim 131 further comprising: receiving third input from the user to exclude one or more results for exclusion from results of subsequent search queries.
133. The method of claim 131 further comprising: receiving third input from the user to identify one or more search results for storage, the identified one or more search results being excluded from search results of subsequent search queries.
134. The method of claim 131 further comprising: receiving identification of one or more specific search results from one or more of the search queries that identifies the one or more specific search results as being relevant to the multiple search queries.
135. The method of claim 131 further comprising: receiving identification of one or more specific search results from one or more of the search queries that identifies the one or more specific search results as being irrelevant to the multiple search queries.
136. The method of claim 135 further comprising: display re-sorted search results to the user in response to the receiving identification of one or more specific search results.
137. The method of claim 131 further comprising: displaying of search terms of the multiple search queries to the user.
138. The method of claim 131 further comprising: communicating a message to temporarily halt the continuous search state.
139. The method of claim 138 further comprising: displaying a list of previously saved continuous state searches.
140. The method of claim 139 further comprising: receiving selection of one of the listed continuous state searches by the user; and communicating a message to resume the selected continuous state search.
141. A method for operating a social network application, comprising: capturing an image or video using a wireless device by a user of the social network application; communicating the image or video from the wireless device of the user to a social network application server; storing the image or video by the social network application server; identifying a user account by the social network application server in response to communication of the image or video; and modifying data, by the social network application server, associated with the account of the user to automatically post the image or video to a web page of the user to make the image or video available for viewing by other users of the social network application.
142. The method of claim 141 wherein the user enters a text description to accompany the image or video and the social network server posts the text description along with the image or video to a web page of the user.
143. The method of claim 142 further comprising: communicating ads to one or more users using keyword analysis of a text description associated with an image or video communicated to or from the user.
144. The method of claim 141 further comprising: in response to receiving communication of the image or video from the wireless device of the user, communicating the image or video to wireless devices of other users of the social network application.
145. The method of claim 144 wherein the other users of the social network application are selected friends of the user within the social network application.
146. A method for operating a location based service (LBS) in conjunction with a social network application, comprising: receiving digital images or videos from users of the social network application from wireless devices of the users of the social network application; storing the digital images or videos in accounts associated with respective users of the social network application; receiving location information indicative of a current location of respective users of the social network application; comparing the received location information to location information associated with the stored digital images or video to select digital images or video for communication to respective users of the social network application; and delivering selected images or videos to wireless devices of respective users of the social network application.
147. The method of claim 146 further comprising: receiving, from a given user of the social network application, identification of friends of the given user within the social network application in conjunction with receiving one or more digital images or videos from the given user; and immediately communicating one or more corresponding digital images or videos to wireless devices of the identified friends of the given user of the social network application.
148. The method of claim 146 further comprising: selecting ads for users of the social network application from an ad database using the metadata associated with respective digital images or videos communicating by the users.
149. The method of claim 148 wherein the selecting ads comprises: performing keyword matching of text descriptions supplied by the users to perform the selecting.
150. A system for operating a social network application, comprising: first software code executed on one or more wireless devices of users of the social network application, the first software code on each wireless device being operable to communicate image or video from the respective wireless device of the user to a social network application server; second software code executed on one or more servers, the second software code being operable to: (i) store image or video from wireless devices of users of the social network application; (ii) identify user accounts in response to communication of images or videos; and (iii) modify data associated with the accounts of users of the social network application to automatically post the images or videos to web pages of the users of the social network application to make the images or videos available for viewing by other users of the social network application.
151. The system of claim 150 wherein text descriptions accompany the images or videos and the second software code posts the text description along with the images or videos to web pages of the users.
152. The system of claim 150 wherein the second software code is further operable to communicate ads to one or more users using keyword analysis of text descriptions associated with images or videos communicated to or from the users.
153. The system of claim 150 wherein the second software code is operable to: in response to receiving communication of an image or video from the wireless device of a respective user, communicate the image or video to wireless devices of other users of the social network application.
154. The system of claim 153 wherein the other users of the social network application are selected friends of the user within the social network application.
155. A method of facilitating substantially real-time communication between users of a social network application, comprising: receiving messages from wireless devices of selected users of the social network application for communication to wireless devices of other uses of the social network application, each received message comprising image or video data and text data; receiving location information indicative of the current location of wireless devices of users of the social network application; analyzing text data in the messages to estimate or predict current activities or future activities of users of the social network application; selecting ads for communication to users of the social network application using at least the location information and the estimated or predicted activities; and communicating the received messages to the wireless devices of the other users along with the selected ads.
156. The method of claim 155 further comprising: detecting references to specific products or product types in the text data, wherein the selecting ads occurs in relation to detection of the specific products or product types.
157. The method of claim 155 further comprising: correlating text data to specific merchants or merchant types, wherein the selecting ads occurs in relations to correlation to the specific merchants or merchant types.
158. The method of claim 155 wherein the estimated or predicted activities are selected from a plurality of activities that are defined hierarchical arrangement.
159. A method of providing a location based service (LBS), comprising: receiving information pertaining to financial transactions completed by a plurality of subscribers; processing the information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of typical amounts of time between purchases of one or more specific types; receiving location information from wireless devices of the plurality of subscribers; processing recent transaction information for at least some of the subscribers to track multiple purchases of each subscriber at respective merchants or merchant types; comparing the processed recent transaction information for the plurality of subscribers against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining amounts of time since recent purchases for specific types against the norm data of the subscribers, the selection of ads further occurring in relation to the received location information; and communicating selected ads to wireless devices of the subscribers.
160. The method of claim 159 further comprising: processing the information to identify one or more days having a higher probability of a respective subscribers completing a purchase of a specific type.
161. The method of claim 159 further comprising: processing the information to identify a typical transaction amount by a respective subscriber for a purchase of a specific type.
162. The method of claim 159 wherein the norm data stores data indicative of an amount of time between purchases at a specific merchant or merchant type.
163. The method of claim 159 wherein the norm data stores data indicative of an amount of time between purchases of a specific product or product type.
164. A method of providing a location based service (LBS), comprising: monitoring one or more financial accounts of a plurality of subscribers; detecting deposits into the one or more financial accounts; identifying information pertaining to financial transactions completed by a plurality of subscribers; processing the identified information over a period of time, by one or more software programs, to generate norm data for the plurality of subscribers, the norm data including data indicative of deviations in purchasing behavior relative to variations in the detected deposits; receiving location information from wireless devices of the plurality of subscribers; processing recent deposit information for at least some of the subscribers to quantify recent deposits against typical deposit amounts; comparing the processed deposit information against the norm data to select ads for communication to subscribers, wherein the comparing differentiates in selection of ads for communication to subscribers by determining whether recent deposits are greater or lesser than typical deposit amounts as reflected in the norm data of the subscribers, the selection of ads further occurring in relation to the received location information; and communicating selected ads to wireless devices of the subscribers.
165. The method of claim 164 wherein the processing the identified information comprises: determining changes in probabilities of purchases of one or more specific types in relation to deviations in variations in deposit amounts.
166. The method of claim 164 wherein the processing the identified information comprises: determining changes in average transaction amounts for purchases of one or more specific types in relation to deviations in variations in deposit amounts.
167. The method of claim 164 wherein the processing the identified information comprises: detecting changes in merchant types for purchases in relation to deviations in variations in deposit amounts.
168. A method of processing a financial transaction using an account, wherein the account is managed in conjunction with multiple budget categories set by an account holder of the account, wherein a respective budget limit is set for each of multiple budget categories, the method comprising: receiving transaction information from a merchant that requests funds for a transaction by a card holder associated with the account; identifying a budget category from a plurality of budget categories for the transaction in response to receiving the transaction information; retrieving or determining a current amount of available funds for the identified budget category; comparing a transaction amount from the transaction information against the current amount of available funds; and communicating a transaction approval or denial depending upon at least the comparing; wherein the method is completed in real-time during processing of a payment within a payment system.
169. The method of claim 168 wherein the identifying a budget category occurs by, at least, examining a merchant identification information in the transaction information.
170. The method of claim 168 wherein the identifying a budget category occurs by, at least, examining a time of day associated with the transaction.
171. The method of claim 168 wherein the identifying a budget category occurs by, at least, retrieving category information provided by the card holder when the card holder activates the budget category for one or more transactions.
172. The method of claim 168 wherein the card holder and the account holder are different individuals.
173. The method of claim 172 wherein further comprising: managing the budget limits associated with the multiple budget categories by the account holder.
174. The method of claim 173 wherein the account holder manages the budget limits from a cellular phone of the account holder.
175. The method of claim 173 further comprising: receiving authorization from the account holder permitting the card holder to exceed a budget limit for a budget category for one or more transactions.
176. The method of claim 175 wherein the account holder communicates the authorization from a cellular device of the account holder.
177. The method of claim 172 further comprising: communicating information to a cellular device of the account holder that details amounts applied against said multiple budget categories.
178. The method of claim 172 wherein the communicating information occurs substantially when transactions are processed.
179. The method of claim 177 further comprising: communicating information to a cellular device of the card holder that details amounts applied against said multiple budget categories.
180. The method of claim 177 wherein the communicating information to a cellular device communicates the information in a SMS formatted message.
181. The method of claim 168 further comprising: when sufficient currently available funds are not available within the identified budget category, determining whether sufficient currently available funds are present in another budget category; wherein the transaction is approved if the second budget category contains sufficient currently available funds.
182. The method of claim 181 wherein the determining sufficient currently available funds determines whether the sum of the currently available funds for the identified budget category and the other budget category are greater than or equal to the transaction amount.
183. The method of claim 168 further comprising: debiting the transaction amount from the amount of currently available funds for the identified budget category upon communication of a transaction approval.
184. The method of claim 168 wherein budget limits define respective maximum amounts of funds that may be spent over one or more budget periods.
185. The method of claim 184 wherein different budget periods are defined for different budget categories of the multiple budget categories.
186. The method of claim 168 wherein the account is a credit card account or a debit card account.
187. The method of claim 186 wherein the account is a stored value account.
188. The method of claim 168 further comprising: examining products or services being purchased in the transaction to identified the budget category.
189. A system for completing a financial transaction using an account, wherein the account is managed in conjunction with multiple budget categories set by an account holder of the account, wherein a respective budget limit is set for each of multiple budget categories, the system comprising: a point-of-sale system for obtaining or receiving account information from a financial card of cardholder, the point-of-sale system communicating transaction information for payment of a transaction; at least one payment server for processing payment transactions from point of sale systems, wherein the at least one payment server being operable to: (i) receive transaction information that requests funds for a transaction, the transaction information comprising financial account information and transaction amount information; (ii) identify a budget category for the transaction in response to receiving the transaction information; (iii) retrieve or determine a current amount of available funds for the identified budget limit of the account; (iv) compare a transaction amount from the transaction information against the current amount of available funds; and (v) communicate a transaction approval or denial depending upon at least the comparing.
190. The system of claim 189 wherein the code for identifying a budget category examines a merchant identification information in the transaction information.
191. The system of claim 189 wherein the code for identifying a budget category retrieves category information provided by the card holder when the card holder activates the budget category for one or more transactions.
192. The system of claim 189 wherein the card holder and the account holder are different individuals.
193. The system of claim 189 wherein further comprising: code for managing the budget limits associated with the multiple budget categories by the account holder.
194. The system of claim 193 wherein the account holder manages the budget limits from a cellular phone of the account holder.
195. The system of claim 193 further comprising: code for receiving authorization from the account holder permitting the card holder to exceed a budget limit for a budget category for one or more transactions.
196. The system of claim 195 wherein the account holder communicates the authorization from a cellular device of the account holder.
197. The system of claim 192 further comprising: code for communicating information to a cellular device of the account holder that details amounts applied against said multiple budget categories.
198. The system of claim 192 wherein the communicating information occurs substantially when transactions are processed.
199. The system of claim 192 further comprising: code for communicating information to a cellular device of the card holder that details amounts applied against said multiple budget categories.
200. The system of claim 199 wherein the code for communicating information to a cellular device communicates the information in a SMS formatted message.
201. The system of claim 189 further comprising: code for determining whether sufficient currently available funds are present in another budget category, when sufficient currently available funds are not available within the identified budget category; wherein the transaction is approved if the second budget category contains sufficient currently available funds.
202. A method for facilitating communication between users of a social network application, comprising: capturing data indicative of user purchases, selection, or approval of products or services; receiving identification of other users having relationship with respective users within the social network application for communication of the captured data; communicating the captured data to the identified users; selecting ads based upon the captured data for communication to the other users; and communicating the selected ads to the other users.
203. The method of claim 202 wherein the selected ads are communicated concurrently with communication of the captured data.
204. The method of claim 202 wherein the captured data identified specific products.
205. The method of claim 202 wherein the captured data identifies specific manufacturers.
206. The method of claim 202 wherein the captured data identifies specific vendors.
207. The method of claim 202 wherein the communicating the captured data comprises communicating digital images of goods identified by the users.
208. The method of claim 207 wherein the digital images are previously uploaded or posted to user pages of the social network application.
PCT/US2007/083987 2005-11-14 2007-11-07 Location based service for directing ads to subscribers WO2008082794A2 (en)

Priority Applications (12)

Application Number Priority Date Filing Date Title
US12/967,040 US8260725B2 (en) 2005-11-14 2010-12-13 Method of conducting operations for a social network application including notification list generation with offer hyperlinks according to notification rules
US13/560,969 US20120289208A1 (en) 2005-11-14 2012-07-27 Method of conducting operations for a social network application including activity list generation
US13/560,971 US20120289209A1 (en) 2005-11-14 2012-07-27 Method of conducting operations for a social network application including activity list generation
US13/586,839 US8571999B2 (en) 2005-11-14 2012-08-15 Method of conducting operations for a social network application including activity list generation
US13/943,751 US9129304B2 (en) 2005-11-14 2013-07-16 Method of conducting social network application operations
US13/943,748 US9147201B2 (en) 2005-11-14 2013-07-16 Method of conducting social network application operations
US13/943,742 US9129303B2 (en) 2005-11-14 2013-07-16 Method of conducting social network application operations
US13/969,561 US20140108540A1 (en) 2005-11-14 2013-08-17 Method of conducting social network application operations
US13/969,560 US20140108539A1 (en) 2005-11-14 2013-08-17 Method of conducting social network application operations
US14/846,982 US10064004B2 (en) 2005-11-14 2015-09-07 Methods of conducting social network operations
US16/114,170 US11070935B2 (en) 2005-11-14 2018-08-27 Devices for conducting social network operations
US17/305,513 US20220070609A1 (en) 2005-11-14 2021-07-08 Devices for conducting social network operations

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US86480706P 2006-11-08 2006-11-08
US60/864,807 2006-11-08
US11/559,438 2006-11-14
US11/559,438 US20070112741A1 (en) 2005-11-14 2006-11-14 Search engine providing persistent search functionality over multiple search queries and method for operating the same
US62383207A 2007-01-17 2007-01-17
US11/623,832 2007-01-17
US91763807P 2007-05-11 2007-05-11
US60/917,638 2007-05-11

Related Parent Applications (5)

Application Number Title Priority Date Filing Date
US11/559,438 Continuation-In-Part US20070112741A1 (en) 2005-11-14 2006-11-14 Search engine providing persistent search functionality over multiple search queries and method for operating the same
US11/623,837 Continuation-In-Part US20080168630A1 (en) 2007-01-17 2007-01-17 Decorative patch jewelry retainer
US62383207A Continuation-In-Part 2005-11-14 2007-01-17
US12/767,785 Continuation-In-Part US20100324994A1 (en) 2005-11-14 2010-04-26 Location based service for directing ads to subscribers
US12/967,040 Continuation-In-Part US8260725B2 (en) 2005-11-14 2010-12-13 Method of conducting operations for a social network application including notification list generation with offer hyperlinks according to notification rules

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/463,168 Continuation US20100285818A1 (en) 2005-11-14 2009-05-08 Location based service for directing ads to subscribers

Publications (2)

Publication Number Publication Date
WO2008082794A2 true WO2008082794A2 (en) 2008-07-10
WO2008082794A3 WO2008082794A3 (en) 2008-11-13

Family

ID=39589165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/083987 WO2008082794A2 (en) 2005-11-14 2007-11-07 Location based service for directing ads to subscribers

Country Status (1)

Country Link
WO (1) WO2008082794A2 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011114294A1 (en) * 2010-03-16 2011-09-22 Nokia Corporation Method and apparatus providing for output of a content package based at least in part on a content category selection and one or more contextual characteristics
EP2395718A1 (en) * 2010-04-23 2011-12-14 Research In Motion Limited Method and apparatus for electronically posting a graphic identifier to a plurality of servers
CN103425381A (en) * 2012-05-15 2013-12-04 腾讯科技(深圳)有限公司 User interaction method and server
WO2014074513A1 (en) * 2012-11-06 2014-05-15 Intertrust Technologies Corporation Activity recognition systems and methods
US8880624B2 (en) 2010-04-23 2014-11-04 Blackberry Limited Method and apparatus for receiving data from a plurality of feed sources
US8910083B2 (en) 2009-11-10 2014-12-09 Blackberry Limited Multi-source picture viewer for portable electronic device
WO2015106275A1 (en) * 2014-01-13 2015-07-16 Cisco Technology, Inc. Location aware captive guest portal
US9154605B2 (en) 2010-04-23 2015-10-06 Blackberry Limited Method and apparatus for posting data to a plurality of accounts
CN109377213A (en) * 2018-08-27 2019-02-22 平安科技(深圳)有限公司 Self-service card Activiation method, device, computer equipment and storage medium
US10984447B2 (en) 2009-05-01 2021-04-20 Ryan Hardin Exclusive delivery of content within geographic areas

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106776857B (en) * 2016-11-28 2020-11-13 北京金山安全软件有限公司 Method and device for acquiring weather data and electronic equipment

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6542749B2 (en) * 2000-06-10 2003-04-01 Telcontar Method and system for connecting proximately located mobile users based on compatible attributes
US20040193538A1 (en) * 2003-03-31 2004-09-30 Raines Walter L. Receipt processing system and method
US20040266457A1 (en) * 1997-08-20 2004-12-30 Dupray Dennis J. Wireless location gateway and applications therefor
US20060074726A1 (en) * 2004-09-15 2006-04-06 Contextware, Inc. Software system for managing information in context
US7085818B2 (en) * 2001-09-27 2006-08-01 International Business Machines Corporation Method, system, and program for providing information on proximate events based on current location and user availability
US20060217131A1 (en) * 2004-10-29 2006-09-28 Skyhook Wireless, Inc. Location-based services that choose location algorithms based on number of detected access points within range of user device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040266457A1 (en) * 1997-08-20 2004-12-30 Dupray Dennis J. Wireless location gateway and applications therefor
US6542749B2 (en) * 2000-06-10 2003-04-01 Telcontar Method and system for connecting proximately located mobile users based on compatible attributes
US7085818B2 (en) * 2001-09-27 2006-08-01 International Business Machines Corporation Method, system, and program for providing information on proximate events based on current location and user availability
US20040193538A1 (en) * 2003-03-31 2004-09-30 Raines Walter L. Receipt processing system and method
US20060074726A1 (en) * 2004-09-15 2006-04-06 Contextware, Inc. Software system for managing information in context
US20060217131A1 (en) * 2004-10-29 2006-09-28 Skyhook Wireless, Inc. Location-based services that choose location algorithms based on number of detected access points within range of user device

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10984447B2 (en) 2009-05-01 2021-04-20 Ryan Hardin Exclusive delivery of content within geographic areas
US11948171B2 (en) 2009-05-01 2024-04-02 Ryan Hardin Exclusive delivery of content within geographic areas
US8910083B2 (en) 2009-11-10 2014-12-09 Blackberry Limited Multi-source picture viewer for portable electronic device
US8380810B2 (en) 2010-03-16 2013-02-19 Nokia Corporation Method and apparatus providing for output of a content package based at least in part on a content category selection and one or more contextual characteristics
WO2011114294A1 (en) * 2010-03-16 2011-09-22 Nokia Corporation Method and apparatus providing for output of a content package based at least in part on a content category selection and one or more contextual characteristics
EP2395718A1 (en) * 2010-04-23 2011-12-14 Research In Motion Limited Method and apparatus for electronically posting a graphic identifier to a plurality of servers
US8880624B2 (en) 2010-04-23 2014-11-04 Blackberry Limited Method and apparatus for receiving data from a plurality of feed sources
US9154605B2 (en) 2010-04-23 2015-10-06 Blackberry Limited Method and apparatus for posting data to a plurality of accounts
CN103425381A (en) * 2012-05-15 2013-12-04 腾讯科技(深圳)有限公司 User interaction method and server
WO2014074513A1 (en) * 2012-11-06 2014-05-15 Intertrust Technologies Corporation Activity recognition systems and methods
US9736652B2 (en) 2012-11-06 2017-08-15 Intertrust Technologies Corporation Activity recognition systems and methods
US10003927B2 (en) 2012-11-06 2018-06-19 Intertrust Technologies Corporation Activity recognition systems and methods
US10200822B2 (en) 2012-11-06 2019-02-05 Intertrust Technologies Corporation Activity recognition systems and methods
US9414416B2 (en) 2014-01-13 2016-08-09 Cisco Technology, Inc. Location aware captive guest portal
WO2015106275A1 (en) * 2014-01-13 2015-07-16 Cisco Technology, Inc. Location aware captive guest portal
CN109377213A (en) * 2018-08-27 2019-02-22 平安科技(深圳)有限公司 Self-service card Activiation method, device, computer equipment and storage medium
CN109377213B (en) * 2018-08-27 2024-01-26 平安科技(深圳)有限公司 Self-service card activation method and device, computer equipment and storage medium

Also Published As

Publication number Publication date
WO2008082794A3 (en) 2008-11-13

Similar Documents

Publication Publication Date Title
US20220070609A1 (en) Devices for conducting social network operations
US8260725B2 (en) Method of conducting operations for a social network application including notification list generation with offer hyperlinks according to notification rules
US11741490B2 (en) Verification of redemption of an electronic offer
US20210019786A1 (en) System for providing a service to venues where people perform transactions
US20100285818A1 (en) Location based service for directing ads to subscribers
WO2008082794A2 (en) Location based service for directing ads to subscribers
KR101854797B1 (en) Providing relevant notifications for a user based on location and social information
KR101831777B1 (en) Pricing relevant notifications provided to a user based on location and social information
US8983858B2 (en) Lifestyle application for consumers
KR101430799B1 (en) Conditional incentive presentation, tracking and redemption
US20040122730A1 (en) Electronic messaging system and method thereof
US20030009385A1 (en) Electronic messaging system and method thereof
US20140372214A1 (en) Targeted marketing to on-hold customer
US20100324994A1 (en) Location based service for directing ads to subscribers
US20100093333A1 (en) Systems and Methods for Providing Wireless Targeted Advertising
US20130173492A1 (en) Collection and distribution of after purchase experience data
US20140279034A1 (en) Products, systems, and methods for creating and interacting with a mobile community
US20210224851A1 (en) Affiliate-driven benefits matching system and methods with location-triggered benefit alert and search score determination
WO2014032039A1 (en) Systems for mobile devices
US20120289209A1 (en) Method of conducting operations for a social network application including activity list generation
US20120289208A1 (en) Method of conducting operations for a social network application including activity list generation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07868691

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07868691

Country of ref document: EP

Kind code of ref document: A2