Work execution support system and method

Abstract

To support task execution with a plurality of persons.SOLUTION: A computer includes a main storage device storing therein a software program and a central control unit for running the software program. When the software program is run by the central control unit, the computer divides a desired task into a plurality of subtasks, determines users as request destinations for the respective subtasks on the basis of contents of the subtasks and behavioral histories of respective users, determines a part of the subtasks as compensating tasks on the basis of the contents of the subtasks and behavioral histories of the users being request destinations of the subtasks if needed, determines users of compensating request destinations for the compensating tasks on the basis of the behavioral histories of the users and contents of the compensating tasks, requests the request destinations to execute the subtasks, and requests the compensating request destinations to execute the compensating tasks.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a technology for supporting multiple people in carrying out an activity collaboratively. [Background technology]

[0002] In urban areas, there are activities in which residents cooperate with each other to improve the city and make life in the city more comfortable. In such activities, the tasks requested by residents need to be carried out by other residents. Therefore, technology is required that enables other residents to smoothly carry out the tasks requested by residents.

[0003] Patent Document 1 discloses a technology that provides users with content (alternatives) tailored to their characteristics and requests them to change their behavior in order to resolve city-wide problems caused by the actions of a large number of users, such as traffic congestion, crowded stores, excessive demand for electricity, and concentrated access to servers.

[0004] Specifically, in response to traffic congestion, the content of detours, time-shifted travel, trains, etc., and associated incentives such as parking discounts and free restaurant coupons are provided to the user, encouraging the user to change his / her behavior. In response to congestion in stores, etc., the content of vacant stores is provided to the user, along with associated incentives such as store-specific discount coupons and discount coupons for sale times and products customized for each user, encouraging the user to change his / her behavior.

[0005] On the other hand, Patent Document 2 discloses a technique for linking a parallel reality game with real commercial activities and data collection activities for the purpose of verifying the real positions of players of the parallel reality game. As part of the technique, a method is disclosed in which users are asked to change their behavior to conform to the intentions of the game organizer.

[0006] Specifically, the game encourages users to visit a real store in the parallel reality game by requesting the user to acquire virtual items, etc., and placing the virtual items, etc. in the store. Alternatively, the game encourages users to purchase real products or collect real data (locations and images of landmarks, artworks, etc.) for purposes other than the game (updating map or museum data, etc.) by offering advantageous benefits in the game on the condition that the user performs the requested action. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] JP 2017-59099 A [Patent Document 2] Special Publication No. 2020-526372 Summary of the Invention [Problem to be solved by the invention]

[0008] As in the above-mentioned activities in urban areas, the required work may be relatively large and require the actions of multiple people to carry it out. However, the techniques disclosed in Patent Documents 1 and 2 both request or encourage an individual to take action, and are not suitable for realizing cooperation among multiple people.

[0009] One object of the present disclosure is to provide a technique for supporting the execution of a task by multiple people. [Means for solving the problem]

[0010] A task execution support system according to one aspect of the present disclosure is a task execution support system for supporting a user in executing a requested task, and is configured as a computer having a main memory device for storing a software program and a central control unit for executing the software program, and is realized by the central control unit executing the software program, and includes an action history collection unit for collecting information on the action history of multiple users, a request reception unit for receiving the task, and a task execution support unit for dividing the task into multiple subtasks and requesting the execution of each of the subtasks based on the contents of the multiple subtasks and the action history of each user. The system includes a boundary determination unit that determines a user to which the subtask will be requested and determines whether or not to make the subtask a compensation target based on the content of the subtask and the behavioral history of the user to which the subtask is requested; a compensation range determination unit that determines a part of the subtask that is a compensation target as a compensation task based on the content of the subtask and the behavioral history of the user to which the subtask is requested and determines a compensation request user to be requested to perform the compensation task based on the behavioral history of each user and the content of the compensation task; and a request plan execution unit that requests the subtask to the requestee and requests the compensation task to the compensation requestee. Effect of the Invention

[0011] According to one aspect of the present disclosure, even if the requested work volume is large and the work takes a long time due to the behavioral change, it is possible to support the execution of the work by multiple people. [Brief description of the drawings]

[0012] [Figure 1] 1 is a diagram showing one form of a configuration of a task execution support system according to an embodiment; [Figure 2A] 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1. [Figure 2B] 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1. [Figure 2C] 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1. [Figure 2D] 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1. [Figure 2E] 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1. [Figure 3A] FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. [Figure 3B] FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. [Figure 3C] FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. [Figure 4A] FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. [Figure 4B] FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. [Figure 4C] FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. [Diagram 5] 2 is a diagram illustrating an example of a request plan execution database illustrated in FIG. 1. [Figure 6] 2 is a diagram for explaining the concept of processing from matching the contents of a request with a user's action history and determining a destination to which a task should be assigned based on the matching result in the task execution support system shown in FIG. 1. FIG. [Figure 7] 2 is a sequence diagram for explaining the overall concept of processing in the task request system shown in FIG. 1. [Figure 8] 2 is a diagram illustrating a concept of processing for subdividing a subtask and adding a compensation task in the task execution support system shown in FIG. 1. [Figure 9] FIG. 2 is a process flow diagram for explaining the overall process from subdividing a request into subtasks, adding a supplementary task, to determining a user to which each task is to be assigned in the task execution support system shown in FIG. [Figure 10] 1. FIG. 4 is a process flow diagram for explaining a process for determining a compensation range for a subtask and adding a compensation task based on the compensation range in the task execution support system shown in FIG. [Figure 11]FIG. 10 is a diagram showing an example of a request registration screen that is output to the input device in process S901 in FIG. 9 and that accepts input of a request from a request source. [Figure 12] FIG. 8 is a diagram showing an example of a screen for providing a request execution result output to an input device in process S732 of FIG. [Figure 13] FIG. 13 is a process flow diagram for explaining another example of the overall process in the work execution support system shown in FIG. 1, from subdividing a request into subtasks, adding a supplementary task, to determining a user to which each task is to be assigned. [Figure 14] 1. FIG. 4 is a diagram for explaining the concept of another example of the process of comparing the contents of a request with a user's action history and determining a destination to which a task should be assigned based on the result of the comparison in the task execution support system shown in FIG. [Figure 15] 1. FIG. 4 is a diagram for explaining the concept of another example of the process of comparing the contents of a request with a user's action history and determining a destination to which a task should be assigned based on the result of the comparison in the task execution support system shown in FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0014] In this embodiment, an example is shown in which multiple residents in an area of ​​a city cooperate to support activities to improve the city. Specifically, a request for activities to improve the city is accepted from the resident himself, and the residents, including other residents, share the work according to the request. If it is expected that some residents can only perform part of the shared work, or that some residents cannot perform the work at all, the other residents are assigned compensatory work to make up for the work that cannot be performed, and the entire request is promoted. However, the present invention is not limited to this embodiment, and the present invention is applicable to any situation for sharing requests.

[0015] FIG. 1 is a diagram showing an example of a configuration of a task execution support system.

[0016] As shown in Fig. 1, the task execution support system according to this embodiment is a task request system 100 that is configured to be connectable to an area management support system 150, a boundary determination information complement system 151, and user portable terminals 160-1 to 160-3 via a communication line 140. The task request system 100 is configured to include a central control device 130, a main memory device 110, an auxiliary memory device 120, a communication device 131, and an input / output device 132, which are connected to each other by a bus. Note that the number of user portable terminals 160-1 to 160-3 is not limited to three.

[0017] The auxiliary storage device 120 stores a request management database 121, a task database 122, a user history database 123, and a request plan execution database .

[0018] The main memory device 110 stores software programs. The behavior history collection unit 111, the request reception unit 112, the boundary determination unit 113, the compensation range determination unit 114, and the request planning / execution unit 115 are each software programs. Hereinafter, in the operations mainly described for the behavior history collection unit 111, the request reception unit 112, the boundary determination unit 113, the compensation range determination unit 114, and the request planning / execution unit 115, the central control device 130 reads each software program from the auxiliary memory device 120, loads it into the main memory device 110, and then realizes the function of each software program (details of which will be described later).

[0019] Area management support system 150 and boundary determination information complement system 151 are general computers, and user portable terminals 160-1 to 160-3 are general portable terminals.

