Restaurant search device, restaurant search method, and program

Abstract

To provide a restaurant search device that enables the efficient selection of suitable restaurants. [Solution] The restaurant search device according to this disclosure comprises: candidate determination means for determining potential participants who are to be invited to a meal at a restaurant; information acquisition means for acquiring profile information for each of the determined potential participants; prediction means for predicting the number of potential participants who will attend the meal based on the profile information; and search means for searching for restaurants that can host a meal with the predicted number of people.

Description

Technical Field

[0001] The present disclosure relates to a restaurant search device and the like.

Background Art

[0002] When planning an event such as a dinner party, there are portal sites that present restaurants that meet the specified conditions by specifying conditions such as the number of people, date and time, and location. These portal sites enable users to efficiently search for restaurants that match the desired conditions.

[0003] Patent Document 1 discloses a server that counts the number of participants in a meeting at a service facility such as a restaurant and provides information on available restaurants based on that number. In Patent Document 1, receiving location information from a user terminal is a condition for counting participants.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] When planning a dinner party for a large number of people, the organizer needs to search for a restaurant of an appropriate scale considering the number of participants. However, it is difficult to accurately predict how many of the people invited will actually participate. On the other hand, in order to smoothly proceed with the event, it is desirable to select a restaurant suitable for the number of participants.

[0006] One of the objects of the present disclosure is to provide a restaurant search device and the like that enable efficient selection of an appropriate restaurant.

Means for Solving the Problems

[0007] A restaurant search device in one aspect of this disclosure includes: candidate determination means for determining potential participants who are to be invited to a meal at a restaurant; information acquisition means for acquiring profile information for each of the determined potential participants; prediction means for predicting the number of potential participants who will attend the meal based on the profile information; and search means for searching for restaurants that can host a meal with the predicted number of people.

[0008] A method for searching for restaurants in one aspect of this disclosure involves determining potential participants who are invited to attend a meal at a restaurant, obtaining profile information for each of the determined candidates, predicting the number of participants who will attend the meal based on the profile information, and searching for restaurants that can host a meal for the predicted number of people.

[0009] A program in one aspect of this disclosure determines potential participants to be invited to a dinner party at a restaurant, obtains profile information for each of the determined candidates, predicts the number of participants who will attend the dinner party based on the profile information, and causes a computer to perform the following processes: searching for restaurants that can host the dinner party with the predicted number of participants. The program may be stored on a computer-readable non-temporary recording medium. [Effects of the Invention]

[0010] One example of the effect of this disclosure is that it enables the efficient selection of appropriate restaurants. [Brief explanation of the drawing]

[0011] [Figure 1] This is an explanatory diagram showing an example configuration of a restaurant search system. [Figure 2] This is a block diagram showing an example configuration of a restaurant search device. [Figure 3] This diagram shows an example of a screen for planning a dinner party. [Figure 4] This figure shows an example of the output screen for the participant prediction results. [Figure 5]It is a diagram showing an example of a search result screen. [Figure 6] It is a flowchart showing an operation example of a restaurant search device. [Figure 7] It is an explanatory diagram showing a configuration example of a restaurant search system. [Figure 8] It is a diagram showing an example of a reservation management screen. [Figure 9] It is a diagram showing an example of a notification creation screen. [Figure 10] It is a flowchart showing an operation example of a restaurant search device. [Figure 11] It is an explanatory diagram showing a configuration example of a restaurant search system. [Figure 12] It is a diagram showing an example of a search condition confirmation screen. [Figure 13] It is a flowchart showing an operation example of a restaurant search device. [Figure 14] It is a block diagram showing an example of the hardware configuration of a computer.

Modes for Carrying Out the Invention

[0012] (First Embodiment) The restaurant search system 100 according to the present disclosure is applicable to searching for restaurants for a large-scale dinner party. The large number means, for example, 10 or more people, but may vary depending on the situation. The present disclosure may also be used for searches for dinner parties with fewer than 10 people. The type of dinner party is not particularly limited and may include drinking parties, lunch parties, dinner parties, parties, farewell parties, New Year parties, end-of-year parties, etc.

[0013] Using FIG. 1, a connection example of each device of the restaurant search system 100 in the present disclosure will be described. The restaurant search system 100 includes a user terminal 10, a restaurant search device 20, a database 30, and an external system 40. The restaurant search device 20 is communicably connected to the user terminal 10, the database 30, and the external system 40 via a communication network.

[0014] The user terminal 10 is an information processing device such as a smartphone or a personal computer. The user terminal 10 is used by a user who plans a dinner party. The user terminal 10 provides an interface for using the restaurant search system 100. An application for restaurant search may be installed on the user terminal 10.

[0015] The database 30 includes a profile information database 31 and a store information database 32. The information in the database 30 is updated periodically, for example, by data input by the user or an automatic update program.

[0016] The profile information database 31 stores the profile information of the participation candidates. The profile information is stored, for example, linked to the email address or SNS (Social Networking Service) account of the participation candidate.

[0017] The profile information includes, for example, information about past dinner parties to which the user has been invited. Information about past dinner parties includes, for example, whether the user attended the invited dinner party, the number of times attended, and the payment amount. The profile information database 31 may store participation record information obtained in cooperation with a payment calculation application. The payment calculation application is an application for performing a sharing calculation among the participants of a dinner party. When payment is made through this application, the information is automatically reflected in the profile information database 31. In addition, the profile information database 31 may store participation record information based on whether the location information at the date and time of the dinner party matches the location information of the store. By doing so, a more accurate participation history is accumulated, leading to an improvement in prediction accuracy.

[0018] Profile information may include personal details of the candidate that may influence their eligibility to participate. Examples of personal details include: Family structure: whether or not they have children, whether or not they have family members requiring care, etc. Health status: allergies, chronic illnesses, dietary restrictions, etc. Hobbies and club activities: days and times of regular activities. Employment type: shift work, flextime, reduced hours, etc. Location information: workplace address, home address, current location. Personal schedule: regular doctor's appointments, picking up and dropping off children, etc.

