JP7648550B2 - Work execution support system and method - Google Patents

Description

This disclosure relates to technology that supports multiple people working together to carry out an activity.

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

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.

Specifically, in response to traffic congestion, content such as detours, staggered travel times, trains, etc., and associated incentives such as discounts on parking spaces and free tickets to restaurants are provided to users, encouraging them to change their behavior. In response to congestion in stores, etc., content showing vacant stores and associated incentives such as discount coupons limited to that store, discount coupons limited to sale times and products customized for each user are provided to users, encouraging them to change their behavior.

Meanwhile, Patent Document 2 discloses a technology that links a parallel reality game with real-world commercial activities and data collection activities in order to verify the real-world positions of players in the parallel reality game. As part of this, a method is shown in which users are asked to change their behavior to conform to the intentions of the game organizer.

Specifically, the system encourages users to visit real stores 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 system encourages users to purchase real products by offering advantageous benefits in the game on the condition that the requested action is taken, or encourages users to collect real data (locations and images of landmarks, artworks, etc.) for purposes other than the game (updating map or museum data, etc.).

JP 2017-59099 A Special Publication No. 2020-526372

As with the urban activities mentioned above, the required tasks may be relatively large and require the actions of multiple people to carry them out. However, the technologies disclosed in Patent Documents 1 and 2 both request or encourage an individual to take action, and are not suitable for achieving cooperation among multiple people.

One objective of this disclosure is to provide technology that supports the execution of tasks by multiple people.

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 a behavior history collection unit for collecting information on the behavior history of multiple users, a request reception unit for receiving the task, and a task execution support system 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 behavior history of each user. The system has a boundary determination unit that determines a user to which the subtask is to be requested, and determines whether or not the subtask is to be compensated based on the content of the subtask and the behavior history of the user to whom the subtask is requested; a compensation range determination unit that determines a part of the subtask that is to be compensated as a compensation task based on the content of the subtask and the behavior history of the user to whom the subtask is requested, and determines a compensation request user to be requested to perform the compensation task based on the behavior 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.

According to one aspect of the present disclosure, it is possible to support the execution of work by multiple people even when the requested work volume is large and the time required for the work is long due to the behavioral change.

1 is a diagram showing one form of a configuration of a task execution support system according to an embodiment; FIG. 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a request management database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a task database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a user history database illustrated in FIG. 1 . FIG. 2 is a diagram illustrating an example of a requested plan execution database illustrated in FIG. 1 . 2 is a diagram for explaining the concept of 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 result. FIG. 2 is a sequence diagram for explaining the overall concept of processing in the task request system shown in FIG. 1. 2 is a diagram showing a concept of processing for subdividing a subtask and adding a compensation task in the task execution support system shown in FIG. 1 . FIG. 2 is a process flow diagram for explaining 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. 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. FIG. 10 is a diagram showing an example of a request registration screen that is output to an input device in step S901 in FIG. 9 and that accepts input of a request from a request source. 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. 7; 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. 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 results of the comparison in the task execution support system shown in FIG. 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 results of the comparison in the task execution support system shown in FIG.

Below, an embodiment of the present invention will be described with reference to the drawings.

In this embodiment, an example is shown in which multiple residents in an urban area cooperate to support activities to improve the city. Specifically, requests for activities to improve the city are accepted from the residents themselves, and tasks according to the requests are shared among the residents, including other residents. If it is anticipated that some residents will only be able to perform part of the shared tasks, or will not be able to perform the tasks at all, compensatory tasks are assigned to other residents to make up for the tasks that cannot be performed, thereby encouraging the realization of the entire request. However, the present invention is not limited to this embodiment, and the present invention is applicable to any situation in which requests are shared.

Figure 1 shows one embodiment of the configuration of a task execution support system.

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 have 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 interconnected by a bus. Note that the number of user portable terminals 160-1 to 160-3 is not limited to three.

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 124.

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 explained 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).

The area management support system 150 and the boundary determination information complement system 151 are general computers. In addition, the user mobile terminals 160-1 to 160-3 are general mobile terminals.

The area management support system 150 is a system that supports activities for improving the city by multiple residents working together in an urban area. The boundary determination information supplement system 151 is a system used to break down requests from residents into tasks in 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 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 task 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 performs route search 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. Additionally, the user portable terminals 160-1 to 160-3 are terminals for collecting user behavior history and requesting tasks from users, such as smartphones. Here, 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.