[0020] The area management support system 150 is a system that supports activities for improving a city by cooperation between multiple residents in an area of ​​the city. The boundary determination information supplement system 151 is a system that is used when breaking down requests from residents into tasks of smaller units. For example, when a request is to investigate the ease of actions on a route from a starting point to a destination point, the starting point and the destination point are input into the boundary determination information supplement system 151 to search for a route from the starting point to the destination point, and in addition to the search results, the route is divided into sections for each means of transportation such as walking, train, and bus, and output. Using the output results, the route may be broken down into tasks such as investigating the ease of actions in a walking section, investigating the ease of actions in a train section, and investigating the ease of actions in a bus section. Such a boundary determination information supplement system 151 that searches for a route is generally called a shortest route search system, and such a shortest route search system may be realized by an existing tool that handles mathematical programming problems. The user portable terminals 160-1 to 160-3 are terminals for collecting user action histories and requesting tasks from users, such as smartphones. The task request system 100 communicates with the area management support system 150, the boundary determination information complement system 151, and the user portable terminals 160-1 to 160-3 via the communication line 140.

[0021] As the communication line 140, various networks can be adopted, such as a LAN (Local Area Network), a dedicated line, a WAN (Wide Area Network), a power line network, a wireless network, a public line network, a mobile phone network, a satellite communication line, etc. Furthermore, when a public communication line such as a public line network is adopted, a virtual private network (VPN) technology may be used to conceal the contents of communication and make it a pseudo dedicated line.

[0022] 1, the task request system 100 is configured to input and output independently, but it may be connected to another terminal via a communication line 140 and input and output information using an input / output device of the other terminal. Also, the task request system 100 may be a subsystem of the area management support system 160.

[0023] Here, the database will be described in detail.

[0024] 2A, 2B, 2C, 2D, and 2E are diagrams showing examples of the request management database 121 shown in FIG.

[0025] The request management database 121 stores data indicating the contents of a request, template data for registering a request, and threshold data for use in breaking down a request into tasks and then requesting the user to complete them.

[0026] The request management database 121 is composed of a request summary table 200 shown in FIG. 2A, a request content table 210 shown in FIG. 2B, a template summary table 230 shown in FIG. 2C, a template content table 240 shown in FIG. 2D, and a threshold table 250 shown in FIG. 2E.

[0027] The request summary table 200 shown in FIG. 2A stores data on the summary of a request registered by a requester. This data is registered by the requester resident as a summary of the work content he or she desires. Here, it is assumed that the data is input to the task request system 100, but it is also possible to cooperate with the area management support system 150 and obtain the data from the area management support system 150. The request summary table 200 is composed of a request ID 201, a title 202, a summary 203, and a template ID 204. The key for identifying each record is the request ID 201. The request ID 201 is an identifier for uniquely identifying the content of the request. The title 202 indicates the title of the request. The summary 203 indicates the summary of the request. The template ID 204 is an identifier for identifying the request registration template used by the requester to register the request.

[0028] The request content table 210 shown in FIG. 2B stores data on the detailed contents of requests registered by the request source. This is data in which the request source resident has registered details of the work content he or she desires. Here, it is assumed that the data is input to the task request system 100, but similar to the request summary table 200, the data may be obtained from the area management support system 150 in cooperation with the area management support system 150. The request content table 210 is composed of a request ID 211, a What option 212, Where 213, When 216, Who 219, and Weather 222. In addition, Where 213 is composed of an option 214 and a value 215, When 216 is composed of an option 217 and a value 218, Who 219 is composed of an option 220 and a value 221, and Weather 222 is composed of an option 223 and a value 224. The keys for identifying each record are the request ID 211 and the What option 212. The request ID 211 is an identifier for uniquely identifying the content of the request, and is the same as the request ID 201. The What option 212 indicates the content of the request, that is, what kind of work the requester wants the user to do as the content of the request. This is selected by the requester from among the options 242 in the template content table 240. Where 213 indicates the work location, that is, where the requester wants the user to do as the content of the request. The option 214 is selected by the requester from among the options 243 in the template content table 240, and the value 215 is a value registered by the requester for the option 214. When 216 indicates the time period, that is, when the requester wants the user to do as the content of the request. The option 217 is selected by the requester from among the options 244 in the template content table 240, and the value 218 is a value registered by the requester for the option 217. Who 219 indicates the type of user the requester wants to work on as the content of the request, and the attributes of that user. Choice 220 is selected by the requester from choices 245 in template content table 240, and value 221 is the value registered by the requester for choice 220.Weather 222 indicates the environment (weather) under which the requester wants the user to work as the content of the request. Choice 223 is selected by the requester from choices 246 in template content table 240, and value 224 is the value registered by the requester for choice 223.

[0029] Template summary table 230 shown in Fig. 2C stores data of a request summary registration template that is referenced by the request source when registering a request. This data is set in advance by a system administrator. Template summary table 230 is composed of template ID 231, title 232, and summary 233. The key for identifying each record is template ID 231. Template ID 231 is an identifier for identifying a request registration template. Title 232 indicates the title of the template. Summary 233 indicates the summary of the template.

[0030] The template content table 240 shown in FIG. 2D stores data of a registration template for request details that the requester refers to when registering a request. This data is set in advance by a system administrator. The template content table 240 is composed of a template ID 241, a What option 242, a Where option 243, a When option 244, a Who option 245, and a Weather option 246. The keys for identifying each record are the template ID 241 and the What option 242. The template ID 241 is an identifier for identifying a template for registering a request, and is the same as the template ID 231. The What option 242 indicates the type of work that the requester wants to request the user to do as the content of the request, and indicates the option of the work content. The Where option 243 indicates the option of the work location where the requester wants the user to do the work as the content of the request. When options 244 indicate options for the time period when the requester wants the user to work, as the content of the request. Who options 245 indicate options for the user attributes when the requester wants the user to work, as the content of the request. Weather options 246 indicate options for the environment (weather) when the requester wants the user to work, as the content of the request.

[0031] The threshold table 250 shown in FIG. 2E stores data on the minimum threshold that should be secured when making a request to a user. This data is set in advance by a system administrator. The threshold table 250 is composed of a template ID 251, a What option 252, a threshold (request acceptance level) 253, and a threshold (condition matching level) 254. The keys for identifying each record are the template ID 251 and the What option 252. The template ID 251 is an identifier for identifying a template for request registration, and is the same as the template ID 231. The What option 252 indicates the option of the work content that the requester wants to request the user as the content of the request, and is the same as the What option 242. The threshold (request acceptance level) 253 is a threshold set by a system administrator, and indicates a value that should be secured at the minimum when making a request to a user for the cumulative value of the request acceptance level that indicates the degree of possibility that the user will accept the request when making a request for the content of What. The threshold (degree of condition matching) 254 is a threshold set by a system administrator, and indicates the minimum value that must be secured when requesting the contents of "What" from a user, with respect to the degree of match between the user's attributes (Who) and the user's range of behavior (Where, When, Weather) extracted from the user's past behavior history and the conditions (Where, When, Who, Weather) of the requested contents of "What", indicating the degree of match.

[0032] 3A, 3B, and 3C are diagrams showing examples of the task database 122 shown in FIG.

[0033] The task database 122 stores data showing the relationship between the tasks that have been subdivided when requested to users and the original requests before they were subdivided, data for managing which user the task is to be requested to, and data for expressing and managing the content of the task using task conditions (Where, When, Who, Weather).

[0034] The task database 122 is made up of a subtask management table 300 shown in FIG. 3A, a task request destination management table 310 shown in FIG. 3B, and a task content management table 320 shown in FIG. 3C.

[0035] Subtask management table 300 shown in FIG. 3A stores data showing the relationship between the tasks subdivided when requested to the user and the original request before subdivision. Subtask management table 300 is composed of subtask ID 301, request ID 302, and compensation task ID 303. The key for identifying each record is subtask ID 301. Subtask ID 301 is an identifier for uniquely identifying a task. This is assigned to each of the subdivided subtasks when a request is subdivided to make it easier to request to a user. Request ID 302 is an identifier for uniquely identifying the content of the request, and is the same as request ID 201. This indicates which request the subtask of subtask ID 301 was subdivided from. Compensation task ID 303 is an identifier for uniquely identifying a compensation task. A filler task is a task that is used when, when subtask ID 301 is requested of a user, it is assumed that some of the task conditions (Where, When, Who, Weather) will not be acceptable to the user because they do not match the user's behavioral history. In this case, the filler task extracts the part of the task that is assumed to be unacceptable from subtask ID 301 and requests another user to complete the extracted part as a separate task.

