TOUR PLAN GENERATION DEVICE, TOUR PLAN GENERATION METHOD, AND PROGRAM

Abstract

To create flexible tour plans which fulfill client requests.SOLUTION: A tour plan creation device (100B) includes: an input unit (150) which receives input regarding tour-related requests and conditions for a package tour; a specification unit (151) which creates specified tour-related requests which fulfill specified conditions, as tour plans, through adding more details to the inputted tour-related requests and conditions; and an output unit (152) which outputs the created tour plans.SELECTED DRAWING: Figure 23

Description

[Technical field]

[0001] The present disclosure relates to a tour plan creation device, a tour plan creation method, and a program for creating a tour plan for a package tour. [Background technology]

[0002] Traditionally, travel agency staff would create package tour plans by asking customers about the various procedures required for the trip (arrangements for transportation, accommodation, sightseeing, events, etc.). This meant that they were unable to quickly propose tour plans to customers.

[0003] For this reason, technology has recently been proposed for automatically generating tour plans for package tours (for example, Patent Document 1). The technology disclosed in Patent Document 1 includes an accommodation facility database, a facility (dining, drinking, sightseeing) database, etc., as well as a travel model template database in which travel model template data that serves as a template for travel plans is registered. When generating a travel plan, the travel model template data is extracted from the travel model template database, and the travel plan is generated while extracting accommodation facilities that satisfy the travel conditions from the accommodation facility database, etc. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2003-044553 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, the technology disclosed in Patent Document 1 generates travel plans using travel model template data, so it has the problem that it can only generate travel plans that follow the template and cannot generate flexible travel plans that meet customer requests.

[0006] Therefore, an object of the present disclosure is to provide a tour plan creation device, a tour plan creation method, and a program that can solve the above-mentioned problems and create flexible tour plans that meet customer requests. [Means for solving the problem]

[0007] A tour plan generating device according to one aspect includes: an input unit for receiving input of tour requests and conditions for the package tour; a concretization unit that concretizes the input tour request and the conditions, thereby generating the concretized tour request that satisfies the concretized conditions as a tour plan; and an output unit that outputs the generated tour plan.

[0008] A method for generating a tour plan according to one aspect includes the steps of: A tour plan generation method performed by a tour plan generation device, comprising: A step of accepting input of tour requests and conditions for a package tour; generating a tour plan based on the input tour request and the conditions, the tour request satisfying the specified conditions; and outputting the generated tour plan.

[0009] A program according to one aspect comprises: On the computer, A procedure for accepting input of tour requests and conditions for package tours; generating a tour plan based on the input tour request and the conditions, the tour request being the embodied tour request that satisfies the embodied conditions; outputting the generated tour plan; Execute the command. Effect of the Invention

[0010] According to the above-described aspects, it is possible to provide a tour plan creation device, a tour plan creation method, and a program that can create a flexible tour plan that meets customer requests. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a tour plan generating device according to a first embodiment. [Diagram 2] FIG. 2 is a diagram conceptually illustrating a data structure of a tour item. [Diagram 3] FIG. 2 is a diagram conceptually illustrating a data structure of a tour request. [Figure 4] 4 is a diagram conceptually illustrating an example of a data structure of conditions linked to the tour request shown in FIG. 3. [Diagram 5] FIG. 2 is a diagram conceptually illustrating a data structure of an instantiation pattern according to the first specific example. [Figure 6] FIG. 13 is a diagram conceptually illustrating the data structures of the left and right sides of an instantiation pattern according to a second specific example. [Figure 7] FIG. 11 is a diagram conceptually illustrating a data structure of a template of an embodiment pattern according to a second specific example. [Figure 8] 8 is a diagram conceptually illustrating a data structure of a tour request after the tour request shown in FIG. 3 is concretized based on the concretization pattern according to specific example 2 shown in FIGS. 6 and 7. FIG. [Figure 9] 8 is a diagram conceptually illustrating a data structure of a condition after the condition shown in FIG. 4 is instantiated based on an instantiation pattern according to specific example 2 shown in FIGS. 6 and 7. FIG. [Figure 10] FIG. 13 is a diagram conceptually illustrating the data structures of the left and right sides of an instantiation pattern according to a third specific example. [Figure 11] FIG. 4 is a diagram illustrating an example of the operation of a tour item registration database according to the first embodiment. [Figure 12]FIG. 4 is a diagram (1 / 3) conceptually illustrating an example of a data structure of a tour plan generated by concretizing the tour request shown in FIG. 3. [Figure 13] FIG. 4 is a diagram (2 / 3) conceptually illustrating an example of a data structure of a tour plan generated by concretizing the tour request shown in FIG. 3. [Figure 14] FIG. 4 is a diagram (3 / 3) conceptually illustrating an example of a data structure of a tour plan generated by concretizing the tour request shown in FIG. 3. [Figure 15] 4A to 4C are diagrams showing examples of an input screen and an output screen displayed on a display of a terminal in accordance with the first embodiment. [Figure 16] 5 is a flowchart illustrating an example of the flow of operations of the tour plan creation device according to the first embodiment. [Figure 17] FIG. 11 is a diagram illustrating an example of the configuration of a tour plan generating device according to a second embodiment. [Figure 18] FIG. 13 is a diagram showing an example of a current tour plan that is a target of a change process and a current tour request that is the basis of the current tour plan. [Figure 19] FIG. 13 is a diagram showing an example of a current tour plan and a modified tour request that is modified based on an unsuccessful tour item in the current tour plan. [Figure 20] FIG. 13 is a diagram showing an example of a changed tour request and a changed tour plan generated based on the changed tour request. [Figure 21] FIG. 13 is a diagram showing an example of a current tour request and a changed tour plan that has been regenerated based on the current tour request. [Figure 22] 13A and 13B are diagrams showing examples of an input screen and an output screen displayed on a display of a terminal according to the second embodiment. [Figure 23] FIG. 11 is a diagram illustrating an example of the configuration of a tour plan generating device according to a third embodiment. [Figure 24] FIG. 13 is a diagram illustrating an example of a hardware configuration of a tour plan creation device according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. Note that the following description and drawings are omitted and simplified as appropriate for clarity of explanation. In addition, in each of the following drawings, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary.

