Information processing device, program, and information processing method

Abstract

To provide an information processing device, a program, and an information processing method which suppress simultaneous turn waiting registration so as to be able to improve the ability to attract customers at a facility.SOLUTION: A turn management server 10 (information processing device) includes a CPU 11 functioning as: a reception section for receiving user's request for turn waiting at a facility so as to generate reception request information; a management section for managing turn waiting information as already-registered information on the turn waiting; and a determination section for determining whether to receive registration of the turn waiting related to the reception request information on the basis of the turn waiting information managed by the management section and the reception request information.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present disclosure relates to an information processing apparatus, a program, and an information processing method.

Background Art

[0002] A system for registering and managing the waiting order of users (customers) waiting to use a store (facility) is known, for example, from Patent Document 1. Such a waiting order management system accepts the waiting order of customers by a reception terminal arranged at the entrance of a store or the like, or a terminal (tablet, smartphone, personal computer, etc.) possessed by the user.

[0003] However, in such a waiting order management system, some users register for waiting orders at multiple facilities simultaneously, and actually use only some of the multiple facilities for which they have registered for the waiting order, and may not appear at other facilities even when their turn comes. In this case, it is not clear whether the facility should cancel the waiting order of the user, and it may be difficult to handle.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In view of this problem, the present disclosure provides an information processing apparatus, a program, and a method capable of suppressing simultaneous waiting order registration for facilities with a low possibility of simultaneous access.

Means for Solving the Problems

[0006] To solve the above problems, the information processing device of this disclosure includes: a reception unit that receives a request from a user to join the waiting list for a facility and generates a reception request information; a management unit that manages waiting list information, which is already registered waiting list information; and a determination unit that determines whether or not to accept the registration of the waiting list related to the reception request information based on the waiting list information managed by the management unit and the reception request information. [Effects of the Invention]

[0007] The technology disclosed herein provides an information processing device, program, and method that can prevent simultaneous registration of people in the waiting list for each facility, even though the likelihood of each person visiting each facility is low. Other issues, configurations, and effects will be revealed by the following description of the embodiments. [Brief explanation of the drawing]

[0008] [Figure 1] This is a configuration diagram of the sequence management system 1 according to the first embodiment. [Figure 2] This is a hardware configuration diagram and a functional block diagram of the sequence management server 10. [Figure 3] This figure shows an example of a store table 142 and an example of a sequence management table 143 stored in database 141. [Figure 4] This shows the hardware configuration diagram and functional block diagram of the management terminal 20. [Figure 5] This is a hardware configuration diagram and a functional block diagram of user terminal 50. [Figure 6] This figure shows examples of the order management screen 222 and the modification screen 223. [Figure 7] This is a flowchart explaining the procedure for registering for a waiting list. [Figure 8] This is a flowchart explaining the procedure for registering for a waiting list. [Figure 9] This is an example of a display screen explaining the procedure for registering for a queue. [Figure 10]This is an example of a display screen for explaining the execution procedure of the registration method for waiting in line. [Figure 11] This is an example of a display screen for explaining the execution procedure of the registration method for waiting in line. [Figure 12] This is a diagram showing an example of the store table 142 stored in the database 141. [Figure 13] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 14] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 15] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 16] This is a diagram showing an example of the store table 142 stored in the database 141. [Figure 17A] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 17B] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 18] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 19] This is a diagram showing an example of the store table 142 stored in the database 141. [Figure 20] This is a flowchart for explaining the execution procedure of the registration method for waiting in line. [Figure 21] This is a flowchart for explaining the execution procedure of the registration method for waiting in line.

Embodiments for Carrying Out the Invention

[0009] Hereinafter, this embodiment will be described with reference to the accompanying drawings. In the accompanying drawings, functionally identical elements may sometimes be denoted by the same reference numerals. Note that the accompanying drawings show embodiments in accordance with the principles of the present disclosure, but these are for the purpose of understanding the present disclosure and are not used to limit the present disclosure in any way. The description in this specification is merely a typical example and does not limit the scope of the claims or the application examples of the present disclosure in any sense.

[0010] In this embodiment, although the description has been made in sufficient detail for those skilled in the art to implement the present disclosure, other implementation forms are also possible, and it is necessary to understand that configuration and structural changes and replacement of various elements can be made without departing from the scope and spirit of the technical idea of the present disclosure. Therefore, the following description should not be construed as being limited thereto.

[0011] [First Embodiment] Referring to FIGS. 1 to 11, a sequence management system according to the first embodiment will be described. The sequence management system of this first embodiment receives the waiting requests of users (customers) who wish to use stores R1 to Rn, and notifies the user terminals when the turn of each user approaches or when the turn of each user arrives.

[0012] In this specification, the "user" refers to a group of customers who wait in line at a store or the like using this system, including both cases where the number of people in a group is plural and cases where the number of people in a group is one. Further, the "user terminal" refers to the user terminal owned by the user who has made a waiting request among a group of users. Note that stores R1 to Rn are an example of facilities used by users, and in addition to restaurants, various types of stores (beauty salons, nail salons, travel agencies, insurance agencies, etc.) where users receive various services, tourist facilities, local governments, bank windows, etc. may be included. Also, stores R1 to Rn are an example of facilities where users can wait in line and use. Facilities that can be targeted include, in addition to stores, for example, hospitals and public facilities.

[0013] FIG. 1 is a configuration diagram of a sequence management system 1 according to the first embodiment. The sequence management system 1 is a system that manages the waiting in line of users in stores R1 to Rn, and includes a sequence management server 10 (information processing device), a management terminal 20, and user terminals 50. The sequence management server 10, the management terminal 20, and the user terminals 50 are interconnected via a network 60 such as the Internet, for example.

