JP7675331B2 - Management system and management method - Google Patents

Description

The present invention relates to a management system and a management method for managing grid computing implemented in multiple computing devices installed in multiple vehicles.

Technology for applying multiple vehicles to grid computing has been proposed in the past (see, for example, Patent Document 1). The system described in Patent Document 1 is composed of a management server connected to a communication network and a computing device mounted on multiple vehicles. In this system, the management server distributes job data (computation jobs) to the multiple computing devices via the communication network and performs computation processing, thereby realizing grid computing.

The computing device can provide stable quality computing power when the vehicle is in an inoperative state (e.g., the ignition is off or the vehicle power is off). For this reason, the management server in Patent Document 1 predicts the period during which each vehicle can participate in grid computing based on the usage history of each vehicle. Then, based on this prediction, the management server selects a computing device suitable for distributing job data. In other words, the management server selects a computing device of a vehicle that is likely to be in an inoperative state throughout the computation period during which the job data is executed.

JP 2020-160661 A

However, when implementing grid computing using multiple computing devices installed in multiple non-operating vehicles, it is considered desirable for these vehicles to be located in close proximity to each other for the following reasons.

When multiple vehicles equipped with computing devices are gathered in close proximity, vehicle-to-vehicle communication can be performed during grid computing, allowing computation data to be properly transferred between the multiple computing devices. In addition, gathering multiple vehicles in close proximity in this way makes it possible to standardize the communication environment with the management server among the multiple computing devices. Furthermore, gathering multiple vehicles in close proximity and forming a vehicle group at a specific location with the multiple vehicles is effective for running multiple computing devices simultaneously for a relatively long period of time. Running multiple computing devices simultaneously in this way makes it possible to efficiently perform, for example, distributed computing (a calculation method in which individual parts of a program are executed simultaneously on multiple computing devices, and processing proceeds as a whole while each of them communicates with each other via a network).

From the above, it is believed that by gathering multiple vehicles equipped with computing devices in a short distance to perform grid computing, it is possible to effectively secure stable and highly reliable computing resources (computing capacity of the computing device) for grid computing. However, the system described in the above-mentioned Patent Document 1 was not able to gather multiple vehicles in a short distance to perform grid computing.

On the other hand, when gathering multiple vehicles in a short distance for grid computing as described above, using the parking area of a designated commercial facility (e.g., supermarket, shopping mall, stadium, theater, restaurant, accommodation facility, movie theater, store, etc.) is thought to contribute to the operation of the facility. For example, by gathering multiple vehicles in a short distance in the parking area of a facility, congestion in the parking area can be alleviated by managing (controlling) the parking positions of each vehicle. In addition, prior to managing the parking positions in this way, information such as the length of time visitors stay at the facility and the number of visitors can be obtained and this information can be used in the operation of the facility.

The present invention has been made to solve the above-mentioned problems, and aims to provide a management system and method that can secure highly reliable computing resources and contribute to the operation of a designated commercial facility by gathering multiple vehicles equipped with computing devices in close proximity in a parking area of the designated facility to perform grid computing.

In order to achieve the above object, the present invention provides a management system for managing grid computing that causes multiple arithmetic units mounted on multiple vehicles to process job data, the management system comprising: a storage device that stores information on multiple arithmetic units and/or multiple vehicles mounted with arithmetic units; and a control device configured to realize grid computing by distributing job data to each of the multiple arithmetic units and having them process the job data based on the information stored in the storage device. The control device is configured to obtain the planned stay time of a user of a vehicle mounted with a arithmetic unit in a specified commercial facility having a parking area, set a group consisting of multiple users whose planned stay time overlaps based on the planned stay time of the multiple users, set designated parking positions where each of the multiple vehicles should be parked in the parking area so that multiple vehicles of multiple users belonging to the same group are located within a range in the parking area where vehicle-to-vehicle communication is possible, transmit the designated parking positions to each user of the multiple vehicles, and realize grid computing by having the arithmetic units mounted on each of the multiple vehicles process the job data when the multiple vehicles park in the parking area in response to the transmission of the designated parking positions.

In the present invention thus configured, the management system sets groups of multiple users whose planned stay times overlap based on the planned stay times at a specified facility acquired from multiple users, and sets designated parking positions for each vehicle so that multiple vehicles belonging to the same group are located within a range in the parking area where vehicle-to-vehicle communication is possible (for example, within 50 m). In this way, grid computing is realized by the computing devices mounted on the vehicles when multiple vehicles whose planned stay times at a specified facility overlap are parked within a range in the parking area where vehicle-to-vehicle communication is possible.
As a result, vehicle-to-vehicle communication can be performed during grid computing, and computation data can be appropriately transferred between multiple computation devices. In addition, the communication environment with the management system can be standardized among the multiple computation devices, allowing job data and the like to be appropriately transferred. Furthermore, by forming a vehicle group in a parking area of a specified facility using multiple vehicles, multiple computation devices can be operated simultaneously for a relatively long period of time. This makes it possible to appropriately realize, for example, distributed computing in grid computing. As described above, according to the present invention, when performing grid computing using multiple computation devices mounted on multiple vehicles that are not in operation, stable and highly reliable computation resources can be effectively secured.

In addition, according to the present invention, by gathering multiple vehicles in a short distance (within a range where vehicle-to-vehicle communication is possible) in a parking area of a specified facility for grid computing, it is possible to contribute to the operation of the facility. For example, by managing (controlling) the parking positions of each vehicle in order to gather multiple vehicles in a short distance in a parking area, congestion in the parking area can be alleviated. Furthermore, by grasping information such as the length of time visitors (users) stay at the facility and the number of visitors before managing the parking positions in this way, this information can be used for the operation of the facility and management of the parking area.

In the present invention, the control device is preferably configured to set a designated parking position so that multiple vehicles belonging to the same group are located within a range where vehicle-to-vehicle communication is possible in the parking area, and multiple vehicles belonging to multiple groups are located adjacent to each other in the parking area.
According to the present invention configured in this manner, a group of vehicles in which each vehicle is positioned close to each other can be formed in a parking area, thereby making it possible to obtain advertising effects from the group of vehicles formed for grid computing.

In the present invention, the control device is preferably configured to determine the planned exit time at which a user will leave a specified facility from the planned stay time, and to set up a group by giving priority to users with similar planned exit times among multiple users whose planned stay times overlap.
According to the present invention configured in this manner, the time during which a vehicle convoy is formed by multiple vehicles from each group can be extended, making it possible to more effectively secure highly reliable computational resources for grid computing.

In the present invention, the control device is preferably configured to give priority to users with upcoming scheduled exit times and set groups in order according to the scheduled exit times, and to set designated parking positions for multiple vehicles belonging to a certain group so that one or more of the designated parking positions set for multiple vehicles belonging to the previous group are located adjacent to one or more of the parking positions of multiple vehicles belonging to the previous group that has an earlier scheduled exit time than the group.
According to the present invention configured in this manner, the time during which a vehicle group is formed by a plurality of vehicles can be extended.

In the present invention, the control device is preferably configured to acquire a planned stay time transmitted from a user of a vehicle in which the computing device is mounted.
According to the present invention thus configured, by using the expected stay time designated by the user himself, it is possible to carry out processing based on the expected stay time thereafter with high accuracy.

In the present invention, the control device is preferably configured to, when the vehicle of the user to whom the designated parking position was transmitted is not parked in the designated parking position, transmit the designated parking position to the user of the other vehicle belonging to the same group as the vehicle so that the other vehicle is parked in the designated parking position.
According to the present invention configured in this manner, even if a vehicle is not parked in a designated parking position, a vehicle group can be appropriately formed in a parking area with multiple vehicles that have overlapping planned stay times.