[0013] <Embodiment 1> First, a configuration example of the tour plan generating device 100 according to the first embodiment will be described. FIG. 1 is a diagram showing a configuration example of the tour plan generating device 100 according to the first embodiment. As shown in FIG. 1, the tour plan generating device 100 according to the first embodiment includes a tour request input unit 101, a tour request concretization unit 102, a concretization pattern registration database 103, a tour item registration database 104, a condition verification unit 105, and a tour plan output unit 106. The terminal 200 shown in FIG. 1 is a terminal used by a customer, and may include at least an input function, a communication function, and a display function. The terminal 200 shown in FIG. 1 is a portable terminal that can be carried by a customer, but may also be a stationary terminal.

[0014] The tour request input unit 101 accepts input of tour requests and conditions for a package tour desired by a customer from the terminal 200. The tour request includes one or more tour items.

[0015] FIG. 2 is a diagram conceptually illustrating the data structure of a tour item. However, FIG. 2 can also be regarded as a diagram illustrating a UI displayed on the terminal 200 (the same applies to FIGS. 3 to 10 and 12 to 14 described below). Here, the UI is a user interface. FIG. 2 shows, as an example, a tour item I1 related to "departure" and a tour item I2 related to "movement". The tour item I1 related to "departure" is given a label L11 related to "later plan", and the tour item I2 related to "movement" is given a label L21 related to "later plan", a label L22 related to "later plan", and a label L23 related to "transport". Among these, the label L11 of the right-angled rectangle is a request related to the tour item I1, and the labels L22 and L23 of the right-angled rectangle are requests related to the tour item I2. In addition, these right-angled rectangle labels L11, L22, and L23 are required to be linked to the label of a rounded rectangle of another tour item. For example, the label L11 of the rectangular rectangle related to the "follow-up plan" of the tour item I1 related to "departure" can be linked to the label L21 of the rounded rectangle related to the "follow-up plan" of the tour item I2 related to "travel".

[0016] Fig. 3 is a diagram conceptually illustrating the data structure of a tour request, and Fig. 4 is a diagram conceptually illustrating the data structure of conditions. For convenience, Fig. 3 and Fig. 4 are shown as separate drawings, but the tour request shown in Fig. 3 and the conditions shown in Fig. 4 are linked and are input as a pair from terminal 200. In Fig. 3 and Fig. 4, a double rectangular frame indicates that the tour request and conditions are illustrated within the frame (the same applies to Figs. 8 and 9 described below).

[0017] The tour request shown in FIG. 3 is an example of a case in which a customer generally desires the following: Depart from starting point S at 9am on August 3rd. Stay at accommodation A. Visit tourist attractions α and β. Arrive at arrival point G at 7pm on August 4th.

[0018] Therefore, the tour request shown in Figure 3 includes tour item I3 related to "departure", tour item I4 related to "accommodation", tour item I5 related to "arrival", tour item I6 related to "accommodation A", tour item I7 related to "tourist attraction α", and tour item I8 related to "tourist attraction β".

[0019] The conditions shown in FIG. 4 are roughly as follows: -Budget: 75,000 yen. -Number of participants: 3 -Total expenditures are below budget. The expenditure items have not yet been finalized at this time.

[0020] The tour request shown in Figure 3 has many uncertainties, such as the means of transportation and time schedule. Similarly, the conditions shown in Figure 4 also have many uncertainties, such as the expense items.

[0021] Therefore, the tour request instantiation unit 102 instantiates the undetermined parts of the tour request and conditions by automatic generation processing in the instantiation process. Specifically, the tour request concretization unit 102 concretizes the undetermined parts of the tour request and conditions based on a concretization pattern, which is a pattern for concretizing the tour request and conditions, registered in the concretization pattern registration database 103.

[0022] Here, the concretization pattern will be described. Fig. 5 is a diagram conceptually illustrating a data structure of a concretization pattern 111 according to concrete example 1. As shown in Fig. 5, the concretization pattern 111 includes information indicating a subject of concretization (hereinafter referred to as the left side of the concretization pattern) 112, information indicating a configuration after concretization (hereinafter referred to as the right side of the concretization pattern) 113, and a template 114 for generating a condition to be added by concretization.

[0023] When a structure corresponding to the left side 112 of the concretization pattern is included in the tour request, the tour request concretization unit 102 rewrites the structure into a structure corresponding to the right side 113 of the concretization pattern. After this rewriting, the tour request concretization unit 102 adds the condition generated by the template 114 to the conditions associated with the tour request.

