System, method, program

Abstract

To make the introduction and operation of urban infrastructure easier and to provide systems, methods, and programs for building sustainable social infrastructure. [Solution] In a system for integrated management of multiple mobile units (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, the control unit of the management server maintains a first criterion and a second criterion different from the first criterion as evaluation criteria for determining the placement or operation of the mobile infrastructure. Normally, the system executes a first mode in which the placement or operation of the mobile infrastructure is determined according to the first criterion, and when an emergency trigger is detected, it switches to a second mode in which the placement or operation of the mobile infrastructure is determined according to the second criterion.

Description

Technical Field

[0001] The present disclosure relates to a system, a method, and a program.

Background Art

[0002] Conventionally, various techniques have been proposed regarding control during disasters in infrastructure facilities. Patent Document 1 describes a power supply system and its control method that performs control to automatically switch from a main system to an independent operation system during power outages or disasters. Further, Patent Document 2 describes a technique for switching to a disaster recovery workflow based on abnormality detection of network elements.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Summary of Invention

Problems to be Solved by the Invention

[0004] In conventional disaster countermeasures and backup systems for urban infrastructure, infrastructure such as power, communications, and water are individually managed and dispatched by respective operators, so they are not necessarily optimally arranged for the entire city.

[0005] Furthermore, installing fixed backup infrastructure at all locations to prepare for every possible situation to achieve complete redundancy may require a decision on whether to invest appropriate costs in facilities that are unlikely to be expected to operate during normal times. Therefore, from the perspective of the cost-efficiency trade-off, there exists a problem that it is not easy to judge whether the arrangement can be called sustainable.

[0006] This disclosure is made in light of the above-mentioned challenges and aims to make the introduction and operation of urban infrastructure easier and to provide a sustainable social infrastructure system. [Means for solving the problem]

[0007] According to one embodiment shown in this disclosure, a system is provided. The system integrates and manages a plurality of mobile objects (hereinafter referred to as mobile infrastructure) that provide different types of infrastructure functions from each other. The system includes a control unit that normally operates in a first mode in which the deployment or operation of the mobile infrastructure is determined according to the first criterion, and switches to a second mode in which the deployment or operation of the mobile infrastructure is determined according to the second criterion when a predetermined trigger is detected. [Effects of the Invention]

[0008] According to this disclosure, even without complete duplication using fixed equipment, the necessary infrastructure functions can be moved to the necessary locations, enabling low-cost and high resilience, and ensuring dynamic redundancy. Furthermore, instead of using the equipment as a reserve solely for emergencies, it can be utilized for profitable economic activities during peacetime (dual use), making the implementation costs more reasonable, making decisions regarding implementation and operation easier, and enhancing the sustainability of the business. [Brief explanation of the drawing]

[0009] [Figure 1] This is an overall conceptual diagram of a mobile urban infrastructure management system (Resilience OS) according to one embodiment of the present invention, showing a comparison of the behavior of mobile infrastructure in normal mode and emergency mode. [Figure 2]This is a conceptual diagram illustrating the logical hierarchical structure of this system (Resilience OS), showing a three-layer structure consisting of a physical layer, a communication and control layer, and an economic and transaction layer, as well as the relationship with external data. [Figure 3] This is a conceptual diagram of the cross-domain collaboration function in this system, illustrating how different types of mobile infrastructure are deployed in coordination based on dependencies where the recovery of one infrastructure function requires the recovery of another infrastructure function. [Figure 4] This is a block diagram showing the overall hardware configuration of a mobile urban infrastructure management system (Resilience OS) according to one embodiment of the present invention. [Figure 5] This is a functional block diagram showing the internal configuration of the management server (Resilience OS), illustrating the structure of each functional unit responsible for mode switching, deployment plan generation, and transaction management, as well as the database. [Figure 6] This is a functional block diagram showing the internal configuration of the mobile infrastructure (autonomous mobile unit) in this system, illustrating the configuration of the drive mechanism, detachable infrastructure modules, and control unit that performs autonomous distributed control. [Figure 7] This diagram shows an example of the data structure of the mobile infrastructure management database stored in the management server's memory, illustrating how information such as the type, location, remaining resources, and owner information of each mobile infrastructure is managed. [Figure 8] This figure shows an example of the configuration of the mode definition table stored in the evaluation function memory unit, and provides examples of how to set the evaluation indicators and weight coefficients applied in both the peacetime mode and the emergency mode. [Figure 9] This diagram shows an example of the data structure of an infrastructure dependency definition database stored in the memory unit, illustrating the rules for combining other infrastructure functions that are essential or recommended for running a particular infrastructure function. [Figure 10] This is an example of the data structure of the resilience credit management table (or distributed ledger) managed by the Transaction Management Department, and it shows each business operator's contribution score, credit balance, and transaction history via smart contracts. [Figure 11]This flowchart illustrates the overall processing flow of this system (Resilience OS), showing the series of processes from the execution of the normal mode to the switch to the emergency mode upon trigger detection, deployment command, and mode return upon recovery detection. [Figure 12] This flowchart details the deployment plan generation process (subroutine), illustrating the steps involved in switching the evaluation function applied depending on the current mode to determine the deployment that maximizes either economic efficiency or survivability. [Figure 13] This is a flowchart of the cross-domain collaboration process (subroutine) executed during the deployment plan generation process. It illustrates the procedure for identifying heterogeneous resources necessary for the operation of the recovery target and performing collaborative deployment. [Figure 14] This is a flowchart illustrating the process of autonomous distributed control (physical AI) executed by the edge control unit of mobile infrastructure during a communication outage. The flowchart shows the steps from cluster formation via proximity communication to leader selection and resource allocation decision-making. [Figure 15] This is a flowchart illustrating the issuance and settlement process of resilience credits performed by the Transaction Management Department, showing the process from calculating contributions during emergencies to recording them on the blockchain and converting them into credit usage rights during normal times. [Figure 16] This diagram shows the screen configuration of the integrated monitoring dashboard (normal mode) displayed on the user terminal, illustrating the profitability heatmap, the current location of the moving object, and the operation interface for maximizing profits, all overlaid on the map information. [Figure 17] This diagram shows the screen configuration of the integrated monitoring dashboard when a disaster trigger is detected, including mode switching notifications, a map display of infrastructure damage locations, survival rate prediction simulation results, and an operation interface for executing rescue plans. [Figure 18] This diagram shows the screen configuration for displaying the simulation results of the deployment plan. It illustrates how changes in survival rate and infrastructure coverage rate are displayed as a comparison graph between "Current" and "Forecast" in response to the virtual deployment operations of mobile infrastructure. [Figure 19] This is a configuration diagram of an infrastructure use request and credit management screen displayed on a user terminal, and is a diagram showing operation interfaces for infrastructure dispatch requests, confirmation of held credit balance, and priority deployment requests using credits. [Description of Embodiments of the Invention]

[0010] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same components are denoted by the same reference numerals. Their names and functions are also identical. Therefore, detailed descriptions thereof will not be repeated.

[0011] <Overview of Embodiment>

[0012] [Overall System Overview] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0013] Prior to the description of specific examples, the overall concept and schematic configuration of the mobile urban infrastructure management system (hereinafter also referred to as "Resilience OS") 100 according to the present embodiment will be described.

[0014] (1) Problems to be Solved Conventional urban infrastructure (electric power, communications, water supply, etc.) often relies on physical fixed networks, and in the event of a large-scale disaster, the vulnerability of widespread functional failure may become apparent. On the other hand, maintaining and managing a large number of dedicated backup facilities (emergency power supplies, water supply vehicles, etc.) that only operate during disasters involves enormous economic costs during normal times, so there was a problem that it is not easy to make such a system sustainable.

[0015] In addition, responses in emergency situations have remained passive and ex post facto, such as dispatching decisions being made after human reports or damage confirmation, leading to time lags and difficulties in optimal resource allocation under chaotic conditions.

[0016] (2) Technical configuration for solving the problem This system 100 is a platform that comprehensively manages and controls numerous "mobile infrastructure 10 (mobile bodies such as EVs, autonomous vehicles, and drones equipped with infrastructure provision modules)" distributed throughout urban spaces. In this embodiment, the "objective function (evaluation logic)" that drives the entire system is dynamically changed in response to changes in the external environment (triggers). This makes it possible to achieve both economical operation in normal times and reliable infrastructure provision in times of emergency. Furthermore, by autonomously deploying alternative infrastructure in response to infrastructure deficiencies, it is possible to minimize downtime (the self-healing function of the city).

[0017] Specifically, this system 100 has the following two modes.

[0018] • Mode 1 (peacetime): The deployment of mobile infrastructure 10 is determined by focusing on "economic revenue (profit)" such as electricity sales and logistics distribution (for example, so that economic revenue is maximized) (Criteria 1).

[0019] • Second mode (emergency): When a trigger such as a disaster is detected, the mode is immediately switched, and the focus is increased on "probability of human survival" and "infrastructure coverage" (for example, to maximize these) rather than on profitability (second criterion) when deciding on deployment (second criterion).

[0020] Furthermore, in emergency mode, System 100 is equipped with a "cross-domain cooperation function" that interprets the dependency relationships between different types of infrastructure (e.g., "power is needed to operate a communication base station") and dispatches the necessary aircraft as a set, thereby enabling more effective rescue operations. It also has an "autonomous distributed control (edge ​​AI) function" that allows aircraft at the scene to form a network using proximity communication, select a leader, and share resources in the event of a wide-area communication disruption.

[0021] In addition, this system incorporates not only technical control but also a social incentive structure. It features a "transaction management function" that quantifies the contribution of businesses that provide and operate mobile infrastructure during emergencies, issues "resilience credits (tokens)," and converts them into economic value such as priority usage rights during peacetime.

[0022] (3) Effects brought about by the present invention With the above configuration, System 100 realizes a dynamic and sustainable infrastructure network that "generates profits through economic activities during peacetime, while autonomously converging to take on the role of saving lives in times of emergency."

[0023] Furthermore, a self-sustaining ecosystem will be built in which participating businesses continue to participate in the system, for example, by having a mechanism that irreversibly records and returns volunteer contributions during emergencies as a business advantage during peacetime.

[0024] Furthermore, a system that allows aircraft on the ground to autonomously cooperate and provide assistance to each other even when communications are lost not only provides robustness against the collapse of a centralized system, but can also create a sense of structural security through the "connections" between participants.

[0025] The details of each component necessary to realize this general configuration will be explained in order with reference to Figures 1 to 19.

[0026] The specific configuration and processing of this system will be explained below using diagrams.

[0027] Figure 1 is a diagram illustrating the overall concept of a mobile urban infrastructure management system (hereinafter simply referred to as "this system" or "Resilience OS") 100 according to one embodiment of the present invention. This diagram shows a comparison between the "normal (first mode)" state shown on the left and the "emergency (second mode)" state shown on the right, with a time axis or change in situation (detection of a trigger) as the boundary.

[0028] This system 100 comprehensively manages and controls multiple mobile infrastructures 10 (10a, 10b, 10c…) distributed within an urban space. The mobile infrastructures 10 are autonomous mobile units (unmanned EVs, drones, etc.) that provide different types of infrastructure functions, such as power supply vehicles with power supply functions, communication vehicles with communication base station functions, water supply vehicles with water purification and supply functions, or delivery robots with logistics functions. Infrastructure functions include power supply functions, communication environment provision functions, water purification or supply functions, material transport functions, computing resource provision functions, medical provision functions, etc. In this system 100, the infrastructure base including the mobile infrastructures 100 may provide at least two or more of the above functions that are different from each other.