[0036] In the task assignment destination management table 310 shown in FIG. 3B, when a subtask or a make-up task is requested to a user, data is stored that indicates the extent to which the activity range extracted from the user's activity history matches the task conditions (Where, When, Who, Weather) when the subtask or the make-up task is requested to a user, and the request acceptance level is assumed in advance. The task assignment destination management table 310 is composed of a task ID (sub / make-up) 311, a request destination user ID 312, a user's request acceptance level 313, and a condition match level 314 with the user's activity range. The keys for identifying each record are the task ID (sub / make-up) 311 and the request destination user ID 312. The task ID (sub / make-up) 311 is an identifier for uniquely identifying a task such as a subtask or a make-up task. The request destination user ID 312 is an identifier for uniquely identifying a user to whom the task is requested, and is the same as the user ID 401. The user's request acceptance degree 313 indicates the degree of possibility that the user will accept a task request when a task is requested to the user. The condition match degree 314 with the user's activity range indicates the degree to which the user's attributes (Who) and the user's activity range (Where, When, Weather) extracted from the user's past activity history match the conditions (Where, When, Who, Weather) of the task request content when a task is requested to the user.

[0037] 3C stores data indicating the contents of subtasks and make-up tasks. Task content management table 320 is composed of task ID (sub / make-up) 321, What options 322, Where 323, When 326, Who 329, and Weather 332. Where 323 is composed of options 324 and value 325, When 326 is composed of options 327 and value 328, Who 329 is composed of options 330 and value 331, and Weather 332 is composed of options 333 and value 334. A key for identifying each record is task ID (sub / make-up) 321. Task ID (sub / make-up) 321 is an identifier for uniquely identifying a task such as a subtask or make-up task, and is the same as task ID (sub / make-up) 311. The What option 322 indicates the type of work that is requested of the user as a task, and the work content. This is selected by the requester from the options 242 in the template content table 240. Where 323 indicates the location of the work that is requested of the user as a task. The option 324 is selected by the requester from the options 243 in the template content table 240, and the value 325 is the value registered by the requester for the option 324. When 326 indicates the time period when the user is requested to perform the task. The option 327 is selected by the requester from the options 244 in the template content table 240, and the value 328 is the value registered by the requester for the option 327. Who 329 indicates the attributes of the user that is requested to perform the task. The option 330 is selected by the requester from the options 245 in the template content table 240, and the value 232 is the value registered by the requester for the option 330. Weather 332 indicates the environment (weather) under which the user is desired to work as a task. Choice 333 is selected by the requester from among choices 246 in template content table 240, and value 334 is the value registered by the requester for choice 333.Although the values ​​325, 328, 331, and 334 are described as values ​​registered by the requester, they may be values ​​reregistered by the task request system 100 based on the values ​​registered by the requester. For example, the value 325 may be reregistered as a combination of a starting point and a destination point output from the boundary determination information supplement system 151, such as home-station, station-station, station-bus stop, or bus stop-store. The value 328 may be reregistered as a time period (morning, afternoon, evening, night, etc.) based on general lifestyle habits. Here, when reregistering a value, a new number is assigned to the task ID (sub / supplement) 321, and the values ​​322-334 other than the value to be reregistered are copied to the same values ​​as those before reregistration.

[0038] 4A, 4B, and 4C are diagrams showing examples of the user history database 123 shown in FIG.

[0039] The user history database 123 stores data on the attributes of users to whom tasks are to be requested, the user's past behavior history, and the history of task requests to the users.

[0040] The user history database 123 is made up of a user attribute table 400 shown in FIG. 4A, a user action history table 410 shown in FIG. 4B, and a user request history table 430 shown in FIG. 4C.

[0041] A user attribute table 400 shown in Fig. 4A stores data indicating user attributes. The user attribute table 400 is composed of a user ID 401 and user attributes 402. The key for identifying each record is the user ID 401. The user ID 401 is an identifier for uniquely identifying a user to whom a task is to be assigned. The user attributes 402 are data indicating user attributes, such as, for example, gender, age, marital status, whether or not the user has children, height, weight, occupation, place of residence, place of origin, special skills, hobbies, favorite food, favorite drink, etc.

[0042] A user action history table 410 shown in FIG. 4B stores data indicating the action history of a user. The user action history table 410 is composed of a user ID 411, a date and time 412, a location 413, and weather 414. The keys for identifying each record are the user ID 411 and the date and time 412. The user ID 411 is an identifier for uniquely identifying the user to whom a task is assigned, and is similar to the user ID 401. The date and time 412 indicates the time of the user's past action. The location 413 indicates where the user ID 411 was at the date and time 412. The weather 414 indicates what kind of weather the user ID 411 was in at the date and time 412.

[0043] A user request history table 420 shown in FIG. 4C stores data indicating a request history to a user. The user request history table 420 is composed of a user ID 411, a task ID (sub / compensation) 422, a request date and time 423, a provided incentive 424, and an acceptance result 425. The keys for identifying each record are the user ID 421 and the task ID (sub / compensation) 422. The user ID 421 is an identifier for uniquely identifying a user to whom a task is requested, and is the same as the user ID 401. The task ID (sub / compensation) 422 is an identifier for uniquely identifying a task such as a subtask or a compensation task, and is the same as the task ID (sub / compensation) 311. The request date and time 423 indicates the date and time when the task ID (sub / compensation) 422 was requested to the user ID 421 in the past. The provided incentive 424 indicates the incentive provided when the task ID (sub / compensation) 422 was requested to the user ID 421 in the past. The acceptance result 425 indicates whether the user ID 421 has accepted or rejected the task ID (sub / fill) 422 in the past.

[0044] FIG. 5 is a diagram showing an example of the request plan execution database 124 shown in FIG.

[0045] The requested plan execution database 124 stores data on plans for requesting tasks to users and the results of their execution.

[0046] The request plan execution database 124 is made up of a request plan execution table 500 shown in FIG.

[0047] A request plan execution table 500 shown in FIG. 5 stores data on a plan when a task is requested to a user and the execution result thereof. The request plan execution table 500 is composed of a task ID (sub / compensation) ID 501, a requested user ID 502, a scheduled request date and time 503, a provided incentive 504, and an acceptance result 505. The keys for identifying each record are the task ID (sub / compensation) 501 and the requested user ID 502. The task ID (sub / compensation) 501 is an identifier for uniquely identifying a task such as a subtask or a compensation task, and is the same as the task ID (sub / compensation) 311. The user ID 502 is an identifier for uniquely identifying a user to which the task is requested, and is the same as the user ID 401. The scheduled request date and time 503 indicates the scheduled date and time when the task ID (sub / compensation) 501 is requested to the user ID 502. The provided incentive 504 indicates the incentive to be provided to the user when the task ID (sub / compensation) 501 is requested to the user ID 502. The acceptance result 505 indicates the result of whether the user ID 502 accepted or rejected the task ID (sub / compensation) 501 when the task ID (sub / compensation) 501 is requested to the user ID 502 by providing the provided incentive 504 at the scheduled request date and time 503.

[0048] The concept of the process of comparing the contents of a request with the user's action history and determining the destination to which the task is to be assigned based on the comparison result in the task execution support system shown in FIG. 1 will be described below.

[0049] FIG. 6 is a diagram for explaining the concept of the processing in the task execution support system shown in FIG. 1, from matching the contents of a request with a user's action history to determining a destination to which the task should be assigned based on the matching results.

[0050] In FIG. 6, a request content 600, a user action history 630, a task image 640, and a task list 650 are shown.

[0051] The request content 600 shows a conceptual diagram of a request for a movement range investigation registered by a requester. There is a Mr. X's house 601 as the home of the requester Mr. X, and a store Y 605 that Mr. X wants to visit for lunch. Mr. X is also considering travelling between them by baby stroller along a route 610, and lists a movement range investigation for a weekday lunch meal with a baby stroller as the request content 620. In response to this, the task request system 100 uses the boundary determination information complement system 151 to search for a route from Mr. X's house 601 to store Y 605, detects a station 602, a station 603 and a bus stop 604 between Mr. X's house 601 and store Y 605, and extracts a movement from Mr. X's house 601 to station 602, a movement from station 602 to station 603, a movement from station 603 to bus stop 604 and a movement from bus stop 604 to store Y 605 as assumed routes for travelling from Mr. X's house 601 to store Y 605 by baby stroller.

[0052] On the other hand, as shown in user behavior history 630, from the locations and dates and times of the past user behavior history, A's weekday morning and afternoon behavior history 631, B's weekday morning and afternoon behavior history 632, C's weekday morning behavior history 633, D's weekday afternoon behavior history 634, E's weekday morning and afternoon behavior history 635, and F's weekday morning and afternoon behavior history 636 are extracted as the behavior range near the expected route from X's house 601 to Y store 605.