[0014] The queue management server 10 is a computer that controls the entire system and holds programs and data for queue management. The management terminal 20 is located within the stores R1 to Rn that are subject to queue management by this system and is operated by the store staff, etc. The management terminal 20 is a terminal for setting store information and managing users who have registered for the queue, and is configured to display a GUI screen. The queue management server 10 is located not within the stores R1 to Rn, but at the business premises of the company that operates this system, and manages queue-related data received from the management terminal 20, and performs various decisions and data processing related to the queue based on this data.

[0015] The user terminal 50 is a communication device with communication capabilities, such as a smartphone or tablet, and is a terminal owned by a user of the service provided by the queue management system 1. The user terminal 50 is connected to the queue management server 10 via internet communication through the network 60.

[0016] The queue management server 10 stores queue-related data received from the management terminal 20 and other devices in a database. The queue management server 10 manages the latest queue status for each store in the database by updating the database according to the data received from the management terminal 20 and user terminal 50. Whether the data is "latest" can be determined, for example, based on the date and time the information was sent from the management terminal 20.

[0017] A user intending to visit any of stores R1 through Rn can access the queue management server 10 via application software for this system installed on the user terminal 50 or via a browser, and request the queue management server 10 to register for the queue at the desired store. In this configuration, queue registration is performed on the application software or browser displayed on the user terminal 50. The queue management server 10 responds to the request and accepts the queue registration under predetermined conditions. The queue management server 10 checks whether the predetermined conditions are met by referring to the database.

[0018] If the specified conditions are met, the queue management server 10 accepts the registration of the queue for the request and sends a message to the user terminal 50 to that effect, as well as information regarding the queue registration to the management terminal 20 of the corresponding store. On the other hand, if it is determined that the conditions are not met, the queue management server 10 sends information to the user terminal 50 to that effect.

[0019] Figure 2(a) is a hardware configuration diagram of the sequence management server 10. The sequence management server 10 can be configured using a general-purpose server computer, and as an example, it may include a CPU (Central Processing Unit) 11, ROM (Read Only Memory) 12, RAM (Random Access Memory) 13, storage device 14, and communication device 15.

[0020] The CPU 11 implements the functions provided by the sequence management server 10 by executing a program described later. The ROM 12 and RAM 13 hold the data used by the CPU 11. The storage device 14 stores the program and database that provide the operation of this system. The communication device 15 communicates with the management terminal 20 and the user terminal 50 via the network 60.

[0021] Figure 2(b) is a functional block diagram of the queue management server 10. The queue management server 10 includes a communication control unit 111, a display control unit 112, and a determination unit 113 as software modules (functions configured by deploying various programs in the internal memory of the CPU 11) executed by the CPU 11. For convenience of description below, these modules may be described as the main operating units, but since the CPU 11 is the one that actually executes these modules, the CPU 11 can also be described as the main operating unit.

[0022] The storage device 14 houses the database 141, which serves as a storage unit. The database 141 is a management unit that manages a store table 142 containing pre-registered store information and a queue management table 143 containing data on queues at each store (queue information).

[0023] The communication control unit 111 receives store information and queue status from the management terminal 20 via the communication device 15. The communication control unit 111 also functions as a reception unit that receives queue registration requests and user information entered at the time of request acceptance from the user terminal 50 via the communication device 15 and generates acceptance request information. The display control unit 112 controls the display of data on the user terminal 50 based on the data received by the communication control unit 111. When the determination unit 113 receives information regarding a queue registration request from the user terminal 50 or the management terminal 20, it compares the information related to the request with the information stored in the queue management table 143 to determine whether the request meets predetermined conditions. The communication control unit 111 transmits the determination result determined by the determination unit 113 to the management terminal 20 or the user terminal 50 via the communication device 15.

[0024] Figure 3(a) shows an example of a store table 142 stored in database 141. The store table 142 is a data table that manages store information for stores that have implemented the service provided by the queue management system 1. The store table 142 has data items such as store ID data 1421, store name data 1422, store genre data 1423, store introduction data 1424, address data 1425, and telephone number data 1426. One record in the store table 142 manages the store information for one store.

[0025] Store ID data 1421 is data containing an ID to identify each store. Store name data 1422 is data indicating the name of the store. Store genre data 1423 is data indicating the type of business or business format (genre) of the store. Store introduction data 1424 is data related to an introduction that shows the type of business, selling points, services offered, ongoing campaigns, etc. of the store. Address data 1425 is data indicating the address of the store or the address of the facility in which the store is located. Telephone number data 1426 is data indicating the telephone number of the store. The store information recorded in the store table 142 can be entered by store employees from the management terminal 20, or by the operator of the queue management server 10, etc., at the request of the store manager, etc.

[0026] Figure 3(b) shows an example of a queue management table 143 stored in the database 141. The queue management table 143 is a data table that manages reception information, including user information of users who have registered for the queue at each store. The table shown in Figure 3(b) is a table related to queue registration at one store, and a table like the one shown in Figure 3(b) is provided for each store. One row in a table shows queue data for one set of users. The queue management table 143 may have data items such as reception ID data 1431, reception number data 1432, queue status data 1433, number of people data 1434, reception time data 1435, waiting time data 1436, telephone number data 1437, and email address data 1438.

[0027] The reception ID data 1431 is an ID used to identify the user who registered for the waiting list. The reception number data 1432 is a number assigned to each user in the order in which their waiting list registration was received. The waiting list status data 1433 shows the waiting list status for each user. For example, if the user has been guided into the store, it will be "Registration Completed," if they are being called, it will be "Calling," if the user or store staff has canceled, it will be "Canceled," and if they have not yet been called, it will be blank. Although not shown in the diagram, if the waiting list registration is canceled, the waiting list status data 1433 will be "Canceled."