[0029] Furthermore, the mobile infrastructure 10 is not limited to vehicles or aircraft specialized in these single functions. For example, a single mobile unit may have multiple functions, such as power supply (generator and battery), water supply and purification (water tank and water treatment device), and communication environment provision (satellite communication antenna, etc.). The mobile infrastructure 10 may also be configured as a "self-contained, multi-purpose infrastructure (e.g., an autonomous mobile mobility house or multi-purpose container)" that is equipped with air conditioning and living space where people can safely reside and stay. Such a multi-purpose infrastructure is managed as a single node on the network of this system 100 that can simultaneously provide multiple infrastructure functions and functions as a hub in cross-domain cooperation.

[0030] In the "normal (normal)" scenario shown on the left side of Figure 1, the system 100 operates in "first mode." In this mode, the deployment and operation of the mobile infrastructure 10 are determined based on "first criteria (evaluation function)" that emphasize economic rationality and operational efficiency. The first criteria may be determined based on economic indicators including at least one of the following: profitability of the operation of the mobile infrastructure, energy consumption efficiency, logistics efficiency, or the rate of fulfillment of user requests.

[0031] For example, power supply vehicle 10a can move to areas with high electricity demand and high electricity selling prices, or to event venues, supplying electricity and generating economic revenue. Logistics vehicle 10b transports goods along the route that maximizes delivery efficiency. Communications vehicle 10c moves to areas with heavy communication traffic (such as stadiums) to temporarily increase communication capacity. In this way, during normal times, each mobile infrastructure 10 is widely "distributed" within the city, operating in a manner that maximizes its respective economic value. This also allows the maintenance costs of the infrastructure to be offset (or even turned into a profit) by revenue.

[0032] Furthermore, the deployment or operation of the mobile infrastructure 10 in the first mode may be determined to dynamically complement capacity shortages or limitations of existing fixed infrastructure (such as grid power, water and sewage systems, or transportation infrastructure). For example, in areas where it is not easy to upgrade aging water and sewage systems or power grids, the system can predict demand peaks that occur during specific time periods and autonomously deploy water supply vehicles and power supply vehicles to match those times, thereby avoiding overloading fixed infrastructure while generating revenue from infrastructure provision. Also, in facilities that attract crowds regularly or seasonally, such as theme parks and aquariums, the mobile infrastructure 10 can be deployed to provide temporary or continuous supply of large amounts of electricity and water needed for specific events or the operation of attractions, instead of adding fixed facilities. As yet another example, for multiple mobile stores (such as food trucks with refrigeration facilities) clustered together at outdoor event venues or public open spaces in cities, a large-capacity power vehicle 10a and a water supply vehicle may be autonomously deployed as a set, replacing individual small fuel generators. In return for supplying clean electricity and water as a hub for the area, an infrastructure usage fee may be collected.

[0033] Furthermore, the scope of application of this system 100 is not limited to emergency backup or peacetime supplementation functions in areas where existing fixed infrastructure is already in place (such as developed countries). For example, in areas where large-scale fixed infrastructure is not yet developed (such as developing countries, remote islands, or undeveloped areas like outer space), it is possible to skip the construction of fixed infrastructure, which requires enormous initial investment and a long construction period, and instead deploy the system's mobile infrastructure 10 groups on demand at the required scale and timing, thereby enabling them to function as the main infrastructure itself (so-called leapfrogging infrastructure construction). This will realize a new urban development model that allows for the rapid and flexible establishment of survival bases (electricity, water, communications, food, etc.) at the city or settlement level without constructing permanent facilities, and to redeploy them in accordance with fluctuations in demand.

[0034] As shown in the center of Figure 1, when a "trigger" (emergency event) occurs, such as a natural disaster like an earthquake, tsunami, or typhoon, or an event requiring defense or a large-scale system failure, and the system 100 detects it, the control logic immediately switches to the "second mode." The trigger may include any of the following: a disaster warning or armed attack warning received from an external system, a supply disruption signal received from mobile or fixed infrastructure, estimated infrastructure damage data obtained by analyzing text data, or ground surface change detection data obtained by remote sensing such as satellite data.

[0035] In the "emergency" scenario shown on the right side of Figure 1, the system 100 reconfigures (reprograms) the mobile infrastructure 10 based on a "second criterion (evaluation function)" that prioritizes the protection of human lives and the maintenance of social functions. The second criterion may be determined based on survival or maintenance indicators, including at least one of the following: the probability of human survival in the target area, the coverage rate of infrastructure supply, the operational maintenance rate of critical facilities, or the time required to restore infrastructure functions.

[0036] This scene depicts how 10 types of mobile infrastructure, necessary for the disaster, are concentrated and "gathered" in 20 areas where fixed infrastructure (power grids and fiber optic networks) has been severed.

[0037] Specifically, power supply vehicles 10a will be dispatched as a top priority to hospitals and evacuation centers experiencing power outages to supply electricity. Simultaneously, communication vehicles 10c will be deployed to areas where communications have been disrupted, and will establish a temporary communication area (mesh network) while receiving power from power supply vehicles 10a. Water supply vehicles will autonomously move to areas without water supply to provide water.

[0038] In this way, System 100 dynamically compensates for and repairs deficiencies in fixed infrastructure by instantly transforming resources that function as "revenue-generating infrastructure" during peacetime into "protective infrastructure" during emergencies, and by physically moving them. This grants cities the ability to self-heal (resilience) against external disturbances.

[0039] Figure 2 is a conceptual diagram representing the architecture of System 100 as a functional hierarchical structure (layers). System 100 is broadly composed of three layers: the lowest layer, the "Physical Layer"; the middle layer, the "Communication and Control Layer"; and the top layer, the "Economic Layer".

[0040] The lowest layer, the "physical layer," consists of hardware that operates physically within urban spaces. This includes various mobile infrastructures 10, as shown in Figure 7, etc. Specifically, energy modules that carry electricity, communication modules that form communication areas, water modules that carry water, and logistics modules that carry goods exist mounted on common EV platforms or mobile vehicles such as drones. These receive commands from higher layers and perform physical movement and provide infrastructure functions (actuation).

[0041] The intermediate "communication and control layer" is the "brain" of this system 100. This layer collects location information and operational status (sensing data) from each moving object in the physical layer, and integrates data from the external environment.

[0042] As shown in the diagram, external systems 200 are connected to satellite constellations (SAR satellites, optical satellites, etc.) that monitor disaster situations, text data from social media, and J-Alert (National Instant Warning System) from public institutions. The "trigger detection unit" within the communication and control layer analyzes this external data to detect the occurrence of an emergency and makes the decision to "switch modes" as described above. The "deployment plan generation unit" generates and transmits the optimal deployment command to the physical layer. In essence, this layer performs simulations in a digital twin in cyberspace and feeds the results back into the physical space.

[0043] The top-level "economic and transactional layer" is the layer that manages the "social contract" necessary for System 100 to function as a sustainable ecosystem.

[0044] Here, distributed ledger technologies such as blockchain are used to manage transactions between providers (owners) and users of mobile infrastructure 10. Specifically, in the second mode (emergency), the contribution of providing infrastructure is quantified and issued and recorded as "resilience credits." In the first mode (normal times), these credits are used to exercise priority usage rights and to settle infrastructure usage fees (automatically executed by smart contracts).

[0045] The existence of this economic and transactional layer means that System 100 is not merely a disaster prevention system, but functions as a platform that integrates normal economic activities and emergency contribution activities in a value-exchangeable manner, and has incentives for many businesses to participate.

[0046] Figure 3 illustrates the conceptual processing of "Cross-Domain Coordination" performed by this system 100.

[0047] Traditionally, infrastructure such as electricity, telecommunications, and water supply have been managed individually by their respective operators, and coordination between them has often been lacking, even during disasters. For example, even if a telecommunications carrier dispatches a mobile base station vehicle to a disaster area, it may not be able to operate due to a power outage in the area (a mismatch in dependencies).

[0048] In response to this, as shown in Figure 9, etc., the system 100 defines and manages dependencies between heterogeneous infrastructures and generates a deployment plan to resolve them.

[0049] In the example shown in Figure 3, a situation exists in disaster area 20 where both "communication is impossible" and "power outages" have occurred. Let's assume that the system has been given the mission (recovery goal) of "restoring communication environment."

[0050] The deployment plan generation unit of this system 100 first refers to the database (dependency definition) and identifies a "dependency" that states "the provision of power functions is essential for the provision of communication functions."

[0051] Based on this dependency, the system searches for the power supply vehicle 10a, which supplies power to the communication vehicle 10c, rather than the communication vehicle 10c alone, and defines the two as a "set (cooperation unit)".

[0052] As shown in the diagram, the system issues commands to the communication vehicle 10c and the power vehicle 10a to head to the same destination. Furthermore, as an action upon arrival at the site, the system executes a deployment plan that includes a "connect command" to physically connect a power supply cable (or contactless power supply) from the power vehicle 10a to the communication vehicle 10c.

[0053] Thus, the ability to sequentially and comprehensively deploy other supporting infrastructures to compensate for deficiencies in a particular infrastructure is the core function of System 100 (Resilience OS), which sets it apart from mere ride-hailing apps.

[0054] Furthermore, this collaboration is not limited to just two types. For example, when dispatching a "vehicle equipped with an advanced medical module," a "water supply vehicle" may also be brought along simultaneously in addition to a "power supply vehicle," demonstrating that three or more types of cross-domain collaboration are also carried out.

[0055] <Configuration Diagram> Figure 4 is a block diagram showing the hardware configuration of the mobile urban infrastructure management system 100 according to this embodiment.

[0056] This system 100 consists of a management server 110, multiple mobile infrastructures 10, user terminals 400, and an external system 200, all of which can communicate with each other via a network 300.

[0057] Network 300 includes the internet, mobile communication networks (5G / 6G / LTE), satellite communication networks (low Earth orbit satellite constellations, etc.), or dedicated lines. In particular, it is preferable to have a redundant configuration that allows for the combined use of satellite communication and a mesh network (ad-hoc communication) between mobile infrastructure 10s, anticipating disruptions to the terrestrial communication network in times of emergency.

[0058] The management server 110 is an information processing device that functions as the central hub (core of the resilience OS) of this system. The management server 110 consists of a general cloud server or on-premises server equipped with a processor such as a CPU, memory, storage, and communication interfaces.

[0059] The management server 110 manages location information and operational data collected from the mobile infrastructure 10, and based on information from the external system 200, it determines whether to switch between "mode 1 (peacetime)" and "mode 2 (emergency)" and sends control commands (deployment plans) to each mobile infrastructure 10.

[0060] As mentioned above, the mobile infrastructure 10 consists of autonomous mobile units such as power supply vehicles, communication vehicles, water supply vehicles, and logistics drones. Each mobile infrastructure 10 is equipped with a drive mechanism for movement, a functional module that provides infrastructure functions (battery, antenna, tank, etc.), a group of sensors for self-position estimation (GNSS, LiDAR, camera, etc.), and an on-board communication device for communicating with the management server 110. It also has edge computing capabilities and is equipped with a control unit that makes autonomous decisions in the event of a communication interruption.

[0061] External system 200 is a third-party or public institution system that provides data used to determine trigger detection.

