This disclosure relates in general to releasing ticket inventory information to subscribers and, more particularly, but not by way of limitation, to integrating ticket inventory information with social media.
Online ticket purchase web sites are widely used and increasing in popularity. In the world of online ticket purchase, it is not uncommon that tickets are sold out within a certain time after they are being released. Often, ticket brokers like to constantly reserve large block of tickets with good seats to prevent other people from purchasing them, and then resell tickets on a secondary market with unreasonable price or as an denial of service attempt for online sales while they focus on in-person purchases. Therefore, good seats are unavailable on the primary market or require real ticket buyers to revisit and refresh website periodically. It can be time-intensive and frustrating to the most loyal fans who have to resort to the secondary market to purchase from brokers and scalpers. The ticket purchase websites often face with a dilemma, either try to post fewer amount of tickets online and lose revenue, or post all the tickets online and let them fall into ticket brokers' hands.
A hybrid ticket messaging system is used to release ticket inventory information to subscribers and, more particularly, to integrate ticket inventory information with a third party site. Relevant interests are determined for the user based on a subscription message. Ticket availability is determined according to the relevant interests. An availability message is sent to the user reflecting the availability of the tickets using the third party site. The availability message is sent prior to release of the tickets to other users.
In one embodiment, systems and/or methods for notifying users of ticket inventory in a selective manner are disclosed. In one step, a subscription message is received from a user that was originally posted using a third party site. Relevant interests of the user are determined from the message. Availability of tickets that correlate to the relevant interests is determined. An availability message is sent to the user reflecting the availability of the tickets using the third party site. The availability message is sent prior to release of the tickets to other users.
In another embodiment, a method for determining relevant interests of the user from the message is disclosed. In one step, a plurality of hash tags of the relevant interests is determined based on the subscription message. The plurality of hash tags is mapped into one or more ticket categories. A confirmatory message is sent to the user. The one or more ticket categories of the user is stored for giving future notice of the availability prior to release of the tickets to other users.
Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the disclosure.
The present disclosure is described in conjunction with the appended figures:
A further understanding of the nature and advantages of various embodiments may be realized by reference to the following figures.
The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.
Referring first to
In the rubric of Twitter™, hash tags are used to identify the interest in categories of tickets. Additionally, the end user 116 could provide a geo hash tag code to indicate their location of interest for tickets. Some embodiments could determine location from the third party messaging service 108, cellular telephone or tablet or installed app on the phone or tablet. Other third party messaging services 108 could use different rubrics to relay interest and location. There could be different Twitter™ handles with this functionality where the handle is the normal channel that an artist, producer, label, venue, sport, event, and/or other channel would use to distribute tweets on other subjects. Additionally, a keyword or hash tag could optionally be used in the tweets or private messages to the end users 116 assigned to a category to differentiate the ticket availability tweet from other tweets that originate from the handle. In this way, the social network becomes the conduit for ticket message subscription and distribution without any specific functionality of the social network being needed.
Subscription messages are relayed from the third party messaging service 108 to the ticket management system 104. The one or more hash tags in the subscription message are mapped to one or more categories. Some embodiments may not need identification of specific tags in the subscription message instead relying on the content of the subscription message itself to determine the category of tickets that likely interest to the end user 116. Some embodiments may use a third-party database (for example, a GOOGLE™ search) or TicketMaster™ web or TicketMaster™ mobile app to search one or more ticket categories. Fuzzy logic, artificial intelligence, machine learning, support vector machine (SVM) and/or other techniques alone or in combination can be used to map the subscription messages to ticket categories. In some embodiments, mapping for a new subscription message may be performed by matching the keywords, symbols and/or other mapping metrics to a set of mapping training data for each ticket category. An example of such a mapping metrics is described in further detail below in connection with
The ticket tweet or private message includes a notice and location for ordering the tickets. A link can also be provided in the ticket tweet to a web site or mobile app that when activated with bring the end user 116 to an interface for ordering the tickets. The link could be unique to a single end user 116 or group of end users 116 so that only that person or group could order from a set aside block of tickets, at least for some time period. The link could be to a web site for those that subscribed using the web version of Twitter™ or could be to the TicketMaster™ mobile app for those that subscribed using a mobile phone version of Twitter™. Additional credentials, coupon codes, username and/or password, or any other secret or semi-secret identifiers. The link preference could also be stated in the original subscription message rather than inferred. Updates to a particular subscription could be made with a replacement subscribe request after an unsubscribe message is sent to the handle. In some embodiments, a different subscribe request is presumed to replace an earlier request without requiring express unsubscription with a message.
The ticket availability tweets and/or direct/private messaging form a sub-channel in the end users 116 normal Twitter™ feed that would include other tweets associated with the handle, if any. For example, an artistic user 112 could have a handle of @AAA_Band, that the end user 116 subscribes to. A direct message to @AAA_Band saying, SUBSCRIBE #Denver #RedRocks would result in tweets with ticket availability for any show featuring the AAA Band at the Venue of Red Rocks Amphitheater in Denver. The ticket management system 104 can release ticket inventory in a staged way prior to general availability to the fans for a particular Twitter™ handle first or early in a staged roll-out of availability. Each user mapped to a ticket category would be given notice of the availability prior to a broader audience and/or the general public. There may be a fee (e.g. one-time fee, per-opportunity or monthly subscription fee) associated with a particular Twitter handle for it to release ticket inventory prior to general availability. Where an end user 116 follows the link to purchase tickets and indeed does complete the purchase, the end user 116 could optionally be unsubscribed automatically. In some embodiments, there may be a coupon or discount code listed together with the link for purchasing tickets, at least for some time period. In some embodiments, one availability message may expire after a predetermined time period (e.g. one hour) after releasing to one or more subscribers. If no purchase is detected, the same availability message may be released to other subscribers or to the general public using the same or a different coupon or discount code.
In the sole table, example hash tags and their corresponding ticket category are shown. The hash tag could be as specific as event serial number #90234875 for a particular show or as general as #LA for all shows in the Los Angeles area relevant to the handle the subscription message was sent to. For example, a message of “SUBSCRIBE #LA” to the @LV_Symphony handle would result in ticket availability messages for the Las Vegas Symphony when they traveled to Los Angeles. A plain English confirmation private or direct message saying the same could be sent to the end user 116 saying that and providing instructions for deleting the subscription if wrong.
In some embodiments, a message with one zip code of #92037 would result in ticket availability message with a group of zip codes (for example, any locations with zip code from 92000 to 93000) in order to list the nearby events for all associated zip codes. Number of desired tickets and a price range could also be specified in the hash tags. For example, a message of “SUBSCRIBE #LA Jazz No3” to the @LA_Symphony handle would result in ticket availability messages for the Los Angeles Symphony to be released when the number of available tickets is more than three.
The present invention is not limited to any particular code or symbol. In one embodiment, a pop-up filter window in the TicketMaster™ web, TicketMaster™ mobile app or third party messaging service 108 may be presented to the end user 116 in order to enter criteria, such as zip code, date of the event, time of the event, minimum ticket quantity, ticket price range, date by when message is to be sent, etc. for one or more subscriptions. A ticket inventory message would be sent when all or at least some criteria are met, which would result in releasing more valuable or directed message to the user in one embodiment. Targeting may result in more ticket purchases with a focused availability message in one embodiment. The end user 116 may adjust the criteria at any time. In some embodiments, based on request history from one or more end users 116, assumption would be made for the next mapping results based on some predetermined criteria and/or metrics. The message can be in the form of direct message via social media, text message from a cell phone, email message, etc. In some cases, the user will have an opportunity to repost the private/direct message to the public or through their social graph on the third party messaging service 108 where allowed or applicable.
In some embodiments, the ticket inventory management system may be configured to generate more than one categories of tickets for an event. Different subscriptions (for example, “SUBSCRIBE #POP” or “SUBSCRIBE #MADONNA” to the @LA_Concert handle) may result in the same event of “Madonna tour in Los Angeles” being offered to the subscriber, for example. Multiple configurations of subscription message or mapping of tickets into categories may be generated such that a rigid syntax is not required. Different categorizing of tickets may be released or made available to different message subscribers or end users 116. The preferences of a user, their purchase history, and other information that may be received from the user or the user's account may be used to generate a category specifically tailored to the user. For example, a subscriber might be mapped to their purchase history with the TicketMaster™ web or TicketMaster™ mobile app or other distribution channels, or even mapped to demographic information or identified/deidentified personal information. A fan who buys cheap seats may be offered select cheap seats through the ticket message, and another fan who has a very high income could be offered front row or in a hospitality suite.
In some embodiments, different users may have vastly different preferences and hence many different ticket categories may be generated. For example, one specific user may have strong preference for choosing events based on price range (any live concert in Las Vegas under $100). The available tickets may be grouped into categories based largely on price. In another example, one specific user may have strong preference for choosing events based on show time (for example, any Friday night shows in Las Vegas). The available tickets may be grouped into categories based largely on show times. In some cases, users may have strong preference for choosing an event based on the best sound quality seats (for example, 2013 Madonna tour in Las Vegas). The tickets with the best sound quality seats may be grouped into category with one price range; tickets with a lower sound quality seats may be grouped to another category with lower price range.
In addition to generating categories of tickets based on specific user preferences of histories, different mapping metrics may be generated for different Twitter™ handles based on their user's demographics, purchase histories, and the like. For example, Twitter™ handles such as fan followers for artists or events, attract a younger demographic than a physical ticket broker. Based on the demographics data, the tickets may be mapped into categories based on different metrics for real ticket buyer and ticket brokers. In some embodiments, user preferences and user purchase history may be used to calculate or change characteristics such as when a ticket purchased by the user, how it influences a metric, and/or how it influences the price for the rest of available tickets. The profile characteristics of user may be periodically analyzed to determine trends and/or profile changes to affect the customized offering to that user or a group of users.
Referring next to
The tag match module 208 takes the keywords, hash tags or other content in the subscription message and matches that to event and artist information 216, 220 to determine ticket categories for each end user 116. The hash tags could relate to a band, event, venue, artist, writer, actor, geography, etc. The subscription message could also specify dates of interest, genres, language, dislikes, show times, target demographic of fan, etc. Additionally, the subscription message could indicate price or class of ticket, seating format (open seating, table seating, reserved seating, etc), seating preferences (front row, balcony, club level, etc.), time of day, etc. for the ticket category of interest.
In other embodiments, the interface 236 can be used to configure ticket tweets and other availability messaging. The interface 236 could allow modification of existing subscriptions, entering of new subscriptions, and deleting unwanted subscription. The interface 236 could be accessed using the web or mobile app. In some embodiments, the interface 236 could allow management of subscriptions for end users 116. For example, subscriptions may be grouped by artist, team, location, etc. The end user 116 would have a chance to change, cancel and/or delete the subscription for each ticket categories. The users associated with social media (for example, FACEBOOK™) may share the availability message within their friend group. Other embodiments could lock down the availability message with a unique code or credential authentication such that it cannot be easily shared.
With reference to
One or more metric information stores hold tags or ticket categories that might appear in a request or otherwise map to a request. For example metric information 310, user account information 329, user purchase history 324, event information 317, ticket categories 322, location information 312, artist information 321, event information 317, etc. all store information about users and tickets that are mapped to tags. Request query strings 320 are mapped to those tags such that words or word strings along with context and/or rules can be used to determine the relevant tags for a given query. User purchase history 324 includes user ticket request history and ticket purchase history. For example, purchasing front row seats for several events will result in a tag for #frontrow being assigned to the user.
In some embodiments, the data ranges of the metric information stores that are used to map the subscription into specific tags that may also be changed at any time, for different events, venues, and the like. For example, for one specific event, such a Super Bowl game, the angle of view of the stadium may be an important characteristic that reflects the value of the ticket and has a particular tag. For another type of events, such as a concert, the sound quality at each seat may be the most important characteristic that has a unique tag. Using different metric-based analysis for a user and ticket, tag matching is done by the tag match module.
Further, the tools may allow an inventory manager or event provider to change the metric information 310 based on new subscription or past sale performance to affect the tag mapping. The number of sections or price levels may be dynamically adjusted during the onsale period for an event. Adjustments may be made to increase revenues, increase sales, meet a sellout date, and the like. In some embodiments, ticket inventory message release schedule may also be used to adjust or change the mapping metrics. The release schedule may be timed or designed to increase the demand for the tickets, increase revenue, and/or increase sales rate compared to an all at once release of tickets.
In some embodiments, a confirmation message with the ticket categories could be sent as a direct message tweet to the end user 116. The confirmation message may provide different action options with instructions to the end user 116. For example, the end user 116 would have a chance to confirm, change, cancel and/or delete the subscription for each ticket category. When tickets become available, the end users for the corresponding tag are notified from the third party messaging service 108 through a ticket tweet in this embodiment.
To support many different third party messaging services 108, tags can be mapped to query strings, hashtags, interface elements, etc. The third party translation store 313 maps tags to the interface or strings for a particular third party messaging service 108 or context. For example, a tag of Front_Row could be mapped to #frontrow hashtag for Twitter™. In another example, an interface pulldown in a ticket ordering app could select Zone A for a venue, that would be mapped to a tag called Top_Tier for the tag match module 208.
With reference to
The confirmatory direct message is in plain English, but may have incorrect presumptions determined from the hash tags by the tag match module 208. Where there are imperfections or other confusion perceived, the end user 116 can modify the subscription by additional direct messages to the handle in block 416. Blocks 408, 412 and 416 can be repeated until the ticket category or tag is correct. In some embodiments, the mapping results may be associated with a probability factor or a percentage of closeness between the original subscription message and possible ticket categories for a certain artist and/or event. In block 420, direct messages show up in the Twitter™ feed for the end user 116 as ticket tweets or direct messages according to the subscription.
In some embodiments, the number of available tickets in the availability message may vary depending on how close the event is or how low the inventory is. For example, availability message may specify less ticket quantity available two weeks away from the event. In most cases, ticket broker would need some extra time prior to the event to post tickets online and resell them. By increasing the number of available tickets one week or 2 days away from the event, ticket availability message would benefit real fans or ticket buyers and attract fewer ticket brokers in one embodiment.
Referring next to
Each end user 116 receives their respective tweet in block 520. The tweets can be customized per end user 116 in some embodiments or the same for a group of end users 116. An end user can take a code from the tweet, click on the link or just log into the ticket management system 104 to authenticate their access to the prerelease of tickets and interact with the interface 236. In some embodiments, the code from the tweet may be unique to each subscriber, and may expire after a predetermined time period. The user may optionally have additional user authentication in block 528 to access their account through the web or phone app. Any tickets are purchased in block 532. Optionally, the end user 116 can be unsubscribed automatically from more ticket tweets for the event once tickets are purchased or an option can be presented in the checkout process to stop further message tweets.
With reference to
A number of variations and modifications of the disclosed embodiments can also be used. For example, any third party messaging service 108 capable of messaging could be used instead of Twitter™. The messaging functionality in user forums, bulletin boards, listservs, commentary functions, and Facebook™ and other social network sites. For example, a user could friend a musician on Facebook™ before sending a direct message with hash tags or keywords that would subscribe the user to return messages relevant to ticket purchases for the user.
Some embodiments could periodically send predetermined messages through the public message channel that are determined by the ticket management system 104. For example, a message could be: “All our subscribed fans have received their customized ticket invitations,” “Justin174fan in San Diego just bought four front row seats,” “LivyLuLu2 just bought the thousandth ticket,” or “The LA show is 50% sold out with fan club purchases.” Any workflow of staged ticket releases and messages is possible for preprogramming.
Referring to
In some embodiments, fuzzy logic, artificial intelligence, machine learning, support vector machine (SVM) and/or other techniques alone or in combination can be used to map the subscription messages to ticket categories or tags by the tag matching module 208. In some embodiments, a mapping training data for each ticket category may be built based on subscription history for one or more users. Mapping for new subscription message may be performed by matching the keywords, and/or other mapping metric to the mapping training data for each ticket category.
The interface 236 may generate alerts or notification prompting the inventory management by reviewing the ticket inventory and ticket grouping when certain thresholds have been met. For example, the inventory manager may be alerted to a drop in inventory below a specific threshold and may prompt the manager to reassess the grouping and/or hash tags assigned to ticket categories. Messaging to the subscribers or general public using the handle or channel can be specified according or in the future if rules and/or thresholds are met.
In some embodiments, metrics such as location, genres, price, seating preferences, dates of interest, and show times may be specified by user either within the subscription message or within a pop-up window. Other metric may be a score, numerical value, rating, and the like that reflects a measure of the event's desirability (e.g., its value or rating with respect to a desirability characteristic, such as nearness to an event, good seats with clear view of the event, etc.). Various search strings, criteria and metrics will be added to the request query strings 320 and/or to other mapping training functionality.
Referring to
Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
Implementation of the techniques, blocks, steps and means described above may be done in various ways. For example, these techniques, blocks, steps and means may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.
Also, it is noted that the embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a swim diagram, a data flow diagram, a structure diagram, or a block diagram. Although a depiction may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed, but could have additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
Furthermore, embodiments may be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and/or any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine readable medium such as a storage medium. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
For a firmware and/or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described herein. For example, software codes may be stored in a memory. Memory may be implemented within the processor or external to the processor. As used herein the term “memory” refers to any type of long term, short term, volatile, nonvolatile, or other storage medium and is not to be limited to any particular type of memory or number of memories, or type of media upon which memory is stored.
Moreover, as disclosed herein, the term “storage medium” may represent one or more memories for storing data, including read only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing information. The term “machine-readable medium” includes, but is not limited to portable or fixed storage devices, optical storage devices, and/or various other storage mediums capable of storing that contain or carry instruction(s) and/or data.
While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure.
This application claims the benefit of U.S. Provisional Application No. 61/788,091 filed on Mar. 15, 2013, which is hereby incorporated by reference in its entirety for all purposes.
Number | Date | Country | |
---|---|---|---|
61788091 | Mar 2013 | US |