WO2016035424A1 - 情報処理装置、情報処理方法及びプログラム - Google Patents

情報処理装置、情報処理方法及びプログラム Download PDF

Info

Publication number
WO2016035424A1
WO2016035424A1 PCT/JP2015/067910 JP2015067910W WO2016035424A1 WO 2016035424 A1 WO2016035424 A1 WO 2016035424A1 JP 2015067910 W JP2015067910 W JP 2015067910W WO 2016035424 A1 WO2016035424 A1 WO 2016035424A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
event
user
sales
management system
Prior art date
Application number
PCT/JP2015/067910
Other languages
English (en)
French (fr)
Inventor
則行 山本
高村　成一
正志 関野
Original Assignee
ソニー株式会社
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
Application filed by ソニー株式会社 filed Critical ソニー株式会社
Priority to US15/505,831 priority Critical patent/US10496606B2/en
Priority to JP2016546359A priority patent/JPWO2016035424A1/ja
Priority to EP15838688.8A priority patent/EP3196821A4/en
Publication of WO2016035424A1 publication Critical patent/WO2016035424A1/ja
Priority to US16/551,726 priority patent/US11379417B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164—File meta data generation
    • G06F16/166—File name conversion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0251—Targeted advertisements
    • G06Q30/0252—Targeted advertisements based on events or environment, e.g. weather or festivals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0631—Item recommendations