[0024] In the instantiation pattern 111 according to the first concrete example shown in FIG. 5, the data structures before and after the rewriting are as follows. Data structure before rewrite: A tour item I9 relating to "Plan 1" and a tour item I10 relating to "Plan 2" are arranged independently. Rewritten data structure: A label L91 relating to the "subsequent plan" of the tour item I9 relating to the "plan 1" is linked to a label L101 relating to the "subsequent plan" of the tour item I10 relating to the "plan 2".

[0025] FIG. 6 is a diagram conceptually illustrating the data structures of the left side 122 and the right side 123 of the instantiation pattern 121 according to specific example 2, and FIG. 7 is a diagram conceptually illustrating the data structure of the template 124 of the instantiation pattern 121 according to specific example 2.

[0026] In the instantiation pattern 121 according to the specific example 2 shown in FIG. 6 and FIG. 7, the data structures before and after the rewriting are as follows. Data structure before rewrite: Tour item I11 relating to "accommodation" is located here. Rewritten data structure: A tour item I12 related to "check-in", a tour item I13 related to "check-out", and a tour item I14 related to "accommodation" are added. Note that if the tour item I14 related to "accommodation" is already included in the tour request, that tour item can be used and there is no need to add it anew. Furthermore, the label L111 related to "accommodation" of the tour item I11 related to "accommodation" is linked to the label L143 related to "accommodation" of the tour item I14 related to "accommodation". Also, the label L141 related to "check-in" of the tour item I14 related to "accommodation" is linked to the label L121 related to "check-in" of the tour item I12 related to "check-in". Also, the label L142 related to "check-out" of the tour item I14 related to "accommodation" is linked to the label L131 related to "check-out" of the tour item I13 related to "check-out".

[0027] 8 and 9 are diagrams each conceptually illustrating an example of data structures of a tour request and a condition after the tour request and the condition shown in FIG. 3 and FIG. 4 are concretized based on the concretization pattern 121 according to the concrete example 2 shown in FIG. 6 and FIG. 7. In the tour request shown in FIG. 8, the left side 122 of the concretization pattern is rewritten to the right side 123. Specifically, a tour item I16 related to "check-in" and a tour item I17 related to "check-out" are added. In addition, a label L61 related to "check-in" of the tour item I6 related to "accommodation" is linked to a label L161 related to "check-in" of the tour item I16 related to "check-in". In addition, a label L62 related to "check-out" of the tour item I6 related to "accommodation" is linked to a label L171 related to "check-out" of the tour item I17 related to "check-out". In addition, a condition generated by the template 124 is added to the condition shown in FIG. 9.

[0028] 10 is a diagram conceptually illustrating the data structures of the left side 132 and the right side 133 of the instantiation pattern 131 according to specific example 3. Note that the data structure of the template of the instantiation pattern 131 is omitted from the illustration. In the instantiation pattern 131 according to the concrete example 3 shown in FIG. 10, the data structures before and after the rewriting are as follows. Data structure before rewrite: Tour item I15 relating to "accommodation" is placed. At this point, "accommodation" has not been specified, but conditions such as budget and area have been specified. Rewritten data structure: The "accommodation" in tour item I15 is embodied in the accommodation that is found by searching the tour item registration database 104 for accommodation that satisfies the conditions.

[0029] Therefore, when using the concrete example 131 according to the concrete example 3, the tour request concrete example unit 102 provides a query including search conditions for accommodation facilities such as budget and area to the tour item registration database 104, and receives a response including accommodation facilities that satisfy the search conditions from the tour item registration database 104. The tour item registration database 104 will be described in detail later.

[0030] The tour request concretization unit 102 repeatedly concretizes the uncertain parts of the tour request and conditions based on the concretization pattern described above, thereby concretizing the tour request and conditions into a configuration that does not include any uncertain parts.

[0031] When the tour item registration database 104 receives a query from the tour request embodiment unit 102, it searches for tour items that satisfy the search conditions included in the query, and returns a response including all or some of the tour items found to the tour request embodiment unit 102.

[0032] FIG. 11 is a diagram for explaining an example of the operation of the tour item registration database 104. FIG. 11 shows an example of the operation when searching for accommodations. In the example of FIG. 11, the tour item registration database 104 receives a query including search conditions for accommodations such as budget and schedule, and returns a response including accommodations A, B, and C found by the search. At this time, the tour item registration database 104 may hold a static database and acquire data from the static database, or may acquire data from a dynamic resource. The dynamic resource may be an external service or an external dynamically changing database. For example, when acquiring data on accommodations, the external service may be an accommodation booking service, a private lodging search service, or the like.

[0033] The tour request input unit 101 may also use the tour item registration database 104 to support input by the customer. For example, when a customer inputs a budget, schedule, etc. as tour requests and conditions, the tour request input unit 101 provides a query including these as search conditions to the tour item registration database 104. As a result, the tour request input unit 101 can obtain data on accommodations that satisfy the search conditions as a response to the query, and can present the accommodations to the customer.

[0034] When the tour request specification unit 102 specifies the tour request and conditions into a configuration that does not include any undetermined parts, it provides the specified tour request and conditions to the condition verification unit 105 and requests verification as to whether or not the specified tour request satisfies the specified conditions.