[0062] Specifically, this includes disaster warning systems operated by the Japan Meteorological Agency and local governments (such as J-Alert), satellite data centers operating SAR satellites and optical satellites, SNS platforms, and smart city infrastructure that manages IoT sensors within cities (such as water level gauges and seismometers). The management server 110 acquires data from these external systems 200 in real time via APIs (Application Programming Interfaces), etc.

[0063] User terminals 400 are PCs, tablets, smartphones, etc., used by local government officials, infrastructure operators, or ordinary citizens. Through these terminals, users send infrastructure usage requests during normal times, check damage status during emergencies (viewing dashboards), and manage and exercise resilience credits.

[0064] Figure 5 is a block diagram showing the internal functional configuration of the management server 110.

[0065] The management server 110 is a computer equipped with a CPU, memory, storage, communication interface, etc., and the programs stored in the storage are executed to logically realize each of the functional blocks (modules) shown in the diagram.

[0066] The communication unit 111 is an interface that transmits and receives data between the mobile infrastructure 10, the external system 200, and the user terminal 400 via the network 300.

[0067] The storage unit 120 is a group of databases that store various data and parameters necessary for system operation.

[0068] The mobile infrastructure management DB121 manages the current location, battery level, installed module type (power, communication, water, etc.), and operational status of each mobile infrastructure 10 in real time.

[0069] The evaluation function storage unit (mode definition table) 122 stores the "first criterion" and "second criterion" shown in Figure 1, etc., as mathematical formulas or parameters. Specifically, it stores the "economic efficiency maximization function (first evaluation function)" for peacetime and the "survivability / coverage maximization function (second evaluation function)" for emergency situations.

[0070] The (infrastructure) dependency definition DB123 stores a set of rules that define dependencies between infrastructure functions (e.g., communication requires power) for cross-domain collaboration as shown in Figure 3, etc.

[0071] The blockchain ledger (resilience credit management table) 124 is a distributed ledger node data (or reference to external nodes) that records the contribution and transaction history of each mobile infrastructure in a tamper-proof format.

[0072] The control unit 130 is a processor that controls the entire system 100 and includes the following functional units.

[0073] The trigger detection unit 131 monitors data (earthquake reports, SNS analysis results, etc.) received from the external system 200 via the communication unit 111, and issues an "emergency trigger" when it detects an abnormal value that exceeds a predetermined threshold.

[0074] The mode switching determination unit 132 switches the operating mode of the entire system to either "first mode (normal)" or "second mode (emergency)" based on the signal from the trigger detection unit 131. Depending on this determination result, the evaluation function that the deployment plan generation unit 133 (described later) should refer to is selected.

[0075] The deployment plan generation unit 133 calculates the optimal placement and operation (movement route, function provision timing, etc.) of each mobile infrastructure 10 based on the selected mode and evaluation function. In emergency mode, it refers to the dependency definition DB 123 and generates a deployment plan that links heterogeneous infrastructures.

[0076] The Transaction Management Department 134 calculates contributions based on resource provision performance during emergencies and issues resilience credits. It also executes smart contracts to automatically process payment settlements and incentive distributions during normal times.

[0077] Figure 6 is a block diagram showing the internal functional configuration of each mobile infrastructure 10.

[0078] The mobile infrastructure 10 is configured by mounting modules according to the infrastructure functions to be provided onto a common mobility platform (chassis or body), or by operating as a dedicated vehicle specialized for specific infrastructure functions.

[0079] Furthermore, the mobile infrastructure 10 in this system 100 may be configured as a mobility device not intended for transporting people. In this case, a dedicated chassis (cabinless structure) can be adopted that omits passenger seats, cabins, and physical margins for person safety (such as airbags), thereby maximizing the loading capacity of the infrastructure module and enabling a design and operation dedicated to providing pure infrastructure functions.

[0080] The drive mechanism 11 is a physical means of movement that includes a motor, inverter, steering mechanism, etc., which drives the tires, propeller (in the case of a drone), screw (in the case of a ship), etc.

[0081] Sensor group 12 is a sensing device for autonomous movement and surrounding environment recognition. It includes a GNSS (Global Navigation Satellite System) receiver, LiDAR, stereo camera, IMU (Inertial Measurement Unit), etc., and performs self-position estimation and obstacle detection. It also has the function of detecting damage (road collapse, flooding, etc.) and reporting it to the server.

[0082] The communication interface 13 is a unit that communicates with the outside world, and it is preferable that it has the following two systems.

[0083] The wide-area communication unit 13a connects to the management server 110 via 5G / 6G or satellite communication to receive deployment plans and control commands.

[0084] The proximity communication unit 13b is a unit that performs direct communication (V2V: Vehicle-to-Vehicle) with other nearby mobile infrastructure 10 to realize a distributed control mode function in which, in the event of a communication interruption, each mobile infrastructure communicates directly with other surrounding mobile infrastructure and autonomously cooperates (cluster formation) according to a second criterion (maximizing survival) without waiting for a command from the central control unit. It uses Wi-Fi Direct, Bluetooth®, or millimeter-wave communication, etc., to form a local mesh network even when the cellular network is out of range.

[0085] The edge control unit 14 is an in-vehicle computer that controls the entire mobile infrastructure 10.

[0086] The autonomous mobile control unit 14a generates a path and performs drive control to avoid obstacles and reach the destination based on input from the sensor group 12.

[0087] The distributed cooperative logic 14b is a backup logic that is activated when communication with the management server 110 is interrupted. It exchanges information with surrounding mobile units via the proximity communication unit 13b and autonomously makes decisions such as "I have excess power, so I will supply power to the neighboring communication vehicle" without going through the server.

[0088] The infrastructure module 15 is hardware that provides each infrastructure function, as shown in Figure 7, etc. Depending on the type of mobile infrastructure 10, one or a combination of the following will be installed.

[0089] • Power module: High-capacity battery, fuel cell, or generator, and connector / contactless power supply pad for external power supply.

[0090] • Communication modules: Portable base station antennas, radios, and satellite backhaul communications equipment.

[0091] • Water module: A vehicle equipped with a water purification system, large-capacity clean water and non-clean water tanks, and a water treatment system.

[0092] • Logistics and Mobility Module: This module includes automated loading and unloading mechanisms for goods (such as material supply arms), automated guided vehicles (AGVs) equipped with temperature-controlled insulated containers, and a fleet of logistics drones. In the first mode (peacetime), it maximizes logistics efficiency by handling last-mile delivery for e-commerce and cold chain transportation. In the second mode (emergency), it autonomously performs heavy machinery roles such as airlifting emergency medical supplies (blood products, etc.) and food to isolated communities, or debris removal. Furthermore, the logistics bases (drone ports, etc.) themselves may function as mobile hubs.

[0093] • Computational resource module: A data center vehicle or container equipped with an edge AI server and large-capacity storage. It can perform local image analysis processing of disaster conditions captured by drones in disaster areas where communication lines are disrupted, and function as a local information sharing portal in evacuation centers.

[0094] • Medical module: A container equipped with surgical equipment, dialysis machines, or medical refrigeration equipment (for storing vaccines, etc.). Since these require a continuous supply of electricity and sterile water, they may be operated in conjunction with power supply vehicles and water supply vehicles, based on the dependency relationships shown in Figure 9.

[0095] • Living / Stay Module: An autonomous mobile living unit (mobility house, etc.) that packages a series of infrastructure functions necessary for human habitability and life support. Inside the module, power generation devices such as solar panels and fuel cells, a large-capacity battery storage system, a water storage tank for storing fresh water, a water circulation and treatment system that filters and reuses used domestic wastewater, and a wide-area communication antenna are integrated and implemented. In the first mode (peacetime), it functions as a mobile office for workation or a mobile hotel in tourist areas to generate revenue, while in the second mode (emergency), it autonomously moves to disaster areas and functions as a self-contained shelter, temporary housing, or local response headquarters.

[0096] • Food and Agriculture Module: Provides functions for the sustainable production, cooking, or storage of food. For example, it can be configured as a mobile plant factory for hydroponics, an alternative protein culture device, or a vehicle or container equipped with mass cooking facilities (kitchen module) for disaster victims. In times of emergency, it can sustainably provide hot meals and fresh food in disaster-stricken areas, and in normal times, it can operate at event venues or in areas where food supplies are temporarily insufficient. Since the operation of this module requires a large amount of electricity and a continuous water supply, it is preferable to operate it in conjunction with power supply vehicles and water supply vehicles based on the aforementioned dependencies (cross-domain cooperation). • Surveillance and Security Module: A vehicle or container equipped with early warning radar, wide-area surveillance cameras, drone jammers, or biometric sensors. In the first mode (peacetime), it functions as a sensor node for security of important facilities and event venues, or for monitoring and security, generating revenue, while in the second mode (wartime), it functions as a mobile defense base (security infrastructure) that supports early warning and rapid recovery in maintaining security and defense activities in disaster-stricken areas.

[0097] The power management unit 16 integrates and manages the mobile battery and the power provided for infrastructure (output from power modules), controlling it to ensure that it secures the power necessary for its own movement while maximizing external supply.

[0098] <2 Data Structure> Figure 7 shows an example of the data structure of the mobile device management DB 121 stored in the memory unit 120.

[0099] This database is a table for managing (digital twinning) the status of numerous mobile infrastructure units 10 distributed throughout urban spaces in real time. Each record is associated with a "unit ID" that uniquely identifies the mobile infrastructure unit 10 and consists of the following fields.

[0100] The "Infrastructure Type" field stores the category of infrastructure function that the mobile unit can provide (POWER: electricity, COMM: communications, WATER: water, LOGI: logistics, etc.). The control unit 130 refers to this type information to identify "different types of infrastructure functions" and assigns an appropriate mobile unit to the missing infrastructure function.

[0101] "Current location" refers to latitude and longitude information obtained by GNSS, etc., or area IDs (voxel IDs) that divide the city into a grid. This information is used to calculate the estimated time of arrival (ETA) at the disaster site.

[0102] "Status" indicates the current operating state of the mobile unit. For example, it can take values ​​such as "IDLE (standby)", "MOVING (moving)", "ACTIVE (providing)", "CHARGING (charging)", and "ERROR (malfunction)". The deployment plan generation unit 133, in principle, selects units in the "IDLE" or lower-priority "ACTIVE" state as candidates for deployment in the event of an emergency.

[0103] "Resource availability / capacity" indicates the quantitative specifications of the infrastructure that can be provided. For example, for power supply vehicles, it records battery capacity (kWh) and maximum output (kW); for communication vehicles, it records coverage radius (km) and number of simultaneous connections; and for water supply vehicles, it records tank water level (L). In emergency mode, this is used in calculations for "maintaining continuity," such as dispatching replacement personnel before these resources are depleted.

[0104] The "Owner ID" is information that identifies the owner of the mobile infrastructure 10 (e.g., local government, infrastructure company, private logistics company). This is used to identify recipients of "resilience credits" as shown in Figure 10, and to identify contracting parties when leasing private resources for a fee during normal times.

[0105] Figure 8 shows an example of the data structure of the evaluation function and mode definition table stored in the evaluation function storage unit 122 within the storage unit 120.

[0106] The control unit 130 (deployment plan generation unit 133) refers to this table according to the currently selected mode and dynamically constructs an objective function (score calculation formula) for determining the deployment destination of the mobile infrastructure 10.

[0107] The "Mode 1 (peacetime)" record has defined economic evaluation indicators.

