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

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

Info

Publication number
WO2014132405A1
WO2014132405A1 PCT/JP2013/055485 JP2013055485W WO2014132405A1 WO 2014132405 A1 WO2014132405 A1 WO 2014132405A1 JP 2013055485 W JP2013055485 W JP 2013055485W WO 2014132405 A1 WO2014132405 A1 WO 2014132405A1
Authority
WO
WIPO (PCT)
Prior art keywords
facility
information
unit
user
history
Prior art date
Application number
PCT/JP2013/055485
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 JP2015502666A priority Critical patent/JP5759648B2/ja
Priority to US14/771,075 priority patent/US20160012354A1/en
Priority to PCT/JP2013/055485 priority patent/WO2014132405A1/ja
Publication of WO2014132405A1 publication Critical patent/WO2014132405A1/ja

Links

Images

Classifications

    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • One embodiment of the present invention relates to an information processing apparatus, an information processing method, and an information processing program that support user facility reservation.
  • Patent Document 1 describes an empty information providing system that allows a user to easily browse and reserve a facility with empty information by browsing the time-limited empty information of the facility.
  • this system When this system receives empty information from the facility terminal, it registers the empty information and the registration time of the empty information in the facility database, and when only the empty information registration request is received from the facility terminal, The empty information reception means for registering the registration time and the predetermined empty information in the facility database, the information on the facility that matches the conditions received from the user terminal, the empty information, and the empty information registration time are extracted and transmitted. Empty information providing means.
  • An information processing apparatus acquires the number of accesses to a facility from a predetermined time before receiving the information provision request in response to an information provision request from a user terminal to an information provision unit that provides facility information.
  • An information processing method acquires the number of accesses to a facility from a predetermined time before receiving the information provision request in response to an information provision request from a user terminal to an information provision unit that provides facility information. Based on the acquisition step, the number of facilities that can be accommodated and the number of accesses to the facility, an estimation step that estimates whether the facility can accept reservations, and information that is based on the estimation result in the estimation step is output to the user terminal Sending step.
  • An information processing program acquires the number of accesses to a facility from a predetermined time before receiving the information provision request in response to an information provision request from a user terminal to an information provision unit that provides facility information.
  • the facility it is estimated whether or not the facility can accept reservations from the number of facilities that can be accommodated and the number of accesses to the facility, and information based on the estimation result is provided to the user.
  • the facility by estimating the vacancy status of the facility from the number of accesses to the facility, it is possible to save labor for each facility to register or update the vacancy status by itself. Therefore, the facility reservation from the user can be accepted while reducing the load on the facility that manages the availability.
  • the acquisition unit acquires a total value of the number of reservations established between the facility and the user, and the estimation unit multiplies the accommodable number by a predetermined coefficient greater than 1.
  • the number of vacant seats of the facility may be obtained from the obtained total value, and it may be estimated that the facility having the vacant seat number equal to or larger than a predetermined threshold can be reserved.
  • the acquisition unit acquires the access rate by dividing the number of accesses to the facility page by the number that can be accommodated, and the estimation unit acquires a facility whose access rate is equal to or less than a predetermined threshold. It may be estimated that a reservation can be accepted.
  • the estimation unit calculates the number of vacant seats, estimates that the facility having the vacant seat number equal to or greater than a predetermined threshold can be reserved, If the acquisition unit cannot acquire the aggregate value, the acquisition unit acquires the access rate by dividing the number of accesses to the facility page by the accommodable number, and the estimation unit selects a facility whose access rate is equal to or less than a predetermined threshold. It may be estimated that a reservation can be accepted.
  • an instruction unit that instructs the acquisition unit and the estimation unit to perform processing when it is determined to provide information based on the estimation result to the application applicant based on an access history related to the application applicant May be further provided.
  • the access history includes a browsing history that is a record of a user browsing the facility page
  • the instruction unit is configured to apply a plurality of applicants within a predetermined time based on the browsing history.
  • the access history includes a communication history that is a record of communication between the user and the facility, and the instructing unit performs a plurality of applicants within a predetermined time based on the communication history.
  • the acquisition unit and the estimation unit may be instructed to perform processing.
  • the communication history is a mail history that is a record of the email between the user and the facility, and the instruction unit cannot analyze the email and reserve the email You may determine whether it corresponds to notification.
  • the communication history is a call history that is a record of a call between the user and the facility
  • the instructing unit is configured to apply a plurality of applicants within a predetermined time based on the communication history. If it is specified that the facility has been called, it may be determined that the applicant has received a reservation impossible notification from the plurality of facilities.
  • the estimation unit relaxes the conditions more than the estimation process and performs the estimation process again May be executed.
  • the communication history is a call history that is a record of a call between the user and the facility
  • the instructing unit is configured to apply a plurality of applicants within a predetermined time based on the communication history. If it is specified that the facility has been called, it may be determined that the applicant has received a reservation impossible notification from the plurality of facilities.
  • the reservation system 1 is a computer system that executes processing related to facility use reservation. For example, the reservation system 1 presents a facility that matches the search query, presents a vacancy status of facility use, or accepts a reservation for facility use in response to a request (information provision request) from the user terminal. By using the reservation system 1, the user can search for a desired facility and make a reservation at the facility.
  • the feature of the reservation system 1 is to present to the user a facility that is still vacant and can accept reservations, and this feature will be particularly described below.
  • the reservation system 1 accepts reservations for restaurants, but the present invention can also be applied to a system that manages reservations for facilities other than restaurants.
  • the present invention may be applied to reservation management of various facilities such as a stadium, a concert hall, a movie theater, a theater, and a hotel.
  • the reservation system 1 includes a user terminal T, a reservation server (information processing apparatus) 10, and a database group (storage unit) 20.
  • the user terminal T and the reservation server 10 are connected via a network such as the Internet.
  • the reservation server 10 can access the database group 20 via a network such as the Internet or a dedicated line.
  • FIG. 1 shows three user terminals T, the number of user terminals T is not limited.
  • the type of the user terminal T is not limited, and may be, for example, a stationary or portable personal computer, or a portable terminal such as a high-function mobile phone (smart phone), a mobile phone, or a personal digital assistant (PDA).
  • a portable terminal such as a high-function mobile phone (smart phone), a mobile phone, or a personal digital assistant (PDA).
  • PDA personal digital assistant
  • the concept of reservation management in the reservation system 1 is shown in Figs.
  • the reservation system 1 provides a restaurant search site (information providing means) to the user.
  • the user can search for a favorite restaurant through this site, and can make a reservation notification to the restaurant.
  • FIG. 2 is a screen including conditions for narrowing down restaurants and a list of restaurants.
  • This screen has a text box and search button for searching for restaurants by entering any word, a check box for displaying only restaurants that can be reserved, and a menu for narrowing down restaurants by category or area. Includes links.
  • a list of restaurants is displayed as an initial value or a search result. Each store name in the list is displayed as a link to a page indicating the detailed information of the restaurant, and when the user clicks the link, the detail page of the selected restaurant is displayed. In this specification, this detailed page is also referred to as a “restaurant page (facility page)”.
  • FIG. 1 An example of a restaurant page is shown in FIG.
  • the user can know the telephone number, menu, map, etc. of the selected restaurant by accessing this detail page.
  • the user can apply for a reservation to the restaurant by pressing the “Reserve from Web” button. If the user terminal T has a call function, the user can call the restaurant by pressing a “call” button.
  • Reservation system 1 introduces restaurants that can be reserved to users who are not able to make reservations because the restaurants they contact are full.
  • FIG. 4 is a diagram showing an overview of such features of the reservation system 1.
  • FIG. 4 shows that the applicant wants to make a reservation at restaurants A, B, and C but all fail.
  • the reservation system 1 presents a restaurant that is estimated to be able to accept reservations to the applicant. Specifically, the reservation system 1 selects a restaurant that is estimated to have a space based on information (accommodation capacity information) indicating the capacity of each restaurant and the history of access to each restaurant page. Introduce to the user as vacancy information. In the example of FIG. 4, restaurants P, Q, and R are presented to the user as restaurants that can be reserved.
  • the capacity (number of seats) of a restaurant is basic information of the facility, and is not information that the restaurant updates every time a reservation is accepted.
  • the access history is information that is automatically stored in the reservation system 1 and is not of a nature that each restaurant registers. Therefore, in this reservation system 1, it is not necessary for each restaurant to register or update the reservation status or the availability status in order to provide availability information.
  • the database group 20 is a collection of various databases necessary for the reservation system 1.
  • the installation location of each database is arbitrary, for example, each database may be gathered in one place, and may be installed in different places.
  • the manager of each database may be the same person or different from each other.
  • the restaurant database 21 is a device that stores information on each restaurant.
  • This restaurant information (facility information) can be said to be basic information of a restaurant as posted on a restaurant page.
  • restaurant information is a record in which a restaurant ID that uniquely identifies a restaurant and an attribute of the restaurant are associated with each other.
  • the name, location, telephone number, e-mail address, restaurant page URL, capacity (capacity), Web reservation availability, category, price range, etc. are shown as restaurant attribute items.
  • the item of attribute information is not limited to these.
  • the access history database 22 is a device that stores a user's access history to restaurants. As long as the data indicates that the user has accessed the restaurant in some form, the data recorded as the access history is not limited.
  • FIG. 6 is a diagram illustrating a reservation history indicating reservations that have been confirmed for each restaurant. Reservation of a restaurant seat is established when a user accesses the facility using a communication means such as a telephone or Web reservation. Therefore, it can be said that this reservation history is a user access history to the restaurant.
  • the reservation history is a record in which a user ID that uniquely identifies a user who has made a reservation, a restaurant ID, and reservation contents are associated with each other.
  • the scheduled use date and time (reservation date and time), the number of people, the contact information of the reservation person, and the like are shown as details of the reservation, but the items of reservation content are not limited to these.
  • the record of the reservation history is deleted when the reservation is canceled, when the reserved use ends, or periodically.
  • FIG. 7 shows a browsing history indicating that the user browsed the restaurant page.
  • the browsing history is a record indicating that the restaurant page is displayed on the user terminal T. Since browsing the Web site means that the user has accessed the facility using the user terminal T, this browsing history is also an access history.
  • the browsing history includes a user ID, a session ID that identifies an HTTP session, a restaurant ID, the URL of the accessed restaurant page, the access start date and time, and the end date and time.
  • the browsing history may include items other than these.
  • the restaurant ID is obtained by referring to the restaurant database 21 based on the accessed URL.
  • FIG. 8 shows an access history (search history) indicating a search query designated and transmitted by each user terminal T.
  • search history a record in which a user ID, a session ID, a query for product search, and a search date and time are associated with each other is accumulated as an access history.
  • the search query includes the date and time when the user wants to use it and the number of participants.
  • the search query may include other conditions such as a restaurant category, an area where the restaurant is located, and a price range.
  • FIG. 9 shows the history (email history) of the email transmitted between the user and the restaurant.
  • the mail history is a kind of record (communication history) of communication between the user and the restaurant.
  • the mail history is a record in which the sender's mail address, destination address, transmission date / time, reception date / time, and mail text are associated with each other.
  • the mail history may include items other than these.
  • the mail history may be a mailbox itself managed by a mail server (not shown). In this case, the mailbox is a part or all of the access history database 22. Alternatively, the mail history may be a copy of the mailbox.
  • FIG. 10 shows a history of calls made between the user and the restaurant (call history).
  • This call history is also a kind of communication history.
  • the call history is a record in which a calling number, a called number, a call start date and time, and a call end date and time are associated with each other.
  • the call history may include items other than these.
  • the communication history may be obtained by accumulating a call history of the user terminal T having a call function in a predetermined storage device.
  • the user terminal T when one restaurant page is continuously displayed on the user terminal T for a predetermined time or longer (for example, 10 minutes or longer), the user terminal T, the reservation server 10, or another monitoring server It may be determined that a call has been made, and a call history including the user and restaurant phone numbers may be generated and stored in the access history database 22.
  • a predetermined time or longer for example, 10 minutes or longer
  • the user database 23 is a device that stores user information. As shown in FIG. 11, the user information is a record in which a user ID and a user attribute are associated with each other. In the example of FIG. 11, the name, telephone number, and mail address are shown as user attribute items, but the attribute information items are not limited to these.
  • each database and each record described above is not limited to that shown above, and any normalization or redundancy may be performed for each database.
  • the restaurant ID and the URL of the website have a one-to-one correspondence, and the other can be derived from one of these two items, so the restaurant ID may be omitted in the browsing history.
  • the user ID and restaurant ID may be added to the mail history or the call history.
  • the hardware configuration of the reservation server 10 is as shown in FIG.
  • the reservation server 10 includes a CPU 101 that executes an operating system, application programs, and the like, a main storage unit 102 that includes a ROM and a RAM, an auxiliary storage unit 103 that includes a hard disk, a flash memory, and the like, and a network card or wireless
  • the communication control unit 104 includes a communication module, an input device 105 such as a keyboard and a mouse, and an output device 106 such as a display.
  • Each functional component of the reservation server 10 described later reads predetermined software on the CPU 101 or the main storage unit 102, and operates the communication control unit 104, the input device 105, the output device 106, and the like under the control of the CPU 101. This is realized by reading and writing data in the main storage unit 102 or the auxiliary storage unit 103. Data and a database necessary for processing are stored in the main storage unit 102 or the auxiliary storage unit 103.
  • the reservation server 10 is composed of one computer, but the reservation server 10 may be composed of a plurality of computers.
  • the reservation server 10 includes an instruction unit 11, an estimation unit (also serving as an acquisition unit) 12, and a transmission unit 13 as functional components.
  • the instruction unit 11 is a functional element that determines whether or not it is necessary to provide empty information to the user (applicant), and instructs the creation of empty information when it is determined that it is necessary.
  • the method for determining whether or not to create vacancy information is not limited, and the instruction unit 11 can perform the determination by the following method, for example.
  • the instruction unit 11 outputs an instruction signal to the estimation unit 12.
  • the instructing unit 11 may estimate the behavior of the user who is accessing the restaurant search site based on the browsing history and determine whether to provide the empty information to the user. Specifically, the instruction unit 11 provides empty information to the user when the user accesses a predetermined number or more of restaurant pages in one session.
  • the threshold value THa used for this determination is not limited.
  • the threshold value THa may be an arbitrary number between 2 and 10.
  • the instructing unit 11 refers to the access history database 22 and identifies a user who is accessing a restaurant page that is equal to or higher than the threshold THa in the currently ongoing session.
  • indication part 11 may determine with providing empty information to the user, when the stay time in the whole restaurant search site is more than predetermined time.
  • the instruction unit 11 identifies the search query used by each user. Specifically, the instruction unit 11 reads a search query corresponding to the user ID and the current session ID. The instruction unit 11 generates one or more pairs of user IDs and search queries, and outputs the generated data to the estimation unit 12 as an instruction signal. When the user's search query cannot be acquired, the instruction unit 11 may set the user's search query to a null value (NULL).
  • NULL null value
  • the instruction unit 11 ends the process without generating the instruction signal.
  • the instructing unit 11 may estimate the behavior of the user accessing the restaurant search site based on the mail history, and determine whether or not to provide free information to the user. Specifically, the instruction unit 11 provides empty information to the user who has received a notification from the restaurant that the reservation cannot be accepted.
  • the instructing unit 11 refers to all the mail history in the access history database 22 generated during a predetermined time after the current time, and specifies the mail including text in the text indicating that the reservation cannot be accepted. Hereinafter, this mail is referred to as “reservation impossible notification”.
  • the instruction unit 11 performs the specifying process by text search using a preset keyword.
  • the search range of the mail history that is, how long the past mail history is referred to may be arbitrarily set. For example, the time interval may be any value between 10 minutes and 3 hours.
  • the instructing unit 11 specifies a user who should provide free information by referring to the user database 23 based on the address of the sender or destination indicated by the specified mail history.
  • the instruction unit 11 uses the mail history to identify a user whose reservation has been refused by a restaurant even once. As another method, the instruction unit 11 may extract only users who have received a plurality of reservation impossible notifications.
  • the threshold value THb can be set arbitrarily, and may be set to any value between 2 and 5, for example.
  • the instruction unit 11 refers to the search history and reads a search query corresponding to the user ID and the current session ID.
  • the instruction unit 11 generates one or more pairs of user IDs and search queries, and outputs the generated data to the estimation unit 12 as an instruction signal.
  • the instruction unit 11 sets the user's search query to a null value (NULL).
  • the instruction unit 11 ends the process without generating the instruction signal.
  • the instructing unit 11 may estimate the behavior of the user accessing the restaurant search site based on the call history and determine whether or not to provide free information to the user. Specifically, the instruction unit 11 provides empty information to a user who has called a plurality of restaurants while going back a predetermined time from the current time.
  • the instructing unit 11 accesses the access history database 22, refers to all the call histories generated during a predetermined time from the current time, and identifies users who have called a plurality of restaurants during that time.
  • the threshold THc of the number of restaurants used for this specification can be arbitrarily set, and may be set to any of 2 to 5, for example.
  • the search range of the call history that is, how long the call history from the present to the past may be arbitrarily set. For example, the time interval may be any value between 10 minutes and 3 hours.
  • the instructing unit 11 refers to the user database 23 based on the transmission number or the incoming call number indicated in the call history, and specifies the user who should provide the free information.
  • the instruction unit 11 refers to the search history and reads a search query corresponding to the user ID and the current session ID.
  • the instruction unit 11 generates one or more pairs of user IDs and search queries, and outputs the generated data to the estimation unit 12 as an instruction signal.
  • the instruction unit 11 sets the user's search query to a null value (NULL).
  • the instruction unit 11 ends the process without generating the instruction signal.
  • the call history has no communication content, so even if the call history itself is viewed, it cannot be determined whether or not a reservation has been made by the call. Therefore, the instruction unit 11 sends empty information on the premise that there is a possibility that a user who has called a plurality of restaurants has not yet completed a reservation (there is a possibility that a reservation impossible notification has been received). Identify the users that should be.
  • the estimation unit 12 is a functional element that estimates the availability of each restaurant and extracts restaurants that can accept reservations for applicants based on the estimation result.
  • the estimation part 12 will start the extraction process, if an instruction
  • the instruction signal includes one or more pairs of a user ID and a search query.
  • the estimation unit 12 performs a search for restaurants that can accept reservations for each user.
  • the flow of extraction processing for one user ID will be described.
  • the estimation unit 12 can extract a vacant restaurant using various methods as described below.
  • the estimation unit 12 may extract a restaurant having a vacant seat by calculating the number of vacant seats of each restaurant corresponding to the desired date and time. Specifically, the estimation unit 12 refers to the reservation history and totals the number of reservations of each restaurant corresponding to the user's desired date and time. Then, the estimation part 12 calculates
  • requires the number of empty seats of each restaurant by a following formula. Capacity can be obtained from restaurant information. (Number of seats available) (Capacity)-(Total number of people reserved)
  • restaurant A has a capacity of 80 (persons) and reservations R1, R2, and R3 are in restaurant A at the user's desired date and time and the number of reservations is 10, 4, and 2, respectively, vacant seats
  • the estimation unit 12 may obtain the number of vacant seats by multiplying the number of reservations obtained from the reservation history in the access history database 22 by a coefficient ⁇ .
  • ⁇ > 1.
  • the method for determining the coefficient ⁇ is arbitrary.
  • the coefficient ⁇ may be determined based on the number of other websites or the number of accesses of each website.
  • the threshold value THd may be the number of people specified in the user's search query, or may be a fixed value (for example, an arbitrary value between 2 and 10).
  • the threshold value THd may be different for each restaurant or for each restaurant attribute (genre, area, price range, etc.). If the number of people specified in the search query is used, restaurants that match the user's wishes can be extracted. On the other hand, when a fixed value is used, restaurants can be narrowed down even if the number of people is not specified in the search query.
  • the estimation unit 12 outputs the finally extracted restaurant list together with the calculated number of vacant seats of each restaurant to the transmission unit 13.
  • the estimation unit 12 may determine whether or not the restaurant can be reserved based on the browsing history of the Web page of the restaurant. Specifically, the estimation unit 12 obtains the number of accesses to each restaurant page by counting the browsing history generated for a predetermined time from the current time for each restaurant.
  • the predetermined time may be arbitrarily set, and may be, for example, one day, one week, or one month. Generally, restaurants have busy periods and quiet periods, and the predetermined time may be changed according to the periods.
  • the estimation part 12 calculates
  • requires the value which divided the number of accesses about each restaurant by the accommodation capacity as an access rate. That is, in this specification, the access rate is obtained by the following equation. (Access rate) (Number of accesses) / (Capacity)
  • the “reservable flag OFF” is associated with the restaurant.
  • the method for setting the threshold value THe is not limited.
  • the threshold value THe may be set after estimating a general ratio of the number of reservation applications to the number of accesses. In this case, since it is unlikely that all the accessing users will apply for a reservation, the threshold value THe may be set to a value larger than 1 (for example, an arbitrary value between 2 and 10). By using the browsing history in this way, it is possible to estimate the availability of restaurants even when the number of reservations cannot be specified.
  • the threshold value THe may be different for each restaurant or for each restaurant attribute (genre, area, price range, etc.).
  • the estimation unit 12 outputs a list of finally extracted restaurants.
  • the estimation unit 12 may execute the same estimation process again with relaxed conditions than the executed estimation process.
  • the estimation unit 12 may increase the number of restaurants shown to the user as places where reservations can be accepted by relaxing the condition for turning on the match flag. As means for relaxing the conditions, it is conceivable to expand or change the area of the restaurant, or to expand or change the price range. If the user has searched a plurality of times within one session, the estimating unit 12 may turn on a match flag of a restaurant corresponding to at least one of a plurality of search queries.
  • the estimation part 12 may increase the number of the restaurants shown to a user as a place which can accept reservation by relaxing the conditions which turn ON a reservation possible flag.
  • the estimation unit 12 may execute the estimation process again after lowering the value of the threshold THd from the previous time or raising the value of the threshold THe from the previous time.
  • the estimation unit 12 generates a list of restaurants that can be reserved for each user ID, and outputs the list to the transmission unit 13. In this process, in order to transmit basic information of each restaurant to the user terminal T, the estimation unit 12 extracts the information from the restaurant database 21 and includes it in the list.
  • the transmitting unit 13 is a functional element that transmits to the user terminal T empty information (information based on the estimation result) indicating the extracted restaurant, that is, the restaurant estimated to be able to accept reservations.
  • the transmission unit 13 transmits the input list as empty information to the user terminal T corresponding to the user ID.
  • the transmission unit 13 transmits corresponding free information to the terminal T of each user.
  • HTTP requests / HTTP responses are generated several times between the user terminal T and the reservation server 10 in the restaurant search site (step S11).
  • the instruction unit 11 specifies a user who cannot make a reservation, and instructs the estimation unit 12 to generate a list of restaurants that can be reserved for the user (step S12).
  • the instruction unit 11 can specify such a user based on the browsing history, the mail history, or the call history.
  • the estimation unit 12 estimates the number of seats at each restaurant (step S13). As described above, the estimation unit 12 can obtain the number of seats based on the reservation history or the browsing history. When the number of vacant seats is estimated for all stores (step S14; YES), the estimating unit 12 selects a restaurant that can accept reservations (step S15). Regarding this selection, various methods can be considered as described above. These steps S13 to S15 correspond to an acquisition step and an estimation step.
  • the transmission unit 13 edits empty information for display (for example, rearrangement as described later) if necessary (step S16), and transmits the empty information to the user terminal T. (Step S17, transmission step).
  • the user terminal T receives the empty information and displays it on the screen (step S18). As a result, a restaurant that can be reserved is displayed on the screen together with the number of vacant seats, so that the user can contact a restaurant that can be reserved based on this vacant information.
  • the user terminal T may display the vacant information in various ways as described below.
  • the user terminal T may display a list including only restaurants that are determined to be available for reservation. In this case, the user terminal T displays only restaurants where the reservation enable flag is ON.
  • the user terminal T may display the restaurants in descending order of the number of vacant seats or in ascending order of the access rate in order to preferentially display the restaurants where reservation is easy to secure.
  • the user terminal T may display only the restaurants located at the top (for example, only the restaurants up to the top 10).
  • the user terminal T may display the higher the restaurant with a higher degree of match with the search query specified by the applicant. In this case, the user terminal T displays a restaurant whose reservation enable flag and match flag are both ON higher than the other restaurants.
  • a restaurant closer to the current position of the user terminal T may be displayed higher.
  • the user terminal T obtains the current position of its own terminal by using a GPS (Global Positioning System) function, etc., and compares the current position with each restaurant information (location) to obtain restaurant information in the list. Rearrange.
  • GPS Global Positioning System
  • the user terminal T may display a list including both restaurants that are determined to be reserved and restaurants that are determined to be unreservable. In this case, the user terminal T sets the display order so that the restaurant whose reservation enable flag is ON is higher than the restaurant whose reservation enable flag is OFF. Also in this case, the user terminal T may rearrange the restaurants in descending order of the number of seats or in ascending order of the access rate.
  • the user terminal T may highlight only the restaurants determined to be reserved without highlighting the restaurants determined to be unreservable.
  • the highlighting method is not limited, and various methods such as changing the background color, disabling the mark, and pop-up display can be used.
  • the user terminal T may display a restaurant at the top, which cannot be reserved at the time when the user accesses it, but after that a vacant seat has become available and the reservation can be accepted.
  • the estimation unit 12 or the transmission unit 13 in the reservation server 10 records the history of vacant information in a predetermined database (not shown). Then, the estimation unit 12 compares the vacant information generated this time with the vacant information generated in the past, so that only the restaurant where the reservation enable flag has changed from OFF to ON has been changed to accept reservations. Is added.
  • the user terminal T may switch the display from the current page displayed on the screen to the empty information page, or pop up the empty information while leaving the current page. Also good.
  • the user terminal T inquires of the user whether or not the control can be executed before the page switching or the pop-up display, and switches the page for the first time when accepting an input of permission from the user. Or you may perform a pop-up display.
  • the vacancy information is displayed in various ways, but in any case, the vacancy information is displayed in a manner appealing to the applicant, so that the applicant can easily find a restaurant that can accept reservations. be able to.
  • the information processing program P includes a main module P10, an instruction module P11, an estimation module P12, and a transmission module P13.
  • the main module P10 is a part that comprehensively controls reservation management.
  • the functions realized by executing the instruction module P11, the estimation module P12, and the transmission module P13 are the same as the functions of the instruction unit 11, the estimation unit 12, and the transmission unit 13, respectively.
  • the information processing program P may be provided after being fixedly recorded on a tangible recording medium such as a CD-ROM, DVD-ROM, or semiconductor memory.
  • the information processing program may be provided via a communication network as a data signal superimposed on a carrier wave.
  • the availability of each restaurant is estimated from the accommodation capacity information of the restaurant and the access history to the restaurant, and the restaurant that can accept the user's reservation is Extracted based on the estimation result and provided to the user.
  • the labor for each restaurant to register or update the vacancy status by itself can be saved. Therefore, the restaurant reservation from the user can be accepted while reducing the load on the restaurant that manages the availability.
  • the applicant who cannot make a reservation is estimated based on the user's browsing history, mail history, or call history, and free information is presented to the applicant. Therefore, it is possible to avoid the user giving up the reservation halfway, and a restaurant having a vacant seat can have an opportunity to receive the reservation.
  • the reservation system 1 is convenient for both the user and the restaurant.
  • the control of the display of the empty information on the user terminal T may be performed by the reservation server 10, may be performed by the user terminal T, or both of them may be executed in cooperation.
  • the number of available seats may be omitted when vacant information is displayed.
  • the instruction unit 11 may output an instruction signal when a signal requesting free information is received from the user terminal T.
  • This request signal includes at least a user ID, and may include a search query for narrowing down restaurants.
  • the instruction unit 11 outputs the user ID or a pair of the user ID and the search query to the estimation unit 12 as an instruction signal.
  • the instruction unit 11 may acquire the search query from the search history in the access history database 22. Specifically, the instruction unit 11 may read a search query corresponding to the user ID and the latest session ID and include the search query in the instruction signal.

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