For the communication line 140, various networks can be used, 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, and a satellite communication line. In addition, when using a public line or other public communication line, a virtual private network (VPN) technology can be used to conceal the contents of the communication and create a pseudo-dedicated line.

In FIG. 1, the task request system 100 is assumed to perform input and output independently, but it may be connected to another terminal via a communication line 140, and information may be input and output by the input/output device of the other terminal. The task request system 100 may also be a subsystem within the area management support system 160.

Here we explain the details of the database.

Figures 2A, 2B, 2C, 2D, and 2E are diagrams showing examples of the request management database 121 shown in Figure 1.

The request management database 121 stores data indicating the content of the request, template data for registering the request, and threshold data used when breaking down the request into tasks and then requesting the user to complete them.

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.

The request summary table 200 shown in FIG. 2A stores request summary data registered by the requester. This data is registered by the requester resident with 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.

The request content table 210 shown in FIG. 2B stores data on the detailed contents of requests registered by the requesters. This is data in which the requesting resident has registered details of the work he or she wishes to do. Here, it is assumed that the data is input to the task request system 100, but similar to the request summary table 200, it is also possible to link with the area management support system 150 and obtain the data from the area management support system 150. The request content table 210 is composed of a request ID 211, What options 212, Where 213, When 216, Who 219, and Weather 222. Furthermore, Where 213 is composed of options 214 and value 215, When 216 is composed of options 217 and value 218, Who 219 is composed of options 220 and value 221, and Weather 222 is composed of options 223 and value 224. The keys for identifying each record are a request ID 211 and a "what" option 212. The request ID 211 is an identifier for uniquely identifying the content of the request, and is similar to the request ID 201. The "what" option 212 indicates the type of work that the requester wants to request 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 location of the work that the requester wants the user to do as the content of the request. "Option 214" is selected by the requester from among the options 243 in the template content table 240, and "Value" 215 is a value registered by the requester for the option 214. "When" 216 indicates the time period when the requester wants the user to do the work as the content of the request. Option 217 is selected by the requester from option 244 in template content table 240, and value 218 is a value registered by the requester for option 217. Who 219 indicates the attributes of the user the requester desires to have work done, as the content of the request. Option 220 is selected by the requester from option 245 in template content table 240, and value 221 is a value registered by the requester for option 220. Weather 222 indicates the environment (weather) under which the requester desires the user to work, as the content of the request. Option 223 is selected by the requester from option 246 in template content table 240, and value 224 is a value registered by the requester for option 223.

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

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 the 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 option for the work content, which is what kind of work the requester wants to request the user to do as the content of the request. The Where option 243 indicates the option for the work location, which is where the requester wants the user to do as the content of the request. The When option 244 indicates the time period when the requester wants the user to work as the content of the request. The Who option 245 indicates the type of user the requester wants to work as the content of the request, and indicates the attributes of that user. The Weather option 246 indicates the environment (weather) under which the requester wants the user to work as the content of the request.

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 must be secured at the minimum when making a request for the content of What, with respect to the cumulative value of the request acceptance level that indicates the degree of the possibility that the user will accept the request. The threshold (degree of condition matching) 254 is a threshold set by the 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 condition matching indicating the degree of matching 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 contents of the What request.

Figures 3A, 3B, and 3C are diagrams showing examples of the task database 122 shown in Figure 1.

The task database 122 stores data showing the relationship between the tasks that have been subdivided when requested from 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).

The task database 122 is composed 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.

The 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. The subtask management table 300 is composed of a subtask ID 301, a request ID 302, and a compensation task ID 303. The key for identifying each record is the subtask ID 301. The subtask ID 301 is an identifier for uniquely identifying a task. This is assigned to each subdivided subtask when a request is subdivided to make it easier to request to a user. The request ID 302 is an identifier for uniquely identifying the contents of the request, and is similar to the request ID 201. This indicates which request the subtask of the subtask ID 301 was subdivided from. The compensation task ID 303 is an identifier for uniquely identifying a compensation task. When a subtask ID 301 is requested of a user, if it is assumed that some of the conditions of the task (Where, When, Who, Weather) will not be acceptable to the user because they do not match the user's behavioral history, the compensation task is used to extract the part of the condition that is assumed to be unacceptable from the subtask ID 301 and request the extracted part as a separate task to another user as compensation.

