JP7696249B2 - System and method for revitalizing rural areas - Google Patents

Description

This invention relates to technology for revitalizing local areas using IT (information technology).

In Japan, "furusato nozei" (hometown taxation / hometown tax donation system) is a means of regional revitalization. Furusato nozei is one of Japan's tax systems for donations, where users can make donations to any local government of their choice and deduct the amount of the donation by reporting the amount to the tax office in their place of residence, which essentially allows them to pay taxes to any local government of their choice. Social recognition of hometown tax has increased through advertising by service providers, and the number of users is also on the rise.

Examples of technologies related to hometown tax donations include websites (also written as "hometown tax donation sites") and web services that support hometown tax donations and are published and provided on the Internet. For example, one hometown tax donation site registers information about products that are eligible as gifts in return for hometown tax donations, and provides functions such as rankings of popular gifts, search for gifts, and support for procedures for filing tax returns related to hometown tax donations.

An example of the prior art is JP 2018-67246 A (Patent Document 1). Patent Document 1 describes a tax return support processing device for hometown tax payers that supports those who have made hometown tax donations so that they can easily file their tax returns.

JP 2018-67246 A

The prior art examples can support procedures for hometown tax donations and tax returns, but they do not fully realize the hometown tax donation philosophy of "individuals donating to local governments they want to support." Specifically, users of hometown tax donation sites tend to donate in order to receive gifts in return, and the ripple effect on the local government does not exceed the amount of the tax donation.

The objective of this invention is to provide IT technology that can realize regional revitalization through hometown tax payments (donations), which is expected to have an even greater ripple effect.

A representative embodiment of the present invention has the configuration shown below. The regional revitalization system of the embodiment displays a digital cart on the display screen of a user terminal, registers product information in the digital cart based on user operations within a target area, and when it is determined that the user terminal has left the target area, or when the user inputs an instruction within the target area, processes donations related to the regional development tax for products in the digital cart to an entity associated with the target area.

A representative embodiment of the present invention can provide IT technology that can realize regional revitalization with even greater ripple effects expected from hometown tax payments (donations). Issues, configurations, effects, etc. other than those mentioned above are described in the [Mode for carrying out the invention].

1 shows an overall schematic configuration of a local revitalization system according to a first embodiment of the present invention. In the first embodiment, a functional block configuration example of a business operator system is shown. In the first embodiment, a configuration example of a business operator system as a computer system will be described. In the first embodiment, an explanatory diagram of an outline of a usage flow is shown. In the first embodiment, the main processing flow will be described. In the first embodiment, a setting example (first example) of a target area of a travel destination will be shown. In the first embodiment, a setting example (second example) of a target area of a travel destination will be shown. In the first embodiment, examples (first to third examples) of the application screen of a user terminal are shown. In the first embodiment, examples (fourth to sixth examples) of the application screen of the user terminal are shown. In the first embodiment, a screen example (seventh example) of an application on a user terminal is shown. In the first embodiment, a configuration example of digital cart information will be shown. In the first embodiment, an example of the configuration of the product master will be shown. In the first embodiment, a configuration example of the area master will be shown. In the first embodiment, an example of the configuration of user information including travel information will be shown. In the first embodiment, the concept of hometown tax payment will be explained. An explanatory diagram for Modification 7 is shown. An explanatory diagram for Modification 8 is shown.

The following describes the embodiment of the present invention in detail with reference to the drawings. In the drawings, the same parts are generally given the same reference numerals, and repeated explanations are omitted. For the purpose of explanation, when describing processing by a program, the program, functions, processing units, etc. may be described as the main body, but the main body of the hardware for these is a processor, or a controller, device, computer, or system, etc., that is composed of a processor, etc. The computer executes processing according to the program read into the memory by the processor, using resources such as memory and communication interfaces as appropriate. This realizes a specified function, processing unit, etc. The processor is composed of semiconductor devices such as a CPU or GPU, for example. The processor is composed of devices and circuits that can perform specified calculations. The processing is not limited to software program processing, and can also be implemented by a dedicated circuit. The dedicated circuit can be an FPGA, an ASIC, a CPLD, etc. The program may be installed in the computer as data in advance, or may be distributed to the computer as data from a program source. The program source may be a program distribution server on a communication network, or a non-transient computer-readable storage medium (e.g., a memory card), etc. A program may be composed of multiple modules. A computer system may be composed of multiple computers. A computer system may be composed of a client-server system, a cloud computing system, an IoT system, etc. Various data and information are represented and implemented in structures such as tables and lists, but are not limited to these. Furthermore, expressions such as identification information, identifiers, IDs, codes, names, and numbers are interchangeable.

<First embodiment>
A local revitalization system according to the first embodiment of the present invention will be described with reference to FIGS. 1 to 15. The local revitalization system according to the first embodiment is realized as a computer system using IT. The local revitalization method according to the first embodiment is a method having steps executed in the local revitalization system according to the first embodiment. In other words, the local revitalization system according to the first embodiment is a hometown tax payment support system, which is a system for revitalizing local areas by supporting hometown tax payments using IT. The local revitalization system according to the first embodiment is a system in which a user can make a donation related to a local development tax such as hometown tax payment to an entity (e.g., a local government) associated with a product or a predetermined location (target area, location, region, etc.) when traveling, etc., in association with the purchase and payment of the product (particularly an item that can be delivered, etc.) in a digital cart (i.e., online) of a user terminal.

The local revitalization system of the first embodiment is a system designed to create a synergistic effect between travel and hometown tax payment, and is designed to smoothly link product sales and purchasing support during travel with hometown tax payment support. This system can guide users from travel to hometown tax payment. This system can increase opportunities for hometown tax payment. For users who are interested in travel, they can easily make hometown tax payment donations in response to product purchases at their travel destination, and can receive the purchased products as gifts in return from the local government.

The regional revitalization system of the first embodiment shown in FIG. 1 etc. provides a digital cart 51 by an application 50 to a user terminal 5 of a user by a business operator system 1, and supports shopping during the user's trip (sales of goods from the viewpoint of a goods seller 2) using the digital cart 51. The digital cart 51 is a shopping cart that can be used for shopping only during a stay in a target area corresponding to the region of the travel destination 400. At the same time, this system links the purchase of goods with the digital cart 51 to hometown tax donations to the local government. This system manages and controls the purchase of goods 40 with the digital cart 51 within the target area corresponding to the travel destination 400 based on the position of the user terminal 5. This system controls the payment and delivery of the purchased goods when the user terminal 5 leaves the target area. And, this system links the donation related to hometown tax donations to the local government associated with the travel destination 400 when the goods purchased with the digital cart 51 are eligible for return gifts in hometown tax donations.

The user can actually see and check the products 40 sold at stores 4 and other places in the target area during the trip, read the product information on the user terminal 5, and purchase the products in the digital cart 51. The user does not need to carry the actual products 40 with him/her during the trip. The product information of the products that the user is considering purchasing is stored in the digital cart 51 during the trip, and the user can confirm or cancel the purchase. When the user returns from the trip and the user terminal 5 goes outside the target area, the payment (including the payment of the donation) and delivery of the purchased products in the digital cart 51 are automatically executed according to the settings or instructions. If the purchased products in the digital cart 51 are eligible for the hometown tax return gift and the user approves the donation, the donation process related to the hometown tax return gift can be automatically executed for the purchased products. When the user purchases a product at a local store, etc., the user can make a donation to the local government through the store, etc., and can receive the product as a return gift. With just a few simple operations on the app 50 on the user terminal 5, the user can make donations related to hometown tax payments as well as purchase, pay for, and deliver products using the digital cart 51 while traveling.

[1. System]
1 shows an overview of the overall configuration of a regional revitalization system according to embodiment 1. The regional revitalization system according to embodiment 1 includes a business operator system 1, a product seller 2, a local government system 3, a user terminal 5 for each user, a payment system 6, and a delivery system 7, which are appropriately connected by communication via a communication network 101. The communication network 101 includes a mobile network and the Internet.

The business operator system 1 is a main component of the local revitalization system of the first embodiment. The business operator system 1 is a computer system under the jurisdiction of a business operator, and is configured with hardware and software such as a server, a database (DB), and a website. The business operator system 1 is realized, for example, in a data center or a cloud computing system on the communication network 101. Based on the cooperation of the hardware and software, the business operator system 1 realizes functions as a local revitalization system, that is, a function to support product sales by the product seller 2, a function to support users' travel and donations related to hometown tax payment, and a function to support hometown tax payment by local governments. The business operator system 1 manages and controls each user's digital cart 51.

The product seller 2 is a seller who sells products 40 at stores 4 in various regions of Japan and the seller's computer system, and is configured with, for example, a PC 21 and product information 22. The seller manages the product information 22 on a seller terminal such as the PC 21. The product information 22 is product information about the products 40 sold at the store 4. Each product 40 at the store 4 is assigned a code 41 for product management in advance. The code 41 assigned to the product 40 corresponds to the product information 22. The seller registers the product information in the DB of the business system 1. In addition to basic information such as the product code and price for each product 40, the product information 22 includes information related to the local government's hometown tax donation, such as whether or not the product is eligible for a hometown tax donation return gift (a flag described later). The product information provided by the business system 1 to the user terminal 5 includes such information related to hometown tax donation.

Of the products 40 sold by the product seller 2 at the store 4, some of the products 40 are eligible for local government hometown tax return gifts. For the sake of explanation, the products 40 eligible for return gifts are also referred to as "return gift products," and the other products 40 are also referred to as "regular products." These some of the products 40 are set as return gift products in advance in this system. Specifically, in the DB of the business operator system 1, information such as a flag indicating whether or not the product 40 is eligible for a hometown tax return gift is set for each product 40. These return gift products are determined by the digital cart 51 to be eligible for a hometown tax return gift, and can be automatically linked to donation processing.

Note that the products 40 (regular products and return gift products) sold by the product seller 2 at the store 4 are not limited to foods, goods, etc. that can be checked by touching them. For example, the actual products 40 may not be placed or displayed at the local store 4, and images and information about the products 40 may be listed in catalogs, pamphlets, or advertisements placed at the local store 4, or on the website of the store 4 or the business operator system 1. Even in this case, if the user can obtain product information by reading the images and information using the functions of the user terminal 5, the product can be purchased using the digital cart 51.

This system is applicable so long as the user actually goes to a specific location, such as a local store 4, while traveling, etc., and purchases a specific product 40 at that specific location, and is not limited to the manner in which the product 40 is displayed. The specific location is a location that is subject to location management as a target area in this system. In the first embodiment, a case is described in which the specific location is the region of the travel destination, but this is not limited to this, and the system is also applicable to specific stores and areas that include them, even when not traveling. An example of a specific store outside the travel destination is so-called antenna shops (stores opened outside the local area by local governments, etc., for the purpose of introducing local products, etc.).

The local government system 3 is a computer system in each local government associated with the travel destination 400 region and in the local government where the user resides, and is configured with a hometown tax payment reception unit 31. The hometown tax payment reception unit 31 is a department that accepts hometown tax payment procedures, and is a general term that includes personnel, machines, computers, systems, etc.

The user terminal 5 is a portable information processing terminal device such as a smartphone or tablet that is owned and carried by the user. The business operator's app 50 is installed on the user terminal 5. The app 50 is an application program for managing and controlling a digital cart 51 (in other words, a shopping cart). The app 50 realizes the functions of this local revitalization system, that is, functions to support product purchases, payments (including donations), delivery, travel, etc. on the digital cart 51. The app 50 of the user terminal 5 displays an app screen including a graphical user interface (GUI) on the display screen of the display device (e.g., a touch panel) of the user terminal 5. The app screen includes a screen of the digital cart 51 described below. The digital cart 51 is controlled based on communication and processing between the app 50 of the user terminal 5 and a server of the business operator system 1, etc.

The user travels from home 8 to travel destination 400. The location of the user terminal 5 is determined as location information (e.g., latitude and longitude) based on a system or means such as a GPS (Global Positioning System) 102. The user also possesses an identification card 80 such as a My Number card. The user can use the information on the identification card 80 when registering and setting user information, payment information, delivery information, tax payment information, and the like in this system. The information on the identification card 80 may be stored as data in the user terminal 5.