[0019] This personal information may include details about specific days of the week and times of day. For example, it could include information such as, "I can't participate on Wednesdays because I have extracurricular activities," or "I can't participate late on Friday evenings because I have to take my children to and from school."

[0020] Furthermore, the profile information may include the candidate's department and position at their workplace. Position information may be recorded using categories such as general employee, supervisor, section chief, or department head. This information will be considered when determining participation plans and setting budgets. In addition, the profile information may include information about the candidate's favorite restaurants.

[0021] The store information database 32 stores information about restaurants. Specifically, it includes the following information: Basic information: store name, address, phone number, business hours, regular holidays. Seating capacity: total number of seats, availability and capacity of private rooms. Budget range: average budget for lunch, average budget for dinner. Number of people who can be reserved: number of people who can be reserved for each time slot. Store atmosphere and characteristics: type of cuisine (Japanese, Western, Chinese, etc.), smoking / non-smoking policy, types of food and drinks offered, whether private events are possible, whether it is suitable for business meetings or dinners. Payment methods: credit card accepted, electronic money accepted, etc. Reservation methods: telephone reservations, online reservations available.

[0022] The store information database 32 may also store usage history and evaluation information for each candidate participant. Usage history may include, for example, the number of times the store has been used, the date and time of use, the number of people, and the budget at the time of use. Evaluation information may include, for example, evaluations of the food and atmosphere (e.g., a 5-point scale).

[0023] The external system 40 is, for example, an SNS server 41 or a mail server 42. The SNS server 41 is a server that provides social networking services. The restaurant search device 20 can obtain profile information of potential participants and group information from this server. It is also possible to send invitations to dinner parties and confirm participation via SNS. The mail server 42 is a server that manages the sending and receiving of emails. Through this server, it is possible to send emails inviting people to dinner parties and confirming their participation, and to receive replies from participants. It is also possible to extract potential participants using information from mailing lists.

[0024] The restaurant search system 100 may include either an SNS server 41 or a mail server 42 as an external system 40. Furthermore, the restaurant search system 100 may also include a map service, a weather forecast service, and a payment service as external systems 40. The map service provides location information and route guidance for restaurants. This service allows for restaurant searches that consider the distance from participants' current locations or workplaces, as well as access methods. The search results can also be displayed on a map. The weather forecast service provides weather information for the day of the meal. Based on this information, it becomes possible to select a more appropriate restaurant, such as prioritizing restaurants that are easily accessible even in rainy weather. The payment service supports prepayment for online reservations, on-the-day splitting of bills, and payment processing. This service can increase the certainty of reservations and reduce the hassle of payment.

[0025] An example of the configuration of the restaurant search device 20 in this disclosure will be explained using Figure 2. The restaurant search device 20 comprises a candidate determination unit 21, an information acquisition unit 22, a prediction unit 23, and a search unit 24.

[0026] The candidate selection unit 21 determines the participants who will be invited to the dinner party at the restaurant. The participants may be those who are yet to be invited to participate, or those who have already been invited to participate. For example, the candidate selection unit 21 determines members specified by the user using the user terminal 10, or members included in a specified group, as participants. The candidate selection unit 21 may refer to the profile information database 31 and display the members and groups that can be specified on the user terminal 10. The specified groups may be, for example, a department at work or a group on social networking services (SNS).

[0027] Figure 3 shows an example of a meal planning screen displayed on user terminal 10. In Figure 3, the group name and member names are displayed in a list format for selection. Users can select their workplace department and members by using checkboxes. Members not displayed in the list can be searched using the candidate search button.

[0028] The candidate selection unit 21 may extract potential participants from the address information of a mass email. For example, the candidate selection unit 21 may use the address list of the email to which the invitation to the dinner party was sent to determine potential participants. For example, in the screen shown in Figure 3, after the "Extract from email" button is pressed, the user selects an email, and the participant corresponding to the selected email address is added. Alternatively, the candidate selection unit 21 may accept a mailing list specification from the user terminal 10 and use the registration information of the mailing list to determine the target participant.

[0029] The candidate selection unit 21 may use location information to determine potential participants. For example, people currently in a specific location (such as an office or restaurant) may be selected as potential participants based on their location. This function is useful when planning an impromptu meal or when planning a subsequent meal following an existing one. For example, the screen in Figure 3 may display a "Search for nearby members" button. Pressing this button will display a list of potential participants based on location information, making them available for selection.

[0030] The candidate selection unit 21 may determine potential participants by utilizing information from past dinner parties. The candidate selection unit 21 refers to lists of participants from similar past dinner parties or lists of members who were invited to participate, and determines that members included in these lists are potential participants. Here, similar dinner parties are, for example, dinner parties with the same purpose.

[0031] The information acquisition unit 22 acquires profile information for each participant selected by the candidate selection unit 21. For example, the information acquisition unit 22 acquires profile information from the profile information database 31, including participation rates in past dinner parties and personal circumstances. The number and types of profile information acquired by the information acquisition unit 22 can be selected as appropriate.

[0032] Furthermore, the information acquisition unit 22 may acquire information about new dinner parties planned by the user. This information may include, for example, the date and time of the event, the area of ​​the venue, and the purpose of the event. The purpose of the event can be set as appropriate, such as a regular gathering, a farewell party, or a year-end party. The information acquisition unit 22 acquires the information about the dinner party entered on the planning screen shown in Figure 3.

[0033] The prediction unit 23 predicts the number of participants who will attend the dinner party based on the profile information acquired by the information acquisition unit 22. For example, the prediction unit 23 predicts whether each participant will attend and counts the number of people predicted to attend, thereby predicting the total number of participants.