[0028] The number of people data 1434 represents the number of users in a single queue, and is the number entered by the user from the user terminal 50. The reception time data 1435 indicates the time when the user can come to the store. The waiting time data 1436 indicates the time the user should wait from the time they register for the queue until the reception time. The telephone number data 1437 and email address data 1438 are the telephone number and email address of the representative of the group of users who have registered for the queue. Note that only one of the telephone number or email address may be registered. Alternatively, SNS account information may be registered in place of, or in addition to, the telephone number and email address data, and registered in the queue management table 143.

[0029] Figure 4(a) is a hardware configuration diagram of the management terminal 20. The management terminal 20 comprises a CPU 21 (processing unit), a display device 22, an input device 23, and a communication device 24. The CPU 21 controls each part of the management terminal 20. The communication device 24 is configured to communicate with the queue management server 10 via the network 60. The communication device 24 receives a GUI screen for inputting store information, etc., and a GUI screen for managing the queue status from the queue management server 10. The display device 22 displays the GUI screen received from the queue management server 10. The input device 23 is an interface used by store employees to input operation instructions for the management terminal 20. For example, the display device 22 and the input device 23 can be configured as an integrated unit using a touch panel or the like.

[0030] Figure 4(b) is a functional block diagram of the management terminal 20. The management terminal 20 includes a storage unit 211, a communication control unit 212, a setting unit 213, and a display control unit 214 as software modules (functions configured by deploying various programs into the internal memory of the CPU 21) executed by the CPU 21. For convenience of description below, these modules may be described as the operating units, but since the CPU 21 is the one that actually executes these modules, the CPU 21 can also be described as the operating unit.

[0031] The memory unit 211 functions as the internal memory of the CPU 21. The communication control unit 212 communicates with the queue management server 10 via the communication device 24. Specifically, the communication control unit 212 receives the GUI screen from the queue management server 10. The setting unit 213 receives the store information and queue status entered by the store clerk via the input device 23 and the GUI screen. The communication control unit 212 transmits the store information and queue status entered by the store clerk to the queue management server 10. The display control unit 214 controls the display on the display device 22. Specifically, the display control unit 214 displays the GUI screen received from the queue management server 10 on the display device 22.

[0032] Figure 5(a) is a hardware configuration diagram of the user terminal 50. The user terminal 50 comprises a CPU 51 (processing unit), a display device 52, an input device 53, and a communication device 54. The CPU 51 controls each part of the user terminal 50. The communication device 54 communicates with the queue management server 10 via the network 60, sends a queue registration request, and receives a reception screen from the queue management server 10. The display device 52 displays various information received from the queue management server 10. The input device 53 is an interface used by the user to input operation instructions for the user terminal 50. For example, the display device 52 and the input device 53 can be configured as an integrated unit using a touch panel or the like.

[0033] Figure 5(b) is a functional block diagram of the user terminal 50. The user terminal 50 includes a storage unit 511, a communication control unit 512, a reception unit 513, and a display control unit 514 as software modules (functions configured by deploying various programs into the internal memory of the CPU 51) executed by the CPU 51. For convenience of description below, these modules may be described as the operating units, but since the CPU 51 is the one that actually executes these modules, the CPU 51 can also be described as the operating unit.

[0034] The memory unit 511 functions as the internal memory of the CPU 51. The communication control unit 512 communicates with the queue management server 10 and other devices via the communication device 54. Specifically, when the communication control unit 512 receives an instruction from the user to send a queue registration request via the input device 53, it sends the request to the queue management server 10. The communication control unit 512 also receives a screen from the queue management server 10 indicating that the queue registration is complete. The reception unit 513 receives user information entered by the user via the input device 53 and the reception screen. The display control unit 514 controls the display of the display device 52. Specifically, the display control unit 514 displays various information received from the queue management server 10.

[0035] Figure 6(a) is a schematic diagram showing the queue management screen 222 displayed on the display device 22 of the management terminal 20. The queue management screen 222 includes, as an example, text 2221 indicating the number of waiting groups, text 2222 indicating the timing of notifications to users, reception information 2223 for users who have registered for the queue, operation buttons 2224, a reception completion button 2225, and a batch cancellation button 2226.

[0036] The reception information 2223 displays any item from the queue management table 143. In the example in Figure 6(a), "reception number," "waiting status," "number of people," and "reception time" are displayed. The reception end button 2225 is clicked when the store will no longer accept queues, for example, when the store's business hours end or when it is time for last orders. When a store employee clicks the operation button 2224 for a particular reception number, a screen for changing the "waiting status" is displayed.

[0037] Figure 6(b) is a schematic diagram showing the queue management screen 222 with the queue status change screen 223 overlaid. In Figure 6(b), the change screen 223 is shown when changing the "queue status" of reception number 12. The change screen 223 has a call button 2231, a reception completion button 2232, a cancel button 2233, and a save button 2234.

[0038] When a staff member clicks either the call button 2231, the reception completion button 2232, or the cancel button 2233, and then clicks the save button 2234, the setting unit 213 of the management terminal 20 sends information to the queue management server 10 via the communication control unit 212 indicating that the queue status has changed. When the queue management server 10 receives the information indicating that the queue status has changed, it updates the queue status in the queue management table 143 and sends the updated information to the management terminal 20. As a result, the display control unit 214 of the management terminal 20 updates the "queue status" in the reception information 2223.