　一実施形態に係る情報処理装置は、取得部、推定部、および送信部を備える。取得部は、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する。推定部は、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する。送信部は、推定部による推定結果に基づく情報をユーザ端末に出力する。

Description

情報処理装置、情報処理方法、及び情報処理プログラム
　本発明の一形態は、ユーザの施設予約を支援する情報処理装置、情報処理方法、及び情報処理プログラムに関する。
　インターネットなどのネットワークを介し、新幹線や飛行機等の座席を指定して予約を行うことができるインターネット予約システムが知られている。また、ユーザ端末からの検索要求に応じて施設の空席情報をそのユーザ端末に送信するシステムが知られている。例えば下記特許文献１には、利用者が施設の時限的な空情報を閲覧することによって、容易に空情報のある施設を閲覧し予約することができる空情報提供システムが記載されている。このシステムは、施設端末から空情報を受信した場合には、空情報と空情報の登録時間とを施設データベースに登録し、施設端末から空情報の登録要請のみを受信した場合には、空情報の登録時間と予め定められた空情報とを施設データベースに登録する空情報受付手段と、ユーザ端末から受信した条件に合致する施設に関する情報、空情報、および空情報の登録時間を抽出して送信する空情報提供手段とを備える。
特開２００３－７６９０２号公報
　しかし、上記の空情報提供システムのような従来の手法では、座席を指定して予約を行うことができるインターネット予約システムとは異なり、施設側が絶えず施設の空き状況を登録または更新する必要があるため、施設にとってはその作業の負担が大きい。そのため、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることが可能な仕組みが求められている。
　本発明の一形態に係る情報処理装置は、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、推定部による推定結果に基づく情報をユーザ端末に出力する送信部とを備える。
　本発明の一形態に係る情報処理方法は、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得ステップと、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定ステップと、推定ステップにおける推定結果に基づく情報をユーザ端末に出力する送信ステップとを含む。
　本発明の一形態に係る情報処理プログラムは、施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、施設の収容可能数と該施設へのアクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、推定部による推定結果に基づく情報をユーザ端末に出力する送信部とをコンピュータに実行させる。
　このような形態によれば、施設の収容可能数とその施設へのアクセス数とから、その施設が予約受付可能か否かが推定され、その推定結果に基づく情報がユーザに提供される。このように、施設へのアクセス数から施設の空き状況を推定することで、個々の施設が自らその空き状況を登録または更新する手間が省かれる。したがって、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることができる。
　別の形態に係る情報処理装置では、取得部が、施設とユーザとの間で成立した予約の人数の集計値を取得し、推定部が、収容可能数と、１より大きい所定の係数が乗じられた集計値とから施設の空席数を求め、空席数が所定の閾値以上である施設を予約受付可能と推定してもよい。
　さらに別の形態に係る情報処理装置では、取得部が、施設ページへのアクセス数を収容可能数で割ることでアクセス率を取得し、推定部が、アクセス率が所定の閾値以下である施設を予約受付可能と推定してもよい。
　さらに別の形態に係る情報処理装置では、取得部が集計値を取得できる場合には、推定部が空席数を求めて該空席数が所定の閾値以上である施設を予約受付可能と推定し、取得部が集計値を取得できない場合には、取得部が施設ページへのアクセス数を収容可能数で割ることでアクセス率を取得し、推定部が、アクセス率が所定の閾値以下である施設を予約受付可能と推定してもよい。
　さらに別の形態に係る情報処理装置では、申込希望者に関するアクセス履歴に基づいて該申込希望者に推定結果に基づく情報を提供すると判定した場合に、取得部および推定部に処理を指示する指示部を更に備えてもよい。
　さらに別の形態に係る情報処理装置では、アクセス履歴が、ユーザが施設ページを閲覧した記録である閲覧履歴を含み、指示部が、閲覧履歴に基づいて、申込希望者が所定時間内に複数の施設ページにアクセスしたと判定した場合に、取得部および推定部に処理を指示してもよい。
　さらに別の形態に係る情報処理装置は、アクセス履歴が、ユーザと施設との通信の記録である通信履歴を含み、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設から予約不可通知を受けたと判定した場合に、取得部および推定部に処理を指示してもよい。
　さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との電子メールの記録であるメール履歴であり、指示部が、電子メールの内容を解析することで該電子メールが予約不可通知に該当するか否かを判定してもよい。
　さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との通話の記録である通話履歴であり、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設と電話したことを特定した場合に、該申込希望者が該複数の施設から予約不可通知を受けたと判定してもよい。
　さらに別の形態に係る情報処理装置では、推定部が、推定処理により得られた予約受付可能な施設の数が所定数以下である場合に、該推定処理よりも条件を緩和して再度推定処理を実行してもよい。
　さらに別の形態に係る情報処理装置では、通信履歴が、ユーザと施設との通話の記録である通話履歴であり、指示部が、通信履歴に基づいて、申込希望者が所定時間内に複数の施設と電話したことを特定した場合に、該申込希望者が該複数の施設から予約不可通知を受けたと判定してもよい。
　本発明の一側面によれば、空き状況を管理する施設の負荷を軽減しつつ、ユーザからの施設予約を受け付けることができる。
実施形態に係る予約システムの全体構成を示す図である。 飲食店検索サイトのＷｅｂページの例を示す図である。 飲食店検索サイトのＷｅｂページの例を示す図である。 実施形態における空き情報の提示の概念を示す図である。 飲食店情報の例を示す図である。 アクセス履歴（予約履歴）の例を示す図である。 アクセス履歴（閲覧履歴）の例を示す図である。 アクセス履歴（検索履歴）の例を示す図である。 アクセス履歴（メール履歴）の例を示す図である。 アクセス履歴（通話履歴）の例を示す図である。 ユーザ情報の例を示す図である。 実施形態に係る予約サーバのハードウェア構成を示す図である。 実施形態に係る予約サーバの機能構成を示すブロック図である。 実施形態に係る予約システムの動作を示すシーケンス図である。 実施形態に係る情報処理プログラムの構成を示す図である。
　以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。以下の実施形態では、本発明に係る情報処理装置を予約サーバに適用する。
　図１～１３を用いて、実施形態に係る予約システム１の機能および構成を説明する。予約システム１は施設利用の予約に関する処理を実行するコンピュータ・システムである。例えば、予約システム１はユーザ端末からの要求（情報提供要求）に応じて、検索クエリに合致する施設を提示したり、施設利用の空き状況を提示したり、施設利用の予約を受け付けたりする。ユーザはこの予約システム１を利用することで、希望する施設を探してその施設に予約を入れることができる。予約システム１の特徴は、まだ席が空いていて予約受付が可能な施設をユーザに提示する点にあるので、以下ではこの特徴について特に説明する。
　本実施形態では、予約システム１が飲食店の予約を受け付けることを前提とするが、本発明は飲食店以外の施設の予約を管理するシステムにも適用することができる。例えば、競技場、コンサート会場、映画館、劇場、ホテルなどの様々な施設の予約管理に本発明を適用してもよい。
　図１に示すように、予約システム１はユーザ端末Ｔ、予約サーバ（情報処理装置）１０、及びデータベース群（記憶部）２０を備えている。ユーザ端末Ｔと予約サーバ１０とはインターネットなどのネットワークを介して接続されている。予約サーバ１０はインターネットや専用線などのネットワークを介してデータベース群２０にアクセスできる。図１では３台のユーザ端末Ｔを示しているが、ユーザ端末Ｔの台数は限定されない。
　ユーザ端末Ｔの種類は限定されず、例えば据置型又は携帯型のパーソナルコンピュータでもよいし、高機能携帯電話機（スマートフォン）や携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末でもよい。
　予約システム１における予約管理の概念を図２～４に示す。予約システム１は飲食店検索サイト（情報提供手段）をユーザに提供する。ユーザはこのサイトを通じて好みの飲食店を検索したりその飲食店に予約の連絡を入れたりすることができる。
　図２の例は、飲食店を絞り込むための条件と飲食店のリストとを含む画面である。この画面は、任意の語句を入力して飲食店を検索するためのテキストボックスおよび検索ボタンと、予約可能な飲食店のみを表示させるためのチェックボックスと、カテゴリまたはエリアで飲食店を絞り込むためのリンクとを含んでいる。また、この画面には、初期値または検索結果として飲食店のリストが表示されている。リスト内の各店名は、その飲食店の詳細情報を示すページへのリンクとして表示されており、ユーザがそのリンクをクリックすると、選択された飲食店の詳細ページが表示される。本明細書ではこの詳細ページを「飲食店ページ（施設ページ）」ともいう。
　飲食店ページの例を図３に示す。ユーザはこの詳細ページにアクセスすることで、選択した飲食店の電話番号やメニュー、地図などを知ることができる。また、ユーザは「Ｗｅｂから予約」ボタンを押すことで、その飲食店に予約を申し込むことができる。ユーザ端末Ｔが通話機能を備えていれば、ユーザは「電話をかける」ボタンを押すことで、その飲食店に電話をすることができる。
　予約システム１は、連絡した飲食店がどこも満杯で予約を取ることができないユーザに予約可能な飲食店を紹介する。図４は、予約システム１のこのような特徴の概観を示す図である。
　飲食店の情報を提供する従来のＷｅｂサイトでは、ユーザはこれから予約しようとする飲食店の空き状況を知ることができない。したがって、ユーザが予約を取ろうした時点で既にその飲食店の席が埋まっていて、ユーザが予約に失敗することがある。この場合、一般にユーザはそのＷｅｂサイト内で別の飲食店を探して電話または当該Ｗｅｂサイト経由でその店に予約を試みる。しかし場合によっては、ユーザがいくつかの飲食店に連絡してもどの店も予約が一杯で、ユーザがなかなか予約を取り付けないことがある。図４は、申込希望者（ａｐｐｌｉｃａｎｔ）がレストランＡ，Ｂ，Ｃに予約を試みたがいずれも失敗したことを示している。
　このように予約ができない状況が続くと、ユーザが不満を抱いたり予約を諦めたりする可能性がある。一方、空席がある飲食店は顧客を掴む折角の機会を失うことにもなる。
　そこで、このように予約ができない状況が続いている場合に、予約システム１は、予約受付が可能であると推定される飲食店を申込希望者に提示する。具体的には、予約システム１は、各飲食店の収容能力を示す情報（収容能力情報）と、各飲食店ページへのアクセスの履歴とに基づいて、空きがあると推定される飲食店を空き情報（ｖａｃａｎｃｙ　ｉｎｆｏｒｍａｔｉｏｎ）としてユーザに紹介する。図４の例では、レストランＰ，Ｑ，Ｒが予約可能な飲食店としてユーザに提示されている。
　飲食店の収容能力（座席数）はその施設の基本情報であるから、予約を受け付ける度にその飲食店が更新する情報ではない。また、アクセス履歴は予約システム１にて自動的に蓄積される情報であって各飲食店が登録する性質のものではない。したがって、この予約システム１では、空き情報を提供するために、各飲食店に予約状況または空き状況を登録または更新させる必要がない。
　次に、予約サーバ１０によりアクセスされるデータベース群２０内の各データベースについて説明する。データベース群２０は、予約システム１で必要な各種データベースの集まりである。各データベースの設置場所は任意であり、例えば、各データベースが一箇所にまとめられていてもよいし、別々の場所に設置されていてもよい。各データベースの管理者は同一人であってもよいし互いに異なっていてもよい。
　飲食店データベース２１は、各飲食店の情報を記憶する装置である。この飲食店情報（施設情報）は、飲食店ページに掲載されるような飲食店の基本情報であると言える。図５に示すように、飲食店情報は、飲食店を一意に特定する飲食店ＩＤとその飲食店の属性とが関連付けられたレコードである。この図の例では名称、所在地、電話番号、メールアドレス、飲食店ページのＵＲＬ、収容能力（収容可能数）、Ｗｅｂ予約の可否、カテゴリ、価格帯などが飲食店属性の項目として示されているが、属性情報の項目はこれらに限定されるものではない。
　アクセス履歴データベース２２は、飲食店へのユーザのアクセス履歴を記憶する装置である。ユーザがなんらかの形で飲食店にアクセスしたことを示すデータであれば、アクセス履歴として記録されるデータは限定されない。
　アクセス履歴の例を図６～１０に示す。図６は、各飲食店の確定した予約を示す予約履歴を示す図である。飲食店の席の予約はユーザが電話やＷｅｂ予約などの通信手段を用いて施設にアクセスすることで成立するから、この予約履歴は飲食店へのユーザのアクセス履歴であると言える。図６に示すように、予約履歴は、予約を入れたユーザを一意に特定するユーザＩＤと、飲食店ＩＤと、予約内容とが互いに関連付けられたレコードである。この例では利用予定日時（予約日時）、人数、予約者の連絡先などが予約の詳細として示されているが、予約内容の項目はこれらに限定されるものではない。予約履歴のレコードは、予約がキャンセルされた場合、または予約された利用が終了した場合、または定期的に削除される。
　図７は、ユーザが飲食店ページを閲覧したことを示す閲覧履歴を示している。閲覧履歴は、ユーザ端末Ｔ上に飲食店ページが表示されたことを示す記録であると言い換えることができる。Ｗｅｂサイトの閲覧はユーザがユーザ端末Ｔを用いて施設にアクセスしたことを意味するから、この閲覧履歴もアクセス履歴である。図７に示すように、閲覧履歴はユーザＩＤと、ＨＴＴＰセッション（ＨＴＴＰ　ｓｅｓｓｉｏｎ）を特定するセッションＩＤと、飲食店ＩＤと、アクセスされた飲食店ページのＵＲＬと、アクセスの開始日時及び終了日時とが互いに関連付けられたレコードである。図７の例では、ユーザ「Ｕ００１」が１セッション「Ｓ００１」内で二つの飲食店ページにアクセスしていることがわかる。閲覧履歴はこれら以外の項目を含んでいてもよい。飲食店ＩＤはアクセスされたＵＲＬに基づいて飲食店データベース２１を参照することで得られる。
　図８は、各ユーザ端末Ｔで指定および送信された検索クエリを示すアクセス履歴（検索履歴）を示している。この例では、ユーザＩＤと、セッションＩＤと、商品検索のためのクエリと、検索日時とが互いに関連付けられたレコードがアクセス履歴として蓄積されている。検索クエリは利用を希望する日時と参加予定人数とを含んでいる。これに加えて、検索クエリは飲食店のカテゴリ、飲食店が位置するエリア、価格帯などの他の条件を含んでいてもよい。
　図９は、ユーザと飲食店との間で伝達された電子メールの履歴（メール履歴）を示している。メール履歴は、ユーザと飲食店との通信の記録（通信履歴）の一種である。図９に示すように、メール履歴は差出人のメールアドレス、宛先アドレス、送信日時、受信日時、およびメール本文が互いに関連付けられたレコードである。メール履歴はこれら以外の項目を含んでいてもよい。メール履歴は、図示しないメールサーバにより管理されているメールボックスそのものであってもよく、その場合にはそのメールボックスはアクセス履歴データベース２２の一部または全部である。あるいは、メール履歴は、そのメールボックスのコピーであってもよい。
　図１０は、ユーザと飲食店との間で為された通話の履歴（通話履歴）を示している。この通話履歴も通信履歴の一種である。図１０に示すように、通話履歴は発信番号、着信番号、通話開始日時、および通話終了日時が互いに関連付けられたレコードである。通話履歴はこれら以外の項目を含んでいてもよい。通信履歴は、通話機能を有するユーザ端末Ｔの通話履歴を所定の記憶装置に蓄積したものであってもよい。あるいは、ユーザ端末Ｔにおいて一つの飲食店ページが所定時間以上（例えば１０分以上）連続して表示されている場合に、ユーザ端末Ｔ、予約サーバ１０、または他の監視サーバが、ユーザが飲食店に電話をしたと判定して、当該ユーザおよび飲食店の電話番号を含む通話履歴を生成しアクセス履歴データベース２２に格納してもよい。
　ユーザ・データベース２３は、ユーザ情報を記憶する装置である。図１１に示すように、ユーザ情報はユーザＩＤとユーザの属性とが関連付けられたレコードである。図１１の例では名前、電話番号、およびメールアドレスがユーザ属性の項目として示されているが、属性情報の項目はこれらに限定されるものではない。
　上記の各データベースおよび各レコードの構成は上記で示すものに限定されず、各データベースに対して任意の正規化又は冗長化を行ってよい。例えば、飲食店のＩＤとそのＷｅｂサイトのＵＲＬとは１対１の対応関係を有し、これら２項目の一方から他方を導くことができるので、閲覧履歴において飲食店ＩＤを省略してもよい。あるいは、メール履歴または通話履歴にユーザＩＤおよび飲食店ＩＤを付加してもよい。
　次に、予約サーバ１０について説明する。予約サーバ１０のハードウェア構成は図１２に示す通りである。予約サーバ１０は、オペレーティングシステムやアプリケーション・プログラムなどを実行するＣＰＵ１０１と、ＲＯＭ及びＲＡＭで構成される主記憶部１０２と、ハードディスクやフラッシュメモリなどで構成される補助記憶部１０３と、ネットワークカードあるいは無線通信モジュールで構成される通信制御部１０４と、キーボードやマウスなどの入力装置１０５と、ディスプレイなどの出力装置１０６とを備えている。
　後述する予約サーバ１０の各機能的構成要素は、ＣＰＵ１０１又は主記憶部１０２の上に所定のソフトウェアを読み込ませ、ＣＰＵ１０１の制御の下で通信制御部１０４や入力装置１０５、出力装置１０６などを動作させ、主記憶部１０２又は補助記憶部１０３におけるデータの読み出し及び書き込みを行うことで実現される。処理に必要なデータやデータベースは主記憶部１０２又は補助記憶部１０３内に格納される。
　図１２では予約サーバ１０が１台のコンピュータで構成されているが、予約サーバ１０は複数台のコンピュータで構成されていてもよい。
　図１３に示すように、予約サーバ１０は機能的構成要素として指示部１１、推定部（取得部も兼ねる）１２、および送信部１３を備えている。
　指示部１１は、ユーザ（申込希望者）への空き情報の提供が必要であるか否かを判定し、それが必要であると判定した場合に空き情報の作成を指示する機能要素である。空き情報を作成するか否かの判定方法は限定されず、指示部１１は例えば下記の手法によりその判定を行うことができる。空き情報の作成が必要であると判定した場合には、指示部１１は指示信号を推定部１２に出力する。
　［閲覧履歴の利用］
　指示部１１は、飲食店検索サイトにアクセスしているユーザの行動を閲覧履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、ユーザが１セッションにおいて所定数以上の飲食店ページにアクセスしている場合に、そのユーザに空き情報を提供する。この判定に用いる閾値ＴＨａは限定されない。例えばその閾値ＴＨａは２～１０の間の任意の数であってもよい。指示部１１はアクセス履歴データベース２２を参照して、現在継続中のセッションにおいて閾値ＴＨａ以上の飲食店ページにアクセスしているユーザを特定する。あるいは、指示部１１は、飲食店検索サイト全体での滞在時間が所定時間以上の場合に、空き情報をそのユーザに提供すると判定してもよい。
　一以上のユーザを特定できた場合には、指示部１１はその各ユーザが用いた検索クエリを特定する。具体的には、指示部１１はユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。なお、ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定すればよい。
　一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。
　［メール履歴の利用］
　指示部１１は、飲食店検索サイトにアクセスしているユーザの行動をメール履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、予約の受付ができない旨の連絡を飲食店から受信したユーザに空き情報を提供する。
　指示部１１は、現在時刻から所定時間だけ遡る間に生成されたアクセス履歴データベース２２内のメール履歴をすべて参照し、予約受付ができないことを示すテキストを本文に含むメールを特定する。以下ではこのメールを「予約不可通知」という。指示部１１は、予め設定したキーワードを用いたテキスト検索によりその特定処理を実行する。メール履歴の検索範囲、すなわち現在からどれくらい過去までのメール履歴を参照するかは任意に設定してよい。例えばその時間間隔は１０分～３時間の間の任意の値であってよい。続いて、指示部１１は特定したメール履歴で示される差出人または宛先のアドレスに基づいてユーザ・データベース２３を参照することで、空き情報を提供すべきユーザを特定する。
　指示部１１はメール履歴を用いることで、最近一回でも飲食店から予約を断られたユーザを特定することになる。別の手法として、指示部１１は複数の予約不可通知を受信したユーザのみを抽出してもよい。その閾値ＴＨｂは任意に設定可能であり、例えば２～５の間のいずれかに設定してもよい。
　一以上のユーザを特定できた場合には、指示部１１は検索履歴を参照して、ユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定する。
　一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。
　［通話履歴の利用］
　指示部１１は、飲食店検索サイトにアクセスしているユーザの行動を通話履歴に基づいて推定し、空き情報をそのユーザに提供するか否かを判定してもよい。具体的には、指示部１１は、現在時刻から所定時間だけ遡る間に複数の飲食店に電話したユーザに空き情報を提供する。
　指示部１１はアクセス履歴データベース２２にアクセスして、現在時刻から所定時間だけ遡る間に生成された通話履歴をすべて参照し、その時間の間に複数の飲食店に電話したユーザを特定する。この特定に用いる飲食店数の閾値ＴＨｃは任意に設定可能であり、例えば２～５のいずれかに設定してもよい。通話履歴の検索範囲、すなわち現在からどれくらい過去までの通話履歴を参照するかは任意に設定してよい。例えばその時間間隔は１０分～３時間の間の任意の値であってよい。続いて、指示部１１は通話履歴で示される発信番号または着信番号に基づいてユーザ・データベース２３を参照することで、空き情報を提供すべきユーザを特定する。
　一以上のユーザを特定できた場合には、指示部１１は検索履歴を参照して、ユーザＩＤおよび現在のセッションＩＤに対応する検索クエリを読み出す。そして、指示部１１はユーザＩＤおよび検索クエリのペアを１以上生成し、生成したそのデータを指示信号として推定部１２に出力する。ユーザの検索クエリを取得できなかった場合には、指示部１１はそのユーザの検索クエリを空値（ＮＵＬＬ）に設定する。
　一人のユーザも特定できなかった場合には、指示部１１はその指示信号を生成することなく処理を終了する。
　メール履歴とは異なり通話履歴は通信内容を持たないので、通話履歴そのものを見ても、その電話により予約が成立したか否かを判定することができない。そこで、指示部１１は、複数の飲食店に電話したユーザは予約をまだ完了していない可能性がある（予約不可通知を受けた可能性がある）との前提に立って、空き情報を送るべきユーザを特定する。
　推定部１２は、各飲食店の空き状況を推定し、申込希望者の予約を受付可能な飲食店をその推定結果に基づいて抽出する機能要素である。推定部１２は指示信号を受け付けるとその抽出処理を開始する。
　上述したように、指示信号はユーザＩＤおよび検索クエリのペアを一つまたは複数含む。推定部１２は予約を受付可能な飲食店の検索をユーザ毎に実行する。以下では、一つのユーザＩＤに対する抽出処理の流れを説明する。推定部１２は以下に示すような様々な方法を用いて空きのある飲食店を抽出することができる。
　［予約履歴の利用］
　推定部１２は、希望日時に相当する各飲食店の空席数を算出することで空席を有する飲食店を抽出してもよい。具体的には、推定部１２は予約履歴を参照して、ユーザの希望日時に相当する各飲食店の予約人数を集計する。続いて、推定部１２は各飲食店の空席数を下記式により求める。収容能力は飲食店情報から得ることができる。
　（空席数）＝（収容能力）－（合計予約人数）
　例えば、レストランＡの収容能力が８０（人）であり、ユーザの希望日時においてレストランＡに予約Ｒ１，Ｒ２，Ｒ３が入っており、各予約の人数がそれぞれ１０、４、２であれば、空席数は８０－（１０＋４＋２）＝６４である。
　飲食店の予約が予約システム１以外の他の予約システムからも可能である場合には、飲食店の空席数が上記の式で求まる値よりも少ないことが考えられる。そこで、推定部１２は、アクセス履歴データベース２２内の予約履歴から求まる予約人数に係数αを乗じた上で空席数を求めてもよい。ここで、α＞１である。係数αの決定方法は任意である。例えば、他のウェブサイトの個数や各ウェブサイトのアクセス数などに基づいて係数αを決めてよい。
　例えば、上記レストランＡに関する例においてα＝３とすれば、推定空席数は８０－３×（１０＋４＋２）＝３２となる。
　このように各飲食店の空席数を求めた後、推定部１２は、空席数が所定の閾値ＴＨｄ以上である飲食店に対して「予約可能フラグ＝ＯＮ」を関連付け、空席数が閾値ＴＨｄ未満である飲食店に対して「予約可能フラグ＝ＯＦＦ」を関連付ける。ここで、この閾値ＴＨｄはユーザの検索クエリで指定されている人数であってもよいし、固定値（例えば２～１０の間の任意の値）であってもよい。閾値ＴＨｄは飲食店毎または飲食店の属性（ジャンル、エリア、価格帯など）毎に異ならせてもよい。検索クエリで指定されている人数を用いれば、ユーザの希望に合致する飲食店を抽出することができる。一方、固定値を用いた場合には、検索クエリに人数が指定されていなくても飲食店を絞り込むことができる。
　検索クエリにカテゴリやエリアなどの他の条件が指定されている場合には、推定部１２は、予約可能フラグがＯＮである飲食店のうちその条件を満たす飲食店に「一致フラグ＝ＯＮ」を関連付け、その条件を満たさなかった飲食店に「一致フラグ＝ＯＦＦ」を関連付ける。他の条件が指定されていなければ、推定部１２はすべての飲食店について一致フラグをＯＮに設定する。
　続いて、推定部１２は最終的に抽出した飲食店のリストを、算出した各飲食店の空席数と共に送信部１３に出力する。
　［閲覧履歴の利用］
　飲食店の予約履歴を取得できない場合には、推定部１２はその飲食店のＷｅｂページの閲覧履歴に基づいて当該飲食店の予約の可否を判定してもよい。具体的には、推定部１２は現在時刻から所定時間だけ遡る間に生成された閲覧履歴を飲食店毎に数えることで、各飲食店ページへのアクセス数を求める。ここで、その所定時間は任意に設定してよく、例えば１日、１週間、１ヵ月でもよい。一般に飲食店には繁忙期および閑散期があるので、その時期に応じてその所定時間を変更してもよい。続いて、推定部１２は各飲食店についてそのアクセス数を収容能力で割った値をアクセス率として求める。すなわち、本明細書において、アクセス率は下記式により求まる。
　（アクセス率）＝（アクセス数）／（収容能力）
　例えば、レストランＡの収容能力が８０（人）であり、集計されたレストランＡのＷｅｂページのアクセス数が１２０であったならば、アクセス率は１２０／８０＝１．５である。
　このように各飲食店のアクセス率を求めた後、推定部１２は、アクセス率が所定の閾値ＴＨｅ未満である飲食店に対して「予約可能フラグ＝ＯＮ」を関連付け、アクセス率が閾値ＴＨｅ以上である飲食店に対して「予約可能フラグ＝ＯＦＦ」を関連付ける。閾値ＴＨｅの設定方法は限定されない。例えば、アクセス数に対する予約申込数の一般的な割合を推定した上で閾値ＴＨｅを設定してもよい。この場合には、アクセスしたユーザの全員が予約を申し込むとは考えにくいことから、閾値ＴＨｅを１より大きな値（たとえば２～１０の間の任意の値）にしてもよい。このように閲覧履歴を用いることで、予約数を特定できない場合にも飲食店の空き状況を推定することができる。閾値ＴＨｅは飲食店毎または飲食店の属性（ジャンル、エリア、価格帯など）毎に異ならせてもよい。
　検索クエリにカテゴリやエリアなどの他の条件が指定されている場合には、推定部１２は、予約可能フラグがＯＮである飲食店のうちその条件を満たす飲食店に「一致フラグ＝ＯＮ」を関連付け、その条件を満たさなかった飲食店に「一致フラグ＝ＯＦＦ」を関連付ける。他の条件が指定されていなければ、推定部１２はすべての飲食店について一致フラグをＯＮに設定する。
　続いて、推定部１２は最終的に抽出した飲食店のリストを出力する。この際に、推定部１２は、各飲食店のアクセス数から予約数を推定し、収容能力からその予約数を引いた値を空席数としてリストと共に送信部１３に出力してもよい。例えば、上記レストランＡでは８件に１件の割合で予約が成立していると仮定し、アクセス数が１２０であったならば、推定部１２は予約数を１２０／８＝１５であると推定して、空席数を８０－１５＝６５と推定する。
　予約可能フラグおよび一致フラグが共にＯＮである飲食店の個数が所定数以下であれば、推定部１２は、実行した推定処理よりも条件を緩和して再度同じ推定処理を実行してもよい。
　例えば、推定部１２は一致フラグをＯＮにする条件を緩和することで、予約受付可能な場所としてユーザに示す飲食店の個数を増やしてもよい。条件を緩和する手段としては、飲食店のエリアを拡張するかまたは変更したり、価格帯を拡張するかまたは変更したりすることが考えられる。ユーザが１セッション内で複数回検索したのであれば、推定部１２は複数の検索クエリの少なくとも一つに該当する飲食店の一致フラグをＯＮにしてもよい。
　あるいは、推定部１２は予約可能フラグをＯＮにする条件を緩和することで、予約受付可能な場所としてユーザに示す飲食店の個数を増やしてもよい。例えば、推定部１２は閾値ＴＨｄの値を前回よりも下げるか、または閾値ＴＨｅの値を前回よりも上げた上で、再度推定処理を実行してもよい。
　推定部１２は、予約可能な飲食店のリストを各ユーザＩＤについて生成し、送信部１３に出力する。この処理において推定部１２は、各飲食店の基本情報もユーザ端末Ｔに送信するために、その情報を飲食店データベース２１から抽出してリストに含める。
　送信部１３は、抽出された飲食店、すなわち予約受付が可能であると推定される飲食店を示す空き情報（推定結果に基づく情報）をユーザ端末Ｔに送信する機能要素である。送信部１３は入力されたリストを空き情報として、ユーザＩＤに対応するユーザ端末Ｔに送信する。複数のユーザに空き情報を提示する場合には、送信部１３は各ユーザの端末Ｔに向けて、対応する空き情報を送信する。
　次に、図１４を用いて、予約システム１の動作を説明するとともに本実施形態に係る情報処理方法について説明する。以下では、ユーザが端末Ｔを介して飲食店予約サイトにアクセスし、店を検索したり、各飲食店のページを閲覧したり、Ｗｅｂ予約を試みたりしているが、なかなか予約できないでいることを前提として、その後の処理を説明する。この場合には、飲食店検索サイトにおいてユーザ端末Ｔと予約サーバ１０との間に何度かＨＴＴＰリクエスト／ＨＴＴＰレスポンス（ＨＴＴＰ　ｒｅｑｕｅｓｔ／ＨＴＴＰ　ｒｅｓｐｏｎｓｅ）が発生している（ステップＳ１１）。
　このとき予約サーバ１０では、指示部１１が、予約できないでいるユーザを特定して、そのユーザのために予約可能な飲食店のリストを生成するように推定部１２に指示する（ステップＳ１２）。上述したように、指示部１１は閲覧履歴、メール履歴、あるいは通話履歴に基づいてそのようなユーザを特定することができる。
　続いて、推定部１２が各飲食店の空席数を推定する（ステップＳ１３）。上述したように、推定部１２は予約履歴または閲覧履歴に基づいて空席数を求めることができる。すべての店舗について空席数の推定を行うと（ステップＳ１４；ＹＥＳ）、推定部１２は予約受付可能な飲食店を選択する（ステップＳ１５）。この選択に関しても、上記の通り様々な手法が考えられる。これらステップＳ１３～Ｓ１５は取得ステップおよび推定ステップに相当する。
　続いて、送信部１３が、必要であれば表示のための空き情報の編集（例えば、後述するような並べ替え）を行った上で（ステップＳ１６）、その空き情報をユーザ端末Ｔに送信する（ステップＳ１７、送信ステップ）。
　ユーザ端末Ｔは、その空き情報を受信して画面上に表示する（ステップＳ１８）。これにより、予約可能な飲食店がその空席数と共に画面上に表示されるので、ユーザはこの空き情報に基づいて、予約が可能と思われる飲食店に連絡することができる。
　ユーザ端末Ｔは下記のような様々な態様により空き情報を表示してよい。
　例えば、ユーザ端末Ｔは予約可能であると判定された飲食店のみを含むリストを表示してもよい。この場合には、ユーザ端末Ｔは予約可能フラグがＯＮである飲食店のみを表示する。
　あるいは、ユーザ端末Ｔは、予約を確保しやすい飲食店を優先的に表示させるために、空席数の降順またはアクセス率の昇順に飲食店を表示してもよい。また、ユーザ端末Ｔは上位に位置する飲食店のみ（例えば上位１０位までの飲食店のみ）を表示してもよい。
　あるいは、ユーザ端末Ｔは申込希望者により指定された検索クエリとの合致度が高い飲食店ほど上位に表示してもよい。この場合には、ユーザ端末Ｔは予約可能フラグおよび一致フラグが共にＯＮである飲食店を、それ以外の飲食店よりも上位に表示する。
　あるいは、ユーザ端末Ｔの現在位置に近い飲食店ほど上位に表示したりしてもよい。この場合には、ユーザ端末ＴはＧＰＳ（Ｇｌｏｂａｌ　Ｐｏｓｉｔｉｏｎｉｎｇ　Ｓｙｓｔｅｍ）機能などにより自端末の現在位置を求め、その現在位置と各飲食店情報（所在地）とを比較することでリスト内の飲食店情報を並べ替える。
　あるいは、ユーザ端末Ｔは予約可能であると判定された飲食店と予約不可能であると判定された飲食店の双方を含むリストを表示してもよい。この場合にはユーザ端末Ｔは、予約可能フラグがＯＮである飲食店が、予約可能フラグがＯＦＦである飲食店よりも上位になるように表示順を設定する。この場合にも、ユーザ端末Ｔは空席数の降順またはアクセス率の昇順に飲食店を並べ替えてもよい。
　あるいは、ユーザ端末Ｔは予約不可能であると判定された飲食店を強調表示することなく、予約可能であると判定された飲食店のみを強調表示してもよい。強調表示の方法は限定されず，例えば背景色の変更、目印の不可、ポップアップ表示などの様々な手法が利用可能である。
　あるいは、ユーザ端末Ｔは、ユーザがアクセスした当時は予約できなかったが、その後に空席が生じて予約受付が可能になった飲食店を上位に表示してもよい。この場合には、予約サーバ１０において推定部１２または送信部１３が、空き情報の履歴を所定のデータベース（図示せず）に記録する。そして、推定部１２は、今回生成した空き情報と過去に生成した空き情報とを比較することで、予約可能フラグがＯＦＦからＯＮに変わった飲食店についてのみ、予約受付可能に変更になったことを示す情報を付加する。
　ユーザ端末Ｔは、空き情報を表示する際に、画面上に表示されている現在ページからその空き情報のページに表示を切り替えてもよいし、その現在ページを残しつつ空き情報をポップアップ表示してもよい。この際にユーザ端末Ｔは、ページ切替またはポップアップ表示の前にその制御を実行してよいか否かをメッセージ表示によりユーザに問い合わせ、ユーザから許可の旨の入力を受け付けた場合に初めてそのページ切替またはポップアップ表示を実行してもよい。
　このように空き情報の表示態様は様々であるが、いずれにしても申込希望者に訴えるような態様で空き情報が表示されるので、申込希望者は予約受付が可能な飲食店を簡単に見つけることができる。
　次に、図１５を用いて、コンピュータを予約サーバ１０として機能させるための情報処理プログラムＰについて説明する。
　情報処理プログラムＰは、メインモジュールＰ１０、指示モジュールＰ１１、推定モジュールＰ１２、および送信モジュールＰ１３を備えている。
　メインモジュールＰ１０は、予約管理を統括的に制御する部分である。指示モジュールＰ１１、推定モジュールＰ１２、および送信モジュールＰ１３を実行することにより実現される機能はそれぞれ、上記の指示部１１、推定部１２、および送信部１３の機能と同様である。
　情報処理プログラムＰは、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ、半導体メモリ等の有形の記録媒体に固定的に記録された上で提供されてもよい。また、情報処理プログラムは、搬送波に重畳されたデータ信号として通信ネットワークを介して提供されてもよい。
　以上説明したように、本実施形態によれば、飲食店の収容能力情報とその飲食店へのアクセス履歴とから各飲食店の空き状況が推定され、ユーザの予約を受付可能な飲食店がその推定結果に基づいて抽出されてユーザに提供される。このように、飲食店へのアクセス状況から飲食店の空き状況を推定することで、個々の飲食店が自らその空き状況を登録または更新する手間が省かれる。したがって、空き状況を管理する飲食店の負荷を軽減しつつ、ユーザからの飲食店予約を受け付けることができる。
　また、本実施形態によれば、予約を取れないでいる申込希望者がユーザの閲覧履歴、メール履歴、あるいは通話履歴に基づいて推定され、その申込希望者に対して空き情報が提示される。したがって、ユーザが予約を途中で諦めてしまう自体を回避でき、空席を有する飲食店は予約を受ける機会を得られる。このように、予約システム１はユーザにとっても飲食店にとっても便利である。
　以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。
　ユーザ端末Ｔにおける空き情報の表示の制御は予約サーバ１０が行ってもよいし、ユーザ端末Ｔで行ってもよいし、これらの双方が協働して実行してもよい。
　空き情報を表示する際には空席数を省略してもよい。
　指示部１１は、空き情報を要求する信号をユーザ端末Ｔから受信した場合に指示信号を出力してもよい。この要求信号は少なくともユーザＩＤを含んでおり、飲食店を絞り込むための検索クエリを含んでいてもよい。この場合には、指示部１１はそのユーザＩＤか、またはユーザＩＤおよび検索クエリのペアを指示信号として推定部１２に出力する。なお、要求信号が検索クエリを含んでいない場合には、指示部１１はアクセス履歴データベース２２の検索履歴から検索クエリを取得してもよい。具体的には、指示部１１はユーザＩＤおよび最新のセッションＩＤに対応する検索クエリを読み出して、その検索クエリを指示信号に含めてもよい。
　１…予約システム、１０…予約サーバ（情報処理装置）、１１…指示部、１２…推定部（取得部も兼ねる）、１３…送信部、２０…データベース群（記憶部）、２１…飲食店データベース、２２…アクセス履歴データベース、２３…ユーザ・データベース、Ｐ…情報処理プログラム、Ｐ１０…メインモジュール、Ｐ１１…指示モジュール、Ｐ１２…推定モジュール、Ｐ１３…送信モジュール、Ｔ…ユーザ端末。
 