[0035] When the condition verification unit 105 receives the specified tour request and conditions from the tour request specification unit 102, it verifies whether the specified tour request satisfies the specified conditions and returns the verification result to the tour request specification unit 102.

[0036] If the specified tour request satisfies the specified conditions, the specified tour request is finalized as a tour plan to be proposed to the customer. Figures 12 to 14 are diagrams conceptually illustrating data structures of tour plans generated by specifying the tour request shown in Figure 3. Note that Figures 12 to 14 show one tour plan divided into three parts and represented in three drawings, and the tour item I18 shown in the bottom row of Figure 12 and the tour item I18 shown in the top row of Figure 13 indicate the same tour item, and the tour item I19 shown in the bottom row of Figure 13 and the tour item I19 shown in the top row of Figure 14 indicate the same tour item.

[0037] The tour plans shown in FIGS. 12 to 14 do not include any undetermined parts and satisfy the specified conditions, and generally include the following tour contents. Depart from location S Travel by train Visit tourist attraction β Travel by bus Stay overnight at accommodation A Travel by bus Visit tourist attraction α Travel by train Arrived at location G

[0038] The tour plan output unit 106 outputs all or a part of the tour plan to the terminal 200 for proposing to the customer.

[0039] FIG. 15 is a diagram showing an example of an input screen 210 and an output screen 220 displayed on the display of the terminal 200 according to the first embodiment. The input screen 210 is a screen that the tour request input unit 101 displays on the display of the terminal 200 when the customer inputs the tour request and conditions. The input screen 210 includes an area 211 and a button 212. The area 211 is an area for the customer to input the tour request and conditions. In detail, elements constituting the tour request and conditions are input as text data in the area 211, and the tour request input unit 101 generates the tour request and conditions as shown in FIG. 3 and FIG. 4 based on the input elements. At this time, the customer is not limited to inputting specific names such as famous places and events, and can also input loose specifications such as "romantic places" and "facility that can be visited with a budget of ~ or less." In other words, loose specifications can be considered as specifications that include room for specificity and specifications that include ambiguity. When a loose specification is input for a famous place or an event, a query including the specification can be given to the tour item registration database 104, and a specific famous place or event can be obtained as a response to the query. In this case, the query may be provided by the tour request input unit 101 when the tour request and conditions are input, or may be provided by the tour request instantiation unit 102 when the tour request and conditions are instantiated.

[0040] When button 212 is operated, the tour request concretization unit 102 acquires from the tour request input unit 101 the tour request and conditions generated based on the elements entered in area 211, and initiates an automatic generation process by a concretization process that concretizes the acquired tour request and conditions.

[0041] The output screen 220 is a screen that the tour plan output unit 106 displays on the display of the terminal 200 after the button 212 is operated. The output screen 220 includes an area 221 and a button 222. The area 221 is an area for displaying a list of tour plans generated by the tour request embodiment unit 102. When one of the tour plans displayed in the area 221 is selected, the tour plan output unit 106 displays another output screen describing the details of the selected tour plan on the display of the terminal 200. The output screen displayed here is, for example, a screen expressed in the data structure of the tour plan as illustrated in FIGS. 12 to 14, but is not limited thereto.

[0042] When the button 222 is operated, the tour request input unit 101 displays the input screen 210 again on the display of the terminal 200. This enables the customer to edit the tour request and conditions again after confirming the details of the tour plan.

[0043] In addition, the customer may be able to order a package tour for the tour plan on the output screen on which the detailed contents of the tour plan are described. In this case, the tour plan output unit 106 may automatically execute procedures that can be performed automatically among the procedures required to carry out the ordered tour plan. Procedures that can be performed automatically include, for example, reservations for accommodations and transportation.

[0044] Next, a description will be given of the flow of operations of the tour plan creation device 100 according to the embodiment 1. Fig. 16 is a flowchart illustrating an example of the flow of operations of the tour plan creation device 100 according to the embodiment 1.

[0045] 16, first, the tour request input unit 101 accepts input of tour requests and conditions for a package tour (step S100). The input tour requests and conditions are linked to each other. Hereinafter, the tour request is represented by the symbol D, and the conditions are represented by the symbol QC. In particular, the tour request input first is represented by the symbol D0, and the conditions input first are represented by the symbol QC0.

[0046] Next, the tour request instantiation unit 102 determines the pair of the tour request D0 and the condition QC0 input to the tour request input unit 101 as the root of a search tree (step S101). This search tree has pairs of the tour request and the condition as nodes. A pair of the tour request and the condition may be written as a pair (D, QC), etc.

[0047] Next, the tour request concretization unit 102 judges whether or not the condition that "the concretizable pair (D, QC) remains and a sufficient number of tour plans have not been obtained" is satisfied (step S102). Here, the concretizable pair (D, QC) is a pair of a concretizable tour request D and a condition QC associated with the tour request D. The above "sufficient number" is determined in advance.

[0048] In step S102, if the above condition is satisfied (YES in step S102), the tour request instantiation unit 102 selects one concretizable pair (D, QC) and instantiates the pair (D, QC) based on the concretization pattern to obtain a pair (D', QC') (step S103). In step S103, the tour request instantiation unit 102 generates a tour request D' and a condition QC' by respectively concretizing the tour request D and the condition QC based on the concretization pattern.