[0053] The determination of whether the range of movement is near the expected route is based on the following factors: (1) whether the route is included in a rectangle connecting the four corners of the most extreme points of the location (latitude, longitude) of the past action history (location 413 in user action history table 410), (2) whether the time period during which the route was traveled matches the time period of date and time 412 in user action history table 410, (3) whether the weather specified in the request content matches the weather 414 in user action history table 410, and (4) whether the attributes of the requested user shown in the request content match the user attributes 402 in user attribute table 400.

[0054] Here, the range of movement in Person A's behavior history 631 includes the route from Person X's house 601 to the station 602, Person B's range of movement 632 includes the area around the station 602 on the route from Person X's house 601 to the station 602, Person C's range of movement in Person C's behavior history 633 includes the route from the station 602 to the station 603 and coincides with the time period when Person X went there, Person D's range of movement in Person D's behavior history 634 includes the route from the station 602 to the station 603 and coincides with the time period when Person X returned home, Person E's range of movement in Person E's behavior history 635 includes the route from the station 603 to the bus stop 604 and the area around the bus stop 604, and Person F's range of movement in Person F's behavior history 636 includes the route from the bus stop 604 to Store Y 605.

[0055] This is judged by the task request system 100, and A is assigned task 1 (641) of investigating behavior by baby car from X's house 601 to the station 602 in the morning and afternoon on weekdays, B is assigned task 2 (642) of investigating behavior by baby car around the station 602 in the morning and afternoon on weekdays, C is assigned task 3 (643) of investigating behavior by baby car from the station 602 to the station 603 in the morning on weekdays, D is assigned task 4 (644) of investigating behavior by baby car from the station 602 to the station 603 in the afternoon on weekdays, E is assigned task 5 (645) of investigating behavior by baby car from the station 603 to the bus stop 604 and around the bus stop 604 in the morning and afternoon on weekdays, and F is assigned task 6 (646) of investigating behavior by baby car from the bus stop 604 to store Y 605 in the morning and afternoon on weekdays.

[0056] These are summarized in a conceptual diagram to form a task image 640. These are summarized in a list to form a task list 650. The task list 650 is made up of a task 651, a request destination 652, and a request content 653.

[0057] In this way, by determining boundaries for generating compensatory tasks depending on the location and time period, subtasks can be generated with appropriate boundaries, and the subtasks can be made to take into account execution by the user.

[0058] Furthermore, if the desired work includes the action of traveling between a desired departure point and a desired destination, and the departure point and destination are divided into multiple sections by means of transportation, and traveling between the sections is treated as a subtask, then subtasks can be generated with appropriate boundaries for the travel action, and the subtasks can be designed to take into account execution by the user.

[0059] FIG. 7 is a sequence diagram showing an overall process in which task request system 100 shown in FIG. 1 collects user behavioral histories from user portable terminal devices 160-1 to 160-3, while a request source 701 registers a request in task request system 100, task request system 100 breaks down the request into tasks based on the collected user behavioral histories and requests them from the user, the results of the tasks requested by the user are registered in task request system 100, and task request system 100 provides the results to the request source.

[0060] In process S711, when the user portable terminal 160-1 provides the action history of user A to the task request system 100, the action history collection unit 111 of the task request system 100 accepts and collects the action history of user A.

[0061] Furthermore, in process S712, when the user portable terminal 160-2 provides the action history of user B to the task request system 100, the action history collection unit 111 of the task request system 100 accepts and collects the action history of user B.

[0062] Furthermore, in process S713, when the user portable terminal 160-3 provides the action history of user C to the task request system 100, the action history collection unit 111 of the task request system 100 accepts the action history of user C.

[0063] In step S721, the request source 701 registers a request in the request receiving unit 112 of the task request system 100, and the request receiving unit 112 receives the requested work.

[0064] Then, in process S722, the boundary determination unit 113 and the compensation range determination unit 114 of the task request system 100 break down the request into subtasks, and if it is assumed in advance that the subtasks requested from the user will only be partially accepted, they determine the range of task compensation to satisfy the request, add compensation tasks based on the compensation range, and determine the user to whom each task will be assigned so that the entire request is realized by requesting each of the subtasks and compensation tasks from the user.

[0065] Next, in process S723, the request planning / execution unit 115 of the task request system 100 requests a subtask or a supplementary task to the user A of the user portable terminal 160-1.

[0066] Also, in process S724, the request planning / execution unit 115 of the task request system 100 requests a subtask or a supplementary task to the user B of the user portable terminal 160-2.

[0067] In this way, the behavior history collecting unit 111 collects information on the behavior history of multiple users. The request receiving unit 112 receives the requested work. The boundary determining unit 113 divides the received work into multiple subtasks, and determines a user to be requested to perform each of the divided subtasks based on the contents of the multiple subtasks and the behavior history of each user, and determines whether or not to make the subtask a compensation target based on the contents of the subtask and the behavior history of the user to which the subtask is requested. The compensation range determining unit 114 determines a part of the subtask that is a compensation target as a compensation task based on the contents of the subtask and the behavior history of the user to which the subtask is requested, and determines a compensation request target user to be requested to perform the compensation task based on the behavior history of each user and the contents of the compensation task. Then, the request planning / executing unit 115 requests the subtask to the request target and requests the compensation task to the compensation request target. This makes it possible to favorably support the execution of work by multiple users.

[0068] In response to this, in process S725, user A of the user portable terminal 160-1 returns acceptance of the task request to the request planning / execution unit 115 of the task request system 100.

[0069] Furthermore, in process S726, user B of the user portable terminal 160-2 returns a refusal to accept the task request to the request planning / execution unit 115 of the task request system 100.

[0070] Then, in process S727, the boundary determination unit 113 and the compensation range determination unit 114 of the task request system 100 determine again the request recipient for the task rejected by user B of the user portable terminal 160-2, excluding the user who rejected the request, and determine whether to make the task a compensation target, and if it is a compensation target, determine again the compensation range to satisfy the request, add a compensation task again based on the compensation range, and determine again the user to whom the compensation task is to be requested. The process here is the process from process S903 onwards in Fig. 9 described later, but the "any subtask" in S903 is replaced with the subtask if the task rejected in process S726 is a subtask, or is replaced with the original subtask if the rejected task is a compensation task, and then the subsequent processes are performed.

[0071] After that, in process S728, the request planning / execution unit 115 of the task request system 100 again requests a compensation task to the user C of the user portable terminal 160-3.

[0072] In response to this, in process S729, user C of the user portable terminal 160-3 returns to the request planning / executing unit 115 of the task request system 100 an acceptance of the task request.

[0073] Furthermore, in process S730, user A of the user portable terminal 160-1 registers the execution result of the task in the request planning / execution unit 115 of the task request system 100.

[0074] Furthermore, in process S731, user C of the user portable terminal 160-3 registers the execution result of the task in the request planning / execution unit 115 of the task request system 100.

[0075] Thereafter, in process S732, the request planning / execution unit 115 of the task request system 100 provides the request source 701 with the task execution result as a result of the request.

[0076] In this way, the request planning / execution unit 115 identifies as rejected tasks the subtasks that were not accepted by the request recipient or the subtasks that were the source of the compensation tasks that were not accepted by the compensation request recipient. The boundary determination unit 113 excludes the users that did not accept the rejected tasks, determines the request recipient of the rejected tasks again, and determines whether or not to make the rejected tasks a compensation target. Then, the compensation range determination unit 114 determines new compensation tasks for the rejected tasks that became compensation targets, and determines new users to whom the compensation task will be requested. This makes it possible to effectively support the execution of work by multiple users.

[0077] Here, when executing a request or re-request in process S723, process S724, or process S728, if the task is a caution item shown in FIG. 10 described later, the request planning / execution unit 115 may increase an incentive for the user before executing the request or re-request.

[0078] In addition, in the case of a request that requires real-time performance, such as the example of ride sharing shown in Fig. 15 described later, in order to make it easier for the user to accept the re-request, the incentive to the user may be increased when making the re-request in process S728 before the re-request is executed. Alternatively, in order to make it easier for the user to accept the request in the first place, the provided incentive 504 may be temporarily reset to a higher value in process S722 or process S727 before the request is executed. Alternatively, in order to increase the frequency of re-requests and make it easier to find a user who will accept the request, the threshold value (request acceptance level) 253 or the threshold value (condition agreement level) 254 may be temporarily reset to a lower value when determining a request destination in process S722 or process S727 before the request destination is determined.

[0079] Next, in process S722 shown in FIG. 7, a request is broken down into subtasks, and when it is assumed in advance that the subtasks requested to the user will only be partially accepted, the process determines the range of task compensation to satisfy the request, adds compensation tasks based on the compensation range, and determines the user to whom each task will be assigned in order to fulfill the request by requesting each of the subtasks and compensation tasks to the user will be assigned.