Claims (12)

  1. 　施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、
    　施設の収容可能数と該施設への前記アクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、
    　前記推定部による推定結果に基づく情報を前記ユーザ端末に出力する送信部と
    を備える情報処理装置。
  2. 　前記取得部が、施設とユーザとの間で成立した予約の人数の集計値を取得し、
    　前記推定部が、前記収容可能数と、１より大きい所定の係数が乗じられた前記集計値とから前記施設の空席数を求め、前記空席数が所定の閾値以上である施設を予約受付可能と推定する、
    請求項１に記載の情報処理装置。
  3. 　前記取得部が、施設ページへのアクセス数を前記収容可能数で割ることでアクセス率を取得し、
    　前記推定部が、前記アクセス率が所定の閾値以下である施設を予約受付可能と推定する、
    請求項１に記載の情報処理装置。
  4. 　前記取得部が前記集計値を取得できる場合には、前記推定部が前記空席数を求めて該空席数が所定の閾値以上である施設を予約受付可能と推定し、
    　前記取得部が前記集計値を取得できない場合には、前記取得部が施設ページへのアクセス数を前記収容可能数で割ることでアクセス率を取得し、前記推定部が、前記アクセス率が所定の閾値以下である施設を予約受付可能と推定する、
    請求項２に記載の情報処理装置。
  5. 　申込希望者に関するアクセス履歴に基づいて該申込希望者に前記推定結果に基づく情報を提供すると判定した場合に、前記取得部および前記推定部に処理を指示する指示部を更に備える
    請求項１～４のいずれか一項に記載の情報処理装置。
  6. 　前記アクセス履歴が、ユーザが施設ページを閲覧した記録である閲覧履歴を含み、
    　前記指示部が、前記閲覧履歴に基づいて、前記申込希望者が所定時間内に複数の施設ページにアクセスしたと判定した場合に、前記取得部および前記推定部に処理を指示する、
    請求項５に記載の情報処理装置。
  7. 　前記アクセス履歴が、ユーザと施設との通信の記録である通信履歴を含み、
    　前記指示部が、前記通信履歴に基づいて、前記申込希望者が所定時間内に複数の施設から予約不可通知を受けたと判定した場合に、前記取得部および前記推定部に処理を指示する、
    請求項５に記載の情報処理装置。
  8. 　前記通信履歴が、ユーザと施設との電子メールの記録であるメール履歴であり、
    　前記指示部が、前記電子メールの内容を解析することで該電子メールが前記予約不可通知に該当するか否かを判定する、
    請求項７に記載の情報処理装置。
  9. 　前記通信履歴が、ユーザと施設との通話の記録である通話履歴であり、
    　前記指示部が、前記通信履歴に基づいて、前記申込希望者が所定時間内に複数の施設と電話したことを特定した場合に、該申込希望者が該複数の施設から予約不可通知を受けたと判定する、
    請求項７に記載の情報処理装置。
  10. 　前記推定部が、推定処理により得られた予約受付可能な施設の数が所定数以下である場合に、該推定処理よりも条件を緩和して再度推定処理を実行する、
    請求項１～９のいずれか一項に記載の情報処理装置。
  11. 　施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得ステップと、
    　施設の収容可能数と該施設への前記アクセス数とに基づいて該施設が予約受付可能か否かを推定する推定ステップと、
    　前記推定ステップにおける推定結果に基づく情報を前記ユーザ端末に出力する送信ステップと
    を含む情報処理方法。
  12. 　施設情報を提供する情報提供手段に対するユーザ端末からの情報提供要求に応じて、該情報提供要求を受け付ける所定時間前からの施設に対するアクセス数を取得する取得部と、
    　施設の収容可能数と該施設への前記アクセス数とに基づいて該施設が予約受付可能か否かを推定する推定部と、
    　前記推定部による推定結果に基づく情報を前記ユーザ端末に出力する送信部と
    をコンピュータに実行させる情報処理プログラム。