[0108] Specifically, metrics such as "Profit" (profitability from electricity sales and delivery fees), "Efficiency" (minimizing travel costs), and "Service Level" (meeting normal user demand) are set. For example, "Profitability" may be calculated as expected revenue by multiplying price data obtained via API from real-time prices in the wholesale electricity market (dynamic pricing) by the predicted sales volume at the destination event venue, etc. "Energy efficiency" may be calculated as the solution to the traveling salesman problem, minimizing the battery consumption of the mobile infrastructure and the total travel distance until delivery is completed for delivery orders to multiple locations. Each metric is assigned a "weighting coefficient (w1, w2…)", and for example, by giving a high weight to "Profitability", the system as a whole will aim to become profitable.

[0109] Furthermore, "logistics efficiency" may be quantified by a logic that calculates the optimal flow point (dynamic hub of a hub-and-spoke system) for each aircraft in a multimodal delivery network using multiple logistics drones and automated guided vehicles (AGVs) deployed at various locations within a city, so as to minimize the waiting time for cargo transshipment (idle time) and the available capacity of the load. In addition, "request completion rate" is calculated as the percentage of infrastructure usage requests (vehicle dispatch requests, etc.) received from user terminals 400 that can be completed and delivered within the specified desired time period (SLA: Service Level Agreement). The system may calculate a weighted linear sum of these multiple economic indicators to determine the deployment during normal times.

[0110] On the other hand, the "second mode (emergency)" record defines evaluation indicators for survival and maintenance.

[0111] Specifically, metrics such as the "survival rate" in the affected area, "infrastructure coverage" indicating the range of communication and power supply, and "critical infrastructure utilization rate" for hospitals and other critical facilities are set. For example, the "survival rate" is calculated by simulating the extended survival time based on data on the capacity of evacuation centers and current temperature and humidity data, and simulating the risk of heatstroke, etc., and the extension of survival time when air conditioning is operated by power supply vehicles and drinking water is provided by water supply vehicles. In addition, the "infrastructure coverage" may be calculated as the percentage of households for which communication functions are restored by overlaying 3D polygon data of the radio wave range when communication vehicles are deployed with nighttime population mesh data based on the basic resident register.

[0112] Furthermore, the "critical facility operational maintenance rate" may be calculated by multiplying a list of critical infrastructure facilities such as hospitals, water treatment plants, and government agencies located within the affected area by the fuel reserve data of the emergency generators equipped at each facility and a criticality coefficient, thereby predicting the percentage of facilities that would cease to function without the intervention of mobile infrastructure by the system. In addition, the "time required to restore infrastructure function" may be calculated not only based on straight-line distance, but also by calculating the estimated arrival time (ETA) that takes into account detour routes for obstacles on the road (debris, sinkholes, etc.) analyzed from satellite data and drone aerial images, as well as the estimated time to complete a task when multiple mobile infrastructures work in parallel. The system may determine the amount and deployment order of mobile infrastructure to maximize these indicators (or minimize the required time).

[0113] In emergency mode, the "profitability" metric is either excluded or its weighting coefficient is set to zero (or negative), while "survival rate" and "critical facility operational rate" are given extremely high weights. As a result, mobile infrastructure 10 will autonomously move to save lives, even in remote or dangerous areas where economic losses would be incurred.

[0114] Thus, this system does not operate with a single algorithm, but rather, by changing the evaluation function (rule) itself that it references in response to a trigger, it can instantly transform its social role without changing the physical hardware configuration.

[0115] Figure 9 shows an example of the structure of a table that defines dependencies between infrastructure functions, stored in the dependency definition DB 123 within the storage unit 120.

[0116] This system 100 not only dispatches individual vehicles, but also has the ability to understand the physical dependencies between infrastructure functions and formulate complex deployment plans. When a recovery target is set in emergency mode, the deployment plan generation unit 133 refers to this table to identify the necessary accompanying resources.

[0117] This table manages the following attributes associated with the "Target Function (Recovery Objective)".

[0118] "Mandatory resources" refer to the types of infrastructure that are physically essential to provide the target functionality.

[0119] For example, as shown in Record 1, when the target is a "Communication Base Station (COMM)", "Power Supply (POWER)" is defined as a required dependent resource. This allows the system to check the local power situation when dispatching a communication vehicle and, if there is a power outage, to always dispatch a power supply vehicle along with (or ahead of) the communication vehicle.

[0120] Similarly, in Record 3, "Medical," both "Power" and "Water" are defined as essential, forming the basis for the triple-domain approach.

[0121] "Recommended Dependent Resources (Optional)" indicates infrastructure types that are not required but whose effectiveness is enhanced when provided simultaneously.

[0122] For example, for "shelter management," in addition to the essential "electricity" and "water," "communication (COMM)" and "logistics (LOGI)" are recommended. If the system has sufficient resources, it proposes deploying these as a "complete package."

[0123] "Requirement" defines the minimum specifications (consumption, etc.) required for the dependent resource.

[0124] For example, parameters such as "an average power supply capacity of 1.5 kW" is stored to operate a communication base station for one hour, and the deployment plan generation unit 133 selects (matches) a power supply vehicle with an appropriate capacity based on this.

[0125] By structuring the "connections" between infrastructures using this table, the system can automatically and quickly perform the "complex resource allocation decisions" that were previously made by skilled personnel at the disaster response headquarters.

[0126] Figure 10 shows an example of the structure of the resilience credit management table stored in the memory unit 120 (or blockchain ledger 124).

[0127] This table manages the "contribution level" for each business participating in this system 100 (local government, logistics company, construction company, etc.) and the "value (tokens)" issued based on that level.

[0128] The "Business Operator ID" identifies the stakeholders who own and provide the mobile infrastructure 10.

[0129] The "Contribution Score (Cumulative)" is an indicator that shows how much social contribution the mobile infrastructure 10 owned by the operator made in the second mode (emergency). This score is calculated not only based on the amount of resources provided, but also by taking into account weights such as "location of provision (high score for severely affected disaster areas)" and "timing (high score for arrival immediately after the disaster)," as shown in Figure 10.

[0130] "Credit balance held" represents the current balance of "Resilience Credits (RC)" issued based on contribution scores. These credits may be implemented as tokens managed on the blockchain.

[0131] As shown in Figure 10, this credit can be used as a means of payment when using other people's infrastructure in the first mode (normal times), or as a "priority right" to receive priority dispatch.

[0132] The "Transaction History (Smart Contract)" records the history of credit increases and decreases.

[0133] For example, in the records for March 11, 2026, in emergency mode, the smart contract (SC-001: Emergency Support Reward Logic) was automatically executed and 5000 RC were issued (minted) for the achievement of "dispatching two power supply vehicles to hospitals".

[0134] On the other hand, records from April 1, 2026 show that in normal mode, 200 RC were consumed (burned or transferred) by a smart contract (SC-005: priority use logic) as payment for "prioritizing drone delivery".

[0135] In this way, by recording and managing contributions during emergencies as irreversible and transparent "assets," participating businesses can justify their "peacetime costs" as "emergency investments," which encourages continued participation in the system and further stabilizes its operation.

[0136] <3 operations> Figure 11 is a flowchart showing the system-wide control process (main routine) executed by the control unit 130 of the management server 110. This process is executed repeatedly at predetermined intervals while the system is running.

[0137] Step S101 (First Mode Execution): In the initial state, the system operates in "Mode 1 (Normal Operation)". The control unit 130 reads the "Normal Operation Evaluation Function (Economy Maximization)" from the evaluation function storage unit 122 and instructs each mobile infrastructure 10 on the location and tasks (electricity sales, logistics and delivery, etc.) that will maximize profitability and efficiency.

[0138] Step S102 (Trigger Monitoring): The control unit 130 (trigger detection unit 131) constantly monitors input data from the external system 200 (earthquake reports, weather data, SNS trends, infrastructure operating rates, etc.).

[0139] Step S103 (Emergency Determination): Based on the data obtained in step S102, it is determined whether or not a "trigger" has occurred.

[0140] In this system 100, the "predetermined trigger" that initiates the switch to the second mode may be configured to include a variety of detection logics, depending on the anticipated variations in emergency situations (disaster prevention / defense events), as follows:

[0141] • Typhoons and floods: In addition to special warnings received from external systems such as the Japan Meteorological Agency, the system is triggered by data from IoT water level sensors installed in rivers and sewers that exceed a specified danger level, or by wide-area flood area estimation data using the aforementioned satellite data. This allows the system to instantly estimate the collapse and submersion of buildings and fixed infrastructure.

[0142] • Earthquakes and tsunamis: The system is triggered by data from a wide-area seismometer network that simultaneously detects shaking above a specific threshold (e.g., seismic intensity 6-minus) at multiple locations, or by data from received tsunami warnings. In the case of a tsunami, the system compares this data with elevation data (DEM) and detects a trigger when it predicts that coastal infrastructure has been damaged.

[0143] • Fire: In response to large-scale accidents at factories, forest fires, or fires spreading in urban areas, the system is triggered by frequent alert signals from a network of smart fire alarms deployed throughout the city, as well as wide-area detection data of abnormal heat sources from infrared observation satellites.

[0144] • Physical destruction such as armed attacks: In response to attacks from other countries, the system will be triggered by the receipt of official alerts such as J-Alert. Furthermore, detection of interruptions in ping responses between land facilities, submarine cable landing stations, and core communication nodes, or a sudden loss of communication traffic, will be considered a "physical network disruption (attack or accident)" and will be treated as a trigger for infrastructure loss.

[0145] • Infrastructure outage due to cyberattack: This refers to an infrastructure outage event that does not involve physical destruction, triggered by an alert from a power company's or telecommunications carrier's network monitoring system (NOC) detecting abnormal traffic such as a DDoS attack, or by receiving an unresponsive (down) signal from the infrastructure control system.

[0146] For example, an emergency is determined (Yes) if "an earthquake signal of magnitude 6 or higher is received" or "the number of power outage reports in a specific area exceeds a threshold." If no trigger is detected (No), the process returns to step S101 and continues in normal mode. The emergency determination in step S103 may include analysis logic using acquired text data and image data. For example, in the analysis of text data from social media, a natural language processing model is used to detect a trigger when the frequency of keywords indicating infrastructure failure or rescue requests, such as "power outage," "no water," and "help," within a specific area (e.g., a 1km square mesh), exceeds a normal statistical threshold (e.g., three times the standard deviation). In addition, in the analysis using remote sensing data such as satellite data, flooded areas are identified from synthetic aperture radar (SAR) satellite observation data, and the system estimates that fixed infrastructure such as substations and water treatment plants within that area are submerged, which is used as a trigger for supply disruption.

[0147] Step S104 (Mode Switching): If an emergency is detected, the control unit 130 immediately switches the operating mode of the entire system to "second mode (emergency)". Accordingly, the referenced evaluation function is changed to the "emergency evaluation function (maximizing survivability and coverage)", and normal economic activity tasks are forcibly interrupted (or suspended).

[0148] Step S105 (Damage analysis and target setting): The control unit 130 identifies the affected area, the type of infrastructure damage (power outage, water outage, service disruption), and the location of critical facilities, and creates a target list of facilities that need to be restored.

[0149] Step S106 (Deployment plan generation): The deployment plan generation unit 133 calculates the optimal mobile infrastructure 10 to be assigned to the target list. In this process, cross-domain cooperation (resolution of dependencies) is also taken into consideration, and pairs such as "communication vehicle and power supply vehicle" are generated.