In the task request destination management table 310 shown in FIG. 3B, when a subtask or a make-up task is requested to a user, the request acceptance level is assumed in advance, and data indicating the degree to which the action range extracted from the user's action history matches the task conditions (Where, When, Who, Weather) is stored. The task request 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 action 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 the 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 to which the user is likely to accept a task request when the user is requested to perform a task. 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 the user is requested to perform a task.

Task content management table 320 shown in FIG. 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. The key for identifying each record is task ID (sub/make-up) 321. The task ID (sub/fill) 321 is an identifier for uniquely identifying a task such as a subtask or a fill task, and is the same as the task ID (sub/fill) 311. The What option 322 indicates the type of work that the requester wants to request the user to do as a task, and the work content. This is selected by the requester from the options 242 in the template content table 240. The Where 323 indicates the location of the work that the requester wants the user to do 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 a value registered by the requester for the option 324. The When 326 indicates the time period when the requester wants the user to do 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 a value registered by the requester for the option 327. Who 329 indicates the attributes of the user who is desired to work on the task. Option 330 is selected by the requester from among options 245 in the template content table 240, and value 232 indicates the value registered by the requester for option 330. Weather 332 indicates the environment (weather) under which the user is desired to work on the task. Option 333 is selected by the requester from among options 246 in the template content table 240, and value 334 is the value registered by the requester for option 333. Note that although values 325, 328, 331, and 334 are described as values registered by the requester, they may also be values reregistered by the task request system 100 based on the values registered by the requester. For example, value 325 may be re-registered as a combination of a starting point and a destination point output from boundary determination information supplementation system 151, such as home-station, station-station, station-bus stop, or bus stop-store. Value 328 may also be re-registered as a time period (morning, afternoon, evening, night, etc.) based on general lifestyle habits. When re-registering a value, a new number is assigned to task ID (sub/supplement) 321, and the values of 322 to 334 other than the value being re-registered are copied to the same values as before the re-registration.

Figures 4A, 4B, and 4C are diagrams showing examples of the user history database 123 shown in Figure 1.

The user history database 123 stores data on the attributes of the user to whom a task is requested, the user's past behavioral history, and the history of task requests to the user.

The user history database 123 is composed 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.

The 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 the user to whom a task is requested. The user attributes 402 are data indicating the attributes of the user, 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.

The user action history table 410 shown in FIG. 4B stores data indicating the user's action history. The user action history table 410 is composed of a user ID 411, date and time 412, location 413, and weather 414. The keys for identifying each record are the user ID 411 and date and time 412. The user ID 411 is an identifier for uniquely identifying the user to whom the task is requested, 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.

The user request history table 420 shown in FIG. 4C stores data indicating the request history to the 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 the user to whom the 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 provided incentive when the task ID (sub/compensation) 422 was requested to the user ID 421 in the past. Acceptance result 425 indicates whether user ID 421 has accepted or rejected task ID (sub/fill) 422 in the past.

Figure 5 shows an example of the request plan execution database 124 shown in Figure 1.

The request plan execution database 124 stores data regarding plans and the results of execution when requesting tasks from users.

The request plan execution database 124 is composed of the request plan execution table 500 shown in FIG. 5.

The request plan execution table 500 shown in FIG. 5 stores data on the plan and the execution result when a task is requested to a user. 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, an incentive provided 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 incentive provided 504 indicates the incentive planned to be provided to the user when the task ID (sub/compensation) 501 is requested from 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 incentive provided 504 at the scheduled request date and time 503.

Below, we explain the concept of the process in the task execution support system shown in Figure 1, from comparing the content of a request with the user's action history and determining who to assign the task to based on the results of the comparison.

Figure 6 is a diagram to explain the concept of the process in the task execution support system shown in Figure 1, from comparing the content of a request with the user's action history and determining who to assign the task to based on the results of the comparison.

Figure 6 shows a request detail 600, a user action history 630, a task image 640, and a task list 650.

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 there is a store Y 605 that Mr. X wants to visit for lunch. Mr. X is also considering traveling between them by stroller along a route 610, and has listed a movement range investigation regarding a weekday lunch meal with a stroller as the request content 620. In response to this, the task request system 100 uses the boundary determination information supplement system 151 to search for a route from Mr. X's house 601 to store Y 605, detects stations 602, 603, and a bus stop 604 between Mr. X's house 601 and store Y 605, and extracts the movement from Mr. X's house 601 to station 602, the movement from station 602 to station 603, the movement from station 603 to bus stop 604, and the movement from bus stop 604 to store Y 605 as the assumed route when traveling from Mr. X's house 601 to store Y 605 by stroller.

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 store Y 605.

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 matches the weather 414 in user action history table 410; and (4) whether the attributes of the requested user indicated in the request match the user attributes 402 in user attribute table 400.

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