In the present invention, preferably, when multiple vehicles are not parked in the same designated parking position, the control device excludes this parking position from the designated parking positions set for parking vehicles in the parking area.
According to the present invention configured in this manner, if a vehicle is not parked continuously at a designated parking position due to an obstacle (such as garbage or a person) present at the parking position or damage to the parking spot, such a parking position can be appropriately excluded from the targets for setting a designated parking position.

In another aspect, in order to achieve the above-mentioned object, the present invention provides a management method for managing grid computing, in which job data is processed by a plurality of arithmetic devices mounted on a plurality of vehicles, by a computer, the management method comprising: a storage step for storing information about the plurality of arithmetic devices and/or the plurality of vehicles mounted with the arithmetic devices; and a control step for distributing job data to each of the plurality of arithmetic devices and having the job data processed based on the information stored in the storage step, thereby realizing grid computing, wherein the control step comprises: a step for acquiring a planned stay time for a user of a vehicle mounted with the arithmetic device to stay in a predetermined commercial facility having a parking area; a step for setting a group consisting of a plurality of users whose planned stay times overlap based on the planned stay times of the plurality of users; a step for setting designated parking positions where each of the plurality of vehicles should be parked in the parking area so that multiple vehicles of multiple users belonging to the same group are located within a range in the parking area where vehicle-to-vehicle communication is possible, and a step for transmitting the designated parking positions to each user of the plurality of vehicles; and a step for realizing grid computing, when the plurality of vehicles are parked in the parking area in response to the transmission of the designated parking positions, by having the arithmetic devices mounted on each of the plurality of vehicles process the job data.
With the present invention configured in this manner, when performing grid computing using multiple computing devices installed in multiple vehicles that are not in operation, it is possible to effectively secure stable and highly reliable computational resources, and to contribute to the operation of specified facilities, etc.

The management system and management method according to the present invention allows multiple vehicles equipped with computing devices to be gathered in close proximity in a parking area of a designated commercial facility to perform grid computing, thereby securing highly reliable computing resources and contributing to the operation of the designated facility.

1 is a schematic diagram showing a configuration of a system according to an embodiment of the present invention. FIG. 1 is a conceptual diagram for explaining grid computing according to an embodiment of the present invention. 1 is a block diagram showing a configuration of a vehicle according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a user terminal according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a client server according to an embodiment of the present invention. 2 is a block diagram showing a configuration of a facility server according to an embodiment of the present invention. FIG. 2 is a block diagram showing a configuration of a management server according to an embodiment of the present invention. FIG. 5 is a flowchart showing a job reception process according to an embodiment of the present invention. FIG. 4 is a schematic diagram showing an image of a job reception screen according to an embodiment of the present invention. 4 is a flowchart showing a parking position designation process according to an embodiment of the present invention. 13 shows an example of an input screen for planned stay time according to an embodiment of the present invention. 1 is a table illustrating an example of group organization and assignment of designated parking positions according to an embodiment of the present invention. 1 illustrates an example of a parking layout according to an embodiment of the present invention. 13 shows an example of a designated parking position notification screen according to an embodiment of the present invention. 4 is a flowchart illustrating a grid computing process according to an embodiment of the present invention.

The following describes a management system and a management method according to an embodiment of the present invention with reference to the attached drawings.

[system]
1 illustrates an example of the configuration of a system 1 according to the present embodiment. The system 1 includes a plurality of vehicles 10, a plurality of user terminals 20, a client server 30, a facility server 40, and a management server 50. These components are capable of communicating with each other via a communication network 5. Each of the plurality of vehicles 10 is equipped with a computing device 105. Note that the system 1 may be provided with a plurality of client servers 30. Similarly, the system 1 may be provided with a plurality of facility servers 40.
The system 1 corresponds to an example of a "management system" in the present invention. In particular, in this embodiment, the facility server 40 and the management server 50 function as the "management system" in the present invention, and are entities that execute the "management method" in the present invention.

As shown in FIG. 2, in the system 1 of this embodiment, grid computing is configured with a plurality of computing devices 105, and grid computing processing is performed in which an available computing device 105 among the plurality of computing devices 105 processes job data.

When the vehicle 10 requires the computing power of the arithmetic device 105, the arithmetic device 105 enters an operating state, and the computing power of the arithmetic device 105 is used. For example, when the vehicle 10 is traveling, the computing power of the arithmetic device 105 is required for the traveling control of the vehicle 10, and the arithmetic device 105 enters an operating state.

On the other hand, when the computing power of the arithmetic device 105 is no longer needed in the vehicle 10, the arithmetic device 105 is stopped, and the computing power of the arithmetic device 105 is no longer used. For example, when the vehicle 10 is stopped and the power supply of the vehicle 10 is turned off, the computing power of the arithmetic device 105 is no longer needed, and the arithmetic device 105 is stopped.

Here, when the computing power of the computing device 105 is not required in the vehicle 10, the computing power of the computing device 105 can be provided for grid computing processing, thereby making it possible to effectively utilize the computing power of the computing device 105.

[vehicle]
The vehicle 10 is owned by a user. The user drives the vehicle 10. In this example, the vehicle 10 is a four-wheeled automobile. The vehicle 10 is also equipped with a battery (not shown). Power from the battery is supplied to on-board devices such as the computing device 105. Examples of such a vehicle 10 include an electric vehicle and a plug-in hybrid vehicle.

As shown in FIG. 3, the vehicle 10 includes an actuator 11, a sensor 12, an input unit 101, an output unit 102, a communication unit 103, a memory unit 104, a computing device 105, and a lighting device 110.

The actuator 11 includes a drive system actuator, a steering system actuator, a braking system actuator, etc. Examples of drive system actuators include an engine, a transmission, and a motor. An example of a braking system actuator is a brake. An example of a steering system actuator is a steering wheel.

The sensor 12 acquires various types of information used to control the vehicle 10. Examples of the sensor 12 include an exterior camera that captures images outside the vehicle, an interior camera that captures images inside the vehicle, a radar that detects objects outside the vehicle, a vehicle speed sensor, an acceleration sensor, a yaw rate sensor, an accelerator opening sensor, a steering sensor, and a brake oil pressure sensor.

The input unit 101 inputs information and data. Examples of the input unit 101 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button or a touch sensor of a car navigation device. The information and data input to the input unit 101 are sent to the calculation device 105. For example, in this embodiment, the input unit 101 accepts instructions from a user to provide the computing power of the calculation device 105 of the vehicle 10 for grid computing processing.

The output unit 102 outputs information and data. Examples of the output unit 102 include a display unit that outputs an image showing information, and a speaker that outputs sound showing information. An example of a display unit is the display of a car navigation device. An example of a speaker is the speaker of a car navigation device.

The communication unit 103 transmits and receives information and data. Information and data received by the communication unit 103 is sent to the calculation device 105. The lighting device 110 has exterior lamps (headlights, tail lights, brake lights, turn signals, etc.), room lamps, etc.

As described above, the computing device 105 provides its computing power to grid computing processing. Specifically, the computing device 105 processes distributed job data so as to realize grid computing. The computing device 105 is a computer having a processor, memory, etc. Examples of a processor include a CPU (Central Processing Unit), an MPU (Media Processing Unit), and a GPU (Graphics Processing Unit). The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The number of processors mounted on the arithmetic device 105 may be one or more. The processor mounted on the arithmetic device 105 may be only one of the MPU, CPU, and GPU, or may be two or more of the MPU, CPU, and GPU. In one example, the arithmetic device 105 is configured with one or more ECUs (Electronic Control Units) and controls each part of the vehicle 10. In this example, the arithmetic device 105 controls the actuator 11 and the lighting device 110 in response to various information obtained by the sensor 12, in addition to processing job data for the above-mentioned grid computing. In another example, the arithmetic device 105 may be a computer different from such an ECU (i.e., separate from the ECU). In this example, the arithmetic device 105 mainly processes job data for grid computing without controlling each part of the vehicle 10.