Payment system 6 is a system operated by payment providers related to credit cards, bank accounts, point services, etc., and is a general term that includes computer systems, etc.

The delivery system 7 is a system operated by a delivery company, such as a logistics center or a home delivery company, that delivers the product 40, and is a general term that includes computer systems, etc.

[2. Business operator system]
2 shows an example of a functional block configuration of the business operator system 1 in FIG. 1. The functional blocks and the connecting lines between the functional blocks are examples. The business operator system 1 has, as its various units (functional blocks), a communication unit 10, a location management unit 11, an authentication unit 12, a tax payment management unit 13, a product management unit 14, a cart management unit 15, a settlement management unit 16, a delivery management unit 17, and the like, which are capable of mutual communication and data input/output. The business operator system 1 also has, as its DBs (in other words, each storage unit), a user DB 202, a tax payment DB 203, a product DB 204, a cart DB 205, and a delivery DB 207, and the like. Each storage unit may be implemented in the form of a file, a table, or the like.

The communication unit 10 has a communication interface for the communication network 101 in FIG. 1 and the LAN 310 in FIG. 3, and performs communication processing between each component such as the user terminal 5 in FIG. 1.

The location management unit 11 grasps the location of each user terminal 5 based on the GPS location information of the user terminal 5 of each user, and stores the location information in the user DB 202. The location management unit 11 also determines the location relationship between the location of the user terminal 5 and the target area 500 (FIG. 4) of the travel destination 400. The location management unit 11 determines and detects whether the user terminal 5 has entered the target area 500 (also described as "enter") or left the target area 500 (also described as "exit") based on the current location information acquired from the user terminal 5. When making this determination, the location management unit 11 refers to the setting information of the target area 500 of the user's trip. The target area 500 is the range in which shopping can be done with the digital cart 51, and corresponds to the payment range described later. The location management unit 11 or the cart control unit 15 sets the target area 500 corresponding to the travel destination 400 in the area master (FIG. 13) described later.

The authentication unit 12 performs registration and authentication processing for users and user terminals 5 who use this system. The business operator system 1 may register users as members who are eligible to receive services from this system. The authentication unit 12 performs user authentication using a specified method when access is made from the user terminal 5. The authentication unit 12 stores information for authentication in a database (not shown). This authentication may be performed automatically at a specified opportunity, such as when the user terminal 5 enters or leaves a target area, or when purchasing a product 40 at the store 4.

The cart management unit 15 is, in other words, the main control unit, and manages and controls the app 50 and the digital cart 51. The cart management unit 15 stores digital cart information in the cart DB 205 as information related to the status and history of the digital cart 51 based on communication with the app 50 of each user terminal 5. This digital cart information includes product information registered in the digital cart 51. The cart management unit 15 turns on the digital cart 51 when the user terminal 5 enters a target area, and turns off the digital cart 51 when the user terminal 5 leaves the target area.

As part of the functionality of the app 50, the cart management unit 15 also manages information related to the user's travels, and stores setting information related to the user's travels (also referred to as "travel information"), such as travel destinations 400 and travel schedules, in the user DB 202. User information, digital cart information, and travel information are managed in association with one another.

Based on communication with the cart management unit 15, the app 50 accepts operations such as user input of instructions on the app screen, and performs processes such as displaying information on the digital cart 51 and registering products to the digital cart 51. The cart management unit 15 updates the digital cart information in the cart DB 205 in response to processes such as registering products to the digital cart 51 of the app 50. The information on the digital cart 51 of the app 50 and the digital cart information in the cart DB 205 are synchronized as appropriate. The history information of the digital cart 51 held in the cart DB 205 also includes history information related to operations such as registration and payment for the digital cart 51 by the user.

The product management unit 14 stores product information related to the products 40 sold by each product seller 2 at the store 4 in the product DB 204. The product DB 204 has a product master (FIG. 12) described below. The product seller 2 or the operator of the business sets product information in the product master of the product DB 204 based on the product information 22 of the product seller 2. For example, if the product 40 is eligible for a gift in return for hometown tax donations, based on information obtained from the product seller 2 or the local government system 3, the operator sets information such as a flag indicating whether the product 40 is eligible for a gift in the product master. The product seller 2 may not hold or manage the product information 22 or website itself, but may leave it to the product DB 204 of the business system 1.

The product management unit 14 refers to the product DB 204 based on the product identification information that the user reads from the code 41 of the product 40 at the store 4 using the reader function of the user terminal 5, identifies the product 40, obtains the product information of the product 40, and transmits it to the user terminal 5. This product information includes various information to be handled by the digital cart 51.

The payment management unit 16 stores management information related to the payment process for the purchase of products in the digital cart 51 by the user. Basically, all payments are made by the payment system 6, and the payment information of the user and the like is basically managed and stored in the payment DB of the payment system 6. The payment management unit 16 on the business system 1 side stores management information related to the payment process between the user, the business system 1, and the local government and the like. The payment management unit 16 uses the user's payment information to perform payment processing (step S7 in FIG. 4 described later) corresponding to the payment method used by the user (e.g., credit card) with the payment system 6 for the purchased products in the digital cart 51. The payment management unit 16 records the status and results of the payment process (e.g., information on whether or not payment has been made). It is to be noted that this is not limited to the above, and the user's payment information may be managed and stored in the business system 1 rather than on the payment system 6 side. In other words, the business system 1 may also have the function of a payment system.

The delivery management unit 17 stores management information related to the delivery process for paid products in the digital cart 51. Basically, all deliveries are performed by the delivery system 7, and the user's delivery information is managed and held in the delivery system 7. The delivery management unit 17 on the business system 1 side stores management information related to the delivery process between the user, the business system 1, the product seller 2, etc. The delivery management unit 17 uses the user's delivery information to perform delivery processing (step S8 in Figure 4 described below) to the user's delivery destination (e.g. home 8) between the delivery system 7 and the paid products in the digital cart 51. The delivery management unit 17 sends delivery instructions to the delivery system 7 and records the status and results of the delivery process (e.g. information on whether or not delivery has been completed).

If the product purchased in the digital cart 51 is eligible for a hometown tax return gift (return gift product), the tax payment management unit 13 performs donation processing related to the hometown tax payment procedures. This donation processing is realized as part of the payment processing (step S7 in FIG. 4 described below). The tax payment management unit 13 stores the user's tax payment information in the tax payment DB 203. The tax payment management unit 13 uses the tax payment information to perform donation processing related to the hometown tax payment between the hometown tax payment reception unit 31 of the local government system 3. When processing the donation, the tax payment management unit 13 transmits the donation information to the hometown tax payment reception unit 31. The tax payment management unit 13 records the status and results of the donation processing (for example, information such as whether or not a donation has been made) in the tax payment DB 203.

3. Computer System
Fig. 3 shows an example of the configuration of a computer system constituting the business operator system 1 in Fig. 1. This computer system includes a server computer 300 (in other words, a server device), a client computer 320 (in other words, a client device) connected to the server computer 300 via a communication network such as a LAN 310, a DB server 330, and a Web server 340. The LAN 310 is connected to the communication network 101 in Fig. 1.

The server computer 300 is configured with a processor 301, memory 302, a communication interface device 303, an input/output interface device 304, and a bus that interconnects them. Based on program processing, the server computer 300 executes middleware such as an OS, a DBMS (DataBase Management System), and a Web server program, as well as applications that run on them. An input device such as a keyboard and a display device such as an LCD display may be connected to the input/output interface device 304. The communication interface device 303 is connected to, for example, a LAN 310 via a communication interface, and performs communication processing with other devices via the LAN 310.

The processor 301 is composed of, for example, a CPU, a ROM, a RAM, etc., and constitutes a controller. The processor 301 realizes the functions of the server computer 300 (for example, each part in FIG. 2) based on program processing. The processor 301 provides a screen including a GUI to the client computer 320.

Memory 302 is composed of a non-volatile storage device or the like, and stores various data and information used by processor 301 and the like. Memory 302 stores control program 311, setting information 312, work data, and the like. Control program 311 is a computer program for realizing the functions of processor 301. Setting information 312 is setting information for the functions of control program 312 and user setting information.

The client computer 320 can be configured as a PC, for example, and is operated by an operator of the business. The client computer 320 is equipped with input devices such as a keyboard and a mouse, and a display device such as an LCD display, or these are externally connected. The client computer 320 accesses the server computer 300. The operator uses this computer system by operating the input device while looking at the display screen of the client computer 320, and performs management tasks such as database settings.

The DB server 330 has DB 350, which contains various data and information managed by the business operator system 1, specifically, each DB shown in FIG. 2.

A website 360 is constructed on the web server 340, and accepts access from the user terminal 5 and the like. The web browser of the user terminal 5 accesses the website 360 and acquires web page data and the like to display the screen of the website 360. The website 360 is a website that provides users with information related to travel and hometown tax donations in this system. The website 360 also provides information for introducing an app 50 including a digital cart 51 to the user terminal 5. The website 360 may provide information to support the user in selecting a travel destination, or may provide information to support the hometown tax donation procedure. The website 360 may provide, for example, information on stores 4 and products 40 in areas that are candidates for the travel destination 400, or information related to the hometown tax donation procedure for each local government in the area (including information on return gifts). Website 360 is not required, and the system may be configured to link with a website provided by an external business operator.

[4. Usage procedure]
Fig. 4 shows an overview of the overall operation and processing flow when a user utilizes the local revitalization system of embodiment 1. Fig. 4 has steps S1 to S8, which will be described in order below.

(1) Step S1 is pre-registration. First, in step S1, the user introduces and installs the app 50 from the business operator system 1 onto his/her user terminal 5, for example at home 8, and performs initial settings of the app 50 and the digital cart 51. This setting includes registration of user information. The user information includes, for example, name, address, telephone number, email address, authentication ID, password, etc. This setting also includes setting of payment information, delivery information, and tax payment information among the user information. With this setting, the information of the user's digital cart 51 is registered in the cart DB 205 on the business operator system 1 side. At this point, the user's digital cart 51 is in the off state. In the off state, shopping with the digital cart 51 is disabled, and product information cannot be registered. In the on state, shopping with the digital cart 51 is enabled, and product information can be registered.

The user also sets payment information in advance in the app 50. This payment information is information required for payment for products purchased in the digital cart 51 (step S7). This payment information is, for example, credit card information, bank account information, or point service information.

The user also sets delivery information in advance in the app 50. This delivery information is information required to deliver the purchased product (regular product or gift product) to the user's home 8 or the like (step S8), and includes information such as the delivery method and delivery address.

The user also sets tax payment information in advance in the app 50. This tax payment information is information required for the hometown tax payment procedure related to the purchased product, and in particular includes information required for the donation process in the payment process of step S8. The tax payment information can be, for example, information on the identity card 80. The identity card 80 can be a My Number card, a driver's license, a passport, etc.

The above-mentioned payment information, delivery information, tax payment information, etc. can also be set later in the app 50. If the user terminal 5 has data on an identity card 80 such as a My Number card, that data may be used to set the above-mentioned payment information, etc.

Furthermore, after the initial settings, if the user is planning to travel, the user sets up the travel in the app 50. The user sets travel information related to the planned travel, such as the travel destination (area) 400, schedule, period, budget, etc. This is considered to be travel information among the user information (see FIG. 14 described later). The business operator system 1 registers the user information, including the travel information, in the user DB 202.

(2) The user travels on the date and time scheduled in the app 50. When traveling, the user carries the user terminal 5, identification card 80, etc., and travels from their home 8 to the travel destination 400 by public transportation (shown as outbound route 431). The user visits a target area 500 corresponding to the region of the travel destination 400. In this example, the travel destination 400 is an area such as a prefecture, as shown in FIG. 6 described below. A target area 500 corresponding to that region is set. The target area 500 is a set area on a map, and is an area for controlling the purchase of products and payment on the digital cart 51, etc.

Step S2 indicates that the user terminal 5 enters the target area 500 (entry). In step S2, the user who possesses the user terminal 5 enters the target area 500 corresponding to the travel destination 400. The app 50 of the user terminal 5 and the operator system 1 determine whether the user terminal 5 has entered the target area 500 based on the user's travel information, the settings of the target area 500, and the detection of the position information of the user terminal 5. This determination can be realized between the user terminal 5 and the operator system 1 using a known technical means such as a GPS 102. For example, in the example of FIG. 6 described later, if the position coordinates indicated by the GPS position information of the user terminal 5 enter a circular area of the target area 500, it is determined that the user has entered. When determining entry or exit from the target area 500, the date and time are determined as well as the location. The operator system 1 grasps the user's location, date and time, etc. based on communication with the app 50 of the user terminal 5.

The determination of the entry and exit of the user and the user terminal 5 is not limited to the method using GPS, and other technical methods may be applied. Other methods may be, for example, a method using a short-range wireless communication function such as an RFID tag, a beacon, or Bluetooth (registered trademark). Another method may be a method of grasping the wireless communication state between a wireless station in a mobile network and the user terminal 5. When setting the target area 500 in a relatively small area such as an individual store 4 or a tourist spot, a method of installing an RFID tag or a beacon is also effective. Another method may be a method of grasping the position, route, and date and time of use in a means of transportation such as a car, train, bus, or airplane. For example, the function of a car navigation system that communicates with the user terminal 5 may be used. A method of grasping the position, date, and time from the usage history information of accommodation facilities, leisure facilities, etc. may also be used.

When the user enters the target area 500 in step S2, the user terminal 5 automatically starts the app 50 if it is not running, and automatically turns on the digital cart 51. The user can use the on-state digital cart 51 within the target area 500. The user can register product information corresponding to a candidate product for purchase in the on-state digital cart 51.

When setting a target area for each store 4 separately from the target area 500 for the travel destination 400, a location detection function using an RFID tag, beacon, wireless LAN, etc. may be set in advance in the store 4, product 40, or code 41. For example, when the user terminal 5 approaches an RFID tag or the like for each store 4, it is possible to detect that the user terminal 5 has entered the target area for each store 4.

The relationship and operation between the app 50 and the digital cart 51 on the user terminal 5 may be such that the app 50 and the digital cart 51 are started/stopped or enabled/disabled together, or the app 50 is basically in an active state and the digital cart 51 is started/stopped or enabled/disabled.

(3) Step S3 is the registration of products in the digital cart 51 by shopping at stores 4 in the target area 500 and during the travel period. In step S3, the user freely visits the desired stores 4, etc., in the target area 500 of the travel destination 400 and does shopping, etc. The user considers purchasing by looking at the desired actual product 40 (e.g., food, goods, etc.) in the store 4 and confirming it. For example, when the user has a product 40 that the user wants to purchase in a certain store 4 (e.g., store 4A), the user uses the reader function of the user terminal 5 to read the product information from the code 41 of the product 40 and registers the product information in the digital cart 51. The reader function is a function that cooperates with the app 50, or a part of the app 50. At this time, the user brings the reader function (e.g., camera) of the user terminal 5 close to the code 41 attached to the product 40 by holding it over it, etc., and has the code 41 read by the reader function. The code 41 is, for example, a barcode or a QR code (registered trademark). Code 41 is a medium on which product information, including at least information for identifying product 40 (product identification information, product code) and attribute information and related information of product 40, is recorded in the form of a code. Application 50 of user terminal 5 identifies product 40 from the read information and transmits at least the product identification information to the server of business operator system 1 via communication network 101.

The above-mentioned reader function is not limited in detail, but for example, it is a function that takes an image of the code 41 using a camera, decodes the code information from the code image, and reads product identification information, etc. Based on the product information read by the reader function, the app 50 of the user terminal 5 communicates with the server of the business system 1 to confirm the product 40 and obtain detailed product information. If the product 40 is a product registered in the product master of the business system 1, that is, if it is a target product in this system, the app 50 of the user terminal 5 obtains product information corresponding to the product 40 from the server. The user terminal 5 uses the obtained product information to additionally register product information corresponding to the product 40 (a candidate product for purchase) in the digital cart 51 of the app 50.

The code 41 may be a medium implemented with an IC chip or the like (e.g., an RFID tag). The code 41 may be attached to the packaging or display shelf of the product 40, or the code 41 may be prepared in a catalog or the like separately from the product 40. The store system or website of the store 4 may provide something equivalent to the code 41. Reading information from the product 40 is not limited to the method using the reader function. For example, a method may be used in which the camera of the user terminal 5 takes an image of the product 40 itself displayed in the store 4 or an image of the product in a catalog or the like, and the product is identified from the captured image by image processing. A method of reading information from an RFID tag or the like by short-range wireless communication may also be applied.

If the user wishes to immediately purchase the product 40 from the store 4, the user can do so through a normal payment system, separate from this system, for example, by paying at the POS register of the store 4. For example, if the product 40 is a food item that the user wants to eat immediately, the user can immediately purchase and pay for the food item on the spot.

The app 50 of the user terminal 5 communicates with the server of the business operator system 1, and sends the read product identification information and current location information from the GPS 102, etc., to the server of the business operator system 1 as a request, and after confirmation by the business operator system 1, obtains the product information from the business operator system 1. The server of the business operator system 1 searches the product master of the product DB 204 based on the product identification information received from the app 50 of the user terminal 5, and confirms whether the product 40 is a target product (normal product or return gift product) registered in the product master. If it is a target product, the server of the business operator system 1 reads detailed product information from the product master and sends it to the app 50 of the user terminal 5 as a response. The server can also identify the area where the user is currently located, the store 4, the relevant local government (donation destination in the case of hometown tax payment), etc., from the current location information of the user terminal 5.

The product information in the product master contains the product code, product name, price, retailer, region, local government, and a flag related to hometown tax donations (see FIG. 12 below). The flag is information that indicates whether the product 40 is eligible for a hometown tax donation return gift in that local government. As the product master also contains flags and local government information, it is easy to determine the local government to which donations are to be made in the case of hometown tax donations, allowing for a smooth donation process.

In this example, the information obtained by reading the code 41 includes at least product identification information, and detailed product information is obtained from the product master of the business operator system 1. This is not limited to the above, and detailed product information may be obtained from the code 41, a store system, etc.

The app 50 of the user terminal 5 creates and registers product information for the product 40 in the digital cart 51 as information on a candidate product for purchase, based on the product information obtained from the server of the business operator system 1. At this point, the product information is maintained as a candidate product for purchase status, not a confirmed purchase status, as a management status. The app 50 displays the product information to be registered on the screen of the digital cart 51 (see, for example, Figures 8 and 9 described below).

In the first embodiment, when the user registers the product 40 in the digital cart 51 in step S3, the product is registered as a candidate product with a purchase candidate status, but this is not limited to the above. In a modified example, the product may be registered as a confirmed purchase product from the beginning, in other words, there may be no distinction between a candidate purchase status and a confirmed purchase status. Also, for example, when reading from the code 41, the user may be able to select between registration as a candidate purchase or registration as a confirmed purchase on the screens of Figures 8 and 9 described below.

In the first embodiment, the information of the digital cart 51 is configured and stored locally, that is, both on the app 50 side of the user terminal 5 and on the server side of the business operator system 1. The information on the app 50 side and the information on the server side are appropriately synchronized so that their contents match. However, the information of the digital cart 51 may be configured and stored either on the app 50 side of the user terminal 5 or on the server side of the business operator system 1.

(4) Step S4 is a product registration step similar to step S3. In step S4, the user similarly visits a desired store 4 (e.g., store 4B) and freely shops, etc. As a result of steps S3 and S4, product information of one or more products 40 that the user has registered as potential purchases is stored as a list in the user's digital cart 51. The app 50 displays information of the registered one or more products on the screen of the digital cart 51 (e.g., FIG. 9 described below).

(5) Step S5 is a step for confirming product information in the digital cart 51 and sorting the products into a confirmed purchase or a cancelled purchase, although it is not essential. During the trip, the user can operate the application 50 of the user terminal 5 as needed to view the screen of the digital cart 51 and check the information of the products that can be purchased and are stored in the digital cart 51 (see Figs. 8 and 9 described below). The user can also freely sort each of the products that can be purchased and registered in the digital cart 51 into a confirmed purchase or a cancelled purchase, etc. (see Fig. 8 (C) described below, etc.). The user can sort the products that the user wants to confirm the purchase of among the products that are registered in the digital cart 51 with a status of a candidate for purchase into a group with a confirmed purchase status by a specified operation. The user can also sort the products that the user wants to cancel the purchase of among the products that are registered in the digital cart 51 with a status of a candidate for purchase into a group with a cancelled purchase status by a specified operation. Products that are in a confirmed purchase status are subject to automatic payment in the following step S7.

Note that the allocation in step S5 is typically assumed to be performed before the user leaves the target area 500 at the end of the trip, but this is not essential. Even if the user does not perform this allocation, confirmation, allocation, or automatic processing can be performed when the user leaves the target area 500, as described below. Note that even after the allocation in step S5, additional product information can be registered to the digital cart 51 as in step S3.

In the first embodiment, even when a purchase cancellation operation is performed, the product information remains in the digital cart 51 as a purchase cancellation status, but this is not limiting. When a purchase cancellation operation is performed, the product information may be deleted from the digital cart 51.

In the first embodiment, a function for changing and allocating product status as in step S5 is provided, but this is not limiting and this function may be omitted. In a modified example, the main operation is to register and delete product information in the digital cart 51, and operations such as confirming purchase by the user are not required. In this modified example, in step S7, the product information registered in the digital cart 51 is automatically considered to be a confirmed purchase and payment is made.

In addition, the system automatically checks whether the product information registered in the digital cart 51 is eligible for the hometown tax return gift based on confirmation of flags, etc. between the app 50 and the server, and stores the information separately. When displaying product information on the screen of the digital cart 51, the app 50 automatically displays information such as whether the product is eligible for the hometown tax return gift to the user in an easy-to-understand manner (see, for example, FIG. 8B, FIG. 9B and FIG. 9C, which will be described later). For example, the app 50 and the server manage the product information in the digital cart 51 by dividing it into a group of return gift products that are eligible for the hometown tax return gift (in other words, items eligible for donation) and a group of regular products that are not eligible for the hometown tax return gift (in other words, items eligible for regular purchase, not eligible for donation). This makes it easy for users to check and consider whether each product 40 is eligible for hometown tax return. In addition, the app 50 and the server display the return gift items on the digital cart 51 screen (such as FIG. 9(C) described below) separately for normal purchase without a donation and for purchase together with a donation, allowing the user to select.

(6) At the end of the trip, the user travels from the travel destination 400 to the home 8 by public transportation (shown as the return journey 432). Step S6 indicates that the user terminal 5 leaves the target area 500 (exits). In step S6, the user carrying the user terminal 5 leaves the target area 500 corresponding to the travel destination 400. The app 50 of the user terminal 5 and the server of the operator system 1 determine whether the user terminal 5 has left the target area 500 based on the user's travel information, the setting information of the target area 500, and the detection of the GPS location information of the user terminal 5. This exit determination can be made in the same way as the determination at the time of entry in step S2.

When the user terminal 5 leaves the target area 500 in step S6, the app 50 of the user terminal 5 turns off the digital cart 51. This disables additional purchases, i.e., the registration of additional product information, in the user's digital cart 51. Even in this off state, product information already registered in the digital cart 51 is retained. The app 50 of the user terminal 5 and the server of the business operator system 1 decide to confirm or cancel the purchase of the products registered in the user's digital cart 51.

(7) Step S7 is a payment process including a donation process. First, the payment process when the product to be paid for is a normal product will be described, and the payment process including a donation process when the product to be paid for is a return gift product will be described later. Immediately after step S6, in step S7, the app 50 of the user terminal 5 automatically performs payment processing for the product with a purchase confirmation status registered in the digital cart 51 at that time. The payment processing is performed between the user terminal 5, the business operator system 1, and the payment system 6 using the user's payment information. The user terminal 5 performs payment processing through the business operator system 1 to the payment system 6 of FIG. 1 corresponding to the payment method used by the user (e.g., a credit card). When payment processing is performed by confirming the purchase of the product information in the digital cart 51, the cart management unit 15 records the status of the product as purchased/paid in the cart DB 205. The app 50, for example, deletes the product information of the product on the screen of the digital cart 51 to make it empty.

In addition, in the first embodiment, if the user terminal 5 goes out of the target area 500 without performing the above-mentioned sorting (step S5), there may be cases where products in the purchase candidate status remain in the digital cart 51 at that time. In this case, it is possible to deal with it in the following manner. In the first embodiment, the application 50 of the user terminal 5 decides to confirm the purchase or cancel the purchase for the products in the purchase candidate status registered in the digital cart 51 at that time, and performs the payment process. In the first embodiment, at this time, the application 50 and the server automatically consider the products in the purchase candidate status in the digital cart 51 as being confirmed to be purchased, and execute the payment process, etc., without the user's confirmation or decision operation. In the modified example, the application 50 asks the user on a screen (similar to FIG. 8 to FIG. 10, for example) whether to make a payment as a purchase confirmation or a purchase cancellation for each product in the purchase candidate status, and accepts the decision operation. On the other hand, when the user performs the purchase confirmation operation, the application 50 changes the status of the product in the purchase candidate status to a purchase confirmation status and performs the payment process. When a purchase cancellation operation is performed, the app 50 changes the status of that product to "purchase canceled" and does not perform payment processing.

The following may be a variation of step S7. The app 50 of the user terminal 5 asks the user whether or not to execute payment for the product in the digital cart 51 that has a purchase confirmed status, and accepts a confirm operation. If the app 50 receives a confirm operation, it executes the payment process, and if it receives a denial operation, it does not execute the payment process. Also, the user may input payment information at the time of step S7.

The following variations regarding payment are also possible. The user issues an instruction to execute payment for the desired product at any desired timing on the screen of the app 50 on the user terminal 5. For example, the user can execute payment in advance for some of the confirmed purchase products in the digital cart 51 while in the target area 500 during the trip by performing a specified operation (similar to (C) in Figure 9).

Furthermore, in step S7, the donation process when the product to be paid for is a return gift product is as follows. This donation process is basically realized by a payment process for the payment system 6. The application 50 of the user terminal 5 instructs the payment system 6 to make a payment for the donation amount through the business operator system 1, and transmits donation information to the local government system 3. The payment management unit 16 and the tax payment management unit 13 of the business operator system 1 record information for management during the payment process, including the donation process. The application 50 of the user terminal 5 automatically performs a donation process related to hometown tax payment for the return gift product that is a purchased product. If the purchased product is a return gift product, the business operator system 1 performs a donation process to the local government associated with the product so that the purchased product is donated as a return gift (donation at the same time as purchase) based on the flag. This donation process is a part of the process that constitutes the procedure for hometown tax payment to the local government associated with the product 40 purchased at the travel destination 400 and the local government where the user resides. The donation process is carried out between the user terminal 5, the business operator system 1, and the local government system 3 using the user's tax payment information. The user terminal 5 transmits donation information for the hometown tax payment related to the purchased return gift product via the business operator system 1 to the hometown tax payment acceptance unit 31 of the local government system 3 of the local government associated with the product 40 and the target area 500. The hometown tax payment acceptance unit 31 of the local government system 3 carries out the hometown tax payment procedure (particularly the acceptance of the donation) for the user based on the received donation information.

The rules for settling the donation amount can be determined in advance between the parties involved. Specifically, this settlement can be achieved, for example, as follows: The app 50 or server instructs the payment system 6 to deposit the donation amount for the return gift product into the account of the business operator system 1. Next, the business operator system 1 instructs the payment system 6 to deposit the donation amount into the account of the donation recipient's local government system 3.

After that, settlement for the price of the return gift may be made between the local government system 3 and the product seller 2 (store 4) at will, depending on the system of each local government. For example, the price of the return gift may be paid from the local government system 3 to the product seller 2 (see FIG. 15 below). In a modified example, the system may also be made to handle settlement between the local government system 3 and the product seller 2. For example, in step S7, the price of the return gift may be deposited from the user terminal 5 to the product seller 2 such as the store 4 in relation to the donation amount to the local government, and the amount obtained by deducting the price of the return gift from the donation amount may be deposited to the local government.

During the donation process, donation information may be sent from the user terminal 5 to the local government system 3, or donation information may be sent from the business operator system 1 to the local government system 3. In other words, the business operator system 1 may be an intermediary between each user and each local government and support the hometown tax payment procedures according to the local government. Furthermore, during the donation process in step S7, the user may input tax payment information. Furthermore, in step S7, before sending the donation information, the app 50 of the user terminal 5 may ask the user on the screen whether or not they wish to carry out the hometown tax payment process, and may accept a confirmation operation.

The donation information sent in step S7 includes, for example, the user's name, contact information, and address based on the tax payment information, whether or not to apply for a one-stop application, information on the region and store where the purchase was made, information on the purchased product (i.e., return gift information), information on the target local government, and monetary information such as the donation amount. In an example of the current system, when a hometown tax payment application (corresponding donation information) is sent to a local government, the local government will send a document requesting verification of the user's personal information, for example, a request to send a copy of the user's Individual Number card. In FIG. 4, the user's identity can be confirmed by exchanging information such as the identity verification card 80 required for the hometown tax payment between the user terminal 5 and the hometown tax payment reception unit 31 of the local government system 3 via the business operator system 1 (by data communication or mail, etc.).

(8) Step S8 is a delivery process. In step S8 following step S7, the application 50 of the user terminal 5 automatically performs delivery processing for the product for which payment processing was performed in step S7. The delivery process is performed between the user terminal 5, the business system 1, and the delivery system 7 using the user's delivery information. The user terminal 5 transmits a delivery instruction for the purchased product (regular product or return gift product) to the delivery system 7 through the business system 1. The delivery instruction includes information on the purchased product, the user's delivery address, etc. The delivery management unit 17 records management information such as whether or not the product has been delivered. The delivery system 7 delivers the purchased product to the delivery destination home 8, etc. in accordance with the delivery instruction (indicated by product delivery 71, 72 in Figures 1 and 4). Product delivery 71 indicates the case where the purchased product is a regular product, and product delivery 72 indicates the case where the purchased product is a return gift product. In addition, the user may input delivery information at the time of step S8. Also, in step S8, the application 50 of the user terminal 5 may display on the screen a confirmation to the user as to whether or not it is OK to execute the delivery process, and may accept a confirmation operation.

In the first embodiment (FIG. 4), the product 40 is delivered and handed over to the user through the delivery system 7 (step S8) together with payment outside the target area 500 (step S7), but this is not limiting. The delivery destination of the product 40 may be a designated delivery destination within or outside the target area 500, such as an accommodation facility or a transportation facility, instead of the home 8, in accordance with the payment for each product 40. For example, the product 40 may be handed over to the user at the store 4 where the user purchased the product 40, another store, or a specified location, in response to the user's delivery designation operation on the screen of the app 50. For example, for a product registered in the digital cart 51 during a trip, the product 40 that was reserved at a specified location when returning from the trip may be handed over as one of the delivery designations. In this case, the user can check the received product 40 on the way back to the home 8 from the travel destination 400. The specified location of delivery may be the boundary of the target area 500, or between the target area 500 and the home 8. Examples of the predetermined location include product delivery counters and parcel lockers at tourist spots, shopping malls, convenience stores, train stations, airports, etc. The predetermined location may also be a "roadside station" (a regional development facility) or a service area along the road.

The delivery process in step S8 is not essential. The modified system does not have a function related to delivery. In that case, product delivery may be performed individually by the user or store 4 to the delivery system 7. After the user exits in step S6 and completes the processes in steps S7 to S8, the app 50 on the user terminal 5 may automatically terminate the digital cart 51 or the app 50.

As a result of the processing of steps S7 to S8, the purchased product (regular product or gift 9) is delivered to the user's home 8 at a later date. The user receives the product at home 8 after returning from the trip.

As in step S7 above, in this system, the user can use the digital cart 51 to purchase product 40 at the travel destination 400 (corresponding target area 500), and, if the product 40 is eligible for a hometown tax return gift, can easily make a hometown tax donation to the local government associated with the product, using the product 40 as a return gift, along with payment and delivery. Hometown tax donations can be made particularly efficiently when one-stop applications are available for each local government. If the hometown tax donation procedures (in other words, the reception interface) differ for each local government, the business operator system 1 may support individual procedures with each individual local government. At least those parts of the hometown tax donation procedures that can be automated through data communication and electronicization on the communication network 101 can be automated through the business operator system 1.

The system of the first embodiment can automatically process product purchases, payments (including donations), and delivery on the digital cart 51 without the need for user operation or confirmation when certain conditions related to the location and time of the user's trip are met. In the first embodiment, the certain condition is the timing when the user terminal 5 leaves the target area 500, prioritizing user convenience. The certain condition can be set in advance in the system, and may be set by the user using a user setting function in particular. In addition, in a modified example described below, the certain condition is that payment processing and the like is performed when a preset period has elapsed.

5. Processing flow
Fig. 5 shows a flow diagram of main processes in the local revitalization system of the first embodiment, which also corresponds to the example of Fig. 4. The flow in Fig. 5 has steps S101 to S111.

In step S101, the user performs initial settings for the digital cart 51 using the application 50 on the user terminal 5, and sets travel information such as the travel destination 400 and schedule. The business operator system 1 sets the information of the user's digital cart 51 in the cart DB 205, sets the travel information in the user DB 202, and sets the target area 500 corresponding to the travel destination 400, etc.

In step S102, the user terminal 5 and the operator system 1 confirm the current location of the user terminal 5 based on the GPS location information of the user terminal 5, and determine/detect whether the user terminal 5 has entered the target area 500 corresponding to the travel destination 400.

If entry is detected, in step S103, the application 50 of the user terminal 5 turns on the digital cart 51. At this time, an authentication process is automatically performed between the user terminal 5 and the authentication unit 12 of the business system 1. At that time, it is also confirmed whether the payment method described in the pre-set payment information is valid or not. For example, the expiration date of the credit card is confirmed.

The user is free to shop at stores 4 within the target area 500. In step S104, the user terminal 5 uses a reader function to read information from the code 41 of the product 40 based on the user's operation. The app 50 of the user terminal 5 transmits the read product identification information, current location information, etc. to the server of the business operator system 1.

In step S105, the server (communication unit 10) of the business operator system 1 receives information from the app 50 of the user terminal 5. The cart management unit 15 searches the product master of the product DB 204 based on the product identification information from the user terminal 5, and if there is product information associated with the product identification information, reads it and sends it to the user terminal 5. In step S105, the business operator system 1 confirms whether the product 40 is an eligible product in this system and confirms the attributes of the product 40. This confirmation of attributes includes confirmation of whether the product 40 is eligible for a hometown tax return gift. In a modified example, in step S105, the business operator system 1 may also check the inventory when providing the product 40.

In step S106, the app 50 of the user terminal 5 receives and acquires the product information from the server of the business operator system 1, and registers it as product information of the product in the purchase candidate status in the digital cart 51. The app 50 updates the display state on the digital cart 51 screen on the display screen of the user terminal 5 so as to additionally register the product information. The app 50 also displays the status of each registered product on the digital cart 51 screen, such as the purchase candidate status, and also clearly displays whether or not the product is eligible for a hometown tax return gift based on a flag (see FIG. 8, etc., described below).

The processing of steps S104 to S106 is repeated for each purchase of each product 40 at each store 4 in the travel destination 400, as in steps S3 and S4 in FIG. 4. Note that in the first embodiment, purchasing a product 40 at a store 4 refers to registering product information as a potential purchase product in the digital cart 51, and then later making a payment or the like to confirm the purchase. This registration is provisional, and it is possible to confirm the purchase or cancel the purchase as described above.

In step S107, during the trip, the user operates the app 50 on the user terminal 5 at a time of their choice, and can check the product information in the digital cart 51 as a list on the app 50 screen. The digital cart 51 screen allows the user to check the status of each product. The status can be purchase candidate, confirmed purchase, purchase canceled, etc. The digital cart 51 screen also accepts allocation operations to change the status. On this screen, each product candidate for purchase can be allocated as confirmed purchase or canceled purchase. When the user decides to actually purchase a product candidate for purchase, the user operates it so that the status becomes confirmed purchase. The user can also change the product's status back to candidate for purchase status on the screen as appropriate.

In step S108, the user terminal 5 and the operator system 1 confirm the location of the user terminal 5 based on the GPS location information of the user terminal 5, and determine/detect whether the user terminal 5 has left the target area 500 corresponding to the travel destination 400.

If an exit is detected, in step S109, the application 50 of the user terminal 5 turns off the digital cart 51. At this time, an authentication process is automatically performed between the user terminal 5 and the business operator system 1, and at this time, it is also confirmed whether the payment method described in the pre-set payment information is valid or not.

In step S110, the app 50 of the user terminal 5 executes payment processing (including donation processing) between the business operator system 1 and the purchased products in the digital cart 51. At this time, the payment processing is performed between the payment system 6 and the payment method confirmed in steps S103 and S109. As described above, for the return gift products among the purchased products, the donation processing (payment related to the donation and transmission of donation information to the local government system 3) is performed through the payment system 7. The donation information includes donation amount information calculated by the app 50 and the server. For example, the price of a purchased product (return gift product) is X yen, the donation amount is Y yen, and the donation amount Y yen is paid to the local government (Figure 15 described below).

Next, in step S111, the application 50 of the user terminal 5 executes a delivery process between the business system 1 and the purchased product in the digital cart 51 for which payment has been processed. At this time, the delivery process is performed between the application 50 of the user terminal 5 and the business system 1 as described above.

[6-1. Target area]
The setting of the target area 500 in Fig. 4 will be described. In the first embodiment, the target area 500 is set in the following manner. The target area 500 corresponds to the user's travel destination 400 and digital cart 51, and is an area that is subject to control of the purchase and payment of the product 40, in other words, a region, area, range, etc. on a map. The target area 500 is also associated with a range (also referred to as "payment range") for collectively controlling the above-mentioned payment and delivery processes.

Figure 6 shows a first example of setting the target area 500. In this first example, a circular target area 500 is set on a map to encompass the region of the travel destination 400. The region of the travel destination 400 is, for example, a large area such as a prefecture. The region of the travel destination 400 may be at least one store 4, a tourist spot, or a city, ward, town, or village. In this case, the circular target area 500 is set using a center position 511 expressed by latitude and longitude in the region, and a radius 512.

In the target area 500, the digital cart 51 is turned on. In addition, within a large area such as a prefecture, smaller areas such as cities, wards, towns, and villages are hierarchically included. In this example, the large area has smaller areas A to F. Within each area, there are stores 4 and tourist spots. Furthermore, even smaller area units and areas may be set within a small area unit such as a town. The user visits stores 4 in the desired area to shop. In the example of FIG. 6, the user can move freely within the prefecture or other area of the travel destination 400 to shop. During the trip, the user can store multiple product information in the digital cart 51 until they leave the area, and can freely consider whether to purchase, what to choose, etc.

In the first embodiment, the target area 500 is set by the business operator system 1 in response to the user's designation of the travel destination 400. Specifically, a circular target area 500 encompassing the region of the travel destination 400 is automatically set as shown in FIG. 6 using an area master (FIG. 13) described below. In a modified example, the user may be able to set the target area 500 in the app 50. For example, the user may designate the region of the travel destination 400 by tapping or encircling it on the map screen of the app 50, or by entering text.

Hometown tax payments are administered by local government units such as prefectures, cities, wards, towns, and villages, and there are jurisdictional areas for these units. As such, one method is for the target area 500 to be set to match the area of such a local government. It is also desirable to set the target area 500 appropriately to match the user's travel destination 400. Taking these points into consideration, in this system, the target area 500 is set as a circular area, as shown in FIG. 6, so as to encompass at least one local government that corresponds to the region of the user's travel destination 400.

The shape of the target area 500 is not limited to a circle as shown in FIG. 6, but can be any shape. In a modified example, the target area may have a more detailed shape that matches the shape of the boundary of the area on the map. In this example, making the target area 500 circular has the advantage of making it easier to determine entry and exit (steps S2 and S6).

In the example of FIG. 6, a circular target area 500 is set to encompass the shape of the region (e.g. prefecture) of the travel destination 400. A payment range is also set for this target area 500. In this example, the target area = the payment range. The payment range is the range for determining whether or not to execute the payment in step S7. In the first embodiment, the payment range is used to control not only the payment but also the associated delivery (step S8). As a variant, a range may be set for each process of payment (step S7) and delivery (step S8). Also, different ranges may be set for normal products and return gift products (for donation processing).

Setting a circular target area (payment range) as in the example of Figure 6 also has the following advantage. Even if the user travels near the border of the region (e.g. prefecture) of the travel destination 400 within this target area 500, the payment process of step S7 will not be activated. This is therefore preferable as the digital cart 51 is stably held within the target area 500.

In this example, the target area is the same as the payment range, but this is not limited to the above, and a payment range with a different shape may be set separately from the target area 500. For example, the shape of the region of the travel destination 400 may be set as the target area 500, and a larger area such as a circle may be set as the payment range.

In the first embodiment, the position of the user terminal 5 is grasped using the GPS 102 as described above. The position of the user terminal 5 may be expressed as a circular range with a center at a position represented by the latitude and longitude in the GPS position information, with a radius that takes into account positioning errors.

The user's travel destination 400 is designated in advance as the travel information described above, but is not limited to this and may be automatically determined based on the location information of the user terminal 5. The target area 500, etc. may be automatically set according to the region of the automatically determined travel destination 400.

[6-2. Target area]
Other setting examples of the target area 500 are as follows. In the first example of Fig. 6, one target area corresponding to the travel destination 400 is set, but multiple target areas corresponding to the travel destination 400 may be set. There may be a case where the user's travel destination 400 is a trip to multiple spatially separated areas (e.g., tourist spots, etc.) in sequence.

Figure 7 shows a second example of the setting of the target area 500 in the modified example. This second example shows a case where the target area 500 corresponding to the travel destination 400 on the map is composed of multiple spatially separated target areas (also described as sub-areas). For example, a case where a certain travel route is roughly composed of three sub-areas 601 to 603 is shown. For example, the route is composed of a first sub-area 601 (including area A), a second sub-area 602 (including area B), and a third sub-area 601 (including area C), in that order. The sub-areas may be spatially separated through movement by transportation. For example, the first sub-area 601 is set as a circle that includes area A using a center position 611 and a radius. The second sub-area 602 and the third sub-area 603 are also set as circles. For example, the user first shops at a store 4a in area A, and product A is registered in the digital cart 51. When user terminal 5 moves out of sub-area 601, payment processing etc. for product A is carried out. Next, the user moves to area B and, for example, shops at store 4b, which causes product B to be registered in digital cart 51. When user terminal 5 moves out of sub-area 602, payment processing etc. for product B is carried out. In this way, in the second example, payment, delivery etc. are controlled using the payment range for each sub-area.

In the second example, the user visits multiple regions in sequence along the planned travel route and itinerary. In each sub-area corresponding to a region, product purchases and the like can be made using the digital cart 51. As another example, even if the travel route has not been decided, i.e., the traveler moves freely, similar control is possible by appropriately setting sub-areas for each region in which the user is staying based on the current location of the user terminal 5. A sub-area may also be set for each store 4 targeted by this system. When the user terminal 5 enters a sub-area for each store 4, the digital cart 51 is automatically turned on and shopping becomes possible, and when the user terminal 5 leaves the sub-area, payment and the like is made.

When subareas (payment ranges) are set in relatively small regional units (e.g., towns), donation processing (step S7) related to hometown tax payments to the corresponding local government can be performed for each subarea. This has the advantage that users can easily determine and recognize the connection between products purchased in the area and donations to the local government corresponding to that area.

In the second example of FIG. 7, as in the first example of FIG. 6, it is also possible to set one target area 500 that encompasses the entire travel route. The route and target area 500 may also include the round trip between home 8 and travel destination 400.

[7. Target period]
In a modified example, as another method related to control of the digital cart 51 and payment, etc., a method using a target period (in other words, a time limit) as a predetermined condition is also possible. When a user sets a travel itinerary, the business operator system 1 sets a target period for control according to the itinerary. Either a method of control using only the target period as a condition or a method of control using both the target period and the target area 500 is possible.

An example of a method of control based only on the target period is as follows. During the target period during the trip (for example, the three days from May 1st to May 3rd), the business operator system 1 turns on shopping on the digital cart 51 and retains product information regardless of the location of the user terminal 5. When the target period has passed, the business operator system 1 turns off the digital cart 51 and performs payment processing (step S7) etc. In this method, the user can freely enter and leave the travel destination 400 area during the target period, and payment processing etc. is not performed during that time. Even if the user is within the travel destination 400 area, payment processing etc. is performed when the target period has passed.

An example of a method for controlling both the target period and the target area is as follows. If the user terminal 5 is located within the target area during the target period of the trip, the business operator system 1 turns on shopping on the digital cart 51 and retains product information. If the user terminal 5 leaves the target area and the target period has passed, the business operator system 1 turns off the digital cart 51 and performs payment processing (step S7), etc.

In the above method, for example, the user can register products in the digital cart 51 on the first day of the trip, and can check and allocate the products in the digital cart 51 while staying at the hotel, etc. The same applies to the second and third days. On the third day, when the user leaves the target area 500 and returns, payment is made for the products in the digital cart 51 when the target period has passed. Furthermore, when the target period is used as the specified condition, an additional condition may be to be within the target area, for example, once a day, as a regular check.

[8-1. Screen example]
8 and 9 show examples of display of a digital cart 51 and the like on an example screen of the application 50 of the user terminal 5. FIG.

(A) of FIG. 8 shows, as a first example, an example screen when the user terminal 5 registers a product recognized by reading the code 41 of the product 40 with the reader function in the digital cart 51 when the user is shopping at the store 4 as shown in FIG. 4. The top of this screen displays an image 801 representing the read product and information (e.g., product name and price). The bottom displays an image 802 (cart icon) representing the digital cart 51. The number of products currently registered in the digital cart 51 is also displayed in the image 802 as a number (e.g., 4). When registering on this screen, the user performs a predetermined operation such as touching and swiping the image 801 with his/her finger to move it to the position of the image 802. This registers the product information of the read product in the digital cart 51. The predetermined operation may be a tap or a flick. When registering, the status of the product is first set to a purchase candidate status. If this operation is not performed, the read product is not registered in the digital cart 51 (registration canceled).

(B) of FIG. 8 shows, as a second example, an example screen in which the scanned product (or a product selected from within the digital cart 51) is eligible for a hometown tax return gift. An image 803 representing the scanned product and information are displayed at the top of this screen. This image 803 is displayed with an image such as a mark (in this example, a ribbon) indicating that the product is eligible for a hometown tax return gift. In addition, as shown in the speech bubble image below the image 803, an explanation of the product being eligible for a hometown tax return gift may be displayed, and further detailed information may be displayed in response to clicking on a link URL, etc. Examples of detailed information include detailed information about the hometown tax return gift of the corresponding local government and detailed explanatory information about the product.

8C is a third example of a display example of the digital cart 51 on the screen of the application 50, showing a screen example relating to a function for allocating "buy" (confirmed purchase) and "don't buy" (cancelled purchase) for each candidate product in the digital cart 51. In this example, on this screen, images 804 of multiple products (corresponding product information) with a candidate purchase status registered in the digital cart 51 are displayed, for example, in a vertical line, and can be scrolled vertically. When the user confirms the purchase of each product ("buy"), the user moves the image 804 to the right of the screen by swiping with a finger (or pressing the right button, etc.). By such a predetermined operation, the product is changed from the candidate purchase status to the confirmed purchase status. The product with the confirmed purchase status is added to the purchase confirmation box (for example, (A) of FIG. 9) of the digital cart 51. On the other hand, when the user cancels the purchase of the product ("don't buy"), the user moves the image corresponding to the product to the left of the screen by swiping with a finger (or pressing the left button, etc.). This changes the product's status from Candidate for Purchase to Cancelled Purchase. The product with Cancelled Purchase status is added to the Cancelled Purchase box. On this screen, the images of the assigned products disappear from the vertical column, and the images of the remaining products are displayed vertically, squeezed in.

In the first embodiment, even if a user cancels a purchase of a product in the digital cart 51, the product information is not deleted but is retained in the purchase cancellation box. This allows the user to later change the product from the purchase cancellation status back to a purchase candidate or confirmed purchase status. In other embodiments, the product information is deleted when a purchase is canceled.

[8-2. Screen examples]
9A shows, as a fourth example, an example screen for displaying a list of the contents and status of the digital cart 51. On this screen, the app 50 displays information on multiple products in the digital cart 51 in boxes (columns) categorized by status. This screen has a purchase confirmation box 901, a potential purchase box 902, and a purchase cancellation box 903. For example, products A and B with a purchase confirmation status are registered in the purchase confirmation box 901.

The user can also change the status of each product on this screen. The arrows show examples of status changes. For example, the user can select a desired product in the purchase candidate box 902 and move it to the purchase confirmation box 901 or purchase cancellation box 903 by swiping or the like. The status changes accordingly. Similarly, products in the purchase confirmation box 901 or purchase cancellation box 903 can also be moved to other boxes.

9B is a fifth example of a screen displaying multiple product information items with a purchase candidate status in, for example, the purchase candidate box 902 in the digital cart 51, and in particular, an example of displaying an image 904 for each purchase candidate product, indicating whether or not it is eligible for a hometown tax return gift based on a flag. In this example, for three products D, E, and F, product F is displayed with an image 904 such as a mark (in this example, a ribbon) indicating that it is eligible for a hometown tax return gift. In the screens of FIG. 9A and FIG. 9B, multiple product information items may be displayed in a group state classified according to whether or not it is eligible for a hometown tax return gift based on a flag. In FIG. 9B, products D and E are displayed as a group of regular products, and product F is displayed as a group of return gift products. In addition, the screen of the digital cart 51 may be arranged and displayed in a desired order or position based on the user's operation.

In addition, the above app screen may have a payment execution instruction button for first paying for a regular product selected by the user. When the user presses this payment execution instruction button, payment processing is performed immediately for only this product, even if the user is within the target area 500. In other words, the basic timing of payment in this system is when the user leaves the target area 500 as in step S7 described above, but it is also possible to complete payment individually at an earlier timing depending on the user's wishes. For example, if the user wants to immediately consume a product 40 such as food within the target area 500, the user can purchase and consume the product using a regular payment method separate from this system as described above, or can consume the product using the advance payment function described above.

9C shows, as a sixth example, an example screen displaying product information of a gift item (e.g., product F) selected by a user from within the digital cart 51 at or before the payment in step S7. This screen displays detailed information such as the name of product F and a mark representing the gift item. This screen displays detailed information about the amount, and a button that allows the user to select between a normal purchase and a donation (a simultaneous donation with purchase). This screen displays the normal amount for normal purchase of product F (when no donation is made), a purchase button 907 for purchasing product F at the normal amount, the donation amount for donating product F as a gift in return for hometown tax donation, and a donation button 908 for making a donation at the donation amount. On this screen, the user can freely select whether to purchase the gift item normally or to purchase it at the same time as making a donation related to hometown tax donation. Also, just like with regular products, it may be possible for a user to immediately perform payment processing (including donation processing) for a desired gift item selected by the user at any time within the target area 500 by pressing a button or the like on a similar screen.

The app 50 and the server (tax payment management unit 13) calculate this donation amount and display it on the screen. The price of the return gift product F (the same as the normal price for a normal purchase) is X yen (for example, 6,000 yen), and the donation amount is Y yen (also shown in FIG. 15 described later). As a condition according to the system of the local government, it is predetermined that the amount of the return gift must be 30% or less of the donation amount. For example, the condition is Y = X / 0.3. Then, for example, the donation amount Y yen can be calculated as Y = 6,000 yen / 0.3 = 20,000 yen. Based on the conditions, the business operator system 1 automatically calculates the necessary donation amount (Y yen) for a donation in which the purchased product is a return gift, and the donation information including the donation amount is included in the donation process.

As described above, in the first embodiment, the user can consider product purchase options in the digital cart 51 through intuitive and simple operations on the screen of the application 50 of the user terminal 5.

[8-3. Screen examples]
FIG. 10 shows another example of a screen of the application 50 of the user terminal 5. The screen of FIG. 10 is an example of displaying the contents and status of the digital cart 51 in a table format. This table displays product information of candidate products for purchase in each row, and has column items such as number, date and time, product image, product name (or product code), purchase store, purchase region, purchase amount, hometown tax return gift (flag), donation, purchase confirmation, and deletion. Other column items of the table may include a prepayment button. Information of multiple products in the digital cart 51 can be sorted and displayed according to selected conditions (for example, order of registration, order of product category, order of price, etc.).

The "date and time" field is the date and time when the product information of the product 40 was registered. The "product image" field displays a product image (or a camera image) obtained from the product master of the product DB 204 in FIG. 2. The "product name" field displays the product name (or product code), and may display a category such as food or goods. The "purchase store" field displays information corresponding to the store 4 or product seller 2 where the product 40 is purchased. The "purchase area" field displays the area such as a city, ward, town, or village corresponding to the store where the product 40 was purchased, and may display information on the corresponding local government. The "purchase amount" field displays the amount when the product 40 is normally purchased or when it is purchased at the same time as a donation as a hometown tax return gift. The "hometown tax return gift" field displays whether the product is eligible for hometown tax return gifts based on a flag. For example, if it is eligible, the value is 1, and if not, the value is 0.

In the "Donation" item, if the product 40 is eligible for the hometown tax return gift, a button is displayed in advance to select whether to donate (ON) or not to donate (OFF). If the user wishes to make a donation in the "Donation" item with the product 40 as a return gift, the user turns the button ON, and if not, turns it OFF. The setting value of this "Donation" item is reflected at the timing of the donation process in step S7 when the user terminal 5 goes outside the target area 500 in step S6. In addition, the amount displayed in the "Purchase Amount" item and the total amount field 1001 at the bottom of the screen is automatically calculated and displayed in conjunction with the ON/OFF state of this "Donation" item. Note that the amount may differ between when a donation is made (ON) and when it is not made (OFF). This is because there are conditions for the donation amount when making a hometown tax payment (such as the amount of the return gift being 30% or less of the donation amount). The business operator system 1 (tax payment management unit 13 in FIG. 2) calculates the donation amount for each return gift item when making a hometown tax payment, and displays it on the screen of the app 50 as described above. Note that, similar to (C) in FIG. 9, both the regular purchase amount and the donation amount may be displayed in parallel.

The "Confirm Purchase" item displays a check button to confirm whether or not to purchase the product. If the user wishes to confirm the purchase of the product, he or she presses the check button. This changes the product's status from a candidate for purchase to a confirmed purchase status. The "Delete" item displays a delete button to delete the product information from the digital cart 51. If the user wishes to delete the product information, he or she presses this delete button.

In this example, the total amount column 1001 displays the total amount for products with a purchase confirmation status (check button is checked ON) in the above table. This total amount is displayed broken down into the total donation amount for the return gift product group for which hometown tax is paid, and the total normal purchase amount for the normal product group for which hometown tax is not paid. The business operator system 1 (tax payment management unit 13 in FIG. 2) calculates the total amount for each group and displays it on the screen of the app 50 as described above. In this example, if there are products AA, BB, and CC as three products with a purchase confirmation status, the two products AA and BB are return gift eligible products and are set to be donated (ON). The purchase amounts (= donation amount) of products AA and BB are 5,000 yen and 3,600 yen. The purchase amount of product CC, which is a normal product, is 7,000 yen. Correspondingly, the total amount column 1001 shows the total amount as 15,600 yen, the total amount for hometown tax (donations) as 8,600 yen, and the total amount for regular purchases as 7,000 yen. By looking at the total amount column 1001, users can estimate the total amount based on their current plans for product purchases, etc., and can consider and change whether or not to make a purchase.

As another example, the screen of the digital cart 51 may similarly display the total price for products with a purchase candidate status in the table (check buttons with the check unchecked). Furthermore, although not shown, the screen of the digital cart 51 may further display the travel budget set by the user and the remaining budget obtained by subtracting the total price from the budget. This allows the user to make decisions based on their budget. The screen of the digital cart 51 may also allow an upper limit for the hometown tax donation amount to be set and display the upper limit. When the total price for the return gift products that the user has selected as purchase candidates or confirmed as purchase reaches the upper limit, the app 50 displays this on the screen. This makes it easier for the user to consider making a donation that does not exceed the upper limit.

In addition, the user may operate the total amount of the hometown tax payment in the total amount column 1001 (e.g., a link URL) to display and confirm detailed information regarding the hometown tax payment. This makes it possible to confirm or input the contents of the donation information sent to the local government in the donation process in step S7, for example.

The above screen also has a history item 1002. When the user wishes to view the history information of the digital cart 51, the user operates the history item 1002 by touching or the like. This causes the history information of the digital cart 51 to be displayed on the app screen. As described above, the cart DB 205 also holds the history information of the digital cart 51, so it is possible to display the history information on the app screen. The history information is history information such as product registration, payment (including donations), and delivery at past dates and times.

In a modified example, this history information may be used to enable repurchase of product 40. For example, the system retains the history information of digital cart 51 from when the user leaves target area 500 of travel destination 400 until the user returns to home 8, or for a set period of time after the user returns to home 8. The user then appropriately refers to the history information of digital cart 51 on the screen of app 50, selects a desired product from the information, and presses a purchase instruction button if the user wishes to purchase the product again. This causes the payment and delivery process to be performed for the product. This allows the user to easily repurchase the product. Furthermore, the user can easily make another hometown tax donation in conjunction with the repurchase.

As described above, in the first embodiment, the display of the digital cart 51 on the screen of the app 50 itself allows the user to identify and recognize whether or not each product is eligible for a hometown tax return gift, and, depending on the user's intentions and operations, it is also possible to specify whether or not to make a hometown tax donation at the same time as purchasing each return gift product.

[9-1. Digital Cart Information]
Fig. 11 shows an example of the configuration of digital cart information in the cart DB 205 of Fig. 2. This table of digital cart information has items corresponding to columns, such as number (representing a record for each row), date and time, product code (in other words, product identification information), product image, product name, purchase store, purchase region, local government, purchase amount (normal purchase amount or donation amount), hometown tax return gift target flag, status, donation, payment, delivery, etc. The status is the aforementioned purchase candidate or purchase confirmation, etc. The data example in Fig. 12 corresponds to the screen example in Fig. 11. Other information such as location information of the product 40 may be registered in the digital cart information.

[9-2. Product Master]
FIG. 12 shows an example of the configuration of the product master of the product DB 204 of FIG. 2. The table of the product master has items corresponding to columns, such as number, product code, product name, product image, store, sales area, local government, location (latitude and longitude), flag of target of hometown tax return gift, normal amount, donation amount, etc. The flag indicates whether the product is a target of the hometown tax return gift of the local government of the region. The "location" item indicates the location of the product 40 or the store by GPS latitude and longitude. In this table, both "normal price" and "donation price" (two types) are set and stored as product price information. The "normal amount" item indicates the sales price corresponding to the normal amount when purchasing normally without making a donation. The "donation amount" item indicates the minimum amount condition corresponding to the donation amount when making a donation related to hometown tax (simultaneous purchase with donation). Conditions regarding the amount of return gifts for each local government may be set in the product DB 204, etc. In the illustrated example, the condition is donation amount (Y)=normal amount (X)/0.3.

[9-3. Area Master]
Fig. 13 shows an example of the configuration of the area master stored in the user DB 202 of Fig. 2. The area master is information for managing the regions of the travel destinations 400, the target areas 500, etc. The business operator system 1 stores setting information such as the target areas 500 corresponding to the travel destinations 400 (travel information) for each user in the area master. The area master may be stored separately in a separate DB (e.g., a map DB).

This area master table has items corresponding to columns such as number, region, region name, target area, center position, radius, etc. The "region" item is the ID for each region. The "region name" is the name of a prefecture, city, ward, town, village, etc. The "target area" item is the ID of the target area 500 when the target area 500 is set in that region. The "center position" and "radius" items are information when setting the circular target area 500 mentioned above. In this example, this target area 500 is the payment range. The target area 500 is not limited to the region of the travel destination or the area of a local government, and as mentioned above, specific stores such as antenna shops can also be set.

[9-4. User information]
FIG. 14 shows an example of the configuration of user information including travel information stored in the user DB 202 of FIG. 2. This table of user information has items corresponding to columns, such as number, user ID, travel destination (region), travel period, target area, center position, radius, payment information, delivery information, tax payment information, etc. The "travel destination (region)" item is specified as one or more regions according to the information of the area master of FIG. 13, for example. The "travel period" item is set with the travel schedule, etc. The "target area" item is set with the ID of the target area 500 corresponding to the travel destination 400. The "center position" and "radius" items are contents that define the target area 500 and are the same as the information in the area master. The business operator system 1 sets this target area 500 based on the information of the area master and the "travel destination (region)" item. The "payment information" item is set with payment information for the payment process (step S7). The "delivery information" item is set with delivery information for the delivery process (step S8). In the "tax payment information" field, tax payment information for donation processing (step S7) is set.

[10. Hometown Tax Payment]
As a supplement, we will explain about hometown tax payment. The upper part of FIG. 15 shows the concept of hometown tax payment amount, etc. In FIG. 15, from the user's perspective, when making a donation within the upper deduction limit, the user can receive a deduction 1504 (income tax refund) from income tax and a deduction 1505 from resident tax for the amount (deduction 1502) obtained by subtracting the self-payment amount of 2,000 yen 1503 from the total donation amount (donation amount 1501). For example, when the upper deduction limit is 100,000 yen, if the user makes a donation of 98,000 yen through hometown tax payment, the self-payment amount of 2,000 yen and the deduction amount of 96,000 yen are deducted from the resident tax and income tax. However, the user must temporarily pay the deduction amount of 98,000 yen (by credit card, etc.). The deduction limit varies depending on the amount of tax paid, and is determined by the family composition and annual income of the person making the donation, as well as the amount of tax deductions already received.

As a procedure after making a hometown tax donation, you will need to file a tax return. In addition, to promote hometown tax donations, a "one-stop special system" (one-stop application) has been established. The one-stop special system is a system that allows you to receive a donation deduction without having to file a tax return after making a hometown tax donation. Under this system, the procedure is completed by filling out and returning the "Declaration Special Application for Donation Tax Deduction" that is sent to you by the local government after you make the donation. However, donations are limited to five local governments, and if you donate to more than five local governments, you will need to file a tax return. In addition, the above required information requires you to return a form of identification such as a driver's license, but some local governments have also started allowing you to apply online using your My Number card.

From the perspective of local governments, in order to increase donation amounts (i.e. tax revenue), they set gifts in return for donation amounts. Local Tax Law stipulates that gifts must be no more than 30% of the donation amount. For example, if a donation of 10,000 yen is received, the gift must be a product worth 3,000 yen or less. In principle, gifts must be local products. In a broad sense, local products include products produced, manufactured, and services provided within the area. Gifts are not limited to food, and can be any type of local product. Gifts such as gift certificates have been abolished.

The lower part of FIG. 15 shows the concept of the donation amount (Y yen) in the donation-at-purchase format of the first embodiment. The donation amount (Y yen) 1511 is the amount when a donation is made in the donation-at-purchase format for a return gift product in the donation process of step S7 of FIG. 4, and is the amount donated by the user to the local government through the business system 1. The price of the return gift product (X yen) 1512 is the price of the return gift product sold by the product seller 2 such as the store 4, and also corresponds to the normal price when the user normally purchases the product without making a donation. The condition of the donation amount is, for example, Y = X / 0.3 as described above. The amount (Y - X yen) 1513 is the amount obtained by subtracting the price of the return gift product (X yen) 1512 from the donation amount (Y yen) 1511. When the local government pays the price (X yen) 1512 to the product seller 2, this amount (Y - X yen) 1513 corresponds to the local government's income.

[11. Effects, etc.]
As described above, according to the local revitalization system of the first embodiment, local revitalization can be realized with an even greater ripple effect expected from hometown tax (donations). According to this system, it is possible to realize demand stimulation and smooth cooperation from travel to tax payment. According to this system, it is possible to increase opportunities for hometown tax payment. A user can make a donation at the same time as purchasing a product at a local store or the like during a trip, and receive the purchased product as a return gift. According to this system, it is possible to stimulate demand by using hometown tax payment locally. According to this system, it is possible to promote hometown tax payment based on the user's interest in travel. Even if a user is interested in travel but not in hometown tax payment, it is possible to encourage hometown tax payment starting from travel. According to this system, it is possible to support a local government corresponding to the region of a travel destination by stimulating and promoting demand for hometown tax payment (donations) from users, bring about profits for local product sellers, and revitalize the local economy including related industries such as transportation and accommodation, and increase the amount of donations received by the local government for hometown tax payment. This system can contribute to improving traveler satisfaction and regional revitalization by effectively utilizing regional development tax systems such as the hometown tax payment system. With this system, users can not only contribute to the regional economy by traveling to regional areas and purchasing products, but also contribute through hometown tax payment. With conventional IT technology, the hometown tax payment procedure is relatively time-consuming, and users are less likely to feel a connection with product sellers and local governments. In contrast, according to the first embodiment, users can make donations more easily than with conventional procedures. Users can easily make hometown tax payment donations when purchasing products at specific locations such as local stores, and users are more likely to feel a connection with product sellers and local governments.

According to the system and method of the first embodiment, as shown in FIG. 4, the user can freely register and hold the product 40 as product information in the digital cart 51 while traveling, so that the user does not need to carry the actual product 40, which reduces the burden and is convenient. The user does not need to make an immediate decision on the purchase of the product while traveling, and can freely consider whether or not to purchase the candidate product in the digital cart 51 while taking into account, for example, the usual purchase amount and the donation amount, which is convenient. Since the user can purchase products using the digital cart 51 while traveling, the user does not need to carry cash or line up at the cash register of the store, and can avoid crowding, increase free time, and make effective use of time. When the user leaves the target area and returns home, the payment and delivery of the purchased product are automatically performed together, so that the user does not need to carry the product on the way home, which is convenient. In addition, when the user leaves the target area and returns home, the user can easily make a donation related to the hometown tax payment for the return gift product, which is convenient. The business operator system 1 acts as an intermediary between the user and the local government to provide support, reducing the burden on the user and local government associated with hometown tax payment procedures.

For the product seller 2 and the local government, the user can see the actual product 40 at the store 4 while traveling and consider purchasing it, which can increase sales profits. The user can select the product as a return gift for hometown tax after seeing and checking the actual product on site. The digital cart 51 reduces the burden and restrictions on the user while traveling, so the number of products purchased by the user and the purchase amount can be increased. In addition, the product seller 2 and the local government can inform the user that the product 40 is eligible for the return gift of the hometown tax of the local government along with the travel. Even a small product seller can inform the user of the return gift product during the trip, and the local government can revitalize local stores, etc. Furthermore, according to this system, it is easy to connect the purchase of a product during the trip to a donation related to the hometown tax, and the amount of donation through the hometown tax can be increased. In addition, the product seller 2 and the local government can obtain information related to the product purchase through the digital cart 51 from the business system 1, and can use it for marketing, etc.

This system can also be applied when the location of the store selling the gift items is outside the travel destination or the area of the relevant local government, such as an antenna shop. Even in such cases, users can easily make donations for the gift items at the antenna shop, etc., and support the relevant local government.

<Modification 1>
The following modification of the first embodiment is also possible. As a modification of the process of steps S6 to S8 in Fig. 4, when the user terminal 5 moves out of the target area 500, the application 50 automatically regards the product in the digital cart 51 that is in the purchase candidate status as having been cancelled, and does not execute the payment process or the like.

When the user terminal 5 goes outside the target area 500 and performs the payment process in step S7, the method of embodiment 1 or the various modified examples to be applied to the products in the purchase candidate status in the digital cart 51 is preset in the system. Alternatively, the user may select and set which method to apply using a user setting function of the app 50.

<Modification 2>
In the first embodiment, the trigger and timing for automatically executing payment and delivery of the product 40 registered in the digital cart 51 is basically immediately after the user leaves the target area 500 as in step S6 of FIG. 4, but the following configurations are also possible. In the second modification, after the user terminal 5 leaves the target area 500 and before the user arrives at home 8, instructions for allocation such as purchase confirmation, payment, delivery, etc. for the products in the digital cart 51 are accepted. The present system executes processing such as payment and delivery for the product at the timing when this instruction is received. The user can make such considerations on the way home, while on transportation, etc. Based on the location information, payment processing, etc. is similarly performed when the user arrives at home 8 or when the target period has passed.

<Modification 3>
In the third modification, after the user terminal 5 leaves the target area 500, the payment process in step S7 and the delivery process in step S8 are executed for products in the digital cart 51 that are in the purchase confirmed status. The business operator system 1 does not yet execute the payment and delivery process for products in the digital cart 51 that are in the purchase candidate status, and holds the product information in the digital cart 51, for example, for a predetermined period of time. During that period, the system accepts instructions regarding payment and delivery for each product in the digital cart 51. For example, after returning home from a trip, the user can check the product information in the digital cart 51 on the screen of the application 50 of the user terminal 5 as appropriate, and input payment and delivery instructions for each purchase candidate product.

<Modification 4>
In the first embodiment, the user can select whether to purchase the return gift product normally or to donate (purchase and donate at the same time) on the screen (FIG. 9C), and the donation process is automatically performed for all products that are donated in step S7. This is not limited to the above, and the following is also possible. First, the return gift product may basically be all donated according to the settings of the system or the user. In the fourth modification, the donation process in step S7 is controlled as follows. The process up to step S6 is the same as described above. The user first purchases a return gift product, which is a certain product 40, at the normal price (non-donation format). In step S7, the purchased product is paid for at the normal price. The system does not execute the donation process at this point. The system holds the product information in the digital cart 51, for example, for a predetermined period of time, even after the user returns to his/her home 8 from the travel destination 400. The user uses and consumes the product 40 delivered to his/her home 8. For example, if a user eats a food product 40 and likes it, and the product 40 is a gift product, the user can input an instruction to make a hometown tax donation for the product 40 on the screen of the digital cart 51 in the application 50 of the user terminal 5. This allows the user to make a second donation for the same product 40.

<Modification 5>
In the fifth modification, the following additional functions are provided. In FIG. 4, when the user terminal 5 is within the target area 500, the business operator system 1 pushes information on the stores 4 and products 40 in the vicinity of the user terminal 5 to the application 50 of the user terminal 5 according to the location of the user terminal 5 and the information in the DB. The delivered information includes information on the return gift products. The application 50 of the user terminal 5 receives the delivered information and displays it on the screen. By looking at the screen while traveling, the user can see that the return gift products are being sold at the stores 4 in the area of the travel destination 400. The user can visit the store 4 to check out the products 40 and make them a candidate for purchase. This can further support product sales and hometown tax donations.

In addition, before the user travels, the business operator system 1 may provide the app 50 of the user terminal 5 with a map of the travel destination 400 and information on the stores 4 that sell the products 40 on the map. The user can view the information on the screen of the app 50 and select a travel destination, etc.