[0039] When the staff member clicks the call button 2231 and the save button 2234, a notification indicating that a call has been made is sent to the user terminal 50. When the user arrives and the assistance is completed, the staff member clicks the reception complete button 2232 and the save button 2234. As a result, the reception information of the user who has been marked as reception complete is removed from the list of reception information 2223.

[0040] If a user who has been called does not show up and a predetermined amount of time has elapsed since the time slot in which they registered for the waiting list, the staff member can cancel the user's waiting list registration by clicking the cancel button 2233 and the save button 2234. As a result, the reception information of the user whose registration has been canceled is removed from the list of reception information 2223. Alternatively, if a user who has been called does not show up and the reception completion button 2232 has not been pressed even after a predetermined amount of time has elapsed since the time slot in which they registered for the waiting list, the queue management server 10 or the management terminal 20 may be configured to automatically cancel the user's waiting list registration. In this manner, when a user's waiting list registration is canceled, the queue management server 10 or the management terminal 20 may send a notification to the contact person registered by the user indicating that the registration has been canceled.

[0041] The procedure for registering for a queue using the user terminal 50 will be explained with reference to the flowcharts and display screen examples in Figures 7 to 11. Figures 7 and 8 are flowcharts of the queue acceptance process executed by the user terminal 50. First, in step S31, the user terminal 50 launches the application software or browser of this system in response to user operation and displays a reception screen on the display device 52 of the user terminal 50 that accepts queue requests for the store the user wishes to visit. Figure 9 shows an example of the reception screen 322 displayed on the display device 52 of the user terminal 50. The reception screen 322 displays text 3221 indicating how many groups are waiting in line at the store, and a request button 3222. The reception screen 322 may also display a list of groups currently registered for the queue. In the example in Figure 9, the text 3221 indicates that there are 5 groups waiting.

[0042] When the request button 3222 is pressed, the process proceeds to step S32. In step S32, the display control unit 514 sequentially switches to display screens 324 to 326 as shown in Figures 10(a) to (c), and the reception unit 513 accepts the queue in response to user operation. On these display screens 324 to 326, the user inputs information regarding the queue request, including the user's specific information (such as a phone number), and a queue request is made. On the number input screen 324 in Figure 10(a), the reception unit 513 accepts the number of people who wish to join the queue based on user operation using the numeric keypad 3223. When the "Next" button 3224 is pressed, the process switches to screen 325 in Figure 10(b), and the reception unit 513 accepts the phone number of the user (or representative in the case of multiple people) based on user operation using the numeric keypad 3225. When a phone number is entered and the "Next" button 3226 is pressed, a screen 326 as shown in Figure 10(c) is displayed, and a final confirmation is made to accept the request to register for the waiting list. If the request is to proceed, the "Request Complete" button 3227 is pressed, and the reception unit 513 completes the acceptance of the waiting list request. If the input content is to be corrected, the "Back" button is pressed. In this step, the case of entering a phone number as an example of user contact information has been explained, but an email address or SNS account information may be entered in place of or in addition to the phone number. When the "Request Complete" button 3227 is pressed on the screen shown in Figure 10(c), the communication control unit 512 of the user terminal 50 sends the waiting list acceptance information received by the reception unit 513 to the waiting list management server 10. Next, in step S33, the communication control unit 512 obtains judgment information from the waiting list management server 10 indicating the result of the judgment on whether or not the waiting list can be accepted.

[0043] In step S34, the display control unit 514 checks whether the judgment information obtained in step S33 indicates acceptance or rejection. If the judgment result is acceptance, the process proceeds to step S35, where the display control unit 514 generates a registration completion screen 327, such as shown in Figure 11(a), and displays it on the display device 52. The display control unit 514 displays the registration completion screen 327 received from the queue management server 10. The registration completion screen 327 displays, for example, the reception number 3271, queue ticket image data 3273 to be presented upon arrival, and a notice for arrival 3274, as shown in Figure 11(a). This completes the acceptance of the queue registration via the user terminal 50.

[0044] On the other hand, if the judgment information is unacceptable, the process proceeds to step S36, in which step S36 the display control unit 514 generates a registration rejection screen 328, for example, as shown in Figure 11(b), and displays it on the display device 52. The registration rejection screen 328 displays, for example, as shown in Figure 11(b), the fact that the request could not be completed, the reason for this 3275, and the name of the store where a queue has already been registered (e.g., Coffee Room C) 3276. Below this, a button 3277 to cancel the queue for the store where a queue has already been registered (Coffee Room C) and a button 3278 to cancel the queue for the store where a queue has been newly requested (Cafe Restaurant A) are displayed. When button 3277 is pressed, the system becomes ready to accept a queue for a new store, and the screen shown in Figure 11(a) is displayed again. When button 3278 is pressed, the queue request for the new store is canceled, and the process shown in Figure 8 ends. The above describes the method of registering a queue using the user terminal 50.

[0045] Next, the process for determining whether or not to accept a queue order, which is performed by the queue management server 10, will be explained with reference to Figure 8. Figure 8 is a flowchart (steps S41 to S45) of the queue order acceptance determination process. First, in step S41, the communication control unit 111 obtains queue order acceptance information from the user terminal 50. Here, the queue order acceptance information includes the target store, the number of people, and the telephone number.

[0046] Next, in step S42, the determination unit 113 refers to the queue management table 143 to determine whether there is a store where the user terminal 50 included in the queue waiting information is already waiting in line. Here, the determination unit 113 makes the determination based on whether there is a queue registration with the same phone number as the phone number included in the queue waiting information, and whose waiting status is neither "reception completed" nor "cancelled". In addition, a similar determination may be made using an email address or identification information of the user terminal 50. If the determination unit 113 determines in step S42 that there is no store where the user is waiting in line, the process proceeds to step S45.