[0049] Here, when selecting one concretizable pair (D, QC) in step S103, the tour request concretization unit 102 selects a pair (D, QC) from the pairs (D, QC) included in the search tree that satisfies the conditions that "the tour request D is not completely concretized" and "there is a concretization pattern that is applicable to the concretization target in the tour request D and has not yet been applied." At this time, for example, if there are two concretization targets in the tour request D to which a concretization pattern can be applied and the concretization pattern has been applied to only one of the concretization targets, the concretization pattern is treated as a concretization pattern that has not yet been applied to the concretization target in the tour request D.

[0050] Next, the tour request concrete unit 102 provides the tour request D' and the condition QC' to the condition verification unit 105, and requests the condition verification unit 105 to verify whether or not the tour request D' satisfies the condition QC'. In response to the request from the tour request concrete unit 102, the condition verification unit 105 verifies whether or not the tour request D' satisfies the condition QC', and returns the verification result to the tour request concrete unit 102. The tour request concrete unit 102 determines whether or not the condition QC' is satisfiable based on the verification result (step S104).

[0051] In step S104, if the condition QC' is satisfiable (YES in step S104), the tour request instantiation unit 102 adds the pair (D', QC') to the search tree as a child node of the pair (D, QC) selected in step S103 (step S105). The tour request D' in the pair (D', QC') added to the search tree becomes one of the tour plans proposed to the customer. After step S105, the tour request instantiation unit 102 returns to step S102 and repeats the processes from step S102 onwards.

[0052] Furthermore, in step S104, if the condition QC' is not satisfiable (NO in step S104), the tour request embodiment unit 102 skips step S105 and moves to step S102, and repeats the processes in and after step S102.

[0053] Also, in step S102, if the condition that "there remains a concretizable pair (D, QC) and a sufficient number of tour plans have not been obtained" is not satisfied (NO in step S102), the tour plan output unit 106 outputs the tour plans obtained up to that point (step S106) and ends the process. Note that in step S106, the tour plan output unit 106 may output all the tour plans obtained, or may output a predetermined number of the tour plans obtained (for example, one).

[0054] As described above, according to the first embodiment, the tour request input unit 101 accepts input of a tour request and conditions for a package tour. The tour request instantiation unit 102 instantiates the input tour request and conditions, thereby generating the instantiated tour request that satisfies the instantiated conditions as a tour plan. The tour plan output unit 106 outputs the generated tour plan.

[0055] Therefore, compared to the technique of generating a tour plan using trip model template data as in Patent Document 1, it becomes possible to generate a flexible tour plan that meets customer requests.

[0056] <Embodiment 2> In the above-described first embodiment, a tour plan is generated based on tour requests and conditions of a package tour. However, during the tour according to the tour plan, an accident such as a deterioration in weather or a delay in transportation may occur, which may make it impossible to carry out the tour items included in the tour plan, and as a result, it may be necessary to make changes to the tour plan. In the second embodiment, when a tour item cannot be carried out due to an accident or the like, a tour plan is regenerated.

[0057] First, a configuration example of a tour plan creation device 100A according to the present embodiment 2 will be described. Fig. 17 is a diagram showing a configuration example of the tour plan creation device 100A according to the present embodiment 2. As shown in Fig. 17, the tour plan creation device 100A according to the present embodiment 2 additionally includes an attempted tour item calculation unit 107, compared to the tour plan creation device 100 according to the above-mentioned embodiment 1.

[0058] An example of a change process for changing a tour plan in the tour plan generating device 100A according to the second embodiment will be described below. Here, a customer inputs a tour request A and conditions, and the tour plan P is generated from the tour plan generating device 100A. A is proposed, and Tour Plan P A During the progress of Tour Plan P A The following description will be given of a change process that is initiated to change the

[0059] Step S201: First, the unsuccessful tour item calculation unit 107 receives the ongoing tour plan P from the terminal 200. A and Tour Plan P A The terminal 200 may input (notify) all completed tour items at once when the change process is started, or may notify the progress of the tour plan P. A Each time a tour item is performed, the tour item may be input (notified) in accordance with the progress of the tour.

[0060] Step S202: Next, the attempted tour item calculation unit 107 calculates the tour plan P A Based on the progress of the tour plan P A Among the tour items included in the tour list, the tour items that have not yet been performed yet are calculated, and the calculated tour items are output (presented) to the terminal 200.

[0061] Step S203: Next, the tour request input unit 101 accepts input of a changed tour request A' and conditions, which have been changed based on the attempted tour item, from the terminal 200 as necessary. The customer can freely decide whether or not to change the tour request A. When changing the tour request A, the customer can also freely decide whether or not to change the conditions as well. Here, it is assumed that the changed tour request A' is input, along with the current conditions.

[0062] Step S204: Thereafter, the tour request specification unit 102 specifies the tour request A' and the conditions based on the specification pattern. If the specified tour request A' satisfies the specified conditions, the specified tour request A' is included in the tour plan P. A’ The tour plan output unit 106 outputs the tour plan P A’ is output (presented) to terminal 200.

[0063] Next, the change process in the tour plan creation device 100A according to the second embodiment will be described with a specific example. Fig. 18 is a diagram showing an example of a current tour plan that is a target of a change process and a current tour request that is the basis of the current tour plan. Note that the tour requests and tour plans shown in Fig. 18 are partially excerpted (the same applies to Figs. 19 to 21 described later).