The storage unit 104 stores information and data. In this example, the storage unit 104 stores vehicle information D11, vehicle state information D12, driving history information D13, computing device information D14, and operation history information D15.

Vehicle information D11 is information related to vehicle 10. For example, vehicle information D11 includes a vehicle ID set for vehicle 10, vehicle performance information indicating the performance of the vehicle, and the address registered for vehicle 10. The vehicle ID is an example of vehicle identification information that identifies vehicle 10. The user ID is an example of user identification information that identifies a user.

The vehicle status information D12 indicates the status of the vehicle 10. For example, the vehicle status information D12 includes vehicle position information, vehicle communication information, vehicle power information, vehicle battery remaining information, vehicle charging information, and the like. The vehicle position information indicates the position (latitude and longitude) of the vehicle 10. For example, the vehicle position information can be acquired by a GPS (Global Positioning System). The vehicle communication information indicates the communication state of the vehicle 10. The vehicle power information indicates the state of the power supply of the vehicle 10. For example, the vehicle power information indicates whether the ignition power supply is on or off, whether the accessory power supply is on or off, and the like. The vehicle battery remaining information indicates the remaining charge of a battery (not shown) installed in the vehicle 10. The vehicle charging information indicates whether the vehicle 10 is being charged in a charging facility (not shown).

The driving history information D13 is information that indicates the driving history of the vehicle 10. For example, the driving history information D13 indicates the position of the vehicle 10 in association with the time. The driving history information D13 may also include information such as the guide route and destination set in the navigation (route guidance) of the vehicle 10.

The arithmetic device information D14 is information related to the arithmetic device 105. For example, the arithmetic device information D14 includes an arithmetic device ID set in the arithmetic device 105, a vehicle ID set in the vehicle 10 in which the arithmetic device 105 is mounted, arithmetic device performance information indicating the performance of the arithmetic device 105, and the like. The arithmetic device ID is an example of arithmetic device identification information for identifying the arithmetic device 105. The performance of the arithmetic device 105 indicated in the arithmetic device performance information includes a computing capacity indicating the computing capacity (specifically, the maximum computing capacity) of the arithmetic device 105, the ratio of the CPU and GPU in the arithmetic device 105, and the like. The computing capacity of the arithmetic device 105 is the amount of data that the arithmetic device 105 can calculate per unit time.

The operation history information D15 is information that indicates the operation history of the computing device 105. For example, the operation history information D15 indicates the utilization rate of the computing capacity of the computing device 105 in association with time.

[User terminal]
The user terminal 20 is owned by a user. The user operates the user terminal 20 to use various functions. The user can also carry the user terminal 20. Examples of such user terminals 20 include smartphones, tablets, and notebook personal computers.

As shown in FIG. 4, the user terminal 20 includes an input unit 201, an output unit 202, a communication unit 203, a memory unit 204, and a control unit 205.

The input unit 201 inputs information and data. Examples of the input unit 201 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button and a touch sensor. The information input to the input unit 201 is sent to the arithmetic device 105. For example, in this embodiment, the input unit 201 accepts instructions from a user to provide the computing power of the arithmetic device 105 of the vehicle 10 for grid computing processing.

The output unit 202 outputs information and data. Examples of the output unit 202 include a display unit that outputs an image representing information, and a speaker that outputs sound representing information. The communication unit 203 transmits and receives information and data. Information and data received by the communication unit 303 are sent to the control unit 205.

The control unit 205 controls each part of the user terminal 20. The control unit 205 has a processor, a memory, etc. The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The storage unit 204 stores information and data. In this example, the storage unit 204 stores terminal information D21, terminal status information D22, and schedule information D23.

The terminal information D21 is information related to the user terminal 20. For example, the terminal information D21 includes a user terminal ID set in the user terminal 20, user terminal performance information indicating the performance of the user terminal 20, and the like. The user terminal ID is an example of user terminal identification information that identifies the user terminal 20.

The terminal status information D22 is information indicating the status of the user terminal 20. The terminal status information D22 includes user terminal position information indicating the position of the user terminal 20, user terminal communication status information indicating the communication status of the user terminal 20, etc.

Schedule information D23 indicates the behavior history and planned behavior of the user who owns the user terminal 20. For example, schedule information D23 indicates the user's location in association with the period of stay (or planned period of stay). Note that schedule information D23 can be acquired by a schedule function installed in the user terminal 20. Specifically, when a user uses the schedule function to input his or her own behavior history and planned behavior into the user terminal 20, schedule information D23 indicating the user's behavior history and planned behavior is obtained.

[Client Server]
The client server 30 is owned by a client. The client requests the calculation of job data. Examples of such clients include companies, research institutes, and educational institutions.

As shown in FIG. 5, the client server 30 includes an input unit 301, an output unit 302, a communication unit 303, a memory unit 304, and a control unit 305.

The input unit 301 inputs information and data. Examples of the input unit 301 include an operation unit that is operated to input information corresponding to the operation, a camera that inputs an image showing information, and a microphone that inputs sound showing information. Examples of the operation unit include an operation button, a touch sensor, a keyboard, and a mouse. The information and data input to the input unit 301 is sent to the control unit 305.

The output unit 302 outputs information and data. Examples of the output unit 302 include a display unit that outputs an image representing information, and a speaker that outputs sound representing information. The communication unit 303 transmits and receives information and data. The information and data received by the communication unit 303 are sent to the control unit 305.

The control unit 305 controls each part of the client server 30. The control unit 305 has a processor, a memory, etc. The memory stores programs for operating the processor, information and data indicating the processing results of the processor, etc.

The storage unit 304 stores information and data. In this example, the storage unit 304 stores client information D31 and job data D1.

Client information D31 is information about a client. Client information D31 includes a client ID set for the client, a client server ID set for the client server 30 owned by the client, a person in charge's name, address, telephone number, etc. The client ID is an example of client identification information that identifies the client. The client server ID is an example of client server identification information that identifies the client server 30.

Job data D1 is data corresponding to a job, and is data that is processed to execute the job. Job data D1 can be classified by calculation type. Examples of calculation types include CPU-based calculation type and GPU-based calculation type. Job data D1 of CPU-based calculation type tends to require complex calculations with many conditional branches, such as simulation calculations. Job data D1 of GPU-based calculation type tends to require a huge amount of simple calculations, such as image processing and machine learning.

Job data D1 can also be classified according to processing conditions. Examples of processing conditions include processing conditions that require constant communication and processing conditions that do not require constant communication. Job data D1 with processing conditions that require constant communication requires that the computing device 105 is always able to communicate in grid computing processing. Job data D1 with processing conditions that do not require constant communication does not require that the computing device 105 is always able to communicate in grid computing processing.

The storage unit 304 may store job information related to a job. The job information includes job name information indicating the name of the job, job content information explaining the content of the job, job data information related to the job data corresponding to the job, job delivery date information indicating the delivery date of the job, etc. The job data information indicates the calculation type, processing conditions, required calculation capacity, etc. of the job data.

[Facility server]
The facility server 40 is owned by a facility that the user visits. Examples of such facilities include supermarkets, shopping malls, stadiums, theaters, restaurants, accommodation facilities, movie theaters, retail stores, etc. The user may be allowed to make a reservation to visit the facility.

As shown in FIG. 6, the facility server 40 includes an input unit 401, an output unit 402, a communication unit 403, a memory unit 404, and a control unit 405. The configurations of the input unit 401, output unit 402, communication unit 403, memory unit 404, and control unit 405 of the facility server 40 are similar to the configurations of the input unit 301, output unit 302, communication unit 303, memory unit 304, and control unit 305 of the client server 30.