[0047] In step S42, if the determination unit 113 determines that there is a store on the waiting list, the process proceeds to step S43. In step S43, the determination unit 113 obtains the genre information of the store to which the user has already registered for the waiting list from the store table 142, and determines whether the genre of the store to which the user has already registered for the waiting list is the same as the genre of the store to which the user has newly requested to register for the waiting list. In other words, in this embodiment, a waiting list condition is set that simultaneous waiting lists for the same genre are not allowed. This condition is based on the idea that, for the same genre, it is highly likely that the user will only visit one of the two stores and not the other.

[0048] If the determination unit 113 determines Yes in step S43, the communication control unit 111 outputs a determination result to the user terminal 50 as determination information indicating that the queue request for the specified store cannot be accepted (NG) (step S44). On the other hand, if the determination unit 113 determines No in step S43, the process proceeds to step S45. In step S45, the communication control unit 111 outputs a determination result to the user terminal 50 as determination information indicating that the queue request for the newly specified store has been accepted.

[0049] As explained above, the system of the first embodiment prevents users from registering for the same genre of waiting list simultaneously. This prevents situations where users who have registered for the waiting list do not show up at the store at the scheduled time. If such waiting lists are suppressed, the total number of waiting groups (total number of groups) at each store will decrease overall. This leads to an increase in the store's ability to attract customers, and for other users, it prevents the display of more waiting groups and estimated waiting times than are actually present.

[0050] In this first embodiment, if the two stores involved in the queue registration belong to different genres, overlapping queues are permitted. For example, there may be cases where a customer wants to make effective use of their time by waiting at a cafe while waiting in line at a shop, and in such cases, it is effective to allow simultaneous overlapping queues.

[0051] Here, a modified version of the first embodiment will be described. First, referring to Figures 12 and 13, Modification 1 of the first embodiment is shown. In this Modification 1, even if there are queue requests for multiple stores of the same genre, simultaneous queueing is permitted if predetermined exclusion conditions are met, which is different from the first embodiment.

[0052] In this modified example 1, as shown in Figure 12, for example, the data items in the store table 142 stored in the database 141 include conditions (exclusion conditions) that allow simultaneous waiting in line. Examples of exclusion conditions include: (i) allowing simultaneous waiting in line if they are in the same building, even if they are of the same genre (store ID 001 in Figure 12); (ii) allowing simultaneous waiting in line if they are sister stores of the store in question (store ID 002 in Figure 12); and (iii) always allowing simultaneous waiting in line regardless of genre (store ID 003 in Figure 12). Other possible exclusion conditions include allowing simultaneous waiting in line for a restaurant if the store already registered for waiting in line is a cafe.

[0053] Figure 13 is a flowchart illustrating the execution procedure for registering queues in this modified example 1. The operation in Figure 7 and the operations from steps S41 to S43 in Figure 8 are the same as in the first embodiment. If a "Yes" determination is made in step S43, before step S44, step S43-1 determines whether or not the exclusion conditions are met. If the exclusion conditions are not met, the process proceeds to step S44. On the other hand, if the exclusion conditions are met, the process proceeds to step S45, where a procedure is executed to register a new store in the queue in order to allow simultaneous queues. According to this modified example 1, the determination of simultaneous queue requests is more flexible compared to the first embodiment, and simultaneous queues can be set according to the characteristics and requests of each store.

[0054] Referring to Figure 14, a modified example 2 of the first embodiment is shown. The operation in Figure 7 and the operations from steps S41 to S43 in Figure 8 are the same as in the first embodiment, so they are not shown. In this modified example 2, even if the queue request is made by the same user in the same genre, simultaneous queueing is allowed if the positional relationship between the two stores satisfies the conditions, for example, if the distance between the two stores is within a predetermined distance (step 43-2 in Figure 14), which is different from the first embodiment.

[0055] Referring to Figure 15, a third modification of the first embodiment is shown. Figure 15 is a flowchart illustrating the operation procedure of the third modification, where the operation, steps S41-S42, and steps S43-S45 in Figure 7 are the same as in the first embodiment (Figure 8).

[0056] In this modified example 3, information indicating whether simultaneous waiting lists for the same genre are permitted is pre-registered in the database 141 for each genre. For example, genres that sell goods, such as retail stores, are set as genres that allow simultaneous waiting lists, including for the same genre, while genres that provide food and beverages, such as izakayas and restaurants, and tourist facilities, such as art museums and museums, are set as genres that do not allow simultaneous waiting lists for the same genre. Then, in step S43-3, it is determined whether the genre of either a store that has already registered for a waiting list or a store related to a new waiting list request is a genre that allows simultaneous waiting lists. If yes, the process proceeds to step S45 to register the waiting list for the new waiting list request. If no, the process proceeds to step S43, and thereafter the same operations as in the first embodiment are performed. According to this modified example 3, regarding simultaneous waiting list requests, a more flexible determination is made compared to the first embodiment, and restrictions on simultaneous registration that are appropriate for the genre can be set.

[0057] [Second Embodiment] Next, a queue management system according to the second embodiment will be described. The queue management system of this second embodiment is similar to the first embodiment in that it accepts queue requests from users (customers) who wish to use stores R1 to Rn under predetermined conditions. The hardware configuration of the system can also be substantially the same as that of the first embodiment. However, the setting of the conditions for accepting queue requests in this second embodiment differs from that of the first embodiment. Specifically, in the first embodiment, a new queue request is rejected if the store to which a queue has already been registered and the store to which a new queue request pertains are the same genre and the same time slot. In contrast, in the second embodiment, data on the average waiting time at stores to which a queue has already been registered and the average waiting time at the store to which a new queue request pertains are obtained, and a decision is made on whether or not to allow the registration of a new queue based on the comparison result between these average waiting time data or against a threshold.