[0064] The current tour requests shown in FIG. 2 days, 1 night Watch the show at Tourist Attraction Alpha every day at 10:00 or 16:00 Participate in the local event beta (13:00-15:00) Visit tourist attractions Visit two local tourist attractions (other than α and γ)

[0065] The current tour plan shown in FIG. 18 is a tour plan generated by specifying the current tour requests shown in FIG. 18, and is as follows. Visit the tourist attraction γ Go to tourist spot α and watch the show that starts at 16:00 Overnight stay at accommodation Visit the tourist attraction δ Participate in the event β (13:00-15:00) Go to tourist attraction ε

[0066] Assume that during the tour of the tour plan shown in FIG. 18, the customer's train is delayed due to an accident, and the customer is unable to carry out the tour item "Visit tourist attraction α and watch a show starting at 16:00". In this case, the customer launches the change process and inputs the progress of the tour plan shown in Figure 18, and the unsuccessful tour item calculation unit 107 calculates the unsuccessful tour items among the tour items included in the tour plan shown in Figure 18 based on the input progress.

[0067] Fig. 19 is a diagram showing an example of a current tour plan and a tour request after modification based on an unsuccessful tour item in the current tour plan. Note that the unsuccessful tour items among the tour items shown in Fig. 19 are underlined.

[0068] The tour plan shown in Fig. 19 is the same as the tour plan shown in Fig. 18. Among the tour items included in the tour plan shown in Fig. 19, the unsuccessful tour items were scheduled to be performed after 16:00, and are as follows: Go to tourist spot α and watch the show that starts at 16:00 Overnight stay at accommodation Visit the tourist attraction δ Participate in the event β (13:00-15:00) Go to tourist attraction ε

[0069] The unsuccessful tour item calculation unit 107 calculates the unsuccessful tour items described above, and outputs (presents) the calculated tour items to the terminal 200. Based on the presented attempted tour items, the customer inputs a revised tour request as shown in Fig. 19. In the example of Fig. 19, the customer changes "visiting two local tourist attractions (other than α and γ)" to "visiting one local tourist attraction (other than α and γ)."

[0070] Fig. 20 is a diagram showing an example of a changed tour request and a changed tour plan regenerated based on the changed tour request. In the changed tour request and the changed tour plan shown in Fig. 20, the changes from the current tour request (Fig. 19) and the current tour plan (Fig. 19) are underlined.

[0071] The modified tour request shown in FIG. 20 is the same as the modified tour request shown in FIG. The tour request instantiation unit 102 instantiates the changed tour request shown in Fig. 20 together with the conditions based on the instantiation pattern. If there are no changes to the conditions, the current conditions are used, and if there are changes to the conditions, the changed conditions are used.

[0072] The modified tour plan shown in FIG. 20 is a tour plan that has been regenerated by embodying the modified tour request shown in FIG. In the modified tour plan shown in FIG. 20, the changes from the current tour plan (FIG. 19) are as follows: "Visit tourist attraction α and watch the show starting at 16:00" changed to the next day · Deleted "Go to tourist attraction ε"

[0073] In the examples shown in Figures 18 to 20, the customer inputs the changed tour request and the changed tour plan is regenerated based on the changed tour request, but changing the tour request is not essential. The changed tour plan may be regenerated based on the current plan request.

[0074] Fig. 21 is a diagram showing an example of a current tour request and a changed tour plan regenerated based on the current tour request. In the changed tour plan shown in Fig. 21, the changes from the current tour plan (Fig. 19) are underlined.

[0075] The tour request shown in FIG. 21 is the same as the current tour request shown in FIG. The tour request instantiation unit 102 instantiates the current tour requests shown in FIG. 21 together with the conditions based on the instantiation pattern, thereby regenerating a changed tour plan.

[0076] In the modified tour plan shown in FIG. 21, the changes from the current tour plan (FIG. 19) are as follows: "Visit tourist attraction α and watch the show starting at 16:00" changed to the next day -Added "Visit tourist attractions μ" · Deleted "Go to tourist attraction ε"

[0077] FIG. 22 is a diagram showing an example of an input screen 230 and an output screen 240 displayed on the display of the terminal 200 according to the second embodiment. The input screen 230 is a screen that the tour request input unit 101 displays on the display of the terminal 200 when the customer inputs the changed tour request and conditions after presenting the attempted tour item to the terminal 200. The input screen 230 includes an area 231 and a button 232. The area 231 is an area for the customer to input the changed tour request and conditions. In detail, in the area 231, elements constituting the changed tour request and conditions are input as text data, similar to the area 211 shown in FIG. 15 described in the above-mentioned embodiment 1, and the tour request input unit 101 generates the changed tour request and conditions based on the input elements. In addition, in the area 231, it is also possible to input loose specifications regarding famous places, events, etc., similar to the area 211. In addition, the method of obtaining specific famous places and events when loose specifications regarding famous places and events are input is the same as in the above-mentioned embodiment 1.

[0078] When button 232 is operated, the tour request concretization unit 102 acquires from the tour request input unit 101 the modified tour request and conditions generated based on the elements entered in area 231, and initiates an automatic generation process by a concretization process that concretizes the acquired tour request and conditions.