[0034] Furthermore, the prediction unit 23 may predict the probability of a candidate participating in a dinner party based on their profile information. For example, based on the participation rate of past dinner parties invited to the group, the prediction unit 23 predicts that the higher the past participation rate, the higher the probability of participation this time as well. The participation rate information may be for each location and each date and time of the dinner party. As participation rates for each date and time, information may be stored for each time slot or each day of the week. In addition, participation rates can be calculated based on the time of the month, such as the beginning, middle, and end of the month. For example, it is possible to reflect trends such as "dinner parties at the end of the month have a low participation rate." The prediction unit 23 may also predict, based on information about personal circumstances, that a candidate with young children has a low probability of participating in a weekday evening dinner party.

[0035] Furthermore, the prediction unit 23 may also take into account the characteristics of the dinner party (purpose, scale, date and time, location, etc.) when making predictions. For example, the prediction unit 23 may reflect in its predictions that dinner parties with formal purposes, such as welcome and farewell parties, tend to have higher participation rates, and that dinner parties held far from the workplaces of the prospective participants tend to have lower participation rates. If the profile information database 31 has an upper limit set for the number of dinner parties that each prospective participant can attend within a predetermined period, the prediction unit 23 may also predict whether or not a prospective participant will attend based on the number of recent events they have attended and the amount they have paid. If the number of events or the amount paid is close to the upper limit, the prediction unit 23 predicts that the probability of participation is low.

[0036] The prediction unit 23 may output the prediction results to the user terminal 10. Figure 4 shows the output screen of the participation prediction results displayed on the user terminal 10. This screen allows the user to visually understand the prediction results and decide whether to proceed with the store search. In the prediction results of Figure 4, the range of the predicted number of participants is displayed. In addition, the top 3 members with a high probability of participation and the bottom 3 members with a low probability of participation are shown along with their respective participation probabilities. Displaying members with high and low probability of participation provides reference information for the organizer when considering actions such as contacting them individually.

[0037] The specific prediction method used by the prediction unit 23 is not particularly limited. The prediction unit 23 may perform predictions by combining multiple methods. One method is a prediction method using a machine learning model. In this method, past dinner party data, including the characteristics of the dinner party, the profile information of each candidate participant, and the actual participation status, is used as training data to construct a prediction model using a machine learning algorithm. The prediction unit 23 inputs new dinner party information and the profile information of the candidate participants acquired by the information acquisition unit 22 into the prediction model. The prediction model, for example, outputs the probability of participation for each candidate participant.

[0038] The prediction unit 23 may employ a rule-based prediction method. Insights regarding empirical rules extracted from past data are set as rules. The prediction unit 23 then makes predictions based on these set rules. For example, rules such as "Friday night dinners have a high participation rate" or "the higher the position, the higher the participation rate" may be applied.

[0039] Furthermore, the prediction unit 23 may utilize a statistical prediction method using past data. In this method, statistical data such as the past participation rate of each candidate participant in similar past dinner parties is analyzed, and predictions are made based on this. The prediction unit 23 may also predict whether each candidate participant will attend and make adjustments to the total number of people predicted to attend using statistical data. For example, the prediction unit 23 may adjust the total number of people predicted to attend using the overall participation rate in similar past dinner parties. As a specific example, if there has been a tendency for the actual number of participants to be 10% less than the predicted value in similar past dinner parties, the prediction unit 23 adjusts the predicted number by subtracting 10%. The prediction unit 23 then uses the adjusted value as the predicted number of people to attend the dinner party.

[0040] Furthermore, the prediction unit 23 may receive feedback on actual participation and continuously learn and update its prediction model. For example, if there is a significant difference between the predicted number of participants and the actual number of participants in a dinner party, the prediction unit 23 may adjust the parameters of the prediction model or add new rules based on that information.

[0041] The search unit 24 searches for restaurants that can host a dinner party with the number of people predicted by the prediction unit 23. The search criteria take into account the number of seats based on the predicted number of people. Restaurants that can host a dinner party may also be restaurants that can accept reservations for the predicted number of people. In this case, the search unit 24 refers to the reservation status of the restaurants and sets the search criteria considering the number of available seats.

[0042] The search unit 24 may also set search conditions that take into account the atmosphere and characteristics of the store, the location information of the participants, and the set budget. For example, the search unit 24 searches for stores within a specified time and distance from each candidate participant's workplace or home. This allows for the selection of stores that are easily accessible. The search unit 24 can also search for stores with a similar atmosphere or a different atmosphere based on information about stores previously used. This makes it possible to select stores that take into account the participants' preferences and desire for novelty. The search unit 24 may also set search conditions based on the preferred store atmosphere registered in the candidate participant's profile information. Based on this information, the search unit 24 can prioritize searching for stores with an atmosphere that matches the candidate participant's preferences. Furthermore, the search unit 24 can also search for stores with an atmosphere that is likely to be preferred by the candidate participant based on other profile information (age, position, etc.).

[0043] The search unit 24 may set a budget based on the positions of the prospective participants. For example, it may set a budget based on the positions of the members expected to participate and search for restaurants within the set budget range. That is, if it is expected that many members with high positions will participate, a higher budget will be set. Alternatively, the search unit 24 may set a budget based on the amount paid by the prospective participants at past dinner parties. This makes it possible to select restaurants within an appropriate budget range that suits the participants' financial situation and preferences.

[0044] Furthermore, the search unit 24 can adjust the search conditions according to the purpose and type of the meal. For example, for special occasions such as farewell parties or welcome parties, it can prioritize searching for more formal restaurants, while for regular get-togethers, it can search for restaurants with a casual atmosphere.