[0058] Figure 16 shows an example of a store table 142 stored in the database 141 in the system of the second embodiment. In addition to the same data items as in the first embodiment, this store table 142 stores average waiting time data 1428 for that store. This average waiting time data 1428 is used as a criterion for determining whether or not to allow the registration of a new queue.

[0059] Referring to the flowchart in Figure 17A, the procedure for registering a queue using the user terminal 50 in the system of the second embodiment will be explained. The operation in Figure 7 and steps S41 to S42 (Figure 8) are the same as in the first embodiment. In step S43-4, the average waiting time data 1428 described above is referenced to obtain the first average waiting time data T1, which is obtained by subtracting the elapsed time since queue registration from the average waiting time for stores that have already registered for queues. Similarly, in step S43-5, the average waiting time data 1428 is referenced to obtain the second average waiting time data T2 based on the average waiting time for stores for which a new queue request has been made.

[0060] In the following step S43-6, it is determined whether the absolute difference between T1 and T2, |T1-T2|, is less than or equal to S2 (minutes). S2 is the difference in average waiting times between the stores that are allowed to register simultaneously, and is set in advance. S2 can also be set for each genre or store. For example, for restaurants and other eateries where customers are expected to stay for 30 minutes or more after entering, S2 can be set to 30 (minutes), while for municipal service counters where customers are expected to complete the procedure in about 10 minutes after their turn comes, S2 can be set to 10 (minutes). If the answer is Yes, the process moves to step S44, and the new waiting list registration is rejected. This is based on the idea that if the difference between the two is less than or equal to S2, the possibility of being able to visit both the store where the customer is already registered on the waiting list and the store where they are newly requesting to join the waiting list is very low, and therefore the new waiting list should not be allowed. If the answer is No, the process moves to step S45, and the new waiting list request is allowed.

[0061] Referring to Figure 17B, the execution procedure for the queue registration method of Modification 1 of the second embodiment will be explained. In this Modification 1, step S43-7 is executed before step S43-6. In step S43-7, it is determined whether the first average waiting time data T1 is less than or equal to S1 (minutes). S1 is, for example, 15 (minutes). If Yes, the process proceeds to step S44, and the registration of a new queue is rejected. This is based on the idea that if the waiting time of a store where a queue has already been registered is 15 minutes or less, the customer's turn will come soon, and therefore simultaneous queue registration should not be allowed. On the other hand, if the determination in step S43-7 is No, the process proceeds to step S43-6.

[0062] Figure 18 shows the procedure for processing queue requests in a system according to a modified example 2 of the second embodiment. Step numbers identical to those in Figure 17B are also used in Figure 18, so redundant explanations will be omitted below.

[0063] In this modified example, after step S43-5, step S43-8 is performed instead of steps S43-7 and S43-6 to determine whether the first average waiting time data T1 is greater than or equal to L1 (minutes) and the second average waiting time data T2 is less than or equal to S3 (minutes). For example, L1 is 60 minutes and S3 is 15 minutes.

[0064] If the determination in step S43-8 is Yes, proceed to step S45; otherwise, proceed to step S44, and the same procedure as in the second embodiment is performed thereafter. It is also possible to combine the modifications 1 and 2.

[0065] If the waiting time at a store where a user has already registered for a queue is long, and the waiting time at a new store where a user is about to join the queue is short, there is a high probability that the user will be able to use the former store after finishing their use of the latter. Therefore, in the second embodiment (including variations 1 to 3), the difference between the first average waiting time T1 and the second average waiting time T2 is compared with a threshold to determine whether simultaneous use is possible. Variations 1 and 2 described above can improve user convenience and increase the efficiency of attracting customers at each store by allowing such simultaneous queues. Alternatively, the estimated remaining waiting time for registered stores may be calculated by subtracting the time already spent waiting (the difference between the time of registration and the current time) from the average waiting time for already registered stores, and this estimated remaining waiting time may be compared with the second average waiting time to determine whether it is acceptable. Alternatively, instead of the average waiting time, the estimated waiting time per group may be kept, and the estimated waiting time may be calculated by multiplying the number of waiting groups by the estimated waiting time per group. This estimated waiting time may then be compared with the estimated waiting time for a store where a queue has already been registered to determine whether it is acceptable.

[0066] [Third Embodiment] Next, a queue management system according to a third embodiment will be described. This third embodiment of the queue management system is similar to the previously described embodiment in that it accepts the request to wait in line from users (customers) who wish to use stores R1 to Rn under predetermined conditions. The hardware configuration of the system can also be substantially the same as that of the previously described embodiment. However, this third embodiment differs from the previously described embodiment in how it sets the conditions for accepting the request to wait in line. Specifically, in the third embodiment, data on the average waiting time at each store and data on the average usage time at each store are referenced to determine whether or not to allow simultaneous waiting in line.

[0067] FIG. 19 is a diagram showing an example of a store table 142 stored in a database 141 in the system of the third embodiment. In addition to the same data items as those in the first embodiment, this store table 142 stores average waiting time data 1428 and average usage time data 1429 (the average stay time of customers in that store) in that store as data items. The average waiting time data 1428 and the average usage time data 1429 are used as a basis for determining whether to allow simultaneous queueing registration.

[0068] FIG. 20 shows a procedure of a process for determining whether to allow simultaneous queueing executed by the queue management server 10 in a system according to a modification of the third embodiment. In FIG. 20, the operations in FIG. 7, and steps S41 to S42, S43-4 to S43-5, and S44 to S45 are the same as those in the second embodiment (FIG. 17A), and thus the illustration is omitted.