[0079] The output screen 240 is a screen that the tour plan output unit 106 displays on the display of the terminal 200 after the button 232 is operated. The output screen 240 includes an area 241 and a button 242. The area 241 is an area for displaying a list of changed tour plans regenerated by the tour request embodiment unit 102. When any of the tour plans displayed in the area 241 is selected, the tour plan output unit 106 displays another output screen including detailed contents of the selected tour plan on the display of the terminal 200. The output screen displayed here is, for example, a screen expressed in the data structure of the tour plan as illustrated in FIGS. 12 to 14, but is not limited thereto.

[0080] When the button 242 is operated, the tour request input unit 101 displays the input screen 230 again on the display of the terminal 200. This enables the customer to edit the tour request and conditions again after confirming the details of the tour plan.

[0081] In the tour plan creation device 100A according to the second embodiment, the operation flow when a new tour plan is created is similar to that shown in Fig. 16 described in the first embodiment. In addition, the operation flow when a changed tour plan is re-created is also similar to that shown in Fig. 16, except that the current or changed tour requests and conditions are input in step S100 in Fig. 16. Therefore, in the tour plan creation device 100A according to the second embodiment, a description of the flow of operations when creating a new tour plan and when regenerating a changed tour plan will be omitted.

[0082] As described above, according to the second embodiment, the unsuccessful tour item calculation unit 107 calculates the unsuccessful tour items among the tour items included in the tour plan. The tour request input unit 101 accepts input of the changed tour request and conditions that have been changed based on the unsuccessful tour items. The tour request concretization unit 102 concretizes the input changed tour request and conditions, thereby regenerating the concretized changed tour request that satisfies the concretized conditions as a changed tour plan. The tour plan output unit 106 outputs the regenerated tour plan.

[0083] In addition, the tour request concretization unit 102 may concretize the tour request and conditions that have already been input, and re-generate the concretized tour request that satisfies the concretized conditions as a modified tour plan.

[0084] Therefore, if a tour item cannot be carried out due to an accident or the like, the tour plan can be regenerated. The other effects are the same as those of the first embodiment described above.

[0085] <Embodiment 3> Fig. 23 is a diagram showing an example of a configuration of a tour plan creation device 100B according to the present embodiment 3. As shown in Fig. 23, the tour plan creation device 100B according to the present embodiment 3 includes an input unit 150, a concretization unit 151, and an output unit 152.

[0086] The input unit 150 receives input of tour requests and conditions for a package tour from the terminal 200. The input unit 150 corresponds to the tour request input unit 101, for example. The concretization unit 151 concretizes the input tour request and conditions, and generates the concretized tour request that satisfies the concretized conditions as a tour plan. The concretization unit 151 corresponds to, for example, the tour request concretization unit 102. The output unit 152 outputs the generated tour plan to the terminal 200. The output unit 152 corresponds to the tour plan output unit 106, for example.

[0087] Therefore, compared to the technique of generating a tour plan using trip model template data as in Patent Document 1, it becomes possible to generate a flexible tour plan that meets customer requests.

[0088] The tour plan generating device 100B according to the third embodiment may further include a concretization pattern registration unit in which concretization patterns, which are patterns for concretizing tour requests and conditions, are registered in advance. This concretization pattern registration unit corresponds to, for example, the concretization pattern registration database 103. The concretization unit 151 may concretize the input tour requests and conditions based on the concretization pattern.

[0089] The tour plan creating device 100B according to the third embodiment may further include a condition verifying unit that verifies whether or not the specified tour request satisfies the specified conditions. This condition verifying unit corresponds to, for example, the condition verifying unit 105. The concretizing unit 151 may provide the specified tour request and the specified conditions to the above-mentioned condition verifying unit, thereby inquiring of the above-mentioned condition verifying unit whether or not the specified tour request satisfies the specified conditions.

[0090] Additionally, the tour request and the tour plan may include one or more tour items. The tour plan creating device 100B according to the third embodiment may further include a tour item registration unit in which tour items are registered in advance. This tour item registration unit corresponds to, for example, the tour item registration database 104. The concretization pattern may include a pattern of rewriting a tour item included in the tour request to a tour item registered in the tour item registration unit.

[0091] The tour plan generating device 100B according to the third embodiment may further include a calculation unit that calculates uncompleted tour items among tour items included in the tour plan. This calculation unit corresponds to, for example, the uncompleted tour item calculation unit 107. The input unit 150 may receive an input of a changed tour request and conditions that have been changed based on the uncompleted tour items from the terminal 200. The concretization unit 151 may concretize the input changed tour request and conditions, and regenerate the concretized changed tour request that satisfies the concretized conditions as a changed tour plan. The output unit 152 may output the regenerated changed tour plan to the terminal 200.

[0092] The concretization unit 151 may also concretize the already input tour request and conditions, and regenerate the concretized tour request that satisfies the concretized conditions as a changed tour plan. The output unit 152 may also output the regenerated changed tour plan to the terminal 200.

[0093] <Fourth embodiment> Fig. 24 is a block diagram showing an example of a hardware configuration of a tour plan creation device 100C according to the fourth embodiment. As shown in Fig. 24, the tour plan creation device 100C according to the fourth embodiment includes a processor 160 and a memory 161. Note that the terminal 200 is not shown in Fig. 24.

[0094] The processor 160 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 160 may include multiple processors. The memory 161 is configured by a combination of volatile memory and non-volatile memory. The memory 161 may include storage located away from the processor 160. In this case, the processor 160 may access the memory 161 via an I (Input) / O (Output) interface (not shown).