[0080] FIG. 8 is a diagram showing a concept of the process of subdividing a subtask and adding a compensation task in the task execution support system shown in FIG.

[0081] The concept of the process S722 shown in FIG. 7 is shown as a conceptual diagram 800 as shown in FIG. 8, and the conceptual diagram 800 is made up of a process outline 801 of the process S722 and a process image 802 of the process S722.

[0082] Strictly speaking, reception of registered request (process S721) 810 is process S721, which is pre-processing of process S722. Further, request content 811 indicates the content of the request registered in process S721.

[0083] Boundary determination 820 indicates a process of determining boundaries in the desired content in order to divide the desired content 811 into subtasks. Boundaries 821 to 825 are boundaries in the desired content determined here. When the desired content 811 has a starting point and a destination, the boundary may be determined by searching the route using the boundary determination information complementation system 151 and extracting the branch points of the means of transportation on the route (the starting point itself, the station (branch point between walking and train travel), the station (branch point between train travel and bus travel), the bus stop (branch point between bus travel and walking), and the destination itself). Alternatively, the time period for performing the desired content 811 may be determined by extracting the characteristics of each time period based on the boundaries, using time periods based on general lifestyle habits (morning, mid-morning, afternoon, evening, night, etc.). In addition, when the desired content is registered with a distinction between sunny days and rainy days, it may be determined as the boundaries. Furthermore, if the request contents are registered by distinguishing the attributes of the request destination user (for example, women with children, elderly people, students, etc.), this may be determined as the boundary.

[0084] Subdivision into subtasks 830 indicates processing for subdividing the request content 811 based on boundaries 821 to 825. Subtasks 831 to 834 are the subtasks that have been divided.

[0085] Compensation range determination 840 indicates a process of extracting the unachievable portion from the subtask when it is assumed in advance that even if a subtask is requested to a user, only a portion of the subtask can be realized and the remaining portion cannot be realized. Compensation ranges 841 to 842 are compensation ranges extracted from the subtasks.

[0086] Addition of a compensation task 850 indicates a process of adding a compensation task to a subtask based on a compensation range 841-842 extracted from the subtask. In this example, a compensation task 851 is added to the subtask 831, and a compensation task 852 is added to the subtask 834. Here, for the subtasks 831-834 shown in the subtask division 830, the subtask 831 is assigned to user A, the subtask 832 is assigned to user C, the subtask 833 is assigned to user E, and the subtask 834 is assigned to user F. In addition, the compensation task 851 is assigned to user B, and the compensation task 852 is assigned to user E. Here, both the subtask 833 and the compensation task 852 are assigned to user E. However, for user E, it is one task, for example, a task that combines both tasks of traveling by bus from the station to the bus stop and traveling on foot around the bus stop.

[0087] Next, in this embodiment, in process S722 shown in FIG. 7, a series of processes is described, in which a request is broken down into subtasks, and when it is assumed in advance that the subtasks requested to a user will only be partially accepted, the range of tasks to be compensated for is determined to satisfy the request, compensation tasks are added based on the compensation range, and each of the subtasks and compensation tasks is requested of the user to realize the request, up to the determination of the user to whom each task is to be assigned.

[0088] FIG. 9 is a process flow diagram for explaining the overall process in the task execution support system shown in FIG. 1, from subdividing a request into subtasks, adding supplementary tasks, to determining users to which each task is to be assigned.

[0089] In step S900, the central control device 130 of the task request system 100 starts the processing flow. First, in step S901, the request receiving unit 112 receives the request contents from the request source via the input / output device 132. The request contents are received on an input screen of a user interface (UI) based on input items of What, Where, When, Who, and Weather. The input screen is shown in FIG. 11 (explained later). This process alone corresponds to step S721. Meanwhile, the subsequent processes are steps S722.

[0090] Next, in process S902, the boundary determination unit 113 determines boundaries in the request contents according to each of the conditions of What, Where, When, Who, and Weather, and divides the request into subtasks based on the boundaries. The What condition is determined by the request source, and the request source registers the work content, i.e., what kind of work the user is requested to do, and determines the boundaries according to the unit of the work. The Where condition indicates where the user is requested to do the work, and indicates the work location registered by the request source. For example, if the request content has a starting point and a destination, the boundary determination information complement system 151 is used to search for the route, and the change points of the transportation means on the route (such as stations, bus stops, and the destination itself) are extracted and determined. The When condition indicates when the user is requested to do the work, and indicates the time period of the work registered by the request source, and determines the time period based on general lifestyle habits (such as morning, mid-morning, afternoon, evening, and night) as the boundary. The Who condition is determined by extracting the attributes of the user registered by the request source, and determining the boundary. The weather condition is determined as the boundary based on the weather (sunny day, rainy day, etc.) registered by the requester, which is the environment (weather) under which the user is desired to work. Note that even if the requester has not registered the weather, if the requester has registered a fixed date and time, a general weather forecast tool may be used as the boundary determination information supplement system 151 to predict the weather for the day using the fixed date and time, and the predicted weather may be used instead to determine the boundary.

[0091] Next, in process S903, the boundary determination unit 113 selects an arbitrary subtask.

[0092] Next, in process S904, the boundary determination unit 113 searches for users who partially satisfy the conditions of the subtask (Where, When, Who, Weather) from the user attributes (Who) and the user's past action history, and adds the searched users to the request recipient candidates. Here, the determination of whether or not a user partially satisfies the conditions is made by narrowing down the user IDs 401 in the user action history table 410 by the user ID 401 of the user attribute 402 that matches the user attribute of the subtask, narrowing down further by records of the date and time 412 that matches the time period of the subtask, and if the weather is also taken into consideration, further narrowing down by records of the weather 414 that matches the weather of the subtask, and determining whether or not the narrowed down records include part of the total length of the subtask route within a rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413. If included, the percentage of the included portion is temporarily stored in the main storage device 110.

[0093] Next, in process S905, the boundary determination unit 113 calculates the request acceptance degree and the degree of match between the user's range of action and the subtask for all users who are candidate request recipients extracted in process S904. Here, the request acceptance degree is calculated from the number of task IDs (sub / fill) 422 for that user in the user request history table 420 and the proportion of acceptances rather than rejections among the acceptance results 425. In addition, the degree of match is calculated by reading the proportion (what percentage of the total length of the subtask route is included in a rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413) temporarily stored in the main memory device 110 in process S904, and calculating the proportion as a degree.

[0094] Next, in step S906, the boundary determination unit 113 selects a user with the highest request acceptance degree calculated in step S905 from among the request destination candidates, and determines that user as the request destination, and excludes that user from the request destination candidates.

[0095] Next, in process S907, the boundary determination unit 113 reads out the condition matching degree (already read out in process S905) of the user determined as the request recipient in process S906, and compares it with the threshold (condition matching degree) 254 in the threshold table 250. If it is equal to or less than the threshold, the process proceeds to process S908, and if it is greater than the threshold, the process proceeds to process S909.

[0096] In process S908, the boundary determination unit 113 determines that this subtask is a subtask to be compensated for, and temporarily stores information about the subtask in the main memory device 110.

[0097] In this way, if the degree of condition matching, which is calculated from the content of the subtask and the behavioral history of the user to whom the subtask is requested, and indicates the extent to which the behavior included in the subtask is included in the behavioral history, is below a predetermined threshold, the boundary determination unit 113 can determine an appropriate compensation target and compensation task by making the subtask a compensation target.

[0098] Next, in process S909, the boundary determination unit 113 adds the request acceptance degree calculated in process S905 to the cumulative value of the request acceptance degree of this subtask, updates the cumulative value, and compares the updated cumulative value with the threshold (request acceptance degree) 253 in the threshold table 250. Here, the method of adding up the request acceptance degrees (method of calculating the cumulative total) may be, for example, a total value, an average value, or a weighted average value. If it is equal to or less than the threshold, the process returns to process S906, and if it is greater than the threshold, the process proceeds to process S910.

[0099] In this way, the boundary determination unit 113 calculates a cumulative value of the request acceptance rate for a user to whom a subtask has been assigned, which represents the rate at which that user has accepted requests in the past, and adds additional users to whom the subtask is assigned until the calculated cumulative value exceeds a predetermined threshold, thereby increasing the possibility that the request will be accepted.

[0100] In process S910, the boundary determination unit 113 determines whether this subtask is to be compensated based on the result of process S908. If it is to be compensated, the process proceeds to process S911, and if it is not to be compensated, the process proceeds to process S912.