[0045] The search unit 24 may combine these multiple conditions and comprehensively evaluate them to find the most suitable store. The search unit 24 may also weight multiple conditions (e.g., budget, capacity, access, atmosphere, etc.) to calculate an overall score and find the most suitable store. The search unit 24 prioritizes the search results in descending order of score, and when presented to the user, stores deemed more appropriate are displayed higher. The usage history and evaluation information of each participant stored in the store information database 32 may be used for prioritization. For example, the search unit 24 may refer to each participant's past usage history and prioritize including stores they frequently use or have given high ratings to in the search results. This makes it possible to suggest stores that match the participant's preferences. In addition, even for new stores that the participant has not used before, the search unit 24 may prioritize including stores with similar characteristics (cuisine genre, price range, atmosphere, etc.) to stores that have given high ratings to the participant.

[0046] The search unit 24 may perform a search in response to the "Search Stores" button being pressed. The search unit 24 may automatically set the search conditions and display the set search conditions to the user. The user may modify or add to the displayed search conditions. The search unit 24 will search for and refine stores according to the updated search conditions.

[0047] The search unit 24 outputs search results to the user terminal 10. The search unit 24 can provide search results in multiple formats, such as a list or map display, according to the user's preference. Figure 5 shows an example of a search results screen displayed on the user terminal 10. In Figure 5, the top three search results are displayed. Each search result includes the store name, capacity, budget, availability of private rooms, and features. Each search result has "Details" and "Make a provisional reservation" buttons. Clicking the "Details" button allows the user to view more detailed information about the store. The "Make a provisional reservation" button provides a function to make a provisional reservation for the store. At the bottom of the screen is a "Show more" button, which, when clicked, displays additional search results. This design allows the user to view many options as needed.

[0048] The restaurant search system 100 disclosed herein can also be applied to predicting the number of participants in a second party and searching for restaurants. Here, "first party" refers to the main meal or drinking party held at the beginning, and "second party" refers to another gathering that takes place immediately after the first party.

[0049] The prediction unit 23 may, for example, designate members who have been invited to the first party as candidates for the second party. Alternatively, the prediction unit 23 may designate members whose attendance at the first party has been confirmed as candidates. Members whose attendance at the first party has been confirmed are, for example, members who have paid the participation fee for the first party in advance. Furthermore, if the prediction unit 23 makes a prediction during or after the first party, it may designate members who are present at the venue of the first party at the time of the prediction as candidates.

[0050] In predicting the number of participants in the after-party, the prediction unit 23 refers to past after-party participation history recorded in the profile information database 31 and reflects each individual's after-party participation tendencies in the prediction. The prediction unit 23 may also make predictions based on information from the first party. Specifically, information such as the number of participants in the first party, the venue, the time of day, the attributes of the participants (age group, position, etc.), and the purpose of the first party (farewell party, welcome party, etc.) may be considered. For example, the prediction may reflect that if there are many participants in the first party, there is a tendency for there to be a relatively large number of participants in the after-party, and that the participation rate in the after-party tends to be higher if the first party is mainly attended by young employees. The prediction unit 23 may also consider the planned end time and day of the week of the first party. For example, the prediction may reflect that the participation rate in the after-party tends to be lower on weekdays due to consideration of the impact on work the next day, and that the participation rate tends to be higher on Fridays and the day before holidays.

[0051] The search unit 24 searches for a suitable venue based on the predicted number of participants in the after-party. The search unit 24 may also set search conditions using information from the first party. For example, one search condition may be that the venue must be within walking distance (e.g., within 500 meters) of the first party venue. Another search condition may be that the venue must have a different atmosphere from the first party venue. For example, if the first party is at a Japanese restaurant, the search unit 24 may search for a Western-style bar or a casual izakaya for the after-party to create a change of atmosphere. Furthermore, considering the expenditure at the first party, the budget for the after-party may be set lower. In addition, if a large amount of alcohol is predicted to be consumed at the first party (e.g., if an all-you-can-drink plan is selected), the search unit 24 prioritizes searching for venues that are closer. The search unit 24 may also set search conditions based on the usual amount of alcohol consumed at the first party, which is stored for each participant in the profile information database 31. For example, if a large amount of alcohol is predicted to be consumed at the first party, the search unit 24 prioritizes searching for venues that are closer.

[0052] An example of the operation of the restaurant search device 20 in this disclosure will be explained using Figure 6. For example, the restaurant search device 20 starts the processing shown in Figure 6 in response to an operation from the user terminal 10.

[0053] In step S1, the candidate selection unit 21 determines the candidates who will be invited to participate in the dinner party at a restaurant. In step S2, the information acquisition unit 22 acquires the profile information of each candidate selected by the candidate selection unit 21. In step S3, the prediction unit 23 predicts the number of candidates who will participate in the dinner party based on the profile information acquired by the information acquisition unit 22. In step S4, the search unit 24 searches for restaurants that can host the dinner party with the number of people predicted by the prediction unit 23.

[0054] With the above steps completed, the restaurant search device 20 terminates the process shown in Figure 6.

[0055] While typical restaurant search portals allow users to search for restaurants based on their input criteria, they lack features to assist in selecting appropriate restaurants when the number of attendees is uncertain. As a result, organizers may overestimate the number of attendees and end up searching for restaurants that are unnecessarily large, or conversely, underestimate the number and end up searching for restaurants with insufficient capacity.

[0056] According to the first embodiment, the prediction unit 23 predicts the number of participants who will attend the dinner party based on profile information, and the search unit 24 searches for restaurants that can host the dinner party with the predicted number of participants. Therefore, even if the number of participants is not yet determined at the planning stage of the dinner party, the organizer can identify potential restaurants. Thus, according to the first embodiment, it is possible to efficiently select an appropriate restaurant.

[0057] (Second Embodiment) In the second embodiment, a restaurant search system 200 is described, which adds a restaurant reservation function and a notification function to the restaurant search system 100 of the first embodiment.

[0058] Figure 7 illustrates an example of the configuration of the restaurant search system 200 of this disclosure. Regarding the configuration of the restaurant search system 200, explanations of configurations similar to those of the restaurant search system 100 will be omitted.