Definitions

  • the present disclosure relates to an information processing apparatus, an information processing method, and a program.
  • Patent Document 1 discloses a movement in which location information is received from a mobile communication terminal possessed by a user, is within a predetermined range from the place where the event is held, and the acquisition date of the location information is earlier than the execution date of the event.
  • a technique for distributing event information of the event to a communication terminal is disclosed.
  • Patent Document 2 discloses a technique for digitizing an event ticket so that a user can be smoothly guided at a venue gate.
  • an organizer for simplicity
  • the organizer Each has its own event management system and ticket sales system. Also, information such as a user's ticket purchase history is generally managed for each organizer. In the techniques described in Patent Documents 1 and 2, such a case where contents are managed by different management systems is not sufficiently considered.
  • the present disclosure proposes a new and improved information processing apparatus, information processing method, and program capable of further improving the convenience of users and content sellers.
  • a schema conversion unit that converts content meta information managed by a plurality of different management systems into a common schema, common content meta information converted into a common schema, and each management system
  • An information processing apparatus includes a recommendation unit that determines a combination of content to be recommended and a user based on the purchase history information of the content.
  • the processor converts content meta information managed by a plurality of different management systems into a common schema, common content meta information converted into a common schema,
  • An information processing method includes determining a combination of recommended content and a user based on content purchase history information in each management system.
  • a function of converting content meta information managed by a plurality of different management systems into a common schema in the computer processor, and common content meta information converted into the common schema And a function for determining a combination of recommended content and a user based on content purchase history information in each management system.
  • event meta information managed by different management systems is converted into a common schema. Accordingly, it is possible to comprehensively handle the purchase history information of contents in each management system with a common schema. Therefore, since the content purchase history information in each management system can be comprehensively used to determine the combination of the recommended content and the user, a more appropriate combination is determined and the purchase behavior by the user is further promoted. .
  • FIG. 2 is an explanatory diagram for describing an overview of a system according to a first embodiment of the present disclosure.
  • FIG. It is a block diagram which shows one structural example of the system which concerns on 1st Embodiment. It is a functional block diagram which shows an example of a function structure of the recommendation part shown in FIG. It is explanatory drawing for demonstrating the determination process of the sales strategy based on a user's action tendency information. It is a flowchart which shows an example of the process sequence of the information processing method which concerns on 1st Embodiment. It is a figure which shows one example of a display of the information input screen into which various information is input by the sponsor.
  • system refers to such a recommendation system unless otherwise specified.
  • the content handled in the first and second embodiments may be any content that can be generally purchased by a user, such as video, music, books, and household items (food, beverages, clothes, electrical appliances, etc.). .
  • an event with a limited number of seats (capacity) such as a concert, a theater, a movie, or a tour trip is preferably handled as content.
  • the sales period and the number of sales of the ticket are limited, and the sales period and the number of sales also change at any time as the holding date approaches and the remaining number of seats decreases.
  • At least one of the sales period and the number of sales is limited, and the content in which the sales period and the sales number can change at any time is also referred to as a quantitative product.
  • Other quantitative products other than those described above include, for example, coupons and products handled in flash marketing.
  • the first and second embodiments have a greater effect when recommending such quantitative products to users. Therefore, in the following description, the case where the content recommended by the system is an event handled as a quantitative product will be described as an example. In the following description, an event simply refers to an event that is handled as such a quantitative product unless otherwise specified. However, as described above, the content handled in the first and second embodiments is not limited to this example, and any content may be recommended to the user in the first and second embodiments.
  • FIG. 1 is an explanatory diagram for explaining an outline of a general system.
  • an event is managed by the organizer of the event (hereinafter also referred to as an eventor or an entertainer).
  • the event X, the event Y, and the event Z are the event management system X210 that is the event management system of the eventer X, the event management system Y220 that is the event management system of the eventer Y, and the event of the eventer Z, respectively.
  • It is managed by the event management system Z230, which is a management system.
  • the event management system X210, the event management system Y220, and the event management system Z230 are not particularly distinguished, they are also simply referred to as a management system.
  • the event management system X210, the event management system Y220, and the event management system Z230 each have a member.
  • a member (X member) of the event management system X210 is a user who has registered his / her profile information in the event management system X210, and an event ticket managed by the event management system X210 is sent via the event management system X210. It is possible to purchase.
  • a member (Y member) of the event management system Y220 and a member (Z member) of the event management system Z230 have registered their profile information in the event management system Y220 and the event management system Z230, respectively. Tickets for events managed by the management system that is a member can be purchased via each management system.
  • the management of events includes the management of event ticket sales, the management of event meta information (various meta information about events), the management of member profile information, the management of purchase history information of tickets for the member, This may include managing event recommendations and the like.
  • the event management system X210, the event management system Y220, and the event management system Z230 perform various types of management as described above for the events registered therein.
  • An event management system X210, an event management system Y220, and an event management system Z230 shown in FIG. 1 schematically illustrate a management system that comprehensively manages various events as described above.
  • the inside may be constituted by a plurality of smaller systems by a plurality of vendors.
  • the event management system X210 includes a prediction engine 217 that predicts a recommended event for its own member, and a log 218 in which purchase history information of the X member is accumulated.
  • the event management system X210 has a function of predicting, for each X member, events that the X member is likely to be interested using the prediction engine 217, and recommending the predicted event to each X member.
  • the prediction engine 217 may be a prediction engine used in a general recommendation system. For example, by referring to the log 218, the prediction engine 217 refers to the purchase trend of past events of the recommended X member, the purchase history of other X members with similar purchase trends, and the like. Events to recommend to X members can be predicted.
  • the event management system Y220 and the event management system Z230 also have prediction engines 227 and 237 and logs 228 and 238, respectively, and have a function of recommending events to their members.
  • event management system X210 the event management system Y220, and the event management system Z230 may manage the same event. Further, there is a possibility that the same user is included in the X member, the Y member, and the Z member.
  • the event management system X210, the event management system Y220, and the event management system Z230 are not linked to each other and cannot participate in events and members managed by other management systems.
  • the ticket for the event X can be purchased only by the X member via the event management system X210, the Y member via the event management system Y220, or the Z member via the event management system Z230. Event X tickets cannot be purchased.
  • the event management system X210 is based on a result predicted by the prediction engine 217 provided in the event management system X210 using the log 218 accumulated in the event management system X210.
  • the event X managed by the event management system X210 can only be recommended to X members.
  • the prediction engine 217 uses the logs 228 and 238 of other management systems for prediction processing, or the event management system X210 recommends events managed by the other management systems to X members. It is not possible.
  • the management methods of various information regarding events and members in the event management system X210, event management system Y220, and event management system Z230 are often different from each other.
  • the event management system X210 and the event management system Y220 may have different schemas for registering event meta information. Therefore, even if the event management system X210, the event management system Y220, and the event management system Z230 simply share the event meta information and the member profile information with each other, the event or member registered in each management system is the same event. It cannot be determined whether or not the user is pointing.
  • the event management system X210, the event management system Y220, and the event management system Z230 each independently manage events and members. Therefore, even if the same event or the same user is registered in different management systems, the system 4 cannot recognize this, and the accuracy of event recommendation to the user, Convenience in ticket purchase has not necessarily been optimized.
  • FIG. 2 is an explanatory diagram for describing an overview of a system according to the first embodiment of the present disclosure. Note that a more detailed configuration of the system according to the first embodiment will be described in detail later in (2-2. System Configuration).
  • the event X is managed by the event management system X210
  • the event Y is managed by the event management system Y220
  • the event Z is managed by the event management system Z230.
  • the event management system X210 has a log 218 in which purchase history information of X members is accumulated
  • the event management system Y220 has a log 228 in which purchase history information of Y members is accumulated
  • the event management system Z230 has a log 238 in which purchase history information of Z members is accumulated.
  • the event management system X210, the event management system Y220, the event management system Z230, and the logs 218, 228, and 238 have functions similar to those shown in FIG. Omitted.
  • the system 1 holds common event meta information in which event meta information of event X, event meta information of event Y, and event meta information of event Z are converted into a common schema.
  • event meta information of event X event meta information of event Y
  • event meta information of event Z event meta information of event Z are converted into a common schema.
  • the system 1 can collectively manage the events that were originally managed by each management system. It becomes. Therefore, in the system 1, it is possible to determine whether the events originally managed by different management systems are the same event.
  • member profile information managed by each management system is converted into a common schema and held as common member profile information.
  • vacant seat information managed by each management system (remaining seat of the event, that is, information indicating the ticket sales status) is converted into a common schema and held as common vacant seat information.
  • the member profile information (for example, user ID) managed by each management system is shared.
  • the user IDs in each management system are shared, the user IDs are different from each other in each management system. Therefore, in the first embodiment, the members indicated by the user IDs are the same user. I can't judge until.
  • the vacant information of each event is shared by holding the common vacant information.
  • various types of information converted into a common schema such as common event meta information, common member profile information, and common vacancy information, are also collectively referred to as common information.
  • each management system does not have its own prediction engine, but a common prediction engine 150 that can access each management system across is provided.
  • the common prediction engine 150 is configured to be able to access the event management system X210, the event management system Y220, the event management system Z230, and the logs 218, 228, and 238, as well as the common information.
  • the common prediction engine 150 has a function of determining a combination of recommended content and a user based on the common information and purchase history information in the logs 218, 228, and 238.
  • the common prediction engine 150 can handle each event managed by each management system in a batch with a common schema by accessing the common event meta information. Moreover, the common prediction engine 150 can handle each member managed by each management system in a lump in a common schema by accessing the common member profile information. In this way, the common prediction engine 150 can comprehensively handle events and members that were originally managed independently by each management system.
  • the common prediction engine 150 refers to the logs 218, 228, and 238, and identifies the same event in the purchase history information in the logs 218, 228, and 238 when determining the combination of recommended content and user. It is possible to integrate and use these purchase history information. Therefore, since the common prediction engine 150 can determine the combination of the recommended content and the user based on more purchase history information, the user's interest and interest are predicted with higher accuracy, and the user shows the interest. Event is recommended to the user more accurately.
  • the common prediction engine 150 can recommend events managed by a certain management system to members of other management systems by using the common event meta information and the common member profile information. .
  • the common prediction engine 150 can select a Y member managed by the event management system Y220 as a user who should recommend the event X managed by the event management system X210.
  • the target for recommending the event is expanded as compared with the general system 4, it is possible to urge more users to purchase the event.
  • the common event meta information can be converted again into a schema in each management system.
  • the ticket sales system in each management system can be used across the board.
  • the event management system Y220 can also manage the event X by converting the common event meta information of the event X originally managed by the event management system X into the schema of the event management system Y220 again. .
  • the Y member does not need to bother to register as a member in the event management system X210.
  • the Y member can purchase a ticket for the event X via the event management system Y220.
  • a ticket sales method having a higher degree of freedom and more convenient for the user is realized.
  • FIG. 3 is a block diagram illustrating a configuration example of the system 1 according to the first embodiment.
  • FIG. 4 is a functional block diagram illustrating an example of a functional configuration of the recommendation unit 130 illustrated in FIG.
  • the system 1 includes an information processing apparatus 10, an event management system X210, an event management system Y220, an event management system Z230, an organizer profile information DB 140, and input / output. Unit 160.
  • the event management system X210, the event management system Y220, and the event management system Z230 respectively correspond to the event management system X210, the event management system Y220, and the event management system Z230 shown in FIG.
  • the first embodiment is not limited to such an example, and the event management system Y220 can perform the same processing for members of the event management system Y220, and the event management system Z230 can also perform the event management system. A similar process can be performed for Z230 members.
  • the number of event management systems constituting the system 1 is not limited to the illustrated example, and the system 1 may be configured by an arbitrary number of event management systems.
  • the input / output unit 160 is an input / output interface between the system 1 and the event organizer.
  • the organizer can input various information to the system 1 through the input / output unit 160. Further, the system 1 can output (present) various information to the organizer via the input / output unit 160.
  • the input / output unit 160 may be a device having an information input / output function owned by the organizer, such as a PC (Personal Computer), a smartphone, or a tablet terminal.
  • the organizer inputs organizer profile information, which will be described later, via the input / output unit 160.
  • the inputted organizer profile information is stored in the organizer profile information DB 140.
  • the organizer inputs event meta information to the event management system X210 via the input / output unit 160.
  • the input event meta information is stored in an event meta information DB 212 of the event management system X210 described later.
  • An example of the event meta information input screen in the input / output unit 160 will be described in detail in the following (2-4. Display example).
  • the input / output unit 160 can present various information such as event ticket sales status, past ticket sales performance analysis data, and ticket sales strategies to the organizer.
  • the information presentation function of the input / output unit 160 can be controlled by the presentation control unit 170 of the information processing apparatus 10 to be described later.
  • the input / output unit 160 does not necessarily have to be configured by a separate device from the information processing apparatus 10, and may be provided integrally with the information processing apparatus 10.
  • the input / output unit 160 can be configured by an input device (for example, a mouse, a keyboard, a touch panel, etc.) and an output device (display, speaker, etc.) provided in the information processing apparatus 10.
  • the organizer profile information DB 140 is a database (DB) in which organizer profile information, which is information about the event organizer, is stored.
  • the organizer profile information indicates an organizer ID for identifying the organizer, an event ID, sales strategy information indicating the sales strategy of the organizer for each event, and schedules and events of performers of each event. Contains information.
  • the sales strategy information includes, for example, the presence / absence of promotion (promotion) of each event, the method of promotion, the timing of the promotion, the presence / absence and discount rate of the ticket fee, the presence / absence of benefits to the event participants Information such as It should be noted that the presence / absence and discount rate of the ticket fee may be set so as to change according to the remaining period of the ticket sales period and the remaining number of tickets. Further, as the contents of the privilege, for example, a handshake ticket, a signing ticket for the autograph session, a present of related goods, a visit to a dressing room, a right to download premium content using AR (Augmented Reality), and the like are assumed.
  • the organizer profile information is registered in the organizer profile information DB 140 for each event by the organizer.
  • the sales strategy can be determined by the recommendation unit 130 described later based on the shared event meta information and the like.
  • the organizer can create sales strategy information to be registered in the organizer profile information DB 140 by appropriately modifying the sales strategy information determined by the recommendation unit 130.
  • the information processing apparatus 10 of the system 1 may have a function of determining an event sales strategy based on common event meta information and purchase history information in each management system.
  • the sales strategy determined by the information processing apparatus 10 may be presented to the organizer via the input / output unit 160.
  • the organizer can input sales strategy information via the input / output unit 160 with reference to the presented content.
  • the function of determining the sales strategy by the information processing apparatus 10 will be described in detail later with reference to FIG.
  • the organizer profile information DB 140, the event meta information DB 212, the vacant seat information DB 213, the member profile information DB 214, the purchase history information DB 215, the common event meta information DB 121, the common vacant seat information DB 122, and the common member profile information DB 123 are described later.
  • a storage unit that stores various types of information configured by various storage devices such as a magnetic storage device such as an HDD (Hard Disk Drive), a semiconductor storage device, an optical storage device, or a magneto-optical storage device .
  • the event management system X210 includes a ticket sales system 211, an event meta information DB 212, a vacant seat information DB 213, a member profile information DB 214, a purchase history information DB 215, and a recommended event presentation unit 216 as its functions. Note that the event management system X210 may have the same configuration as various commonly used management systems.
  • the ticket sales system 211 uses the information stored in the event meta information DB 212, vacancy information DB 213, and member profile information DB 214 to manage event ticket sales and reservations.
  • a user who is a member of the event management system X210 can purchase a ticket for a desired event via the ticket sales system 211.
  • the ticket sales system 211 supports electronic ticket sales through a website or the like.
  • the ticket sales system 211 displays a ticket sales screen or website on a terminal placed at a store such as a ticket sales store or a convenience store, or a terminal such as a PC or smartphone of each user, thereby selling tickets.
  • a store such as a ticket sales store or a convenience store
  • a terminal such as a PC or smartphone of each user
  • the ticket sales system 211 Based on the event meta information stored in the event meta information DB 212, the ticket sales system 211 presents to the user the event name, the date and time of the event, the venue, the fee, and the like. At that time, the ticket sales system 211 refers to the vacant seat information stored in the vacant seat information DB 213 and informs the user of the remaining number of tickets and the vacant seat position in the venue if the seat can be designated. It can also be presented together.
  • the ticket sales system 211 refers to the member profile information stored in the member profile information DB 214, and is associated with the user (in the example shown in FIG. 3, the X member of the event management system X210). Sell tickets.
  • the user who purchased the ticket can be managed by the user ID.
  • the ticket sales system 211 sequentially updates information in the event meta information DB 212, the vacant seat information DB 213, the member profile information DB 214, and the purchase history information DB 215 in accordance with the ticket sales status and the like.
  • the purchase history information DB 215 event meta information of an event for which a ticket is purchased and a user ID for purchasing the ticket are stored in association with each other.
  • ticket sales system 211 various known systems that are generally used may be applied.
  • the event meta information DB 212 stores various meta information about events handled by the ticket sales system 211.
  • the event meta information includes information such as the name of the event, the event ID for identifying the event, the date and time of the event, the venue, the content of the event, the performer, and the fee.
  • the event meta information may include information such as the event start information release start date / time, ticket reservation start / end date / time, ticket sales start / end date / time, and the like.
  • the event meta information may include various types of information that can be generally used as information related to an event in the ticket sales system.
  • the event meta information in the event meta information DB 212 is registered in the event management system X210 via the input / output unit 160 for each event by the event organizer.
  • the event meta information includes information on the progress and performance of each event such as a time table, the appearance order of performers, scheduled appearance time, set list, lighting and movement of the set as information on the contents of the event.
  • the event meta information includes the venue type, size, seat arrangement, seat type (S seat, A seat, standing seat, non-smoking seat, smoking seat, etc.) It includes information such as seat spacing, seat specifications (eg, shape, size, material, etc.), surrounding environment (eg, entrance / exit, passage, position of air conditioning equipment).
  • venue information includes, for example, the facilities and settings of each event venue such as the area where the event will be held (event area), set, musical instrument, lecture stand, moderator, lighting, audio equipment, equipment location and specifications, etc. Contains information about.
  • the venue information includes information on the change of the setting when the setting of the venue changes in time series, for example.
  • the event meta information is the virtual seat of the user.
  • various kinds of information necessary for distributing the event such as the relationship between the appearance of the event area in the video to be distributed.
  • the event meta information includes, for example, information about the performers, such as physical characteristics of the performers of the event (for example, height, body shape, etc.), movement and performance characteristics, performers' costumes, and the like.
  • performers include persons and animals that are the targets of the event.
  • performers include sports players and circus animals.
  • event information is created for each event, Retained.
  • venue information is created and held for each venue.
  • the vacant seat information DB 213 stores vacant seat information about vacant seats of events handled by the ticket sales system 211.
  • the vacant seat information includes a venue ID representing a venue, a seat ID representing a seat at the venue, information on the position of the seat represented by the seat ID in the venue, and the like.
  • the vacant seat information is generated by the ticket sales system 211 based on the event meta information, and the content is updated according to the ticket sales status. It can be said that the vacant seat information is information indicating the sales situation of the ticket.
  • the vacant seat information may include various types of information that can be generally used as information representing a vacant seat at an event in a ticket sales system.
  • the member profile information DB 214 stores member profile information about members registered in the ticket sales system 211.
  • the member profile information includes a user ID representing a user, information about the user's gender, age, nationality, address, occupation, credit card number, and the like.
  • the member profile information includes the user's physical characteristics such as height, sitting height, body shape, visual acuity, and whether or not a wheelchair is used.
  • the member profile information includes, for example, preference information related to user preferences.
  • the preference information includes the user's favorite artist, favorite group member, favorite team, favorite player, favorite event type, favorite genre, favorite or favorite instrument, favorite stage set, etc.
  • Preference information for events including performers.
  • the preference information includes preference information for the user's venue and seat such as a favorite venue, a favorite seat position, an angle for viewing a favorite event area, a favorite seat type, a favorite seat specification, and the like.
  • the member profile information includes, for example, behavior tendency information related to behavior trends when the user purchases a ticket.
  • the user's behavior tendency is, for example, a strong tendency to buy a ticket immediately after ticket sales start (pre-purchase group), or a strong tendency to buy a ticket immediately before the event date (pre-purchase group), etc. This is a behavior tendency of a user when purchasing a ticket.
  • the user behavior tendency will be described in detail later with reference to FIG.
  • preference information and behavior tendency information can be obtained, for example, by analyzing purchase history information.
  • the analysis process may be performed by the ticket sales system 211 or may be performed by another configuration (for example, a recommendation unit 130 of the information processing apparatus 10 described later).
  • the member profile information includes, for example, viewing feature information indicating the viewing features of the user's event.
  • View feature information includes, for example, making noise, singing, dancing, intense movement, laughing, crying, clapping hands, watching quietly, sitting and watching, standing, sleeping, cheering, raising a strange voice, skipping a goat , Tweet, talk with the surroundings, cosplay, use cheering goods, poor pants, drink alcohol, often take a seat, join late, return on the way, etc.
  • the viewing characteristic information may include not only the user's actual characteristics but also the user's wishes such as wanting to make a noise, singing, or dancing. Further, considering that the user's view of the event is different for each event type and performer, each user's view characteristic information may be separately provided for each event type and performer.
  • the viewing feature information can be created based on, for example, questionnaire responses from each user, or can be created based on video, image, and audio analysis results near each user's seat during the event. It is.
  • information on the user's viewpoint characteristics may be extracted and reflected in the viewpoint characteristic information. Is possible.
  • the member profile information can include various types of information that can be generally used as information about members in the ticket sales system.
  • the purchase history information DB 215 stores purchase history information for each member registered in the ticket sales system 211.
  • the purchase history information DB 215 includes, as purchase history information, a user ID, the number of purchases, a venue of the purchased event, a seat type and a seat position, an event type (for example, a movie, a play, a concert, a sport, etc.), an event Are stored in association with each other.
  • the purchase history information is information indicating purchase patterns of each user such as repeatedly purchasing tickets of the same type of event (for example, concerts of the same artist, etc.), purchasing tickets of a wide range of genres, and rarely purchasing tickets. May be included.
  • the purchase history information may include information about an event recommended to the user and a user's action for the event (whether or not a ticket for the event has been purchased). Further, the purchase history information may include information on the purchase time of the ticket within the sales period. In addition to ticket purchase, for example, a history such as each user viewing information related to an event or adding a bookmark or the like to consider ticket purchase may be included in the purchase history information.
  • the purchase history information DB 215 may store various types of information that can generally be stored as member purchase history information in a ticket sales system. Good.
  • the recommended event presentation unit 216 presents an event to be recommended to a user (a member of the event management system X in the example shown in FIG. 3) determined by the recommendation unit 130 of the information processing apparatus 10 to be described later. To advertise the event to the user. For example, the recommended event presentation unit 216 displays an event advertisement on the ticket sales screen of the ticket sales system 211 as a recommended event for the user. In addition, for example, the recommended event presentation unit 216 distributes information about the event to the user as an event recommended to the user by e-mail or the like.
  • the recommended event presentation unit 216 includes various processors such as a CPU (Central Processing Unit) and a DSP (Digital Signal Processor), and the function of the recommended event presentation unit 216 operates according to a predetermined program. Can be realized.
  • the information processing apparatus 10 functions as a schema conversion unit 110, a common event meta information DB 121, a common vacancy information DB 122, a common member profile information DB 123, a recommendation unit 130, a presentation control unit 170, Have
  • the schema conversion unit 110, the recommendation unit 130, and the presentation control unit 170 are configured by various processors such as a CPU and a DSP, for example, and the functions of the schema conversion unit 110, the recommendation unit 130, and the presentation control unit 170 are performed by the processor. It can be realized by operating according to a predetermined program.
  • the presentation control unit 170 controls the presentation of information in the input / output unit 160 that is an interface through which the organizer inputs and outputs various types of information to the system 1.
  • the presentation control unit 170 presents the information to the organizer by causing the input / output unit 160 to display various types of information.
  • the presentation control unit 170 presents information about the event sales strategy determined by the recommendation unit 130 to the organizer via the input / output unit 160.
  • the presentation control unit 170 presents various information desired by the organizer to the organizer via the input / output unit 160, such as event ticket sales status, analysis data of past ticket sales results, and the like. May be.
  • the schema conversion unit 110 converts information stored in the event meta information DB 212, the vacant seat information DB 213, and the member profile information DB 214 into a common schema. Specifically, the schema conversion unit 110 converts information stored in the event meta information DB 212, the vacant seat information DB 213, and the member profile information DB 214 so that they can be managed by a common ID system. As described above (1. General system), generally, the schema of information to be managed is different if the management system for managing the event is different. In the first embodiment, information managed by different management systems is converted into a common schema by the schema conversion unit 110, so that the information can be managed collectively. is there.
  • the event meta information in the event meta information DB 212 converted by the schema conversion unit 110 is stored in the common event meta information DB 121 as common event meta information.
  • the vacant seat information in the vacant seat information DB 213 converted by the schema conversion unit 110 is stored in the common vacant seat information DB 122 as the common vacant seat information.
  • the member profile information in the member profile information DB 214 subjected to schema conversion by the schema conversion unit 110 is stored in the common member profile information DB 123 as common member profile information.
  • the common event meta information DB 121 stores event meta information (common event meta information) converted into a common schema.
  • the common event meta information includes the name of the event, the performer of the event, the genre of the event, the venue where the event is held, the date and time related to the event (the date and time of the event, the date and time when the event information is released, the start and end date and time of the reservation, Ticket sales start and end date, etc.), ticket price (ticket price, admission fee, etc.), event contents (summary text, event introduction images or videos, reviews of performers and events, and detailed event information) Part or all of information about items such as Web site URL).
  • common IDs common performer ID, common genre ID, common venue ID
  • Other information is also managed in a common format.
  • event meta information originally registered in different management systems in different management systems is stored in a common schema.
  • the common vacancy information DB 122 stores vacancy information (common vacancy information) converted into a common schema.
  • the common vacant seat information includes event vacant seat information (for example, information on the seat classification, seat number, price, etc. of the remaining seats).
  • the common member profile information DB 123 stores member profile information (common member profile information) converted into a common schema.
  • the common member profile information includes, for example, information about the user ID. Thereby, the user ID managed by each management system is shared. However, even if the user IDs in each management system are shared, the user IDs are different from each other in each management system. Therefore, in the first embodiment, whether the members indicated by the user IDs are the same user. I can't judge until. Further, the common member profile information may include the above-described preference information, trend information, and viewing feature information.
  • the recommendation unit 130 determines a combination of recommended content and user based on the common event meta information and purchase history information in each management system. In other words, the recommendation unit 130 selects a user to recommend an event or selects an event to recommend to a user based on the common event meta information and purchase history information in each management system. To do.
  • the recommendation unit 130 has a function corresponding to the common prediction engine 150 shown in FIG.
  • the recommendation unit 130 comprehensively uses the purchase history information of each management system by associating the purchase history information in the purchase history information DB 215 of each management system with the common event meta information. A prediction model for selecting a combination of recommended event and user is generated. And the recommendation part 130 determines the combination of the event and user to recommend based on the produced
  • the recommendation unit 130 transmits information on the combination of the determined event and the user to the recommended event presentation unit of the management system in which the determined user is registered as a member.
  • the determined user is a member of the event management system X210, and information on the determined event and user combination is transmitted to the recommended event presentation unit 216 of the event management system X210. Is illustrated.
  • the recommended event presentation unit 216 presents the selected event to the selected user. For example, the recommended event presentation unit 216 displays the selected event in the recommendation column or the advertisement column of the ticket purchase screen (for example, the ticket purchase screen when the user is logged in) associated with the selected user. Display the information.
  • the combination of the event and the user determined by the recommendation unit 130 is expressed by, for example, common event meta information and a common user ID. Therefore, when information about a combination of an event and a user is transmitted from the recommendation unit 130 to the recommendation event presentation unit 216, the information is a management system to be presented via the schema conversion unit 110. (In the example shown in FIG. 3, the event management system X210 is converted into a schema). As a result, the recommended event presentation unit 216 of the event management system X210 can handle the event meta information and the user ID with the original schema of the event management system X210.
  • the event presented to the members of the event management system X210 does not necessarily have to be an event managed by the event management system X210.
  • event meta information is collectively managed as common event meta information, whereby an event managed by one management system is sent to members of other management systems. It is also possible to present it.
  • the recommendation unit 130 may further have a function of determining an event sales strategy based on the shared event meta information and purchase history information in each management system. Information about the determined sales strategy is provided to the presentation control unit 170, and is presented to the organizer by the presentation control unit 170 via the input / output unit 160.
  • the recommendation unit 130 functions as an organizer profile information acquisition unit 131, a common information acquisition unit 132, a purchase history information acquisition unit 133, a prediction model generation unit 134, an event-user. It has a determination unit 135 and a sales strategy determination unit 136.
  • the organizer profile information DB 140, the common information DB 120, the purchase history information DB 215, the schema conversion unit 110, and the presentation control unit 170 are combined to exchange information with the recommendation unit 130. It is shown.
  • the common information DB 120 is illustrated as one block including the common event meta information DB 121, the common vacant seat information DB 122, and the common member profile information DB 123 shown in FIG. It is a thing.
  • the organizer profile information acquisition unit 131 acquires organizer profile information from the organizer profile information DB 140.
  • the organizer profile information acquisition unit 131 provides the acquired organizer profile information to the prediction model generation unit 134, the event-user determination unit 135, and the sales strategy determination unit 136.
  • the common information acquisition unit 132 acquires common information from the common information DB 120.
  • the common information acquisition unit 132 provides the acquired common information to the prediction model generation unit 134, the event-user determination unit 135, and the sales strategy determination unit 136.
  • the purchase history information acquisition unit 133 acquires purchase history information from the purchase history information DB 215.
  • the purchase history information acquisition unit 133 provides the acquired purchase history information to the prediction model generation unit 134, the event-user determination unit 135, and the sales strategy determination unit 136.
  • 4 shows only one purchase history information DB 215 (for example, the purchase history information DB 215 of the event management system X210 shown in FIG. 3), the purchase history information acquisition unit 133 includes the event management system Y220 and the event management system.
  • purchase history information is acquired from the purchase history information DB 215 of the system Z230.
  • the sales strategy determination unit 136 determines an event sales strategy based on the common event meta information and purchase history information in each management system.
  • the sales strategy determined by the sales strategy determination unit 136 may include various items mentioned when the organizer profile information DB 140 is described above.
  • the sales strategy determination unit 136 preferably determines an advertising strategy (advertising strategy) according to the ticket sales period and the number of sales.
  • the advertising strategy includes, for example, the amount of advertising of an event according to the sales period and the number of sales, the time of advertising of the event according to the sales period and the number of sales, the attributes of the user who advertises the event according to the sales period and the number of sales , Information on the cost effectiveness of advertising the event according to the sales period and the number of sales. For events that are quantitative products, the sales period and number of tickets are limited, so by setting a detailed advertising strategy according to the sales period and the number of sales, more accurate advertising can be achieved. Is possible.
  • the sales strategy deciding unit 136 advertises as described above based on the information on the event type included in the common event meta information, the information on the past ticket sales results included in the purchase history information, and the like.
  • Strategy can be determined. For example, many music-related events have a single or a small number of performances, and many tickets are sold out in advance. Therefore, for music events, it is preferable that more advertisements are made at a time close to the ticket release date.
  • theater events are often held repeatedly within a predetermined period, and tickets are often left just before the event. For this reason, it is preferable that a large number of advertisements are performed for theatrical events at both the time close to the ticket release date and the time close to the event date.
  • the time of advertisement or the like can be determined in consideration of the tendency.
  • the sales strategy determination unit 136 advertises to more users at a time close to the ticket release start date and time, and becomes more interested in the event as the ticket release end date approaches.
  • the advertising strategy may be determined so as to promote to a user who is inferred. Because it is considered effective to pinpoint advertisements to users who are more likely to purchase tickets in order to minimize unsold tickets as much as possible near the end of ticket sales It is.
  • the sales strategy determination unit 136 may be based on the remaining period of the ticket sales period, the remaining number of tickets, the number of users estimated to be interested in the event, the degree of interest, and the like.
  • the probability of purchasing a ticket may be calculated by performing an advertisement, and the cost-effectiveness of the advertisement may be calculated. By showing cost effectiveness to the organizer, it can be a guideline when the organizer decides when to advertise and the amount of advertisement.
  • the sales strategy determination unit 136 may determine the advertising strategy based further on the user behavior tendency information included in the shared member profile information.
  • FIG. 5 is an explanatory diagram for explaining sales strategy determination processing based on user behavior tendency information.
  • time is plotted on the horizontal axis, and the probability of the user purchasing a ticket is plotted on the vertical axis, and the temporal change in the purchase probability of the user is schematically illustrated.
  • the purchase probability distribution as shown in FIG. 5 represents the ticket purchase results of the user as a histogram, and based on the histogram, an appropriate probability distribution according to the nature of the histogram such as a Gaussian distribution is estimated. Obtainable.
  • FIG. 5A illustrates an example of the purchase probability distribution of the user 1 of the advance purchase group.
  • the user 1 has a high probability of purchasing a ticket immediately after the ticket sales start date and time. Therefore, there is a high possibility that the user 1 is checking information on an event of interest before the ticket is released. Therefore, the sales strategy determination unit 136 suitably determines a sales strategy for the user 1 so as to advertise the event before the start of ticket sales.
  • FIG. 5B illustrates an example of the purchase probability distribution of the user 2 of the last purchase group.
  • the user 2 has a high probability of purchasing a ticket immediately before the event date. Therefore, even if the event is advertised to the user 2 before the ticket is released, the effect is considered to be small. Therefore, the sales strategy determination unit 136 suitably determines a sales strategy for the user 2 such that the event is advertised after a while from the ticket release start date.
  • the sales strategy determination unit 136 provides the presentation control unit 170 with information on the determined sales strategy.
  • Information about the sales strategy is presented to the organizer by the presentation control unit 170.
  • the organizer can determine the final sales strategy with reference to the presented information, and can input it to the organizer profile information DB 140 as the organizer profile information.
  • the presentation control unit 170 may cause the input / output unit 160 to display a setting screen that allows the organizer to more easily and more intuitively correct the sales strategy determined by the sales strategy determination unit 136. .
  • the sales strategy determination unit 136 may determine a plurality of sales strategies, and the plurality of sales strategies may be presented to the organizer by the presentation control unit 170. In this case, the organizer can select a sales strategy most suited to his / her intention from among the presented sales strategy candidates.
  • the prediction model generation unit 134 generates a prediction model for selecting a combination of a recommended event and a user based on the common event meta information and purchase history information. Specifically, the prediction model generation unit 134 associates purchase history information in the purchase history information DB 215 of each management system with the common event meta information. By the association process, purchase history information in a plurality of different management systems can be collectively handled in association with the common event meta information.
  • the recommendation unit 130 generates a prediction model for selecting a combination of an event to recommend and a user based on purchase history information associated with the common event meta information. Since the prediction model is generated by comprehensively using purchase history information in a plurality of different management systems, the prediction model is more predictive than the prediction model generated using the purchase history information of one management system. It can be said that the accuracy of is excellent.
  • the prediction model various known prediction models may be used.
  • the prediction model may be a collaborative filter model.
  • the collaborative filter model using the purchase history information of other users with similar preferences, an event that the target user seems to be interested in is predicted.
  • a feature amount representing the degree of cooperation can be calculated using the common event meta information associated with the purchase history information.
  • a technique using vector matching may be applied.
  • the common event meta information included in the purchase history information of the user is vectorized, and the frequency is overlapped for each feature amount.
  • the user vector which shows the object of a user's interest can be produced
  • vector matching is performed between the vector indicating the characteristic amount of the event obtained from the common event meta information of a certain event and the user vector obtained from the purchase history information of the user, and the distance is cosine. Calculated by distance, Euclidean distance, etc. It can be said that the user who is closer to the distance is a user who is interested in the event.
  • the prediction model generation unit 134 may generate a prediction model further based on behavior tendency information, preference information, and viewing feature information included in the common member profile information. This makes it possible to generate a prediction model that reflects the user's tendency.
  • generation part 134 may produce
  • the sales strategy information may be determined by the sales strategy determination unit 136 and corrected by the organizer. This makes it possible to generate a prediction model that reflects the organizer's intention to sell tickets while taking into account the types of events and past sales results. If there is no explicit sales strategy instruction from the organizer, the prediction model generation unit 134 may generate a prediction model based on the sales strategy determined by the sales strategy determination unit 136.
  • the prediction model generation unit 134 may generate a prediction model by combining the behavior tendency information and the sales strategy information. For example, for a user who is a pre-purchase group as shown in FIG. 5A, purchasing a ticket for the event by recommending an event that is about to sell many tickets immediately after the start of sale as a sales strategy. It is thought that it can promote more. Therefore, the prediction model generation unit 134 preferably uses a prediction model that recommends an event for which a sales strategy for selling many tickets at a time close to the ticket sales start date is recommended for the user. Can be generated. On the other hand, by recommending an event that sells a large number of tickets immediately before the event as a sales strategy to a user who is a previous purchase group as shown in FIG. It is thought that the purchase can be promoted more. Therefore, the prediction model generation unit 134 preferably generates a prediction model that recommends an event in which a sales strategy for selling many tickets immediately before the date of the event is set for the user. Can do.
  • the prediction model generation unit 134 provides the generated prediction model to the event-user determination unit 135.
  • the event-user determining unit 135 determines a combination of recommended event and user using the prediction model. Specifically, the event-user determining unit 135 performs matching between the event and the user using the prediction model, and selects a user who seems to be interested in the event to be recommended (or vice versa). , Select an event that the user you ’re recommending might be interested in). Since the common event meta information and the common member profile information are acquired as the common information, the event-user determination unit 135 comprehensively crosses the events and members managed by each event management system. It is possible to match an event with a user.
  • the event-user determining unit 135 may perform matching between the event and the user in consideration of the seat based on the common vacant seat information. For example, when the seat that the user likes is known based on the purchase history information or the preference information included in the shared member profile information, the event-user determination unit 135 uses the prediction model and the user likes it. An event in which a seat close to the seat where the user sits is empty may be selected as an event to be recommended to the user.
  • the event-user determining unit 135 selects an event suitable for the user based on other preference information included in the shared member profile information, viewing characteristic information, information indicating the physical characteristics of the user, and the like. You can also.
  • the event-user determining unit 135 may target only a member of a management system with a predetermined organizer ID based on an organizer ID (that is, an ID representing the management system) included in the organizer profile information. .
  • an organizer ID that is, an ID representing the management system
  • the setting may be performed by the organizer when registering the organizer profile information.
  • the event-user determination unit 135 provides the schema conversion unit 110 with information on the determined event and user combination.
  • a combination of an event and a user determined by the event-user determining unit 135 is expressed by, for example, common event meta information and a common user ID.
  • the schema conversion unit 110 uses the common event meta information of the event and the common user ID representing the user as an object of presentation. Convert back to the management system schema.
  • the event management system to be presented is a management system in which the determined user is registered as a member. By performing schema conversion again, events and users can be handled by the schema of each event management system.
  • the recommended event presenting unit 216 shown in FIG. 3 can present the advertisement of the selected event to the selected user.
  • Each event management system can also sell a ticket for an event presented to the user in accordance with the user's operation.
  • the event-user determining unit 135 can select a member of another management system as a user who recommends an event managed in a certain management system.
  • a user who is a member of the event management system X210 can be selected as a user who recommends the event Y managed by the event management system Y220.
  • the event meta information of the event Y is converted into the common event meta information and then reconverted into a schema that can be managed by the event management system X210.
  • the event Y can be handled by the event management system X210.
  • event meta information and member profile information are made common and can be comprehensively managed by the information processing apparatus 10, thereby matching such a user and an event between different management systems. Is possible.
  • an event managed by one management system is stored in a DB of another management system by schema conversion, so that the ticket for the event is sold by the other management system. It is also possible.
  • a user who is a member of the event management system X210 who recommended the event Y that was originally managed by the event management system Y220 via the event management system X210 uses the event management system X210.
  • the ticket for the event Y can be purchased through the user. At this time, the user can watch the advertisement of the event and purchase the ticket without being aware of the event being managed by a different event management system.
  • event meta information managed by a plurality of different management systems is converted into a common schema, so that the event meta information is comprehensively handled. It becomes possible. Therefore, the purchase history information of the plurality of management systems can be handled comprehensively, and the accuracy of the prediction engine can be improved. Therefore, the matching between the recommended event and the user is performed more appropriately. Further, by sharing the event meta information, the purchase of the event meta information is further promoted, and the convenience of the organizer who is the ticket seller is improved.
  • event meta information can be mutually used between management systems. Accordingly, since the user who is the target of the event recommendation matching is expanded to all management system members, the ticket purchase layer is expanded and the ticket purchase is further promoted.
  • event meta information can be used mutually between management systems, event tickets can be sold in any management system. Convenience is improved.
  • the apparatus configuration of the information processing apparatus 10 is not limited to the examples illustrated in FIGS. 3 and 4.
  • the functions of the information processing apparatus 10 illustrated in FIGS. 3 and 4 do not necessarily have to be integrally mounted on one apparatus.
  • Each function installed in the information processing apparatus 10 shown in FIG. 3 and FIG. 4 is distributed and installed in a plurality of apparatuses, and the plurality of apparatuses are communicably connected to form the information processing apparatus 10. May be.
  • each DB may be provided as an external device different from the information processing apparatus 10, and the information processing apparatus 10 executes the various processes described above while communicating with these DBs that are external devices. Also good.
  • a computer program for realizing the functions of the information processing apparatus 10 according to the first embodiment as described above, and to implement it on a personal computer or the like.
  • a computer-readable recording medium storing such a computer program can be provided.
  • the recording medium is, for example, a magnetic disk, an optical disk, a magneto-optical disk, a flash memory, or the like.
  • the above computer program may be distributed via a network, for example, without using a recording medium.
  • FIG. 6 is a flowchart illustrating an example of a processing procedure of the information processing method according to the first embodiment.
  • the information processing method is exemplified by a case where the event S managed by the event management system X210 is recommended to the user (member of the event management system X210). Will be described.
  • step S101 event meta information and organizer profile information of event S are registered by the organizer (step S101). Specifically, in the process shown in step S101, event meta information and organizer profile information of event S are stored in the event meta information DB 212 and the organizer profile information DB 140 via the input / output unit 160, respectively.
  • step S103 the event meta information and vacancy information of the event S and the member profile information of the event management system X210 are converted into a common schema. Specifically, in the process shown in step S103, information stored in the event meta information DB 212, the vacant seat information DB 213, and the member profile information DB 214 of the event management system X210 is converted into a common schema, and shared information (that is, , Common event meta information, common vacancy information, and common member profile information) are generated. Similarly, event meta information, vacant seat information, and member profile information of other management systems are also converted into a common schema.
  • the process shown in step S103 corresponds to, for example, the process performed by the schema conversion unit 110 shown in FIG.
  • a sales strategy is determined based on the common event meta information and purchase history information (step S104).
  • the sales strategy can be determined based on, for example, the type of event, the past sales record of the same type of event, or the like. Although illustration is omitted, the determined sales strategy is presented to the organizer, and the final sales strategy is determined by the organizer.
  • the process shown in step S104 corresponds to the process performed by, for example, the sales strategy determination unit 136 shown in FIG.
  • a prediction model is generated based on the common event meta information and purchase history information (step S105).
  • the prediction model is a model for predicting a user who should recommend the event S in consideration of, for example, the type of event and the purchase history of the user.
  • the process shown in step S105 corresponds to, for example, the process performed by the prediction model generation unit 134 shown in FIG.
  • step S107 a user that matches the event S is selected based on the generated prediction model.
  • the process shown in step S107 corresponds to the process performed by, for example, the event-user determining unit 135 shown in FIG.
  • step S109 information about the event S and the selected user is transmitted to the event management system X210 in which the user is registered.
  • the transmitted information is converted into a schema corresponding to the event management system X210 of the transmission destination.
  • the schema conversion process shown in step S107 can be executed by, for example, the schema conversion unit 110 shown in FIG.
  • step S111 the event S is presented to the selected user (step S111).
  • the process shown in step S111 corresponds to, for example, the process performed by the recommended event presentation unit 216 shown in FIG.
  • event S information may be displayed as a recommended event on a ticket purchase screen displayed to the user, or event S information may be displayed in an advertisement area in the ticket purchase screen.
  • step S113 the vacant seat information of the event S in the vacant seat information DB 213 and the purchase history information in the purchase history information DB 215 are updated (step S113).
  • step S113 not only when the user purchases a ticket of the event S by looking at the advertisement of the event S presented in the process shown in step S111, purchase actions of other users are also included.
  • the vacant seat information in the vacant seat information DB 213 and the purchase history information in the purchase history information DB 215 can be reflected.
  • the offline purchase record is a purchase record that cannot be directly detected by the system 1, such as a ticket purchase record at a venue window.
  • the process shown in step S115 is performed by, for example, an organizer who can grasp the ticket sales offline.
  • step S113 and the process shown in step S115 are shown in this order. However, these processes are executed at any time in the system 1, and thus the order. May be arbitrary.
  • step S115 When the process shown in step S115 is completed, the process returns to step S103, and the processes in and after step S103 are repeatedly executed based on the updated vacant seat information and purchase history information.
  • the change of the profile information, the change of the event meta information accompanying the change of the event content, etc. can be performed at any time.
  • such change of the organizer profile information, event meta information, and member profile information may be appropriately executed. In that case, processing shown in each step may be executed based on the changed information.
  • the prediction model generation process shown in step S105 may not be performed every time the series of processes shown in FIG. 6 is executed.
  • the process shown in step S105 may be performed to update the prediction model once a week or at a timing when a certain amount of purchase history information is updated.
  • the organizer can input event meta information, organizer profile information, and the like via the input / output unit 160.
  • the convenience of the organizer can be improved by providing such an input / output interface capable of collectively inputting information necessary for the system 1.
  • FIG. 7 is a diagram illustrating a display example of an information input screen on which various types of information are input by the organizer.
  • the display screen 310 shown in FIG. 7 corresponds to the display screen of the input / output unit 160 shown in FIG. 3, for example.
  • the organizer can input various information to the system 1 via the display screen 310.
  • the display screen 310 illustrated in FIG. 7 is merely an example of an information input screen provided to the organizer, and the information input screen may have other configurations.
  • a display screen 310 mainly includes an area 311 where event information is registered, an area 312 where information about a ticket sales site is mainly registered, and information about event advertisements presented to the user. It is divided into areas 313 to be registered.
  • information such as an event name (title), an event performer (artist), an event venue, and an event date and time can be input in a drop-down list format.
  • event meta information for example, in the event meta information DB 212 of the event management system X210 shown in FIG.
  • the information input format is not limited to the drop-down list format, and various types of information may be directly input as text.
  • various information related to the event may be input in addition to the items exemplified.
  • Information about the ticket sales start date and time, the sales end date and time, the sales region, and the number of sales is registered as event meta information in, for example, the event meta information DB 212 of the event management system X210 shown in FIG.
  • information on ticket sales strategies is registered as organizer profile information in, for example, the organizer profile information DB 140 shown in FIG.
  • various information that can be set for each sales site may be input in addition to the items exemplified.
  • information on the sales strategy determined by the sales strategy determination unit 136 shown in FIG. 4 may be displayed.
  • the organizer can input sales strategy information with reference to the displayed information.
  • a GUI Graphic User Interface
  • a GUI capable of correcting the sales strategy determined by the displayed sales strategy determination unit 136 may be provided.
  • an advertisement layout and an authority to change the layout when an event is presented to the user can be input.
  • various information related to the advertisement of the event may be input in addition to the items exemplified.
  • the system 1 according to the first embodiment is provided with the common prediction engine 150, and an event recommended to the user in each management system is represented by the common prediction.
  • the engine 150 was determined.
  • the system 1 which concerns on 1st Embodiment is not limited to this example, You may take another structure.
  • the prediction engine of each management system may behave as the common prediction engine 150.
  • FIG. 8 is a diagram illustrating an overview of a system according to a modified example in which a prediction engine is provided in each management system.
  • the system according to the present modification corresponds to the system 1 according to the first embodiment in which the configuration of the prediction engine is changed, and the configurations and functions of other members are the same as those of the system 1. . Therefore, in the following description of the present modification, detailed description of items that are the same as those of the system 1 according to the first embodiment will be omitted, and differences from the system 1 will be mainly described.
  • the event X is managed by the event management system X210
  • the event Y is managed by the event management system Y220
  • the event Z is managed by the event management system Z230.
  • the event management system X210 includes a prediction engine 267 that predicts a recommended event for the X member who is the member, and a log 218 in which purchase history information of the X member is accumulated.
  • the event management system Y220 includes a prediction engine 277 that predicts a recommended event for the Y member who is the member, and a log 228 in which purchase history information of the Y member is accumulated.
  • the event management system Z230 includes a prediction engine 287 that predicts a recommended event for the Z member that is its own member, and a log 238 in which purchase history information of the Z member is accumulated.
  • the event management system X210, the event management system Y220, the event management system Z230, and the logs 218, 228, and 238 have functions similar to those shown in FIG. Omitted.
  • the system 2 is a common event in which event meta information of event X, event meta information of event Y, and event meta information of event Z are converted into a common schema. Holds meta information. Thereby, the event managed by each management system is managed as the common event meta information with the same schema.
  • event meta information of event X event meta information of event Y
  • event meta information of event Z event meta information of event Z
  • the event managed by each management system is managed as the common event meta information with the same schema.
  • the system 2 as well as the system 1, not only event meta information but also member profile information and vacancy information are converted into a common schema.
  • the system 1 is provided with a common prediction engine 150 that can access each management system across.
  • the common prediction engine 150 is not provided, and each of the prediction engines 267, 277, and 287 of each management system has the same function as the common prediction engine 150.
  • the prediction engine 267 of the event management system X210 is configured to be able to access logs 228 and 238 of other management systems via the network 250. Further, the prediction engine 267 is configured to be able to access the common event meta information (and other common information).
  • the prediction engine 267 has the same function as the common prediction engine 150 shown in FIG. 2, and based on the common event meta information and the logs 218, 228, 238 (that is, purchase history information) of each management system, The combination of recommended event and user can be determined.
  • the other prediction engines 277 and 287 also have the same function as the prediction engine 267.
  • system 2 the same effect as system 1 can be obtained. That is, in the general system 4 shown in FIG. 1, the prediction engines 217, 227, and 237 can recommend only events managed by the event management system X 210 to the user. However, in this modification, the event meta information is collectively managed with a common schema, so that the prediction engine 267 can manage events managed by the event management system Y220 and the event management system Z230 that are other management systems. Can be selected as an event to be recommended to the user.
  • the prediction engines 217, 227, and 237 can access only the logs 218, 228, and 238 managed by the management system in which they are provided, and the log of any management system Based on the information stored in 218, 228, and 238, the combination of the recommended event and the user has been determined.
  • the prediction engines 267, 277, 287 are configured to be able to access the logs 218, 228, 238 of other management systems across.
  • the prediction engines 267, 277, and 287 can grasp events managed by other management systems by using the common event meta information. Accordingly, the prediction engines 267, 277, and 287 can comprehensively use the logs 218, 228, and 238 of other management systems to determine the recommended event and user combination. Therefore, the accuracy of prediction is further improved, and more appropriate event recommendation is possible.
  • the modification example in which the prediction engine is provided in each management system has been described as a modification example of the first embodiment with reference to FIG.
  • the prediction engine provided in each management system plays the same role as the common prediction engine, and thus has the same configuration as that of the system 1 by the configuration different from the system 1 described above. Can be realized.
  • the system designer can appropriately select one of the configurations of the system 1 and the system 2 so that the system can be configured more easily, for example, according to the configuration of each management system. .
  • an event is recommended to members in each management system based on the processing result by the common prediction engine 150.
  • users whose events are recommended are limited to members of any management system.
  • information that the common prediction engine 150 refers to in order to generate a prediction model is also limited to a log (purchase history information) in each management system.
  • the second embodiment proposes a system for presenting events to a larger number of users, not limited to members of the management system. Moreover, the system which can produce
  • a technique in which a user's interests and interests are estimated based on a user's behavior history, and a digital advertisement is distributed through the Internet or the like with a target being narrowed down.
  • the second embodiment schematically corresponds to a technique in which the technology described in the first embodiment is applied to the targeting advertisement. Therefore, in the description of the second embodiment below, first, a system related to a general targeting advertisement will be described, and how the system 1 according to the first embodiment can be applied in the system. Will be described. Thereafter, details of the system according to the second embodiment, which is configured by combining the system according to targeting advertisement and the system 1 according to the first embodiment, will be described.
  • FIG. 9 is an explanatory diagram for describing a system related to a general targeting advertisement.
  • the audience 450 (user 450) is a general net user.
  • the targeting advertisement for example, when the user 450 visits the media 460 (for example, a web page), an advertisement in accordance with the interest and interest of the user is displayed in the advertisement display area (advertisement space) in the media 460. Is done.
  • an affiliate company 431 and a DSP (Demand Side Platform) company 442 are illustrated as examples of a company that distributes advertisements to the advertising space of the media 460.
  • Advertisers 431 and DSP companies 442 are provided (published) advertisement data of content (for example, events) from advertisers 410, and affiliate companies 431 and DSP companies 442 use the advertisement data as media. Delivered to 460 advertising spaces.
  • the creation of advertisement data and the placement of advertisement data may be performed via the advertisement agency 420 or the like. For example, when the content is an event, the advertiser 410 can be the organizer of the event.
  • the affiliate system 430 allows the user 450 to register as a member in a system managed by the advertiser 410 or purchase a product of the advertiser 410 through the advertisement distributed to the advertising space, so that the media 460 can be used. It is a system that pays the administrator.
  • An RTB (Real Time Bidding) system 440 to which the DSP provider 442 belongs is a system that supports the buying and selling of advertising space between the advertiser and the manager of the media 460.
  • an SSP (Supply Side Platform) provider 441 that deposits and sells advertising space from the administrator of the media 460
  • a DSP provider 442 that manages and manages advertisement data from the advertiser 410
  • the advertising space is bought and sold in a real-time auction format, and the advertising data of the DSP operator 442 that has bid off the advertising space is posted in the advertising space.
  • affiliate operator 431 can access advertiser 410 through advertisements delivered by more users 450, and DSP operator 442 can promote advertising more effectively than bid prices.
  • a targeting advertisement is preferably performed in consideration of the behavior tendency and preference of the user 450.
  • the history of actions of the user 450 on the media 460 can be grasped for each CookieID through Cookie. .
  • This can be realized by, for example, the DSP operator 442 installing a tag (DSP tag 461) on the medium 460 (Web page), and identifying the user 450 via the Cookie ID using the tag.
  • This technique is called Cookie-Sync.
  • the purchase history of members in a system managed by the advertiser 410 is managed as a private DMP (Data Management Platform) 471 or a public DMP 472.
  • the prediction engine 470 can determine a combination of a recommended event and a user using an action history on the medium 460 of the user 450, information in the Private DMP 471 and / or information in the Public DMP 472.
  • the prediction engine 470 provides information about the determined event and user combination to the DSP operator 442 and / or the affiliate operator 431. Accordingly, an advertisement of an appropriate event that better matches the preference of the user 450 is distributed by the DSP operator 442 and / or the affiliate operator 431. Further, the prediction engine 470 may provide information about the determined event and user combination to the SSP operator 441. Thereby, the SSP provider 441 can make a strategy for selling the advertising space, such as selecting a Web site in which the advertising space is installed so that the advertising space can be purchased at a higher bid price.
  • the system 5 related to general targeting advertisement has been described above.
  • the system 1 according to the first embodiment is applied to the system 5 illustrated in FIG. 9.
  • the logs 218, 228, 238 and the purchase history information DB 215 described in the first embodiment can correspond to the Private DMP 471 shown in FIG. Advertiser 410 can also correspond to an event organizer.
  • Advertiser 410 can also correspond to an event organizer.
  • the user to whom the event advertisement is distributed is not limited to a member of the management system, and the distribution target of the advertisement can be extended to a general net user.
  • the system according to the second embodiment will be described in detail.
  • the second embodiment a case will be described in which an advertisement is distributed by the DSP provider based on the processing result of the prediction engine.
  • the second embodiment is not limited to this example, and the trader that distributes the advertisement may be another trader such as the above-described affiliate company.
  • FIG. 10 is an explanatory diagram for explaining an overview of a system according to the second embodiment.
  • the detailed configuration of the system according to the second embodiment will be described in detail in the following (3-3. System configuration).
  • 3-3. System configuration 3-3. System configuration
  • the event X is managed by the event management system X610
  • the event Y is managed by the event management system Y620
  • the event Z is managed by the event management system Z630.
  • the event management system X610 has a Private DMP 618 in which purchase history information of the X member who is its own member is stored.
  • the event management system Y620 includes a Private DMP 628 in which purchase history information of the Y member who is its own member is accumulated.
  • the event management system Z630 has a Private DMP 638 in which purchase history information of the Z member that is its own member is stored.
  • the Private DMPs 618, 628, and 638 have substantially the same functions as the logs 218, 228, and 238 shown in FIG.
  • the event meta information of the event X, the event meta information of the event Y, and the event meta information of the event Z are converted into a common schema, and the common event Meta information is retained.
  • the event managed by each management system is managed as the common event meta information with the same schema.
  • not only event meta information but also member profile information and vacant seat information are converted into a common schema.
  • the system 3 includes an Ad Log DB 560.
  • the Ad Log DB 560 is a database in which user action history information on the Web site is accumulated.
  • users are managed by Cookie ID.
  • the common prediction engine 570 is configured to be able to access the private DMPs 618, 628, and 638 managed by each management system, and to access the common event meta information described above and the Ad Log DB 560. Is done.
  • the common prediction engine 570 determines a combination of a recommended event and a user based on purchase history information in the private DMPs 618, 628, and 638, common event meta information, and user action history information in the Ad Log DB 560.
  • the common prediction engine 570 uses the private DMPs 618, 628, and 638 of other management systems comprehensively by using the common event meta information. The combination of recommended event and user can be determined. Therefore, the accuracy of the prediction process by the common prediction engine 570 is further improved, and more accurate event and user matching is possible.
  • user behavior history information in the Ad Log DB 560 is also used for prediction processing by the common prediction engine 570.
  • the user is managed by the user ID as a member registered in each management system.
  • Ad Log DB 560 the user is managed by Cookie ID. Therefore, in the second embodiment, the Cookie ID of each member is identified, and the users are collectively managed by the Cookie ID. As a result, the user's action on the management system (ticket purchase or the like) and the action on the website (browsing the website or selecting a link) are linked by the CookieID.
  • the user can be preferably managed by the Cookie ID.
  • the user ID in the first embodiment can be read as Cookie ID in the second embodiment.
  • the identification of a member's Cookie ID as described above can be realized by using a technique called Cookie-Sync, for example.
  • Cookie-Sync for example, a subject that performs identification embeds a tag in a website, whereby a predetermined cookie is set for the browser of the user who visited the website. For example, even when the user visits another website via the set cookie, the user is uniquely identified.
  • Cookie-Sync is a widely used technique. For example, as described in (3-1. Targeting advertisement) above, in order to perform a targeting advertisement, a DSP company embeds a tag in a website, identifies a user using Cookie-Sync, In general, the interest and interest are estimated from the history. For example, in the second embodiment, a Cookie ID of a member can be identified by performing Cookie-Sync using a tag installed by a DSP contractor. Thus, by using an existing tag, it is not necessary to newly install a tag, and the system 3 can be constructed at a lower cost. As described above, since Cookie-Sync is a widely used technique, a detailed description of Cookie-Sync is omitted here.
  • the behavior of other users on the management system and the behavior on the Web site are grasped by being linked by CookieID.
  • a user 590b different from the user 590a purchases a ticket for a certain event using the event management system X610.
  • the ticket purchase history information of the user 590b is stored in the Private DMP 618.
  • the action history information on the user 590b on the website is stored in the Ad Log DB 560.
  • the purchase history information of the ticket of the user 590c who has purchased a ticket for an event using the event management system Y620 is stored in the private DMP 628, and the action history information on the website of the user 590c is Ad Log. Stored in the DB 560.
  • the purchase history information of the ticket of the user 590d who purchased the ticket of the event using the event management system Z630 is stored in the Private DMP 638, and the action history information on the Web site of the user 590d is the Ad Log DB 560. Stored in
  • the common prediction engine 570 refers to the purchase history information on the management system stored in the Private DMPs 618, 628, and 638 and the action history information on the Web site stored in the Ad Log DB 560.
  • the common prediction engine 570 determines a combination of a recommended event and a user by comprehensively using purchase history information and action history information of a certain user. Therefore, the accuracy of the prediction process by the common prediction engine 570 is further improved.
  • the event is presented to the user.
  • a user who recommends an event is also determined using the action history information in the Ad Log DB 560, so the user is not necessarily a member of any management system.
  • the common prediction engine 570 selecting a user who should recommend an event, a user who is assumed to be interested in the event from non-member users based on the behavior history information May be extracted.
  • the user since the user is managed by the user ID in each management system, when the same user is registered as a member of a different management system and has a plurality of user IDs. The user is treated as a different person for each user ID.
  • users since users are managed by CookieID, even when the same user is registered as a member of a different management system, the user can be uniquely identified. Therefore, when matching a recommended event with a user, a situation in which the same user is matched multiple times is avoided, and more efficient advertisement distribution can be realized.
  • a combination of recommended event and user by referring not only to private DMP (purchase history information) in each management system but also to action history information on the website. Is determined.
  • the user (member) in the management system and the user who uses the website are linked through, for example, CookieID, so the common prediction engine 570 determines the purchase history information and the action history information.
  • the user's preference can be analyzed and matching with an event can be performed. Therefore, more accurate matching can be realized.
  • a user who is not a member of the management system can also be selected as an event recommendation target. Therefore, it is possible to expand the target for which an event is recommended, and to promote sales of tickets for the event.
  • FIG. 11 is a block diagram illustrating a configuration example of the system 3 according to the second embodiment.
  • 12 is a functional block diagram illustrating an example of a functional configuration of the recommendation unit 530 illustrated in FIG.
  • the system 3 includes an information processing device 50, an event management system X610, an event management system Y620, an event management system Z630, an organizer profile information DB 140, and input / output.
  • Unit 160 and Ad Log DB 560 the event management system X610, the event management system Y620, and the event management system Z630 correspond to the event management system X610, the event management system Y620, and the event management system Z630 shown in FIG. 10, respectively.
  • the Ad Log DB 560 corresponds to the Ad Log DB 560 shown in FIG.
  • the organizer profile information DB 140 and the input / output unit 160 have the same functions as those shown in FIG.
  • the configuration of the event management system X610 is illustrated in detail, but the event management system Y620 and the event management system Z630, which are other management systems, may have the same configuration.
  • the processing executed between the user who is a member of the event management system X610 and the event management system X610 will be described, but the event management system Y620 and the event Similar processing can be executed between members of the management system Y620, and similar processing can be executed between members of the event management system Z630 and the event management system Z630.
  • the Ad Log DB 560 stores user action history information on the Web site.
  • the action history information includes information on every action performed by the user on the medium (for example, a website).
  • the action history information includes information about a website viewed by the user, information about a link selected by the user on the website, and conversion (for example, purchase of a product, member registration) on the user's website. This information is included.
  • the action history information is managed by CookieID. A specific method for acquiring the action history information will be described in detail again in the following (3-4. Specific Example of Acquisition Method of Action History Information).
  • the event management system X610 has a ticket sales system 211, an event meta information DB 212, a vacant seat information DB 213, a member profile information DB 214, and a purchase history information DB 215 as its functions.
  • the purchase history information DB 215 corresponds to the Private DMP 618 shown in FIG. Note that the ticket sales system 211, the event meta information DB 212, the vacant seat information DB 213, the member profile information DB 214, and the purchase history information DB 215 have the same functions as those shown in FIG. Description is omitted.
  • the information processing apparatus 50 functions as a schema conversion unit 110, a common event meta information DB 121, a common vacancy information DB 122, a common member profile information DB 123, a recommendation unit 530, a presentation control unit 170, Have
  • the schema conversion unit 110, the recommendation unit 530, and the presentation control unit 170 are configured by various processors such as a CPU and a DSP, for example, and the functions of the schema conversion unit 110, the recommendation unit 130, and the presentation control unit 170 are performed by the processor. It can be realized by operating according to a predetermined program.
  • the schema conversion unit 110, the presentation control unit 170, the common event meta information DB 121, the common vacant seat information DB 122, and the common member profile information DB 123 have the same functions as those shown in FIG. Therefore, detailed description thereof is omitted.
  • the recommendation unit 530 determines a combination of recommended event and user based on the common event meta information, purchase history information, and action history information.
  • the recommendation unit 530 has a function corresponding to the common prediction engine 570 shown in FIG.
  • the method of using the common information and purchase history information in the recommendation unit 530 is the same as that of the recommendation unit 130 in the first embodiment.
  • the recommendation unit 530 associates the purchase history information in the purchase history information DB 215 with the common event meta information, thereby comprehensively using the purchase history information of each management system, and recommending a combination of the event and the user Generate a prediction model for selecting.
  • the recommendation unit 530 associates the user ID included in the purchase history information with the Cookie ID included in the action history information in the Ad Log DB 560 using, for example, a method such as Cookie-Sync. This makes it possible to link purchase history information and action history information of the same user.
  • the recommendation unit 530 can grasp, for example, what action a user who has purchased a ticket for an event is taking on the Web site.
  • the recommendation unit 530 determines the combination of the recommended event and the user by using both the purchase history information and the action history information in which the user is identified in this way. Therefore, highly accurate recommendation processing is realized.
  • the recommendation unit 530 has a function of determining a sales strategy, like the recommendation unit 130 in the first embodiment.
  • the recommendation unit 530 can determine the sales strategy by further using the action history information as well as the common event meta information and purchase history information. Therefore, a more accurate sales strategy can be determined.
  • the DSP operator 550 corresponds to the DSP operator 442 shown in FIG. Since the browser of the selected user can also be specified by CookieID, the DSP operator 442 auctions the advertising space provided on the Web browser used by the selected user by RTB and selects the winning advertising space. Display advertisements for selected events.
  • an event can be presented to an unspecified number of net users. Therefore, the target range for which an event is recommended is further expanded, and ticket purchase is promoted.
  • the recommendation unit 530 functions as an organizer profile information acquisition unit 131, a common information acquisition unit 132, a purchase history information acquisition unit 133, an action history information acquisition unit 536, and a prediction model.
  • a generation unit 534, an event-user determination unit 535, and a sales strategy determination unit 537 are included.
  • the organizer profile information DB 140, the common information DB 120, the purchase history information DB 215, the Ad Log DB 560, and the presentation control unit 170 are illustrated together as a configuration for exchanging information with the recommendation unit 530. Show. As in FIG.
  • the common information DB 120 is a block diagram in which the common event meta information DB 121, common vacant seat information DB 122, and common member profile information DB 123 shown in FIG. 11 are combined. Further, among the functions of the recommendation unit 530, the functions of the organizer profile information acquisition unit 131, the common information acquisition unit 132, and the purchase history information acquisition unit 133 are the same as the functions of these configurations illustrated in FIG. Detailed description thereof is omitted.
  • the action history information acquisition unit 536 acquires action history information from the Ad Log DB 560.
  • the behavior history information acquisition unit 536 provides the acquired behavior history information to the prediction model generation unit 534, the event-user determination unit 535, and the sales strategy determination unit 537.
  • the sales strategy determination unit 537 determines an event sales strategy based on the common event meta information, purchase history information in each management system, and behavior information.
  • the purchase history information in the purchase history information DB 215 of each management system is linked by event meta information, the user ID included in the purchase history information, and the cookie ID included in the action history information in the Ad Log DB 560.
  • the sales strategy determination unit 537 can determine the sales strategy by comprehensively using the purchase history information and the action history information in each management system. Since the function of the sales strategy determination unit 537 is the same as the function of the sales strategy determination unit 136 in the first embodiment except that the action history information is further used, detailed description thereof is omitted.
  • the sales strategy determination unit 537 provides the presentation control unit 170 with information on the determined sales strategy.
  • Information about the sales strategy is presented to the organizer by the presentation control unit 170 via the input / output unit 160.
  • the organizer can determine the final sales strategy with reference to the presented information, and can input it to the organizer profile information DB 140 as the organizer profile information.
  • the prediction model generation unit 534 generates a prediction model for selecting a combination of recommended event and user based on the common event meta information, purchase history information, and behavior history information. As described above, since the purchase history information and the action history information in each management system are associated with each other, the prediction model generation unit 534 can generate a prediction model using these pieces of information comprehensively. .
  • the function of the prediction model generation unit 534 is the same as the function of the prediction model generation unit 134 in the first embodiment except that the action history information is further used, and thus detailed description thereof is omitted.
  • the type of the prediction model generated by the prediction model generation unit 534 may be the same as the prediction model generated by the prediction model generation unit 134 illustrated in FIG.
  • the prediction model generation unit 534 can also generate a prediction model based on sales history information, user behavior tendency information, and the like, similarly to the prediction model generation unit 134 shown in FIG.
  • the prediction model generation unit 534 provides the generated prediction model to the event-user determination unit 535.
  • the event-user determination unit 535 determines a combination of recommended event and user based on the generated prediction model. Since the process performed by the event-user determination unit 535 is substantially the same as that of the prediction model generation unit 134 illustrated in FIG. 4, detailed description thereof is omitted. However, in the second embodiment, the event-user determining unit 535 includes not only members of the management system but also users who recommend events including a large number of unspecified users whose behavior history information has been acquired. You can choose.
  • the event-user determining unit 535 provides the DSP operator 550 with information on the selected event and user combination.
  • the DSP operator 550 displays an advertisement of the selected event in an advertisement space on the selected user's Web browser, for example.
  • action history information representing the action of the user on the media is acquired. Since the user ID included in the purchase history information and the Cookie ID included in the action history information can be associated with each other by a method such as Cookie-Sync, for example, the purchase history information and the action history information of the same user are linked. Is possible. Therefore, in the second embodiment, the purchase history information and the action history information of each management system can be handled comprehensively, and the accuracy of the prediction engine can be further improved.
  • the target for recommending an event is not limited to members of the management system but also to an unspecified number of users whose behavior history information has been acquired, advertisements can be distributed to a larger number of users. It becomes possible. Therefore, sales of event tickets are further promoted, and a system that is highly convenient for the organizer can be realized. In addition, for the user, an event more suited to his / her preference is recommended, and the convenience for the user is improved.
  • each DB may be provided as an external device different from the information processing device 50, and the information processing device 50 executes the various processes described above while communicating with these DBs that are external devices. Also good.
  • a computer program for realizing the functions of the information processing apparatus 50 according to the second embodiment as described above, and to implement it on a personal computer or the like.
  • a computer-readable recording medium storing such a computer program can be provided.
  • the recording medium is, for example, a magnetic disk, an optical disk, a magneto-optical disk, a flash memory, or the like.
  • the above computer program may be distributed via a network, for example, without using a recording medium.
  • FIG. 13 shows an example of the website 320 that the user is browsing.
  • the website 320 is a main page for ticket sales for a live event.
  • information indicating that the main page of ticket sales for the live event has been browsed can be acquired as action history information.
  • the website 320 includes images of the performers of the event and event information, as well as links to ticket sales sites (“Sales site X”, “Sales site Y” and “Sales site Z” in the figure). Is displayed. When actually purchasing a ticket, the user selects a link of one of the sales sites, moves to the corresponding sales site, and then purchases the ticket. For example, information about which sales site link the user has selected can also be acquired as action history information.
  • FIG. 14 schematically illustrates the relationship between the ticket sales main page and the linked sales site.
  • a website 330 is a main page for event ticket sales, similar to the website 320 shown in FIG.
  • a link 331 to a company site for example, as a link to a ticket sales site, a link 331 to a company site, a link 332 to another sales site X, and a link 333 to another sales site Y are displayed. Further, a tag 334 (for example, a DSP tag) is set on the Web site 330. The fact that the user has browsed the website 330 or that the user has selected any of the links 331, 332, and 333 on the website 330 is stored in the Ad Log DB 560 by the tag 334.
  • a tag 334 for example, a DSP tag
  • the website 340 of the sales site X is displayed.
  • a tag 344 is set in the Web site 340, and user actions on the Web site 340 are accumulated in the Ad Log DB 560 by the tag 344.
  • the website 350 of the sales site Y is displayed.
  • a tag 354 is set in the Web site 350, and user actions on the Web site 350 are accumulated in the Ad Log DB 560 by the tag 354.
  • a tag is embedded in the main page of ticket sales or each sales site, and user behavior information on the main page of ticket sales or each sales site is acquired based on the tag.
  • the second embodiment is not limited to such an example. For example, it is possible to acquire web page information (so-called referrer URL) before moving to the web page by installing a tag on the web page.
  • web page information so-called referrer URL
  • not only the web page on which the tag is set but also the web page information before moving to the web page may be acquired as one of the browsing history information of the user.
  • the web page on which the tag is installed may be a web page without an advertisement frame.
  • a tag on a Web page without an advertisement frame it is possible to acquire user browsing history information about a Web page more generally and widely.
  • such browsing history information for a web page without a tag directly installed or browsing history information for a web page without an advertising space is also acquired as user behavior history information and predicted. It may be reflected in the model. This makes it possible to generate a prediction model that captures user preferences with higher accuracy.
  • FIG. 15 is a flowchart illustrating an example of a processing procedure of the information processing method according to the second embodiment.
  • the information processing method will be described by taking as an example a case where the event S managed by the event management system X610 is recommended to the user in the system 3 shown in FIG.
  • step S201 event meta information and organizer profile information of event S are registered by the organizer (step S201).
  • step S203 the event meta information and vacancy information of the event S and the member profile information of the management system are converted into a common schema (step S203). Note that the processing shown in step S201 and the processing shown in step S203 are the same as the processing shown in step S101 and the processing shown in step S103 of the information processing method according to the first embodiment shown in FIG. Detailed description thereof will be omitted.
  • a sales strategy is determined based on the common event meta information, purchase history information, and action history information (step S204).
  • the sales strategy can be determined based on, for example, the type of event, the past sales record of the same type of event, the user's action on the Web page related to the event S, and the like.
  • the process shown in step S204 corresponds to the process performed by, for example, the sales strategy determination unit 537 shown in FIG.
  • a prediction model is generated based on the common event meta information, purchase history information, and action history information (step S205).
  • the prediction model is a model for predicting a user who should recommend the event S in consideration of, for example, the type of event and the purchase history of the user.
  • the process shown in step S205 corresponds to, for example, the process performed by the prediction model generation unit 534 shown in FIG.
  • step S207 a user that matches the event S is selected based on the generated prediction model.
  • the process shown in step S207 corresponds to the process performed by, for example, the event-user determining unit 535 shown in FIG. Note that the user selected in the process shown in step S207 is not limited to a member of any management system, and may be an unspecified number of users whose behavior history information has been acquired.
  • step S209 information about the event S and the selected user is provided to the DSP operator 550 (step S209). Then, when the selected user visits the Web site where the advertising space exists, the DSP business operator 550 performs RTB (step S211).
  • the DSP operator 550 displays the advertisement of the event S in the advertising space (step S213). As a result, the event S to be recommended is presented to the selected user.
  • the user's action on the website is transmitted to the Ad Log DB 560 by the tag set in the website (step S215).
  • the action history information is accumulated in the Ad Log DB 560, and the action history information in the Ad Log DB 560 is updated.
  • the action on the website is an action for an advertisement of the displayed event S.
  • the process shown in step S215 not only the behavior of the selected user with respect to the advertisement of the event S, but also any behavior of any user on the website can be acquired as behavior history information.
  • step S217 the vacant information of the event S in the vacant seat information DB 213 and the purchase history information of the user in the purchase history information DB 215 are updated (step S217).
  • step S217 not only when the user purchases a ticket for the event S by looking at the presented advertisement for the event S, but other purchase behaviors of the user are also vacant seat information in the vacant seat information DB 213. And the purchase history information in the purchase history information DB 215 can be reflected.
  • step S219 the vacancy information of the event S in the vacancy information DB 213 and the purchase history information of the user in the purchase history information DB 215 are updated. Since the process shown in step S219 is the same process as the process shown in step S115 of the information processing method according to the first embodiment shown in FIG. 6, detailed description thereof is omitted.
  • step S215 the processing shown in step S215, the processing shown in step S217, and the processing shown in step S219 are shown in this order.
  • these processing are processing that is executed as needed in the system 3. Therefore, the order may be arbitrary.
  • step S219 When the process shown in step S219 is completed, the process returns to step S203, and the processes after step S203 are repeatedly executed based on the updated vacant seat information, purchase history information, and action history information.
  • a member by changing sales strategy information in the organizer profile information according to the sales performance, registering a new member, or withdrawing an existing member, etc.
  • the change of the profile information, the change of the event meta information accompanying the change of the event content, etc. can be performed at any time. In the flow shown in FIG. 15, such change of the organizer profile information, event meta information, and member profile information may be appropriately executed. In that case, processing shown in each step may be executed based on the changed information.
  • the prediction model generation process shown in step S205 may not be performed every time the series of processes shown in FIG. 15 is executed.
  • the process shown in step S205 may be performed to update the prediction model once a week or at a timing when a certain amount of purchase history information is updated.
  • FIG. 16 is a functional block diagram illustrating an example of a hardware configuration of the information processing apparatus according to the first and second embodiments.
  • the information processing apparatus 900 illustrated in FIG. 16 can realize, for example, the information processing apparatuses 10 and 50 illustrated in FIGS. 3 and 11.
  • the information processing apparatus 900 includes a CPU 901, a ROM (Read Only Memory) 903, and a RAM (Random Access Memory) 905.
  • the information processing apparatus 900 may include a host bus 907, a bridge 909, an external bus 911, an interface 913, an input device 915, an output device 917, a storage device 919, a communication device 921, a drive 923, and a connection port 925.
  • the information processing apparatus 900 may include a processing circuit called a DSP or ASIC (Application Specific Integrated Circuit) instead of or in addition to the CPU 901.
  • the CPU 901 functions as an arithmetic processing device and a control device, and controls all or a part of the operation in the information processing device 900 according to various programs recorded in the ROM 903, the RAM 905, the storage device 919, or the removable recording medium 929.
  • the ROM 903 stores programs used by the CPU 901, calculation parameters, and the like.
  • the RAM 905 temporarily stores programs used in the execution of the CPU 901, parameters at the time of execution, and the like.
  • the CPU 901, the ROM 903, and the RAM 905 are connected to each other by a host bus 907 configured by an internal bus such as a CPU bus. Further, the host bus 907 is connected to an external bus 911 such as a PCI (Peripheral Component Interconnect / Interface) bus via a bridge 909.
  • the CPU 901 can configure, for example, the schema conversion unit 110, the recommendation units 130 and 530, and the presentation control unit 170 in the first and second embodiments described above.
  • the host bus 907 is connected to an external bus 911 such as a PCI (Peripheral Component Interconnect / Interface) bus via a bridge 909.
  • PCI Peripheral Component Interconnect / Interface
  • the input device 915 is configured by a device operated by a user, such as a mouse, a keyboard, a touch panel, a button, a switch, and a lever.
  • the input device 915 may be, for example, a remote control device (so-called remote controller) that uses infrared rays or other radio waves, or an external connection device such as a mobile phone or a PDA that supports the operation of the information processing device 900. It may be 931.
  • the input device 915 includes an input control circuit that generates an input signal based on information input by the user using the above-described operation means and outputs the input signal to the CPU 901, for example.
  • a user of the information processing apparatus 900 can input various data and instruct a processing operation to the information processing apparatus 900 by operating the input device 915.
  • various types of information processed by the information processing devices 10 and 50 may be input via the input device 915.
  • the input / output unit 160 illustrated in FIGS. 3 and 11 is configured integrally with the information processing apparatuses 10 and 50, the input / output unit 160 may be configured by the input device 915.
  • the output device 917 is a device that can notify the user of the acquired information visually or audibly. Examples of such devices include CRT display devices, liquid crystal display devices, plasma display devices, EL display devices, display devices such as lamps, audio output devices such as speakers and headphones, printer devices, and the like.
  • the output device 917 outputs results obtained by various processes performed by the information processing apparatus 900. Specifically, the display device visually displays results obtained by various processes performed by the information processing device 900 in various formats such as text, images, tables, and graphs.
  • the audio output device converts an audio signal composed of reproduced audio data, acoustic data, and the like into an analog signal and outputs it aurally.
  • various types of information processed by the information processing devices 10 and 50 may be output via the output device 917.
  • the input / output unit 160 illustrated in FIGS. 3 and 11 is configured integrally with the information processing apparatuses 10 and 50, the input / output unit 160 may be configured by the output device 917.
  • the storage device 919 is a data storage device configured as an example of a storage unit of the information processing device 900.
  • the storage device 919 includes, for example, a magnetic storage device such as an HDD, a semiconductor storage device, an optical storage device, or a magneto-optical storage device.
  • the storage device 919 stores programs executed by the CPU 901, various data, various data acquired from the outside, and the like.
  • the storage device 919 can configure various DBs provided in the information processing apparatuses 10 and 50 according to the first and second embodiments described above, for example.
  • the communication device 921 is a communication interface configured by a communication device for connecting to a communication network (network) 927, for example.
  • the communication device 921 is, for example, a communication card for wired or wireless LAN (Local Area Network), Bluetooth (registered trademark), or WUSB (Wireless USB).
  • the communication device 921 may be a router for optical communication, a router for ADSL (Asymmetric Digital Subscriber Line), a modem for various communication, or the like.
  • the communication device 921 can transmit and receive signals and the like according to a predetermined protocol such as TCP / IP, for example, with the Internet or other communication devices.
  • the network 927 connected to the communication device 921 is configured by a wired or wireless network, and may be, for example, the Internet, a home LAN, infrared communication, radio wave communication, satellite communication, or the like.
  • the information processing apparatuses 10 and 50 and other various configurations for example, between the information processing apparatuses 10 and 50 and other various configurations (for example, the management system, the input / output unit 160, the organizer profile information DB 140, the Ad Log DB 560, etc.) May be executed by the communication device 921 via the network 927.
  • the drive 923 is a recording medium reader / writer, and is built in or externally attached to the information processing apparatus 900.
  • the drive 923 reads information recorded on a removable recording medium 929 such as a mounted magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, and outputs the information to the RAM 905.
  • the drive 923 can also write information to a removable recording medium 929 such as a mounted magnetic disk, optical disk, magneto-optical disk, or semiconductor memory.
  • the removable recording medium 929 is, for example, a DVD medium, an HD-DVD medium, a Blu-ray (registered trademark) medium, or the like.
  • the removable recording medium 929 may be a compact flash (registered trademark) (CompactFlash: CF), a flash memory, an SD memory card (Secure Digital memory card), or the like. Further, the removable recording medium 929 may be, for example, an IC card (Integrated Circuit card) on which a non-contact IC chip is mounted, an electronic device, or the like. In the first and second embodiments, for example, various types of information processed by the information processing apparatuses 10 and 50 may be read from the removable recording medium 929 by the drive 923 or written to the removable recording medium 929. Good.
  • the connection port 925 is a port for directly connecting a device to the information processing apparatus 900.
  • Examples of the connection port 925 include a USB (Universal Serial Bus) port, an IEEE 1394 port, and a SCSI (Small Computer System Interface) port.
  • As another example of the connection port 925 there are an RS-232C port, an optical audio terminal, an HDMI (registered trademark) (High-Definition Multimedia Interface) port, and the like.
  • the information processing apparatus 900 acquires various data directly from the external connection device 931 or provides various data to the external connection device 931.
  • various types of information processed by the information processing apparatuses 10 and 50 are acquired from the external connection device 931 via the connection port 925 or output to the external connection device 931. May be.
  • each component described above may be configured using a general-purpose member, or may be configured by hardware specialized for the function of each component. Therefore, it is possible to change the hardware configuration to be used as appropriate according to the technical level at the time of carrying out this embodiment.
  • a computer program for realizing each function of the information processing apparatus 900 according to the present embodiment as described above can be produced and mounted on a PC or the like.
  • a computer-readable recording medium storing such a computer program can be provided.
  • the recording medium is, for example, a magnetic disk, an optical disk, a magneto-optical disk, a flash memory, or the like.
  • the above computer program may be distributed via a network, for example, without using a recording medium.
  • the type of website that presents the event determined by the recommendation unit 530 to the user is not particularly limited, but the present technology is not limited to such an example.
  • the URL of a website related to an event to be recommended is defined in advance, and the recommendation unit 530 performs RTB when the user who recommends the event visits the website, and An advertisement may be displayed.
  • an appropriate medium that matches the user's preference is selected as the medium on which the event is presented, and the attractiveness of the advertisement is further enhanced.
  • the content handled in the first and second embodiments described above is not limited to an event, and may be any content.
  • the content may be an auction item, a personal resale, or the like.
  • the advertiser may be an individual who is a seller at the auction or resale rather than a business that sells content as a business. In this way, the present technology can be suitably applied to a system for buying and selling content personally.
  • Schema conversion unit that converts content meta information managed by a plurality of different management systems into a common schema, common content meta information converted into a common schema, content of each management system
  • An information processing apparatus comprising: a recommendation unit that determines a combination of content to be recommended and a user based on purchase history information.
  • a sales strategy determination unit that determines a sales strategy of the content based on the common content meta information and content purchase history information in each management system, wherein the recommendation unit includes the sales The information processing apparatus according to (1), wherein a combination of recommended content and a user is determined based on the sales strategy determined by the strategy determination unit.
  • the content is a quantitative product in which at least one of a sales period and the number of sales is limited, and the sales strategy includes an advertising strategy for the content according to the sales period and the number of sales.
  • the advertising strategy depends on the advertising amount of the content according to the sales period and the number of sales, the advertising period of the content according to the sales period and the sales number, the sales period and the number of sales.
  • the information processing apparatus according to (3) including at least one of an attribute of a user who advertises the content and a cost-effectiveness of advertising the content according to the sales period and the number of sales.
  • the sales strategy determined by the sales strategy determination unit is presented to the seller of the content, and the seller can specify the sales strategy used for the determination process by the recommendation unit based on the presented sales strategy
  • the information processing apparatus according to any one of (2) to (4), further including a presentation control unit that provides a simple interface.
  • the recommendation unit determines a combination of the recommended content and the user based further on a sales strategy specified by the seller of the content via an interface provided by the presentation control unit.
  • the recommendation unit determines a combination of content to be recommended and the user based further on behavior tendency information indicating a behavior tendency of the user when purchasing the content, any one of (1) to (6)
  • the information processing apparatus according to any one of (1) to (8), wherein: (10) In any one of (1) to (9), the recommendation unit further determines a combination of content to be recommended and a user based on behavior history information representing the behavior of the user on the media. The information processing apparatus described.
  • the behavior history information includes at least one of information indicating that a website has been browsed, information indicating that a link on the website has been selected, and information regarding conversion on the website.
  • the recommendation unit determines a user who has acquired the behavior history information and is not a member registered in any of the plurality of management systems as a user who recommends content.
  • (13) The information processing apparatus according to any one of (1) to (12), wherein the content is an event with a limited number of seats.
  • the processor converts content meta information managed by a plurality of different management systems into a common schema, common content meta information converted into a common schema, and content in each management system And determining the combination of the recommended content and the user based on the purchase history information.
  • a function for converting content meta information managed by a plurality of different management systems into a common schema in a processor of a computer, common content meta information converted into a common schema, and each management system A program for realizing a function for determining a combination of a recommended content and a user based on the purchase history information of the content.
  • Information processing device 110 Schema conversion unit 120 Common information DB 121 Common event meta information DB 122 Common vacancy information DB 123 Common member profile information DB 130, 530 Recommendation unit 131 Organizer profile information acquisition unit 132 Common information acquisition unit 133 Purchase history information acquisition unit 134, 534 Prediction model generation unit 135, 535 Event-user determination unit 136, 537 Sales strategy determination unit 140 Host profile Information DB 150 Prediction Engine 160 Input / Output Unit 170 Presentation Control Unit 210 Event Management System X 211 Ticket sales system 212 Event meta information DB 213 Vacancy information DB 214 Member Profile Information DB 215 Purchase history information DB 216 Recommended Event Presentation Unit 220 Event Management System Y 230 Event management system Z 536 Action history information acquisition unit 560 AD Log DB

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Computer Interaction (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Environmental & Geological Engineering (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

ユーザ及びコンテンツの売り主の利便性をより向上させることを可能にする。互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置を提供する。

Description

情報処理装置、情報処理方法及びプログラム
　本開示は、情報処理装置、情報処理方法及びプログラムに関する。
　一般的に、各種のコンテンツ（例えば、コンサート、演劇、映画等のイベント）をユーザに対して推薦する技術が開発されている。例えば、特許文献１には、ユーザが所持する移動通信端末から位置情報を受信し、イベントの開催場所から所定の範囲内にあり、かつ位置情報の取得日時がイベントの実行日時より前である移動通信端末に対して、当該イベントのイベント情報を配信する技術が開示されている。
　また、コンサート等の座席が存在するイベントでは、ユーザが、座席を選択して当該イベントのチケットを購入することが一般的に行われている。特許文献２には、イベントのチケットを電子化し、会場のゲートでのユーザの誘導を円滑に実施できるようにする技術が開示されている。
特開２００９－７１４９９号公報 特開２００２－１９７２２４号公報
　ここで、興行主や主催者（以下、簡単のため、まとめて主催者と総称する。）が存在する興行イベント（例えば、コンサート、演劇、スポーツの試合、映画、講演会等）では、主催者ごとに独自のイベント管理システムやチケット販売システムを有している場合が多い。また、ユーザのチケットの購入履歴等の情報も主催者ごとに管理されることが一般的である。特許文献１、２に記載の技術では、このような、コンテンツが互いに異なる管理システムによって管理されている場合については十分に考慮されていなかった。
　上記事情に鑑みれば、ユーザに対してコンテンツを推薦するシステムや、ユーザに対してコンテンツを販売するシステムを、ユーザ及びコンテンツの売り主にとってより利便性の高いものに改良できる余地がある。そこで、本開示では、ユーザ及びコンテンツの売り主の利便性をより向上させることが可能な、新規かつ改良された情報処理装置、情報処理方法及びプログラムを提案する。
　本開示によれば、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置が提供される。
　また、本開示によれば、プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、を含む、情報処理方法が提供される。
　また、本開示によれば、コンピュータのプロセッサに、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、を実現させるためのプログラム。
　本開示によれば、互いに異なる管理システムによって管理されるイベントメタ情報が、共通のスキーマに変換される。従って、各管理システムにおけるコンテンツの購入履歴情報を、共通のスキーマで総合的に扱うことが可能となる。よって、各管理システムにおけるコンテンツの購入履歴情報を総合的に用いて、推薦するコンテンツとユーザの組み合わせを決定することができるため、より適切な組み合わせが決定され、ユーザによる購入行動がより促進される。
　以上説明したように本開示によれば、ユーザ及びコンテンツの売り主の利便性をより向上させることが可能となる。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、又は上記の効果に代えて、本明細書に示されたいずれかの効果、又は本明細書から把握され得る他の効果が奏されてもよい。
一般的なシステムの概要について説明するための説明図である。 本開示の第１の実施形態に係るシステムの概要について説明するための説明図である。 第１の実施形態に係るシステムの一構成例を示すブロック図である。 図３に示す推薦部の機能構成の一例を示す機能ブロック図である。 ユーザの行動傾向情報に基づく販売戦略の決定処理について説明するための説明図である。 第１の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。 主催者によって各種の情報が入力される情報入力画面の一表示例を示す図である。 各管理システムに予測エンジンが設けられる変形例に係るシステムの概要を示す図である。 一般的なターゲティング広告に係るシステムについて説明するための説明図である。 第２の実施形態に係るシステムの概要について説明するための説明図である。 第２の実施形態に係るシステムの一構成例を示すブロック図である。 図１１に示す推薦部の機能構成の一例を示す機能ブロック図である。 行動履歴情報の取得方法について説明するための説明図である。 行動履歴情報の取得方法について説明するための説明図である。 第２の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。 第１及び第２の実施形態に係る情報処理装置のハードウェア構成の一例を示す機能ブロック図である。
　以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
　なお、説明は以下の順序で行うものとする。
　１．一般的なシステムについて
　２．第１の実施形態
　　２－１．システムの概要
　　２－２．システムの構成
　　２－３．情報処理方法
　　２－４．表示例
　　２－５．変形例
　３．第２の実施形態
　　３－１．ターゲティング広告について
　　３－２．システムの概要
　　３－３．システムの構成
　　３－４．行動履歴情報の取得方法の具体例
　　３－５．情報処理方法
　４．ハードウェア構成
　５．補足
　ここで、本開示の第１及び第２の実施形態では、ユーザに対してコンテンツを推薦するシステムについて説明する。以下の説明において、単にシステムといった場合には、特に記載のない限り、このような推薦システムを指すものとする。
　第１及び第２の実施形態において扱われるコンテンツは、例えば映像、音楽、書籍、生活用品（食料品や飲料、衣服、電化製品等）等、一般的にユーザによって購入され得るあらゆるコンテンツであり得る。ただし、第１及び第２の実施形態では、例えばコンサート、演劇、映画、ツアー旅行等の席数（定員）が限定されているイベントが、好適にコンテンツとして扱われる。席数が限定されているイベントでは、そのチケットの販売期間や販売数が制限されるとともに、開催日時が近付くにつれて又残り席数が減るにつれて、当該販売期間や当該販売数も随時変化する。本明細書では、このような販売期間及び販売数の少なくともいずれかが制限されており、販売期間及び販売数が随時変化し得るコンテンツのことを、定量商材とも呼称する。なお、上述した以外のその他の定量商材としては、例えばフラッシュマーケティングにおいて扱われるクーポンや商品等が挙げられる。
　第１及び第２の実施形態は、このような定量商材をユーザに対して推薦する際に、より大きな効果を奏するものである。従って、以下の説明では、システムによって推薦されるコンテンツが、定量商材として扱われるイベントである場合を例に挙げて説明を行う。以下の説明において、単にイベントといった場合には、特に記載のない限り、このような定量商材として扱われるイベントを指すものとする。ただし、上述したように、第１及び第２の実施形態において扱われるコンテンツはかかる例に限定されず、第１及び第２の実施形態では、あらゆるコンテンツがユーザに対して推薦されてよい。
　（１．一般的なシステムについて）
　まず、本開示の第１及び第２の実施形態について説明するに先立ち、本開示をより明確なものとするために、図１を参照して一般的なシステムについて説明する。図１は、一般的なシステムの概要について説明するための説明図である。
　一般的に、イベントは、当該イベントの主催者（以下、イベンター、興行主等とも呼称する。）によって管理されている。図１に示すシステム４では、イベントＸ、イベントＹ、イベントＺが、それぞれ、イベンターＸのイベント管理システムであるイベント管理システムＸ２１０、イベンターＹのイベント管理システムであるイベント管理システムＹ２２０及びイベンターＺのイベント管理システムであるイベント管理システムＺ２３０によって管理されている。なお、以下の説明では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０を特に区別しない場合には、これらを、単に管理システムとも呼称する。
　イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、それぞれが会員を有する。例えば、イベント管理システムＸ２１０の会員（Ｘ会員）は、イベント管理システムＸ２１０に自身のプロファイル情報を登録したユーザであり、イベント管理システムＸ２１０が管理するイベントのチケットを、当該イベント管理システムＸ２１０を介して購入することが可能である。同様に、イベント管理システムＹ２２０の会員（Ｙ会員）及びイベント管理システムＺ２３０の会員（Ｚ会員）も、それぞれ、イベント管理システムＹ２２０及びイベント管理システムＺ２３０に自身のプロファイル情報を登録しており、自身が会員となっている管理システムが管理するイベントのチケットを、各管理システムを介して購入することができる。
　ここで、イベントの管理には、イベントのチケットの販売の管理、イベントメタ情報（イベントについての各種のメタ情報）の管理、会員のプロファイル情報の管理、当該会員のチケットの購入履歴情報の管理及びイベントの推薦の管理等が含まれ得る。イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、各自に登録されているイベントについて、上記のような各種の管理を行う。
　なお、実際の業態としては、イベントの主催者と、当該イベントの管理者とが異なる場合も存在し得る。例えば、イベントの主催者が、チケットの販売を請け負う業者に対して、当該イベントのチケット販売の管理を委託する場合もあり得る。図１に示すイベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、上述したような各種のイベントの管理を総合的に行う管理システムを概略的に図示するものであり、各管理システムの内部は、複数の業者による複数のより小規模なシステムによって構成されていてもよい。
　イベント管理システムＸ２１０は、自身の会員であるＸ会員に対するお薦めのイベントを予測する予測エンジン２１７と、Ｘ会員の購入履歴情報が蓄積されたログ２１８を有する。イベント管理システムＸ２１０は、当該予測エンジン２１７を用いて、Ｘ会員が興味を持ちそうなイベントを、Ｘ会員ごとに予測し、予測されたイベントを各Ｘ会員に対して推薦する機能を有する。なお、予測エンジン２１７は、一般的な推薦システムにおいて用いられる予測エンジンであってよい。例えば、予測エンジン２１７は、ログ２１８を参照することにより、推薦対象であるＸ会員の過去のイベントの購入傾向や、購入傾向の似た他のＸ会員の購入履歴等を参照することにより、当該Ｘ会員に対して推薦するイベントを予測することができる。
　同様に、イベント管理システムＹ２２０及びイベント管理システムＺ２３０も、それぞれ、予測エンジン２２７、２３７及びログ２２８、２３８を有し、自身の会員に対して、イベントを推薦する機能を有する。
　ここで、上述したように、イベントのチケットの販売、推薦においては、イベントの主催者と、当該イベントの管理者とが異なる場合も存在し得る。従って、例えば、同一のイベントが、互いに異なる複数のチケット販売業者に委託されることもある。また、同一のユーザが、互いに異なる複数の管理システムの会員となることもあり得る。このように、実際には、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、同一のイベントを管理している場合もあり得る。また、Ｘ会員、Ｙ会員及びＺ会員の中に、同一のユーザが含まれる可能性もある。
　しかしながら、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、互いに連携しておらず、他の管理システムが管理するイベント及び会員に関与することはできない。例えば、システム４においては、イベントＸのチケットは、イベント管理システムＸ２１０を介してＸ会員によってのみ購入可能であり、Ｙ会員がイベント管理システムＹ２２０を介して又はＺ会員がイベント管理システムＺ２３０を介して、イベントＸのチケットを購入することはできない。また、例えば、会員へのイベントの推薦においても、イベント管理システムＸ２１０は、イベント管理システムＸ２１０に設けられた予測エンジン２１７が、イベント管理システムＸ２１０において蓄積されたログ２１８を用いて予測した結果に基づいて、イベント管理システムＸ２１０が管理するイベントＸを、Ｘ会員に対して推薦することしかできない。このように、システム４では、予測エンジン２１７が、他の管理システムのログ２２８、２３８を予測処理に用いたり、イベント管理システムＸ２１０が他の管理システムが管理するイベントをＸ会員に推薦したりすることはできない。
　また、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０におけるイベントや会員に関する各種の情報の管理手法が、互いに異なっていることが多い。例えば、イベント管理システムＸ２１０とイベント管理システムＹ２２０とでは、イベントメタ情報を登録する際のスキーマが異なる可能性がある。従って、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、ただ単に、イベントメタ情報や会員プロファイル情報を互いに共有したとしても、各管理システムに登録されているイベントや会員が同一のイベントやユーザを指しているのかどうかを判断することができない。
　以上説明したように、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、それぞれ独自に、イベント及び会員を管理していた。従って、同一のイベントや同一のユーザが、互いに異なる管理システムに登録されている場合であっても、そのことをシステム４が認識することができず、ユーザに対するイベントの推薦の精度や、ユーザによるチケット購入における利便性が、必ずしも最適化されているとは言えなかった。
　本発明者らは、上記事情に鑑みて、ユーザの利便性をより向上させることが可能な技術について鋭意検討した結果、以下に示す本開示の好適な実施形態に想到した。以下では、本発明者らが想到した、本開示の好適な実施形態について詳細に説明する。
　（２．第１の実施形態）
　（２－１．システムの概要）
　図２を参照して、本開示の第１の実施形態に係るシステムの概要について説明する。図２は、本開示の第１の実施形態に係るシステムの概要について説明するための説明図である。なお、第１の実施形態に係るシステムのより詳細な構成については、下記（２－２．システムの構成）で改めて詳しく説明する。
　図２を参照すると、第１の実施形態に係るシステム１では、イベント管理システムＸ２１０によってイベントＸが管理され、イベント管理システムＹ２２０によってイベントＹが管理され、イベント管理システムＺ２３０によってイベントＺが管理されている。また、イベント管理システムＸ２１０は、Ｘ会員の購入履歴情報が蓄積されたログ２１８を有し、イベント管理システムＹ２２０は、Ｙ会員の購入履歴情報が蓄積されたログ２２８を有し、イベント管理システムＺ２３０は、Ｚ会員の購入履歴情報が蓄積されたログ２３８を有している。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０、並びに、ログ２１８、２２８、２３８は、図１に示すこれらの構成と同様の機能を有するものであるため、詳細な説明は省略する。
　システム１は、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換された、共通化イベントメタ情報を保持している。各イベントのイベントメタ情報が、共通化イベントメタ情報として同一のスキーマで管理されることにより、システム１では、元々は各管理システムによってそれぞれ管理されていたイベントを、一括して管理することが可能となる。従って、システム１では、元々異なる管理システムで管理されていたイベントが同一のイベントかどうかを判断することが可能となる。
　なお、図示は省略しているが、システム１では、同様に、各管理システムによって管理されている会員プロファイル情報が、共通のスキーマに変換され、共通化会員プロファイル情報として保持される。また、システム１では、同様に、各管理システムによって管理されている空席情報（イベントの残席、すなわちチケットの販売状況を表す情報）が、共通のスキーマに変換され、共通化空席情報として保持される。
　システム１では、共通化会員プロファイル情報が保持されることにより、各管理システムによって管理されている会員プロファイル情報（例えばユーザＩＤ）が共有されることとなる。ただし、各管理システムにおけるユーザＩＤが共有化されたとしても、当該ユーザＩＤは各管理システムにおいて互いに異なるものであるため、第１の実施形態では、それらのユーザＩＤが示す会員が同一のユーザかどうかまでは判断することができない。
　また、システム１では、共通化空席情報が保持されることにより、各イベントの空席情報が共有されることとなる。以下では、共通化イベントメタ情報、共通化会員プロファイル情報及び共通化空席情報等、共通のスキーマに変換された各種の情報のことを、共通化情報とも総称する。
　ここで、システム１では、各管理システムがそれぞれ独自に予測エンジンを有するのではなく、各管理システムに横断的にアクセス可能な共通予測エンジン１５０が設けられる。共通予測エンジン１５０は、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０並びにログ２１８、２２８、２３８にアクセス可能であるとともに、共通化情報にもアクセス可能に構成される。共通予測エンジン１５０は、共通化情報及びログ２１８、２２８、２３８内の購入履歴情報に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能を有する。
　ここで、共通予測エンジン１５０は、共通化イベントメタ情報にアクセスすることにより、各管理システムによって管理されている各イベントを、共通のスキーマで一括して扱うことができる。また、共通予測エンジン１５０は、共通化会員プロファイル情報にアクセスすることにより、各管理システムによって管理されている各会員を、共通のスキーマで一括して扱うことができる。このように、共通予測エンジン１５０は、元来は各管理システムによってそれぞれ独自に管理されていたイベント及び会員を、総合的に扱うことができる。
　従って、共通予測エンジン１５０は、ログ２１８、２２８、２３８を参照して、推薦するコンテンツとユーザの組み合わせを決定する際に、ログ２１８、２２８、２３８内の購入履歴情報における同一のイベントを同定することができ、これらの購入履歴情報を統合して利用することが可能となる。従って、共通予測エンジン１５０は、より多くの購入履歴情報に基づいて推薦するコンテンツとユーザの組み合わせを決定することができるため、ユーザの興味や関心がより高精度に予測され、ユーザが興味を示しているイベントが、より的確に、当該ユーザに対して推薦されることとなる。
　また、共通予測エンジン１５０は、共通化イベントメタ情報及び共通化会員プロファイル情報を用いることにより、ある管理システムによって管理されているイベントを、他の管理システムの会員に対しても推薦することができる。例えば、共通予測エンジン１５０は、イベント管理システムＸ２１０によって管理されているイベントＸを推薦すべきユーザとして、イベント管理システムＹ２２０によって管理されているＹ会員を選択することができる。このように、システム１では、一般的なシステム４に比べて、イベントを推薦する対象が拡大されるため、より多くのユーザに対してイベントの購入を促すことが可能となる、
　更に、システム１では、共通化イベントメタ情報を、各管理システムでのスキーマに再度変換することができる。これにより、各管理システムにおけるチケット販売システムを横断的に利用することが可能となる。例えば、元々イベント管理システムＸによって管理されていたイベントＸの共通化イベントメタ情報を、イベント管理システムＹ２２０のスキーマに再度変換することにより、イベントＸの管理をイベント管理システムＹ２２０によっても行えるようにする。これにより、Ｙ会員に対してイベント管理システムＸ２１０が管理しているイベントＸが推薦された場合であっても、Ｙ会員は、わざわざイベント管理システムＸ２１０に会員として登録する必要はない。Ｙ会員は、イベント管理システムＹ２２０を介して、イベントＸのチケットを購入することができる。このように、第１の実施形態によれば、より自由度が高く、ユーザにとってより利便性の高いチケットの販売方法が実現される。
　以上、図２を参照して、第１の実施形態に係るシステム１の概要について説明した。以上説明したように、第１の実施形態では、共通化イベントメタ情報を用いることにより、互いに異なる複数の管理システムによってそれぞれ管理されているイベントが、共通のスキーマで管理される。従って、各管理システムで管理されているイベントを一括して扱うことができ、イベントの推薦の精度の向上や、ユーザにとってより利便性の高いチケットの購入方法が実現される。
　（２－２．システムの構成）
　図３及び図４を参照して、以上説明した第１の実施形態に係るシステム１の構成についてより詳細に説明する。図３は、第１の実施形態に係るシステム１の一構成例を示すブロック図である。図４は、図３に示す推薦部１３０の機能構成の一例を示す機能ブロック図である。
　図３を参照すると、第１の実施形態に係るシステム１は、情報処理装置１０と、イベント管理システムＸ２１０と、イベント管理システムＹ２２０と、イベント管理システムＺ２３０と、主催者プロファイル情報ＤＢ１４０と、入出力部１６０と、を備える。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、それぞれ、図２に示すイベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０に対応するものである。
　なお、図３では、一例として、イベント管理システムＸ２１０の会員であるユーザが、イベント管理システムＸ２１０を介してイベントを推薦され、イベント管理システムＸ２１０を介してイベントのチケットを購入する場合について説明する。ただし、第１の実施形態はかかる例に限定されず、イベント管理システムＹ２２０においても、イベント管理システムＹ２２０の会員に対して同様の処理が行われ得るし、イベント管理システムＺ２３０においても、イベント管理システムＺ２３０の会員に対して同様の処理が行われ得る。また、システム１を構成するイベント管理システムの数も図示する例に限定されず、任意の数のイベント管理システムによってシステム１が構成されてよい。
　（入出力部１６０）
　入出力部１６０は、システム１とイベントの主催者との間の入出力インターフェースである。主催者は、入出力部１６０を介して、システム１に対して各種の情報を入力することができる。また、システム１は、入出力部１６０を介して、主催者に対して各種の情報を出力（提示）することができる。入出力部１６０は、例えばＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）や、スマートフォン、タブレット端末等、主催者が所有する、情報の入出力機能を有するデバイスであってよい。
　例えば、主催者は、入出力部１６０を介して、後述する主催者プロファイル情報を入力する。入力された主催者プロファイル情報は、主催者プロファイル情報ＤＢ１４０に格納される。また、例えば、主催者は、入出力部１６０を介して、イベントメタ情報をイベント管理システムＸ２１０に入力する。入力されたイベントメタ情報は、後述するイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に格納される。なお、入出力部１６０におけるイベントメタ情報の入力画面の一例については、下記（２－４．表示例）で詳しく説明する。
　また、入出力部１６０は、主催者に対して、イベントのチケットの販売状況、過去のチケットの販売実績の分析データ、チケットの販売戦略等の各種の情報を提示することができる。なお、入出力部１６０の情報提示機能は、後述する情報処理装置１０の提示制御部１７０によって制御され得る。
　なお、入出力部１６０は、必ずしも情報処理装置１０と別個の装置によって構成されなくてもよく、情報処理装置１０と一体的に設けられてもよい。その場合、入出力部１６０は、情報処理装置１０に設けられる入力装置（例えば、マウス、キーボード、タッチパネル等）及び出力装置（ディスプレイ、スピーカ等）によって構成され得る。
　（主催者プロファイル情報ＤＢ１４０）
　主催者プロファイル情報ＤＢ１４０は、イベントの主催者についての情報である主催者プロファイル情報が格納されたデータベース（ＤＢ）である。例えば、主催者プロファイル情報は、主催者等を識別するための主催者ＩＤ、イベントＩＤ、各イベントに対する主催者の販売戦略を示す販売戦略情報、及び、各イベントの出演者のスケジュールや出来事を示す情報を含む。ここで、販売戦略情報は、例えば、各イベントの宣伝（プロモーション）の有無、宣伝の方法、宣伝の時期、チケットの料金の割引の有無及び割引率、イベントの参加者への特典の有無及び特典の内容等の情報を含む。なお、チケットの料金の割引の有無及び割引率は、チケット販売期間の残り期間とチケットの残り枚数に応じて変化するように設定されてもよい。また、特典の内容としては、例えば、握手券、サイン会の参加券、関連グッズのプレゼント、楽屋訪問、ＡＲ（Ａｕｇｍｅｎｔｅｄ　Ｒｅａｌｉｔｙ）を使ったプレミアムコンテンツのダウンロードの権利等が想定される。
　主催者プロファイル情報は、主催者によって、イベントごとに主催者プロファイル情報ＤＢ１４０に登録される。なお、第１の実施形態では、後述する推薦部１３０によって、共通化イベントメタ情報等に基づいて、販売戦略が決定され得る。主催者は、推薦部１３０によって決定された販売戦略情報を適宜修正することにより、主催者プロファイル情報ＤＢ１４０に登録する販売戦略情報を作成することができる。
　ここで、後述するように、システム１の情報処理装置１０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する機能を有し得る。第１の実施形態では、情報処理装置１０によって決定された販売戦略が、入出力部１６０を介して、主催者に対して提示されてよい。主催者は、提示された内容を参考にして、入出力部１６０を介して、販売戦略情報を入力することができる。情報処理装置１０による販売戦略の決定機能については、図４を参照して後で詳しく説明する。
　なお、主催者プロファイル情報ＤＢ１４０、並びに後述するイベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４、購入履歴情報ＤＢ２１５、共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３は、例えばＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス又は光磁気記憶デバイス等の各種の記憶デバイスによって構成される、各種の情報を記憶する記憶部の一形態である。
　（イベント管理システムＸ２１０）
　イベント管理システムＸ２１０は、その機能として、チケット販売システム２１１と、イベントメタ情報ＤＢ２１２と、空席情報ＤＢ２１３と、会員プロファイル情報ＤＢ２１４と、購入履歴情報ＤＢ２１５と、推薦イベント提示部２１６と、を有する。なお、イベント管理システムＸ２１０は、一般的に用いられている、各種の公知の管理システムと同様の構成であってよい。
　チケット販売システム２１１は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を用いて、イベントのチケットの販売や予約の管理を行う。イベント管理システムＸ２１０の会員であるユーザは、チケット販売システム２１１を介して、所望のイベントのチケットを購入することができる。
　例えば、チケット販売システム２１１は、Ｗｅｂサイト等を通じた電子的なチケットの販売に対応している。例えば、チケット販売システム２１１は、チケット販売店やコンビニエンスストア等の店頭に置かれる端末や、各ユーザのＰＣ、スマートフォン等の端末に、チケット販売用の画面やＷｅｂサイトを表示させて、チケットの販売サービスを提供する。
　チケット販売システム２１１は、イベントメタ情報ＤＢ２１２に格納されているイベントメタ情報に基づいて、イベント名や当該イベントの開催日時、会場、料金等をユーザに対して提示する。その際、チケット販売システム２１１は、空席情報ＤＢ２１３に格納されている空席情報を参照して、チケットの残り枚数や、席の指定が可能なイベントであれば会場内の空席の位置を、ユーザに対して併せて提示することができる。
　チケット販売システム２１１は、会員プロファイル情報ＤＢ２１４に格納されている会員プロファイル情報を参照することにより、自身に紐付けられているユーザ（図３に示す例であれば、イベント管理システムＸ２１０のＸ会員）に対して、チケットの販売を行う。チケットを購入したユーザは、ユーザＩＤによって管理され得る。
　チケット販売システム２１１は、チケットの販売状況等に応じて、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４及び購入履歴情報ＤＢ２１５の情報を逐次更新する。例えば、購入履歴情報ＤＢ２１５では、チケットが購入されたイベントのイベントメタ情報と、当該チケットを購入したユーザＩＤとが関連付けられて格納される。
　なお、チケット販売システム２１１としては、一般的に用いられている、各種の公知のシステムが適用されてよい。
　イベントメタ情報ＤＢ２１２は、チケット販売システム２１１が取り扱うイベントについての各種のメタ情報を格納する。例えば、イベントメタ情報は、イベントの名称、イベントを識別するためのイベントＩＤ、開催日時、会場、イベントの内容、出演者、料金等の情報を含む。また、イベントメタ情報は、イベント開催情報の公開開始日時、チケットの予約開始及び終了日時、チケットの販売開始及び終了日時等の情報を含んでもよい。イベントメタ情報には、その他、一般的にチケット販売システムにおいてイベントに関する情報として用いられ得る、あらゆる各種の情報が含まれ得る。なお、イベントメタ情報ＤＢ２１２内のイベントメタ情報は、イベントの主催者によって、イベントごとに、入出力部１６０を介して、イベント管理システムＸ２１０に登録される。
　以下、イベントメタ情報に含まれ得る情報について具体的に例示する。
　例えば、イベントメタ情報は、イベントの内容についての情報として、タイムテーブル、出演者の出演順や出演予定時刻、セットリスト、照明やセットの動き等の各イベントの進行や演出等に関する情報を含む。
　また、例えば、イベントメタ情報は、イベントの会場についての会場情報として、会場の種類、大きさ、席の配置、席の種類（Ｓ席、Ａ席、立見席、禁煙席、喫煙席等）、席の間隔、席の仕様（例えば、形、大きさ、材質等）、席の周囲の環境（例えば、出入口、通路、空調設備の位置等）等の情報を含む。また、会場情報は、例えば、会場内でイベントが行われる領域（イベント領域）、セット、楽器、講演台、司会台、照明、音響設備、機材の位置や仕様等の各イベント会場の設備やセッティングに関する情報を含む。更に、会場情報は、例えば、会場のセッティングが時系列で変化する場合には、当該セッティングの変化についての情報も含む。
　また、例えば、イベントが、当該イベントを撮影した映像が各ユーザに対して配信されるような、ユーザが直接会場に出向かないイベントである場合には、イベントメタ情報は、ユーザの仮想的な席と、配信する映像内のイベント領域の見え方との関係等、イベントを配信する際に必要となる各種の情報を含む。
　更に、イベントメタ情報は、例えば、出演者についての情報として、イベントの出演者の身体的特徴（例えば、身長、体型等）、動きやパフォーマンスの特徴、出演者の衣装等の情報を含む。
　なお、本明細書において、出演者は、イベントにおいて見られる対象となる人及び動物等を含むものとする。例えば、スポーツの選手、サーカスの動物等も出演者に含まれる。
　また、例えば、昼夜２公演のイベントや同じ会場で連日行われるイベント等、同様のイ
ベントが同じ会場で続けて行われる場合、イベント情報は各回のイベント毎に作成され、
保持される。また、例えば、ライブビューイング等の複数の会場で分散して行われるイベ
ントについては、会場毎に会場情報が作成され、保持される。
　空席情報ＤＢ２１３は、チケット販売システム２１１が取り扱うイベントの空席についての空席情報を格納する。例えば、空席情報には、会場を表す会場ＩＤ、当該会場での座席を表す座席ＩＤ、当該座席ＩＤが表す座席の会場内での位置についての情報等が含まれる。空席情報は、チケット販売システム２１１によって、イベントメタ情報に基づいて生成され、また、チケットの販売状況に応じてその内容が更新される。空席情報は、チケットの販売状況を表す情報であるとも言える。空席情報には、その他、一般的にチケット販売システムにおいてイベントでの空席を表す情報として用いられ得る、あらゆる各種の情報が含まれ得る。
　会員プロファイル情報ＤＢ２１４は、チケット販売システム２１１に登録されている会員についての会員プロファイル情報を格納する。例えば、会員プロファイル情報には、ユーザを表すユーザＩＤや、当該ユーザの性別、年齢、国籍、住所、職業、クレジットカード番号についての情報等が含まれる。
　また、会員プロファイル情報は、例えば、身長、座高、体型、視力、車椅子の使用の有無等の、ユーザの身体的特徴を含む。
　更に、会員プロファイル情報は、例えば、ユーザの嗜好に関する嗜好情報を含む。例えば、嗜好情報は、ユーザが好きなアーティスト、好きなグループのメンバー、好きなチーム、好きな選手、好きなイベントの種類、好きなジャンル、好き又は得意な楽器、好きなステージセット等の、ユーザのイベント（出演者を含む）に対する嗜好情報を含む。また、例えば、嗜好情報は、好きな会場、好きな席の位置、好きなイベント領域を見る角度、好きな席の種類、好きな席の仕様等のユーザの会場や席に対する嗜好情報を含む。
　また、会員プロファイル情報は、例えば、ユーザがチケットを購入する際の行動傾向に関する行動傾向情報を含む。ユーザの行動傾向とは、例えば、チケットの発売が開始された直後にチケットを買う傾向が強い（事前購入派）、又は、イベントの開催日直前にチケットを買う傾向が強い（直前購入派）等の、ユーザのチケット購入時の行動傾向である。なお、ユーザの行動傾向については、図５を参照して後で詳しく説明する。
　なお、上述した嗜好情報や行動傾向情報は、例えば購入履歴情報を分析することによって得ることができる。当該分析処理は、チケット販売システム２１１によって行われてもよいし、その他の構成（例えば後述する情報処理装置１０の推薦部１３０）によって行われてもよい。
　また、会員プロファイル情報は、例えば、ユーザのイベントの見方の特徴を示す見方特徴情報を含む。見方特徴情報は、例えば、騒ぐ、歌う、踊る、動きが激しい、笑う、泣く、手を叩く、静かに見る、座って見る、立って見る、寝る、声援を送る、奇声を上げる、ヤジを飛ばす、つぶやく、周囲と話す、コスプレをする、応援用のグッズを使う、貧乏ゆすりをする、アルコールを飲む、よく席を外す、遅れて参加する、途中で帰る等の情報を含む。
　なお、見方特徴情報は、ユーザの実際の特徴だけではなく、騒ぎたい、歌いたい、踊りたい等のユーザの希望を含んでいてもよい。また、イベントの種類や出演者ごとにユーザのイベントの見方が異なることを考慮して、イベントの種類や出演者毎に各ユーザの見方特徴情報を分けて持つようにしてもよい。
　なお、見方特徴情報は、例えば、各ユーザからのアンケートの回答に基づいて作成したり、イベント中の各ユーザの席付近の映像、画像、音声の解析結果に基づいて作成したりすることが可能である。また、例えば、ユーザ自身及びユーザの周囲の席の観客のイベントに関するソーシャルメディアへの投稿などをテキスト解析することにより、そのユーザの見方の特徴に関する情報を抽出し、見方特徴情報に反映させることも可能である。
　会員プロファイル情報には、その他、一般的にチケット販売システムにおいて会員についての情報として用いられ得る、あらゆる各種の情報が含まれ得る。
　購入履歴情報ＤＢ２１５は、チケット販売システム２１１に登録されている会員ごとの購入履歴情報を格納する。例えば、購入履歴情報ＤＢ２１５には、購入履歴情報として、ユーザＩＤ、購入回数、購入したイベントの会場、席種及び席の位置、イベントの種類（例えば、映画、演劇、コンサート、スポーツ等）、イベントの出演者等の情報が、互いに関連付けられて格納される。また、購入履歴情報は、例えば、同種のイベント（例えば、同じアーティストのコンサート等）のチケットを繰り返し購入する、幅広いジャンルのチケットを購入する、滅多に購入しない等の各ユーザの購入パターンを示す情報を含んでもよい。また、購入履歴情報は、ユーザに対して推薦したイベントと、当該イベントに対するユーザの行動（当該イベントのチケットを買ったか否か）についての情報を含んでもよい。更に、購入履歴情報は、販売期間内におけるチケットの購入時期についての情報を含んでもよい。なお、チケットの購入だけでなく、例えば、各ユーザがイベントに関する情報を閲覧したり、チケットの購入を検討するためにブックマーク等を付加した等の履歴も購入履歴情報に含めるようにしてもよい。
　購入履歴情報に含まれるこれらの情報に基づいて、上述した嗜好情報や行動傾向情報が抽出され得る。このように、購入履歴情報に基づいて会員プロファイル情報が更新されてよい。なお、購入履歴情報ＤＢ２１５に格納される情報はかかる例に限定されず、購入履歴情報ＤＢ２１５は、一般的にチケット販売システムにおいて会員の購入履歴情報として格納され得るあらゆる各種の情報を記憶してもよい。
　推薦イベント提示部２１６は、後述する情報処理装置１０の推薦部１３０によって決定されたユーザ（図３に示す例であればイベント管理システムＸの会員）に対して、推薦すべきイベントを提示することにより、当該ユーザに対して当該イベントの宣伝を行う。例えば、推薦イベント提示部２１６は、イベントの広告を、チケット販売システム２１１のチケット販売画面等に、ユーザへのお薦めのイベントとして表示する。また、例えば、推薦イベント提示部２１６は、イベントについての情報を、ユーザへのお薦めのイベントとして、電子メール等によって当該ユーザに対して配信する。なお、推薦イベント提示部２１６は、例えばＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）やＤＳＰ（Ｄｉｇｉｔａｌ　Ｓｉｇｎａｌ　Ｐｏｃｅｓｓｏｒ）等の各種のプロセッサによって構成され、推薦イベント提示部２１６の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。
　（情報処理装置１０）
　情報処理装置１０は、その機能として、スキーマ変換部１１０と、共通化イベントメタ情報ＤＢ１２１と、共通化空席情報ＤＢ１２２と、共通化会員プロファイル情報ＤＢ１２３と、推薦部１３０と、提示制御部１７０と、を有する。なお、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０は、例えばＣＰＵやＤＳＰ等の各種のプロセッサによって構成され、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。
　提示制御部１７０は、主催者がシステム１に対して各種の情報の入出力を行うインターフェースである入出力部１６０における情報の提示を制御する。提示制御部１７０は、入出力部１６０に各種の情報を表示させることにより、当該情報を主催者に対して提示する。例えば、提示制御部１７０は、推薦部１３０によって決定されるイベントの販売戦略についての情報を、入出力部１６０を介して主催者に対して提示する。提示制御部１７０は、その他にも、イベントのチケットの販売状況、過去のチケットの販売実績の分析データ等、主催者が所望する各種の情報を、入出力部１６０を介して主催者に提示してもよい。
　スキーマ変換部１１０は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を、共通のスキーマに変換する。具体的には、スキーマ変換部１１０は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を、共通のＩＤ体系で管理できるように変換する。上記（１．一般的なシステムについて）で説明したように、一般的に、イベントを管理する管理システムが異なれば、管理される情報のスキーマが異なる。第１の実施形態では、スキーマ変換部１１０によって、互いに異なる管理システムで管理されている情報が、共通のスキーマに変換されることにより、これらの情報を一括して管理することが可能となるのである。
　スキーマ変換部１１０によってスキーマ変換された、イベントメタ情報ＤＢ２１２内のイベントメタ情報は、共通化イベントメタ情報として共通化イベントメタ情報ＤＢ１２１に格納される。スキーマ変換部１１０によってスキーマ変換された、空席情報ＤＢ２１３内の空席情報は、共通化空席情報として共通化空席情報ＤＢ１２２に格納される。スキーマ変換部１１０によってスキーマ変換された、会員プロファイル情報ＤＢ２１４内の会員プロファイル情報は、共通化会員プロファイル情報として共通化会員プロファイル情報ＤＢ１２３に格納される。
　共通化イベントメタ情報ＤＢ１２１は、共通のスキーマに変換されたイベントメタ情報（共通化イベントメタ情報）を格納する。例えば、共通化イベントメタ情報は、イベントの名称、イベントの出演者、イベントのジャンル、イベントが開催される会場、イベントに関する日時（開催日時、イベント開催情報の公開開始日時、予約開始及び終了日時、チケット販売開始及び終了日時等）、チケットの料金（チケット価格、入場料等）、イベントの内容（概要文、イベント紹介用の画像又は動画、出演者やイベントに対するレビュー、イベントの詳細情報を掲載したＷｅｂサイトのＵＲＬ等）等の項目についての情報の一部又は全てを含む。ここで、例えば出演者についての情報、イベントのジャンルについての情報及びイベントが開催される会場についての情報は、それぞれ、共通のＩＤ（共通化出演者ＩＤ、共通化ジャンルＩＤ、共通化会場ＩＤ）によって管理されている。また、その他の情報も、共通のフォーマットで管理されている。このように、共通化イベントメタ情報ＤＢ１２１には、元々は互いに異なる管理システムにおいて互いに異なるスキーマで登録されていたイベントメタ情報が、共通のスキーマで格納される。
　共通化空席情報ＤＢ１２２は、共通のスキーマに変換された空席情報（共通化空席情報）を格納する。例えば、共通化空席情報は、イベントの空席情報（例えば残っている席の座席区分、座席番号、価格等についての情報）を含む。
　共通化会員プロファイル情報ＤＢ１２３は、共通のスキーマに変換された会員プロファイル情報（共通化会員プロファイル情報）を格納する。共通化会員プロファイル情報は、例えば、ユーザＩＤについての情報を含む。これにより、各管理システムによって管理されていたユーザＩＤが共有されることとなる。ただし、各管理システムにおけるユーザＩＤが共通化されたとしても、当該ユーザＩＤは各管理システムにおいて互いに異なるものであるため、第１の実施形態では、それらのユーザＩＤが示す会員が同一のユーザかどうかまでは判断することができない。また、共通化会員プロファイル情報は、上述した嗜好情報、傾向情報、見方特徴情報を含んでもよい。
　推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する。換言すれば、推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントを推薦すべきユーザを選択したり、ユーザに対して推薦すべきイベントを選択したりする。推薦部１３０は、図２に示す共通予測エンジン１５０に対応する機能を有する。
　具体的には、推薦部１３０は、各管理システムの購入履歴情報ＤＢ２１５内の購入履歴情報を、共通化イベントメタ情報に紐付けることにより、各管理システムの購入履歴情報を総合的に利用して、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。そして、推薦部１３０は、生成した予測モデルに基づいて、推薦するイベントとユーザの組み合わせを決定する。
　推薦部１３０は、決定されたユーザが会員として登録されている管理システムの推薦イベント提示部に対して、決定したイベントとユーザとの組み合わせについての情報を送信する。図３に示す例では、決定されたユーザがイベント管理システムＸ２１０の会員であり、イベント管理システムＸ２１０の推薦イベント提示部２１６に対して決定したイベントとユーザとの組み合わせについての情報が送信される場合について図示している。
　推薦イベント提示部２１６は、選択されたユーザに対して、選択されたイベントを提示する。例えば、推薦イベント提示部２１６は、選択されたユーザに紐付けられたチケット購入画面（例えば、当該ユーザがログインした状態でのチケット購入画面等）のお薦め欄や広告欄に、選択されたイベントについての情報を表示させる。
　ここで、推薦部１３０によって決定されるイベントとユーザとの組み合わせは、例えば、共通化イベントメタ情報と共通化されたユーザＩＤとで表現されている。従って、イベントとユーザとの組み合わせについての情報が、推薦部１３０から推薦イベント提示部２１６に送信される際には、これらの情報は、スキーマ変換部１１０を介して、提示する対象である管理システム（図３に示す例であればイベント管理システムＸ２１０）のスキーマに変換される。これにより、イベント管理システムＸ２１０の推薦イベント提示部２１６では、元々のイベント管理システムＸ２１０のスキーマで、イベントメタ情報及びユーザＩＤを扱うことが可能となる。
　なお、第１の実施形態では、イベント管理システムＸ２１０の会員に提示されるイベントは、必ずしも、イベント管理システムＸ２１０によって管理されているイベントでなくてもよい。このように、第１の実施形態では、イベントメタ情報が、共通化イベントメタ情報として一括して管理されることにより、一の管理システムによって管理されているイベントを他の管理システムの会員に対して提示することも可能である。
　また、推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する機能を更に有してもよい。決定された販売戦略についての情報は提示制御部１７０に提供され、提示制御部１７０によって、入出力部１６０を介して主催者に対して提示される。
　ここで、図４を参照して、推薦部１３０の機能構成についてより詳細に説明する。図４を参照すると、推薦部１３０は、その機能として、主催者プロファイル情報取得部１３１と、共通化情報取得部１３２と、購入履歴情報取得部１３３と、予測モデル生成部１３４と、イベント－ユーザ決定部１３５と、販売戦略決定部１３６と、を有する。ここで、図４では、説明のため、推薦部１３０と情報をやり取りする構成として、主催者プロファイル情報ＤＢ１４０、共通化情報ＤＢ１２０、購入履歴情報ＤＢ２１５、スキーマ変換部１１０及び提示制御部１７０を併せて図示している。なお、共通化情報ＤＢ１２０は、図面が煩雑になることを避けるために、図３に示す共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３を併せて１つのブロックとして図示したものである。
　主催者プロファイル情報取得部１３１は、主催者プロファイル情報ＤＢ１４０から主催者プロファイル情報を取得する。主催者プロファイル情報取得部１３１は、取得した主催者プロファイル情報を、予測モデル生成部１３４、イベント－ユーザ決定部１３５及び販売戦略決定部１３６に提供する。
　共通化情報取得部１３２は、共通化情報ＤＢ１２０から共通化情報を取得する。共通化情報取得部１３２は、取得した共通化情報を、予測モデル生成部１３４、イベント－ユーザ決定部１３５及び販売戦略決定部１３６に提供する。
　購入履歴情報取得部１３３は、購入履歴情報ＤＢ２１５から購入履歴情報を取得する。購入履歴情報取得部１３３は、取得した購入履歴情報を、予測モデル生成部１３４、イベント－ユーザ決定部１３５及び販売戦略決定部１３６に提供する。なお、図４では、一の購入履歴情報ＤＢ２１５（例えば図３に示すイベント管理システムＸ２１０の購入履歴情報ＤＢ２１５）しか図示していないが、購入履歴情報取得部１３３は、イベント管理システムＹ２２０及びイベント管理システムＺ２３０の購入履歴情報ＤＢ２１５からも、同様に、購入履歴情報を取得する。
　販売戦略決定部１３６は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する。販売戦略決定部１３６によって決定される販売戦略には、上記で主催者プロファイル情報ＤＢ１４０について説明した際に言及した各種の項目が含まれてよい。
　ここで、第１の実施形態では、販売戦略決定部１３６は、好適に、チケットの販売期間及び販売数に応じた宣伝戦略（広告戦略）を決定する。当該宣伝戦略には、例えば、販売期間及び販売数に応じたイベントの宣伝量、販売期間及び販売数に応じたイベントの宣伝時期、販売期間及び販売数に応じたイベントの宣伝を行うユーザの属性、販売期間及び販売数に応じたイベントの宣伝の費用対効果についての情報等が含まれる。定量商材であるイベントでは、チケットの販売期間及び販売数が制限されているため、このような、販売期間や販売数に応じた細やかな宣伝戦略が設定されることにより、より的確な宣伝が可能にある。
　例えば、販売戦略決定部１３６は、共通化イベントメタ情報に含まれるイベントの種類についての情報や、購入履歴情報に含まれる過去のチケットの販売実績についての情報等に基づいて、上述したような宣伝戦略を決定することができる。例えば、音楽系のイベントは、単発又は公演数が少ないものが多く、事前にチケットが売り切れるものが多い。従って、音楽系イベントについては、チケット発売日時に近い時期により多くの宣伝が行われることが好ましい。一方、演劇系のイベントは、所定の期間内に繰り返し開催されることが多く、開催直前でもチケットが残っていることが多い。そのため、演劇系イベントについては、チケット発売日時に近い時期及びイベントの開催日時に近い時期の、両方の時期により多くの宣伝が行われることが好ましい。このように、イベントの種類に応じて、チケットが購入される時期に明確な傾向が現れる場合には、当該傾向を考慮して宣伝の時期等が決定され得る。
　また、例えば、販売戦略決定部１３６は、チケットの発売開始日時に近い時期にはより多くのユーザに対して宣伝を行い、チケットの発売終了日時が近付くにつれて、よりそのイベントに興味を抱いていることが推測されるユーザに対して宣伝を行うように、宣伝戦略を決定してもよい。チケットの発売終了日時が近い時期には、チケットの売れ残りを極力少なくするために、チケットを購入する可能性がより高いユーザに対してピンポイントで宣伝を行うことが効果的であると考えられるからである。
　また、例えば、販売戦略決定部１３６は、チケットの販売期間の残り期間、チケットの残り枚数、及びそのイベントに興味を抱いていることが推測されるユーザの数やその興味の度合い等に基づいて、宣伝を行うことによってチケットが購入される確率を計算し、宣伝の費用対効果を計算してもよい。費用対効果が主催者に対して示されることにより、主催者が宣伝を行う時期や宣伝量を決定する際の指針となり得る。
　また、例えば、販売戦略決定部１３６は、共通化会員プロファイル情報に含まれるユーザの行動傾向情報に更に基づいて、宣伝戦略を決定してもよい。
　ここで、図５を参照して、このような、ユーザの行動傾向情報に基づく販売戦略の決定処理について詳しく説明する。図５は、ユーザの行動傾向情報に基づく販売戦略の決定処理について説明するための説明図である。
　図５では、横軸に時間を取り、縦軸にユーザがチケットを購入する確率を取り、ユーザの購入確率の時間的な変化を概略的に図示している。なお、図５に示すような購入確率分布は、ユーザのチケット購入の実績をヒストグラムとして表し、当該ヒストグラムに基づいて、ガウス分布等の当該ヒストグラムの性質に応じた適切な確率分布を推定することにより得ることができる。
　図５（ａ）は、事前購入派のユーザ１の購入確率分布の一例を図示している。ユーザ１は、チケットの発売開始日時の直後にチケットを購入する確率が高い。従って、ユーザ１は、チケットの発売開始前から、興味のあるイベントの情報をチェックしている可能性が高い。よって、販売戦略決定部１３６は、ユーザ１に対しては、チケット発売開始前からイベントの宣伝を行うような販売戦略を好適に決定する。
　一方、図５（ｂ）は、直前購入派のユーザ２の購入確率分布の一例を図示している。ユーザ２は、イベントの開催日直前にチケットを購入する確率が高い。従って、ユーザ２に対して、チケットの発売開始前からイベントの宣伝をしてもその効果は小さいと考えられる。よって、販売戦略決定部１３６は、ユーザ２に対しては、チケット発売開始日からしばらく経過した後にイベントの宣伝を行うような販売戦略を好適に決定する。
　このように、ユーザの行動傾向情報に基づいて販売戦略が決定されることにより、より適切なタイミングでイベントの宣伝を行うことが可能となる。
　販売戦略決定部１３６は、決定した販売戦略についての情報を、提示制御部１７０に提供する。当該販売戦略についての情報は、提示制御部１７０によって主催者に対して提示される。主催者は、提示された情報を参考にして、最終的な販売戦略を決定し、主催者プロファイル情報として、主催者プロファイル情報ＤＢ１４０に入力することができる。提示制御部１７０は、例えば、販売戦略決定部１３６によって決定された販売戦略を、主催者がより容易に、より直感的に修正できるような設定画面を、入出力部１６０に表示させてもよい。
　なお、販売戦略決定部１３６は、複数の販売戦略を決定してもよく、それら複数の販売戦略が、提示制御部１７０によって主催者に対して提示されてもよい。この場合、主催者は、提示された販売戦略の候補の中から、自身の意図に最も沿った販売戦略を選択することができる。
　予測モデル生成部１３４は、共通化イベントメタ情報と、購入履歴情報と、に基づいて、推薦するイベントとユーザとの組み合わせを選択するための予測モデルを生成する。具体的には、予測モデル生成部１３４は、各管理システムの購入履歴情報ＤＢ２１５内の購入履歴情報を、共通化イベントメタ情報に紐付ける。当該紐付け処理により、互いに異なる複数の管理システムにおける購入履歴情報が、共通化イベントメタ情報と関連付けられて一括して扱えるようになる。推薦部１３０は、共通化イベントメタ情報と関連付けられた購入履歴情報に基づいて、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。当該予測モデルは、互いに異なる複数の管理システムにおける購入履歴情報を総合的に利用して生成されるものであるため、一の管理システムの購入履歴情報を用いて生成される予測モデルよりも、予測の精度が優れていると言える。
　ここで、予測モデルとしては、公知の各種の予測モデルが用いられてよい。例えば、予測モデルは、協調フィルタモデルであってよい。協調フィルタモデルでは、嗜好が類似する他のユーザの購入履歴情報を用いて、対象とするユーザが興味を有していると思われるイベントが予測される。予測モデルが協調フィルタモデルである場合、購入履歴情報に関連付けられた共通化イベントメタ情報を用いて、協調度を表す特徴量が算出され得る。
　また、例えば、予測モデルでは、ベクトルマッチングを用いた手法が適用されてもよい。当該手法では、ユーザの購入履歴情報に含まれる共通化イベントメタ情報をベクトル化し、特徴量ごとに頻度を重ねる。これにより、ユーザの興味の対象を示すユーザベクトルが生成され得る。そして、あるイベントの共通化イベントメタ情報から求められた、当該イベントの特徴量を示すベクトルと、ユーザの購入履歴情報から得られたユーザベクトルとの間でベクトルマッチングを行い、その距離を、コサイン距離、ユークリッド距離等で算出する。当該距離が近いユーザほど、当該イベントに対して興味を抱いているユーザであると言える。
　また、予測モデル生成部１３４は、共通化会員プロファイル情報に含まれる行動傾向情報や嗜好情報、見方特徴情報に更に基づいて予測モデルを生成してもよい。これにより、よりユーザの性向が反映された予測モデルを生成することが可能となる。また、予測モデル生成部１３４は、主催者プロファイル情報に含まれる販売戦略情報に更に基づいて予測モデルを生成してもよい。当該販売戦略情報は、販売戦略決定部１３６によって決定され、主催者によって修正されたものであり得る。これにより、イベントの種類や過去の販売実績を踏まえつつ、より主催者のチケット販売の意図が反映された予測モデルを生成することが可能となる。なお、主催者からの明示的な販売戦略の指示がなかった場合には、予測モデル生成部１３４は、販売戦略決定部１３６によって決定された販売戦略に基づいて予測モデルを生成してもよい。
　また、予測モデル生成部１３４は、行動傾向情報と販売戦略情報とを組み合わせて、予測モデルを生成してもよい。例えば、図５（ａ）に示すような事前購入派であるユーザに対しては、販売戦略として発売開始直後に多くのチケットを売ろうとしているイベントを推薦することにより、当該イベントのチケットの購入をより促すことができると考えられる。従って、予測モデル生成部１３４は、当該ユーザに対しては、チケットの発売開始日に近い時期に多くのチケットを販売するような販売戦略が設定されているイベントを推薦するような予測モデルを好適に生成することができる。一方、図５（ｂ）に示すような直前購入派であるユーザに対しては、販売戦略としてイベントの開催直前に多くのチケットを売ろうとしているイベントを推薦することにより、当該イベントのチケットの購入をより促すことができると考えられる。従って、予測モデル生成部１３４は、当該ユーザに対しては、開催日の直前に多くのチケットを販売するような販売戦略が設定されているイベントを推薦するような予測モデルを好適に生成することができる。
　予測モデル生成部１３４は、生成した予測モデルを、イベント－ユーザ決定部１３５に提供する。
　イベント－ユーザ決定部１３５は、予測モデルを用いて、推薦するイベントとユーザの組み合わせを決定する。具体的には、イベント－ユーザ決定部１３５は、予測モデルを用いてイベントとユーザとのマッチングを行い、推薦対象であるイベントに興味を抱いていると思われるユーザを選択する（あるいは、逆に、推薦対象であるユーザが興味を抱いていると思われるイベントを選択する）。共通化情報として、共通化イベントメタ情報及び共通化会員プロファイル情報が取得されているため、イベント－ユーザ決定部１３５は、各イベント管理システムによってそれぞれ管理されているイベント及び会員を総合して、横断的にイベントとユーザとのマッチングを行うことができる。
　なお、イベント－ユーザ決定部１３５は、共通化空席情報に基づいて、席まで考慮して、イベントとユーザとのマッチングを行ってもよい。例えば、購入履歴情報や、共通化会員プロファイル情報に含まれる嗜好情報に基づいて、ユーザが好んで座る席が分かる場合には、イベント－ユーザ決定部１３５は、予測モデルを用いるとともに、ユーザが好んで座る席に近い席が空席であるイベントを、当該ユーザに対して推薦すべきイベントとして選択してもよい。
　また、イベント－ユーザ決定部１３５は、共通化会員プロファイル情報に含まれるその他の嗜好情報や、見方特徴情報、ユーザの身体的特徴を示す情報等に基づいて、ユーザに適したイベントを選択することもできる。
　また、イベント－ユーザ決定部１３５は、主催者プロファイル情報に含まれる主催者ＩＤ（すなわち管理システムを表すＩＤ）に基づいて、所定の主催者ＩＤの管理システムの会員のみをマッチングの対象としてもよい。このように、第１の実施形態では、イベントを提示する対象となるユーザを、いずれかの管理システムの会員のみに制限することができる。当該設定は、主催者プロファイル情報を登録する際に、主催者によって行われてよい。
　イベント－ユーザ決定部１３５は、決定したイベント及びユーザの組み合わせについての情報を、スキーマ変換部１１０に提供する。
　ここで、イベント－ユーザ決定部１３５によって決定されるイベントとユーザとの組み合わせは、例えば、共通化イベントメタ情報と共通化されたユーザＩＤとで表現されている。スキーマ変換部１１０は、決定されたイベント及びユーザの組み合わせについての情報に基づいて、当該イベントの共通化イベントメタ情報及び当該ユーザを表す共通化されたユーザＩＤを、それぞれ、提示の対象としているイベント管理システムのスキーマに変換し直す。ここで、提示の対象としているイベント管理システムは、決定されたユーザが会員として登録されている管理システムである。スキーマ変換が再度行われることにより、イベント及びユーザを、各イベント管理システムのスキーマで扱うことが可能となる。各イベント管理システムでは、例えば図３に示す推薦イベント提示部２１６により、選択されたイベントの宣伝を、選択されたユーザに対して提示することができる。また、各イベント管理システムでは、ユーザの操作に応じて、ユーザに対して提示されたイベントのチケットを販売することもできる。
　ここで、第１の実施形態では、イベント－ユーザ決定部１３５は、ある管理システムにおいて管理されているイベントを推薦するユーザとして、他の管理システムの会員を選択することができる。例えば、イベント管理システムＹ２２０で管理されているイベントＹを推薦するユーザとして、イベント管理システムＸ２１０の会員であるユーザが選択され得る。この場合には、イベントＹのイベントメタ情報は、共通化イベントメタ情報に変換された後、イベント管理システムＸ２１０で管理可能なスキーマに再変換される。これにより、イベントＹをイベント管理システムＸ２１０で扱うことが可能となる。第１の実施形態では、イベントメタ情報及び会員プロファイル情報が共通化され、情報処理装置１０によって総合的に管理され得ることにより、このような、異なる管理システム間での、ユーザとイベントとのマッチングが可能となるのである。
　また、第１の実施形態では、一の管理システムで管理しているイベントを、スキーマ変換によって他の管理システムのＤＢに格納することにより、当該イベントのチケットの販売を当該他の管理システムが行うことも可能である。例えば、上記の例であれば、元々イベント管理システムＹ２２０で管理されていたイベントＹを、イベント管理システムＸ２１０を介して推薦された、イベント管理システムＸ２１０の会員であるユーザは、イベント管理システムＸ２１０を介して、当該イベントＹのチケットの購入を行うことができる。この際、当該ユーザは、異なるイベント管理システムで管理されているイベントであることを意識することなく、イベントの宣伝の視聴や、チケットの購入を行うことができる。このように、第１の実施形態によれば、より自由度が高く、ユーザにとって利便性の高い、イベントの推薦やチケットの購入が実現され得る。
　以上、図３及び図４を参照して、第１の実施形態に係るシステム１の構成について説明した。以上説明したように、第１の実施形態によれば、互いに異なる複数の管理システムによって管理されているイベントメタ情報が共通のスキーマに変換されることにより、これらのイベントメタ情報を総合的に扱うことが可能となる。従って、当該複数の管理システムの購入履歴情報も総合的に扱うことができ、予測エンジンの精度を向上させることができる。よって、より適切に、推薦するイベントとユーザとのマッチングが行われることとなる。また、イベントメタ情報が共通化されることにより、イベントメタ情報をイベントのチケットの購入がより促進され、チケットの売り主である主催者の利便性が向上する。
　また、共通化されたイベントメタ情報を、各管理システムのスキーマに変換し直すことにより、元々は一の管理システムによって管理されていたイベントを、他の管理システムにおいても扱うことが可能となる。すなわち、管理システム間でイベントメタ情報を相互に利用することができる。従って、イベントの推薦のマッチングの対象であるユーザが、全ての管理システムの会員に拡張されるため、チケットの購入層が広がり、チケットの購入が更に促進される。
　また、上記のように、各管理システム間でイベントメタ情報が相互に利用可能となることにより、イベントのチケットの販売を、いずれの管理システムでも行うことが可能となるため、会員であるユーザの利便性が向上する。
　なお、情報処理装置１０の装置構成は、図３及び図４に示す例に限定されない。例えば、図３及び図４に示す情報処理装置１０の各機能は、必ずしも１つの装置に一体的に搭載されなくてもよい。図３及び図４に示す情報処理装置１０に搭載される各機能が、複数の装置に分散されて搭載され、当該複数の装置が通信可能に接続されることにより、情報処理装置１０が構成されてもよい。例えば、各ＤＢは、情報処理装置１０とは異なる外部の機器として備えられてもよく、情報処理装置１０が、外部機器であるこれらＤＢと通信を行いながら、上述した各種の処理を実行してもよい。
　また、上述のような第１の実施形態に係る情報処理装置１０の機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
　（２－３．情報処理方法）
　図６を参照して、図３に示すシステム１において実行される、第１の実施形態に係る情報処理方法について説明する。図６は、第１の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。なお、以下では、図３に示すシステム１において、イベント管理システムＸ２１０によって管理されているイベントＳがユーザ（イベント管理システムＸ２１０の会員）に対して推薦される場合を例に挙げて、情報処理方法についての説明を行う。
　図６を参照すると、第１の実施形態に係る情報処理方法では、まず、主催者によって、イベントＳのイベントメタ情報及び主催者プロファイル情報が登録される（ステップＳ１０１）。具体的には、ステップＳ１０１に示す処理では、イベントＳのイベントメタ情報及び主催者プロファイル情報が、入出力部１６０を介して、それぞれ、イベントメタ情報ＤＢ２１２及び主催者プロファイル情報ＤＢ１４０に格納される。
　次に、イベントＳのイベントメタ情報及び空席情報と、イベント管理システムＸ２１０の会員プロファイル情報と、が、共通のスキーマに変換される（ステップＳ１０３）。具体的には、ステップＳ１０３に示す処理では、イベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報が、共通のスキーマに変換され、共通化情報（すなわち、共通化イベントメタ情報、共通化空席情報及び共通化会員プロファイル情報）が生成される。同様に、他の管理システムのイベントメタ情報、空席情報及び会員プロファイル情報も、共通のスキーマに変換される。ステップＳ１０３に示す処理は、例えば図３に示すスキーマ変換部１１０によって行われる処理に対応している。
　次に、共通化イベントメタ情報及び購入履歴情報に基づいて、販売戦略が決定される（ステップＳ１０４）。当該販売戦略は、例えば、イベントの種類や、過去の同種のイベントの販売実績等に基づいて決定され得る。図示は省略するが、決定された販売戦略は主催者に対して提示され、主催者によって最終的な販売戦略が決定される。ステップＳ１０４に示す処理は、例えば図４に示す販売戦略決定部１３６によって行われる処理に対応している。
　次に、共通化イベントメタ情報及び購入履歴情報に基づいて、予測モデルが生成される（ステップＳ１０５）。当該予測モデルは、例えば、イベントの種類や、ユーザの購入履歴等を考慮して、イベントＳを推薦すべきユーザを予測するためのモデルである。ステップＳ１０５に示す処理は、例えば図４に示す予測モデル生成部１３４によって行われる処理に対応している。
　次に、生成された予測モデルに基づいて、イベントＳにマッチするユーザが選択される（ステップＳ１０７）。ステップＳ１０７に示す処理は、例えば図４に示すイベント－ユーザ決定部１３５によって行われる処理に対応している。ここでは、例えば、イベント管理システムＸ２１０の会員であるユーザが選択されたとする。
　次に、イベントＳと選択されたユーザについての情報が、当該ユーザが登録されているイベント管理システムＸ２１０に送信される（ステップＳ１０９）。なお、ステップＳ１０９に示す処理では、送信される情報は、送信先のイベント管理システムＸ２１０に対応したスキーマに変換される。ステップＳ１０７に示すスキーマ変換処理は、例えば図３に示すスキーマ変換部１１０によって実行され得る。
　次に、選択されたユーザに対して、イベントＳが提示される（ステップＳ１１１）。ステップＳ１１１に示す処理は、例えば図３に示す推薦イベント提示部２１６によって行われる処理に対応している。例えば、ユーザに対して表示されるチケット購入画面等においてお薦めのイベントとしてイベントＳの情報が表示されたり、当該チケット購入画面内の広告領域にイベントＳの情報が表示されたりしてよい。
　次に、ユーザの購入行動に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の購入履歴情報が更新される（ステップＳ１１３）。なお、ステップＳ１１３に示す処理では、ユーザが、ステップＳ１１１に示す処理において提示されたイベントＳの広告を見て当該イベントＳのチケットを購入した場合はもちろんのこと、他のユーザの購入行動も、空席情報ＤＢ２１３内の空席情報及び購入履歴情報ＤＢ２１５内の購入履歴情報に反映され得る。
　次に、オフラインでの購入実績に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の購入履歴情報が更新される（ステップＳ１１５）。ここで、オフラインでの購入実績とは、例えば会場の窓口でのチケットの購入実績等、システム１では直接検知できない購入実績である。ステップＳ１１５に示す処理は、例えば、オフラインでのチケットの売り上げを把握し得る主催者等によって行われる。
　なお、図６では、便宜的に、ステップＳ１１３に示す処理及びステップＳ１１５に示す処理をこの順序で図示しているが、これらの処理は、システム１において随時実行される処理であるため、その順序は任意であってよい。
　ステップＳ１１５に示す処理が終了すると、ステップＳ１０３に戻り、更新された空席情報及び購入履歴情報に基づいて、ステップＳ１０３以降の処理が繰り返し実行される。なお、図６に示すフロー図では明示していないが、実際には、例えば売り上げ実績に応じた主催者プロファイル情報内の販売戦略情報の変更や、新規会員の登録及び既存会員の退会等による会員プロファイル情報の変更、イベント内容の変更に伴うイベントメタ情報の変更等も随時行われ得る。図６に示すフローにおいては、このような主催者プロファイル情報、イベントメタ情報及び会員プロファイル情報の変更も適宜実行されてよい。その場合、変更されたこれらの情報に基づいて、各ステップに示す処理が実行され得る。また、ステップＳ１０５に示す予測モデルの生成処理は、図６に示す一連の処理が実行される際に、毎回行われなくてもよい。例えば、１週間に１度、あるいは一定量の購入履歴情報が更新されたタイミングで、ステップＳ１０５に示す処理が行われ、予測モデルが更新されてもよい。
　以上、図６を参照して、第１の実施形態に係る情報処理方法について説明した。
　（２－４．表示例）
　図３を参照して説明したように、第１の実施形態に係るシステム１では、主催者は、入出力部１６０を介してイベントメタ情報や主催者プロファイル情報等を入力することができる。このような、本システム１に必要な情報を一括して入力可能な入出力インターフェースを提供することにより、主催者の利便性を向上させることができる。
　図７を参照して、当該入出力部１６０における一表示例について説明する。図７は、主催者によって各種の情報が入力される情報入力画面の一表示例を示す図である。
　図７に示す表示画面３１０は、例えば図３に示す入出力部１６０の表示画面に対応している。主催者は、当該表示画面３１０を介して各種の情報をシステム１に入力することができる。なお、図７に示す表示画面３１０は、主催者に提供される情報入力画面のあくまで一例であり、当該情報入力画面は他の構成を有していてもよい。
　図７を参照すると、表示画面３１０は、主にイベント情報が登録される領域３１１、主にチケットの販売サイトについての情報が登録される領域３１２及びユーザに提示されるイベントの広告についての情報が登録される領域３１３に分割される。
　領域３１１では、例えば、イベントの名称（タイトル）、イベントの出演者（アーティスト）、イベントの会場、イベントの開催日時等の情報を、ドロップダウンリスト形式で入力することができる。これらの情報は、イベントメタ情報として、例えば図３に示すイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に登録される。なお、領域３１１及び後述する他の領域３１２、３１３において、情報の入力形式はドロップダウンリスト形式に限定されず、各種の情報は直接テキストで入力されてもよい。また、領域３１１では、例示する項目以外にも、イベントに関する各種の情報が入力されてよい。
　領域３１２では、例えば、チケットの販売サイト名、各販売サイトでのチケット販売開始日時、各販売サイトでのチケット販売終了日時、各販売サイトでのチケット販売地域、各販売サイトでのチケット販売枚数、各販売サイトでのチケット販売戦略等の情報を、プルダウン形式で入力することができる。チケットの販売開始日時、販売終了日時、販売地域、販売枚数についての情報は、イベントメタ情報として、例えば図３に示すイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に登録される。また、チケットの販売戦略についての情報は、主催者プロファイル情報として、例えば図３に示す主催者プロファイル情報ＤＢ１４０に登録される。なお、領域３１２では、例示する項目以外にも、販売サイトごとに設定可能な各種の情報が入力されてよい。
　また、領域３１２には、図４に示す販売戦略決定部１３６によって決定された販売戦略についての情報が表示されてもよい。主催者は、当該表示された情報を参考にして、販売戦略情報を入力することができる。また、領域３１２において、表示された販売戦略決定部１３６によって決定された販売戦略を修正することが可能なＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）が提供されてもよい。
　領域３１３では、例えば、ユーザに対してイベントを提示する際の、広告のレイアウトや、当該レイアウトの変更権を入力することができる。なお、領域３１３では、例示する項目以外にも、イベントの広告に関する各種の情報が入力されてよい。
　以上、図７を参照して、主催者によって各種の情報が入力される情報入力画面の一表示例について説明した。
　（２－５．変形例）
　次に、第１の実施形態の一変形例について説明する。上記（２－１．システムの概要）で説明したように、第１の実施形態に係るシステム１は、共通予測エンジン１５０が設けられ、各管理システムにおいてユーザに推薦されるイベントを、当該共通予測エンジン１５０が決定していた。ただし、第１の実施形態に係るシステム１は、かかる例に限定されず、他の構成を取ってもよい。例えば、各管理システムの予測エンジンが、それぞれ、共通予測エンジン１５０として振る舞ってもよい。
　図８を参照して、第１の実施形態の一変形例として、各管理システムに予測エンジンが設けられる変形例について説明する。図８は、各管理システムに予測エンジンが設けられる変形例に係るシステムの概要を示す図である。なお、本変形例に係るシステムは、第１の実施形態に係るシステム１に対して、予測エンジンの構成が変更されたものに対応し、その他の部材の構成及び機能はシステム１と同様である。従って、以下の本変形例についての説明では、第１の実施形態に係るシステム１と重複する事項についてはその詳細な説明を省略し、システム１との相違点について主に説明することとする。
　図８を参照すると、本変形例に係るシステム２では、イベント管理システムＸ２１０によってイベントＸが管理され、イベント管理システムＹ２２０によってイベントＹが管理され、イベント管理システムＺ２３０によってイベントＺが管理されている。また、イベント管理システムＸ２１０は、自身の会員であるＸ会員に対するお薦めのイベントを予測する予測エンジン２６７と、Ｘ会員の購入履歴情報が蓄積されたログ２１８と、を有している。また、イベント管理システムＹ２２０は、自身の会員であるＹ会員に対するお薦めのイベントを予測する予測エンジン２７７と、Ｙ会員の購入履歴情報が蓄積されたログ２２８と、を有している。また、イベント管理システムＺ２３０は、自身の会員であるＺ会員に対するお薦めのイベントを予測する予測エンジン２８７と、Ｚ会員の購入履歴情報が蓄積されたログ２３８と、を有している。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０、並びに、ログ２１８、２２８、２３８は、図１に示すこれらの構成と同様の機能を有するものであるため、詳細な説明は省略する。
　システム２は、第１の実施形態に係るシステム１と同様に、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換された、共通化イベントメタ情報を保持している。これにより、各管理システムによって管理されているイベントが、共通化イベントメタ情報として同一のスキーマで管理されることになる。なお、図８では図示を省略しているが、システム２においても、システム１と同様に、イベントメタ情報だけでなく、会員プロファイル情報や空席情報も共通スキーマに変換される。
　ここで、システム１では、各管理システムに横断的にアクセス可能な共通予測エンジン１５０が設けられていた。これに対して、本変形例では、共通予測エンジン１５０は設けられず、各管理システムの予測エンジン２６７、２７７、２８７のそれぞれが、共通予測エンジン１５０と同様の機能を有している。
　具体的には、イベント管理システムＸ２１０の予測エンジン２６７は、ネットワーク２５０を介して他の管理システムのログ２２８、２３８にアクセス可能に構成されている。また、予測エンジン２６７は、共通化イベントメタ情報（及び他の共通化情報）にアクセス可能に構成される。予測エンジン２６７は、図２に示す共通予測エンジン１５０と同様の機能を有しており、共通化イベントメタ情報と、各管理システムのログ２１８、２２８、２３８（すなわち購入履歴情報）に基づいて、推薦するイベントとユーザの組み合わせを決定することができる。詳細な説明は省略するが、他の予測エンジン２７７、２８７も、予測エンジン２６７と同様の機能を有する。
　システム２においても、システム１と同様の効果を得ることができる。すなわち、図１に示す一般的なシステム４では、予測エンジン２１７、２２７、２３７は、イベント管理システムＸ２１０が管理するイベントしか、ユーザに対して推薦することができなかった。しかし、本変形例では、イベントメタ情報が共通のスキーマで一括的に管理されることにより、予測エンジン２６７は、他の管理システムであるイベント管理システムＹ２２０及びイベント管理システムＺ２３０が管理しているイベントも、ユーザに対して推薦すべきイベントとして選択することが可能となる。
　更に、一般的なシステム４では、予測エンジン２１７、２２７、２３７は、自身が設けられた管理システムが管理するログ２１８、２２８、２３８にしかアクセスすることができず、いずれかの管理システムのログ２１８、２２８、２３８に格納された情報に基づいて推薦するイベントとユーザの組み合わせが決定されていた。しかし、本変形例では、予測エンジン２６７、２７７、２８７が、他の管理システムのログ２１８、２２８、２３８に横断的にアクセス可能に構成される。また、予測エンジン２６７、２７７、２８７は、共通化イベントメタ情報を用いることにより、他の管理システムによって管理されているイベントを把握することができる。従って、予測エンジン２６７、２７７、２８７は、他の管理システムのログ２１８、２２８、２３８を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。よって、予測の精度がより向上し、より的確なイベントの推薦が可能となる。
　以上、図８を参照して、第１の実施形態の一変形例として、各管理システムに予測エンジンが設けられる変形例について説明した。以上説明したように、本変形例によれば、各管理システムに設けられた予測エンジンが、共通予測エンジンと同様の役割を果たすことにより、上述したシステム１とは異なる構成によって、システム１と同様の機能を実現することが可能となる。なお、システムの設計者は、例えば各管理システムの構成等に応じて、より簡易にシステムを構成することが可能なように、システム１とシステム２のいずれかの構成を適宜選択することができる。
　（３．第２の実施形態）
　次に、第２の実施形態について説明する。上述した第１の実施形態では、共通予測エンジン１５０による処理結果に基づいて、各管理システムにおける会員に対してイベントが推薦されていた。このように、第１の実施形態では、イベントが推薦されるユーザは、いずれかの管理システムの会員に限定されていた。また、共通予測エンジン１５０が予測モデルを生成するために参照する情報も、各管理システムにおけるログ（購入履歴情報）に限定されていた。
　そこで、第２の実施形態では、管理システムの会員に限られない、より多数のユーザに対してイベントを提示するシステムを提案する。また、管理システムの会員に限られないより多数のユーザの行動履歴に基づいて予測モデルを生成可能なシステムを提案する。
　ここで、一般的に、ユーザの行動履歴に基づいて当該ユーザの興味や関心を推測し、ターゲットを絞ってインターネット等を介したデジタル広告を配信する手法（いわゆるターゲティング広告）が知られている。第２の実施形態は、概略的には、第１の実施形態で説明した技術を、当該ターゲティング広告に適用したものに対応する。そこで、以下の第２の実施形態についての説明では、まず、一般的なターゲティング広告に係るシステムについて説明するとともに、第１の実施形態に係るシステム１が、当該システムにおいてどのように適用され得るかについて説明する。その後、ターゲティング広告に係るシステムと第１の実施形態に係るシステム１とが組み合わされて構成される、第２の実施形態に係るシステムの詳細について説明することとする。
　（３－１．ターゲティング広告について）
　図９を参照して、一般的なターゲティング広告に係るシステムについて説明する。図９は、一般的なターゲティング広告に係るシステムについて説明するための説明図である。
　図９に示すシステム５において、オーディエンス４５０（ユーザ４５０）は、一般のネットユーザである。ターゲティング広告では、例えば、ユーザ４５０が、メディア４６０（例えばＷｅｂページ等）を訪問する際に、当該メディア４６０内の広告表示領域（広告枠）に、当該ユーザの興味や関心に沿った広告が表示される。
　図９に示す例では、メディア４６０の広告枠に広告を配信する事業者の一例として、アフィリエイト事業者４３１及びＤＳＰ（Ｄｅｍａｎｄ　Ｓｉｄｅ　Ｐｌａｔｆｏｒｍ）事業者４４２を図示している。アフィリエイト事業者４３１及びＤＳＰ事業者４４２には、広告主４１０から、コンテンツ（例えばイベント）の広告データが提供（出稿）されており、アフィリエイト事業者４３１及びＤＳＰ事業者４４２は、当該広告データをメディア４６０の広告枠に配信する。なお、広告データの作成や広告データの出稿は、広告代理店４２０等を介して行われてもよい。また、例えばコンテンツがイベントである場合には、広告主４１０は、当該イベントの主催者であり得る。
　アフィリエイトシステム４３０は、ユーザ４５０が、広告枠に配信された広告を介して、広告主４１０の管理するシステムにおいて会員登録をしたり、広告主４１０の商品を購入したりすることにより、メディア４６０の管理者に報酬が支払われるシステムである。また、ＤＳＰ事業者４４２が属するＲＴＢ（Ｒｅａｌ　Ｔｉｍｅ　Ｂｉｄｄｉｎｇ）システム４４０は、広告主とメディア４６０の管理者との間での広告枠の売買を支援するシステムである。具体的には、ＲＴＢシステム４４０では、メディア４６０の管理者から広告枠を預かり売りに出すＳＳＰ（Ｓｕｐｐｌｙ　Ｓｉｄｅ　Ｐｌａｔｆｏｒｍ）事業者４４１と、広告主４１０から広告データを預かり管理するＤＳＰ事業者４４２との間で、リアルタイムのオークション形式で広告枠の売買が行われ、広告枠を競り落としたＤＳＰ事業者４４２の広告データが当該広告枠に掲載される。アフィリエイト事業者４３１は、より多くのユーザ４５０が配信された広告を介して広告主４１０にアクセスするように、また、ＤＳＰ事業者４４２は、入札価格に比してより効果的な宣伝ができるように、ユーザ４５０の行動傾向や嗜好を考慮したターゲティング広告を好適に行う。
　一般的には、ユーザ４５０のメディア４６０上での行動（例えばＷｅｂサイト上での閲覧、選択（クリック）、コンバージョン（購入や会員登録）等）の履歴が、Ｃｏｏｋｉｅを通じて、ＣｏｏｋｉｅＩＤごとに把握され得る。これは、メディア４６０（Ｗｅｂページ）に、例えばＤＳＰ事業者４４２が、タグ（ＤＳＰタグ４６１）を設置し、当該タグによりＣｏｏｋｉｅＩＤを介してユーザ４５０を同定することにより実現され得る。当該手法はＣｏｏｋｉｅ－Ｓｙｎｃと呼称される。また、広告主４１０が管理しているシステム（例えば図２に示すイベント管理システムＸ２１０）における会員の購入履歴が、Ｐｒｉｖａｔｅ　ＤＭＰ（Ｄａｔａ　Ｍａｎａｇｅｍｅｎｔ　Ｐｌａｔｆｏｒｍ）４７１やＰｕｂｌｉｃ　ＤＭＰ４７２として管理されている。予測エンジン４７０は、ユーザ４５０のメディア４６０上での行動履歴、Ｐｒｉｖａｔｅ　ＤＭＰ４７１内の情報及び／又はＰｕｂｌｉｃ　ＤＭＰ４７２内の情報を用いて、推薦するイベントとユーザの組み合わせを決定することができる。
　予測エンジン４７０は、決定したイベントとユーザの組み合わせについての情報を、ＤＳＰ事業者４４２及び／又はアフィリエイト事業者４３１に提供する。これにより、ＤＳＰ事業者４４２及び／又はアフィリエイト事業者４３１によって、よりユーザ４５０の嗜好に合った、適切なイベントの広告が配信されることとなる。また、予測エンジン４７０は、決定したイベントとユーザの組み合わせについての情報を、ＳＳＰ事業者４４１に提供してもよい。これにより、ＳＳＰ事業者４４１は、より高い入札価格で広告枠が購入されるように広告枠を設置するＷｅｂサイトを選定する等、広告枠を売却する戦略を立てることができる。
　以上、一般的なターゲティング広告に係るシステム５について説明した。
　ここで、上述したように、本開示の第２の実施形態では、第１の実施形態に係るシステム１を、図９に示すシステム５に適用するものである。第１の実施形態で説明したログ２１８、２２８、２３８及び購入履歴情報ＤＢ２１５は、図９に示すＰｒｉｖａｔｅ　ＤＭＰ４７１に対応し得るものである。また、広告主４１０は、イベントの主催者に対応し得る。一方、第１の実施形態では、イベントメタ情報を共通化し、互いに異なる管理システムによって管理されているログ２１８、２２８、２３８を総合的に用いることにより、予測エンジンの予測精度を向上させることができた。従って、本開示の第２の実施形態では、第１の実施形態に係るシステム１を、図９に示すシステム５に適用することにより、互いに異なる管理システムによって管理されているログ２１８、２２８、２３８（すなわちＰｒｉｖａｔｅ　ＤＭＰ４７１）と、ユーザ４５０のメディア４６０上での行動履歴と、を総合的に用いた、更に高精度な予測エンジンを提供することができる。また、第２の実施形態では、イベントの広告が配信されるユーザが、管理システムの会員に限定されず、広告の配信の対象を一般のネットユーザにまで拡張することが可能となる。
　以下では、このような第２の実施形態に係るシステムについて詳細に説明する。なお、以下の第２の実施形態についての説明では、予測エンジンの処理結果に基づいて、ＤＳＰ事業者によって広告が配信される場合について説明する。ただし、第２の実施形態はかかる例に限定されず、広告を配信する業者は、例えば上述したアフィリエイト事業者のような、他の業者であってもよい。
　（３－２．システムの概要）
　図１０を参照して、第２の実施形態に係るシステムの概要について説明する。図１０は、第２の実施形態に係るシステムの概要について説明するための説明図である。なお、第２の実施形態に係るシステムのより詳細な構成については、下記（３－３．システムの構成）で詳しく説明する。なお、以下の第２の実施形態についての説明では、第１の実施形態と実質的に同様の構成についてはその詳細な説明を省略し、第１の実施形態との相違点について主に説明することとする。
　図１０を参照すると、第２の実施形態に係るシステム３では、イベント管理システムＸ６１０によってイベントＸが管理され、イベント管理システムＹ６２０によってイベントＹが管理され、イベント管理システムＺ６３０によってイベントＺが管理されている。また、イベント管理システムＸ６１０は、自身の会員であるＸ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ　ＤＭＰ６１８を有している。また、イベント管理システムＹ６２０は、自身の会員であるＹ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ　ＤＭＰ６２８を有している。また、イベント管理システムＺ６３０は、自身の会員であるＺ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ　ＤＭＰ６３８と、を有している。ここで、Ｐｒｉｖａｔｅ　ＤＭＰ６１８、６２８、６３８は、図３に示すログ２１８、２２８、２３８と略同様の機能を有するものである。
　システム３においても、第１の実施形態に係るシステム１と同様に、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換され、共通化イベントメタ情報が保持される。これにより、各管理システムによって管理されているイベントが、共通化イベントメタ情報として同一のスキーマで管理されることになる。なお、図１０では図示を省略しているが、システム３においても、システム１と同様に、イベントメタ情報だけでなく、会員プロファイル情報や空席情報も共通スキーマに変換される。
　また、システム３は、Ａｄ　Ｌｏｇ　ＤＢ５６０を備える。Ａｄ　Ｌｏｇ　ＤＢ５６０は、Ｗｅｂサイト上でのユーザの行動履歴情報が蓄積されるデータベースである。Ａｄ　Ｌｏｇ　ＤＢ５６０では、ユーザがＣｏｏｋｉｅＩＤによって管理されている。
　共通予測エンジン５７０は、各管理システムによってそれぞれ管理されているＰｒｉｖａｔｅ　ＤＭＰ６１８、６２８、６３８に横断的にアクセス可能であるとともに、上述した共通化イベントメタ情報と、Ａｄ　Ｌｏｇ　ＤＢ５６０と、にアクセス可能に構成される。共通予測エンジン５７０は、Ｐｒｉｖａｔｅ　ＤＭＰ６１８、６２８、６３８内の購入履歴情報、共通化イベントメタ情報、及びＡｄ　Ｌｏｇ　ＤＢ５６０内のユーザの行動履歴情報に基づいて、推薦するイベントとユーザの組み合わせを決定する。
　第１の実施形態と同様に、第２の実施形態においても、共通化イベントメタ情報を用いることにより、共通予測エンジン５７０が、他の管理システムのＰｒｉｖａｔｅ　ＤＭＰ６１８、６２８、６３８を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。従って、共通予測エンジン５７０による予測処理の精度がより向上し、より的確なイベント及びユーザのマッチングが可能となる。ただし、第２の実施形態では、Ａｄ　Ｌｏｇ　ＤＢ５６０内のユーザの行動履歴情報も、更に、共通予測エンジン５７０による予測処理に用いられる。
　ここで、各管理システムにおいては、ユーザは、各管理システムに登録された会員として、ユーザＩＤによって管理されている。一方、上述したように、Ａｄ　Ｌｏｇ　ＤＢ５６０では、ユーザは、ＣｏｏｋｉｅＩＤによって管理されている。従って、第２の実施形態では、各会員のＣｏｏｋｉｅＩＤを同定し、ユーザをＣｏｏｋｉｅＩＤによって一括して管理する。これにより、ユーザの管理システム上での行動（チケット購入等）と、Ｗｅｂサイト上での行動（Ｗｅｂサイトの閲覧やリンクの選択等）とが、ＣｏｏｋｉｅＩＤによって結び付けられることとなる。このように、第２の実施形態では、ユーザは、好適にＣｏｏｋｉｅＩＤによって管理され得る。第１の実施形態におけるユーザＩＤは、第２の実施形態では、ＣｏｏｋｉｅＩＤに読み替えることができる。
　上記のような会員のＣｏｏｋｉｅＩＤの同定は、例えばＣｏｏｋｉｅ－Ｓｙｎｃと呼ばれる手法を用いて実現され得る。Ｃｏｏｋｉｅ－Ｓｙｎｃでは、例えば、同定を行う主体が、Ｗｅｂサイトにタグを埋め込むことにより、当該Ｗｅｂサイトを訪問したユーザのブラウザに対して所定のＣｏｏｋｉｅが設定される。設定されたＣｏｏｋｉｅを介して、例えば当該ユーザが他のＷｅｂサイトを訪問した場合であっても、当該ユーザが一意に特定されることとなる。
　なお、Ｃｏｏｋｉｅ－Ｓｙｎｃは、一般的に広く用いられている手法である。例えば、上記（３－１．ターゲティング広告について）で説明したように、ターゲティング広告を行うために、ＤＳＰ業者がＷｅｂサイトにタグを埋め込み、Ｃｏｏｋｉｅ－Ｓｙｎｃを用いてユーザを特定し、当該ユーザの行動履歴から、その興味や関心を推定することが一般的に行われている。例えば、第２の実施形態では、ＤＳＰ業者が設置したタグを用いて、Ｃｏｏｋｉｅ－Ｓｙｎｃを行うことにより、会員のＣｏｏｋｉｅＩＤを同定することができる。このように、既存のタグを利用することにより、タグを新たに設置する必要がなくなり、より低コストでシステム３を構築することが可能となる。なお、上記のように、Ｃｏｏｋｉｅ－Ｓｙｎｃは、一般的に広く用いられている手法であるため、ここでは、Ｃｏｏｋｉｅ－Ｓｙｎｃについての詳細な説明は割愛する。
　例えば、Ｘ会員が、イベント管理システムＸ６１０を利用して、あるイベントのチケットを購入したとする。すると、当該Ｘ会員のＣｏｏｋｉｅＩＤが、Ｃｏｏｋｉｅ－Ｓｙｎｃを用いて同定される。これにより、Ｗｅｂサイト上でのＸ会員（図中ユーザ５９０ａ）の行動履歴が特定され得る。
　同様にして、他のユーザの管理システム上での行動及びＷｅｂサイト上での行動も、ＣｏｏｋｉｅＩＤによって結び付けられて把握される。例えば、ユーザ５９０ａとは異なるユーザ５９０ｂが、イベント管理システムＸ６１０を利用して、あるイベントのチケットを購入したとする。当該ユーザ５９０ｂのチケットの購入履歴情報は、Ｐｒｉｖａｔｅ　ＤＭＰ６１８に格納される。また、当該ユーザ５９０ｂのＷｅｂサイト上での行動履歴情報は、Ａｄ　Ｌｏｇ　ＤＢ５６０に格納される。同様に、イベント管理システムＹ６２０を利用してあるイベントのチケットを購入したユーザ５９０ｃのチケットの購入履歴情報がＰｒｉｖａｔｅ　ＤＭＰ６２８に格納されるとともに、当該ユーザ５９０ｃのＷｅｂサイト上での行動履歴情報がＡｄ　Ｌｏｇ　ＤＢ５６０に格納される。また、イベント管理システムＺ６３０を利用してあるイベントのチケットを購入したユーザ５９０ｄのチケットの購入履歴情報がＰｒｉｖａｔｅ　ＤＭＰ６３８に格納されるとともに、当該ユーザ５９０ｄのＷｅｂサイト上での行動履歴情報がＡｄ　Ｌｏｇ　ＤＢ５６０に格納される。
　従って、共通予測エンジン５７０は、Ｐｒｉｖａｔｅ　ＤＭＰ６１８、６２８、６３８に格納されている管理システム上での購入履歴情報と、Ａｄ　Ｌｏｇ　ＤＢ５６０に格納されているＷｅｂサイト上での行動履歴情報と、を参照することにより、あるユーザの購入履歴情報及び行動履歴情報を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。よって、共通予測エンジン５７０による予測処理の精度が更に向上するのである。
　共通予測エンジン５７０によって決定されたイベントとユーザの組み合わせに基づいて、当該ユーザに対して当該イベントが提示される。ここで、第２の実施形態では、Ａｄ　Ｌｏｇ　ＤＢ５６０内の行動履歴情報も用いてイベントを推薦するユーザが決定されるため、当該ユーザは、必ずしもいずれかの管理システムの会員とは限らない。例えば、共通予測エンジン５７０が、あるイベントを推薦すべきユーザを選択した結果、行動履歴情報に基づいて、非会員であるユーザの中から、当該イベントに興味を抱いていることが推測されるユーザが抽出される可能性もある。このように、第２の実施形態では、管理システムの会員でないユーザにまで、イベントを推薦する対象を拡張することができ、商材の購入を更に促すことが可能となる。
　ここで、第１の実施形態では、各管理システムにおけるユーザＩＤによってユーザを管理していたため、同一のユーザが互いに異なる管理システムの会員として登録され、複数のユーザＩＤを有している場合には、当該ユーザは、ユーザＩＤごとに別人として扱われる。しかしながら、第２の実施形態では、ＣｏｏｋｉｅＩＤによってユーザが管理されるため、同一のユーザが互いに異なる管理システムの会員として登録されている場合であっても、当該ユーザが一意に同定され得る。従って、推薦するイベントとユーザとのマッチングを行う際に、同一のユーザを複数回マッチングしてしまう事態が回避され、より効率的な広告の配信が実現され得る。
　以上、図１０を参照して、第２の実施形態に係るシステム３の概要について説明した。以上説明したように、第２の実施形態によれば、各管理システムにおけるＰｒｉｖａｔｅ　ＤＭＰ（購入履歴情報）だけでなく、Ｗｅｂサイト上での行動履歴情報まで参照して、推薦するイベントとユーザの組み合わせが決定される。その際、例えば管理システムにおけるユーザ（会員）と、Ｗｅｂサイトを利用しているユーザとが、例えばＣｏｏｋｉｅＩＤを介して結び付けられているため、共通予測エンジン５７０は、当該購入履歴情報と当該行動履歴情報とを総合的に用いて、当該ユーザの嗜好を解析し、イベントとのマッチングを行うことができる。従って、より精度の高いマッチングが実現され得る。
　また、第２の実施形態では、管理システムの会員でないユーザも、イベントの推薦対象として選択され得る。従って、イベントが推薦される対象を拡張することができ、当該イベントのチケットの販売をより促すことができる。
　（３－３．システムの構成）
　図１１及び図１２を参照して、以上説明した第２の実施形態に係るシステム３の構成についてより詳細に説明する。図１１は、第２の実施形態に係るシステム３の一構成例を示すブロック図である。図１２は、図１１に示す推薦部５３０の機能構成の一例を示す機能ブロック図である。
　図１１を参照すると、第２の実施形態に係るシステム３は、情報処理装置５０と、イベント管理システムＸ６１０と、イベント管理システムＹ６２０と、イベント管理システムＺ６３０と、主催者プロファイル情報ＤＢ１４０と、入出力部１６０と、Ａｄ　Ｌｏｇ　ＤＢ５６０と、を備える。ここで、イベント管理システムＸ６１０、イベント管理システムＹ６２０及びイベント管理システムＺ６３０は、それぞれ、図１０に示すイベント管理システムＸ６１０、イベント管理システムＹ６２０及びイベント管理システムＺ６３０に対応するものである。また、Ａｄ　Ｌｏｇ　ＤＢ５６０は、図１０に示すＡｄ　Ｌｏｇ　ＤＢ５６０に対応据えるものである。なお、主催者プロファイル情報ＤＢ１４０及び入出力部１６０は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
　なお、図１１では、一例として、イベント管理システムＸ６１０の構成を詳細に図示しているが、他の管理システムであるイベント管理システムＹ６２０及びイベント管理システムＺ６３０も同様の構成であり得る。また、以下では、イベント管理システムＸ６１０における処理について説明するために、イベント管理システムＸ６１０の会員であるユーザとイベント管理システムＸ６１０との間で実行される処理について説明するが、イベント管理システムＹ６２０とイベント管理システムＹ６２０の会員との間においても同様の処理が実行され得るし、イベント管理システムＺ６３０とイベント管理システムＺ６３０の会員との間においても同様の処理が実行され得る。
　（Ａｄ　Ｌｏｇ　ＤＢ５６０）
　Ａｄ　Ｌｏｇ　ＤＢ５６０は、Ｗｅｂサイト上でのユーザの行動履歴情報を格納する。行動履歴情報には、メディア（例えばＷｅｂサイト）上でユーザが行ったあらゆる行動についての情報が含まれる。例えば、行動履歴情報には、ユーザが閲覧したＷｅｂサイトについての情報、ユーザがＷｅｂサイト上で選択したリンクについての情報、ユーザのＷｅｂサイト上でのコンバージョン（例えば商品の購入、会員登録等）についての情報等が含まれる。Ａｄ　Ｌｏｇ　ＤＢ５６０では、行動履歴情報は、ＣｏｏｋｉｅＩＤによって管理されている。なお、行動履歴情報を取得する具体的な方法については、下記（３－４．行動履歴情報の取得方法の具体例）で改めて詳しく説明する。
　（イベント管理システムＸ６１０）
　イベント管理システムＸ６１０は、その機能として、チケット販売システム２１１と、イベントメタ情報ＤＢ２１２と、空席情報ＤＢ２１３と、会員プロファイル情報ＤＢ２１４と、購入履歴情報ＤＢ２１５と、を有する。購入履歴情報ＤＢ２１５は、図１０に示すＰｒｉｖａｔｅ　ＤＭＰ６１８に対応するものである。なお、チケット販売システム２１１、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４及び購入履歴情報ＤＢ２１５は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
　（情報処理装置５０）
　情報処理装置５０は、その機能として、スキーマ変換部１１０と、共通化イベントメタ情報ＤＢ１２１と、共通化空席情報ＤＢ１２２と、共通化会員プロファイル情報ＤＢ１２３と、推薦部５３０と、提示制御部１７０と、を有する。なお、スキーマ変換部１１０、推薦部５３０及び提示制御部１７０は、例えばＣＰＵやＤＳＰ等の各種のプロセッサによって構成され、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。また、スキーマ変換部１１０、提示制御部１７０、共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
　推薦部５３０は、共通化イベントメタ情報と、購入履歴情報と、行動履歴情報と、に基づいて、推薦するイベントとユーザの組み合わせを決定する。推薦部５３０は、図１０に示す共通予測エンジン５７０に対応する機能を有する。
　推薦部５３０における、共通化情報及び購入履歴情報の利用方法は、第１の実施形態における推薦部１３０と同様である。すなわち、推薦部５３０は、購入履歴情報ＤＢ２１５内の購入履歴情報を共通化イベントメタ情報に紐付けることにより、各管理システムの購入履歴情報を総合的に利用して、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。更に、第２の実施形態では、推薦部５３０は、購入履歴情報に含まれるユーザＩＤと、Ａｄ　Ｌｏｇ　ＤＢ５６０内の行動履歴情報に含まれるＣｏｏｋｉｅＩＤとを、例えばＣｏｏｋｉｅ－Ｓｙｎｃ等の手法により紐付けることにより、同一のユーザの購入履歴情報と行動履歴情報とを結び付けることが可能となる。従って、推薦部５３０は、例えばあるイベントのチケットを購入したユーザが、Ｗｅｂサイト上ではどのような行動をとっているかを把握することが可能となる。推薦部５３０は、このようにユーザが同定された購入履歴情報及び行動履歴情報の双方を用いて、推薦するイベントとユーザの組み合わせを決定する。よって、より高精度な推薦処理が実現される。
　また、推薦部５３０は、第１の実施形態における推薦部１３０と同様に、販売戦略を決定する機能を有する。ただし、推薦部５３０は、共通化イベントメタ情報及び購入履歴情報だけでなく、行動履歴情報を更に用いて販売戦略を決定することができる。従って、より的確な販売戦略が決定され得る。
　推薦部５３０によって選択されたイベント及びユーザについての情報は、ＤＳＰ事業者５５０に提供される。ＤＳＰ事業者５５０は、図９に示すＤＳＰ事業者４４２に対応する。選択されたユーザのブラウザもＣｏｏｋｉｅＩＤで特定され得るため、ＤＳＰ事業者４４２は、選択されたユーザが使用しているＷｅｂブラウザ上に設けられた広告枠をＲＴＢによって競り落とし、落札した広告枠に選択されたイベントの広告を表示させる。このように、第２の実施形態では、不特定多数のネットユーザに対して、イベントを提示することができる。従って、イベントが推薦される対象範囲がより拡大され、チケットの購入が促進される。
　ここで、図１２を参照して、推薦部５３０の機能構成についてより詳細に説明する。図１２を参照すると、推薦部５３０は、その機能として、主催者プロファイル情報取得部１３１と、共通化情報取得部１３２と、購入履歴情報取得部１３３と、行動履歴情報取得部５３６と、予測モデル生成部５３４と、イベント－ユーザ決定部５３５と、販売戦略決定部５３７と、を有する。ここで、図１２では、説明のため、推薦部５３０と情報をやり取りする構成として、主催者プロファイル情報ＤＢ１４０、共通化情報ＤＢ１２０、購入履歴情報ＤＢ２１５、Ａｄ　Ｌｏｇ　ＤＢ５６０及び提示制御部１７０を併せて図示している。なお、図４と同様に、共通化情報ＤＢ１２０は、図１１に示す共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３を併せて１つのブロックとして図示したものである。また、推薦部５３０の機能のうち、主催者プロファイル情報取得部１３１、共通化情報取得部１３２及び購入履歴情報取得部１３３の機能は、図４に示すこれらの構成の機能と同様であるため、その詳細な説明は省略する。
　行動履歴情報取得部５３６は、Ａｄ　Ｌｏｇ　ＤＢ５６０から行動履歴情報を取得する。行動履歴情報取得部５３６は、取得した行動履歴情報を、予測モデル生成部５３４、イベント－ユーザ決定部５３５及び販売戦略決定部５３７に提供する。
　販売戦略決定部５３７は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、行動情報と、に基づいて、イベントの販売戦略を決定する。第２の実施形態では、各管理システムの購入履歴情報ＤＢ２１５の購入履歴情報がイベントメタ情報によって紐付けられ、購入履歴情報に含まれるユーザＩＤと、Ａｄ　Ｌｏｇ　ＤＢ５６０内の行動履歴情報に含まれるＣｏｏｋｉｅＩＤとが、例えばＣｏｏｋｉｅ－Ｓｙｎｃ等の手法により紐付けられる。従って、販売戦略決定部５３７は、各管理システムにおける購入履歴情報及び行動履歴情報を総合的に用いて、販売戦略を決定することができる。なお、販売戦略決定部５３７の機能は、行動履歴情報を更に用いること以外は、第１の実施形態における販売戦略決定部１３６の機能と同様であるため、その詳細な説明は省略する。
　第１の実施形態と同様に、販売戦略決定部５３７は、決定した販売戦略についての情報を、提示制御部１７０に提供する。当該販売戦略についての情報は、提示制御部１７０によって、入出力部１６０を介して主催者に対して提示される。主催者は、提示された情報を参考にして、最終的な販売戦略を決定し、主催者プロファイル情報として、主催者プロファイル情報ＤＢ１４０に入力することができる。
　予測モデル生成部５３４は、共通化イベントメタ情報と、購入履歴情報と、行動履歴情報と、に基づいて、推薦するイベントとユーザとの組み合わせを選択するための予測モデルを生成する。上述したように、各管理システムにおける購入履歴情報及び行動履歴情報が、互いに紐付けられているため、予測モデル生成部５３４は、これらの情報を総合的に用いて予測モデルを生成することができる。
　なお、予測モデル生成部５３４の機能は、行動履歴情報を更に用いること以外は、第１の実施形態における予測モデル生成部１３４の機能と同様であるため、その詳細な説明は省略する。予測モデル生成部５３４が生成する予測モデルの種類は、図４に示す予測モデル生成部１３４が生成する予測モデルと同様であってよい。また、予測モデル生成部５３４も、図４に示す予測モデル生成部１３４と同様に、販売履歴情報や、ユーザの行動傾向情報等に更に基づいて、予測モデルを生成することができる。予測モデル生成部５３４は、生成した予測モデルを、イベント－ユーザ決定部５３５に提供する。
　イベント－ユーザ決定部５３５は、生成された予測モデルに基づいて、推薦するイベントとユーザの組み合わせを決定する。イベント－ユーザ決定部５３５が行う処理は、図４に示す予測モデル生成部１３４と略同様であるため、その詳細な説明は省略する。ただし、第２の実施形態では、イベント－ユーザ決定部５３５は、管理システムの会員だけでなく、行動履歴情報が取得されている不特定多数のユーザまで候補に含めて、イベントを推薦するユーザを選択することができる。
　イベント－ユーザ決定部５３５は、選択したイベント及びユーザの組み合わせについての情報を、ＤＳＰ事業者５５０に提供する。ＤＳＰ事業者５５０によって、例えば選択されたユーザのＷｅｂブラウザ上の広告枠に、選択されたイベントの広告が表示される。
　以上、図１１及び図１２を参照して、第２の実施形態に係るシステム３の構成について説明した。以上説明したように、第２の実施形態によれば、第１の実施形態の構成に加えて、更に、メディア上でのユーザの行動を表す行動履歴情報が取得される。購入履歴情報に含まれるユーザＩＤと、行動履歴情報に含まれるＣｏｏｋｉｅＩＤとは、例えばＣｏｏｋｉｅ－Ｓｙｎｃ等の手法により紐付けることができるため、同一のユーザの購入履歴情報と行動履歴情報とを結び付けることが可能となる。従って、第２の実施形態では、各管理システムの購入履歴情報と行動履歴情報とを総合的に扱うことができ、予測エンジンの精度を更に向上させることができる。また、イベントを推薦する対象が、管理システムの会員だけでなく、行動履歴情報が取得されている不特定多数のユーザにまで拡張されるため、より多くのユーザに対して広告を配信することが可能となる。従って、イベントのチケットの売り上げがより促進され、主催者にとって利便性の高いシステムが実現され得る。また、ユーザにとっても、より自身の嗜好に合ったイベントが推薦されることとなり、ユーザの利便性も向上される。
　なお、情報処理装置５０の装置構成は、図１１及び図１２に示す例に限定されない。例えば、図１１及び図１２に示す情報処理装置５０の各機能は、必ずしも１つの装置に一体的に搭載されなくてもよい。図１１及び図１２に示す情報処理装置５０に搭載される各機能が、複数の装置に分散されて搭載され、当該複数の装置が通信可能に接続されることにより、情報処理装置５０が構成されてもよい。例えば、各ＤＢは、情報処理装置５０とは異なる外部の機器として備えられてもよく、情報処理装置５０が、外部機器であるこれらＤＢと通信を行いながら、上述した各種の処理を実行してもよい。
　また、上述のような第２の実施形態に係る情報処理装置５０の機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
　（３－４．行動履歴情報の取得方法の具体例）
　上述したように、第２の実施形態では、Ｗｅｂサイト上でのユーザの行動が、行動履歴情報として取得される。図１３及び図１４を参照して、このような、Ｗｅｂサイト上での行動履歴情報の取得方法の一例について説明する。図１３及び図１４は、行動履歴情報の取得方法について説明するための説明図である。
　図１３には、ユーザが閲覧しているＷｅｂサイト３２０の一例が図示されている。例えば、Ｗｅｂサイト３２０は、あるライブイベントのチケット販売のメインページである。例えば、当該ライブイベントのチケット販売のメインページを閲覧した旨の情報が、行動履歴情報として取得され得る。
　また、Ｗｅｂサイト３２０には、イベントの出演者の画像や、イベントの情報とともに、チケットの販売サイトへのリンク（図中、「販売サイトＸ」、「販売サイトＹ」及び「販売サイトＺ」）が表示されている。ユーザは、実際にチケットを購入する場合には、いずれかの販売サイトのリンクを選択し、対応する販売サイトに移動してからチケットを購入することになる。例えば、ユーザがどの販売サイトのリンクを選択したかについての情報も、行動履歴情報として取得され得る。
　図１４は、チケット販売のメインページとリンク先の販売サイトとの関係を、より概略的に図示するものである。図１４を参照すると、Ｗｅｂサイト３３０は、図１３に示すＷｅｂサイト３２０と同様に、イベントのチケット販売のメインページである。
　Ｗｅｂサイト３３０には、例えば、チケット販売サイトへのリンクとして、自社サイトへのリンク３３１、他の販売サイトＸへのリンク３３２及び更に他の販売サイトＹへのリンク３３３が表示されている。また、Ｗｅｂサイト３３０には、タグ３３４（例えばＤＳＰタグ）が設定されている。ユーザがＷｅｂサイト３３０を閲覧したことや、ユーザがＷｅｂサイト３３０においてリンク３３１、３３２、３３３のいずれかを選択したことは、当該タグ３３４によってＡｄ　Ｌｏｇ　ＤＢ５６０に蓄積される。
　ユーザがリンク３３２を選択した場合には、販売サイトＸのＷｅｂサイト３４０が表示される。Ｗｅｂサイト３４０にも、同様に、タグ３４４が設定されており、当該Ｗｅｂサイト３４０上でのユーザの行動は、当該タグ３４４によってＡｄ　Ｌｏｇ　ＤＢ５６０に蓄積される。
　また、ユーザがリンク３３３を選択した場合には、販売サイトＹのＷｅｂサイト３５０が表示される。Ｗｅｂサイト３５０にも、同様に、タグ３５４が設定されており、当該Ｗｅｂサイト３５０上でのユーザの行動は、当該タグ３５４によってＡｄ　Ｌｏｇ　ＤＢ５６０に蓄積される。
　このように、チケット販売のメインページだけでなく、各チケット販売サイトにタグを設定することにより、ユーザがチケットを購入したという情報だけでなく、ユーザがどの販売サイトでチケットを購入したかまで追跡し、行動履歴情報として取得することが可能となる。このように、リンク先のＷｅｂサイトにまでタグを設定することにより、より詳細な行動履歴情報を取得することが可能となる。
　以上、図１３及び図１４を参照して、Ｗｅｂサイト上での行動履歴情報の取得方法の一例について説明した。なお、上記の例では、チケット販売のメインページ又は各販売サイトにタグが埋め込まれ、当該タグに基づいて、当該チケット販売のメインページ又は当該各販売サイトにおけるユーザの行動情報が取得される場合について説明したが、第２の実施形態はかかる例に限定されない。例えば、あるＷｅｂページへのタグの設置により、当該Ｗｅｂページに移動する前のＷｅｂページ情報（いわゆるリファラーＵＲＬ）を取得することが可能である。第２の実施形態では、タグが設置されたＷｅｂページだけでなく、このような当該Ｗｅｂページに移動する前のＷｅｂページ情報も、ユーザの閲覧履歴情報の一つとして取得されてもよい。また、タグが設置されるＷｅｂページは、広告枠のないＷｅｂページであってもよい。広告枠のないＷｅｂページにタグを設置することにより、より一般的に、幅広く、Ｗｅｂページについてのユーザの閲覧履歴情報を取得することが可能となる。第２の実施形態では、このような、タグが直接設置されていないＷｅｂページについての閲覧履歴情報や、広告枠のないＷｅｂページについての閲覧履歴情報も、ユーザの行動履歴情報として取得され、予測モデルに反映されてもよい。これにより、より高精度にユーザの嗜好を捉えた予測モデルを生成することが可能となる。
　（３－５．情報処理方法）
　図１５を参照して、図１１に示すシステム３において実行される、第２の実施形態に係る情報処理方法について説明する。図１５は、第２の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。なお、以下では、図１１に示すシステム３において、イベント管理システムＸ６１０によって管理されているイベントＳがユーザに対して推薦される場合を例に挙げて、情報処理方法についての説明を行う。
　図１５を参照すると、第２の実施形態に係る情報処理方法では、まず、主催者によって、イベントＳのイベントメタ情報及び主催者プロファイル情報が登録される（ステップＳ２０１）。次に、イベントＳのイベントメタ情報及び空席情報と、管理システムの会員プロファイル情報と、が、共通のスキーマに変換される（ステップＳ２０３）。なお、ステップＳ２０１に示す処理及びステップＳ２０３に示す処理は、図６に示す第１の実施形態に係る情報処理方法のステップＳ１０１に示す処理及びステップＳ１０３に示す処理と、それぞれ同様の処理であるため、その詳細な説明は省略する。
　次に、共通化イベントメタ情報、購入履歴情報及び行動履歴情報に基づいて、販売戦略が決定される（ステップＳ２０４）。当該販売戦略は、例えば、イベントの種類や、過去の同種のイベントの販売実績、イベントＳに関連するＷｅｂページへのユーザの行動等に基づいて決定され得る。ステップＳ２０４に示す処理は、例えば図１１に示す販売戦略決定部５３７によって行われる処理に対応している。
　次に、共通化イベントメタ情報、購入履歴情報及び行動履歴情報に基づいて、予測モデルが生成される（ステップＳ２０５）。当該予測モデルは、例えば、イベントの種類や、ユーザの購入履歴等を考慮して、イベントＳを推薦すべきユーザを予測するためのモデルである。ステップＳ２０５に示す処理は、例えば図１１に示す予測モデル生成部５３４によって行われる処理に対応している。
　次に、生成された予測モデルに基づいて、イベントＳにマッチするユーザが選択される（ステップＳ２０７）。ステップＳ２０７に示す処理は、例えば図１１に示すイベント－ユーザ決定部５３５によって行われる処理に対応している。なお、ステップＳ２０７に示す処理において選択されるユーザは、いずれかの管理システムの会員に限定されず、行動履歴情報が取得されている不特定多数のユーザであり得る。
　次に、イベントＳと選択されたユーザについての情報が、ＤＳＰ事業者５５０に提供される（ステップＳ２０９）。そして、選択されたユーザが広告枠の存在するＷｅｂサイトに訪れた際に、ＤＳＰ事業者５５０によってＲＴＢが実施される（ステップＳ２１１）。
　広告枠を落札できた場合には、ＤＳＰ事業者５５０は、当該広告枠にイベントＳの広告を表示させる（ステップＳ２１３）。これにより、選択されたユーザに対して、推薦すべきイベントＳが提示されることになる。
　次に、ユーザのＷｅｂサイト上での行動が、当該Ｗｅｂサイトに設定されたタグによって、Ａｄ　Ｌｏｇ　ＤＢ５６０に送信される（ステップＳ２１５）。これにより、Ａｄ　Ｌｏｇ　ＤＢ５６０に行動履歴情報が蓄積され、また、Ａｄ　Ｌｏｇ　ＤＢ５６０内の行動履歴情報が更新される。例えば、当該Ｗｅｂサイト上での行動は、表示されたイベントＳの広告に対する行動である。ただし、ステップＳ２１５に示す処理では、選択されたユーザの当該イベントＳの広告に対する行動だけでなく、Ｗｅｂサイト上でのあらゆるユーザのあらゆる行動が、行動履歴情報として取得され得る。
　次に、ユーザの購入行動に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の当該ユーザの購入履歴情報が更新される（ステップＳ２１７）。なお、ステップＳ２１７に示す処理では、ユーザが、提示されたイベントＳの広告を見てイベントＳのチケットを購入した場合はもちろんのこと、ユーザの他の購入行動も、空席情報ＤＢ２１３内の空席情報及び購入履歴情報ＤＢ２１５内の購入履歴情報に反映され得る。
　次に、オフラインでの購入実績に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の当該ユーザの購入履歴情報が更新される（ステップＳ２１９）。ステップＳ２１９に示す処理は、図６に示す第１の実施形態に係る情報処理方法のステップＳ１１５に示す処理と同様の処理であるため、その詳細な説明は省略する。
　なお、図１５では、便宜的に、ステップＳ２１５に示す処理、ステップＳ２１７に示す処理及びステップＳ２１９に示す処理をこの順序で図示しているが、これらの処理は、システム３において随時実行される処理であるため、その順序は任意であってよい。
　ステップＳ２１９に示す処理が終了すると、ステップＳ２０３に戻り、更新された空席情報、購入履歴情報及び行動履歴情報に基づいて、ステップＳ２０３以降の処理が繰り返し実行される。なお、図１５に示すフロー図では明示していないが、実際には、例えば売り上げ実績に応じた主催者プロファイル情報内の販売戦略情報の変更や、新規会員の登録及び既存会員の退会等による会員プロファイル情報の変更、イベント内容の変更に伴うイベントメタ情報の変更等も随時行われ得る。図１５に示すフローにおいては、このような主催者プロファイル情報、イベントメタ情報及び会員プロファイル情報の変更も適宜実行されてよい。その場合、変更されたこれらの情報に基づいて、各ステップに示す処理が実行され得る。また、第１の実施形態と同様に、ステップＳ２０５に示す予測モデルの生成処理は、図１５に示す一連の処理が実行される際に、毎回行われなくてもよい。例えば、１週間に１度、あるいは一定量の購入履歴情報が更新されたタイミングで、ステップＳ２０５に示す処理が行われ、予測モデルが更新されてもよい。
　以上、図１５を参照して、第２の実施形態に係る情報処理方法について説明した。
　（４．ハードウェア構成）
　次に、図１６を参照して、第１及び第２の実施形態に係る情報処理装置のハードウェア構成について説明する。図１６は、第１及び第２の実施形態に係る情報処理装置のハードウェア構成の一例を示す機能ブロック図である。なお、図１６に示す情報処理装置９００は、例えば、図３及び図１１に示す情報処理装置１０、５０を実現し得る。
　情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）９０３及びＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）９０５を備える。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、通信装置９２１、ドライブ９２３及び接続ポート９２５を備えてもよい。情報処理装置９００は、ＣＰＵ９０１に代えて、又はこれとともに、ＤＳＰ若しくはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ　Ｓｐｅｃｉｆｉｃ　Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ）と呼ばれるような処理回路を有してもよい。
　ＣＰＵ９０１は、演算処理装置及び制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９又はリムーバブル記録媒体９２９に記録された各種のプログラムに従って、情報処理装置９００内の動作全般又はその一部を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行時のパラメータ等を一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３及びＲＡＭ９０５は、ＣＰＵバス等の内部バスにより構成されるホストバス９０７により相互に接続されている。更に、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス９１１に接続されている。ＣＰＵ９０１は、例えば、上述した第１及び第２の実施形態におけるスキーマ変換部１１０、推薦部１３０、５３０及び提示制御部１７０を構成し得る。
　ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ　Ｃｏｍｐｏｎｅｎｔ　Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス９１１に接続されている。
　入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ及びレバー等、ユーザによって操作される装置によって構成される。また、入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置（いわゆる、リモコン）であってもよいし、情報処理装置９００の操作に対応した携帯電話やＰＤＡ等の外部接続機器９３１であってもよい。更に、入力装置９１５は、例えば、上記の操作手段を用いてユーザにより入力された情報に基づいて入力信号を生成し、ＣＰＵ９０１に出力する入力制御回路などから構成されている。情報処理装置９００のユーザは、この入力装置９１５を操作することにより、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりすることができる。第１及び第２の実施形態では、入力装置９１５を介して、情報処理装置１０、５０によって処理される各種の情報が入力されてよい。なお、図３及び図１１に示す入出力部１６０が、情報処理装置１０、５０と一体的に構成される場合には、当該入出力部１６０は、入力装置９１５によって構成され得る。
　出力装置９１７は、取得した情報をユーザに対して視覚的又は聴覚的に通知することが可能な装置で構成される。このような装置として、ＣＲＴディスプレイ装置、液晶ディスプレイ装置、プラズマディスプレイ装置、ＥＬディスプレイ装置及びランプ等の表示装置や、スピーカ及びヘッドホン等の音声出力装置や、プリンタ装置等がある。出力装置９１７は、例えば、情報処理装置９００が行った各種処理により得られた結果を出力する。具体的には、表示装置は、情報処理装置９００が行った各種処理により得られた結果を、テキスト、イメージ、表、グラフ等、様々な形式で視覚的に表示する。他方、音声出力装置は、再生された音声データや音響データ等からなるオーディオ信号をアナログ信号に変換して聴覚的に出力する。本実施形態では、出力装置９１７を介して、情報処理装置１０、５０によって処理される各種の情報が出力されてよい。なお、図３及び図１１に示す入出力部１６０が、情報処理装置１０、５０と一体的に構成される場合には、当該入出力部１６０は、出力装置９１７によって構成され得る。
　ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ等の磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス又は光磁気記憶デバイス等により構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ及び外部から取得した各種のデータ等を格納する。ストレージ装置９１９は、例えば、上述した第１及び第２の実施形態に係る情報処理装置１０、５０に設けられる各種のＤＢを構成し得る。
　通信装置９２１は、例えば、通信網（ネットワーク）９２７に接続するための通信デバイス等で構成された通信インターフェースである。通信装置９２１は、例えば、有線若しくは無線ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＷＵＳＢ（Ｗｉｒｅｌｅｓｓ　ＵＳＢ）用の通信カード等である。また、通信装置９２１は、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ　Ｄｉｇｉｔａｌ　Ｓｕｂｓｃｒｉｂｅｒ　Ｌｉｎｅ）用のルータ又は各種通信用のモデム等であってもよい。この通信装置９２１は、例えば、インターネットや他の通信機器との間で、例えばＴＣＰ／ＩＰ等の所定のプロトコルに則して信号等を送受信することができる。また、通信装置９２１に接続されるネットワーク９２７は、有線又は無線によって接続されたネットワーク等により構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信又は衛星通信等であってもよい。上述した第１及び第２の実施形態では、例えば、情報処理装置１０、５０と他の各種の構成（例えば管理システム、入出力部１６０、主催者プロファイル情報ＤＢ１４０、Ａｄ　Ｌｏｇ　ＤＢ５６０等）との間の通信が、通信装置９２１によってネットワーク９２７を介して実行されてよい。
　ドライブ９２３は、記録媒体用リーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２３は、装着されている磁気ディスク、光ディスク、光磁気ディスク又は半導体メモリ等のリムーバブル記録媒体９２９に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２３は、装着されている磁気ディスク、光ディスク、光磁気ディスク又は半導体メモリ等のリムーバブル記録媒体９２９に情報を書き込むことも可能である。リムーバブル記録媒体９２９は、例えば、ＤＶＤメディア、ＨＤ－ＤＶＤメディア、Ｂｌｕ－ｒａｙ（登録商標）メディア等である。また、リムーバブル記録媒体９２９は、コンパクトフラッシュ（登録商標）（ＣｏｍｐａｃｔＦｌａｓｈ：ＣＦ）、フラッシュメモリ又はＳＤメモリカード（Ｓｅｃｕｒｅ　Ｄｉｇｉｔａｌ　ｍｅｍｏｒｙ　ｃａｒｄ）等であってもよい。また、リムーバブル記録媒体９２９は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ　Ｃｉｒｃｕｉｔ　ｃａｒｄ）又は電子機器等であってもよい。第１及び第２の実施形態では、例えば情報処理装置１０、５０によって処理される各種の情報が、ドライブ９２３によってリムーバブル記録媒体９２９から読み出されたり、リムーバブル記録媒体９２９に書き込まれたりしてもよい。
　接続ポート９２５は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２５の一例として、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート及びＳＣＳＩ（Ｓｍａｌｌ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ）ポート等がある。接続ポート９２５の別の例として、ＲＳ－２３２Ｃポート、光オーディオ端子及びＨＤＭＩ（登録商標）（Ｈｉｇｈ－Ｄｅｆｉｎｉｔｉｏｎ　Ｍｕｌｔｉｍｅｄｉａ　Ｉｎｔｅｒｆａｃｅ）ポート等がある。この接続ポート９２５に外部接続機器９３１を接続することで、情報処理装置９００は、外部接続機器９３１から直接各種のデータを取得したり、外部接続機器９３１に各種のデータを提供したりする。第１及び第２の実施形態では、例えば情報処理装置１０、５０によって処理される各種の情報が、接続ポート９２５を介して外部接続機器９３１から取得されたり、外部接続機器９３１に出力されたりしてもよい。
　以上、本実施形態に係る情報処理装置９００の機能を実現可能なハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用するハードウェア構成を変更することが可能である。
　なお、上述のような本実施形態に係る情報処理装置９００の各機能を実現するためのコンピュータプログラムを作製し、ＰＣ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等である。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信されてもよい。
　（５．補足）
　以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
　また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
　例えば、上記第２の実施形態では、推薦部５３０によって決定されたイベントをユーザに対して提示するＷｅｂサイトの種類は特に限定されていなかったが、本技術はかかる例に限定されない。例えば、推薦するイベントに関連するＷｅｂサイトのＵＲＬが予め定義されており、推薦部５３０は、イベントを推薦する対象であるユーザが、当該Ｗｅｂサイトに訪れたタイミングでＲＴＢを実施し、当該イベントの広告を表示させてもよい。これにより、イベントが提示される媒体も、ユーザの嗜好に合った適切なものが選択されることとなり、広告の誘引力がより増強される。
　また、冒頭で説明したように、上述した第１及び第２の実施形態において扱われるコンテンツは、イベントに限定されず、あらゆるコンテンツであり得る。例えば、当該コンテンツは、オークションにおける出品物や、個人的な転売品等であってもよい。この場合、広告主は事業としてコンテンツの販売を行っている業者ではなく、当該オークションや転売での売り主である個人であり得る。このように、本技術は、個人的にコンテンツを売買するシステムに対しても好適に適用され得る。
　なお、以下のような構成も本開示の技術的範囲に属する。
（１）互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置。
（２）前記共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、前記コンテンツの販売戦略を決定する販売戦略決定部、を更に備え、前記推薦部は、前記販売戦略決定部によって決定された販売戦略に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）に記載の情報処理装置。
（３）前記コンテンツは、販売期間及び販売数の少なくともいずれかが限定されている定量商材であり、前記販売戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝戦略を含む、前記（２）に記載の情報処理装置。
（４）前記宣伝戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝量、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝時期、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝を行うユーザの属性、及び前記販売期間及び前記販売数に応じた前記コンテンツの宣伝の費用対効果、の少なくともいずれかを含む、前記（３）に記載の情報処理装置。
（５）前記販売戦略決定部によって決定された販売戦略を前記コンテンツの売り主に提示するとともに、提示された前記販売戦略に基づいて前記売り主が前記推薦部による決定処理に用いられる販売戦略を指定可能なインターフェースを提供する、提示制御部、を更に備える、前記（２）～（４）のいずれか１項に記載の情報処理装置。
（６）前記推薦部は、提示制御部によって提供されるインターフェースを介して前記コンテンツの売り主によって指定される販売戦略に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（５）に記載の情報処理装置。
（７）前記推薦部は、ユーザのコンテンツ購入時の行動傾向を表す行動傾向情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）～（６）のいずれか１項に記載の情報処理装置。
（８）前記推薦部は、前記複数の管理システムのいずれかに登録されている会員を、コンテンツを推薦するユーザとして決定する、前記（１）～（７）のいずれか１項に記載の情報処理装置。
（９）前記スキーマ変換部は、前記推薦部によって決定されたコンテンツについての共通化コンテンツメタ情報を、前記推薦部によって決定されたユーザが会員として登録されている管理システムにおいて販売可能なスキーマに変換する、前記（１）～（８）のいずれか１項に記載の情報処理装置。
（１０）前記推薦部は、メディア上でのユーザの行動を表す行動履歴情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）～（９）のいずれか１項に記載の情報処理装置。
（１１）前記行動履歴情報は、Ｗｅｂサイトを閲覧した旨の情報、Ｗｅｂサイト上のリンクを選択した旨の情報、及びＷｅｂサイト上でのコンバージョンについての情報、の少なくともいずれかを含む、前記（１０）に記載の情報処理装置。
（１２）前記推薦部は、前記行動履歴情報が取得されたユーザであって、前記複数の管理システムのいずれかに登録されている会員でないユーザを、コンテンツを推薦するユーザとして決定する、前記（１０）又は（１１）に記載の情報処理装置。
（１３）前記コンテンツは、席数が限定されているイベントである、前記（１）～（１２）のいずれか１項に記載の情報処理装置。
（１４）プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、を含む、情報処理方法。
（１５）コンピュータのプロセッサに、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、を実現させるためのプログラム。
　１、２、３　　システム
　１０、５０　　情報処理装置
　１１０　　スキーマ変換部
　１２０　　共通化情報ＤＢ
　１２１　　共通化イベントメタ情報ＤＢ
　１２２　　共通化空席情報ＤＢ
　１２３　　共通化会員プロファイル情報ＤＢ
　１３０、５３０　　推薦部
　１３１　　主催者プロファイル情報取得部
　１３２　　共通化情報取得部
　１３３　　購入履歴情報取得部
　１３４、５３４　　予測モデル生成部
　１３５、５３５　　イベント－ユーザ決定部
　１３６、５３７　　販売戦略決定部
　１４０　　主催者プロファイル情報ＤＢ
　１５０　　予測エンジン
　１６０　　入出力部
　１７０　　提示制御部
　２１０　　イベント管理システムＸ
　２１１　　チケット販売システム
　２１２　　イベントメタ情報ＤＢ
　２１３　　空席情報ＤＢ
　２１４　　会員プロファイル情報ＤＢ
　２１５　　購入履歴情報ＤＢ
　２１６　　推薦イベント提示部
　２２０　　イベント管理システムＹ
　２３０　　イベント管理システムＺ
　５３６　　行動履歴情報取得部
　５６０　　ＡＤ　Ｌｏｇ　ＤＢ
 

Claims (15)

  1. 　互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、
    　共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、
    　を備える、情報処理装置。
  2. 　前記共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、前記コンテンツの販売戦略を決定する販売戦略決定部、を更に備え、
    　前記推薦部は、前記販売戦略決定部によって決定された販売戦略に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、
    　請求項１に記載の情報処理装置。
  3. 　前記コンテンツは、販売期間及び販売数の少なくともいずれかが限定されている定量商材であり、
    　前記販売戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝戦略を含む、
    　請求項２に記載の情報処理装置。
  4. 　前記宣伝戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝量、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝時期、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝を行うユーザの属性、及び前記販売期間及び前記販売数に応じた前記コンテンツの宣伝の費用対効果、の少なくともいずれかを含む、
    　請求項３に記載の情報処理装置。
  5. 　前記販売戦略決定部によって決定された販売戦略を前記コンテンツの売り主に提示するとともに、提示された前記販売戦略に基づいて前記売り主が前記推薦部による決定処理に用いられる販売戦略を指定可能なインターフェースを提供する、提示制御部、を更に備える、
    　請求項２に記載の情報処理装置。
  6. 　前記推薦部は、提示制御部によって提供されるインターフェースを介して前記コンテンツの売り主によって指定される販売戦略に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、
    　請求項５に記載の情報処理装置。
  7. 　前記推薦部は、ユーザのコンテンツ購入時の行動傾向を表す行動傾向情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、
    　請求項１に記載の情報処理装置。
  8. 　前記推薦部は、前記複数の管理システムのいずれかに登録されている会員を、コンテンツを推薦するユーザとして決定する、
    　請求項１に記載の情報処理装置。
  9. 　前記スキーマ変換部は、前記推薦部によって決定されたコンテンツについての共通化コンテンツメタ情報を、前記推薦部によって決定されたユーザが会員として登録されている管理システムにおいて販売可能なスキーマに変換する、
    　請求項８に記載の情報処理装置。
  10. 　前記推薦部は、メディア上でのユーザの行動を表す行動履歴情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、
    　請求項１に記載の情報処理装置。
  11. 　前記行動履歴情報は、Ｗｅｂサイトを閲覧した旨の情報、Ｗｅｂサイト上のリンクを選択した旨の情報、及びＷｅｂサイト上でのコンバージョンについての情報、の少なくともいずれかを含む、
    　請求項１０に記載の情報処理装置。
  12. 　前記推薦部は、前記行動履歴情報が取得されたユーザであって、前記複数の管理システムのいずれかに登録されている会員でないユーザを、コンテンツを推薦するユーザとして決定する、
    　請求項１０又は１１に記載の情報処理装置。
  13. 　前記コンテンツは、席数が限定されているイベントである、
    　請求項１～１２のいずれか１項に記載の情報処理装置。
  14. 　プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、
    　共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、
    　を含む、情報処理方法。
  15. 　コンピュータのプロセッサに、
    　互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、
    　共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、
    　を実現させるためのプログラム。
     
PCT/JP2015/067910 2014-09-05 2015-06-22 情報処理装置、情報処理方法及びプログラム WO2016035424A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/505,831 US10496606B2 (en) 2014-09-05 2015-06-22 Information processing device, information processing method, and program
JP2016546359A JPWO2016035424A1 (ja) 2014-09-05 2015-06-22 情報処理装置、情報処理方法及びプログラム
EP15838688.8A EP3196821A4 (en) 2014-09-05 2015-06-22 Information processing device, information processing method and program
US16/551,726 US11379417B2 (en) 2014-09-05 2019-08-27 Information processing device, information processing method, and program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014180940 2014-09-05
JP2014-180940 2014-09-05

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US15/505,831 A-371-Of-International US10496606B2 (en) 2014-09-05 2015-06-22 Information processing device, information processing method, and program
US16/551,726 Continuation US11379417B2 (en) 2014-09-05 2019-08-27 Information processing device, information processing method, and program

Publications (1)

Publication Number Publication Date
WO2016035424A1 true WO2016035424A1 (ja) 2016-03-10

Family

ID=55439495

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/067910 WO2016035424A1 (ja) 2014-09-05 2015-06-22 情報処理装置、情報処理方法及びプログラム

Country Status (4)

Country Link
US (2) US10496606B2 (ja)
EP (1) EP3196821A4 (ja)
JP (1) JPWO2016035424A1 (ja)
WO (1) WO2016035424A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018010519A (ja) * 2016-07-14 2018-01-18 東芝テック株式会社 情報通知装置、情報通知システム及びプログラム
WO2018123248A1 (ja) * 2016-12-28 2018-07-05 ソニーネットワークコミュニケーションズ株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JP2020004344A (ja) * 2018-07-02 2020-01-09 大日本印刷株式会社 サービス提供者選定装置、プログラム及びサービス提供者選定システム
CN112930548A (zh) * 2018-10-22 2021-06-08 本田技研工业株式会社 服务提供装置
WO2024195213A1 (ja) * 2023-03-22 2024-09-26 株式会社Ｎｔｔドコモ レコメンドシステム

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3196821A4 (en) * 2014-09-05 2018-01-24 Sony Corporation Information processing device, information processing method and program
JP7130418B2 (ja) * 2018-04-23 2022-09-05 シャープ株式会社 情報処理装置、表示装置、制御プログラム、及び記録媒体
CN110335099B (zh) * 2019-05-06 2021-01-01 盛威时代科技集团有限公司 一种基于用户历史数据的车票购买线路推荐方法
USD966318S1 (en) 2019-06-28 2022-10-11 Block, Inc. Display screen or portion thereof having a graphical user interface
JP6963001B2 (ja) * 2019-12-26 2021-11-05 株式会社 みずほ銀行 サービス管理システム、サービス管理方法及びサービス管理プログラム

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000059515A (ja) * 1998-08-06 2000-02-25 Omron Corp 通信システム
JP2001229171A (ja) * 2000-02-15 2001-08-24 Jcb:Kk 商品検索システム
JP2005293384A (ja) * 2004-04-02 2005-10-20 Nippon Telegr & Teleph Corp <Ntt> コンテンツレコメンドシステムと方法、及びコンテンツレコメンドプログラム
JP2006018755A (ja) * 2004-07-05 2006-01-19 Stardust Promotion:Kk 情報配信装置及び情報配信方法
JP2008186431A (ja) * 2007-01-31 2008-08-14 Yahoo Japan Corp 情報検索システム、情報検索装置、情報検索結果出力方法およびプログラム
WO2012049987A1 (ja) * 2010-10-12 2012-04-19 日本電気株式会社 商品推薦システムおよび商品推薦方法
JP2013034069A (ja) * 2011-08-01 2013-02-14 Kddi Corp 他社契約の端末を接続可能とする無線ネットワークアクセス方法、中継サーバ及びプログラム
JP2014119805A (ja) * 2012-12-13 2014-06-30 Kizuna Japan Corp 物々交換をクーポンを介して現金化するクーポン流通仲介システムおよびクーポン流通仲介装置

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6377934B1 (en) * 1999-01-15 2002-04-23 Metaedge Corporation Method for providing a reverse star schema data model
US20020062241A1 (en) * 2000-07-19 2002-05-23 Janet Rubio Apparatus and method for coding electronic direct marketing lists to common searchable format
US7188081B1 (en) * 2000-10-30 2007-03-06 Microsoft Corporation Electronic shopping basket
JP2002197224A (ja) 2000-12-25 2002-07-12 Sony Corp 電子チケット管理システム，電子チケット情報読み出し装置，電子チケットプラットフォームセンタ，情報記憶チップ，携帯装置，プログラム記憶媒体および電子チケット管理方法
US20040148232A1 (en) * 2001-01-22 2004-07-29 Osamu Fushimi Electronic catalog aggregation apparatus for realizing fast and efficient electronic catalog system
WO2003012698A2 (en) * 2001-08-01 2003-02-13 Harmony Software, Inc. Method and apparatus for processing a query to a multi-dimensional data structure
JP2006235634A (ja) * 2005-01-28 2006-09-07 Hideo Yoshii 衣服を媒体とした広告方法
US20060291506A1 (en) * 2005-06-23 2006-12-28 Cain David C Process of providing content component displays with a digital video recorder
US20070260520A1 (en) * 2006-01-18 2007-11-08 Teracent Corporation System, method and computer program product for selecting internet-based advertising
US8117246B2 (en) * 2006-04-17 2012-02-14 Microsoft Corporation Registering, transfering, and acting on event metadata
US20080103945A1 (en) * 2006-11-01 2008-05-01 Robin Ross Cooper System and method for connecting entertainment media servers to local video shop inventories
JP4389987B2 (ja) 2007-09-12 2009-12-24 ソニー株式会社 情報配信装置、情報受信装置、情報配信方法、情報受信方法及び情報配信システム
JP2011501271A (ja) * 2007-10-09 2011-01-06 スキッフ・エルエルシー コンテンツ配信のシステム、方法および装置
US10565229B2 (en) * 2018-05-24 2020-02-18 People.ai, Inc. Systems and methods for matching electronic activities directly to record objects of systems of record
US9269060B2 (en) * 2009-11-20 2016-02-23 Oracle International Corporation Methods and systems for generating metadata describing dependencies for composable elements
US8484255B2 (en) * 2010-12-03 2013-07-09 Sap Ag Automatic conversion of multidimentional schema entities
US10282461B2 (en) * 2015-07-01 2019-05-07 Ncino, Inc. Structure-based entity analysis
US9183265B2 (en) * 2012-06-12 2015-11-10 International Business Machines Corporation Database query language gateway
US10977701B2 (en) * 2012-12-04 2021-04-13 Crutchfield Corporation Techniques for providing retail customers a seamless, individualized discovery and shopping experience between online and brick and mortar retail locations
US10108697B1 (en) * 2013-06-17 2018-10-23 The Boeing Company Event matching by analysis of text characteristics (e-match)
US9922102B2 (en) * 2013-07-31 2018-03-20 Splunk Inc. Templates for defining fields in machine data
US9336287B2 (en) * 2013-09-26 2016-05-10 SecurityDo Corp. System and method for merging network events and security events via superimposing data
EP3196821A4 (en) * 2014-09-05 2018-01-24 Sony Corporation Information processing device, information processing method and program
US9727607B2 (en) * 2014-11-19 2017-08-08 Ebay Inc. Systems and methods for representing search query rewrites
US10049500B2 (en) * 2015-09-22 2018-08-14 3D Product Imaging Inc. Augmented reality e-commerce for home improvement
US11004096B2 (en) * 2015-11-25 2021-05-11 Sprinklr, Inc. Buy intent estimation and its applications for social media data
US20170243125A1 (en) * 2016-02-24 2017-08-24 Sprinklr, Inc. Bayesian classification algorithm modification for sentiment estimation
US10218726B2 (en) * 2016-03-25 2019-02-26 Cisco Technology, Inc. Dynamic device clustering using device profile information
US11373232B2 (en) * 2019-05-24 2022-06-28 Salesforce.Com, Inc. Dynamic ranking of recommendation pairings

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000059515A (ja) * 1998-08-06 2000-02-25 Omron Corp 通信システム
JP2001229171A (ja) * 2000-02-15 2001-08-24 Jcb:Kk 商品検索システム
JP2005293384A (ja) * 2004-04-02 2005-10-20 Nippon Telegr & Teleph Corp <Ntt> コンテンツレコメンドシステムと方法、及びコンテンツレコメンドプログラム
JP2006018755A (ja) * 2004-07-05 2006-01-19 Stardust Promotion:Kk 情報配信装置及び情報配信方法
JP2008186431A (ja) * 2007-01-31 2008-08-14 Yahoo Japan Corp 情報検索システム、情報検索装置、情報検索結果出力方法およびプログラム
WO2012049987A1 (ja) * 2010-10-12 2012-04-19 日本電気株式会社 商品推薦システムおよび商品推薦方法
JP2013034069A (ja) * 2011-08-01 2013-02-14 Kddi Corp 他社契約の端末を接続可能とする無線ネットワークアクセス方法、中継サーバ及びプログラム
JP2014119805A (ja) * 2012-12-13 2014-06-30 Kizuna Japan Corp 物々交換をクーポンを介して現金化するクーポン流通仲介システムおよびクーポン流通仲介装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3196821A4 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018010519A (ja) * 2016-07-14 2018-01-18 東芝テック株式会社 情報通知装置、情報通知システム及びプログラム
WO2018123248A1 (ja) * 2016-12-28 2018-07-05 ソニーネットワークコミュニケーションズ株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JPWO2018123248A1 (ja) * 2016-12-28 2019-11-21 ソニーネットワークコミュニケーションズ株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JP7129913B2 (ja) 2016-12-28 2022-09-02 ソニーネットワークコミュニケーションズ株式会社 情報処理装置、情報処理方法およびプログラム
JP2020004344A (ja) * 2018-07-02 2020-01-09 大日本印刷株式会社 サービス提供者選定装置、プログラム及びサービス提供者選定システム
JP7180146B2 (ja) 2018-07-02 2022-11-30 大日本印刷株式会社 サービス提供者選定装置、プログラム及びサービス提供者選定システム
CN112930548A (zh) * 2018-10-22 2021-06-08 本田技研工业株式会社 服务提供装置
WO2024195213A1 (ja) * 2023-03-22 2024-09-26 株式会社Ｎｔｔドコモ レコメンドシステム

Also Published As

Publication number Publication date
EP3196821A1 (en) 2017-07-26
US10496606B2 (en) 2019-12-03
JPWO2016035424A1 (ja) 2017-07-13
US20190384746A1 (en) 2019-12-19
EP3196821A4 (en) 2018-01-24
US20170249326A1 (en) 2017-08-31
US11379417B2 (en) 2022-07-05

Similar Documents

Publication Publication Date Title
US11379417B2 (en) Information processing device, information processing method, and program
US12100195B2 (en) Systems and methods for automatic image generation and arrangement using a machine learning architecture
JP5649303B2 (ja) メディア・ストリームに注釈を付ける方法および装置
US8682809B2 (en) System and methods for providing user generated video reviews
US10032196B2 (en) Product and presentation placement system and method
US10325287B2 (en) Advertising based on user trends in an online system
AU2013363366B2 (en) Targeting objects to users based on search results in an online system
US20150095782A1 (en) System and methods for providing user generated video reviews
CN115151938A (zh) 用于标识视听内容内的产品的系统
CN106537901A (zh) 用于提供定制的娱乐内容的计算机处理方法和系统
CN107004005A (zh) 可定制的数据管理系统
US20170068910A1 (en) System and method for music distribution
US20140143058A1 (en) Sponsoring venues for targeting a social networking system
CN105474248A (zh) 用于促销与节目内容相关的项目的系统和方法
US20230385715A1 (en) Systems and methods for live event management and remote integration
US20180285474A1 (en) Third-party-site interoperability using publication and interactive discussion engine
CN109417644A (zh) 跨屏广告投放的收益优化
US20140143048A1 (en) Audience-based pricing in an online system
Das Application of digital marketing for life success in business
Mills et al. Market power, exclusive rights, and substitution effects in sports
Tan How to interact with consumers to enhance their purchase intention? Evidence from China’s agricultural products live streaming commerce
Church Maintaining Your Marketing Competitiveness Through Marketing Innovations
Lu et al. Relational platform entrepreneurs: Live commerce and the 818 Jiazu
JP2015135583A (ja) 決定装置、決定方法、決定プログラム、配信装置、配信方法、配信プログラムおよび入札装置
Xiaojuan Resource reorganization and service sector growth in highly interconnected society

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: 15838688

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016546359

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015838688

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015838688

Country of ref document: EP

Ref document number: 15505831

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE