JP2024084131A - Information processor - Google Patents

Abstract

To provide an information processor that enables effective use of information from various map software.SOLUTION: An information processor reads and stores information on a store name, a name and an address contained in and associated with map software in storage means of an information processing system, and when a requesting user terminal executes input information processing related to a pick-up destination, a return destination, favorite or today's parking lot, reads and associates the information in the map software and stores the same in the storage means of the information processing system.SELECTED DRAWING: Figure 14B

Description

This disclosure relates to an information processing device.

There is a known substitute driver management system that is used to manage substitute driver services that drive for people who are unable to drive due to drinking or other reasons.

JP 2016-151886 A

However, the above-mentioned conventional techniques do not incorporate and store the information contained in various map software into the storage means of an information processing system for effective use.

The purpose of this disclosure is to incorporate and store information contained in various map software into the storage means of an information processing system for effective use.

In one aspect, an information processing device that reads and stores associated store names, titles, and address information included in map software in a storage means of an information processing system reads and associates the information from the map software and stores it in the storage means of the information processing system when a requesting user terminal executes input information processing related to a pick-up destination, a return destination, favorites, or today's parking lot.

According to the present disclosure, it is possible to import and store information contained in various map software into the storage means of an information processing system and make effective use of it.

1 is a schematic diagram of an overall configuration of an information processing system according to an embodiment; FIG. 2 is a diagram illustrating an example of a hardware configuration of an information processing server. 13 is a flowchart showing a schematic flow of a process executed by a requesting user terminal in response to an input from a requesting user. 13 is a flowchart showing a schematic flow of a registration-related process among the processes executed by the information processing server. 13 is a flowchart showing a schematic flow of a process related to a substitute driving request among the processes executed by the information processing server. FIG. 11 is a table showing an example of a method for managing request information related to a substitute driving request. 11 is a flowchart showing a schematic flow of a process executed by a receiving user terminal in response to an input from a receiving user. 13 is a flowchart showing a general flow of a process relating to an assignment among the processes executed by the information processing server. FIG. 13 is a diagram showing an example of an input screen for inputting a request for substitute driving. FIG. 2 is an expanded view of the user interface. FIG. 13 is a diagram showing an example of an input screen for inputting a parking position. 13 is a schematic flow chart illustrating actions taken by a requesting user when generating a designated driving request using registered parking locations. FIG. 13 is a diagram showing an example of a top screen in a case where a parking position has already been registered. FIG. 1 is an explanatory diagram (part 1) for explaining how to associate a name with an address based on a search word. FIG. 2 is an explanatory diagram (part 2) for explaining how to associate a name with an address based on a search word. FIG. 3 is an explanatory diagram (part 3) for explaining how to associate a name with an address based on a search word. FIG. 13 is an explanatory diagram (part 1) for explaining how to associate a name with an address from a tap. FIG. 13 is an explanatory diagram (part 2) for explaining how to associate a name with an address from a tap. This is an explanatory diagram (part 1) for explaining how to associate names with addresses from favorites and today's parking lots. This is an explanatory diagram (part 2) for explaining how to associate names with addresses from favorites and today's parking lots.

Each embodiment will be described in detail below with reference to the attached drawings.

In this specification, the term "association" includes not only direct association but also indirect association. For example, a state in which element A is associated with element B is a concept that includes not only a state in which element A is associated with element B, but also a state in which element A is associated with element C and element C is associated with element B. The same applies to the similar term "linking."

Figure 1 is a schematic diagram of the overall configuration of an information processing system 1 according to one embodiment.

The information processing system 1 includes an information processing server 100.

The information processing server 100 can communicate with each of the user terminals 21, 31 via the network 4. That is, the user terminals 21, 31 and the information processing server 100 are connected via the network 4.

In the following, the requesting user refers to the user who receives the driving service, and the accepting user refers to the user who performs the driving service. The user terminal 21 is the terminal used by the requesting user, and is also referred to as the "requesting user terminal 21." The user terminal 31 is the terminal used by the accepting user, and is also referred to as the "accepting user terminal 31." Note that the requesting user and the accepting user are formal terms that indicate whether they are the requesting or accepting user at that time, and therefore a user who is the requesting user at one time may become the accepting user at another time.