In this example, the storage unit 404 stores facility information D41 and facility usage information D42. The facility information D41 is information related to the facility. The facility information D41 includes a facility ID set for the facility, a facility server ID set for the facility server 40 owned by the facility, facility location information indicating the location (latitude and longitude) of the facility, information on the company that operates (or manages) the facility, the name of the person in charge, an address, a telephone number, and the like. The facility ID is an example of facility identification information that identifies the facility. The facility server ID is an example of facility server identification information that identifies the facility server 40. In addition, in this embodiment, the facility information D41 also includes parking position information related to multiple parking positions in a parking area provided in the facility. This parking position information includes a map (defined by latitude and longitude, for example) indicating the multiple parking positions, parking numbers assigned to each of the multiple parking positions, and the like. Note that the multiple parking positions are defined in a predetermined area in a parking area that is prepared in advance for parking the vehicle 10 that realizes grid computing, for example.

Facility usage information D42 indicates the usage status (usage history and planned usage) of the facility. In this embodiment, facility usage information D42 is information that indicates the user (specifically, the user ID) visiting the facility in association with the user's planned stay information at the facility. This planned stay information includes the date of visit to the facility, the time of entry, the planned duration of stay, the planned time of leaving, etc.

[Administration Server]
The management server 50 manages the operation of the system 1 in which grid computing is implemented. The management server 50 is owned by the operator who operates the system 1.

7, the management server 50 includes an input unit 501, an output unit 502, a communication unit 503, a storage unit 504, and a control unit 505. The configurations of the input unit 501, the output unit 502, the communication unit 503, the storage unit 504, and the control unit 505 of the management server 50 are the same as the configurations of the input unit 301, the output unit 302, the communication unit 303, the storage unit 304, and the control unit 305 of the client server 30.
In addition, the memory unit 504 of the management server 50, together with the memory unit 404 of the facility server 40 described above, functions as an example of a "memory device" in the present invention, and the control unit 505 of the management server 50, together with the control unit 405 of the facility server 40 described above, functions as an example of a "control device" in the present invention.

In this example, the memory unit 504 stores a user table D51, a calculation device table D52, a client table D53, a job table D54, a resource table D55, a matching table D56, job data D1, and calculation result data D2.

The user table D51 is a table for managing users. For each user, the user table D51 registers a user ID set for that user, a vehicle ID set for the vehicle 10 owned by that user, a computing device ID set for the computing device 105 owned by that user, a user terminal ID set for the user terminal 20 owned by that user, and the like.

The arithmetic device table D52 is a table for managing the arithmetic devices 105. In the arithmetic device table D52, for each arithmetic device 105, a arithmetic device ID set in that arithmetic device 105, a user ID set for the user who owns that arithmetic device 105, a vehicle ID set in the vehicle 10 in which that arithmetic device 105 is installed, etc. are registered.

The arithmetic unit table D52 also registers, for each arithmetic unit 105, the performance of that arithmetic unit 105 (such as computing capacity and the ratio of CPU to GPU), the operating status of that arithmetic unit 105 (operating history and operating schedule), and the like. In other words, the arithmetic unit table D52 includes operating status information D5 indicating the operating status of each of the multiple arithmetic units 105, and performance information D6 indicating the performance of each of the multiple arithmetic units 105. The performance information D6 includes computing capacity information D7 indicating the computing capacity of each of the multiple arithmetic units 105.

The client table D53 is a table for managing clients. For each client, the client table D53 registers the client ID set for that client, the client server ID set for the client server 30 owned by the client, the name, address, and telephone number of the client's contact person, etc.

The job table D54 is a table for managing jobs requested by clients. For each job, the job table D54 registers the reception number set for that job, the client ID set for the client who requested the job, the name and content of the job, and so on. In addition, for each job, the job table D54 registers the calculation type and processing conditions of the job data corresponding to that job, the required computing power that is the computing power required to calculate the job data, the delivery date set for that job, and so on.

The resource table D55 is a table for managing the computing power in grid computing processing. Specifically, the resource table D55 registers, for each computing device 105, the computing device ID set for that computing device 105, the predicted results of the temporal change in the computing power available for the grid computing processing of that computing device 105, and the like. The matching table D56 registers, for each job, the reception number set for that job, the job data corresponding to that job, the computing device ID set for the computing device 105 assigned to that job data, and the like.

The job data D1 stored in the memory unit 504 is job data D1 accepted by the job acceptance process described below. The calculation result data D2 stored in the memory unit 504 is job data calculated by the grid computing process described below, and indicates the results of the calculation.

Next, the updating of the user table D51 will be described. The user table D51 is updated by the control unit 505 of the management server 50. For example, when a new user joins the system 1, the control unit 505 updates the user table D51 by registering information related to the new user in the user table D51. Specifically, the control unit 505 sets a new user ID for the new user, associates the "user ID" set for the new user with the "vehicle ID" set for the vehicle 10 owned by the user, the "computing device ID" set for the computing device 105 mounted on the vehicle 10, and the "user terminal ID" set for the user terminal 20 owned by the new user, and registers them in the user table D51.

In addition, by communication between the vehicle 10 owned by the new user and the management server 50, it is possible to obtain a "vehicle ID" and a "computing device ID" related to the new user. Also, by communication between the user terminal 20 owned by the new user and the management server 50, it is possible to obtain a "user terminal ID" related to the new user.

[Update the arithmetic unit table]
Next, the update of the arithmetic device table D52 will be described. The arithmetic device table D52 is updated by the control unit 505 of the management server 50. For example, when a new arithmetic device 105 joins the system 1, the control unit 505 updates the arithmetic device table D52 by registering information related to the new arithmetic device 105 in the arithmetic device table D52. Specifically, the control unit 505 associates the "arithmetic device ID" set in the new arithmetic device 105, the "user ID" set in the user who owns the arithmetic device 105, the "vehicle ID" set in the vehicle 10 in which the arithmetic device 105 is mounted, and the "performance" and "operation status" of the arithmetic device 105, and registers them in the arithmetic device table D52.

In addition, by communication between the vehicle 10 equipped with the new arithmetic device 105 and the management server 50, it is possible to obtain the "arithmetic device ID", "vehicle ID", "performance", and "operation status" related to the new arithmetic device 105. In addition, by referring to the user table D51, it is possible to obtain the "user ID" related to the new arithmetic device 105.

[Periodic update of the calculation unit table]
In addition, the “operation status” of the arithmetic device 105 registered in the arithmetic device table D52 is periodically updated. In other words, the operation status information D5 included in the arithmetic device table D52 is periodically updated. This periodic update is performed by the control unit 505 of the management server 50.

(First update process)
For example, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "operation history information D15" of the vehicle 10. Specifically, the control unit 505 may execute the following first update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the first update process, the control unit 505 requests the vehicle 10 equipped with the calculation device 105 to access the "operation history information D15". In response to the request, the calculation device 105 of the vehicle 10 allows access to the "operation history information D15". The control unit 505 updates the "operation history", which is the past operation status, of the "operation status" of the calculation device 105 registered in the calculation device table D52, based on the operation history of the calculation device 105 indicated in the operation history information D15.

(Second update process)
Furthermore, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "travel history information D13" of the vehicle 10. Specifically, the control unit 505 may execute the following second update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the second update process, the control unit 505 requests the vehicle 10 equipped with the calculation device 105 to access the "driving history information D13". In response to the request, the calculation device 105 of the vehicle 10 allows access to the "driving history information D13". The control unit 505 estimates the operation history of the calculation device 105 based on the driving history of the vehicle 10 indicated in the driving history information D13. Next, the control unit 505 updates the "operation history", which is the past operation status, of the "operation status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operation history of the calculation device 105.

(Third Update Process)
Furthermore, the "operation status" of the arithmetic device 105 in the arithmetic device table D52 (in other words, the operation status information D5) may be periodically updated based on the "schedule information D23" of the user terminal 20. Specifically, the control unit 505 may execute the following third update process for each arithmetic device 105 registered in the arithmetic device table D52.