[0095] The tour plan creation devices 100, 100A, 100B according to the above-mentioned first, second, and third embodiments may each have a hardware configuration shown in Fig. 24. The tour request input unit 101, the tour request concretization unit 102, the condition verification unit 105, the tour plan output unit 106, the attempted tour item calculation unit 107, the input unit 150, the concretization unit 151, and the output unit 152 in the above-mentioned tour plan creation devices 100, 100A, and 100B may be realized by the processor 160 reading and executing a program stored in the memory 161. Also, the concretization pattern registration database 103 and the tour item registration database 104 in the above-mentioned tour plan creation devices 100 and 100A may be realized by the memory 161.

[0096] The above-mentioned program can be stored using various types of non-transitory computer readable media and can be supplied to a computer (including the computer 50). The non-transitory computer readable medium includes various types of tangible storage media. Examples of the non-transitory computer readable medium include magnetic recording media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (e.g., magneto-optical disks), compact disc-ROMs (CD-ROMs), CD-recordables (CD-Rs), CD-rewritables (CD-R / Ws), semiconductor memories (e.g., mask ROMs, programmable ROMs (PROMs), erasable PROMs (EPROMs), flash ROMs, and RAMs). The program can also be supplied to a computer by various types of transitory computer readable media. Examples of the transitory computer readable medium include electric signals, optical signals, and electromagnetic waves. The transitory computer readable medium can supply the program to a computer via a wired communication path such as an electric wire and an optical fiber, or via a wireless communication path.

[0097] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by a person skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure. [Explanation of symbols]

[0098] 100, 100A, 100B, 100C Tour plan generation device 101 Tour request input section 102 Tour Request Formation Department 103 Concrete Pattern Registration Database 104 Tour Item Registration Database 105 Condition Verification Section 106 Tour Plan Output Section 107 Unsuccessful Tour Item Calculation Department 150 Input section 151 Materialization Department 152 Output section 160 processors 161 Memory 200 terminals

Claims

1. A tour plan generation device, comprising: an embodiment pattern registration unit in which an embodiment pattern is registered in advance, which is a pattern for expressing tour requests including a time schedule, a means of transportation, accommodations, and tourist facilities of a package tour, as well as conditions including a budget and a number of people; an input unit for receiving input of the tour request and the conditions; a concretization unit that concretizes the input tour request and the conditions based on the concretization pattern, thereby generating the concretized tour request that satisfies the concretized conditions as a tour plan; an output unit that outputs the generated tour plan, The tour request and the tour plan include one or more tour items; The tour plan generation device further includes a calculation unit that calculates an uncompleted tour item among the tour items included in the tour plan, The input unit receives an input of the tour request and the conditions after the change based on the attempted tour item, The concretization unit concretizes the input changed tour request and the conditions, and regenerates the concretized changed tour request that satisfies the concretized conditions as the changed tour plan; The output unit outputs the regenerated changed tour plan. Tour plan generator.

2. A condition verification unit is further provided for verifying whether the specified tour request satisfies the specified condition, The concreteification unit provides the concrete tour request and the concrete conditions to the condition verification unit, thereby inquiring of the condition verification unit as to whether the concrete tour request satisfies the concrete conditions. The tour plan generating device according to claim 1 .

3. A tour item registration unit in which the tour items are registered in advance, the concretization pattern includes a pattern of rewriting the tour item included in the tour request to the tour item registered in the tour item registration unit; The tour plan generating device according to claim 1 .

4. A tour plan generation method performed by a tour plan generation device, comprising: A registration step of registering in advance an embodiment pattern which is a pattern for expressing tour requests including a time schedule, a means of transportation, accommodations, and tourist facilities of a package tour, as well as conditions including a budget and a number of people; an input step of accepting input of the tour request and the conditions; a concretization step of concretizing the input tour request and the conditions based on the concretization pattern, thereby generating the concretized tour request, which satisfies the concretized conditions, as a tour plan; and an output step of outputting the generated tour plan, The tour request and the tour plan include one or more tour items; The tour plan generating method further includes a calculation step of calculating an uncompleted tour item among the tour items included in the tour plan; In the input step, input of the tour request and the conditions after the change based on the attempted tour item is accepted, In the concretization step, the input changed tour request and the conditions are concretized, and the concretized changed tour request that satisfies the concretized conditions is regenerated as the changed tour plan; In the output step, the regenerated and changed tour plan is output. How to generate a tour plan.

5. On the computer, A registration step of registering in advance a concrete pattern which is a pattern for concretely specifying conditions including a time schedule, a means of transportation, accommodation, and tourist facilities of a package tour, as well as a budget and a number of people; an input step of accepting input of the tour request and the conditions; a concretization step of concretizing the input tour request and the conditions based on the concretization pattern, thereby generating the concretized tour request that satisfies the concretized conditions as a tour plan; an output step of outputting the generated tour plan; This is a program for executing The tour request and the tour plan include one or more tour items; The program further causes the computer to execute a calculation procedure for calculating tour items that have not yet been performed among the tour items included in the tour plan, In the input step, input of the tour request and the conditions after the change based on the attempted tour item is received; In the concretization step, the input changed tour request and the conditions are concretized, and the concretized changed tour request that satisfies the concretized conditions is regenerated as the changed tour plan; In the output step, the regenerated and changed tour plan is output. program.

Images