[0150] Step S107 (Command transmission and autonomous movement): Based on the generated plan, movement commands are sent to each mobile infrastructure unit 10. Each mobile unit rushes to the disaster area while sensing road conditions and begins providing infrastructure functions.

[0151] Step S108 (Recovery detection determination): Even while the second mode is running, the control unit 130 continues to monitor the situation. If it receives a signal that the fixed infrastructure has been restored, or if it is determined that the alternative infrastructure (such as a temporary power supply) has been sufficiently installed (Yes), it considers the restoration complete.

[0152] Step S109 (Mode recovery): For mobile infrastructure 10 in areas where recovery has been confirmed, the second mode is deactivated and the system is returned to the first mode. The mobile units either return to their base station for recharging or immediately resume economic activities in the vicinity.

[0153] Figure 12 is a detailed flowchart of the deployment plan generation process (step S106 in Figure 11) performed by the deployment plan generation unit 133.

[0154] Step S201 (Mode Determination): First, it is determined whether the currently set mode is "Mode 1 (peacetime)" or "Mode 2 (emergency)".

[0155] <In the first mode (normal times)> Step S202 (Acquisition of economic demand data): Under normal circumstances, economic demand data is acquired from external systems 200 and user terminals 400. Specifically, this includes regional electricity market prices (dynamic pricing), logistics delivery orders, and event information.

[0156] Step S203 (Application of the first evaluation function): Based on the "first criterion" shown in Figures 1 and 8, the "expected revenue (expected sales - relocation costs)" is calculated when each mobile infrastructure 10 is deployed to a specific location.

[0157] Step S204 (Profit Maximization Placement Determination): Determine the optimal placement (location and task) that maximizes the calculated expected revenue. For example, plan to move power generators to areas with high electricity prices and sell the electricity.

[0158] In determining this placement, the system may dynamically identify "urban void spaces" such as unused parking lots, public open spaces, or surplus road space in urban areas, and select these spaces as temporary or permanent infrastructure deployment bases (standby locations or operational locations). This allows the system to flexibly and cost-effectively construct an infrastructure network by fitting into gaps in existing urban spaces, without requiring the acquisition of expensive land or large-scale foundation work.

[0159] <In the second mode (emergency)> Step S205 (Acquisition of damaged / missing data): In the event of an emergency, damage data is acquired from the trigger detection unit 131, etc. This includes information on areas without power, areas without communications, areas without water, and the locations of isolated evacuation centers.

[0160] Step S206 (Dependency Resolution): Refer to the dependency definition DB123 to identify the combination of resources required for the recovery target. For example, if a "power supply vehicle" is required for "communication recovery," these will be grouped together as a pair.

[0161] Step S207 (Application of the second evaluation function): Based on the "second criterion" shown in Figures 1 and 8, the "social score" is calculated for each mobile infrastructure (or pair) when placed in a specific location. Here, the "survivability" and "coverage rate" are quantified based on population density maps and the presence or absence of critical facilities.

[0162] Step S208 (Determining the optimal placement for maximizing survivability): The arrangement that maximizes the calculated social score is determined. Even if it results in an economic deficit (e.g., long-distance travel), the plan may be adopted if it has a high score.

[0163] Furthermore, the determination of the deployment plan for the second mode in step S208 may include coordinated operation with fixed infrastructure that is not affected by disaster or attack and is functioning normally. Fixed infrastructure is often designed and operated with a certain degree of redundancy (buffer) even during peacetime. The system may also dynamically calculate the "surplus resource amount" by subtracting the minimum amount of resources required for maintenance by residents, etc., in the surrounding area from the supply capacity of the normally functioning fixed infrastructure in that area.

[0164] The system sets up the fixed infrastructure with the calculated surplus resources as a "supply hub" for the mobile infrastructure 10 and generates a plan for round trips (shuttle transport or rotation) between it and the disaster area.

[0165] • Example of water coordination: For water treatment plants and distributed water storage tanks (dams, etc.) that escaped damage, the surplus water volume is calculated after securing the legally mandated reserve water volume for local residents. The system designates these facilities as water refueling points for water tankers, and after refilling the water tankers, they are dispatched to evacuation centers in the disaster-stricken areas to provide drinking and bathing water.

[0166] • Example of power integration: The system calculates the amount of surplus power from large-scale battery storage systems (BESS), microgrids, or small modular reactors (SMRs) that continue to operate outside the disaster area. The system designates these as rapid charging spots for 10a power supply vehicles and rotates multiple power supply vehicles to continuously charge and supply power to the disaster area.

[0167] • Example of communication and logistics collaboration: Data centers and logistics warehouses that escaped damage are set up as forward bases for communication vehicles (drone base stations, etc.) and logistics drones sent to disaster-stricken areas, and are operated in conjunction as stable wired backhaul lines and supply sources for materials.

[0168] In this way, by not only enabling mobile infrastructure to function independently, but also integrating existing fixed infrastructure with redundancy as a "living supply source" into the system, sustainable infrastructure supply can be achieved even in prolonged emergencies.

[0169] Step S209 (Generation of planning output and machine control commands): The deployment plan generation unit 133 automatically generates and outputs the determined deployment plan (and the optimal resource allocation derived from the aforementioned digital twin simulation) not only in a report format requiring human interpretation and approval (or not in such a report format), but also as a "machine-readable control command set" that can be directly executed by the edge control unit 14 of each mobile infrastructure 10.

[0170] This set of control commands may include not only destination coordinates, but also a target arrival time (Time-To-Arrival for rendezvous control), a travel trajectory (waypoints) including GNSS coordinates for autonomous driving, and physical output parameters of the infrastructure module 15 to be executed immediately upon arrival at the site (e.g., voltage and frequency settings of the power supply inverter, tilt angle and output signal strength profile of the communication antenna, etc.). This completes a cyber-physical loop in which the results of advanced damage prediction and agent simulation in cyberspace are directly and immediately translated into control of hardware (actuators) in the physical space without time lags or judgment errors caused by human operation (intervention).

[0171] Figure 13 is a detailed flowchart of the "cross-domain collaboration processing" performed by the deployment plan generation unit 133. This processing is called when restoring specific infrastructure functions (targets) in emergency mode.

[0172] Step S301 (Identify recovery target): First, based on the damage analysis, identify the infrastructure functions (primary resources) that need to be restored. Here, as an example, let's assume the target is "restoration of communication areas (dispatch of communication vehicles)."

[0173] Step S302 (Dependency DB reference): Next, the dependency definition DB123 in the storage unit 120 is referenced, and the definitions of "essential dependent resources" and "recommended dependent resources" for the target function (communication) are read.

[0174] In this example, the rule "Power supply is essential for the operation of a communication base station" is obtained.

[0175] Step S303 (On-site environment check): The system refers to current data of the target deployment site (disaster-stricken area) to determine whether the dependent resource (electricity) is available locally.

[0176] If there is no power outage at the site and the existing power grid is operational (Yes), an escort vehicle is not needed, so proceed to step S308 and deploy the communication vehicle alone.

[0177] If there is a power outage at the site (No), the communication vehicle alone cannot operate, so proceed to step S304.

[0178] Step S304 (Sub-resource search): The system searches the mobile infrastructure database 121 for mobile infrastructure (power supply vehicles, etc.) capable of providing the insufficient dependent resource (electricity). In this process, it extracts candidates that meet the target's required "essential specifications (e.g., 1.5kW or more)" and are capable of reaching the site.

[0179] Step S305 (Pairing and Grouping): The selected "primary unit (communication vehicle)" and "secondary unit (power supply vehicle)" are logically linked together as a single "cooperation unit (group)." As a result, the two units are treated as a set in subsequent processing.

[0180] Step S306 (Synchronized travel plan generation): This involves coordinating the movement schedules of grouped aircraft. Specifically, it calculates routes and speeds (rendezvous control) so that the power vehicle arrives "simultaneously with or before" the communication vehicle and can quickly connect the power connector.

[0181] Step S307 (Issuance of coordinated command): Based on the generated plan, cross-domain cooperation commands are finalized for each vehicle. The commands include the "partner vehicle ID" and the "merging point."

[0182] This process prevents situations where rescue teams arrive on-site only to find they are unable to operate due to a lack of power, enabling effective rescue operations where diverse infrastructures work together seamlessly.

[0183] Figure 14 is a flowchart of the autonomous distributed control processing performed by the edge control unit 14 (distributed cooperative logic 14b) of the mobile infrastructure 10.

[0184] This process is automatically activated as a fail-safe if wide-area communication with the management server 110 is interrupted due to the intensification of a disaster or other reasons.

[0185] Step S401 (Server communication monitoring): The mobile infrastructure 10 periodically performs "heartbeat communication (liveness check)" with the management server 110. If it is determined that there is no response for a certain period of time or that the communication strength has significantly decreased (No), the system is determined to be in an "isolated state" and proceeds to step S402.

[0186] Step S402 (Autonomous Mode Activation): The control mode is switched from "server-centralized management" to "autonomous distributed control (edge ​​AI mode)". From this point onward, the mobile object will decide its actions based on its own judgment and consultation with its surroundings.

[0187] Step S403 (Proximity Broadcast): The proximity communication unit 13b (Wi-Fi Direct, Bluetooth, etc.) broadcasts a "hello packet" to the surrounding area. This allows the system to search for other mobile infrastructure 10 within its communication range.

[0188] Step S404 (Local cluster formation): Neighboring mobile devices that have responded form a temporary network (mesh network or cluster). Within this group, they synchronize information such as "infrastructure type (electricity, water, etc.)" and "remaining resources" as a shared table.

[0189] Step S405 (Leader Election): Within the formed cluster, a "leader unit" is selected to make decisions.

[0190] The selection algorithm automatically selects the aircraft with the highest battery level, the highest CPU processing power, or the aircraft located on the highest ground with the best chance of communication recovery as the leader.

[0191] Furthermore, since each mobile infrastructure 10 is constantly moving, the composition of the units constituting the cluster and the communication topology can change dynamically. For this reason, each unit in autonomous distributed control mode may continuously exchange heartbeat packets and detect units leaving the cluster or new units joining in real time to rebuild the cluster configuration. In addition, if the selected leader unit is lost (disappears) due to movement outside the communication range or failure, a failover function is provided that immediately runs a re-election algorithm among the remaining units to select a new leader. Moreover, if a unit equipped with the aforementioned "computation resource module" exists within the cluster, that unit will be preferentially selected as the leader and will locally undertake complex resource sharing calculations, thereby achieving advanced autonomous cooperation in the edge environment.

[0192] Step S406 (Decision on Cooperative Action): The selected leader machine (or a consensus among all machines) performs resource optimization calculations within the cluster.

[0193] For example, in a situation where "Unit A has surplus power, but Unit B is on the verge of running out," a local plan is generated such as "Unit A approaches Unit B and provides P2P power." Alternatively, a decision is made such as "All units form a convoy and move collectively to an area with a high probability of survival." For example, in a situation where "Unit A has surplus power, but Unit B is on the verge of running out," a local plan is generated such as "Unit A approaches Unit B and provides P2P power." Furthermore, as coordination in accordance with the second criterion (maximizing survival), the leader unit receives SOS beacons transmitted from smartphones of nearby disaster victims via proximity communication, sets the area with the highest density of SOS transmissions (where the probability of survival is significantly reduced) as the local recovery target, and then makes an autonomous decision to guide the communication vehicles and power vehicles within the cluster collectively (in a convoy) to that area.