[0059] Furthermore, the restaurant search system 200 includes, in addition to the components of the restaurant search device 20 of the first embodiment, a restaurant selection unit 25, a reservation management unit 26, and a notification unit 27. In the second embodiment, the notification unit 27 may be provided as needed.

[0060] The restaurant selection unit 25 has the function of selecting a restaurant to be reserved from among the restaurants searched by the search unit 24. The restaurant selection unit 25 may select a restaurant based on the user's manual selection, or it may automatically select a restaurant based on pre-set conditions (e.g., the restaurant with the highest rating, the restaurant that best matches the budget, etc.).

[0061] The reservation management unit 26 processes reservations for the selected restaurant. The reservation management unit 26 makes reservations within a range of the number of people predicted by the prediction unit 23 (e.g., from the minimum predicted number of people to the maximum predicted number of people). The reservation management unit 26 may make a provisional reservation before the number of participants is finalized, and then automatically transition to a final reservation once the number of participants is finalized. The reservation management unit 26 may also reflect information such as invitations to the dinner party and confirmation replies sent and received via the SNS server 41 or mail server 42 in the reservation. The reservation management unit 26 also processes changes to and cancellations of reservations.

[0062] The reservation management unit 26 outputs the reservation management status to the user terminal 10. Figure 8 shows an example of the reservation management screen displayed on the user terminal 10. The reservation management screen provides an interface for the user to check the provisional reservation status and to confirm or cancel the reservation. The current status of the reservation is displayed at the top of the reservation management screen. In the example in Figure 8, "Reservation Status: Provisional Reservation" is displayed, allowing the user to understand that the reservation is not yet confirmed. Below that, the basic information of the reserved store is displayed. Specifically, the store name, reservation date and time, and number of people are listed. The number of people is displayed within the range predicted by the prediction unit 23 (e.g., 15-20 people). The participation confirmation status is displayed in the center of the screen. This indicates the response status from potential participants. "Confirmed" indicates the number of people who have indicated their intention to participate, "Not Response" indicates the number of people who have not responded, and "Not Attending" indicates the number of people who have responded that they cannot attend. With this information, the user can understand the current participation status and take additional actions such as contacting people as needed. Buttons for performing reservation-related operations are located at the bottom of the screen. Pressing the "Participant List" button displays a list of people who have confirmed their participation. The "Reminder to Unanswered Participants" button automatically sends a reminder message to potential participants who have not yet responded. At the bottom are buttons for performing the final reservation actions. The "Confirm Reservation" button confirms the reservation with the current number of planned participants. When this button is pressed, the reservation management unit 26 processes the reservation with the store. The "Cancel Reservation" button cancels the reservation.

[0063] The notification unit 27 has the function of notifying potential participants of the reservation status and details of the dinner party. The notification unit 27 can send notifications using various means, such as email, short message service, and in-app notifications. The notification content may include store information, date and time, store reservation status, range of expected number of participants, and a request for participation confirmation. If the notification includes a request for participation confirmation, each potential participant will reply whether or not they will participate. The reservation management unit 26 confirms the number of participants and makes the reservation based on the responses from the potential participants. The notification unit 27 notifies the potential participants or members who have replied that they will participate of the final reservation information. This notification includes detailed information such as the confirmed store information, date and time, and number of participants. By having the notification unit 27 send notifications automatically, it is possible to quickly and uniformly transmit accurate information to all participants.

[0064] The notification unit 27 may output the notification creation screen to the user terminal. Figure 9 shows an example of the notification creation screen displayed on the user terminal 10. This screen provides an interface for notifying potential participants of a dinner party of their participation confirmation and detailed information. At the top of the screen is a pull-down menu for selecting the notification type. In the example in Figure 9, "Participation Confirmation" is selected, but other options such as "Sharing Detailed Information" and "Reminder" may also be included. Below that is a recipient selection area. Here, a list of potential participants is displayed, with a checkbox next to each candidate. The user can select recipients individually. The user can also select all candidates at once by using the "Select All" option. The lower half of the screen is a message editing area. A template message corresponding to the selected notification type is automatically displayed here. In the example in Figure 9, a template for participation confirmation is displayed, which includes the subject, body, and detailed information about the dinner party (date, time, location, budget). The template message is editable, and the user can change the wording or add additional information as needed. Furthermore, the end of the message includes response buttons such as "I will participate" and "I cannot participate," making it easy for recipients to respond. A "Send Notification" button is located at the bottom of the screen. Clicking this button sends the created notification to the selected recipient. Multiple options for sending methods are possible, including email, text message, and in-app notification. The notification unit 27 manages the notifications created on this screen and distributes them to potential participants via the selected sending method. The notification unit 27 may also automatically aggregate responses from potential participants and update the reservation status in cooperation with the reservation management unit 26.

[0065] Furthermore, the system of this embodiment can also be applied to the after-party prediction described in the first embodiment. After the reservation for the first party is confirmed, the system automatically searches for candidate venues for the after-party and makes a provisional reservation, enabling smoother preparation for the after-party.

[0066] Next, Figure 10 will be used to illustrate another example of the operation of the restaurant search device 20 in this disclosure. For example, the restaurant search device 20 starts the process shown in Figure 10 in response to an operation from the user terminal 10.

[0067] Steps S21 to S24 are the same as steps S1 to S4 of the operation example described in the first embodiment, so their explanation will be omitted.

[0068] In step S25, the store selection unit 25 selects a store as a reservation candidate from the search results. This selection is made, for example, by the user choosing a desired store from the search results displayed on the user terminal 10. In step S26, the reservation management unit 26 makes a provisional reservation for the selected store. In the provisional reservation, seats are secured within the range of the predicted number of participants. In step S27, the notification unit 27 notifies the prospective participants of the invitation to the dinner party. This notification includes detailed information such as store information, date and time, and budget, as well as a question asking whether they can attend.