The task request system 100 determines this, and assigns A task 1 (641) to investigate behavior in a stroller from X's house 601 to the station 602 in the morning and afternoon on weekdays, B task 2 (642) to investigate behavior in a stroller around the station 602 in the morning and afternoon on weekdays, C task 3 (643) to investigate behavior in a stroller from the station 602 to the station 603 in the morning on weekdays, D task 4 (644) to investigate behavior in a stroller from the station 602 to the station 603 in the afternoon on weekdays, E task 5 (645) to investigate behavior in a stroller from the station 603 to the bus stop 604 and around the bus stop 604 in the morning and afternoon on weekdays, and F task 6 (646) to investigate behavior in a stroller from the bus stop 604 to store Y 605 in the morning and afternoon on weekdays.

These are summarized in a conceptual diagram, which is the task image 640. These are summarized in a list, which is the task list 650. The task list 650 is made up of a task 651, a request destination 652, and request contents 653.

In this way, by determining boundaries for generating compensatory tasks based on location and time of day, subtasks can be generated with appropriate boundaries and can be made to take into account user execution.

In addition, 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 the travel 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 the user's execution.

Figure 7 is a sequence diagram showing the overall process in which the task request system 100 shown in Figure 1 collects user behavior history from user portable terminals 160-1 to 160-3, while a request source 701 registers a request in the task request system 100, the task request system 100 breaks down the request into tasks based on the collected user behavior history and requests them from the user, the user registers the results of the requested tasks in the task request system 100, and the task request system 100 provides the results to the request source.

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

In addition, in process S712, when the user portable terminal device 160-2 provides the behavioral history of user B to the task request system 100, the behavioral history collection unit 111 of the task request system 100 accepts and collects the behavioral history of user B.

In addition, in process S713, when the user portable terminal device 160-3 provides the behavioral history of user C to the task request system 100, the behavioral history collection unit 111 of the task request system 100 accepts the behavioral history of user C.

In addition, in process 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 accepts the requested work.

Then, in process S722, the boundary determination unit 113 and 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, determine the range of compensation tasks 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.

Next, in process S723, the request planning/execution unit 115 of the task request system 100 requests subtasks and make-up tasks from user A of the user portable terminal device 160-1.

In addition, in process S724, the request planning/execution unit 115 of the task request system 100 requests subtasks and make-up tasks from user B of the user portable terminal device 160-2.

In this way, the behavior history collection unit 111 collects information on the behavior history of multiple users. The request reception unit 112 receives the requested work. The boundary determination unit 113 divides the received work into multiple subtasks, and determines the user to whom each divided subtask is to be requested to perform based on the contents of the multiple subtasks and the behavior history of each user, and determines whether or not the subtask is to be compensated based on the contents of the subtask and the behavior history of the user to whom the subtask is requested. The compensation range determination unit 114 determines a part of the subtask that is to be compensated based on the contents of the subtask and the behavior history of the user to whom the subtask is requested, as a compensation task, and determines the user to whom the compensation task is 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/execution unit 115 requests the subtask to the requestee and requests the compensation task to the compensation requestee. This makes it possible to effectively support the execution of work by multiple users.

In response to this, in process S725, user A of the user portable terminal 160-1 replies to the request planning/execution unit 115 of the task request system 100 to accept the task request.

Furthermore, in process S726, user B of user portable terminal device 160-2 replies to the request planning/execution unit 115 of task request system 100 to refuse to accept the task request.

Then, in process S727, the boundary determination unit 113 and compensation range determination unit 114 of the task request system 100 re-determine 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 or not to make the task eligible for compensation. If the task is eligible for compensation, the compensation range is determined again to satisfy the request, a compensation task is added again based on the compensation range, and the user to whom the compensation task is to be requested is determined again. The process here is the process from process S903 onwards in Figure 9 described below, 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, before the subsequent process is performed.

Then, in process S728, the request planning/execution unit 115 of the task request system 100 again requests a compensation task from user C of the user portable terminal device 160-3.

In response to this, in process S729, user C of the user portable terminal device 160-3 replies to the request planning/execution unit 115 of the task request system 100 to accept the task request.

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

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

Then, in process S732, the request planning/execution unit 115 of the task request system 100 provides the task execution results to the request source 701 as the result of the request.