[0194] Step S407 (Physical Action Execution): Based on the determined coordinated actions, physical movement and infrastructure provision (power supply, water supply, etc.) will be carried out.

[0195] Step S408 (Confirmation of communication recovery): Even during autonomous operation, the system monitors the recovery of wide-area communication, and if the connection is restored, it sends the accumulated logs to the server and returns to centralized management mode (flow in Figure 11).

[0196] In this way, even if the central command and control system is lost, the robots on site can "communicate" with each other and help one another, preventing the complete collapse of infrastructure functions (ensuring survivability through degraded operation).

[0197] Figure 15 is a flowchart of the resilience credit management process executed by the transaction management unit 134 of the management server 110. This process is broadly composed of the "issuance phase in emergency mode" and the "settlement phase in normal mode".

[0198] <Phase 1: Issuance Process (Emergency Mode)> Step S501 (Measurement of Supply Amount): In emergency mode, when the mobile infrastructure 10 arrives at the site and begins the commanded task (e.g., supplying power to evacuation centers or establishing communication areas), IoT sensors (such as smart meters) installed on the mobile infrastructure 10 measure physical quantities such as the amount of electricity supplied (kWh), the amount of communication data (GB), or the amount of water supplied (L) in real time or periodically. This measurement data is securely transmitted in a tamper-proof format as external input data to a smart contract on the blockchain.

[0199] Steps S502 (Contribution Score Calculation) and S503 (Blockchain Recording and Issuance): The smart contract automatically executes a pre-coded evaluation logic based on the received external input data.

[0200] Specifically, the system calculates the business operator's contribution by performing a calculation such as "Score = Amount Provided × Location Coefficient (e.g., a multiplier based on the risk level on the hazard map) × Time Coefficient (a decay multiplier based on the time elapsed since the disaster)".

[0201] Then, resilience credits (RC) corresponding to the calculated score are issued (minted) to the target business's wallet address and recorded as a transaction in the distributed ledger 124. This entire process is executed autonomously and transparently by the program without the need for manual approval from an administrator.

[0202] <Phase 2: Settlement and Usage Processing (Normal Mode)> Step S504 (Received usage request): In normal operation, the system receives requests from businesses (credit holders) for priority use of infrastructure or discounts. For example, a request might be, "We want to secure logistics drones on a priority basis."

[0203] Step S505 (Balance Check / Lock): Refer to blockchain ledger 124 to verify that the applicant has sufficient credit balance. Steps S506 (Smart Contract Payment) and S507 (Service Provision and Incentive Granting): If conditions such as priority requests are met, the smart contract will be automatically executed, and the necessary credits will be consumed (burned) from the applicant's wallet or transferred (transferred) to the service provider's (another business or system operator's) wallet.

[0204] Furthermore, in this system, the physical control of the target mobile infrastructure 10 is automatically unlocked when payment is completed via smart contract (confirmation of transaction approval). For example, when a credit payment is completed for a priority use request for another operator's power vehicle at an event venue, the system 100 sends a "power supply start permission command" to the edge control unit 14 of the corresponding power vehicle, releasing the physical lockout of the connector and enabling power output.

[0205] Thus, a cyber-physical interconnected architecture in which the transfer of value on the economic and transaction layer (blockchain) is directly reflected as the operation of the physical layer (mobile entities) via the communication and control layer realizes a frictionless infrastructure interoperability ecosystem during normal times.

[0206] This entire process further transforms the volunteer activities (costs) incurred during emergencies into business advantages (profits) during peacetime.

[0207] <4 Screen Examples> Figure 16 shows an example of the integrated monitoring dashboard (normal mode) screen displayed on the user terminal 400's display unit.

[0208] This screen employs a "standard operating system (map scrolling, zoom level changes, layer switching, etc.)" similar to that of general map applications and ride-hailing service management screens, enabling operators (local government officials or infrastructure operators) to intuitively grasp the situation and make quick decisions. As a result, users can utilize this system without incurring the cost of learning new operations.

[0209] The main map area 601 displays a map of the city to be managed. The "profitability heatmap 602," a feature of the present invention, is overlaid on this map using contour lines or grayscale.

[0210] This heatmap 602 visualizes areas with high electricity market prices and areas where delivery demand is surging, and is shown as "High-profit areas" in the diagram. Users can instantly determine which areas would be most economically efficient to deploy mobile infrastructure 10 to simply by looking at this display.

[0211] Mobile infrastructure icon 603 is displayed on the map, and its current status (occupied, vacant, charging, etc.) can be seen.

[0212] Side panel area 604 displays the system's overall KPIs (Key Performance Indicators). Economic indicators such as "Total Sales" and "Utilization Rate" are updated here in real time.

[0213] The control panel area 605 has multiple control buttons.

[0214] Here, alongside general operation buttons such as "View Details" and "Search," is a "Revenue Maximization Auto (Optimize)" button 606 that activates the core function of the present invention.

[0215] Simply by the user pressing button 606, calculations based on the aforementioned "first evaluation function" are performed, and optimal dispatch commands are sent to all mobile vehicles simultaneously, directing them towards high-profit areas on the heatmap 602.

[0216] In this way, the UI design allows users to switch to economically rational operations with a single click, without having to perform complex parameter adjustments, thereby improving the ease of use of the system during normal operation.

[0217] Figure 17 shows an example of the screen immediately after the system transitions to "second mode (emergency)" upon detection of a trigger such as a disaster.

[0218] When the control unit 130 detects an emergency trigger, it automatically transitions from the normal operation screen shown in Figure 16 to this screen and provides a visual warning (alert) to the operator.

[0219] The alert notification window 610 pops up at the very front in the center of the screen and notifies the user of the trigger, such as "Earthquake Early Warning Received" or "Wide-Area Power Outage Detected," as well as that a mode switch has occurred. This allows operators to respond immediately with a sense of urgency.

[0220] The display content in the main map area 601 switches from the normal "profitability heatmap" to the "damage situation map 612".

[0221] Here, areas experiencing power outages or communication disruptions are highlighted with shading, and critical locations where infrastructure supply is particularly disrupted (hospitals, evacuation centers) are marked with an "X" (missing). This allows users to intuitively understand "where assistance is needed."

[0222] The KPI display in side panel area 604 will also switch from economic indicators to survival indicators.

[0223] Specifically, the "Predicted Survival Rate" and "Infrastructure Coverage" are displayed. These are the results of simulations performed by the deployment plan generation unit 133 and indicate the predicted percentage of the survival rate that can be maintained if the current plan is implemented.

[0224] In the control panel area 605, the most significant change is that the main action button has changed from "Maximize Revenue Auto" to the "Execute Rescue" button 616.

[0225] In the chaotic conditions of an emergency, manually issuing instructions to individual vehicles is difficult. Therefore, this system automatically generates complex deployment plans, including cross-domain coordination (who will be paired with whom and where they will go), and is designed so that users can initiate optimal rescue operations simply by "approving" (one-clicking) button 616.

[0226] This UI configuration allows even inexperienced administrators to immediately implement the system's recommended "human life-first logic."

[0227] Figure 18 is a results display screen for interactively operating the simulation function provided by the deployment plan generation unit 133.

[0228] This screen is used when a user wants to modify an automatically generated plan or manually enhance support for a specific area.

[0229] The main map area 601 displays a map showing the current damage situation.

[0230] On the right side of the screen, a list of available mobile infrastructure is displayed as the "Resource Palette 620," from which the user can drag and drop any icon (e.g., "Power Truck") to any point on the map (e.g., "Hospital Area") (Operation A).

[0231] When this operation is performed, the system immediately recalculates in the background using the second evaluation function. The result is then displayed in the "Simulation Results Panel 622" at the bottom of the screen.

[0232] The results panel 622 contains the following information:

[0233] 1. Survival rate trend graph 624: The survival rate decline prediction curve (dotted line) for the "Current" scenario is overlaid with the survival rate maintenance curve (solid line) for the "Forecast" scenario. This allows users to quantitatively understand the effect, such as "adding just one of these power supply vehicles will improve the survival rate by 15% after 72 hours."

[0234] The system constructs a digital twin (urban vulnerability map) on a 3D model of the city, reflecting real-time damage. A predicted survival rate decline curve (dotted line) for the "current" scenario is overlaid with a survival rate maintenance curve (solid line) for the "forecast" scenario. This simulation is performed by calculating the difference between, for example, "the time until the hospital's backup generator runs out of fuel if no power generator is deployed" and "the time the power generator is virtually deployed to extend its operating time," and plotting this as a comparison graph on the dashboard. This allows users to quantitatively understand the effect, such as "adding just one power generator improves the survival rate by 15% after 72 hours."

[0235] Furthermore, the damage prediction and deployment effect simulations performed by this system 100 (particularly the deployment plan generation unit 133 or visualization means) can utilize several methods, either individually or in combination, depending on the computing resources held by participating businesses and local governments, as well as the scale of the target area and the required accuracy.

[0236] • Physics-based digital twin simulation: A 3D model of the city (BIM / CIM data, point cloud data, etc.) is constructed in cyberspace, and fluid dynamics simulations (prediction of inundation due to typhoons, floods, and tsunamis, etc.) and structural calculation simulations (prediction of building collapse, etc.) are performed based on weather data and seismic wave data. This allows for the highly accurate identification of roads that mobile infrastructure 10 cannot reach and areas at risk of flooding, and the generation of deployment plans.

[0237] • Crowd behavior simulation using AI agents: A large number of AI agents, representing humans, animals, etc., are placed on a constructed digital twin to perform the simulation. Each AI agent is controlled using a Large-Scale Language Model (LLM), etc., and performs autonomous movement actions (evacuation actions, etc.) based on current virtual visual information, instinctive need parameters such as "hungry" and "thirsty," as well as psychological and social anxiety parameters such as "unable to contact family" and "no power and information is cut off." Furthermore, by simulating how these AI agents collect and transmit information on a network such as a simulated SNS in the virtual space (posts such as "There is no water at the XX evacuation center"), the risk of depletion of supplies due to the concentration of evacuees in a specific area and the occurrence of panic due to communication disruption are predicted, and the placement of communication vehicles and water supply vehicles is determined in advance to resolve these issues.

[0238] • Pre-deployment simulation considering lead time: The system can perform simulations and generate deployment plans not only after an emergency has actually occurred, but also at the "precursor" stage when an emergency is predicted. For example, based on the predicted approach route of a large typhoon and the number of days remaining until its arrival (lead time), or the expected grace period between the signs of an attack in a defensive event and the execution of the operation, it can perform a simulation to "pre-assemble mobile infrastructure to the immediate vicinity of the predicted disaster area while securing a safe zone before the emergency materializes and transportation networks are disrupted." This allows the system to begin preparations for the second mode without waiting for an emergency to occur, and to perform autonomous deployment that minimizes the time lag until arrival at the scene.

[0239] • Macro-statistical model simulation independent of digital twins: In environments where computational resources for rendering 3D models or performing advanced physics calculations are insufficient, or when quick estimations are needed for a wider area, the system utilizes a lightweight mathematical optimization model using 2D mesh data and historical disaster statistics. For example, a probabilistic model (such as a Markov chain) or macro-level supply and demand balance calculation can be used to quickly and simply calculate the "improvement in survival rate when power generators are deployed," using only population distribution data from the Basic Resident Register and infrastructure capacity data as variables.

[0240] Thus, the system can dynamically select or scale simulation methods according to available data and computing resources, making it flexibly implementable in the diverse environments held by various businesses.

[0241] Furthermore, the digital twin in this simulation space may not be limited to offline numerical analysis based on pre-prepared static urban data (historical disaster data, defense data, BIM models, etc.). The digital twin may be continuously assimilated (updated) in milliseconds to seconds by dynamic data (progress of damage and fluctuations in infrastructure demand) fed back in real time from sensor groups 12 (LiDAR, cameras, communication traffic monitoring data, etc.) of mobile infrastructure groups 10 deployed on the front lines of the physical space.

[0242] Each AI agent, driven by an LLM or similar within the simulation space, instantly senses changes in this dynamic digital twin (for example, a change in the physical state such as "water trucks have actually arrived at the site and water has begun to be supplied") within the virtual space, reduces its own "anxiety parameters" and "thirst," and recalculates its next action logic in real time based on this (for example, canceling a move to another shelter and staying where it is). In this way, unlike simulation and consulting methods that rely on static datasets and offline analysis, this system can achieve extremely accurate predictions that immediately incorporate the results of interventions in the physical space, and continuous resource reallocation based on those predictions.

[0243] Furthermore, the system resolves issues that could be seen as trade-offs through mode switching. For example, regarding data handling, in the first mode (normal times), only anonymized data and low-resolution data from user terminals 400, etc., are acquired from the perspective of privacy protection. However, when an emergency trigger is detected and the system switches to the second mode, based on an emergency exception (or prior opt-in consent), the system may dynamically unlock restrictions on acquiring pinpoint GPS coordinates of terminals in the affected area and high-resolution biometric data (heart rate, etc.) from wearable devices, which can then be used for simulations and life-saving activities. In addition, regarding hardware lifespan management, in the first mode, the upper limit of the battery charge rate (SoC) of the mobile infrastructure 10 is limited to prevent degradation. However, when signs of an emergency are detected, the system may allow the risk of degradation and raise the upper limit of the charge rate to 100%, or unlock the emergency reserve capacity that is normally sealed.

[0244] 2. Infrastructure adequacy chart 626: The adequacy of various infrastructure functions, such as power, communications, and water, is displayed comparatively using radar charts or bar graphs. Furthermore, from a cross-domain collaboration perspective, "bottleneck resources" within the entire system are highlighted. For example, the system visualizes operational limitations (dependency constraints) caused by shortages of other types of infrastructure, such as "there are enough medical containers and refrigerated containers, but the availability of accompanying power vehicles is limited, thus restricting the operational rate of these containers."

[0245] 3. Action button 628: If the user is satisfied with the simulation results, they can simply click the "Apply Plan" button to register the virtual deployment as an actual deployment command in the system.

[0246] Furthermore, this system 100 (visualization means or transaction management unit 134) has a function to present "investment guidance (entry recommendation) information" on a dashboard to businesses considering the new development of mobile infrastructure or participation in a system, based on the simulation results of these cross-domain collaborations and the analysis of the supply and demand gap.

[0247] Specifically, the system identifies specific single-function infrastructures that are currently lacking (e.g., power supply vehicles or water supply vehicles) and simulates the ripple effect of adding and registering these single-function infrastructures into the system, showing how much cross-domain collaboration with existing infrastructures will be activated and how much the overall resilience (ability to maintain survival) of the city will be boosted. Based on the magnitude of this predicted ripple effect, the system then calculates and presents the expected value of resilience credits (expected ROI) that can be expected to be acquired in a second mode (emergency).

[0248] This feature makes it easier for businesses that only possess development technology for water treatment modules or refrigeration / storage modules to understand that "they do not need to develop habitability, communication, and power functions in-house; they only need to provide a single-function mobile infrastructure, and the system's cross-domain coordination will autonomously accompany the optimal power supply and communication vehicles, guaranteeing operation." This further lowers the barrier to participation in the system. At the same time, businesses can easily grasp the market supply and demand balance, including areas outside their expertise, to determine "which infrastructure functions to develop to receive the highest evaluation (credit) from the entire system." This allows them to encourage private investment in truly necessary infrastructure, and as a result, the resilience of the entire ecosystem, in which a wide variety of businesses participate, can be autonomously developed and strengthened.

[0249] In this way, by combining intuitive operation with real-time predictive feedback, it becomes possible to make evidence-based and optimal resource allocations even in tense situations.

[0250] Furthermore, this visualization method (simulation function) can perform a "historical simulation" to verify the effectiveness of deploying mobile infrastructure 10 using this system, even during peacetime when there are no immediate signs of an emergency. This simulation reproduces data from past actual emergency cases (such as past major earthquakes, floods, or widespread power outages) on a digital twin. For example, a specific municipality or company can simulate on the system "how much damage reduction (improvement of survival rates and avoidance of economic losses) is possible if an event equivalent to a past disaster occurs," and display the return on investment (ROI) on a dashboard. This quantitatively demonstrates the validity of participating in this system (introducing mobile infrastructure) compared to making massive investments in fixed infrastructure that is difficult to update, thus facilitating decision-making during peacetime.

[0251] Figure 19 shows an example screen for users (local governments, event organizers, construction companies, etc.) to reserve and request the dispatch of mobile infrastructure 10 in normal mode.

[0252] This screen provides a user experience similar to that of ride-hailing apps and online shopping apps that users use on a daily basis, while also having the function of visualizing and exercising the value of "Resilience Credit (RC)," a key feature of the present invention.

[0253] The header area 630 constantly displays the current "Credit Balance (12,500 RC)". This allows users to always be aware of the assets they have acquired through their contributions during times of crisis.

[0254] Request panel 632 is the area where the conditions for infrastructure dispatch are set.

[0255] Users specify the "deployment location" by entering a map or address, and select the "necessary infrastructure (power supply vehicle, communication vehicle, etc.)" by selecting icons. This operation is similar to that of a typical service and does not require any special learning.

[0256] Order panel 634 displays a quote based on the selections and action buttons. Two types of request buttons are placed side by side here.

[0257] 1. "Standard Request" button 636: This is a standard application for use with cash (or invoice payment). There may be a waiting list during peak hours.

[0258] 2. "Priority Deployment Request (Priority w / Credit)" button 638: This is the control unit that is a key feature of the present invention. By spending your credits (for example, 500 RC), you can secure a priority ride-hailing slot or receive a discount on the usage fee.

[0259] The user only needs to select this button 638, and in the background, the smart contract on the blockchain is executed, whereby payment and grant of priority are completed immediately.

[0260] The credit history panel 640 displays the history of credit acquisition and consumption. By displaying logs such as "Acquired through disaster dispatch (+5000 RC)", the incentive structure of "contribute in emergencies, gain benefits in normal times" is clearly presented to users, so as to promote continuous participation in the ecosystem.

[0261] Furthermore, the credit history panel 640 may display not only simple numerical increases and decreases, but also the traceability (story) of contributions of the mobile infrastructure provided by the user himself / herself during an emergency, namely "which disaster-stricken area, operation of what kind of facility was maintained, and how many evacuees were rescued as a result", in association with metadata (narrative sharing). Further, the held credits may be configured to be transferable on the blockchain not only as the user's own priority usage right, but also as a "gift of priority deployment right" to others (for example, a disaster-stricken business partner company, a specific shelter, etc.). In addition, a function may be provided to grant credits as a reward to an aircraft that autonomously participates in and rushes to disaster prevention and defense drills (virtual emergency events) led by the system in normal times. As a result, a sense of unity beyond mere economic transactions can be continuously fostered among participants, which can encourage them to continue participating in the ecosystem, so that the ecosystem as a whole can develop.

[0262] <Modification>

[0263] (1) An information processing system that performs language processing in response to input of a prompt In the above description of the embodiment, as an example of the information processing system that performs language processing in response to input of a prompt, an example has been described in which the prompt is transmitted to the server of a large language model service that is an external information processing system, and a result generated by the server of the large language model service in response to the prompt is received.

[0264] Alternatively, instead of using an external information processing system, a large-scale language model may be run on the terminal to perform processing in response to prompts. Alternatively, the large-scale language model may be run on a server that holds the information to be included in the prompts.

[0265] As described above, the information processing system that performs language processing in response to prompt input may be an external information processing system different from the service provided by the server, the server may have the functionality of the information processing system, or it may run on a terminal. The terminal may have a processor such as a GPU (Graphics Processing Unit) for running a large-scale language model, and this processor may enable the large-scale language model to perform language processing in response to prompt input. For example, the server may provide a large-scale language model to run on the terminal, and the terminal may be required to build an information processing system that performs language processing.

[0266] <Other> In the above description, "processor" refers to one or more processors. At least one processor is typically a microprocessor such as a CPU (Central Processing Unit), but may be other types of processors such as a GPU (Graphics Processing Unit). At least one processor may be single-core or multi-core.

[0267] Furthermore, at least one processor may be a broad-sense processor, such as a hardware circuit that performs some or all of the processing (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)).