PCT/JP2013/055485 2013-02-28 2013-02-28 情報処理装置、情報処理方法、及び情報処理プログラム WO2014132405A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2015502666A JP5759648B2 (ja) 2013-02-28 2013-02-28 情報処理装置、情報処理方法、及び情報処理プログラム
US14/771,075 US20160012354A1 (en) 2013-02-28 2013-02-28 Information processing device, information processing method, and information processing program
PCT/JP2013/055485 WO2014132405A1 (ja) 2013-02-28 2013-02-28 情報処理装置、情報処理方法、及び情報処理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/055485 WO2014132405A1 (ja) 2013-02-28 2013-02-28 情報処理装置、情報処理方法、及び情報処理プログラム

Publications (1)

Publication Number Publication Date
WO2014132405A1 true WO2014132405A1 (ja) 2014-09-04

Family

ID=51427706

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/055485 WO2014132405A1 (ja) 2013-02-28 2013-02-28 情報処理装置、情報処理方法、及び情報処理プログラム

Country Status (3)

Country Link
US (1) US20160012354A1 (ja)
JP (1) JP5759648B2 (ja)
WO (1) WO2014132405A1 (ja)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016218725A (ja) * 2015-05-20 2016-12-22 株式会社オープンドア 商品取引の仲介における自動応答システム、商品取引の仲介における自動応答方法、商品取引の仲介における自動応答プログラム、および商品取引の仲介における自動応答プログラムが記憶された記憶媒体
JP6074555B1 (ja) * 2015-12-10 2017-02-01 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2017084241A (ja) * 2015-10-30 2017-05-18 株式会社エビソル 予約管理装置
JP2018018336A (ja) * 2016-07-28 2018-02-01 株式会社ぐるなび 予約支援方法、予約支援プログラム、及び予約支援装置
JP2018018335A (ja) * 2016-07-28 2018-02-01 株式会社ぐるなび 予約支援方法、予約支援プログラム、及び予約支援装置
JP2018072963A (ja) * 2016-10-25 2018-05-10 株式会社ぐるなび サーバ、情報提供方法、及び情報提供プログラム
JP6351817B1 (ja) * 2017-10-11 2018-07-04 株式会社ドリコム 予約支援システム、サーバ装置、店舗検索方法、ならびに、プログラム
JP2019023938A (ja) * 2018-11-14 2019-02-14 株式会社ぐるなび 情報提供システム
JP2019087034A (ja) * 2017-11-07 2019-06-06 株式会社ぐるなび サーバの制御方法、サーバ、およびサーバの制御プログラム
WO2019203218A1 (ja) * 2018-04-16 2019-10-24 株式会社リクルート 順番管理システム、順番管理サーバ、およびプログラム
JP2020057154A (ja) * 2018-10-01 2020-04-09 株式会社ぐるなび 予約支援システム、予約支援方法、及び予約支援プログラム
JP2020067832A (ja) * 2018-10-24 2020-04-30 株式会社ぐるなび 情報処理装置、情報処理方法及びプログラム
JP2020170564A (ja) * 2020-07-20 2020-10-15 株式会社ぐるなび 予約支援システム、予約支援方法、及び予約支援プログラム
JP6964817B1 (ja) * 2021-07-02 2021-11-10 株式会社Wing of Freedom 数量限定メニュー予約システム
JP2021179648A (ja) * 2020-05-11 2021-11-18 株式会社ぐるなび 予約管理システム、予約管理方法、及び予約管理プログラム

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5394599B1 (ja) * 2013-06-28 2014-01-22 楽天株式会社 情報提供装置、情報提供方法、および情報提供プログラム
JP6306254B1 (ja) * 2017-08-28 2018-04-04 株式会社ＦｉＮＣ 予約支援方法およびプログラム
JP6311061B1 (ja) * 2017-11-30 2018-04-11 株式会社Ｅｐａｒｋ 情報管理装置、情報管理方法及びプログラム
CN108632452A (zh) * 2018-03-27 2018-10-09 珠海格力电器股份有限公司 一种日程安排更新方法、装置及系统
CN114861955A (zh) * 2022-04-27 2022-08-05 中国银行股份有限公司 信息处理方法、装置及设备和存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013001850A1 (ja) * 2011-06-30 2013-01-03 楽天株式会社 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体
JP2013030108A (ja) * 2011-07-29 2013-02-07 Rakuten Inc 情報提供装置、情報提供方法、情報提供プログラム、及びそのプログラムを記憶するコンピュータ読取可能な記録媒体

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013001850A1 (ja) * 2011-06-30 2013-01-03 楽天株式会社 情報提供装置、情報提供方法、情報提供プログラム及び記録媒体
JP2013030108A (ja) * 2011-07-29 2013-02-07 Rakuten Inc 情報提供装置、情報提供方法、情報提供プログラム、及びそのプログラムを記憶するコンピュータ読取可能な記録媒体

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016218725A (ja) * 2015-05-20 2016-12-22 株式会社オープンドア 商品取引の仲介における自動応答システム、商品取引の仲介における自動応答方法、商品取引の仲介における自動応答プログラム、および商品取引の仲介における自動応答プログラムが記憶された記憶媒体
JP2017084241A (ja) * 2015-10-30 2017-05-18 株式会社エビソル 予約管理装置
JP6074555B1 (ja) * 2015-12-10 2017-02-01 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
WO2017098642A1 (ja) * 2015-12-10 2017-06-15 楽天株式会社 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2018018336A (ja) * 2016-07-28 2018-02-01 株式会社ぐるなび 予約支援方法、予約支援プログラム、及び予約支援装置
JP2018018335A (ja) * 2016-07-28 2018-02-01 株式会社ぐるなび 予約支援方法、予約支援プログラム、及び予約支援装置
JP2018072963A (ja) * 2016-10-25 2018-05-10 株式会社ぐるなび サーバ、情報提供方法、及び情報提供プログラム
JP2019071023A (ja) * 2017-10-11 2019-05-09 株式会社ドリコム 予約支援システム、サーバ装置、店舗検索方法、ならびに、プログラム
JP6351817B1 (ja) * 2017-10-11 2018-07-04 株式会社ドリコム 予約支援システム、サーバ装置、店舗検索方法、ならびに、プログラム
JP2019087034A (ja) * 2017-11-07 2019-06-06 株式会社ぐるなび サーバの制御方法、サーバ、およびサーバの制御プログラム
JP7059569B2 (ja) 2017-11-07 2022-04-26 株式会社ぐるなび サーバの制御方法、サーバ、およびサーバの制御プログラム
WO2019203218A1 (ja) * 2018-04-16 2019-10-24 株式会社リクルート 順番管理システム、順番管理サーバ、およびプログラム
JP2019185617A (ja) * 2018-04-16 2019-10-24 株式会社リクルート 順番管理システム、順番管理サーバ、およびプログラム
JP2020057154A (ja) * 2018-10-01 2020-04-09 株式会社ぐるなび 予約支援システム、予約支援方法、及び予約支援プログラム
JP2020067832A (ja) * 2018-10-24 2020-04-30 株式会社ぐるなび 情報処理装置、情報処理方法及びプログラム
JP2019023938A (ja) * 2018-11-14 2019-02-14 株式会社ぐるなび 情報提供システム
JP2021179648A (ja) * 2020-05-11 2021-11-18 株式会社ぐるなび 予約管理システム、予約管理方法、及び予約管理プログラム
JP7144689B2 (ja) 2020-05-11 2022-09-30 株式会社ぐるなび 予約管理システム、予約管理方法、及び予約管理プログラム
JP2020170564A (ja) * 2020-07-20 2020-10-15 株式会社ぐるなび 予約支援システム、予約支援方法、及び予約支援プログラム
JP7210510B2 (ja) 2020-07-20 2023-01-23 株式会社ぐるなび 予約支援システム、予約支援方法、及び予約支援プログラム
JP6964817B1 (ja) * 2021-07-02 2021-11-10 株式会社Wing of Freedom 数量限定メニュー予約システム
JP2023007884A (ja) * 2021-07-02 2023-01-19 株式会社Wing of Freedom 数量限定メニュー予約システム