In this way, the request planning/execution unit 115 identifies as rejected tasks subtasks that were not accepted by the requestee or subtasks that were the source of compensation tasks that were not accepted by the compensation request recipient. The boundary determination unit 113 excludes users who did not accept the rejected task and re-determines the request recipient of the rejected task, and determines whether or not to make the rejected task a compensation target. The compensation range determination unit 114 then determines a new compensation task for the rejected task that has become a compensation target, and determines a new user to which the compensation task will be requested to be compensated. This makes it possible to effectively support the execution of work by multiple users.

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 below, the request planning/execution unit 115 may increase the incentive for the user before executing the request or re-request.

Also, 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 repeat request, the incentive to the user may be increased when making a repeat request in process S728 before the repeat request is made. 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 made. Alternatively, in order to increase the frequency of repeat requests and make it easier to find a user who will accept the request, the threshold value (request acceptance level) 253 or threshold value (condition matching level) 254 may be temporarily reset to a lower value when determining the request destination in process S722 or process S727 before the request destination is determined.

Next, in process S722 shown in FIG. 7, the process is described in which the request is broken down into subtasks, and when it is assumed in advance that the subtasks requested from 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 request each of the subtasks and compensation tasks from the user to fulfill the request.

Figure 8 shows the concept of the process of subdividing subtasks and adding supplementary tasks in the task execution support system shown in Figure 1.

The concept of process S722 shown in FIG. 7 is shown as a conceptual diagram 800 as shown in FIG. 8, and the conceptual diagram 800 is composed of a processing overview 801 of process S722 and a processing image 802 of process S722.

Acceptance of registered request (process S721) 810 is, strictly speaking, process S721, which is pre-processing of process S722. In addition, request content 811 indicates the content of the request registered in process S721.

Boundary determination 820 shows a process of determining boundaries in the request content in order to divide the request content 811 into subtasks. Boundaries 821 to 825 are boundaries in the request content determined here. When the request content 811 has a starting point and a destination store, the boundary determination information complementation system 151 may be used to search for the route and extract 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 travel), and the destination itself). Alternatively, the time period for performing the request 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.). Also, if the request content is registered with a distinction between sunny days and rainy days, it may be determined as the boundaries. Also, if the request details are registered based on the attributes of the requesting user (for example, women with children, elderly people, students, etc.), this may be used as a boundary.

Subdivision into subtasks 830 shows the process of subdividing the request content 811 based on boundaries 821-825. Subtasks 831-834 are the subdivided subtasks.

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

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

Next, in this embodiment, in process S722 shown in FIG. 7, a series of processes is described, from breaking down a request into subtasks, to determining the range of task compensation to satisfy the request when it is assumed in advance that the subtasks requested from the user will only be partially accepted, adding compensation tasks based on the compensation range, and requesting each of the subtasks and compensation tasks from the user to realize the request, up to determining the user to whom each task is to be assigned.

Figure 9 is a process flow diagram to explain the overall process in the task execution support system shown in Figure 1, from breaking down requests into subtasks, adding supplementary tasks, to determining the users to whom each task will be assigned.

In process S900, the central control device 130 of the task request system 100 starts the process flow. First, in process 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 the input items What, Where, When, Who, and Weather. The input screen is shown in FIG. 11 (explained later). This process alone corresponds to process S721. The subsequent processes are processes of process S722.

Next, in 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. The What condition is determined by the request source, and the request source registers the work content of what kind of work they want to request the user to do, and determines the boundaries according to the unit of that work. The Where condition indicates where the user is to 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 means of transportation on the route (such as stations, bus stops, and the destination itself) are extracted and determined. The When condition indicates when the user is to 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 as the boundary by extracting the attributes of the user registered by the requester as to what kind of user is desired to perform the work. The Weather condition is determined as the boundary by the weather registered by the requester as to what environment (weather) the user is desired to perform the work in. 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.

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

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 behavior history, and adds the searched users to the request recipient candidates. Here, the determination of whether a user partially satisfies the conditions is made by narrowing down the user IDs 401 in the user behavior 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 with date and time 412 that match the time zone of the subtask, and if the weather is also taken into consideration, further narrowing down by records with weather 414 that match the weather of the subtask, and determining whether the narrowed down records include part of the total length of the subtask's 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 memory device 110.

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 activity 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 temporarily stored in the main memory device 110 in process S904 (what percentage of the total length of the subtask route is included in the rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413), and calculating this proportion as a degree.