[0069] In step S28, the reservation management unit 26 confirms the number of participants based on responses from prospective participants. If there is a significant difference between the initial forecast and the actual number of participants at this stage, the reservation details are adjusted as necessary. In step S29, the reservation management unit 26 makes the final reservation with the confirmed number of participants. At this point, the store is notified of the final number of reservations, and any detailed requests (seating layout, menu, etc.) are also communicated as needed.

[0070] With the above steps completed, the restaurant search device 20 terminates the process shown in Figure 10.

[0071] According to the second embodiment, the efficient selection of a suitable restaurant is possible, similar to the first embodiment. Furthermore, since the reservation management unit 26 processes reservations with the restaurants, the likelihood of securing reservations at popular restaurants or during peak seasons increases even when the number of participants is not yet determined. In addition, since the reservation management unit 26 makes provisional reservations within a predetermined range of people, it can flexibly respond to changes in the number of participants. Therefore, it becomes easier to secure a restaurant of an appropriate size.

[0072] (Third embodiment) In the third embodiment, a restaurant search system 300 is described, which adds a function to analyze the status of participants to the restaurant search system 100 of the first embodiment. This embodiment is particularly useful for searching for restaurants for after-parties.

[0073] Figure 11 illustrates an example of the configuration of the restaurant search system 300 of this disclosure. Regarding the configuration of the restaurant search system 300, explanations of configurations similar to those of the restaurant search system 100 will be omitted.

[0074] The restaurant search system 300 includes a sensor 50 and a data processing server 60. In addition, the restaurant search device 20 related to the restaurant search system 300 includes a sensor data acquisition unit 28 and a state analysis unit 29, in addition to the components of the restaurant search device 20 of the first embodiment.

[0075] Sensor 50 is worn by the candidate participant and measures data about the wearer's condition. Sensor 50 may include, for example, an accelerometer, a gyroscope, or a pressure sensor. The accelerometer can detect walking speed and the degree of body sway. The gyroscope can detect the wearer's body wobble or unstable movement. The pressure sensor may be incorporated into, for example, a shoe and measure the pressure distribution on the sole of the foot during walking. This allows for the detection of walking stability and changes in stride length. Sensor 50 may also include a heart rate sensor. The heart rate sensor measures the candidate participant's heart rate in real time.

[0076] The sensor 50 is mounted on or embedded in a wearable device such as a smartwatch, or in a smartphone. Alternatively, the sensor 50 may be incorporated into the insole of a shoe or into the shoe itself.

[0077] Sensor 50 acquires data at regular intervals (for example, any interval from 0.1 seconds to 1 second) and transmits the data to the data processing server 60 in real time using wireless communication technology. Data acquisition is performed continuously, for example, from before the start of the first meeting until after it ends, allowing for the tracking of changes in the walking patterns of the participating candidates over time.

[0078] The data processing server 60 receives data transmitted from the sensor 50. The data processing server 60 may perform preprocessing such as noise reduction, data normalization, and feature extraction. For example, as preprocessing, the data processing server 60 calculates indices that represent the characteristics of the walking pattern, such as walking speed, stride length, and body sway. The data processing server 60 transmits the data to the sensor data acquisition unit 28.

[0079] The sensor data acquisition unit 28 acquires sensor data. For example, the sensor data acquisition unit 28 acquires sensor data from the data processing server 60. The acquired data includes information such as each participant candidate's walking speed, stride length, degree of body sway, and regularity of walking rhythm. The sensor data acquisition unit 28 organizes this data for each participant candidate and passes it to the state analysis unit 29.

[0080] The state analysis unit 29 analyzes the data acquired by the sensor data acquisition unit 28 and evaluates the state of each participant candidate. Specifically, the state analysis unit 29 analyzes walking conditions such as changes in walking speed, changes in stride length, body sway, and walking stability. Regarding changes in walking speed, it analyzes whether the walking speed is slower than normal. Regarding changes in stride length, it analyzes whether the stride length is irregular. Regarding body sway, it analyzes whether there is an increase in swaying from side to side or forward and backward. Regarding walking stability, it analyzes whether the participant candidate is walking at a consistent rhythm. The state analysis unit 29 also analyzes whether the heart rate is elevated and the magnitude of heart rate variability.

[0081] The state analysis unit 29 comprehensively evaluates the results of the analysis of the walking state, for example, and estimates the degree of intoxication of each participant candidate. The state analysis unit 29 may evaluate the state according to the following criteria: Level 0: Normal walking state (no change). Level 1: Mild change (slight change in walking speed or stride length). Level 2: Moderate change (decreased walking speed, increased body sway). Level 3: Severe change (significant walking instability, large body sway). The state analysis unit 29 provides these evaluation results to the search unit 24.

[0082] The prediction unit 23 may predict the number of participants in the after-party based on the measurement results from the sensor 50. Candidates whose heart rate is significantly higher than normal may be highly fatigued and have a lower probability of participating in the after-party. Candidates with large fluctuations in heart rate may be strongly affected by alcohol, and their probability of participating in the after-party may fluctuate.

[0083] The search unit 24 sets search conditions based on the measurement results from the sensor 50. Specifically, for example, the search unit 24 adjusts the search conditions to be used based on the results of the state analysis unit 29's analysis of the degree of intoxication. If there are many participants at level 2 or higher, the search unit prioritizes searching for restaurants that are closer or have comfortable seating. It also prioritizes searching for restaurants with private rooms or partitioned seating. If the heart rates of the participants are generally high, the search unit prioritizes searching for restaurants with a quieter and more relaxing atmosphere. If there are many participants with large fluctuations in heart rate, the search unit prioritizes searching for restaurants with comfortable seating or private rooms. Through these adjustments, it becomes possible to select a more appropriate after-party venue that matches the condition of the participants.