[0101] In process S911, the compensation range determination unit 114 determines the compensation range for the subtask using the subtask information temporarily stored in the main memory device 110 in process S908, and adds a compensation task based on the compensation range (details will be described later using Figure 10).

[0102] Next, in process S912, the boundary determination unit 113 determines whether any other subtasks remain. If so, the process proceeds to process S903. If not, the process proceeds to process S913.

[0103] Thereafter, in step S913, the central controller 130 ends the process flow.

[0104] FIG. 10 is a process flow diagram for explaining the process of determining the compensation range for a subtask and adding a compensation task based on the compensation range in the task execution support system shown in FIG.

[0105] In process S1000, when the boundary determination section 113 starts the process flow of process S911, first, in process S1001, the compensation range determination section 114 reads the information relating to the degree of condition agreement read in process S905.

[0106] Next, in process S1002, the compensation range determination unit 114 extracts a portion of the subtask that is determined when calculating the degree of condition agreement in process S905 and does not match the user's attributes or behavior history. Specifically, among the conditions of the subtask (What, Where, When, Who, Weather), the work content of the subtask is defined as What, the user ID 401 of the user's attributes 402 that matches the user attributes of the subtask and the user ID 401 in the user behavior history table 410 is defined as Who, the date and time 412 that matches the time zone of the subtask is defined as Where, when the weather is also taken into consideration, the weather 414 that matches the weather of the subtask is defined as Weather, and the portion of the total length of the path of the subtask that is not included in the rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413 is extracted as Where, and this is cut out as a compensation task.

[0107] In this way, the compensation range determination unit 114 can determine an appropriate compensation task by determining, as a compensation task, an action that is included in a subtask and is not included in the action history of the request destination.

[0108] Next, in process S1003, the compensation range determination unit 114 selects an arbitrary compensation task.

[0109] Next, in process S1004, the compensation range determination unit 114 searches for a user who completely satisfies the conditions (Where, When, Who, Weather) of the compensation task from the user attributes (Who) and the user's past action history, and adds the searched user to the compensation destination candidates. Here, the determination of whether or not the user completely satisfies the conditions is made by narrowing down the user IDs 401 in the user action history table 410 by the user ID 401 of the user attribute 402 that matches the user attribute of the compensation task, further narrowing down the records by records of date and time 412 that match the time zone of the compensation task, and if the weather is also taken into consideration, further narrowing down the records by records of weather 414 that match the weather of the compensation task, and determining whether or not the entire length of the route of the compensation task is included in the entire narrowed down records within a rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413.

[0110] Next, in process S1005, the compensation range determination unit 114 re-reads the request acceptance degree (already calculated in process S905) for all users who are compensation destination candidates extracted in process S1004.

[0111] Next, in process S1006, the compensation range determination unit 114 selects the user with the highest request acceptance degree reacquired in process S1005 from among the compensation destination candidates. The selected user is determined as the compensation destination and is excluded from the compensation destination candidates.

[0112] Next, in process S1007, the compensation range determination unit 114 adds the request acceptance degree reacquired in process S1005 to the cumulative value of the request acceptance degree of this compensation task, and updates the cumulative value. Here, as described above, the method of adding up the request acceptance degrees (method of calculating the cumulative total) may be, for example, a total value, an average value, or a weighted average value. Also, for the pair of subtask and user determined to be a compensation target in process S908 of FIG. 9, the request acceptance degree of the user is set as the request acceptance degree of this subtask. The updated cumulative value is compared with the request acceptance degree of this subtask, and if the updated cumulative value is equal to or less than the request acceptance degree of this subtask, the process proceeds to process S1008, and if the cumulative value is greater than the request acceptance degree of this subtask, the process proceeds to process S1015.

[0113] In process S1008, the compensation range determination unit 114 determines whether there are any other compensation candidate users remaining. If there are, the process returns to process S1006, and if there are no remaining users, the process proceeds to process S1009.

[0114] In process S1009, the compensation range determination unit 114 searches for users who partially satisfy the conditions (Where, When, Who, Weather) of the compensation task from the user attributes (Who) and the user's past action history, and adds the searched users to the compensation destination candidates. Here, the determination of whether or not a user partially satisfies the conditions is performed by narrowing down the user IDs 401 in the user action history table 410 by the user IDs 401 of the user attributes 402 that match the user attributes of the compensation task, narrowing down the records by records of the date and time 412 that match the time period of the compensation task, and if the weather is also taken into consideration, further narrowing down the records by records of the weather 414 that match the weather of the compensation task, and determining whether or not the narrowed down records include part of the total length of the route of the compensation task within a rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413. If included, the percentage of the included portion is temporarily stored in the main storage device 110.

[0115] Next, in process S1010, the compensation range determination unit 114 calculates the request acceptance degree and the degree of match between the user's range of action and the subtask for all users who are compensation candidates extracted in process S1004. Here, the request acceptance degree is calculated from the number of task IDs (sub / compensation) 422 for that user in the user request history table 420 and the proportion of acceptances rather than rejections among the acceptance results 425. In addition, the degree of match is calculated by reading the proportion (what percentage of the total length of the subtask path is included in a rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413) temporarily stored in the main memory device 110 in process S1009, and calculating the proportion as a degree.

[0116] Next, in process S1011, the compensation range determination unit 114 selects the user with the highest degree of condition matching, determines the user as the compensation recipient, and excludes the user from the compensation recipient candidates.

[0117] Next, in process S1012, the compensation range determination unit 114 reads the condition match degree (already calculated in process S1009) of the user determined as the compensation recipient in process S1010, and compares it with the threshold (condition match degree) 254 in the threshold table 250. If it is equal to or less than the threshold, the process proceeds to process S1013, and if it is greater than the threshold, the process proceeds to process S1014.

[0118] In process S1013, the compensation range determination unit 114 determines that the compensation task does not have a sufficient degree of condition agreement (Where, When, Who, Weather) with respect to the subtasks, adds the compensation task to the attention items, and proceeds to process S1014.

[0119] In process S1014, the compensation range determination unit 114 adds the request acceptance degree calculated in process S1010 to the cumulative value of the request acceptance degree of this compensation task, and updates the cumulative value. Also, the request acceptance degree process of this subtask used in process S1007 (for the pair of subtask and user determined to be a compensation target in S908, the user's request acceptance degree 425 is the request acceptance degree of this subtask) is compared with the updated cumulative value, and if the cumulative value is equal to or less than the request acceptance degree of this subtask, the process returns to process S1011, and if the cumulative value is greater than the request acceptance degree of this subtask, the process proceeds to process S1015.

[0120] In process S1015, the compensation range determination unit 114 determines whether any other compensation tasks remain. If any remain, the process proceeds to process S1003. If no remain, the process proceeds to process S1016.

[0121] Thereafter, in process S1016, the boundary determination unit 113 ends the process flow of process S911.

[0122] In this way, the compensation range determination unit 114 calculates the cumulative value of the request acceptance degree for users who have been requested to make compensation for the compensation task, and adds compensation request recipients for the compensation task until the calculated cumulative value exceeds the cumulative value of the request acceptance degree of the subtask that was the source of the compensation task, thereby increasing the likelihood that the request for the compensation task will be accepted and the likelihood that the original subtask will be executed.

[0123] Next, a description will be given of the request registration screen which is output to the input / output device 132 in step S901 in FIG. 9 and which accepts input of a request from a request source.

[0124] FIG. 11 is a diagram showing an example of a request registration screen that is output to the input / output device 132 in step S901 of FIG. 9 and that accepts input of a request from a request source.

[0125] An example of a request registration screen that is output to the input / output device 132 in process S901 of Figure 9 and that accepts input of requests from the request source is a request registration screen 1100, as shown in Figure 11, which is composed of a template 1101, a request registration button 1102, and request content 1110.

[0126] Template 1101 shows a selection field for a template for registering a request, and in this example, a movement range survey template, a graffiti prevention template, and a ride-sharing template are shown. Any template can also be added. Request registration button 1102 is a button for registering the content of a request, and is a button for registering the content of a request after inputting the specific content of a request in request content 1110 for the template selected in template 1101. Request content 1110 is an area for registering the specific content of a request, and the display content may be changed depending on the template selected in template 1101. Here, an example is shown in which a survey template is selected. Request content 1110 is composed of a What input field 1111, What selection 1112, a What item registration button 1113, and conditions 1120.

[0127] The What input field 1111 is a field for inputting a specific value for the What option selected in the What selection 1112. The What selection 1112 is a field for selecting the work content to be requested to the client as What. Here, an example is shown in which "meal in a stroller" is selected and nothing is entered in the What input field 1111. The What item registration button 1113 is a button for registering each of the What conditions selected in the What input field 1111 and What selection 1112 and the corresponding Where, When, Who, and Weather conditions are entered in the conditions 1120 as specific values ​​of the request.

[0128] Condition 1120 is a field for inputting conditions Where, When, Who, and Weather. Condition 1120 is composed of a Where input field 1121, a Where selection 1122, a When input field 1123, a When selection 1124, a Who input field 1125, a Who selection 1126, a Weather input field 1127, and a Weather selection 1128.

[0129] The Where input field 1121 is a field for inputting a specific value for the Where option selected in the Where selection 1122. The Where selection 1122 is a field for selecting the location of the work to be requested of the requester as Where. Here, an example is shown in which the departure point and arrival point are selected for What "meal in a baby cart" in the activity range survey template, and the latitude and longitude of the departure point and the latitude and longitude of the arrival point are input in the Where input field 1121.

[0130] The When input field 1123 is a field for inputting a specific value for the When option selected in When selection 1124. The When selection 1124 is a field for selecting the time period for the work to be requested to the contractor as When. Here, an example is shown in which the time period and weekday / weekend / holiday have been selected for What "meal in a stroller" in the activity range survey template, and the time period and weekday / weekend / holiday have been entered in the When input field 1123.

[0131] The Who input field 1125 is a field for inputting a specific value for the Who option selected in the Who selection 1126. The Who selection 1126 is a field for selecting the attributes of the user to be requested to the request destination as Who. Here, an example is shown in which the presence or absence of children is selected in the What "eating with a baby cart" in the activity range survey template, and "with children" is selected. An example is shown in which nothing is entered in the Who input field 1125.

[0132] The Weather input field 1127 is a field for inputting a specific value for the Weather option selected in the Weather selection 1128. The Weather selection 1128 is a field for selecting the weather to be expected when making a request to the requesting party. Here, an example is shown in which rain is selected for "eating in a baby cart" in the What of the activity range investigation template, and nothing is entered in the Weather input field 1127.

[0133] Next, a screen for providing the request execution result output to the input / output device 132 in process S732 of FIG. 7 will be described.

[0134] FIG. 12 is a diagram showing an example of a screen for providing the request execution result output to the input / output device 132 in process S732 of FIG.

[0135] An example of the request execution result provision screen output to the input / output device 132 in process S732 of FIG. 7 is a request execution result provision screen 1200, as shown in FIG. 12, which compiles the results of execution by each user in relation to a request from the requester and provides them to the requester, and is displayed on the input / output device 132 of the task request system 100.

[0136] The screen 1200 showing the request execution result shown in FIG. 12 is composed of a travel route (X's house 1201, station 1202, station 1203, bus stop 1204, store Y 1205, route (X's house - station) 1211, route (station - station) 1212, route (station - bus stop) 1213, route (bus stop - store Y) 1214) to store Y that X wants to visit for lunch, difficult-to-travel locations (difficult-to-travel locations 1215, difficult-to-travel locations 1216), and survey results explaining the reasons for the difficulty of travel (survey results 1220, survey results 1230). The travel route is provided to the request source as a recommended travel route because the reason for the difficulty of travel is not found in the survey by the user. On the other hand, the difficult-to-travel locations are information for the request source to decide whether to pass through them, since some users have stated the reasons for the difficulty of travel. Here, the investigation result 1220 corresponds to the difficult-to-move location 1215, and the investigation result 1230 corresponds to the difficult-to-move location 1216. The investigation result 1220 is composed of negative opinions 1221 and results 1222, where the negative opinions 1221 indicate the number of users who consider it difficult to move, and the results 1222 indicate the investigation results when the user judges it difficult to move. The results 1222 may include an image of the investigation result. Similarly, the investigation result 1230 is composed of negative opinions 1231, results 1232, and results 1233, where the negative opinions 1231 indicate the number of users who consider it difficult to move, and the results 1232 and 1233 indicate the investigation results when the user judges it difficult to move.

[0137] (Other embodiments)

[0138] Fig. 13 is a process flow diagram for explaining another example of the overall process from dividing a request into subtasks, adding a supplementary task, to deciding a user to which each task is to be assigned in the task execution support system shown in Fig. 1. In this example, a method for gradually reducing the number of candidates to which the task is to be assigned is shown.

[0139] When the central control device 130 of the task request system 100 starts the process flow in step S1300, first, in step S1301, the request receiving unit 112 receives request contents from the request source via the input / output device 132, similarly to step S901.

[0140] Next, in process S1302, similarly to process S902, the boundary determination unit 113 determines boundaries in the request content according to each of the conditions What, Where, When, Who, and Weather, and divides the request into subtasks based on the boundaries.

[0141] Next, in process S1303, similarly to process S903, the boundary determination unit 113 selects an arbitrary subtask.

[0142] Next, in process S1304, similar to process S904, the boundary determination unit 113 searches for users who partially satisfy the subtask conditions (Where, When, Who, Weather) based on the user attributes (Who) and the user's past behavioral history, and adds the searched users to the list of candidate recipients.

[0143] Next, in process S1305, similarly to process S905, the boundary determination unit 113 calculates the request acceptance degree and the condition matching degree between the user's action range and the subtask for all the request destination candidate users extracted in process S1304.

[0144] Next, in process S1306, the boundary determination unit 113 selects, from among the request destination candidates, a user with the lowest degree of match of the conditions calculated in process S1305.

[0145] Next, in process S1307, the boundary determination unit 113 calculates the cumulative value of the request acceptance level of this subtask when the selected user is provisionally excluded from the request recipient candidates, and compares it with the threshold (request acceptance level) 253 in the threshold table 250. Here, as described above, the method of adding up the request acceptance levels (method of calculating the cumulative total) may be, for example, the total value, the average value, or the weighted average value. If it is equal to or less than the threshold, the process proceeds to process S1309, and if it is greater than the threshold, the process proceeds to process S1308.

[0146] In process S1308, the boundary determining section 113 excludes this user from candidates for the subtask request recipient, and the process proceeds to process S1310.

[0147] In process S1309, the boundary determination unit 113 adds the user to the essential user list for this subtask without excluding the user, and the process proceeds to process S1310.

[0148] In step S1310, the boundary determination unit 113 determines whether the candidate request recipients for this subtask match the essential user list. If they match, the process proceeds to step S1311, and if they do not match, the process returns to step S1306.

[0149] In process S1311, the boundary determination unit 113 requests all users in the essential user list of this subtask to be the request recipients.

[0150] Next, in process S1312, the boundary determination unit 113 determines whether any other subtasks remain. If so, the process proceeds to process S1303. If not, the process proceeds to process S1313.

[0151] Thereafter, in step S1313, the central control device 130 ends the processing flow.

[0152] FIG. 14 is a diagram for explaining the concept of another example of the processing in the task execution support system shown in FIG. 1, in which the content of a request is compared with a user's behavioral history and a destination to which the task is to be assigned is determined based on the result of the comparison.

[0153] In FIG. 14, a request content 1400, a user action history 1430, a task image 1440, and a task list 1450 are shown.

[0154] Request details 1400 shows a conceptual diagram of a request regarding graffiti prevention registered by a requester. There is an area 1401 where the requester is planning to carry out graffiti prevention activities, and there is a graffiti location (point X) 1402 and a graffiti location (point Y) 1403 that will be discovered later. The request details include patrols 1420 of the area 1401, priority patrols 1421 for graffiti that will be discovered later, graffiti removal 1422 for the graffiti that will be discovered, and prevention of recurrence of graffiti that will be discovered 1423.

[0155] On the other hand, as shown in user behavior history 1430, from the location and date and time of the past user behavior history, A's behavior history 1431, B's behavior history 1432, C's behavior history 1433, D's behavior history 1434, H's behavior history 1435, and I's behavior history 1436 are extracted as their respective ranges of behavior in area 1401. In addition, from the user attributes, the F group of Fa, Fb, and Fc with the attribute of graffiti removal, and E and G with the attribute of recurrence prevention activities are extracted as highly specialized people engaged in graffiti prevention activities in the area.

[0156] Here, the task request system 100 divides the area 1401 into areas in charge of multiple users. For example, the action history 1431 of A, the action history 1432 of B, the action history 1433 of C, and the action history 1434 of D are used to form a rectangle by connecting the four corners of the most extreme points of the location (latitude, longitude) of each past action history (location 413 in the user action history table 410), and the area 1401 can be reconstructed by overlapping each action range. From this, the task request system 100 determines that the area 1401 can be divided into the action ranges of A, B, C, and D, and assigns task 1-1 (1441) to A, task 1-2 (1442) to B, task 1-3 (1443) to C, and task 1-4 (1444) to D. All of these tasks are patrol tasks.