Next, in process S906, the boundary determination unit 113 selects from among the request recipient candidates the user with the highest request acceptance degree calculated in process S905. This user is determined to be the request recipient and is excluded from the request recipient candidates.

Next, in process S907, the boundary determination unit 113 reads the condition matching degree (already read 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.

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.

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.

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 degree (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.

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 requested, which represents the percentage of requests that the user has accepted in the past, and adds more users to whom the subtask has been requested until the calculated cumulative value exceeds a predetermined threshold, thereby increasing the possibility that the request will be accepted.

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.

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

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.

Then, in process S913, the central control unit 130 ends the processing flow.

Figure 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 Figure 1.

In process S1000, the boundary determination unit 113 starts the process flow of process S911. First, in process S1001, the compensation range determination unit 114 reads the information related to the degree of condition agreement read in process S905.

Next, in process S1002, the compensation range determination unit 114 extracts the portion of the subtask that does not match the user's attributes or behavior history determined when calculating the degree of condition agreement in process S905. Specifically, among the conditions of the subtask (What, Where, When, Who, Weather), the work content of the subtask is 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 Who, the date and time 412 that matches the time zone of the subtask is Where, and if the weather is also taken into consideration, the weather 414 that matches the weather of the subtask is Weather, and the portion of the total length of the subtask's path 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 Where, and this is extracted as a compensation task.

In this way, the compensation range determination unit 114 can determine an appropriate compensation task by determining, as a compensation task, actions included in a subtask that are not included in the action history of the request recipient.

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

Next, in process S1004, the compensation range determination unit 114 searches for users who completely satisfy the conditions of the compensation task (Where, When, Who, Weather) from the user attributes (Who) and the user's past behavior history, and adds the searched users to the compensation candidate list. Here, the determination of whether a user completely satisfies the conditions is made by narrowing down the user IDs 401 in the user behavior history table 410 with the user IDs 401 of the user attributes 402 that match the user attributes of the compensation task, narrowing down further to records with dates and times 412 that match the time period of the compensation task, and if the weather is also taken into consideration, further narrowing down to records with weather 414 that match the weather of the compensation task, and determining whether the entire length of the route of the compensation task is included in the narrowed down records by determining whether the rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413 is included in the entire length of the route of the compensation task.

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

Next, in process S1006, the compensation range determination unit 114 selects the user with the highest request acceptance level reacquired in process S1005 from among the compensation recipient candidates. This user is determined to be the compensation recipient and is excluded from the compensation recipient candidates.

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 subject to compensation 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.

In process S1008, the compensation range determination unit 114 determines whether there are any other users remaining as compensation candidates. If there are, the process returns to process S1006; if there are no remaining users, the process proceeds to process S1009.

In process S1009, the compensation range determination unit 114 searches for users who partially satisfy the conditions of the compensation task (Where, When, Who, Weather) from the user attributes (Who) and the user's past behavior history, and adds the searched users to the compensation destination candidates. Here, the determination of whether a user partially satisfies the conditions is made by narrowing down the user IDs 401 in the user behavior history table 410 with the user IDs 401 of the user attributes 402 that match the user attributes of the compensation task, narrowing down further to records with dates and times 412 that match the time period of the compensation task, and if the weather is also taken into consideration, further narrowing down to records with weather 414 that match the weather of the compensation task, and determining whether 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 they do, the percentage of the total length is temporarily stored in the main memory device 110.

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 temporarily stored in the main memory device 110 in process S1009 (what percentage of the total length of the subtask path is included in the rectangle connecting the four corners of the most extreme points of the latitude and longitude of the location 413), and calculating this proportion as a degree.

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.

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.

In process S1013, the compensation range determination unit 114 determines that the compensation task does not have sufficient condition matching (Where, When, Who, Weather) with respect to the subtasks, adds the compensation task to the attention cases, and proceeds to process S1014.

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. The request acceptance degree process of this subtask used in process S1007 (for the pair of subtask and user determined to be subject to compensation 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.

In process S1015, the compensation range determination unit 114 determines whether other compensation tasks remain. If so, the process proceeds to process S1003. If not, the process proceeds to process S1016.

Then, in process S1016, the boundary determination unit 113 ends the processing flow of process S911.

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 possibility that the request for the compensation task will be accepted and the possibility that the original subtask will be executed.

Next, we will explain the 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.

Figure 11 shows 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.

As shown in FIG. 11, an example of a request registration screen that is output to the input/output device 132 in process S901 of FIG. 9 and that accepts input of a request from the request source is a request registration screen 1100 that is composed of a template 1101, a request registration button 1102, and request content 1110.

Template 1101 shows a template selection field for registering requests, 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 contents of a request, and is a button for registering the contents of a request after inputting the specific contents of a request in request contents 1110 for the template selected in template 1101. Request contents 1110 is an area for registering the specific contents of a request, and the display contents may be changed depending on the template selected in template 1101. Here, an example is shown in which a survey template is selected. Request contents 1110 are composed of a What input field 1111, What selection 1112, a What item registration button 1113, and conditions 1120.

The What input field 1111 is a field for inputting a specific value for the What option selected in What selection 1112. The What selection 1112 is a field for selecting the work content to be requested as What from the client. Here, an example is shown in which "Meals 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 conditions of Where, When, Who, and Weather, after they have been entered in conditions 1120, as specific values of the request.

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

Where input field 1121 is a field for inputting a specific value for the Where option selected in Where selection 1122. Where selection 1122 is a field for selecting the location of the work to be requested of the client as Where. Here is an example in which the departure point and arrival point are selected for "Meals in a stroller" 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 Where input field 1121.

The When input field 1123 is a field for inputting a specific value for the When option selected in When selection 1124. When selection 1124 is a field for selecting the time period for the work to be requested of the client as When. Here, an example is shown in which the time period and weekday/weekend/holiday are selected for "eating with a stroller" in the activity range survey template, and the time period and weekday/weekend/holiday are entered in the When input field 1123.

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

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 used when making a request to the requesting party. Here, an example is shown in which rain has been selected for "eating in a stroller" in the What in the activity range survey template, and nothing has been entered in the Weather input field 1127.

Next, we will explain the screen showing the request execution results that is output to the input/output device 132 in process S732 of Figure 7.

Figure 12 shows an example of a screen showing the request execution results output to the input/output device 132 in process S732 of Figure 7.

The request execution result provision screen output to the input/output device 132 in process S732 of FIG. 7 is, as shown in FIG. 12, a request execution result provision screen 1200 for consolidating the results of execution by each user in relation to a request from the request source and providing the request source with the result, and is displayed on the input/output device 132 of the task request system 100.

The screen 1200 showing the request execution result shown in FIG. 12 is composed of the travel route to store Y 605 that X wants to visit for lunch (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), difficult-to-travel points (difficult-to-travel points 1215, difficult-to-travel points 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 requester as a recommended travel route because the reason for the difficulty of travel was not found in the user's survey. In contrast, the difficult-to-travel points are information for the requester to decide whether to pass through, since some users have stated the reason for the difficulty of travel. Here, investigation result 1220 corresponds to difficult-to-move location 1215, and investigation result 1230 corresponds to difficult-to-move location 1216. Investigation result 1220 is composed of negative opinions 1221 and results 1222, where negative opinions 1221 indicate the number of users who consider it difficult to move, and results 1222 indicate investigation results when users judge it difficult to move. Results 1222 may include an image of the investigation result. Similarly, investigation result 1230 is composed of negative opinions 1231, results 1232, and results 1233, where negative opinions 1231 indicate the number of users who consider it difficult to move, and results 1232 and 1233 indicate investigation results when users judge it difficult to move.

(Other embodiments)

Figure 13 is a process flow diagram to explain another example of the overall process in the task execution support system shown in Figure 1, from breaking down a request into subtasks, adding supplementary tasks, to determining the user to whom each task will be assigned. This example shows a method of gradually reducing the number of candidates to whom the task will be assigned.

When the central control device 130 of the task request system 100 starts the processing flow in process S1300, first, in process S1301, the request receiving unit 112 receives the request content from the request source via the input/output device 132, similar to process S901.

Next, in process S1302, similar to process S902, the boundary determination unit 113 determines boundaries within 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.

Next, in process S1303, similar to process S903, the boundary determination unit 113 selects an arbitrary subtask.

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 behavior history, and adds the searched users to the list of request recipient candidates.

Next, in process S1305, similar to process S905, the boundary determination unit 113 calculates the request acceptance degree and the degree of match between the user's range of activity and the subtask for all users who are candidate request recipients extracted in process S1304.

Next, in process S1306, the boundary determination unit 113 selects from among the request recipient candidates the user with the lowest degree of match calculated in process S1305.

Next, in process S1307, the boundary determination unit 113 calculates the cumulative value of the request acceptance level for this subtask if the selected user is hypothetically 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, proceed to process S1309, and if it is greater than the threshold, proceed to process S1308.

In process S1308, the boundary determination unit 113 excludes this user from the candidates to which the subtask may be requested, and the process proceeds to process S1310.

In process S1309, the boundary determination unit 113 does not exclude the user, but adds the user to the required user list for this subtask, and proceeds to process S1310.

In process S1310, the boundary determination unit 113 determines whether the candidate request recipients for this subtask match the required user list. If they match, the process proceeds to process S1311; if they do not match, the process returns to process S1306.

In process S1311, the boundary determination unit 113 requests all users in the required user list for this subtask.

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.

Then, in process S1313, the central control unit 130 ends the processing flow.

Figure 14 is a diagram for explaining the concept of another example of the process in the task execution support system shown in Figure 1, in which the content of a request is compared with the user's action history, and a destination for the task is determined based on the results of the comparison.

Figure 14 shows request details 1400, user action history 1430, task image 1440, and task list 1450.

Request details 1400 shows a conceptual diagram of a request for graffiti prevention registered by the 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 also include patrols 1420 of the area 1401, priority patrols 1421 for graffiti that will be discovered later, graffiti removal 1422 for graffiti that will be discovered, and prevention of recurrence of graffiti that will be discovered 1423.

On the other hand, as shown in user behavior history 1430, from the locations and dates and times of the past user behavior history, in area 1401, 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 addition, from the user attributes, the F group of Fa, Fb, and Fc, who have the attribute of graffiti removal, and E and G, who have the attribute of recurrence prevention activities, are extracted as highly specialized people engaged in graffiti prevention activities in the area.

Here, the task request system 100 divides the area 1401 into areas in charge of multiple users. For example, the action history 1431 of Mr. A, the action history 1432 of Mr. B, the action history 1433 of Mr. C, and the action history 1434 of Mr. 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 Mr. A, Mr. B, Mr. C, and Mr. D, and assigns task 1-1 (1441) to Mr. A, task 1-2 (1442) to Mr. B, task 1-3 (1443) to Mr. C, and task 1-4 (1444) to Mr. D. All of these tasks are patrol tasks.

The task request system 100 also 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 locations (latitude, longitude) in 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.

F-group consisting of Fa, Fb, and Fc is extracted from user attribute 402 in user attribute table 400 as people who are specialized in graffiti prevention activities in this area. Since Fa, Fb, and Fc have the attributes of graffiti removal users, task 3 of graffiti removal is assigned to them.

Furthermore, Mr. E and Mr. G are extracted from user attribute 402 in user attribute table 400 as people who are specialized in graffiti prevention activities in this area. 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.

These are summarized in a conceptual diagram, which is the task image 1440. These are summarized in a list, which is the task list 1450. The task list 1450 is made up of a task 1451, a request destination 1452, and request content 1453.

Figure 15 is a diagram for explaining the concept of another example of the process in the task execution support system shown in Figure 1, in which the content of a request is compared with the user's action history, and a destination to which the task is to be assigned is determined based on the results of the comparison.

Figure 15 shows request details 1500, user action history 1530, task image 1540, and task list 1550.

Request details 1500 shows a conceptual diagram of a request for ride sharing registered by a requester. There is a home 1501 of the requester, Mr. X, and a store 1502 that Mr. X would like to visit for shopping. In addition, Mr. X is considering traveling by car along route 1510 between the two locations, and lists a request 1520 for someone to drive and share the ride.

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), A's behavior history 1531, B's behavior history 1532, and C's behavior history 1533 are extracted as the behavior range near route 1510.

The next step is to determine whether the area is within the vicinity of the expected route based on the following factors:

(1) Does the route fall within a rectangle connecting the four corners of the locations (latitude, longitude) in the past behavior history (locations 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?

The task request system 100 determines this and assigns A a ride-sharing trip from X's house 1501 to store Y 1505 as task 1-1 (1541). Also, B and C are each assigned a ride-sharing trip from store Y 1505 to X's house 1501 as task 1-2 (1542).

These are summarized in a conceptual diagram, which is the task image 1540. These are summarized in a list, which is the task list 1550. The task list 1550 is made up of tasks 1551, request destinations 1552, and request contents 1553.

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 (5)

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 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, 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 the requestee by transmitting information requesting the subtask to the terminal device of the user who is 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 who 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. 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 . 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 . 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 . 1. A task execution support method for supporting 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