Furthermore, in the system of embodiment 1, based on the location information of the user terminal 5, it is possible to ascertain that the attributes of a user in the target area 500 are that of a tourist, in other words, that the user is not a local resident. The system may provide the tourist with a predetermined preferential treatment, such as points or discounts in a point service. Alternatively, the local government may provide preferential treatment regarding return gifts. The system may provide preferential treatment when it is determined that the user has purchased product 40 from a general EC site or hometown tax donation site, and when it is determined that the user has purchased product 40 from a local store 4. This makes it more advantageous to make donations while traveling, thereby further encouraging travel and donations.

<Modification 6>
This system is also applicable to cases where multiple users, such as family and friends, are traveling together. In this case, in the sixth modification, product information registered in the digital cart 51 of a user terminal 5 of a first user can be copied or moved to the digital cart 51 of a different associated user terminal 5 of a second user through communication. This allows users to recommend products to each other, make simultaneous purchases, joint purchases, and have children ask their parents to buy products.

<Modification 7>
FIG. 16 is an explanatory diagram of the seventh modification. As with the sixth modification, the seventh modification has an additional function assuming a case where a group of multiple users (e.g., a family) goes to a target area such as a travel destination and does shopping. In the seventh modification, when a taxpayer (e.g., a father) is traveling with the taxpayer (i.e., when the group is in the target area), the accompanying persons (e.g., a mother and a child) can share and use the taxpayer's digital cart. In the seventh modification, one user (e.g., a father) in the group is the taxpayer (in other words, the person who makes the payment), and the taxpayer's digital cart is shared and used by the group as a shared cart. At a predetermined timing such as when the user terminal of the taxpayer (e.g., a father) leaves the target area, a payment process including a donation process for the purchased items in the shared cart is performed, as in the above-mentioned embodiment.

In the example of FIG. 16, a group of users includes a family of three people, a father, a mother, and a child, each of whom has a user terminal 5. The user IDs for the father are U01, the mother is U02, and the child is U03. As in the first embodiment, the digital cart 51 can be used for each individual user terminal 5. In this system, each user, user terminal 5, digital cart 51, etc. are identified by an ID. In the example of FIG. 16, three people, a father, a mother, and a child, are in a target area 500 corresponding to a travel destination, etc. One user in the group is determined as a taxpayer (in other words, a settlement person). In this example, the father (U01) is a taxpayer. This taxpayer is the subject when making hometown tax donations to a local government. In the target area 500, the father is the taxpayer, and the taxpayer's digital cart 51 is set as a shared cart for the group. Shopping is possible using the shared cart for the group, and if the product is a return gift product, a donation process is performed by the taxpayer (father) at the time of settlement. This shared cart can be set up at any time, and once set, it can be cancelled.

An example of implementation and processing in the seventh modified example is as follows. First, within the target area 500, the father (U01), who is a taxpayer, performs a predetermined operation on the app 50 of his user terminal 5 to set his digital cart 51 as a shared cart for the group. At this time, the app 50 of the user terminal 5 of the taxpayer (U01) creates a shared cart ID. This shared cart ID is information indicating that the digital cart 51 (identified as "cart 01", for example) of the taxpayer (U01) is to be a shared cart, and may be information including, for example, a flag indicating which user issued the shared cart ID as a taxpayer. The app 50 issues the shared cart ID to the user terminals 5 of the other users in the group (the mother and child who are accompanying them) through communication. The app 50 of each user terminal 5 of the mother and child registers and holds the issued shared cart ID for itself.

After that, within the target area 500, when each member of the group shops at a store or the like (including the aforementioned return gift items), they can register product information in the shared cart indicated by the shared cart ID in the app 50 of the user terminal 5. In this example, the digital carts 51 of each of the three user terminals 5 are the same shared cart, and the actual shared cart is the father's digital cart 51 (cart 01). The registered product information is synchronized between each of the three digital carts 51. For example, when the mother registers product information in the shared cart on her user terminal 5, that product information is also sent to and registered in the shared cart (cart 01) of the father's user terminal 5.

Then, if the taxpayer's (father's) user terminal 5 goes outside the target area 500, payment processing including donation processing is performed for the product information registered in the shared cart, similar to step S7 described above. For return gift products, donation processing is performed with the father (U01) as the taxpayer. Also, for example, after the payment processing is completed outside the target area 500, the shared cart ID is deleted and the shared cart settings are cancelled.

<Modification 8>
FIG. 17 is an explanatory diagram of the modified example 8. The modified example 8 is different from the modified example 7 in that one of the group (e.g., the father) taxpayer (in other words, the settlement person) does not go to the target area such as the travel destination, while the other users of the group (e.g., the mother and the child) go to the target area such as the travel destination to shop, etc. In the example of FIG. 17, the mother and the child of the family are in the target area 500 such as the travel destination, and the father is at home. The modified example 8 has a function to temporarily use (in other words, borrow, etc.) the taxpayer's digital cart. A designated person of the group (e.g., the mother) applies to the taxpayer for temporary use of the taxpayer's digital cart at any time (e.g., before or during the trip) and receives permission to use the cart. Then, when shopping within the target area, the designated person who is permitted to use the cart can register product information to the taxpayer's digital cart (in other words, the borrowed cart). Then, at a predetermined time such as when the designated person's user terminal leaves the target area, a payment process (including a donation process) is performed for the purchased products in the taxpayer's digital cart (borrowed cart). In the eighth variant, prior and subsequent approval of the taxpayer is possible with respect to payment for purchases in the target area, including donations related to hometown tax payment.

An implementation example and a processing example in the eighth modified example are as follows. First, for example, the mother (U02) applies to the user terminal 5 of the father (taxpayer) to temporarily borrow and use the taxpayer's digital cart 51, with the mother (U02) as the designated person (borrower) and the father (U01) as the taxpayer (renter), by performing a predetermined operation on the app 50 of her user terminal 5 within the target area 500. The app 50 of the mother's user terminal 5 transmits the usage application information to the user terminal 5 of the father (taxpayer). The app 50 of the father's user terminal 5 decides whether to permit the usage application information. For example, the app 50 displays the usage application information on the screen, and the father checks the information and presses the permission button if he permits it. The app 50 of the user terminal 5 of the taxpayer (father) transmits the usage permission information to the user terminal 5 of the designated person (mother). When the app 50 of the mother's user terminal 5 receives the usage permission information, it sets the taxpayer's digital cart 51 as a valid borrowed cart within the target area 500 within its own user terminal 5. In other words, this setting allows payment for products purchased within the target area 500 to be made using the taxpayer's digital cart 51 (borrowed cart). In addition, when applying for and granting permission to use the taxpayer, it is also possible to set an upper limit on the amount that can be used for payments using the borrowed cart.

Thereafter, when the designated person (mother) is shopping at a store or the like (including the aforementioned return gift product) within the target area 500, the designated person (mother) can register the product information in the borrowed cart in the app 50 of her user terminal 5. The actual borrowed cart is the taxpayer (father)'s digital cart 51 (cart 01). Then, when the designated person (mother)'s user terminal 5 goes outside the target area 500, the product information registered in the borrowed cart is transferred to the taxpayer (father)'s user terminal 5 as a payment processing request. The app 50 of the taxpayer (father)'s user terminal 5 that receives the payment processing request performs the payment processing (including donation processing) by the taxpayer (father) in the same manner as in step S7 described above. After the payment processing, a payment completion notification is sent from the taxpayer (father)'s user terminal 5 to the designated person (mother)'s user terminal 5. In addition, when a payment process request is made, the process may be automatic, but the designated person (mother) may request the taxpayer (father) to confirm the details of the payment request on the screen before the payment process is performed. For example, after the payment process is completed outside the target area 500, the borrowed cart setting is released.

According to variants 6 to 8, groups such as families can conveniently use digital carts and contribute to local economies through shopping, etc.

Although the present invention has been specifically described above based on the embodiment, the present invention is not limited to the above embodiment and can be modified in various ways without departing from the gist of the invention. The components of the embodiment can be added, deleted, replaced, etc., except for essential ones. A form based on a combination of each embodiment is also possible. Unless otherwise specified, each component can be singular or plural. This local revitalization system is a system that allows a user to make a donation related to a local development tax such as hometown tax to an entity (e.g., a local government) associated with a specified location (target area, location, region, etc.) in association with the purchase and payment of a product (especially an item that can be delivered, etc.) in a digital cart (i.e., online). The entity is not limited to a local government, but can be a country, a service provider, a product seller 2 (store 4), etc. In the first embodiment, a case where it is applied to the current hometown tax system in Japan has been described, but it is not limited to this and can be applied in the same way according to the tax payment and donation system.

1...business operator system, 2...product seller, 3...local government system, 4...store, 5...user terminal, 6...payment system, 7...delivery system, 8...home, 9...return gift, 21...PC, 22...product information, 31...hometown tax payment reception department, 40...product, 41...code, 50...app, 51...digital cart, 71, 72...product delivery, 80...identification card, 101...communication network, 102...GPS, 400...travel destination (region).

Claims (9)

Displaying the digital cart on the display screen of the user terminal;
registering product information in the digital cart based on a user's operation within the target area;
The target area can be set as a payment range that includes a destination area of the user's travel destination, in correspondence with the destination area of the user's travel destination,
When it is determined that the user terminal has gone outside the settlement range corresponding to the target area ,
A payment process is performed for the items in the digital cart, including a donation process for a regional development tax to an entity associated with the target area;
The donation process is a process for making a donation related to hometown tax to the local government together with the purchase of the product and receiving the product as the return gift when the product is eligible for a hometown tax return gift of the local government associated with the target area or the product seller, the process including a calculation of the amount of the donation;
Based on location information of the user terminal, it is determined that the user having the user terminal is within the target area, and when the user makes the donation by purchasing the product that is the target of the return gift, a predetermined preferential treatment is provided.
Local revitalization system. In the local revitalization system according to claim 1 ,
In the digital cart on the display screen of the user terminal, when the product is the return gift, the user selects whether to purchase the product at a normal price or to purchase the product as the return gift and make a donation together with the purchase, based on an operation of the user.
Local revitalization system. In the local revitalization system according to claim 1 ,
When the product information is displayed in the digital cart on the display screen of the user terminal, if the product is eligible for a gift in return for the hometown tax donation of the local government, the fact that the product is eligible for the gift in return for the hometown tax donation of the local government is displayed.
Local revitalization system. In the local revitalization system according to claim 1 ,
When the product information is displayed in the digital cart on the display screen of the user terminal, a total amount of the donation is calculated and displayed when the donation is made to the local government through the hometown tax payment system.
Local revitalization system. In the local revitalization system according to claim 1,
When registering the product information in the digital cart, registering the status of the product as a purchase candidate;
changing the status of the product in the digital cart from the purchase candidate to a purchase confirmed or a purchase cancelled based on an operation of the user on the user terminal;
Local revitalization system. In the local revitalization system according to claim 1,
A delivery process is performed for the purchased products in the product information in the digital cart.
Local revitalization system. In the local revitalization system according to claim 1,
A target period is set in the digital cart of the user in association with the target area ;
When it is determined that the target period has passed, the payment process including the donation process is performed.
Local revitalization system. In the local revitalization system according to claim 1 ,
If the target area is a region of the travel destination and has multiple regions, a sub-area is set for each region;
performing the payment process including the donation process of the product every time the user terminal goes out of the sub-area;
Local revitalization system. A method for revitalizing a local area in a local area revitalization system, comprising:
As a step executed by the local revitalization system,
displaying the digital cart on a display screen of the user terminal;
registering product information in a digital cart based on an operation of a user within a target area;
The target area can be set as a payment range that includes a destination area of the user's travel destination, in correspondence with the destination area of the user's travel destination,
When it is determined that the user terminal has gone outside the settlement range corresponding to the target area ,
A step of performing a payment process for the items in the digital cart, including a donation process for a regional development tax to an entity associated with the target area;
having
The donation process is a process for making a donation related to hometown tax to the local government together with the purchase of the product and receiving the product as the return gift when the product is eligible for a hometown tax return gift of the local government associated with the target area or the product seller, the process including a calculation of the amount of the donation;
Based on location information of the user terminal, it is determined that the user having the user terminal is within the target area, and when the user makes the donation by purchasing the product that is the target of the return gift, a predetermined preferential treatment is provided.
Regional revitalization methods.

Images