In the third update process, the control unit 505 requests the user terminal 20 owned by the user who owns the arithmetic device 105 to access "schedule information D23". In response to the request, the control unit 205 of the user terminal 20 allows access to "schedule information D23". The control unit 505 detects the behavioral status related to the vehicle 10 in which the arithmetic device 105 is mounted from the behavioral status of the user (behavioral history and behavioral plan) shown in the schedule information D23. For example, from the behavioral history, which is a past behavioral status among the user's behavioral status, a behavioral history in which the user has boarded the vehicle 10 is detected, and from the behavioral plan, which is a future behavioral status among the user's behavioral status, a behavioral plan in which the user plans to board the vehicle 10 is detected.

Next, the control unit 505 estimates the driving status (driving history and driving schedule) of the vehicle 10 based on the detected behavioral status of the user. Next, the control unit 505 estimates the operating status (operating history and operating schedule) of the calculation device 105 based on the estimated driving status of the vehicle 10. Then, the control unit 505 updates the "operating status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operating status of the calculation device 105.

(Fourth update process)
Furthermore, the "operation status" of the calculation device 105 in the calculation device table D52 (in other words, the operation status information D5) may be periodically updated based on the "facility usage information D42" of the facility server 40. Specifically, the control unit 505 may execute the following fourth update process for each calculation device 105 registered in the calculation device table D52.

In the fourth update process, the control unit 505 requests the facility server 40 to access the "facility usage information D42". In response to the request, the facility server 40 permits access to the "facility usage information D42". The control unit 505 detects usage related to the vehicle 10 in which the calculation device 105 is mounted from the usage status (usage history and usage plans) of the facility indicated in the facility usage information D42. For example, from the usage history, which is the past usage status among the facility usage status, usage history in which the user boarded the vehicle 10 is detected, and from the usage plans, which are the future usage status among the facility usage status, usage plans in which the user plans to board the vehicle 10 are detected.

The control unit 505 then estimates the driving status (driving history and driving schedule) of the vehicle 10 based on the detected facility usage status. The control unit 505 then estimates the operating status (operating history and operating schedule) of the calculation device 105 based on the estimated driving status of the vehicle 10. The control unit 505 then updates the "operating status" of the calculation device 105 registered in the calculation device table D52 based on the estimated operating status of the calculation device 105.

[Update Client Table]
Next, an explanation will be given of updating the client table D53. The client table D53 is updated by the control unit 505 of the management server 50. For example, when a new client joins the system 1, the control unit 505 updates the client table D53 by registering information related to the new client in the client table D53.

Specifically, the control unit 505 sets a new client ID for the new client, associates the "client ID" set for the new client, the "client server ID" set for the client server 30 owned by the new client, and the "person in charge," "address," and "telephone number" of the new client, and registers them in the client table D53.

In addition, through communication between the client server 30 and the management server 50, it is possible to obtain the "client server ID," "contact person," "address," and "telephone number" for a new client.

[Processing according to this embodiment]
Next, the processes performed in this embodiment will be specifically described. In this embodiment, a job reception process, a parking position designation process, and a grid computing process are mainly performed.

(Job acceptance processing)
8, a job reception process performed by the control unit 505 of the management server 50 in this embodiment will be described. In the job reception process, job data D1 for which a calculation is requested by a client is received. For example, the control unit 505 of the management server 50 performs the following process each time a calculation of the job data D1 is requested by a client.

First, in step S1, the management server 50 accepts a job request from a client. Specifically, the client server 30 responds to an operation by a person in charge of the client and sends a job request application to the management server 50. In response to the application, the control unit 505 of the management server 50 performs the following processing.

The control unit 505 requests the client server 30 to send information required to accept the job (specifically, client information about the client requesting the job and job information about the job). In this example, the control unit 505 sends image data of the job acceptance screen to the client server 30. The control unit 305 of the client server 30 reproduces the image of the job acceptance screen from the image data, and outputs (displays) the image on the output unit 302 (display unit).

As shown in FIG. 9, the job reception screen is a screen for inputting information required to accept a job. The job reception screen is provided with a client name input field R101 for inputting the client name, a person in charge name input field R102 for inputting the client's person in charge name, an address input field R104 for inputting the client's address, a job name input field R111 for inputting the name of the job, a job content input field R112 for inputting a description of the job content, a calculation type input field R113 for inputting the calculation type of the job data corresponding to the job, a processing condition input field R114 for inputting the processing conditions of the job data, a required calculation capacity input field R115 for inputting the required calculation capacity of the job data, a delivery date input field R116 for inputting the delivery date of the job, and a registration button B100.

The client staff operates the input unit 301 (operation unit) of the client server 30 to input the necessary information into the job reception screen. This inputs client information about the client requesting the job and job information about the job. Then, once input of this information is complete, the client staff operates the input unit 301 (operation unit) of the client server 30 to press the registration button B100 on the job reception screen. When the registration button B100 is pressed, the control unit 305 of the client server 30 sends the information (client information and job information) input into the job reception screen to the management server 50. The control unit 505 of the management server 50 receives the client information and job information.

Next, the control unit 505 requests the client server 30 to send job data D1 corresponding to the job. In response to the request, the control unit 305 of the client server 30 sends job data D1 corresponding to the job to the management server 50. The control unit 505 of the management server 50 receives the job data D1.

Next, in step S2, the control unit 505 of the management server 50 analyzes the job data D1 received in step S1. Specifically, the control unit 505 analyzes the calculation type, processing conditions, required calculation capacity, etc. of the job data D1. Then, the control unit 505 corrects the job information received in step S1 based on the results of the analysis of the job data D1. Note that if the job information received in step S1 is sufficiently reliable, the processing of step S2 may be omitted.

Next, in step S3, the control unit 505 of the management server 50 associates the client information received in step S1 with the job information corrected as necessary in step S2 (or the job information received in step S1) and registers them in the job table D54. The control unit 505 also stores the job data D1 received in step S1 in the memory unit 504.

(Parking position designation process)
Next, the parking position designation process according to this embodiment will be described with reference to Fig. 10 to Fig. 14. Fig. 10 is a flowchart showing the parking position designation process according to this embodiment, Fig. 11 shows an example of an input screen for the planned stay time according to this embodiment, Fig. 12 is a table showing an example of group organization and allocation of designated parking positions according to this embodiment, Fig. 13 shows an example of a parking layout according to this embodiment, and Fig. 14 shows an example of a notification screen for the designated parking position according to this embodiment.

The parking position designation process according to this embodiment is executed by the control unit 505 of the management server 50 and the control unit 405 of the facility server 40. To give an overview of this parking position designation process, the control unit 405 of the facility server 40 first receives from the user of the vehicle 10 equipped with the computing device 105 the planned stay time at the specified facility in which the facility server 40 is installed, and sets a group consisting of multiple users who will have overlapping planned stay times at the specified facility based on the planned stay times received from the multiple users. Then, the control unit 405 of the facility server 40 sets the designated parking positions at which each of the multiple vehicles 10 should park in the parking area so that the multiple vehicles 10 belonging to the same group are located close to each other in the parking area, specifically within a range where vehicle-to-vehicle communication is possible, and transmits the designated parking positions to the users of the multiple vehicles 10. After that, the control unit 505 of the management server 50 determines whether each of the multiple vehicles 10 to which the designated parking positions have been transmitted is parked in the designated parking position, and determines whether a vehicle group is formed by the multiple vehicles 10.