[0069] In steps S43-4 and S43-5, after obtaining the first average waiting time data T1 and the second average waiting time data T2 in the same manner as in the second embodiment, in step S43-8, the magnitude relationship between T1 and T2 is compared to identify the shorter one. Then, the average usage time U of the store is added to the shorter one to estimate the scheduled end time of use of the store.

[0070] As an example, assume the following situation. · Current time: 1:00 p.m. · The first average waiting time T1 = 60 minutes · The second average waiting time T2 = 20 minutes · The average usage time U of the store where a new queueing request is made = 30 minutes In this case, since T2 < T1, the average usage time U = 30 minutes for the store where a new queueing request is made is identified by referring to the average usage time data 1429 in the store table 142. Then, by adding this U to T2, the scheduled end time of use of the second store (the store where new queueing registration is desired) is estimated to be 1:00 p.m. + 20 minutes + 30 minutes = 1:50 p.m.

[0071] Next, in step S43-9, it is determined whether the expected end time of use for the new queue request at a store is earlier than the start time of use at other stores where the queue has already been registered. If yes, the process proceeds to step S45, and simultaneous queueing at two stores is permitted. If no, the process proceeds to step S44, and simultaneous queueing is rejected. In the above case, the determination is yes, and the process proceeds to step S45, where determination information indicating that simultaneous queueing registration is permitted is output. In the above situation, it is reasonable to permit simultaneous queueing because after finishing use at the store where the new queue is to be registered, it is possible to use the store where the queue has already been registered.

[0072] As explained above, according to the third embodiment, a decision is made based on average waiting time data and average usage time data to determine whether or not to allow simultaneous waiting in line at multiple stores. By allowing such simultaneous waiting in line, user convenience can be enhanced, and the efficiency of attracting customers at each store can be improved.

[0073] [Fourth Embodiment] Next, a queue management system according to a fourth embodiment will be described. The hardware configuration of the system in this fourth embodiment may be substantially the same as that of the previously described embodiment. However, the queue management system in this fourth embodiment is configured to allow simultaneous waiting in line at multiple stores under predetermined conditions, and when it is the user's turn to enter one store, it determines the availability of other stores and, depending on the result, recommends to the user to cancel their waiting in line at those other stores.

[0074] The operation of the system in the fourth embodiment will be explained with reference to the flowchart in Figure 21. Figure 21 illustrates the process that the queue management server 10 executes when it is the user's turn to enter one of the stores (e.g., store A) after allowing a single user to wait in line at multiple stores (e.g., stores A and B) simultaneously, under conditions such as those described in the previous embodiment, or under other conditions.

[0075] After a user is allowed to wait in line for both stores A and B simultaneously, if, for example, their turn comes for store A, the user terminal 50 receives information from the management terminal 20 for store A indicating that the user ID and the "call" operation have been received. (Step S51) Next, the queue management server 10 issues a command to its communication control unit 111 to send a call message to the user terminal 50 informing the user that their turn for store A has come and urging them to come to store A. The communication control unit 111 identifies the user's email address as the recipient of the call message from the queue management table 143, adds store name and time information to the message, and sends it (Step S52).

[0076] Next, the determination unit 113 refers to the store table 142 to identify information about store B, where the user is waiting in line. Then, the determination unit 113 determines whether the likelihood of the user using store B is low or low, based on the identified information (for example, the genre of store B, the estimated waiting time until entry, the distance from store A, etc.) (step S53). Here, whether the likelihood is low or low can be determined based on the identified information and other external information. In this embodiment, the likelihood of using store B is determined based on whether the estimated waiting time is less than or equal to a predetermined time (for example, 5 minutes). Alternatively, the likelihood of using store B may be determined to be low if the estimated waiting time until entry is shorter than the estimated travel time based on the distance from store A, or if store B is of the same genre as store A, which the user has entered.

[0077] If the determination in step S53 is Yes, the communication control unit 111 sends a call message to the user terminal 50, including a message recommending that the user cancel their waiting list for store B, prompting the user to cancel their waiting list for store B (step S54). Although not shown in the diagram, the call message screen includes text such as "Do you want to cancel your current waiting list for store B?" along with a button to cancel the waiting list for store B. By pressing the cancel button, the user can cancel their waiting list for store B. On the other hand, if the determination in step S53 is No, the communication control unit 111 terminates the process without notifying the user of the message recommending the cancellation of store B.

[0078] As explained above, according to the fourth embodiment, after simultaneous waiting in line at multiple stores is permitted, when it is the customer's turn at one store, cancellation of waiting lists at other stores is recommended under predetermined conditions. This increases user convenience, and at each store, the number of people waiting in line is reduced by canceling waiting lists of users who will not be visiting, which can attract other customers and improve customer acquisition efficiency.