[0268] Furthermore, in the above explanation, the term "xxx table" is sometimes used to describe information that yields an output for a given input. This information can be data with any structure, or it can be a learning model such as a neural network that generates an output for a given input. Therefore, "xxx table" can be referred to as "xxx information."

[0269] Furthermore, the above description is merely an example of the structure of each table; one table may be divided into two or more tables, or all or part of two or more tables may constitute a single table.

[0270] Furthermore, while the above explanation sometimes uses "program" as the subject to describe the process, a program is executed by a processor and performs defined processes using the memory and / or interface as appropriate. Therefore, the subject of the process may also be the processor (or a device such as a controller that has that processor).

[0271] The program may be installed on a device such as a computer, or it may reside on a program distribution server or a computer-readable (e.g., non-temporary) recording medium. Furthermore, in the following description, two or more programs may be implemented as a single program, or one program may be implemented as two or more programs.

[0272] A network consists of various mobile communication systems, such as the internet, LANs, and wireless base stations. For example, a network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks that can connect to the internet via designated access points (e.g., Wi-Fi®). When connecting wirelessly, communication protocols include, for example, Z-Wave®, ZigBee®, and Bluetooth®. When connecting via a wired connection, the network also includes connections made directly via USB (Universal Serial Bus) cables, etc.

[0273] Furthermore, by distributing all or part of each hardware configuration across multiple computers and connecting them to each other via a network, a computer can be virtually realized. Thus, the concept of a computer includes not only computers housed in a single enclosure or case, but also virtualized computer systems.

[0274] Furthermore, each of the above-mentioned configurations, functions, processing units, processing means, etc., may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. The present invention can also be implemented by software program code that realizes the functions of the embodiment. In this case, a storage medium on which the program code is recorded is provided to a computer, and the processor of that computer reads the program code stored in the storage medium. In this case, the program code read from the storage medium itself realizes the functions of the embodiment described above, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media used to supply such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, SSDs, optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, ROMs, and the like.

[0275] Furthermore, the program code that implements the functions described in this embodiment can be implemented in a wide range of programming or scripting languages, such as assembler, C / C++, Perl, Shell, PHP, and Java (registered trademark).

[0276] Furthermore, the program code for the software that implements the functions of the embodiment may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the computer's processor may read and execute the program code stored in the storage means or storage medium.