[0157] Furthermore, the task request system 100 extracts the range of movement in Mr. H's behavior history 1433 and the range of movement in Mr. I's behavior history 1434 from a rectangle connecting the four corners of the most extreme points of the location (latitude, longitude) of the past behavior history (location 413 in user behavior history table 410), and determines that they each include graffiti location (location X) 1402 and graffiti location (location Y) 1403, which will be discovered later, and assigns task 2-1 (1445) to Mr. H and task 2-2 (1446) to Mr. I. All of these tasks are priority patrol tasks.

[0158] In addition, as people who are professionally engaged in graffiti prevention activities in this area, the F group of Fa, Fb, and Fc is extracted from the user attributes 402 in the user attribute table 400. Since Fa, Fb, and Fc have the attributes of users who remove graffiti, they are assigned the task 3 of removing graffiti.

[0159] Furthermore, as people who are professionally engaged in graffiti prevention activities in this area, Mr. E and Mr. G are extracted from user attribute 402 in user attribute table 400. Since Mr. E and Mr. G have the attributes of a recurrence prevention user, they are assigned recurrence prevention tasks 4-1 and 4-2, respectively.

[0160] These are summarized in a conceptual diagram as a task image 1440. These are summarized in a list as a task list 1450. The task list 1450 is made up of a task 1451, a request destination 1452, and request contents 1453.

[0161] FIG. 15 is a diagram for explaining the concept of another example of the processing in the task execution support system shown in FIG. 1, in which the content of a request is compared with a user's behavioral history and a destination to which the task is to be assigned is determined based on the result of the comparison.

[0162] In FIG. 15, a request content 1500, a user action history 1530, a task image 1540, and a task list 1550 are shown.

[0163] Request details 1500 shows a conceptual diagram of a request for ride sharing registered by a requester. There is a house 1501 of Mr. X, who is the requester, as his / her home, and a store Y 1502 that Mr. X wants to visit for shopping. Mr. X is also considering travelling by car for a route 1510 between the two locations, and has listed a request 1520 for someone to drive for a ride sharing session.

[0164] On the other hand, as shown in user behavior history 1530, from the locations and dates and times of the user's past behavior history (date and time 412 and location 413 in user behavior history table 410), Mr. A's behavior history 1531, Mr. B's behavior history 1532, and Mr. C's behavior history 1533 are extracted as the behavior range near route 1510.

[0165] The determination of whether the movement range is in the vicinity of the assumed route is made based on the following elements.

[0166] (1) Does the route fall within a rectangle connecting the four corners of the locations (latitude, longitude) of the past behavior history (location 413 in user behavior history table 410)? (2) Does the time period during which the route was traveled match the time period of date and time 412 in user behavior history table 410?

[0167] This is judged by the task request system 100, and A is assigned a ride-sharing from X's house 1501 to store Y 1505 as task 1-1 (1541). Also, B and C are assigned a ride-sharing from store Y 1505 to X's house 1501 as task 1-2 (1542).

[0168] These are summarized in a conceptual diagram to form a task image 1540. These are summarized in a list to form a task list 1550. The task list 1550 is made up of a task 1551, a request destination 1552, and a request content 1553. [Explanation of symbols]

[0169] 100··Task request system, 110··Main memory device, 111··Action history collection unit, 112··Request reception unit, 113··Boundary determination unit, 114··Compensation range determination unit, 115··Request plan / execution unit, 120··Auxiliary memory device, 121··Request management database, 122··Task database, 123··User history database, 124··Request plan execution database, 130··Central control device, 131··Communication device, 132··Input / output device, 140··Communication line, 150··Area management support system, 151··Boundary determination information complementation system

Claims

1. A task execution support system for assisting a user in performing a desired task including actions to be performed under desired conditions including where to perform the task and what to perform, comprising: The present invention is configured with a computer having a main memory device for storing a software program and a central control unit for executing the software program, and is realized by the central control unit executing the software program. A behavior history collection unit that collects information on the behavior histories of a plurality of users; A request receiving unit that receives the work; a boundary determination unit that divides the work into a plurality of subtasks by dividing the work into a plurality of subtasks at the boundaries of the conditions and treating each of the subtasks as a subtask, and determines a user to be requested to perform each of the subtasks by selecting from among users whose behavioral histories partially satisfy the conditions of the subtasks based on the contents of the subtasks and the behavioral history of each of the users, and determines whether or not to make the subtask a compensation target based on whether the degree to which the behavioral history of the user matches the conditions is equal to or lower than a predetermined threshold value based on the contents of the subtask and the behavioral history of the user to whom the subtask is requested. a compensation range determination unit which determines a portion of the subtask that is the subject of compensation as a compensation task by extracting a portion of the behavior history of the user to whom the subtask is to be requested that does not match the conditions of the subtask based on the content of the subtask and the behavior history of the user to whom the subtask is to be requested, and which determines a user to be requested to perform the compensation task by selecting from among users whose behavior history partially satisfies the conditions of the compensation task based on the behavior history of each user and the content of the compensation task; a request plan execution unit that requests the subtask to a requestee by transmitting information requesting the subtask to the terminal device of the requestee, and requests the compensation task to the compensation requestee by transmitting information requesting the compensation task to the terminal device of the user that is the compensation requestee; having The request plan execution unit identifies a subtask that was not accepted by the request recipient and / or a subtask that was the source of a compensation task that was not accepted by the compensation request recipient as a rejected task, the boundary determination unit excludes the user who did not accept the rejected task, determines again the request destination of the rejected task, and determines whether or not to make the rejected task a compensation target; The compensation range determination unit determines a new compensation task for the rejected task that is the compensation target, and determines a new user to which the compensation task is to be requested to be compensated. Work execution support system.

2. the boundary determination unit calculates an accumulated value of a request acceptance degree representing a rate at which a user who has been assigned the subtask has accepted a request in the past, and adds a request recipient for the subtask until the accumulated value exceeds a predetermined threshold value. The task execution support system according to claim 1 .

3. the compensation range determination unit calculates a cumulative value of a request acceptance degree for a user who has been requested to make a compensation for the compensation task, and adds a compensation request destination for the compensation task until the cumulative value exceeds a cumulative value of a request acceptance degree for a subtask that is the source of the compensation task. The task execution support system according to claim 2 .

4. the desired task includes travel between a desired start location and a desired destination location; The boundary determination unit divides the distance between the departure point and the arrival point into a plurality of sections by a transportation means, and the movement of the sections is set as a subtask. The task execution support system according to claim 1 .

5. A task execution assistance method for assisting a user in performing a desired task including actions to be performed under desired conditions including where to perform and what to perform, comprising: A computer having a main memory device for storing a software program and a central control unit for executing the software program executes the software program by the central control unit, Collect information on the behavioral history of multiple users, Accept the work, Dividing the work into a plurality of subtasks by dividing the work into a plurality of subtasks at the boundaries of the conditions and treating each of the subtasks as a subtask, determining a user to be requested to perform each of the subtasks by selecting from among users whose behavioral history partially satisfies the conditions of the subtasks based on the content of the plurality of subtasks and the behavioral history of each of the users, and determining whether or not to make the subtask a compensation target based on the content of the subtask and the behavioral history of the user to whom the subtask is requested, depending on whether the degree to which the behavioral history of the user matches the conditions is equal to or below a predetermined threshold; For the subtask to be compensated for, a portion of the subtask is determined as a compensation task by extracting a portion of the behavior history of the user to whom the subtask is to be requested that does not match the conditions of the subtask based on the content of the subtask and the behavior history of the user to whom the subtask is to be requested, and a user to be requested to perform the compensation task is determined by selecting from among users whose behavior history partially satisfies the conditions of the compensation task based on the behavior history of each user and the content of the compensation task; A method for requesting the subtask to a requestee by transmitting information for requesting the subtask to the requestee's terminal device, and for requesting the compensation task to the compensation requestee by transmitting information for requesting the compensation task to the compensation requestee's terminal device, further comprising: Identifying a subtask that was not accepted by the requester and / or a subtask that was the source of a compensation task that was not accepted by the compensation requester as a rejected task; determining again to whom the rejected task should be requested, excluding the users who did not accept the rejected task, and determining whether or not the rejected task should be compensated; determining a new compensation task for the rejected task that is the compensation target, and determining a new user to which the compensation task is to be requested to be compensated; A method for assisting in the execution of work.

Images