Specifically, when the parking position designation process of FIG. 10 is started, first, in step S11, the control unit 405 of the facility server 40 determines whether or not it has received the time (planned stay time) that the user of the vehicle 10 equipped with the arithmetic device 105 plans to stay at a specific facility from the user. In one example, the facility server 40 receives the planned stay time input by the user on the vehicle 10. In this example, the user refers to the input screen displayed on the output unit 102 as a display unit on the vehicle 10 and inputs the planned stay time using the input unit 101 as a touch sensor on the vehicle 10 (see FIG. 11). In the example of the input screen shown in FIG. 11, the user is to select one planned stay time (for example, "up to 2 hours") from multiple displayed candidates of planned stay time when visiting a shopping mall. In addition to the received planned stay time, the control unit 405 associates the user's entry time into the facility (basically the current time) with the user ID (which may include the vehicle ID) and stores it in the storage unit 404 as facility usage information D42. In another example, the facility server 40 may receive the planned stay time input by the user on the user terminal 20, or may receive the planned stay time input by the user on a parking lot ticket machine installed at the entrance gate of the parking area. If the control unit 405 of the facility server 40 determines that the planned stay time has been received (step S11: Yes), the control unit 405 proceeds to step S12, and if the control unit 405 does not determine that the planned stay time has been received (step S11: No), the control unit 405 repeats the determination of step S11.

In step S12, the control unit 405 of the facility server 40 refers to the facility usage information D42 stored in the memory unit 404 as described above, and sets a group consisting of multiple users who have overlapping planned stay times at a specific facility based on the planned stay times received from multiple users. In particular, the control unit 405 calculates the planned exit time at which a user will leave the specific facility by adding the entry time and planned stay time included in the facility usage information D42, and organizes a group by preferentially gathering users who have similar planned exit times among the multiple users who have overlapping planned stay times. The control unit 405 also stores information about the groups organized in this way, specifically information indicating the group to which each user belongs, in the memory unit 404 as facility usage information D42.

Next, in step S13, the control unit 405 of the facility server 40 creates a parking layout that specifies designated parking positions for parking each of the multiple vehicles 10 in the parking area based on the groups organized in step S12. In particular, the control unit 405 references the parking position information included in the facility information D41 stored in the memory unit 404 and sets designated parking positions for each of the multiple vehicles 10 that belong to the same group so that the multiple vehicles 10 are located within a range (e.g., within 50 m) in the parking area where vehicle-to-vehicle communication is possible. The control unit 405 also stores the designated parking positions set for each of the multiple users (multiple vehicles 10) in this manner in the memory unit 404 as facility usage information D42.

Here, a specific example shown in FIG. 12 and FIG. 13 will be described. In this example, the control unit 405 of the facility server 40 prioritizes gathering users who have similar planned exit times among multiple users whose planned stay times overlap, and sets users b, c, d, and g to group II, and sets users a, e, and f to group III after group II (see FIG. 12). Then, the control unit 405 creates a parking layout so that the vehicles 10 of users b, c, d, and g belonging to group II are located within a range where vehicle-to-vehicle communication is possible, and the vehicles 10 of users a, e, and f belonging to group III are located within a range where vehicle-to-vehicle communication is possible, and sets designated parking positions (represented by parking numbers) to be assigned to each of users a to g (see FIG. 12 and FIG. 13). In particular, the control unit 405 assigns designated parking positions to each vehicle 10 so that the positions of the multiple vehicles 10 belonging to groups II and III are adjacent to each other in the parking area, in other words, so that a group of vehicles located close to each other is formed, as shown in FIG. 13. In addition, the control unit 405 assigns designated parking positions to each vehicle 10 so that one or more of the designated parking positions of the vehicles 10 of users a, e, and f belonging to group III are adjacent to one or more of the designated parking positions of the vehicles 10 of users b, c, d, and g belonging to group II, which has an earlier planned exit time than group III and is one step ahead in order. In other words, the control unit 405 connects the designated parking positions of group II, which has an earlier planned exit time, to the designated parking positions of group III, which has a later planned exit time, so that the group of vehicles located close to each other is maintained for as long as possible. In the example shown in FIG. 13, the designated parking positions of users b, c, d, and g are arranged so as to surround the designated parking positions of users a, e, and f. Note that the conditions for setting designated parking positions in the parking area as described above are presented in advance from the management server 50 to the facility server 40.

Returning to FIG. 10, in step S14, the control unit 405 of the facility server 40 transmits the designated parking position set as described above to the user. In one example, the facility server 40 transmits the designated parking position to the vehicle 10, which causes the vehicle 10 to display a notification screen of the designated parking position on the output unit 102 as a display unit (see FIG. 14). In the example of the notification screen shown in FIG. 14, the parking number indicating the designated parking position and its specific location within the parking area are displayed. Note that in another example, the facility server 40 may transmit the designated parking position to the user terminal 20 or a guidance device within the facility (which may be a parking lot ticket machine) and notify the user of the designated parking position via these.

Next, in step S15, the control unit 405 of the facility server 40 associates at least the planned stay time and the designated parking location with a user ID (which may include a vehicle ID) and transmits them to the management server 50 in order to share with the management server 50 the planned stay time of the user acquired in step S11 and the designated parking location set in step S13. As a result, the management server 50 stores the received information such as the planned stay time and the designated parking location in the memory unit 504 in association with the user ID. For example, the control unit 505 of the management server 50 stores this information in a user table D51 of the memory unit 504.

On the other hand, in step S21, the control unit 505 of the management server 50 determines whether or not the location where the vehicle 10 is actually parked (hereinafter referred to as the "actual parking location") has been received from the vehicle 10. In this case, when the vehicle 10 is in a non-operating state (for example, a standby state such as a state where the ignition power is off or the accessory power is off), the control unit 505 of the management server 50 transmits the vehicle status information D12 (including the vehicle position information indicating the position (latitude and longitude) of the vehicle 10 as described above) to the management server 50, and the control unit 505 of the management server 50 uses the vehicle position information included in this vehicle status information D12 as the actual parking location. If the control unit 505 determines that the actual parking location has been received (step S21: Yes), it proceeds to step S22, and if it does not determine that the actual parking location has been received (step S21: No), it repeats the determination of step S21.

In step S22, the control unit 505 of the management server 50 determines whether the vehicle 10 has been parked in the designated parking position set by the facility server 40 based on the designated parking position received from the facility server 40 and the actual parking position received from the vehicle 10. Specifically, the control unit 505 determines that the vehicle 10 has been parked in the designated parking position when the actual parking position matches the designated parking position. In addition, in determining whether the vehicle 10 has been parked in the designated parking position, instead of comparing the actual parking position with the designated parking position in this manner, in another example, the control unit 505 may make this determination based on the result of reading a marker (that can identify the parking position) that is provided in advance at each parking position in the parking area using a camera or the like of the vehicle 10. In yet another example, a sensor such as a camera may be provided in the parking area, and the control unit 405 of the facility server 40 may make this determination by acquiring the license plate number or the like of the parked vehicle 10.

Next, in step S23, the control unit 505 of the management server 50 transmits the parking position determination result in step S22, that is, the determination result of whether or not the actual parking position matches the designated parking position, to the management server 50. Then, in step S24, the control unit 505 determines whether or not a vehicle group has been formed by multiple vehicles 10 belonging to the group parking at their respective designated parking positions based on the parking position determination result in step S22. As a result, if the control unit 505 determines that a vehicle group has been formed (step S24: Yes), it ends the processing flow of FIG. 10. On the other hand, if the control unit 505 does not determine that a vehicle group has been formed (step S24: No), it returns to step S21. In this case, the control unit 505 repeats the processing of steps S21 to S24 until a vehicle group is formed.

On the other hand, in step S16, the control unit 405 of the facility server 40 determines whether or not the vehicle 10 is parked in the designated parking position, i.e., whether or not the actual parking position matches the designated parking position, based on the determination result sent from the management server 50 in step S23. As a result, if the control unit 405 determines that the vehicle 10 is parked in the designated parking position (step S16: Yes), it ends the processing flow of FIG. 10. On the other hand, if the control unit 405 does not determine that the vehicle 10 is parked in the designated parking position (step S16: No), it proceeds to step S17.

In step S17, the control unit 405 of the facility server 40 recreates the parking layout created in step S13. Specifically, the control unit 405 treats the designated parking position where the vehicle 10 is not parked as an empty space, and sets a new designated parking position corresponding to the empty space for another vehicle 10 belonging to the same group as the vehicle 10 (particularly, the vehicle 10 that entered after the vehicle 10 in the same group) so that the other vehicle 10 can park in the empty space. Taking the case shown in FIG. 12 and FIG. 13 as an example, when a user c belonging to group II does not park in the set designated parking position D2, the control unit 405 sets the designated parking position D2 for a user d who entered after the user c in this group II. After this, the control unit 405 of the facility server 40 returns to step S14 and performs the process from step S14 onwards again.

If multiple vehicles 10 are not parked in the same designated parking position, the control unit 405 will exclude this parking position from the designated parking positions set for parking vehicles 10 in the parking area. Possible reasons for not parking continuously in designated parking positions include obstacles (garbage or people) present at the parking position or damage to the parking space. To prevent vehicles from being forced to park in such a parking position, it is best to exclude this parking position from the set of designated parking positions.

In addition, even if the vehicle 10 is not parked in the designated parking position, if it is parked in another parking position in the parking area of a specified facility, it is preferable to have the computing device 105 installed in the vehicle 10 perform grid computing.

(Grid Computing Processing)
Next, the grid computing process performed by the control unit 505 of the management server 50 in this embodiment will be described with reference to Fig. 15. In the grid computing process, the control unit 505 of the management server 50 causes the arithmetic devices 105 mounted on each of the multiple vehicles 10 that form a vehicle group as a result of the parking position designation process in Fig. 10 to process the job data D1. For example, the control unit 505 performs the following processes after the job acceptance process and the parking position designation process.

First, in step S31, the control unit 505 of the management server 50 predicts the computing capacity of the computing device 105 mounted on each of the multiple vehicles 10 constituting the vehicle group. Specifically, the control unit 505 predicts the computing capacity (calculation amount), calculation type, and computable schedule as the computing capacity of each computing device 105 of the vehicle group based on the computing device table D52 stored in the storage unit 504 of the management server 50 and the vehicle state information D12 received from the vehicle 10. The calculation type is the ratio of CPU and GPU included in the computing device table D52, and the computable schedule is specified by the computable time based on the battery state according to the vehicle battery remaining amount information and vehicle charging information included in the vehicle state information D12. Then, the control unit 505 registers the information on the computing capacity of the entire vehicle group as computing grid information based on the computing capacity of each of the multiple computing devices 105 predicted in this way.

Next, in step S32, the control unit 505 assigns the job data D1 to be subjected to grid computing processing, which was accepted in the above job acceptance process (FIG. 8), to each of the computing devices 105 constituting the grid of the vehicle group, based on the computing capacity of each computing device 105 predicted in step S31. The job data D1 thus assigned to each computing device 105 is job data corresponding to the same job. Then, in step S33, the control unit 505 distributes (transmits) a portion of the job data D1 to each computing device 105 based on the assignment result of step S32.

After this, the arithmetic device 105 of each of the vehicles 10 constituting the vehicle group processes a part of the distributed job data D1. At this time, in a preferred example, the control unit 505 of the management server 50 may transmit a request to the vehicle 10 to turn on the lighting device 110 of the vehicle 10 equipped with the arithmetic device 105 performing grid computing in the parking area. Then, in response to this request, each of the vehicles 10 constituting the vehicle group may turn on the lighting device 110 in a predetermined manner so that it is clear that a process related to grid computing is currently being performed. For example, each of the vehicles 10 (vehicle group) parked adjacent to each other in a certain parking area turns on the lighting device 110 as an exterior lamp. In this case, it is preferable to turn on the exterior lamp in a specific color (such as green). In another example, the room lamp may be turned on in a specific color (such as blue) instead of the exterior lamp. In this way, by turning on the lighting devices 110 of the multiple vehicles 10, an advertising effect can be obtained by the vehicle group formed for grid computing.

Next, when each of the computing devices 105 completes the calculation of the data (part of the job data D1) sent to that computing device 105, it sends the partial calculation result data obtained by that calculation to the management server 50. In step S34, the control unit 505 of the management server 50 receives the partial calculation result data sent from the computing device 105 and stores the partial calculation result data in the memory unit 504.

Next, in step S35, the control unit 505 determines whether all of the calculation devices 105 to which the job data D1 was distributed in step S33 have completed calculations. If the control unit 505 determines that all of the calculation devices 105 have completed calculations (step S35: Yes), it proceeds to step S36, and if the control unit 505 does not determine that all of the calculation devices 105 have completed calculations (step S35: No), it returns to step S34.

Next, in step S36, the control unit 505 generates calculation result data D2 (calculation result data D2 indicating the result of the calculation of job data D1) corresponding to the job data D1 that is the target of the grid computing process by combining the partial calculation result data stored in the storage unit 504. Then, the control unit 505 transmits the calculation result data D2 corresponding to the job data D1 that is the target of the grid computing process to the client server 30 of the client that requested the calculation of the job data D1.

Next, in step S37, the control unit 505 calculates a reward to be given by the operator of the system 1 to the user who provided the computing power of the computing device 105 to the grid computing process. Examples of rewards include points, virtual currency, and product discount benefits that can be used in the system 1. Specifically, the control unit 505 determines a reward to be given to the user according to the amount of calculation that the computing device 105 provided to the grid computing process. In this case, the control unit 505 gives a larger reward to the user the greater the amount of calculation provided to the grid computing process.

Next, in step S38, the control unit 505 performs processing to grant the user the reward calculated in step S37. Examples of the processing to grant the reward include processing to associate the "user ID" set for the user with "points" (or virtual currency) available in the system 1 and register them in the user table D51, and processing to send information indicating a product discount benefit to the user terminal 20 owned by the user. Note that the information indicating the reward may be registered for each job in the job table D54. In addition, a reward may be granted by the client to a user who has provided the computing capacity of the computing device 105 to the grid computing process. For example, the control unit 305 of the client server 30 may execute processing to grant a reward to a user who has provided the computing capacity of the computing device 105 to the grid computing process.

[Action and Effect]
Next, the operation and effect of this embodiment will be described. In this embodiment, the control unit 405 of the facility server 40 receives the planned stay time of a user of the vehicle 10 equipped with the arithmetic device 105 in a predetermined commercial facility having a parking area, and sets a group consisting of a plurality of users whose planned stay time period at the predetermined facility overlaps based on the planned stay time of the plurality of users. Then, the control unit 405 of the facility server 40 sets a designated parking position where each of the plurality of vehicles 10 belonging to the same group should be parked in the parking area so that the plurality of vehicles 10 are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmits the designated parking position to each user of the plurality of vehicles 10. After that, when a vehicle group is formed by parking the plurality of vehicles 10 in the parking area in response to the transmission of the designated parking position, the control unit 505 of the management server 50 causes the arithmetic device 105 equipped in each of the plurality of vehicles 10 forming the vehicle group to process job data, thereby realizing grid computing.

According to this embodiment, grid computing is realized by the arithmetic devices 105 mounted on the vehicles 10 when the vehicles 10 are parked within a range in a parking area where vehicle-to-vehicle communication is possible, with the vehicles 10 having overlapping planned stay times. This allows vehicle-to-vehicle communication during grid computing, and allows calculation data to be appropriately transferred between the multiple arithmetic devices 105. In addition, the communication environment with the management server 50 is made uniform among the multiple arithmetic devices 105, and job data and the like can be appropriately transferred. Furthermore, by forming a vehicle group in the parking area of a specified facility using the multiple vehicles 10, the multiple arithmetic devices 105 can be operated simultaneously for a relatively long period of time. This makes it possible to appropriately realize, for example, distributed computing. As described above, according to this embodiment, stable and highly reliable computational resources for grid computing can be effectively secured.

In addition, according to this embodiment, by gathering multiple vehicles 10 in a short distance (within a range where vehicle-to-vehicle communication is possible) in a parking area of a specified facility for grid computing, it is possible to contribute to the operation of the facility. For example, in order to gather multiple vehicles 10 in a short distance in a parking area, congestion in the parking area can be alleviated by managing (controlling) the parking positions of each vehicle 10. Furthermore, prior to managing the parking positions in this way, by understanding information such as the length of time visitors stay at the facility and the number of visitors, this information can be used in the operation of the facility.

Furthermore, in this embodiment, the control unit 405 of the facility server 40 sets the designated parking position so that each of the multiple vehicles 10 belonging to multiple groups is positioned adjacent to each other in the parking area, thereby achieving advertising effects by using a group of vehicles formed for grid computing.

Furthermore, in this embodiment, the control unit 405 of the facility server 40 sets up a group by preferentially gathering users who have overlapping planned stay times and who are scheduled to leave a specific facility close to each other. This makes it possible to extend the time during which a vehicle group is formed by multiple vehicles 10 in each group, and to more effectively secure highly reliable computational resources for grid computing.

Furthermore, in this embodiment, the control unit 405 of the facility server 40 sets the designated parking positions of the multiple vehicles 10 belonging to a certain group so that one or more of the parking positions of the multiple vehicles 10 belonging to the previous group that has an earlier scheduled exit time than the group is adjacent to one or more of the designated parking positions set for the multiple vehicles 10 belonging to the previous group. This makes it possible to extend the time during which a vehicle group is formed by the multiple vehicles 10.

Furthermore, in this embodiment, the control unit 405 of the facility server 40 acquires the planned stay time transmitted from the user of the vehicle 10 equipped with the computing device 105. This allows the planned stay time specified by the user to be used to perform subsequent processing based on the planned stay time with high accuracy.

Furthermore, in this embodiment, when the vehicle 10 of the user to whom the designated parking position was transmitted is not parked at the designated parking position, the control unit 405 of the facility server 40 transmits the designated parking position to the user of the other vehicle 10 in order to park the other vehicle 10 belonging to the same group as the vehicle 10 at the designated parking position. This allows a vehicle group to be appropriately formed in the parking area by multiple vehicles 10 whose planned stay time periods overlap, even if the vehicle 10 is not parked at the designated parking position.

Furthermore, in this embodiment, when multiple vehicles 10 are not parked at the same designated parking position, the control unit 405 of the facility server 40 excludes this parking position from the designated parking positions set for parking the vehicles 10 in the parking area. This allows appropriate exclusion of parking positions from the set of designated parking positions when vehicles 10 are not consecutively parked at the designated parking positions due to obstacles (such as trash or people) present at the parking positions or damage to the parking positions.

[Modification]
In the above embodiment, the facility server 40 receives the planned stay time from the user, sets a group consisting of multiple users based on the planned stay time, sets the designated parking positions of each of the multiple vehicles 10 based on the group, and transmits the designated parking positions to the user. In another embodiment, the management server 50 may perform at least one of these processes instead of the facility server 40. In one example, the management server 50 receives the planned stay time from the user and also receives facility information D41 (particularly parking position information) from the facility server 40, sets a group and a designated parking position based on these, and transmits the designated parking position to the user. In this example, only the management server 50 corresponds to the "management system" and the "control device" in the present invention. In another example, the management server 50 receives the planned stay time from the user and transmits the planned stay time associated with the user to the facility server 40. Then, the facility server 40 sets a group and a designated parking position based on the planned stay time received from the management server 50 and transmits the designated parking position to the management server 50, and the management server 50 transmits the designated parking position to the user. In this example, the facility server 40 and the management server 50 correspond to the "management system" and the "control device" of the present invention.

In addition, in the above embodiment, the planned stay time specified (input) by the user is used, but in other embodiments, an estimated planned stay time may be used. For example, the user's planned stay time may be estimated based on the time zone of the entrance time to the facility or the day of the week on which the facility is visited. In this case, the average stay time to date based on the time zone of the entrance time, the day of the week, etc. may be used.

REFERENCE SIGNS LIST 1 System 10 Vehicle 20 User terminal 30 Client server 40 Facility server 50 Management server 104 Storage unit 105 Arithmetic device 404 Storage unit 405 Control unit 504 Storage unit 505 Control unit D1 Job data

Claims (8)

A management system for managing grid computing that causes a plurality of computing devices mounted on a plurality of vehicles to process job data, comprising:
A storage device that stores information about a plurality of computing devices and/or a plurality of vehicles equipped with the computing devices;
a control device configured to distribute the job data to each of a plurality of computing devices and cause them to process the job data based on the information stored in the storage device, thereby achieving the grid computing;
The control device includes:
acquiring a planned stay time for a user of a vehicle equipped with the computing device to stay in a predetermined commercial facility having a parking area;
Based on the expected stay times of a plurality of users, a group is set that is made up of a plurality of users whose expected stay times overlap in a time zone;
setting designated parking positions at which each of a plurality of vehicles of a plurality of users belonging to the same group should be parked in the parking area so that the plurality of vehicles are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmitting the designated parking positions to the respective users of the plurality of vehicles;
When a plurality of vehicles are parked in the parking area in response to the transmission of the designated parking positions, the job data is processed by the arithmetic device mounted on each of the plurality of vehicles, thereby realizing the grid computing.
The management system is configured as follows. The management system according to claim 1, wherein the control device is configured to set the designated parking position so that multiple vehicles belonging to the same group are located within a range in the parking area where vehicle-to-vehicle communication is possible, and multiple vehicles belonging to multiple groups are each located adjacent to each other in the parking area. The management system according to claim 1 or 2, wherein the control device is configured to calculate a planned exit time at which the user will leave the specified facility from the planned stay time, and to set the group by preferentially gathering users who have similar planned exit times among multiple users whose planned stay times overlap. The management system according to claim 3, wherein the control device is configured to prioritize gathering users whose planned exit time is closest, set the groups in order according to the planned exit time, and set the designated parking positions of multiple vehicles belonging to a certain group so that one or more of the designated parking positions set for multiple vehicles belonging to the previous group, which has an earlier planned exit time than the group, are adjacent to one or more of the parking positions of multiple vehicles belonging to the previous group. The management system according to any one of claims 1 to 4, wherein the control device is configured to acquire the planned stay time transmitted from a user of a vehicle equipped with the computing device. The management system according to any one of claims 1 to 5, wherein the control device is configured to transmit the designated parking position to a user of another vehicle that belongs to the same group as the vehicle when the vehicle of the user to whom the designated parking position was transmitted is not parked in the designated parking position, so that the other vehicle is parked in the designated parking position. The management system according to any one of claims 1 to 6, wherein, when a plurality of vehicles are not parked in the same designated parking position, the control device excludes the parking position from the designated parking positions set for parking vehicles in the parking area. A management method for managing grid computing, in which job data is processed by a plurality of computing devices mounted on a plurality of vehicles, by a computer, comprising the steps of:
storing information about the plurality of computing devices and/or the plurality of vehicles equipped with the computing devices;
and a control step of distributing the job data to each of a plurality of computing devices based on the information stored in the storage step, and causing the computing devices to process the job data, thereby achieving the grid computing,
The control step includes:
acquiring a planned stay time of a user of a vehicle equipped with the computing device in a predetermined commercial facility having a parking area;
A step of setting a group consisting of a plurality of users whose planned stay times overlap based on the planned stay times of the plurality of users;
setting designated parking positions at which each of a plurality of vehicles of a plurality of users belonging to the same group should be parked in the parking area so that the plurality of vehicles are located within a range in the parking area where vehicle-to-vehicle communication is possible, and transmitting the designated parking positions to the respective users of the plurality of vehicles;
When a plurality of vehicles are parked in the parking area in response to the transmission of the designated parking positions, the computing device mounted on each of the plurality of vehicles processes the job data, thereby realizing the grid computing;
The management method according to claim 1,

Images