Also Published As

Publication number Publication date
JP5759648B2 (ja) 2015-08-05
US20160012354A1 (en) 2016-01-14
JPWO2014132405A1 (ja) 2017-02-02

Similar Documents

Publication Publication Date Title
JP5759648B2 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JP5819412B2 (ja) コンテキストに基づいて選択したコンテンツ項目の提供
US7882056B2 (en) Method and system to predict and recommend future goal-oriented activity
US9460156B2 (en) Matching a first location profile with at least one other location profile
CN105324771B (zh) 识别用户先前交互的物理位置的个人搜索结果
JP2003067328A (ja) ブックマーク管理システム及びブックマーク管理方法
JP2012113544A (ja) 飲食店推薦システム
JP5740536B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
KR20140114030A (ko) 웹 페이지 표시 방법 및 시스템
WO2005125231A2 (en) Automated voice link initiation
US20100094543A1 (en) Systems And Methods For Providing Geography-Based Tours
US9972029B2 (en) Use of personalized points of reference in selecting advertisements shown to users
JP5407336B2 (ja) 情報処理装置
JP6433043B2 (ja) 予約情報処理装置、予約情報処理方法、およびプログラム
JP2003242169A (ja) 情報収集配信処理方法，情報収集配信装置，そのプログラムおよびそのプログラムの記録媒体
US20150189482A1 (en) Device for providing related information for monile communication terminal and system for sharing related information
JP2013054576A (ja) クーポン発行システム
JP6843958B1 (ja) 検索方法および検索プログラム、並びに検索システム
US20170076407A1 (en) Location-based data structure information retrieval and modification
JP6384067B2 (ja) サーバ装置、プログラム及び推薦情報提供方法
JP5153210B2 (ja) 広告配信装置
JP2017091071A (ja) 情報検索サーバ、情報検索プログラム及び情報検索方法
JP6456492B2 (ja) 通知制御システム、サーバ装置、通信端末装置、プログラム及び通知制御方法
JP2020057127A (ja) 情報提供装置、情報提供方法、及び情報提供プログラム
JP6088022B1 (ja) 予約処理装置、予約処理方法および予約処理プログラム

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015502666

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14771075

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13876673

Country of ref document: EP

Kind code of ref document: A1