[0277] The functions realized by the components described herein may be implemented in a circuit or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), CPUs (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to realize the functions described herein. A processor is considered to be a circuit or processing circuitry, including transistors and other circuits. A processor may be a programmed processor that executes a program stored in memory.

[0278] In this specification, circuitry, unit, and means are hardware programmed to perform or execute the functions described herein. Such hardware may be any hardware disclosed herein, or any hardware known to be programmed to perform or execute the functions described herein.

[0279] When the hardware is a processor that is considered to be of the circuitry type, the circuitry, means, or unit is a combination of hardware and software used to configure the hardware and / or the processor.

[0280] While several embodiments of the present disclosure have been described above, these embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their variations shall be included in the scope and gist of the invention, and shall also be included in the invention described in the claims and the equivalent scope thereof.

[0281] In the above embodiments, each device (terminal device, server, etc.) can also be understood as an information processing device. That is, the aggregate of each device can be understood as one "information processing device", and the system may be formed as an aggregate of a plurality of devices. The method of distributing the plurality of functions required to implement the system according to the present embodiment for one or a plurality of hardware can be appropriately determined in consideration of the processing capability of each hardware and / or the specifications required for the system, etc.

[0282] In the above embodiments, in the service provided by the server, a program to be executed on the terminal may be distributed by the server or the like, and the terminal may perform processing in a state where the program is installed, or the processing may be appropriately shared between the terminal and the server. For example, each process of the above embodiments can be performed by a terminal or by a server.

[0283] The above embodiments do not unduly limit the content of the present disclosure described in the claims. In addition, not all the constituent elements shown in the embodiments are necessarily essential constituent elements of the present disclosure. Each drawing is a schematic diagram and is not necessarily strictly illustrated.

[0284] Furthermore, while identification numbers are used as identification information for various objects in the above explanation, other types of identification information (for example, identifiers including letters or symbols) may also be used.

[0285] Furthermore, in the above explanation, when describing similar elements without distinction, a reference code (or a common code among reference codes) may be used, and when describing similar elements with distinction, the element's identification number (or reference code) may be used.

[0286] Furthermore, in the above explanation, the control lines and information lines shown are those deemed necessary for the explanation, and do not necessarily represent all control lines and information lines in the actual product. All components may be interconnected.

[0287] (Note) The details described in each of the above embodiments are noted below.

[0288] (Note 1) A system for integrating and managing multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, the system having a first criterion and a second criterion different from the first criterion as evaluation criteria for determining the placement or operation of the mobile infrastructure, and a control unit that normally executes a first mode in which the placement or operation of the mobile infrastructure is determined according to the first criterion, and switches to a second mode in which the placement or operation of the mobile infrastructure is determined according to the second criterion when a predetermined trigger is detected.

[0289] (Note 2) The first criterion is determined based on the system described in Appendix 1, which includes economic indicators such as profitability of the operation of mobile infrastructure, energy efficiency, logistics efficiency, or the rate of fulfillment of user requests.

[0290] (Note 3) The second criterion is a system described in either Appendix 1 or 2, based on survival or maintenance indicators including at least one of the following: the probability of human survival in the target area, the coverage rate of infrastructure supply, the operational maintenance rate of critical facilities, or the time required to restore infrastructure functionality.

[0291] (Note 4) The trigger is a system described in any of the appendices 1 to 3, which includes any of the following: a disaster warning or armed attack warning received from an external system; a supply disruption signal received from mobile or fixed infrastructure; estimated infrastructure damage data obtained by analyzing text data; or ground surface change detection data obtained by remote sensing such as satellite data.

[0292] (Note 5) The infrastructure function is at least two distinct functions selected from the group of functions including power supply, communication environment provision, water purification or supply, material transport, computing resource provision, and medical care provision, as described in any of the appendices 1 to 4.

[0293] (Note 6) The system described in any of Appendix 1 to 5 further includes a visualization means that simulates the damage or survival rate when an event corresponding to a trigger occurs in the current mobile infrastructure deployment, and outputs the result in comparison with the improvement effect when switching to a second mode when the event occurs.

[0294] (Note 7) The system according to any one of the appendices 1 to 6, wherein, in the second mode, when the control unit decides to deploy mobile infrastructure that provides a specific type of infrastructure function, it generates a plan for the coordinated deployment of mobile infrastructure that provides other types of infrastructure functions, based on a dependency definition that other types of infrastructure functions are essential for maintaining the said infrastructure function.

[0295] (Note 8) The mobile infrastructure is a system as described in any of Appendix 1 to 7, which has a distributed control mode in which, if communication with the control unit is interrupted, or based on a command from the control unit, it communicates directly with other nearby mobile infrastructures and autonomously cooperates to determine placement or operation according to the second criterion.

[0296] (Note 9) In the second mode, the system further comprises a transaction management unit that calculates the contribution of the administrator or owner of the mobile infrastructure that provided infrastructure functions based on the amount, location, or timing of the resources provided, and issues and manages value records (credits) corresponding to said contribution, as described in any of the appendices 1 to 8.

[0297] (Note 10) The Transaction Management Department, in the first mode, grants holders of value records (credits) priority access to mobile infrastructure managed by others, or discounts on usage fees, as described in Appendix 9.

[0298] (Note 11) The system described in any of Appendix 9 to 10 automatically executes the conclusion of resource provision agreements and the issuance or settlement of value records (credits) associated with mode switching using smart contracts based on distributed ledger technology.

[0299] (Note 12) A method for a computer having one or more computer processors to centrally manage multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, wherein the method comprises one or more computer processors that maintain a first criterion and a second criterion different from the first criterion as evaluation criteria for determining the placement or operation of the mobile infrastructure, and normally executes a first mode in which the placement or operation of the mobile infrastructure is determined according to the first criterion, and switches to a second mode in which the placement or operation of the mobile infrastructure is determined according to the second criterion in response to the detection of a predetermined trigger.

[0300] (Note 13) A program executed by a computer having one or more computer processors for the integrated management of multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions from one another, the program causing one or more computer processors to: maintain a first criterion and a second criterion different from the first criterion as evaluation criteria for determining the placement or operation of the mobile infrastructure; normally execute a first mode in which the placement or operation of the mobile infrastructure is determined according to the first criterion; and, upon detection of a predetermined trigger, switch to a second mode in which the placement or operation of the mobile infrastructure is determined according to the second criterion.

Claims

1. A system for integrating and managing multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion are maintained. Under normal circumstances, a first mode is executed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. The system includes a control unit that, upon detection of a predetermined trigger, switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, A system comprising: a visualization means that simulates the damage or survival rate when an event corresponding to the trigger occurs in the current deployment of the mobile infrastructure, and outputs the simulation compared with the improvement effect when switching to the second mode when the event occurs.

2. A system for integrating and managing multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion are maintained. Under normal circumstances, a first mode is executed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. A control unit that, upon detecting a predetermined trigger, switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, In the second mode described above, the contribution of the administrator or owner of the mobile infrastructure that provided the infrastructure functions is calculated based on the amount, location, or timing of the resources provided, and a value record (credit) corresponding to that contribution is issued and managed. A system comprising, in the first mode, a transaction management unit that grants the holder of the value record (credit) priority use rights or discounted usage fees for mobile infrastructure managed by others.

3. The system according to claim 1 or 2, wherein the first criterion is determined based on an economic indicator including at least one of the profitability of the operation of the mobile infrastructure, energy efficiency, logistics efficiency, or the rate of fulfillment of user requests.

4. The system according to claim 1 or 2, wherein the second criterion is determined based on a survival or maintenance indicator that includes at least one of the probability of human survival in the target area, the coverage rate of infrastructure supply, the operational maintenance rate of critical facilities, or the time required to restore infrastructure functions.

5. The system according to claim 1 or 2, wherein the trigger includes any of the following: a disaster warning or armed attack warning received from an external system, a supply disruption signal received from the mobile infrastructure or fixed infrastructure, estimated infrastructure damage data obtained by analyzing text data, or ground surface change detection data obtained by remote sensing such as satellite data.

6. The system according to claim 1 or 2, wherein the infrastructure function is at least two distinct functions selected from the group consisting of a power supply function, a communication environment provision function, a water purification or supply function, a material transport function, a computing resource provision function, and a medical care provision function.

7. The system according to claim 1 or 2, wherein, in the second mode, when determining the deployment of mobile infrastructure that provides a specific type of infrastructure function, the control unit generates a plan for the coordinated deployment of mobile infrastructure that provides other types of infrastructure functions, based on a dependency definition that other types of infrastructure functions are essential for maintaining the said infrastructure function.

8. The system according to claim 1 or 2, wherein the mobile infrastructure has a distributed control mode in which, if communication with the control unit is interrupted, or based on a command from the control unit, it communicates directly with other nearby mobile infrastructure and autonomously cooperates to determine its placement or operation in accordance with the second criterion.

9. The system according to claim 2, wherein the conclusion of a resource provision contract and the issuance or settlement of the value record (credit) associated with the switching of the aforementioned mode are automatically performed by a smart contract using distributed ledger technology.

10. A method for a computer having one or more computer processors to centrally manage multiple mobile entities (hereinafter referred to as "mobile infrastructure") that provide different types of infrastructure functions, The above method involves one or more computer processors, As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion are maintained. Under normal circumstances, a first mode is executed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. Upon detection of a predetermined trigger, the system switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, and The system simulates the damage or survival rate when an event corresponding to the trigger occurs in the current deployment of the mobile infrastructure, and outputs the results compared with the improvement effect when switching to the second mode when the event occurs. How to do it.

11. A method for a computer having one or more computer processors to integrate and manage a plurality of mobile entities (hereinafter referred to as mobile infrastructure) that provide different types of infrastructure functions, The above method involves one or more computer processors, As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion are maintained. Under normal circumstances, a first mode is executed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. Upon detection of a predetermined trigger, the system switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, and In the second mode described above, the contribution of the administrator or owner of the mobile infrastructure that provided the infrastructure functions is calculated based on the amount, location, or timing of the resources provided, and a value record (credit) corresponding to that contribution is issued and managed. In the first mode described above, granting the holder of the value record (credit) priority use rights or discounted usage fees for mobile infrastructure managed by others, How to do it.

12. A program executed by a computer having one or more computer processors for the integrated management of a plurality of mobile entities (hereinafter referred to as mobile infrastructure) that provide different types of infrastructure functions, The program is configured on one or more computer processors. As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion shall be maintained. Normally, a first mode is performed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. Upon detection of a predetermined trigger, the system switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, and The system simulates the damage or survival rate when an event corresponding to the trigger occurs in the current deployment of the mobile infrastructure, and outputs the results compared with the improvement effect when switching to the second mode when the event occurs. A program that executes something.

13. A program executed by a computer having one or more computer processors for the integrated management of a plurality of mobile entities (hereinafter referred to as mobile infrastructure) that provide different types of infrastructure functions, The program is configured on one or more computer processors. As evaluation criteria for determining the deployment or operation of the aforementioned mobile infrastructure, a first criterion and a second criterion different from the first criterion shall be maintained. Normally, a first mode is performed in which the placement or operation of the mobile infrastructure is determined according to the first criterion. Upon detection of a predetermined trigger, the system switches to a second mode in which it determines the placement or operation of the mobile infrastructure according to the second criterion, and In the second mode described above, the contribution of the administrator or owner of the mobile infrastructure that provided the infrastructure functions is calculated based on the amount, location, or timing of the resources provided, and a value record (credit) corresponding to that contribution is issued and managed. In the first mode described above, granting the holder of the value record (credit) priority use rights or discounted usage fees for mobile infrastructure managed by others, A program that executes something.

Images