[0084] Figure 12 illustrates an example screen for searching for a venue for a second party in the third embodiment. This screen is displayed, for example, when the organizer or participants are searching for a venue for a second party as the first party is nearing its end. The title "Second Party Search" is displayed at the top of the screen. Below that, information about the first party, which is currently underway, is displayed. Specifically, the name of the venue for the first party, "Washoku Izakaya 'Sakurazaka'", and the scheduled end time of the first party, "21:30", are listed. This allows the user to search for a second party while checking the current situation. Next, there is an item called "Participant Status", which displays the status of the candidate participants, analyzed based on data obtained from the sensor 50. "Walking Stability" indicates the average walking stability of all candidate participants, and is displayed as "Moderate" here. This reflects the analysis results by the status analysis unit 29. Also, "Predicted Participation Rate" is displayed as "60%", which indicates the predicted participation rate for the second party calculated by the prediction unit 23. In the lower half of the screen, there is an item called "Search Conditions", where the user can set conditions when searching for a venue for a second party. Three conditions are displayed: "Distance," "Budget," and "Seat Type," with a pull-down menu to the right of each condition.

[0085] For the "distance" condition, "within 500m" is currently selected. This setting takes into account the participants' walking stability as "moderate" and is intended to search within a relatively short distance. For the "budget" condition, "under 3000 yen" is selected, which may be set considering the expenses at the first party. For "seating type," "comfortable seating" is selected, which can be set considering the participants' condition. A "Start Search" button is located at the bottom of the screen. When the user taps this button, the search unit 24 starts searching for a suitable venue for the after-party based on the set conditions.

[0086] Figure 13 illustrates another example of the operation of the restaurant search device 20 in this disclosure. In step S31, the sensor data acquisition unit 28 acquires data from the sensors 50 worn by the candidate participants. This data includes information about walking. In step S32, the state analysis unit 29 analyzes the acquired sensor data and evaluates the walking state of the candidate participants. Specifically, it analyzes changes in walking speed, changes in stride length, body sway, walking stability, etc., and estimates the degree of intoxication of each candidate participant. In step S33, the prediction unit 23 predicts the number of participants in the after-party based on the analysis results of the state analysis unit 29 and the profile information acquired by the information acquisition unit 22. In this case, in addition to the usual prediction, the current walking state of the candidate participants may also be taken into consideration.

[0087] In step S34, the search unit 24 sets search conditions based on the predicted number of participants and the analysis results of their walking status. In step S35, the search unit 24 searches for restaurants suitable for a second party based on the set conditions. In this search, it refers to the information stored in the restaurant information database 32 and extracts restaurants that match the conditions. In step S36, the search results are displayed on the user terminal 10. The displayed information includes the name, location, capacity, budget, and characteristics of each restaurant. In addition, if there are any restaurants that are particularly recommended considering the current status of the potential participants, this may be highlighted. With this, the restaurant search device 20 completes the flow shown in Figure 13.

[0088] According to the third embodiment, it is possible to efficiently search for a suitable venue for the after-party while taking into account the current status of the prospective participants. This is because the search unit 24 sets search conditions such as the distance from the venue for the first party based on the measurement results of sensors that measure the movements of the members participating in the first party.

[0089] The third embodiment can also be implemented in combination with the second embodiment. In this case, a candidate store can be selected from the stores that have been re-searched using search conditions adjusted based on the results of the gait analysis, and the reservation process can be carried out. This makes it possible to smoothly set up a second party while ensuring the safety and comfort of the participants.

[0090] [Hardware configuration] In each of the embodiments described above, each component of the restaurant search device 20 represents a functional unit block. Some or all of the components of the restaurant search device 20 may be implemented by any combination of computer 500 and program.

[0091] Figure 14 is a block diagram showing an example of the hardware configuration of computer 500. Referring to Figure 14, computer 500 includes, for example, a processor 501, ROM (Read Only Memory) 502, RAM (Random Access Memory) 503, a program 504, a storage device 505, a drive device 507, a communication interface 508, an input device 509, an output device 510, an input / output interface 511, and a bus 512.

[0092] The processor 501 controls the entire computer 500. An example of a processor 501 is a CPU (Central Processing Unit). The number of processors 501 is not particularly limited; there may be one or more processors 501.

[0093] Program 504 includes instructions for implementing each function of the restaurant search device 20. Program 504 is pre-stored in ROM 502, RAM 503, and storage device 505. The processor 501 implements each function of the restaurant search device 20 by executing the instructions contained in Program 504. RAM 503 may also store data processed in each function of the restaurant search device 20.

[0094] The drive device 507 reads and writes to the recording medium 506. The communication interface 508 provides an interface with the communication network. The input device 509 is, for example, a mouse or keyboard, and receives information input from an administrator or the like. The output device 510 is, for example, a display, and outputs (displays) information to an administrator or the like. The input / output interface 511 provides an interface with peripheral devices. The bus 512 connects each of these hardware components. The program 504 may be supplied to the processor 501 via the communication network, or it may be stored in the recording medium 506 beforehand, read by the drive device 507, and supplied to the processor 501.

[0095] Note that the hardware configuration shown in Figure 14 is an example, and other components may be added, or some components may be omitted.

[0096] There are various ways to implement the restaurant search device 20. For example, the restaurant search device 20 may be implemented by any combination of different computers and programs for each component. Alternatively, the multiple components of the restaurant search device 20 may be implemented by any combination of a single computer and program.

[0097] Furthermore, at least a portion of the restaurant search device 20 may be provided in SaaS (Software as a Service) format. That is, at least a portion of the functions necessary to realize the restaurant search device 20 may be executed by software that runs over a network.

[0098] Although the present disclosure has been described above with reference to embodiments, the present disclosure is not limited to the embodiments described above. Various modifications to the configuration and details of the present disclosure are possible, as can be understood by those skilled in the art within the scope of the present disclosure. Furthermore, the configurations in each embodiment can be combined with one another, as long as they do not depart from the scope of the present disclosure.