[0079] [others] In the above embodiment, the case where the queue management server 10 determines whether or not to accept simultaneous queue registrations was explained as an example, but for example, the user terminal 50 may make the determination. For example, when a queue registration is performed by an application on the user terminal 50, information about stores where queue registrations have been made in the past (genre, average waiting time, registration time, queue number, etc.) is stored. When the user terminal 50 specifies a store where it will register for the queue next, it may query the queue management server 10 for information about the specified store, determine whether or not to accept the queue registration for the specified store, and only send information about the store to be queued (the newly specified store) to the queue management server 10 if it decides to accept the queue registration for the specified store. In this case, the user terminal 50 functions as an information processing device that determines whether or not to accept multiple queue registrations. Furthermore, in this case, the user terminal 50 can also control the system so that facilities that do not meet the conditions cannot be designated for queue registration based on the simultaneous registration acceptance conditions set for facilities where queue registrations have already been made. Furthermore, in the above embodiment, priority is given to the store where the user first registered their place in line, and then it is determined whether the next store the user attempts to register their place in line can accept the registration. However, if simultaneous registration is not possible, the user terminal 50 may be shown text indicating that simultaneous registration is not possible, along with prompting the user to choose either the store they have already registered with or the store they wish to register with. The above-described embodiment explained a system that accepts registrations from users (customers) who wish to use a store where seats and tables are provided and food and drinks are served. However, this system can also be applied to waiting lists in facilities other than restaurants. For example, the technology disclosed can be applied to waiting lists for entry to event venues, or waiting lists for customer service at cosmetic counters or bank tellers.

[0080] The queue management system described above only accepts queue registrations from user terminals. However, in addition to registrations from user terminals, queue registrations may also be accepted at reception terminals installed at the storefront. The basic queue registration procedure is the same even when a user comes to the storefront of their desired store and operates the reception terminal. The queue management server 10 manages queues accepted from the reception terminal in the same way as queues accepted from user terminals 50. In this case, similar to registrations from user terminals, if a user is also waiting in line at another store using the same user information (telephone number in the above example), the server may decide whether to accept the registration based on the facility information, or it may be possible to accept queue registrations from the reception terminal by default.

[0081] As described above, the technology of this disclosure can be implemented by supplying a program that implements one or more of the functions of the embodiments described above to a system or device via a network or storage medium, and by a process in which one or more processors in the computer of that system or device read and operate the program. Alternatively, it may be implemented by a circuit that implements one or more functions.

[0082] This disclosure is not limited to the embodiments described above and includes various modifications. For example, the embodiments described above are described in detail for illustrative purposes and do not necessarily have to include all the configurations described. Furthermore, parts of one embodiment can be replaced with the configurations of another embodiment. In addition, configurations of other embodiments can be added to the configuration of one embodiment. Furthermore, parts of the configuration of each embodiment can be added, deleted, or replaced with parts of the configurations of other embodiments. [Explanation of symbols]

[0083] 1…Queue management system 10…Queue management server 20... Management terminal 50...User terminal 60…Network

Claims

1. A reception unit that receives requests from users to wait in line for the facility and generates reception request information, The management department manages the waiting list information, which is already registered waiting list information. A determination unit that determines whether or not to accept registration of a queue related to the reception request information based on the queue information managed by the management unit and the reception request information, The system includes an output unit that outputs the determination result from the determination unit, The aforementioned waiting list information includes at least information indicating the type of facility currently on the waiting list. The information processing device is characterized in that the determination unit does not accept registration of a facility in the waiting list if the genre of a facility that is already waiting in line is the same as the genre of the facility in the reception request information.

2. The aforementioned waiting list information includes at least information indicating the location of the facility where the person is waiting in line. The information processing apparatus according to claim 1, wherein the determination unit determines, based on the position, whether or not to accept registration of a waiting list for the facility relating to the reception request information.

3. The aforementioned management department manages facility information relating to the aforementioned facility, The facility information includes information regarding the conditions for simultaneous waiting in line for multiple facilities permitted by the facility. The information processing apparatus according to claim 1, wherein the determination unit determines whether or not to accept registration of a waiting list for the facility relating to the reception request information based on the conditions.

4. The aforementioned management department manages facility information relating to the aforementioned facility, The facility information includes information regarding the average waiting time at the facility. The information processing apparatus according to claim 1, wherein the determination unit determines whether or not to accept registration of a waiting list for the facility relating to the reception request information based on the average waiting time.

5. The determination unit further determines whether to recommend that the user cancel their reservation at another facility where they are waiting in line, when the user's turn arrives at the facility where the user is waiting in line. The information processing apparatus according to any one of claims 1 to 4.

6. The reception unit receives requests for waiting in line for the facility and user information in response to the operation. The aforementioned information processing device further, An acquisition unit obtains a determination result indicating whether or not to accept a waiting list request for the determined facility, based on the facility information received by the reception unit and the user information. A display control unit that controls the display according to the determination result, It has, If the determination result indicates that the facility does not accept queues, the display control unit shall display a message indicating that the facility does not accept queues. The information processing apparatus according to claim 1, characterized in that it is a product of the present invention.

7. The process involves receiving a user's request to join the waiting list for a facility and generating a request information, and managing the waiting list information, which is already registered waiting list information. A step of determining whether or not to accept the registration of the queue related to the acceptance request information, based on the queue information and the acceptance request information, The system is configured to cause a computer to perform the steps of outputting the result of the aforementioned determination, The aforementioned waiting list information includes at least information indicating the type of facility currently on the waiting list. In the step of making the determination, the computer is a program that does not accept registration for the facility related to the reception request information if the genre of the facility that is already waiting in line is the same as the genre of the facility related to the reception request information.

8. An information processing method that causes a computer to perform a process to make a determination based on waiting list information, which is already registered waiting list information, wherein the computer, The steps include: receiving a request from a user to join the waiting list for a facility and generating a request for acceptance information; and determining whether or not to accept the registration of the waiting list related to the request for acceptance information based on the waiting list information and the request for acceptance information. The step of outputting the result of the above determination is performed, The aforementioned waiting list information includes at least information indicating the type of facility currently on the waiting list. An information processing method in which, in the step of making the determination, the computer does not accept registration of the waiting list for the facility related to the reception request information if the genre of the facility that is already waiting in line is the same as the genre of the facility related to the reception request information.

Images