Network 4 may include the Internet, a Wide Area Network (WAN), a wireless communication network, a wired network, or any combination of these. Note that part or all of network 4 may be realized by a P2P network.

User terminals 21 and 31 are, for example, smartphones or mobile phones, but may also be wearable terminals (e.g., smart watches, rings, etc.), tablet terminals, laptop terminals, desktop terminals, etc.

The user terminals 21, 31 each include a processing unit 23, 33, a display unit 24, 34, an input device 25, 35, and a GPS (Global Positioning System) receiver 26, 36. The processing units 23, 33 may be a computer such as a microcomputer. The display units 24, 34 may be a liquid crystal display or an organic EL (Electro-Luminescence) display. The input devices 25, 35 may be a touch panel or the like. The GPS receivers 26, 36 may generate terminal position information based on satellite signals from GPS satellites.

The information processing server 100 is in the form of a server, and is formed, for example, by a server computer. The information processing server 100 may be realized by multiple server computers. For example, the information processing server 100 may be realized by multiple server computers located in different locations working together. The information processing server 100 may also include a Web server. In this case, some of the functions of the user terminals 21 and 31 described below may be realized by a browser processing HTML documents received from the Web server and various programs associated therewith (Javascript).

Figure 2 shows an example of the hardware configuration of the information processing server 100.

In the example shown in FIG. 2, the information processing server 100 includes a control unit 101, a main memory unit 102, an auxiliary memory unit 103, a drive device 104, a network I/F unit 106, and an input unit 107.

The control unit 101 is a calculation device that executes programs stored in the main memory unit 102 and the auxiliary memory unit 103, and receives data from the input unit 107 and a storage device, calculates and processes the data, and then outputs the data to a storage device, etc.

The main memory unit 102 is a read only memory (ROM) or a random access memory (RAM). The main memory unit 102 is a storage device that stores or temporarily saves programs and data such as the OS (Operating System), which is the basic software executed by the control unit 101, and application software.

The auxiliary storage unit 103 is a storage device such as a hard disk drive (HDD) or a solid state drive (SSD) that stores data related to application software, etc.

The drive device 104 reads the program from the recording medium 105, such as a flexible disk, and installs it in the storage device.

The recording medium 105 stores a specific program. The program stored in this recording medium 105 is installed in the information processing server 100 via the drive device 104. The installed specific program can be executed by the information processing server 100.

The network I/F unit 106 is an interface between the information processing server 100 and peripheral devices and user terminals 21, 31, etc. that have communication capabilities and are connected via the network 4.

The input unit 107 includes a keyboard equipped with cursor keys, numeric input keys, and various function keys, a mouse, a touch pad, etc.

In the example shown in FIG. 2, the various processes described below can be realized by having the information processing server 100 execute a program. It is also possible to record the program on the recording medium 105 and have the information processing server 100 read the recording medium 105 on which the program is recorded to realize the various processes described below. Various types of recording media can be used for the recording medium 105. For example, the recording medium 105 may be a recording medium that records information optically, electrically, or magnetically, such as a CD (Compact Disc)-ROM, a flexible disk, or a magneto-optical disk, or a semiconductor memory that records information electrically, such as a ROM or a flash memory.

The hardware configuration of the user terminal 21 (the same applies to the user terminal 31) may be the same as the hardware configuration of the information processing server 100, except that the user terminal 21 (the same applies to the user terminal 31) includes a display unit 24 and a GPS receiver 26. However, the information processing server 100 may also include a display unit.

Next, the operation of the user terminals 21, 31 and the information processing server 100 in the information processing system 1 will be described with reference to FIG. 3 onward. In the following description, some of the functions of the user terminals 21, 31 may be realized by the information processing server 100, and some or all of the functions of the information processing server 100 may be realized by the user terminals 21, 31.

Figure 3 is a flowchart showing the general flow of the processing executed by the requesting user terminal 21 in response to input from the requesting user.

In response to a download instruction from the requesting user, the requesting user terminal 21 downloads a dedicated application (hereinafter, also simply referred to as a "driver service request app") (step S30). As described above, the driver service request app may be a so-called native application or a web application. A map application (e.g., Google Maps (registered trademark)) may be separately implemented in the requesting user terminal 21. In this case, the driver service request app may work in conjunction with the map application to realize various functions described below.

In the following description, the launch state of the designated driving service request app refers to a state in which the designated driving service request app is running and is ready to receive input from the user. Therefore, the launch state of the designated driving service request app differs from a state in which the designated driving service request app is running in the background on a multitasking screen, etc.

Next, the requesting user terminal 21 generates user information for user registration based on various inputs from the requesting user while the driving service request app is in a launched state (running state) (step S31). User registration may include, for example, registration of the requesting user's telephone number, address (e.g., home address), payment method, email address, password, etc. The user information for user registration may be transmitted to the information processing server 100. In this case, the information processing server 100 may issue a user ID and link the user information for user registration to the user ID. In this way, the user information for user registration may be stored (managed) in the information processing server 100 in a state linked to the user ID.

Once user registration has been completed, the requesting user may be able to launch the designated driving request app by inputting a user ID and password, etc.

Next, the requesting user terminal 21 generates vehicle information for registration based on various inputs from the requesting user while the driving service request app is in a launched state (activated state) (step S32). The vehicle information for registration may be transmitted to the information processing server 100. In this case, the information processing server 100 may link the vehicle information for registration to the corresponding user ID. In this way, the vehicle information for registration may be stored (managed) in the information processing server 100 while linked to the user ID. Note that, like the registration of user information, the registration of vehicle information only needs to be performed once unless there is a change. Furthermore, the registration of vehicle information is a process that can be executed depending on the user, and may be omitted.

In this way, the requesting user can register vehicle information related to their own vehicle that will be used for the designated driving service. This makes it easier for the accepting user to find the vehicle, making meetings smoother and improving convenience.

Next, the requesting user terminal 21 generates parking position information for parking position registration based on the parking position registration input (an example of a first input) from the requesting user while the driving service request app is running (step S33). For example, the generation of parking position information for parking position registration may be realized based on the parking position registration input from the requesting user while the input screen for parking position input is in an output state.

Parking position information for parking position registration may be generated using receiver position information from the GPS receiver 26. A preferred method for generating parking position information for parking position registration will be described later. Parking position information for parking position registration may be transmitted to the information processing server 100. In this case, the registration status of the parking position may be stored (managed) in the information processing server 100 in a manner linked to the user ID (or the request ID described later). Alternatively, parking position information for parking position registration may be stored (managed) in the requesting user terminal 21.

The registered parking location is the parking location of the vehicle used by the requesting user for the designated driving service. Typically, the registered parking location is a meeting place between the requesting user and the designated user, and the designated driving service begins when the two users meet there. In some cases, the requesting user and the designated user may meet at different meeting places and then head to the registered parking location.

Next, the requesting user terminal 21 generates (confirms) a driving service request based on a request confirmation input (an example of a second input) from the requesting user while the driving service request app is running (step S34). For example, the generation of a driving service request may be realized based on a request confirmation input from the requesting user while the input screen for entering a parking position is in an output state. In this case, the requesting user can generate a driving service request without screen transitions from the registration of the parking position, improving convenience.

The substitute driving request is linked to the parking position information for parking position registration generated in step S33. For example, if the parking position information for parking position registration is stored (managed) in the requesting user terminal 21, the substitute driving request may be sent to the information processing server 100 together with the parking position information for parking position registration. Alternatively, if the parking position information for parking position registration is stored (managed) in the information processing server 100, the substitute driving request may be sent to the information processing server 100 together with the user ID. In this case, the information processing server 100 can link the substitute driving request to the registered parking position information via the user ID.

The request for a designated driver may include information about the return destination. In this case, the return destination may be specified by the requesting user only if it is other than the home address (user information).

By generating a substitute driving request in this manner via the requesting user terminal 21, the requesting user can receive substitute driving services from the accepting user, which will be described later (step S35).

Figure 4 is a flowchart showing the general flow of the registration-related processing among the processing executed by the information processing server 100.

When the information processing server 100 receives the user information for user registration generated by the requesting user terminal 21 as described above (step S40), it registers the received user information (step S41). In other words, it realizes user registration.

When the information processing server 100 receives parking position information for parking position registration generated by the requesting user terminal 21 as described above (step S42), the information processing server 100 registers (temporarily stores) the received parking position information in association with the user ID (step S43). That is, the registration of the parking position is realized. Since the parking position may change for each driving service request, it may be deleted (invalidated) when a specified deletion condition is satisfied. The specified deletion condition may be satisfied when a certain amount of time has elapsed since registration, when the corresponding driving service service has ended, etc. Furthermore, the parking position information may be managed by address or by coordinates (e.g., latitude and longitude).

Figure 5 is a flowchart showing the general flow of processing related to substitute driving requests among the processes executed by the information processing server 100. Figure 6 is a table showing an example of a method for managing request information related to substitute driving requests. In Figure 6, "***" indicates a state in which some information is stored, and "..." indicates a state in which similar information is repeatedly stored.

When the information processing server 100 receives a driving service request sent from the requesting user terminal 21 (step S50), it issues a request ID (step S51). Then, the information processing server 100 identifies the parking location related to the current driving service request and links the parking location to the request ID (step S52). The parking location related to the current driving service request (i.e., the parking location to be identified) may correspond to the registered parking location information (see step S43 in FIG. 4). Next, the information processing server 100 generates (updates) request information as shown in FIG. 6 (step S53), and updates the output data of the acceptance display screen based on the request information data including the newly generated request information (step S54). The acceptance display screen is a screen that can be viewed by the accepting user, and may include a user interface that allows the accepting user to accept a desired request from various requests.

The request information may be information for managing the history and current status of driving service requests. In the example shown in FIG. 6, each request ID is associated with request details, parking location, requesting user information, and acceptance status. In this case, the request details may include information other than the parking location among the details of the request (e.g., request date and time, desired meeting date and time, return destination, contact phone number, etc.). The parking location may be registered parking location information as described above. The requesting user information may be the user ID of the requesting user. The acceptance status may include information on whether the accepting user has accepted the driving service request (i.e., information on whether the request is waiting to be accepted).

Figure 7 is a flowchart showing the general flow of the processing executed by the receiving user terminal 31 in response to input from the receiving user.

In response to a download instruction from the designated user, the designated user terminal 31 downloads a dedicated application (hereinafter, also simply referred to as the "designated driving service application") (step S70). As described above, the designated driving service application may be a so-called native application or a web application. A map application (e.g., Google Maps (registered trademark)) may be separately implemented on the designated user terminal 31. In this case, the designated driving service application may work in conjunction with the map application to realize the various functions described below.

Next, the accepting user terminal 31 generates user information for user registration based on various inputs from the accepting user while the driving service acceptance app is in a launched state (running state) (step S71). User registration may include, for example, registration of the accepting user's telephone number, email address, password, etc. The user information for user registration may be transmitted to the information processing server 100. In this case, the information processing server 100 may issue a user ID and link the user information for user registration to the user ID. In this way, the user information for user registration may be stored (managed) in the information processing server 100 while linked to the user ID.

Once user registration is completed, the designated user may then be able to launch the designated driving app (output the designated driving display screen) based on input of a user ID and password, etc.

Next, the accepting user terminal 31 outputs an acceptance display screen based on the terminal location information (step S72). The acceptance display screen includes information related to unaccepted substitute driving requests (i.e., substitute driving requests that the accepting user can accept). The terminal location information may be generated using receiver location information from the GPS receiver 26. For example, the acceptance display screen may include a map display centered on the location of the terminal location information. In this case, the map display may be output in conjunction with a map application.

Next, the receiving user terminal 31 generates (confirms) acceptance information for the substitute driving request based on the acceptance input from the receiving user while the acceptance display screen is in an output state (step S73). When multiple substitute driving requests are competing, the acceptance input may be linked to any one of the substitute driving requests (the selected substitute driving request).

The accepting user can generate acceptance information for the driving substitution request in this manner via the accepting user terminal 31, thereby providing the driving substitution service to the requesting user described above (step S74).

Figure 8 is a flowchart showing the general flow of the process related to accepting an assignment, among the processes executed by the information processing server 100.

When the information processing server 100 receives the request information generated by the request receiving user terminal 31 as described above (step S80), it updates the request information based on the received request information (step S81). For example, in the case of the request information shown in FIG. 6, the acceptance status of the corresponding substitute driving request may be updated to indicate "accepted."

Next, the information processing server 100 executes a support process for meeting at the parking location (meeting place) (step S82). For example, the information processing server 100 may inform (notify) the requesting user terminal 21 related to the requesting user of the location information of the accepting user who accepted the request, the estimated arrival time, the telephone number of the other party, the accepting user, etc. In addition, the information processing server 100 may execute route guidance to the meeting place (parking location related to the driving service request), vehicle information guidance, the telephone number of the other party, the requesting user, etc., for the accepting user terminal 31 related to the accepting user. Note that the telephone number of the other party may be in the form of a switch that makes a call when operated.

Next, when the information processing server 100 detects the start of the driving service (step S83), it supports the driving service (step S84). The start of the driving service may be notified to the information processing server 100 from the receiving user terminal 31 in response to a start input from the receiving user, for example. The support of the driving service may be realized, for example, by the requesting user notifying the registered user (family member, etc.) of the current location information or route guidance to the home destination. Note that, among the support of the driving service, the route guidance to the home destination may be realized autonomously in the receiving user terminal 31. Then, when the driving service ends (i.e., when the home destination is reached), the information processing server 100 stores the service completion information (step S85) and ends the processing for the current driving service request and acceptance. Note that the service completion information may include information such as the arrival time and details (fees).

Next, we will explain the processing and output screen on the requesting user terminal 21 with reference to Figure 9 onwards.

Figure 9 is a diagram showing an example of an input screen SC1 for inputting a request for a substitute driver. The input screen SC1 for inputting a request for a substitute driver may be output to the display unit 24 of the requesting user terminal 21.

The input screen SC1 for inputting a driving service request is preferably the top screen when the driving service request app is running.

In the example shown in FIG. 9, the input screen SC1 for inputting a request for a designated driver includes a map display G2 on the upper side and a user interface G3 on the lower side. The map display G2 may preferably be displayed in a wider area than the user interface G3. The map display G2 displays a support display G7 for registering a parking position. The support display G7 is a display that shows a position corresponding to the parking position or a candidate thereof on the map display G2. In the example shown in FIG. 9, the support display G7 includes a position display G70 and a mark display G71, and the position display G70 is, for example, initially positioned at the current position (terminal position information) of the requesting user terminal 21 on the map display G2. The mark display G71 is a display for making the position display G70 stand out.

Figure 10 is an enlarged view of the user interface G3. The user interface G3 includes a registration interface section G31 and a main interface section G32.

The registration interface unit G31 is in the form of a touch switch and includes a switch SW61 and a switch SW62. The switch SW61 is an interface for inputting a pickup destination, and may include a notation that prompts the user to register a parking location ("today's" parking location) via the main switch SW322.

Alternatively, switch SW61 may include characters (notation) indicating the current candidate (candidate parking position) corresponding to the current position according to the terminal position information. In this case, if the requesting user is satisfied with the current candidate, he or she can slide switch SW62 (to approve the parking position) to confirm the request for substitute driving. Switch SW62 is a switch that is slid when confirming the request for substitute driving. In other words, when switch SW62 is operated, the request confirmation input described above is generated.

The main interface unit G32 includes four main switches SW320, SW321, SW322, and SW323. The main switch SW320 is a switch labeled "Call now" and is a switch for calling the switch SW62 for confirming the driving service request. The main switch SW321 is a switch labeled "Call later" and is a switch for confirming the driving service request (reservation) at a time significantly later than the current time. The main switches SW320 and SW321 may be activated (operable state) in a state in which the parking position is registered. The main switch SW322 is a switch labeled "Today's parking lot" and is a switch for registering the parking position. By registering the parking position in advance, it is possible to eliminate the trouble of inputting the parking position when the driving service request is confirmed later by the main switch SW320, improving convenience for the requesting user. The main switch SW323 is a so-called hamburger button, and may be a button for various detailed settings.

Figure 11 shows an example of an input screen SC1-1 for inputting a parking position.

In the example shown in Fig. 9 and Fig. 10, the main switch SW320 is active and the switch SW62 is operable. In this case, for example, when the requesting user wishes to register a parking position, the requesting user can activate the main switch SW321 to display the registration confirmation switch SW63 (Fig. 11) that allows the parking position to be registered.

Hereinafter, the input screen SC1 for inputting a request for a designated driver, when the main switch SW321 is active, will also be referred to as the "input screen SC1-1 for inputting a parking position." The input screen SC1-1 for inputting a parking position has a similar map display G2 and user interface G3 to the screen shown in FIG. 9, and is one of the top screens. The input screen SC1-1 for inputting a parking position differs from the screen shown in FIG. 9 in that a registration confirmation switch SW63 appears instead of switches SW61 and 62, and a user interface section G1 for detailed input is superimposed on the top of the map display G2.

The registration confirmation switch SW63 is a switch for confirming the position indicated by the position display G70 of the assistance display G7 on the map display G2 as the parking position for registration. As described above, the position display G70 is positioned at a position on the map display G2 that corresponds to the position of the requesting user terminal 21. Therefore, when the requesting user parks the vehicle to be used for designated driving, they can complete the registration of the parking position simply by operating the registration confirmation switch SW63.

The position of the position indication G70 on the map display G2 may be fine-tuned by the requesting user. For example, the requesting user may enlarge the map display G2 and then accurately position the position of the position indication G70 to the actual parking location. Alternatively, the position of the position indication G70 may be automatically fine-tuned to a position on the map display G2 that corresponds to the parking lot based on map data.

The user interface unit G1 for detailed input is an interface for inputting information that is not required for registering a parking position, but some of it may be required. In the example shown in FIG. 11, the user interface unit G1 for detailed input may include an input unit for parking lot information for identifying or searching for a parking position by address or keyword, an input unit for inputting parking lot information such as the name of the parking lot, and an input unit for inputting a destination (such as a parking space number in the parking lot). Although not shown, in a modified example, a photo (image) of the parking position may be registered. In this case, the receiving user can easily identify the parking position and facilitate a smooth meeting. Although not shown, image data of the parking position may be registered. In this case, image data of the parking lot sign, the destination, and landmarks around the parking lot may also be registered. In this case, the image data for registration may include an image of the vehicle in a parked state. In this case, the receiving user can simultaneously recognize the vehicle (the vehicle used for the driving service) along with the parking position, improving convenience.

Figure 12 is a schematic flowchart showing the actions taken by a requesting user when generating a driving service request using a registered parking location. Figure 13 is a diagram showing an example of the top screen when a parking location has already been registered.

If the parking location has already been registered, the requesting user simply launches the designated driving request app (step S1200) and operates switch SW62 (see FIG. 13) on the top screen (step S1201). This allows the requesting user to immediately receive the designated driving service (step S1202).

Specifically, in the example shown in FIG. 13, when the driving service request app is launched, "Shinsaibashi ***, Osaka City" is shown as the registered parking location. If the requesting user is satisfied with the parking location, they can slide switch SW62 to confirm the driving service request to use the vehicle in that parking location. As described above, switch SW62 is a switch that is slid when confirming a driving service request. In other words, when switch SW62 is operated, the above-mentioned request confirmation input is generated.

In FIG. 13, the support display G7 includes a display such as "Pick up in 2 minutes" that indicates the estimated pick-up time if a driving service request is currently generated. This allows the requesting user to know the estimated time for confirming the driving service request, improving convenience. Also, in FIG. 13, the location display G50 of the accepting user who could accept the driving service request if the driving service request is currently generated is output in the form of a vehicle on the map display G2. This allows the requesting user to visually confirm the location information of the accepting user around the parking location, improving convenience.

However, users who request designated driving services generally tend to receive the designated driving services after a significant amount of time has passed since they parked their vehicle in a parking lot. For example, when there is an opportunity to drink alcohol, such as at a drinking party, it is common to receive the designated driving service after the occasion has ended.

However, when the requesting user has consumed alcohol, it may become difficult for them to remember where they parked today or perform complex operations due to impaired judgment and memory.

In this regard, according to this embodiment, as described above, since the parking location pre-registration function is provided, the requesting user can relatively easily and appropriately generate a substitute driving request even when in an intoxicated state (e.g., in an intoxicated state). In other words, according to this embodiment, since the parking location pre-registration function is provided, the burden on the requesting user when issuing a subsequent substitute driving request can be effectively reduced.

In addition, according to this embodiment, the parking location can be registered practically directly from the top screen. Therefore, the operational burden of the requesting user can be minimized for the input operations from launching the driving service request app to registering the parking location. This reduction in the input operation burden is particularly suitable for registering a parking location that may change each time. That is, the parking location when requesting a driving service is different from the parking lot at home and may be different each time, so the registered parking location cannot be used every time. That is, the parking location when requesting a driving service needs to be basically input for each driving service request. According to this embodiment, the convenience of the driving service request app can be effectively improved by facilitating the registration of the parking location for each driving service request.

In this embodiment, only one parking position can be registered, but two or more parking positions may be registered. In this case, switch SW61 may include the default parking position as the character (notation) indicating the current candidate. That is, the registered parking position may be set as the default parking position for each parking position. In this case, when the requesting user parks the vehicle at a parking position that is registered and set as the default, for example, the requesting user can generate a driving service request for the default parking position simply by operating switch SW62 from the top screen. Such a registration function is convenient for requesting users who tend to use the same parking position each time.

In FIG. 13, switch SW61 displays the address of the destination, "Shinsaibashi ***, Osaka City," and the name of the destination parking lot, "Izakaya Arigato Parking Lot 203." In this example, the user inputs the name in association with the address, but it is also possible to automatically obtain this name from map software and associate it with the address. A more detailed explanation is given below.

In addition to the map graphic information, a map application (any application such as Google Maps (registered trademark)) stores information on longitude, latitude, address, and the name of the location (e.g., ** electronics store, ++ parking lot, etc.) that corresponds to the address (e.g., *** Shinsaibashi, Osaka City) in association with each other. These associations are then reflected in the information processing system 1.

In this example, the information processing server 100 of the information processing system 1 is linked (integrated) with a map application (any application, such as Google Maps (registered trademark)). Then, when the requesting user terminal 21 executes information processing related to "Pick-up destination, return destination, favorites, and today's parking lot", the information is imported into the information processing server 100. Specifically, a process of storing the information in the auxiliary memory unit 103 is executed.

Here, "pick-up location" refers to the location where the requesting user meets the vehicle of the designated user who provided the driving service. For example, it refers to the location that is determined by the parking lot specified by the requesting user (here, the address and name of the parking lot) and the consent of the designated user who is the recipient of this information.

"Destination" refers to the destination to which the requesting user is to be dropped off (e.g., home). "Favorites" refers to information in which the requesting user has registered a meeting place or the like in advance. "Today's parking lot" refers to information in which the requesting user has registered a meeting place or the like in advance. For example, multiple "Favorites" and "Today's parking lot" may be registered. The user selects from among these.

As shown in FIG. 14A, a search keyword is entered in a search word input box 141 using (tapping) multiple input buttons 140. This displays a list of multiple (or single) pieces of information (store name, parking lot name, address, etc.) searched for using the search keyword. When the requesting user selects (tap) the relevant information 142 (store name, parking lot name, address, etc.) from this list, the screen changes to FIG. 14B. A screen 143 shows an enlarged display of information 142. Specifically, the first line displays the store name, title, etc. as "Yakiniku... Fukuoka Store," and the second line displays the address as "Takamatsu City, Kagawa Prefecture...." If the store name is long, up to 15 characters may be reflected. When the requesting user selects (tap) the information 142 (store name, parking lot name, address, etc.), the store name, title, etc. and the address are associated.

In FIG. 14B, an icon 145 is displayed at the corresponding address location on the map graphic information 144, and address information 146 (attachment location) such as the name of the store to be picked up is also displayed.

In this state, when the Confirm button 147 is tapped, the screen changes to that shown in FIG. 14C. Then, a process is executed to store the associated store name, name etc., and address information 146 in the auxiliary storage unit 103.

As shown in FIG. 14C, once confirmation is made, the position of the icon 148 is displayed on the top screen, and the address and name of the pickup location are displayed in the first line in the display box 149. In other words, an association between the address and pickup location is established. This allows the information processing server 100 of the information processing system 1, the requesting user terminal 21, and the accepting user terminal 31 to use this information at any time. Note that the display box 149 may be configured to allow additional information such as "south side parking lot."

As shown in FIG. 15A, by tapping on an icon 152 on the map's graphic information 151, it is also possible to associate the address and the name of the pickup location. That is, the map software associates the address in the map's graphic information with the store name, name, etc. Then, this information is read and stored in the auxiliary memory unit 103 at the timing of tapping. This allows the information processing server 100 of the information processing system 1, the requesting user terminal 21, and the accepting user terminal 31 to use this information at any time.

In this case, as shown in FIG. 15B, an icon 153 is displayed on the map information 151, and the name of the destination is displayed on the first line and the address of the destination is displayed on the second line in a display box 154.

As shown in Figures 16A and B, it is also possible to associate addresses and names with "Favorites" and "Today's Parking."

As shown in FIG. 16A, when map information 161 and icon 162 are specified and confirmation button 163 is tapped, the information is registered in "favorites" or "today's parking lot." At the time of registration, the address, store name, name, etc. are associated and read and stored in the auxiliary storage unit 103. This allows the information processing server 100 of the information processing system 1, the requesting user terminal 21, and the accepting user terminal 31 to use this information at any time. Also, once registered,

As shown in FIG. 16B, the name is associated with the address of the icon 165 in the map information 164 and registered.

On the other hand, by registering an address (e.g., *** Shinsaibashi, Osaka) and a name (e.g., *** Electronics Store, ++ Parking Lot, etc.) in association with each other, it is possible to accurately ascertain the address and name when viewing the history of past associations at a later time. This makes it easier to understand the attributes of the location compared to simply displaying coordinates, improving convenience. Note that past history, etc. may be edited as appropriate.

Although each embodiment has been described in detail above, it is not limited to a specific embodiment, and various modifications and changes are possible within the scope of the claims. It is also possible to combine all or some of the components of the above-mentioned embodiments.

For example, in the above-described embodiment, the requesting user terminal 21 uses terminal position information (i.e., the requesting user's position information) to register the parking position, but instead of or in addition to this, the position information of the requesting user's vehicle (the vehicle used for designated driving) may be used. In this case, the vehicle's position information may be acquired by the requesting user terminal 21 via communication between the requesting user terminal 21 and the vehicle.

1. Information processing system (information processing device)
4 Network 21 Requester user terminal (information processing device)
23 Processing device 24 Display unit 25 Input device 26 GPS receiver 31 Accepting user terminal 100 Information processing server 101 Control unit 102 Main memory unit 103 Auxiliary memory unit 104 Drive device 105 Recording medium 106 Network I/F unit 107 Input unit

Claims (1)

In an information processing device, information on store names, names, and addresses included in map software and associated with the map software is read and stored in a storage means of an information processing system,
An information processing device characterized in that, when a requesting user terminal executes input information processing related to a pick-up destination, a return destination, favorites, or today's parking lot, the information of the map software is read and associated, and stored in a storage means of the information processing system.