[0099] Some or all of the above embodiments may be described as follows, but are not limited to the following:

[0100] [Note 1] A method for determining potential participants to be invited to a dinner party at a restaurant, A means of obtaining information to acquire the profile information of each selected candidate, A prediction means for predicting the number of participants who will attend the dinner party based on the aforementioned profile information, A search method to find restaurants that can accommodate a dinner party with the predicted number of people. A restaurant search device equipped with the following features.

[0101] [Note 2] A method for selecting a restaurant to make a reservation from the search results, A reservation management system that reserves selected restaurants for the predicted number of people. A restaurant search device as described in Appendix 1, comprising the following features.

[0102] [Note 3] The aforementioned reservation management system makes a provisional reservation within the range of the predicted number of people, and then proceeds to a final reservation after the number of participants is confirmed. The restaurant search device described in Appendix 2.

[0103] [Note 4] The prediction means outputs information on a predetermined number of participants whose probability of attending the dinner party is either high or low. A restaurant search device as described in any one of the appendices 1 to 3.

[0104] [Note 5] The aforementioned profile information includes information on past participation rates in dinner parties, or information on personal circumstances that may influence whether or not someone is able to attend a dinner party. A restaurant search device as described in any one of the appendices 1 to 4.

[0105] [Note 6] The aforementioned participation rate represents the percentage of past dinner parties to which a candidate participant has made a payment. The restaurant search device described in Appendix 5.

[0106] [Note 7] The search means sets search criteria for a restaurant for a second dinner party (a meal held after the first dinner party), including at least one of the following: distance from the restaurant for the first dinner party, atmosphere, and budget, based on information about the restaurant for the first dinner party (the first dinner party). A restaurant search device as described in any one of the appendices 1 to 5.

[0107] [Note 8] The search means sets search conditions for the venue of the second dinner party, which takes place after the first dinner party, including the distance from the venue of the first dinner party, based on the measurement results of sensors that measure the movements of the participants in the first dinner party. A restaurant search device as described in any one of the appendices 1 to 6.

[0108] [Note 9] We will select the potential participants to invite to the dinner party at the restaurant. We obtain the profile information of each selected candidate. Based on the aforementioned profile information, we predict the number of potential participants who will attend the dinner party. Search for restaurants that can accommodate the predicted number of people for a dinner party. How to search for restaurants.

[0109] [Note 10] We will select the potential participants to invite to the dinner party at the restaurant. We obtain the profile information of each selected candidate. Based on the aforementioned profile information, we predict the number of potential participants who will attend the dinner party. Search for restaurants that can accommodate the predicted number of people for a dinner party. A program that instructs a computer to perform a process.

[0110] Some or all of the configurations described in Appendices 2-8, which are dependent on Appendice 1 above, may also be dependent on Appendices 9-10 in the same manner as in Appendices 2-8. Not limited to Appendices 1 and 9-10, some or all of the configurations described as appendices may also be dependent on various hardware, software, various recording devices or systems for recording software, without departing from the embodiments described above. [Explanation of Symbols]

[0111] 100, 200, 300 Restaurant Search System 10 User terminals 20 Restaurant search device, 21 Candidate selection unit, 22 Information acquisition unit, 23 Prediction unit, 24 Search unit, 25 Store selection unit, 26 Reservation management unit, 27 Notification unit, 28 Sensor data acquisition unit, 29 State analysis unit 30 Databases, 31 Profile Information Database, 32 Store Information Database 40 External systems, 41 SNS servers, 42 Mail servers 50 sensors 60 Data Processing Servers

Claims

1. A method for determining potential participants to be invited to a dinner party at a restaurant, A means of obtaining information to acquire the profile information of each selected candidate, A prediction means for predicting the number of participants who will attend the dinner party based on the aforementioned profile information, A search method to find restaurants that can accommodate a dinner party with the predicted number of people. A restaurant search device equipped with the following features.

2. A method for selecting a restaurant to make a reservation from the search results, A reservation management system that reserves selected restaurants for the predicted number of people. The restaurant search device according to claim 1, comprising:

3. The aforementioned reservation management system makes a provisional reservation within the range of the predicted number of people, and then proceeds to a final reservation after the number of participants is confirmed. The restaurant search device according to claim 2.

4. The prediction means outputs information on a predetermined number of participants whose probability of attending the dinner party is either high or low. A restaurant search device according to any one of claims 1 to 3.

5. The aforementioned profile information includes information on past participation rates in dinner parties, or information on personal circumstances that may influence whether or not someone is able to attend a dinner party. A restaurant search device according to any one of claims 1 to 3.

6. The aforementioned participation rate represents the percentage of past dinner parties to which a candidate participant has made a payment. The restaurant search device according to claim 5.

7. The search means sets search criteria for a restaurant for a second dinner party (a meal held after the first dinner party), including at least one of the following: distance from the restaurant for the first dinner party, atmosphere, and budget, based on information about the restaurant for the first dinner party (the first dinner party). A restaurant search device according to any one of claims 1 to 3.

8. The search means sets search conditions for the venue of the second dinner party, which takes place after the first dinner party, including the distance from the venue of the first dinner party, based on the measurement results of sensors that measure the movements of the participants in the first dinner party. A restaurant search device according to any one of claims 1 to 3.

9. We will select the potential participants to invite to the dinner party at the restaurant. We obtain the profile information of each selected candidate. Based on the aforementioned profile information, we predict the number of potential participants who will attend the dinner party. Search for restaurants that can accommodate the predicted number of people for a dinner party. How to search for restaurants.

10. We will select the potential participants to invite to the dinner party at the restaurant. We obtain the profile information of each selected candidate. Based on the aforementioned profile information, we predict the number of potential participants who will attend the dinner party. Search for restaurants that can accommodate the predicted number of people for a dinner party. A program that instructs a computer to perform a process.

Images