WO2022044217A1 - アラート通知プログラム、装置、及び方法 - Google Patents

アラート通知プログラム、装置、及び方法 Download PDF

Info

Publication number
WO2022044217A1
WO2022044217A1 PCT/JP2020/032440 JP2020032440W WO2022044217A1 WO 2022044217 A1 WO2022044217 A1 WO 2022044217A1 JP 2020032440 W JP2020032440 W JP 2020032440W WO 2022044217 A1 WO2022044217 A1 WO 2022044217A1
Authority
WO
WIPO (PCT)
Prior art keywords
reception
transition
people
people waiting
person
Prior art date
Application number
PCT/JP2020/032440
Other languages
English (en)
French (fr)
Inventor
裕介 大石
文泰 牧野嶋
昇平 山根
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2022545166A priority Critical patent/JPWO2022044217A1/ja
Priority to PCT/JP2020/032440 priority patent/WO2022044217A1/ja
Publication of WO2022044217A1 publication Critical patent/WO2022044217A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B31/00—Predictive alarm systems characterised by extrapolation or other computation using updated historic data

Definitions

  • the disclosed technology relates to an alert notification program, an alert notification device, and an alert notification method.
  • the mobile phone terminal information collection server includes means for storing the position information of each mobile phone terminal based on the information acquired from the mobile phone provider and extracting and providing the position information of a specific mobile phone terminal.
  • the evacuation shelter information providing server stores evacuation shelter registration information including sea level and area information in advance for each evacuation shelter, and acquires disaster information including the height of the tsunami.
  • the shelter information providing server exists in an area determined by using the location information of a specific mobile phone terminal acquired from the mobile phone terminal information collection server as the user location information, and is predetermined with respect to the height of the tsunami. Determine a shelter located above sea level with a sufficient height difference. Then, the evacuation shelter information providing server provides the evacuation shelter information to a specific mobile phone terminal.
  • the disclosure technology aims to notify the receptionist of infection risk alerts.
  • the disclosed technology acquires the first transition of the number of people waiting for reception.
  • the disclosed technology refers to the relationship between the transition of the number of people waiting for reception and the transition of infection risk when at least one of the information about infected persons, the distribution of outbreaks, and the operation system of reception is different. .. Then, based on this relationship, the disclosed technology estimates an index indicating the infection risk according to the first transition of the acquired number of people waiting for reception, and notifies an alert when the estimated index exceeds the threshold value. do.
  • it has the effect of being able to notify an infection risk alert at the reception.
  • the alert notification device 10 functionally includes a creation unit 11, an acquisition unit 13, an estimation unit 14, and a notification unit 15. Further, the scenario DB (Database) 21 is stored in the predetermined storage area of the alert notification device 10.
  • the creation unit 11 creates a scenario for estimating the infection risk of people waiting for reception.
  • the risk of infection varies depending on the magnitude of the infection rate, which is expressed by the number of infected persons with respect to the population. Furthermore, the risk of infection changes in stages according to the congestion status of visitors waiting for reception.
  • the infection risk is an index based on the degree of contact with the infected person.
  • FIG. 2 shows an example of the relationship between congestion and infection risk.
  • each of the circles represents each of the visitors waiting for reception.
  • the black circle indicates the infected person
  • the shaded circle indicates the contact person with the infected person.
  • the definition of the contact person is appropriately set, for example, a person who has existed within a radius of 1 m of the infected person for 10 seconds or more.
  • the possibility of infection is extremely low because the visitors do not come into contact with each other.
  • the infection may spread one-dimensionally to the contacts before and after the infected person.
  • the infection may spread two-dimensionally to the contacts around the infected person.
  • the congestion situation as described above changes depending on the structure around the reception, the operation system of the reception, the timing and how many visitors gather at the reception, and the like.
  • the creating unit 11 analyzes a large number of cases in advance by a human flow simulation in consideration of infection, and scenarios the transition of the number of people waiting for reception in each case and the transition of the infection risk when the number of people waiting for reception occurs.
  • the scenario is an example of the disclosed technology "relationship between each transition of the number of people waiting for reception and each transition of infection risk".
  • Each case corresponds to a case where at least one of the information about the infected person and the distribution of the number of visitors around the reception is different for each operating system.
  • the management system includes factors such as the number of receptions, the arrangement of receptions, and the number of personnel for each reception.
  • Information on infected persons includes the infection rate, the arrangement and timing of infected persons generated around the reception (hereinafter referred to as "initial arrangement of infected persons"), and the like.
  • the attendance occurrence distribution is the arrangement, timing, arrangement, number of occurrences for each timing, etc. that generate visitors around the reception area.
  • the attendance distribution is an example of the "person generation distribution" of the disclosed technology.
  • the creation unit 11 simulates the flow of people around the reception desk for a large number of patterns by making the simulation conditions including the above-mentioned initial placement of infected persons, distribution of outbreaks of visitors, and operating system different from each other. More specifically, in each simulation, the creating unit 11 is an object corresponding to a visitor according to the attendance generation distribution at a position where a visitor can exist based on the structure such as the shape of the road or the building around the reception. (Hereinafter, simply referred to as "visitors") is generated and moved to the reception. In addition, the creation unit 11 sets the number of visitors based on the infection rate, for example, the number of visitors determined by random numbers, as infected persons based on the initial arrangement of infected persons. Further, the preparation unit 11 suspends the visitors who have reached the reception at the reception in consideration of the reception time of each visitor according to the operation system of the reception, and then passes the reception.
  • the creating unit 11 is an object corresponding to a visitor according to the attendance generation distribution at a position where a visitor
  • the infection rate should be set to an appropriate value based on the number of infected people in the area with respect to the population.
  • the infection rate is obtained by multiplying the ratio of the current number of infected persons in X city to the population of X city of the target municipality by a safety factor (for example, 10).
  • the number of infected people is the number obtained by multiplying the total number of visitors generated by the simulation by the infection rate. For example, if the number of infected people in City X is 600, the population of City X is 1.5 million, and the safety factor is 10, the infected person rate is 0.004, and if the number of visitors is 500, the number of infected people is 2. Become a person.
  • other general parameters required for human flow simulation such as the moving speed of a person, may be appropriately set.
  • the creation unit 11 obtains, for example, the transition of the number of people waiting for reception with the passage of time of the simulation, as shown in the upper figure of FIG.
  • the number of people waiting for reception is the number of visitors before passing the reception among the visitors occurring at each time.
  • the creating unit 11 measures for each visitor, for example, the time within a radius of 1 m centered on the infected person as the contact time, and the contact time for each visitor is for all the visitors. The total is stated and calculated as the contact time. Then, the creating unit 11 obtains the transition of the total contact time with the passage of time of the simulation as shown in the lower figure of FIG. As shown in FIG.
  • the creating unit 11 fixes the conditions of the distribution of visitors and the operation system, and sets a plurality of simulation conditions in which the initial arrangement of infected persons is changed as one simulation pattern.
  • the creating unit 11 takes the average of the total contact time calculated for each simulation of each pattern at each time, and obtains the transition of the average of the total contact time for the pattern (solid line in the lower figure of FIG. 3).
  • the creation unit 11 obtains the transition of the total contact time per person from the transition of the number of people waiting for reception and the transition of the average total contact time obtained for each simulation pattern. Specifically, if the number of people waiting for reception at time t is N (t) and the average of the total contact time at time t is T_all (t), the creation unit 11 sets the total contact time per person at time t to T_all ( Obtained as t) / N (t). In this embodiment, this total contact time per person is used as an index indicating the risk of infection.
  • the index indicating the infection risk is not limited to this example, and may be an index based on the degree of contact between each visitor and the infected person.
  • the creation unit 11 sets the transition of the number of people waiting for reception obtained for each simulation pattern and the total contact time per person, that is, the transition of infection risk, as a set, and sets the conditions of the attendance distribution and the operation system. Create for each different simulation pattern.
  • the creation unit 11 stores the created scenario in the scenario DB 21.
  • the scenario DB 21 In the example of FIG. 4, it is shown that three scenarios are created for the conditions of the three different visitor distributions A, B, and C for a certain operation system. Many scenarios are remembered. For example, the infection rate is fixed, the condition for initial placement of infected persons is 100 patterns, the condition for distribution of visitors is 100 patterns, and the condition for operating system is 10 patterns. In this case, the creating unit 11 will execute the simulation 100 times (initial placement of infected persons 100 patterns) for 1000 patterns (visitor distribution 100 patterns ⁇ operating system 10 patterns). Then, in this case, 1000 scenarios are stored in the scenario DB 21.
  • the creation unit 11 extracts a scenario for each operation system regarding a specific attendance distribution from the created scenario and stores it in the scenario DB 21 as support information.
  • three scenarios of operating systems A, B, and C are extracted as support information, but there may be two scenarios for each operating system included in the support information. It may be four or more.
  • scenarios for 10 patterns may be included.
  • the acquisition unit 13 acquires the actual number of people waiting for reception at each time. For example, the acquisition unit 13 acquires a camera image taken by a camera around the reception area, analyzes the camera image, counts the number of visitors reflected in the camera image, and acquires the number of people waiting for reception. As a method of image analysis for counting the number of visitors from a camera image, a conventionally known method can be used, and therefore detailed description thereof will be omitted here.
  • the camera is an example of the "sensing device" of the disclosed technology.
  • the acquisition unit 13 acquires the transition of the number of people waiting for reception in a predetermined period up to the present time by storing the number of people waiting for reception acquired for each hour.
  • the estimation unit 14 estimates the infection risk at one or more time points after the present time with respect to the transition of the number of people waiting for reception acquired by the acquisition unit 13 based on the scenario stored in the scenario DB 21.
  • the estimation unit 14 is a scenario about the current operating system among the scenarios stored in the scenario DB 21, and corresponds to the transition of the acquired number of people waiting for reception.
  • the estimation unit 14 matches the acquired number of people waiting for reception with the change in the number of people waiting for reception included in each scenario by the least squares method or the like. Then, the estimation unit 14 identifies a scenario including a transition of the number of people waiting for reception having a portion that best matches the transition of the number of people waiting for reception that has been acquired.
  • the estimation unit 14 takes a time axis correspondence with the transition of the number of people waiting for reception acquired by matching and the transition of the number of people waiting for reception included in the scenario, and at the present time of the transition of the acquired number of people waiting for reception.
  • the estimation unit 14 is acquired after converting the value above the observation limit value into the observation limit value for each of the transitions of the number of people waiting for reception included in the scenario. Matching should be done with the transition of the number of people waiting for reception.
  • the estimation unit 14 uses the transition of the number of people waiting for reception before the time when the number of people waiting for reception reaches the observation limit value among the changes in the number of people waiting for reception, which are included in the scenario. You may perform matching with.
  • the notification unit 15 notifies an alert when the infection risk estimated by the estimation unit 14 exceeds a predetermined threshold value.
  • the notification unit 15 may notify different alerts depending on which time point the infection risk exceeds the threshold value. .. For example, when the current infection risk T now and the infection risk T + 10 after 10 minutes are estimated, the notification unit 15 notifies a highly urgent alert when T now exceeds the threshold value Tth. do. Further, the notification unit 15 notifies an alert notifying that the infection risk exceeds the threshold value after 10 minutes when T now does not exceed the threshold value Tth but T + 10 exceeds the threshold value Tth.
  • the notification unit 15 notifies the alert to an information processing terminal such as a smartphone, a tablet terminal, or a personal computer held by the receptionist, for example. At this time, the notification unit 15 notifies the support information stored in the scenario DB 21 together with the alert.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG.
  • the support information is a scenario for each operating system regarding a specific attendance distribution as shown in FIG
  • the congestion is further reduced and the risk of infection is reduced.
  • the scenario for each operating system regarding the distribution of specific visitors which is the support information, can quantitatively grasp the degree of infection risk due to the difference in the operating system as described above. Based on this support information, the person in charge of operation determines an appropriate operation system that can be expected to alleviate congestion, for example, in consideration of cost effectiveness. By changing to an appropriate operating system, congestion will be alleviated and the risk of infection will be reduced.
  • the notification unit 15 may notify the alert to an information processing terminal such as a smartphone, a tablet terminal, or a personal computer held by the visitors gathering at the reception. In this case, the notification unit 15 notifies, for example, a message urging the visitor to refrain from visiting because the risk of infection is currently high.
  • the alert notification device 10 can be realized by, for example, the computer 40 shown in FIG.
  • the computer 40 includes a CPU (Central Processing Unit) 41, a memory 42 as a temporary storage area, and a non-volatile storage unit 43. Further, the computer 40 includes an input / output device 44 such as an input unit and a display unit, and an R / W (Read / Write) unit 45 that controls reading and writing of data to the storage medium 49. Further, the computer 40 includes a communication I / F (Interface) 46 connected to a network such as the Internet.
  • the CPU 41, the memory 42, the storage unit 43, the input / output device 44, the R / W unit 45, and the communication I / F 46 are connected to each other via the bus 47.
  • the storage unit 43 can be realized by an HDD (Hard Disk Drive), an SSD (Solid State Drive), a flash memory, or the like.
  • the storage unit 43 as a storage medium stores an alert notification program 50 for causing the computer 40 to function as an alert notification device 10 for executing preparatory processing and operation-time processing, which will be described later.
  • the alert notification program 50 includes a creation process 51, an acquisition process 53, an estimation process 54, and a notification process 55. Further, the storage unit 43 has an information storage area 60 in which the information constituting the scenario DB 21 is stored.
  • the CPU 41 reads the alert notification program 50 from the storage unit 43, expands it into the memory 42, and sequentially executes the processes included in the alert notification program 50.
  • the CPU 41 operates as the creation unit 11 shown in FIG. 1 by executing the creation process 51. Further, the CPU 41 operates as the acquisition unit 13 shown in FIG. 1 by executing the acquisition process 53. Further, the CPU 41 operates as the estimation unit 14 shown in FIG. 1 by executing the estimation process 54. Further, the CPU 41 operates as the notification unit 15 shown in FIG. 1 by executing the notification process 55. Further, the CPU 41 reads information from the information storage area 60 and expands the scenario DB 21 into the memory 42. As a result, the computer 40 that has executed the alert notification program 50 functions as the alert notification device 10.
  • the CPU 41 that executes the program is hardware.
  • the function realized by the alert notification program 50 can also be realized by, for example, a semiconductor integrated circuit, more specifically, an ASIC (Application Specific Integrated Circuit) or the like.
  • a semiconductor integrated circuit more specifically, an ASIC (Application Specific Integrated Circuit) or the like.
  • the alert notification device 10 executes the preparatory process shown in FIG. Then, at the time of actual reception operation, the alert notification device 10 executes the operation-time processing shown in FIG.
  • the preparatory processing and the operation time processing are examples of the alert notification method of the disclosed technology.
  • step S11 the creating unit 11 selects one operating system from the operating systems prepared for a plurality of patterns (for example, 10 patterns) and sets it as a condition for simulation.
  • step S12 the creating unit 11 selects one attendee distribution from the attendee distribution prepared in a plurality of patterns (for example, 1000 patterns) and sets it as a simulation condition.
  • step S13 the creating unit 11 determines the initial placement of the infected person with a random number and sets it as a condition for simulation.
  • step S14 the creating unit 11 simulates the flow of people around the reception area based on the conditions set in the above steps S11 to S13, the infection rate specified in advance, and the structure around the reception area.
  • step S15 the creating unit 11 calculates the transition of the number of people waiting for reception and the stated contact time based on the simulation result.
  • step S16 the creating unit 11 determines whether or not the number of changes in the initial arrangement of the infected person has reached the required number of times (for example, 100 times). If the required number of times has been reached, the process proceeds to step S17, and if not, the process returns to step S13.
  • step S17 the creating unit 11 takes the average of the total contact time calculated for each simulation at each time, and obtains the transition of the average of the total contact time. Further, the creation unit 11 obtains the transition of the total contact time per person as the infection risk from the transition of the number of people waiting for reception calculated in step S15 and the transition of the average total contact time obtained in this step.
  • the creation unit 11 sets a scenario in which the transition of the number of people waiting for reception and the transition of the infection risk are set in the operation system set in step S11 above, and the scenario of the pattern shown by the distribution of visitors set in step S12 above. Is stored in the scenario DB 21.
  • step S18 the creating unit 11 determines whether or not the processing for all the patterns of the attendance distribution is completed. If there is an unprocessed attendee distribution pattern, the process returns to step S12, the creating unit 11 selects the unprocessed attendee distribution, and the process after S12 is repeated. On the other hand, when the processing of all the patterns of the attendance distribution is completed, the processing proceeds to step S19. In step S19, the creating unit 11 determines whether or not the processing for all the patterns of the operating system has been completed. If there is an unprocessed operation system pattern, the process returns to step S11, the creating unit 11 selects the unprocessed operation system, and the process after S11 is repeated.
  • step S20 the processing proceeds to step S20.
  • scenarios for each pattern in which the operating system and the distribution of visitors are different are stored in the scenario DB 21.
  • step S20 the creation unit 11 extracts a scenario for each operating system regarding a specific attendance distribution from the created scenario, and stores it in the scenario DB 21 as support information. Then, the preparatory process is completed.
  • step S21 the acquisition unit 13 acquires a camera image taken by the camera around the reception area, analyzes the camera image, and counts the number of visitors reflected in the camera image, so that the number of people waiting for reception is reached. To get.
  • step S23 the estimation unit 14 estimates the infection risk for the transition of the number of people waiting for reception acquired in step S21 from the transition of the infection risk included in the scenario specified in step S22.
  • the estimation unit 14 estimates the current infection risk T now and the infection risk T + 10 10 minutes after the current time.
  • step S24 the notification unit 15 determines whether or not the infection risk T now estimated in step S23 exceeds the threshold value Tth.
  • T now > Tth the process proceeds to step S25, and the notification unit 15 notifies an urgent alert indicating that the infection risk has already exceeded the threshold value.
  • T now ⁇ Tth the process proceeds to step S26, and the notification unit 15 determines whether or not the infection risk T + 10 estimated in step S23 exceeds the threshold value Tth. If T + 10 > Tth, the process proceeds to step S27, and the notification unit 15 notifies a warning alert for notifying that the infection risk exceeds the threshold after 10 minutes.
  • step S28 the notification unit 15 notifies the support information, which is a scenario for each operating system regarding the specific attendance distribution, stored in the scenario DB 21, and the process returns to step S21.
  • the alert notification device sets the conditions for each of the information about the infected person, the distribution of the occurrence of visitors, and the operation system of the reception, and the area around the reception including the placement of the infected person. Simulate the flow of people. Based on this simulation result, the alert notification device creates a scenario showing the relationship between each transition of the number of people waiting for reception and each transition of the infection risk. Then, the alert notification device acquires the transition of the number of people waiting for reception up to the present time, and identifies the scenario that best matches the transition of the acquired number of people waiting for reception.
  • the alert notification device estimates the infection risk at one or more time points after the present time with respect to the transition of the acquired number of people waiting for reception from the transition of the infection risk included in the specified scenario, and the estimated infection risk exceeds a predetermined threshold value. If so, notify an alert. This makes it possible to notify an infection risk alert at the reception.
  • the alert notification device In addition to the alert notification, the alert notification device also notifies the scenario showing the relationship between the change in the number of receptionists and the change in the infection risk for each operation system as support information for the operation system. Based on this quantitative support information, it is possible to select an appropriate operation system and operate the reception while achieving both the cost of reception operation and the reduction of infection risk.
  • the alert notification device 210 functionally includes a creation unit 11, a machine learning unit 212, an acquisition unit 13, an estimation unit 214, and a notification unit 15. include. Further, the scenario DB 21 and the estimation model 222 are stored in a predetermined storage area of the alert notification device 210.
  • the machine learning unit 212 generates learning data from the scenario stored in the scenario DB 21, and uses the generated learning data to estimate the risk of infection at one or more time points after the present time with respect to the change in the number of people waiting for reception.
  • the estimation model 222 for this is machine-learned.
  • the estimation model is an example of the "model" of the disclosed technology.
  • the machine learning unit 212 extracts each of the parts up to a plurality of time points from the transition of the number of people waiting for reception included in the scenario.
  • FIG. 14 shows an example in which a portion up to time t1, a portion up to time t3, a portion up to time t5, and so on are extracted. Further, the machine learning unit 212 extracts the value of the infection risk at the above-mentioned plurality of time points and the time point after a predetermined time from the plurality of time points in the change of the infection risk corresponding to the change of the number of people waiting for reception.
  • FIG. 14 shows an example in which a portion up to time t1, a portion up to time t3, a portion up to time t5, and so on are extracted. Further, the machine learning unit 212 extracts the value of the infection risk at the above-mentioned plurality of time points and the time point after a predetermined time from the plurality of time points in the change of the infection risk corresponding to the change of the number of people waiting
  • the machine learning unit 212 uses a plurality of sets of the extracted change in the number of people waiting for reception up to a certain point in time and the infection risk value at that time and after that point as learning data for each pattern of the operation system. Generate. Then, the machine learning unit 212 machine-learns the parameters of the estimation model 222 configured by, for example, a neural network or the like, using the learning data for each pattern of the generated operating system.
  • an estimation model 222 for each operating system is constructed, which outputs the estimation result of the infection risk at the present time and at a time point after a predetermined time from the present time by inputting the transition of the number of people waiting for reception.
  • the machine learning unit 212 stores the constructed estimation model 222 in a predetermined storage area.
  • the estimation unit 214 inputs the transition of the number of people waiting for reception acquired by the acquisition unit 13 into the estimation model 222 for the current operating system. As a result, the estimation unit 214 acquires the estimation result of the infection risk at the present time and at a time point after a predetermined time from the present time, which is output from the estimation model 222.
  • the alert notification device 210 can be realized by, for example, the computer 40 shown in FIG.
  • the storage unit 43 of the computer 40 stores an alert notification program 250 for causing the computer 40 to function as an alert notification device 210 that executes preparatory processing, machine learning processing described later, and operation-time processing.
  • the alert notification program 250 has a creation process 51, a machine learning process 252, an acquisition process 53, an estimation process 254, and a notification process 55.
  • the storage unit 43 has an information storage area 260 in which the information constituting each of the scenario DB 21 and the estimation model 222 is stored.
  • the CPU 41 reads the alert notification program 250 from the storage unit 43, expands it to the memory 42, and sequentially executes the process of the alert notification program 250.
  • the CPU 41 operates as the machine learning unit 212 shown in FIG. 13 by executing the machine learning process 252. Further, the CPU 41 operates as the estimation unit 214 shown in FIG. 13 by executing the estimation process 254. Further, the CPU 41 reads information from the information storage area 260 and expands each of the scenario DB 21 and the estimation model 222 into the memory 42. Other processes are the same as those of the alert notification program 50 according to the first embodiment.
  • the computer 40 that has executed the alert notification program 250 functions as the alert notification device 210.
  • the function realized by the alert notification program 250 can also be realized by, for example, a semiconductor integrated circuit, more specifically, an ASIC or the like.
  • the alert notification device 210 executes the preparatory process shown in FIG. 11 as in the first embodiment. Further, in the second embodiment, the alert notification device 210 executes the machine learning process shown in FIG. 16 before the actual operation. Then, at the time of actual reception operation, the alert notification device 210 executes the operation-time processing shown in FIG.
  • the preparatory processing, machine learning processing, and operation time processing are examples of alert notification methods of the disclosed technology.
  • step S31 the machine learning unit 212 selects one operating system from the operating systems prepared for a plurality of patterns (for example, 10 patterns).
  • step S32 the machine learning unit 212 extracts a scenario for the selected operating system from the scenario DB 21.
  • step S33 the machine learning unit 212 extracts a portion from each of the transitions of the number of people waiting for reception included in each of the extracted scenarios to the time point of time ti (ti is a plurality of different times).
  • the machine learning unit 212 has an infection risk at the time of time ti and at a predetermined time (here, time ti + 10 after 10 minutes) in the transition of infection risk corresponding to the transition of the number of people waiting for reception.
  • the values T ti and T ti + 10 of are extracted.
  • the machine learning unit 212 generates a plurality of sets of the portion of the transition of the number of people waiting for reception up to the time ti and the infection risk values T ti and T ti + 10 as learning data.
  • step S34 the machine learning unit 212 machine-learns the parameters of the estimation model 222 using the generated learning data. Then, the machine learning unit 212 stores the estimation model 222 whose parameters are machine-learned in a predetermined storage area in association with the pattern of the operating system selected in step S31.
  • step S35 the machine learning unit 212 determines whether or not the processing for all the patterns of the operating system is completed. If there is an unprocessed operating system pattern, the process returns to step S31, the machine learning unit 212 selects the unprocessed operating system, and repeats the processing after S31. On the other hand, when the processing of all patterns of the operating system is completed, the machine learning processing is completed.
  • step S21 the acquisition unit 13 acquires the number of people waiting for reception.
  • step S222 the estimation unit 214 inputs the transition of the number of people waiting for reception acquired by the acquisition unit 13 into the estimation model 222 for the current operating system. As a result, the estimation unit 214 acquires the infection risk estimation results (T ti and T ti + 10 ) output from the estimation model 222. Then, after that, the processes of steps S24 to S28 are executed in the same manner as in the first embodiment.
  • the alert notification device has learning data from a scenario showing the relationship between each transition of the number of people waiting for reception and each transition of the infection risk created in the same manner as in the first embodiment. And machine-learn the estimation model. Then, the alert notification device acquires the transition of the number of people waiting for reception up to the present time and inputs it into the estimation model to estimate the infection risk at one or more time points after the present time with respect to the transition of the acquired number of people waiting for reception. Then, the alert notification device notifies an alert when the estimated infection risk exceeds a predetermined threshold value. As a result, as in the first embodiment, it is possible to notify an infection risk alert at the reception desk.
  • the present invention is not limited to this.
  • the creating unit calculates the number of contacts waiting for reception and the total contact time, as well as the number of contacts for each contact time with the infected person.
  • FIG. 18 shows an example of calculating the number of contacts who have been in contact with the contact for 10 seconds or more as an example of the number of contacts for each contact time.
  • the preparation unit may use the number of contacts with a contact time as a threshold value at one or more time points after the present time as an index indicating the infection risk.
  • the time is represented by the horizontal axis
  • the contact time is represented by the vertical axis
  • the number of people for each contact time is represented by the concentration. It shows the case where it is used as an index indicating.
  • the present invention is not limited to this.
  • the support information of the operation system can also be used as useful information when deciding the operation system before starting the operation of the reception.
  • the present invention is not limited to this.
  • the disclosed technology can be applied to reception work where people gather, such as supermarket cashiers and entrance to theme parks.
  • the mode in which the alert notification program is stored (installed) in the storage unit in advance has been described, but the present invention is not limited to this.
  • the program according to the disclosed technique can also be provided in a form stored in a storage medium such as a CD-ROM, a DVD-ROM, or a USB memory.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Emergency Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

アラート通知装置は、感染率、感染者の初期配置、入場者発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む受付周辺の人流をシミュレーションした結果に基づいて、受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を示すシナリオを作成する。そして、アラート通知装置は、現時点までの受付待ち人数の推移を取得し、シナリオのうち、取得した受付待ち人数の推移に最もマッチするシナリオを特定し、特定したシナリオに含まれる感染リスクの推移から、取得した受付待ち人数の推移に対する現時点以降の１以上の時点における感染リスクを推定し、推定した感染リスクが予め定めた閾値を超える場合に、アラートを通知する。

Description

アラート通知プログラム、装置、及び方法
　開示の技術は、アラート通知プログラム、アラート通知装置、及びアラート通知方法に関する。
　従来、災害発生時に避難所に関する情報を提供する技術が存在する。例えば、災害発生時に携帯電話端末を所有する利用者に対して避難所情報を提供するシステムが提案されている。このシステムにおいて、携帯電話端末情報収集サーバは、携帯電話プロバイダから取得した情報に基づいた各携帯電話端末の位置情報を記憶し、特定の携帯電話端末の位置情報を抽出し提供する手段を備える。また、避難所情報提供サーバは、各避難所について海抜及びエリアの情報を含む避難所登録情報を予め記憶し、津波の高さを含む災害情報を取得する。また、避難所情報提供サーバは、携帯電話端末情報収集サーバから取得した特定の携帯電話端末の位置情報を利用者位置情報として用いて決定したエリアに存在し、かつ津波の高さに対して所定の十分な高低差のある海抜に位置する避難所を決定する。そして、避難所情報提供サーバは、避難所の情報を特定の携帯電話端末に対して提供する。
特開２０１３－５４５４３号公報
　感染症が発生している状況において、災害避難所の受付では、検温や消毒等の手順が加わることにより、受付に時間を要する。受付に要する時間が長時間化することにより、受付待ちの混雑が誘発され、混雑の中に感染症への感染者が存在する場合に、感染拡大につながるリスクが高まってしまう。従来技術では、災害避難所における感染リスクについては考慮されていない。また、上記のような現象は、災害避難所の受付に限らず、スーパーマーケットのレジ、テーマパークへの入場等、人が集まる施設で受付が必要な状況において、同様に生じ得る。
　一つの側面として、開示の技術は、受付における感染リスクのアラートを通知することを目的とする。
　一つの態様として、開示の技術は、受付待ち人数の第１の推移を取得する。また、開示の技術は、感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を参照する。そして、開示の技術は、この関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、推定した前記指標が閾値を超える場合に、アラートを通知する。
　一つの側面として、受付における感染リスクのアラートを通知することができる、という効果を有する。
第１実施形態に係るアラート通知装置の機能ブロック図である。 混雑状況と感染リスクとの関係の一例を示す図である。 受付待ち人数の推移と感染リスクの推移との関係を示すシナリオの作成を説明するための図である。 受付待ち人数の推移と感染リスクの推移との関係を示すシナリオの作成を説明するための図である。 運営体制の支援情報を説明するための図である。 取得された受付待ち人数の推移に対する感染リスクの推定を説明するための図である。 受付待ち人数の観測限界を説明するための図である。 受付待ち人数が観測限界に達している場合の感染リスクの推定の一例を説明するための図である。 受付の運営体制の変更を説明するための図である。 アラート通知装置として機能するコンピュータの概略構成を示すブロック図である。 事前準備処理の一例を示すフローチャートである。 第１実施形態における運営時処理の一例を示すフローチャートである。 第２実施形態に係るアラート通知装置の機能ブロック図である。 推定モデルの機械学習を説明するための図である。 推定モデルを用いた感染リスクの推定を説明するための図である。 機械学習処理の一例を示すフローチャートである。 第２実施形態における運営時処理の一例を示すフローチャートである。 感染リスクを示す指標の他の例を説明するための図である。
　以下、図面を参照して、開示の技術に係る実施形態の一例を説明する。以下の各実施形態では、感染症が発生している状況で、災害避難所等へ入場する入場者の受付における感染リスクのアラートを通知する場合について説明する。
＜第１実施形態＞
　図１に示すように、第１実施形態に係るアラート通知装置１０は、機能的には、作成部１１と、取得部１３と、推定部１４と、通知部１５とを含む。また、アラート通知装置１０の所定の記憶領域には、シナリオＤＢ（Database）２１が記憶される。
　作成部１１は、受付待ちの人々の感染リスクを推定するためのシナリオを作成する。ここで、感染リスクは、人口に対する感染者の数で表される感染率の大小で変化する。さらに、感染リスクは、受付待ちの入場者の混雑状況に応じて段階的に変化する。なお、本実施形態において、感染リスクは、感染者との接触の度合いに基づく指標である。
　図２に、混雑状況と感染リスクとの関係の一例を示す。図２において、丸印の各々は、受付待ちの入場者の各々を表している。また、黒い丸印が感染者、網掛が付された丸印が感染者との接触者を表している。なお、接触者の定義は、例えば、感染者の半径１ｍ以内に１０秒以上存在した人等、適宜設定する。図２に示すように、混雑が生じていない状態では、入場者同士が接触しないため、感染の可能性は極めて低い。また、受付に並ぶ入場者により列が形成される場合、感染者の前後の接触者に一次元的に感染が拡大する可能性がある。また、受付待ちの入場者が面的に滞留している場合、感染者の周辺の接触者に二次元的に感染が拡大する可能性がある。上記のような混雑状況は、受付周辺の構造、受付の運営体制、受付にどのタイミングでどれだけの入場者が集まるか等に応じて変化する。
　そこで、作成部１１は、感染を考慮した人流シミュレーションにより、多数のケースを事前に解析して、各ケースにおける受付待ち人数の推移と、その受付待ち人数が生じる場合における感染リスクの推移とをシナリオとして作成する。なお、シナリオは、開示の技術の「受付待ち人数の推移の各々と、感染リスクの推移の各々との関係」の一例である。各ケースは、各運営体制について、感染者に関する情報及び受付周辺における入場者発生分布の少なくとも一方がそれぞれ異なる場合に相当する。運営体制は、受付の数、受付の配置、受付毎の要員数等の要因を含む。感染者に関する情報は、感染率、受付周辺に発生させる感染者の配置及びタイミング（以下、「感染者の初期配置」という）等である。入場者発生分布は、受付周辺に入場者を発生させる配置、タイミング、その配置及びタイミング毎の発生人数等である。なお、入場者発生分布は、開示の技術の「人物発生分布」の一例である。
　具体的には、作成部１１は、上記の感染者の初期配置、入場者発生分布、及び運営体制を含むシミュレーション条件をそれぞれ異ならせて、多数のパターンについて、受付周辺の人流をシミュレーションする。より具体的には、作成部１１は、各シミュレーションにおいて、受付周辺の道路や建物の形状等の構造に基づいて、入場者が存在可能な位置に、入場者発生分布に従って入場者に相当するオブジェクト（以下、単に「入場者」という）を発生させ、受付に移動させる。また、作成部１１は、発生させた入場者のうち、感染率に基づく数の入場者であって、例えば乱数によって決定した入場者を、感染者の初期配置に基づいて感染者に設定する。さらに、作成部１１は、受付の運営体制に応じた各入場者の受付時間を考慮して、受付に到達した入場者を受付で一時停止させたうえで、受付を通過させる。
　なお、感染率は、人口に対する地域の感染者数等から、適切な値を設定する。例えば、対象自治体Ｘ市の人口に対する、Ｘ市の現在の感染者数の割合に、安全係数（例えば、１０）を乗算した値を感染率とする。シミュレーションで発生させる入場者の総数に感染率を掛け合わせた数が感染者数となる。例えば、Ｘ市の感染者が６００人、Ｘ市の人口が１５０万人で、安全係数を１０とすると、感染者率は０．００４であり、入場者が５００人とすると、感染者は２人となる。また、人の移動速度等、人流シミュレーションに必要な一般的な他のパラメータは適宜設定すればよい。
　作成部１１は、シミュレーション結果に基づいて、例えば、図３上図に示すような、シミュレーションの時間経過に伴う受付待ち人数の推移を求める。受付待ち人数は、各時間において発生している入場者のうち、受付通過前の入場者の数である。また、作成部１１は、シミュレーション結果に基づいて、入場者毎に、例えば、感染者を中心とした半径１ｍ以内にいる時間を接触時間として計測し、各時間における接触時間の全入場者分の合計を述べ接触時間として計算する。そして、作成部１１は、図３下図に示すような、シミュレーションの時間経過に伴う延べ接触時間の推移を求める。なお、図３に示すように、シミュレーション条件として、入場者分布が固定の場合、感染者の初期配置を変更しても、受付待ち人数の推移はシミュレーション毎に変化しない。一方、感染者の初期配置が異なる場合には、延べ接触時間の推移（図３下図の点線）はシミュレーション毎に変化する。そこで、作成部１１は、入場者分布及び運営体制の条件を固定して、感染者の初期配置を変更した複数のシミュレーション条件を、シミュレーションの１パターンとする。作成部１１は、各パターンのシミュレーション毎に計算した延べ接触時間の各時間における平均をとり、そのパターンについての延べ接触時間の平均の推移（図３下図の実線）を求める。
　作成部１１は、図４に示すように、シミュレーションのパターン毎に求めた受付待ち人数の推移、及び延べ接触時間の平均の推移から、一人当たりの延べ接触時間の推移を求める。具体的には、作成部１１は、時間ｔの受付待ち人数をＮ（ｔ）、時間ｔの延べ接触時間の平均をＴ＿ａｌｌ（ｔ）とすると、時間ｔの一人当たりの延べ接触時間をＴ＿ａｌｌ（ｔ）／Ｎ（ｔ）として求める。本実施形態では、この一人当たりの延べ接触時間を、感染リスクを示す指標として用いる。なお、感染リスクを示す指標は、この例に限定されず、各入場者と感染者との接触の度合いに基づく指標であればよい。
　作成部１１は、シミュレーションのパターン毎に求めた受付待ち人数の推移と、一人当たりの延べ接触時間、すなわち感染リスクの推移とをセットにしたシナリオを、入場者分布及び運営体制の各々の条件を異ならせたシミュレーションのパターン毎に作成する。作成部１１は、作成したシナリオをシナリオＤＢ２１に記憶する。図４の例では、ある運営体制について、入場者分布Ａ、Ｂ、及びＣの３つの異なる入場者分布の条件について、３つのシナリオが作成されることを表しているが、シナリオＤＢ２１にはより多くのシナリオが記憶される。例えば、感染率は固定とし、感染者の初期配置の条件を１００パターン、入場者分布の条件を１００パターン、運営体制の条件を１０パターンとする。この場合、作成部１１は、１０００パターン（入場者分布１００パターン×運営体制１０パターン）について、１００回（感染者の初期配置１００パターン）のシミュレーションを実行することになる。そして、この場合、シナリオＤＢ２１には、１０００個のシナリオが記憶されることになる。
　また、作成部１１は、図５に示すように、作成したシナリオから、特定の入場者分布についての運営体制毎のシナリオを抽出し、支援情報としてシナリオＤＢ２１に記憶する。図５の例では、運営体制Ａ、Ｂ、及びＣについて３つのシナリオを支援情報として抽出した場合を表しているが、支援情報に含める運営体制毎のシナリオは、２つであってもよいし、４つ以上であってもよい。運営体制の条件を１０パターン用意した場合には、１０パターン分のシナリオを含めてもよい。
　取得部１３は、各時間における実際の受付待ち人数を取得する。例えば、取得部１３は、受付周辺をカメラで撮影したカメラ画像を取得し、カメラ画像を画像解析することにより、カメラ画像に映っている入場者の人数をカウントし、受付待ち人数を取得する。カメラ画像から入場者の人数をカウントする画像解析の方法は、従来既知の手法を用いることができるため、ここでは詳細な説明を省略する。なお、カメラは、開示の技術の「センシングデバイス」の一例である。取得部１３は、時間毎に取得した受付待ち人数を記憶しておくことにより、現時点までの所定期間における、受付待ち人数の推移を取得する。
　推定部１４は、シナリオＤＢ２１に記憶されたシナリオに基づいて、取得部１３により取得された受付待ち人数の推移に対する、現時点以降の１以上の時点における感染リスクを推定する。具体的には、推定部１４は、図６に示すように、シナリオＤＢ２１に記憶されたシナリオのうち、現在の運営体制についてのシナリオであって、取得された受付待ち人数の推移に対応するシナリオを特定する。例えば、推定部１４は、取得された受付待ち人数の推移と、各シナリオに含まれる受付待ち人数の推移とで、最小二乗法等によりマッチングを行う。そして、推定部１４は、取得された受付待ち人数の推移と最もマッチする部分を有する受付待ち人数の推移を含むシナリオを特定する。この際、推定部１４は、マッチングにより、取得された受付待ち人数の推移と、シナリオに含まれる受付待ち人数の推移とで時間軸の対応をとり、取得された受付待ち人数の推移の現時点に対応する、シナリオに含まれる受付待ち人数の推移における時間（図６における「ｔ＝ｎｏｗ」）を特定する。
　推定部１４は、特定したシナリオに含まれる感染リスクの推移において、例えば、現時点における感染リスクＴｎｏｗと、現時点から所定時間α後の感染リスクＴ＋αとを、取得された受付待ち人数の推移に対する感染リスクとして推定する。図６の例では、推定部１４は、Ｔｎｏｗと共に、α＝１０分として、現時点から１０分後の感染リスクＴ＋１０を推定している。
　なお、受付周辺の構造及びカメラの撮影範囲によっては、図７の上図に示すように、受付に向かって集まっている入場者が存在する全領域を撮影できない場合がある。すなわち、カメラによって観測可能な入場者の数には限界がある。そのため、図７の下図に示すように、取得部１３に取得される受付待ち人数が、観測限界値に達して、本来の値（図７下図中の破線部分）を示さない場合がある。このような場合、推定部１４は、図８に示すように、シナリオに含まれる受付待ち人数の推移の各々についても、観測限界値以上の値を観測限界値に変換した上で、取得された受付待ち人数の推移とマッチングを行えばよい。又は、推定部１４は、取得した受付待ち人数の推移のうち、受付待ち人数が観測限界値に達した時点以前の受付待ち人数の推移を用いて、シナリオに含まれる受付待ち人数の推移の各々とのマッチングを行ってもよい。
　通知部１５は、推定部１４により推定された感染リスクが予め定めた閾値を超える場合に、アラートを通知する。推定部１４により、現時点以降の複数の時点の感染リスクが推定されている場合、通知部１５は、いずれの時点の感染リスクが閾値を超えているかに応じて、異なるアラートを通知してもよい。例えば、現時点の感染リスクＴｎｏｗと１０分後の感染リスクＴ＋１０とが推定されている場合、通知部１５は、Ｔｎｏｗが閾値Ｔｔｈを超えている場合には、緊急性の高いアラートを通知する。また、通知部１５は、Ｔｎｏｗは閾値Ｔｔｈを超えていないが、Ｔ＋１０が閾値Ｔｔｈを超えている場合には、１０分後には感染リスクが閾値を超えることを予告するアラートを通知する。
　通知部１５は、アラートを、例えば、受付の運営担当者が保持するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末へ通知する。この際、通知部１５は、シナリオＤＢ２１に記憶されている支援情報をアラートと共に通知する。上述したように、支援情報は、図５に示すような、特定の入場者分布についての運営体制毎のシナリオである。例えば、図９上段の図に示すように、受付が１つの場合、その受付に入場者が集中するため、混雑が生じ、感染リスクが高まる。また、図９中段の図に示すように、受付を複数に分けた場合、入場者が分散するため、受付が１つの場合に比べ、混雑が緩和し、感染リスクが低下する。さらに、図９下段の図に示すように、受付前の入場者の待機場所を設け、複数に分けた受付に時間差で誘導する場合、さらに混雑が緩和し、感染リスクが低下する。支援情報である特定の入場者分布についての運営体制毎のシナリオは、上記のような運営体制の違いによる感染リスクの程度を定量的に把握することができる。運営担当者は、この支援情報に基づいて、例えば費用対効果等を考慮し、混雑の緩和が見込める適切な運営体制を決定する。適切な運営体制に変更することにより、混雑が緩和され、感染リスクの低下が図られる。
　また、通知部１５は、アラートを、受付に集まる入場者が保持するスマートフォン、タブレット端末、パーソナルコンピュータ等の情報処理端末へ通知してもよい。この場合、通知部１５は、例えば、現在感染リスクが高いため、来場を控えるように促すメッセージを通知する。
　アラート通知装置１０は、例えば図１０に示すコンピュータ４０で実現することができる。コンピュータ４０は、ＣＰＵ（Central Processing Unit）４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入力部、表示部等の入出力装置４４と、記憶媒体４９に対するデータの読み込み及び書き込みを制御するＲ／Ｗ（Read/Write）部４５とを備える。また、コンピュータ４０は、インターネット等のネットワークに接続される通信Ｉ／Ｆ（Interface）４６を備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。
　記憶部４３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０を、後述する事前準備処理及び運営時処理を実行するアラート通知装置１０として機能させるためのアラート通知プログラム５０が記憶される。アラート通知プログラム５０は、作成プロセス５１と、取得プロセス５３と、推定プロセス５４と、通知プロセス５５とを有する。また、記憶部４３は、シナリオＤＢ２１を構成する情報が記憶される情報記憶領域６０を有する。
　ＣＰＵ４１は、アラート通知プログラム５０を記憶部４３から読み出してメモリ４２に展開し、アラート通知プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、作成プロセス５１を実行することで、図１に示す作成部１１として動作する。また、ＣＰＵ４１は、取得プロセス５３を実行することで、図１に示す取得部１３として動作する。また、ＣＰＵ４１は、推定プロセス５４を実行することで、図１に示す推定部１４として動作する。また、ＣＰＵ４１は、通知プロセス５５を実行することで、図１に示す通知部１５として動作する。また、ＣＰＵ４１は、情報記憶領域６０から情報を読み出して、シナリオＤＢ２１をメモリ４２に展開する。これにより、アラート通知プログラム５０を実行したコンピュータ４０が、アラート通知装置１０として機能することになる。なお、プログラムを実行するＣＰＵ４１はハードウェアである。
　なお、アラート通知プログラム５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。
　次に、第１実施形態に係るアラート通知装置１０の作用について説明する。まず、アラート通知装置１０が、図１１に示す事前準備処理を実行する。そして、実際の受付運営時には、アラート通知装置１０が、図１２に示す運営時処理を実行する。なお、事前準備処理及び運営時処理は、開示の技術のアラート通知方法の一例である。
　まず、図１１を参照して、事前準備処理について説明する。ステップＳ１１で、作成部１１が、複数パターン（例えば、１０パターン）用意された運営体制から、１つの運営体制を選択し、シミュレーションの条件として設定する。次に、ステップＳ１２で、作成部１１が、複数パターン（例えば、１０００パターン）用意された入場者分布から、１つの入場者分布を選択し、シミュレーションの条件として設定する。次に、ステップＳ１３で、作成部１１が、感染者の初期配置を乱数で決定し、シミュレーションの条件として設定する。
　次に、ステップＳ１４で、作成部１１が、上記ステップＳ１１～Ｓ１３で設定された条件と、予め指定された感染率及び受付周辺の構造とに基づいて、受付周辺の人流をシミュレーションする。次に、ステップＳ１５で、作成部１１が、シミュレーション結果に基づいて、受付待ち人数の推移、及び述べ接触時間を計算する。
　次に、ステップＳ１６で、作成部１１が、感染者の初期配置の変更回数が必要回数（例えば、１００回）に到達したか否かを判定する。必要回数に到達している場合には、処理はステップＳ１７へ移行し、到達していない場合には、処理はステップＳ１３に戻る。ステップＳ１７では、作成部１１が、シミュレーション毎に計算した延べ接触時間の各時間における平均をとり、延べ接触時間の平均の推移を求める。また、作成部１１が、上記ステップＳ１５で計算した受付待ち人数の推移と、本ステップで求めた延べ接触時間の平均の推移とから、一人当たりの延べ接触時間の推移を感染リスクとして求める。そして、作成部１１が、受付待ち人数の推移と、感染リスクの推移とをセットにしたシナリオを、上記ステップＳ１１で設定した運営体制、及び上記ステップＳ１２で設定した入場者分布が示すパターンのシナリオをとしてシナリオＤＢ２１に記憶する。
　次に、ステップＳ１８で、作成部１１が、入場者分布の全パターンについて処理が終了したか否かを判定する。未処理の入場者分布のパターンが存在する場合には、処理はステップＳ１２に戻り、作成部１１が未処理の入場者分布を選択して、Ｓ１２以降の処理を繰り返す。一方、入場者分布の全パターンの処理が終了した場合、処理はステップＳ１９へ移行する。ステップＳ１９では、作成部１１が、運営体制の全パターンについて処理が終了したか否かを判定する。未処理の運営体制のパターンが存在する場合には、処理はステップＳ１１に戻り、作成部１１が未処理の運営体制を選択して、Ｓ１１以降の処理を繰り返す。一方、運営体制の全パターンの処理が終了した場合、処理はステップＳ２０へ移行する。この段階で、運営体制及び入場者分布の各々が異なるパターン毎のシナリオがシナリオＤＢ２１に記憶されている。次に、ステップＳ２０で、作成部１１が、作成したシナリオから、特定の入場者分布についての運営体制毎のシナリオを抽出し、支援情報としてシナリオＤＢ２１に記憶する。そして、事前準備処理は終了する。
　次に、図１２を参照して、運営時処理について説明する。ステップＳ２１で、取得部１３が、受付周辺をカメラで撮影したカメラ画像を取得し、カメラ画像を画像解析することにより、カメラ画像に映っている入場者の人数をカウントすることにより、受付待ち人数を取得する。
　次に、ステップＳ２２で、推定部１４が、シナリオＤＢ２１に記憶されたシナリオのうち、現在の運営体制についてのシナリオを抽出する。そして、推定部１４が、抽出したシナリオの中から、取得された現時点（ｔ＝ｎｏｗ）までの受付待ち人数の推移と最もマッチする部分を有する受付待ち人数の推移を含むシナリオを特定する。次に、ステップＳ２３で、推定部１４が、上記ステップＳ２２で特定したシナリオに含まれる感染リスクの推移から、上記ステップＳ２１で取得された受付待ち人数の推移に対する感染リスクを推定する。ここでは、推定部１４は、現時点の感染リスクＴｎｏｗと、現時点から１０分後の感染リスクＴ＋１０とを推定するものとする。
　次に、ステップＳ２４で、通知部１５が、上記ステップＳ２３で推定された感染リスクＴｎｏｗが閾値Ｔｔｈを超えているか否かを判定する。Ｔｎｏｗ＞Ｔｔｈの場合、処理はステップＳ２５へ移行し、通知部１５が、感染リスクが既に閾値を超えていることを示す緊急アラートを通知する。一方、Ｔｎｏｗ≦Ｔｔｈの場合、処理はステップＳ２６へ移行し、通知部１５が、上記ステップＳ２３で推定された感染リスクＴ＋１０が閾値Ｔｔｈを超えているか否かを判定する。Ｔ＋１０＞Ｔｔｈの場合、処理はステップＳ２７へ移行し、通知部１５が、１０分後には感染リスクが閾値を超えることを予告する予告アラートを通知する。一方、Ｔ＋１０≦Ｔｔｈの場合、アラートは通知されることなく、処理はステップＳ２１に戻る。次に、ステップＳ２８で、通知部１５が、シナリオＤＢ２１に記憶されている、特定の入場者分布についての運営体制毎のシナリオである支援情報を通知し、処理はステップＳ２１に戻る。
　以上説明したように、第１実施形態に係るアラート通知装置は、感染者に関する情報、入場者発生分布、及び受付の運営体制の各々の条件を設定して、感染者の配置を含む受付周辺の人流をシミュレーションする。アラート通知装置は、このシミュレーション結果に基づいて、受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を示すシナリオを作成する。そして、アラート通知装置は、現時点までの受付待ち人数の推移を取得し、シナリオのうち、取得した受付待ち人数の推移に最もマッチするシナリオを特定する。アラート通知装置は、特定したシナリオに含まれる感染リスクの推移から、取得した受付待ち人数の推移に対する現時点以降の１以上の時点における感染リスクを推定し、推定した感染リスクが予め定めた閾値を超える場合に、アラートを通知する。これにより、受付における感染リスクのアラートを通知することができる。
　また、アラート通知装置は、アラートの通知と共に、運営体制毎の、受付人数の推移と感染リスクの推移との関係を示すシナリオを、運営体制の支援情報として通知する。この定量的な支援情報を根拠として、適切な運営体制を選択し、受付運営のコストと、感染リスク低減とを両立した受付運営が可能となる。
＜第２実施形態＞
　次に、第２実施形態について説明する。なお、第２実施形態に係るアラート通知装置において、第１実施形態に係るアラート通知装置１０と同様の構成については、同一符号を付して詳細な説明を省略する。
　図１３に示すように、第２実施形態に係るアラート通知装置２１０は、機能的には、作成部１１と、機械学習部２１２と、取得部１３と、推定部２１４と、通知部１５とを含む。また、アラート通知装置２１０の所定の記憶領域には、シナリオＤＢ２１と、推定モデル２２２とが記憶される。
　機械学習部２１２は、シナリオＤＢ２１に記憶されたシナリオから学習データを生成し、生成した学習データを用いて、取得された受付待ち人数の推移に対する、現時点以降の１以上の時点における感染リスクを推定するための推定モデル２２２を機械学習する。なお、推定モデルは、開示の技術の「モデル」の一例である。
　具体的には、図１４に示すように、機械学習部２１２は、シナリオに含まれる受付待ち人数の推移から、複数の時点までの部分の各々を抽出する。図１４では、時間ｔ１までの部分、時間ｔ３までの部分、時間ｔ５までの部分、・・・が抽出された例を示している。また、機械学習部２１２は、受付待ち人数の推移に対応する感染リスクの推移における、上記の複数の時点及び複数の時点から所定時間後の時点における感染リスクの値を抽出する。図１４では、時間ｔ１、ｔ３、ｔ５、・・・と、それぞれの１０分後の時間ｔ２、ｔ４、ｔ６、・・・の感染リスクＴｔ１、Ｔｔ２、Ｔｔ３、Ｔｔ４、Ｔｔ５、Ｔｔ６、・・・が抽出された例を示している。機械学習部２１２は、運営体制のパターン毎に、抽出したある時点までの受付待ち人数の推移の部分と、その時点及びその時点以降の時点における感染リスクの値との複数の組を学習データとして生成する。そして、機械学習部２１２は、生成した運営体制のパターン毎の学習データを用いて、例えばニューラルネットワーク等で構成された推定モデル２２２のパラメータを機械学習する。これにより、受付待ち人数の推移を入力することにより、現時点及び現時点から所定時間後の時点における感染リスクの推定結果を出力する、運営体制毎の推定モデル２２２が構築される。機械学習部２１２は、構築した推定モデル２２２を所定の記憶領域に記憶する。
　推定部２１４は、図１５に示すように、取得部１３により取得された受付待ち人数の推移を、現在の運営体制についての推定モデル２２２に入力する。これにより、推定部２１４は、推定モデル２２２から出力される、現時点及び現時点から所定時間後の時点における感染リスクの推定結果を取得する。図１５では、現時点（ｔ＝ｎｏｗ）までの受付待ち人数の推移から、現時点における感染リスクＴｎｏｗ、及び現時点から１０分後の時点における感染リスクＴ＋１０の推定結果が取得される例を示している。
　アラート通知装置２１０は、例えば図１０に示すコンピュータ４０で実現することができる。コンピュータ４０の記憶部４３には、コンピュータ４０を、事前準備処理、後述する機械学習処理、及び運営時処理を実行するアラート通知装置２１０として機能させるためのアラート通知プログラム２５０が記憶される。アラート通知プログラム２５０は、作成プロセス５１と、機械学習プロセス２５２と、取得プロセス５３と、推定プロセス２５４と、通知プロセス５５とを有する。また、記憶部４３は、シナリオＤＢ２１及び推定モデル２２２の各々を構成する情報が記憶される情報記憶領域２６０を有する。
　ＣＰＵ４１は、アラート通知プログラム２５０を記憶部４３から読み出してメモリ４２に展開し、アラート通知プログラム２５０が有するプロセスを順次実行する。ＣＰＵ４１は、機械学習プロセス２５２を実行することで、図１３に示す機械学習部２１２として動作する。また、ＣＰＵ４１は、推定プロセス２５４を実行することで、図１３に示す推定部２１４として動作する。また、ＣＰＵ４１は、情報記憶領域２６０から情報を読み出して、シナリオＤＢ２１及び推定モデル２２２の各々をメモリ４２に展開する。他のプロセスについては、第１実施形態に係るアラート通知プログラム５０と同様である。これにより、アラート通知プログラム２５０を実行したコンピュータ４０が、アラート通知装置２１０として機能することになる。なお、アラート通知プログラム２５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
　次に、第２実施形態に係るアラート通知装置２１０の作用について説明する。まず、アラート通知装置２１０が、第１実施形態と同様に、図１１に示す事前準備処理を実行する。さらに、第２実施形態では、実際の運営の前に、アラート通知装置２１０が、図１６に示す機械学習処理を実行する。そして、実際の受付運営時には、アラート通知装置２１０が、図１７に示す運営時処理を実行する。なお、事前準備処理、機械学習処理、及び運営時処理は、開示の技術のアラート通知方法の一例である。
　まず、図１６を参照して、機械学習処理について説明する。ステップＳ３１で、機械学習部２１２が、複数パターン（例えば、１０パターン）用意された運営体制から、１つの運営体制を選択する。次に、ステップＳ３２で、機械学習部２１２が、シナリオＤＢ２１から、選択した運営体制についてのシナリオを抽出する。
　次に、ステップＳ３３で、機械学習部２１２が、抽出したシナリオの各々に含まれる受付待ち人数の推移の各々から、時間ｔｉ（ｔｉは複数の異なる時間）の時点までの部分を抽出する。また、機械学習部２１２が、受付待ち人数の推移に対応する感染リスクの推移における、時間ｔｉの時点及び時間ｔｉから所定時間後（ここでは１０分後の時間ｔｉ＋１０とする）の時点における感染リスクの値Ｔｔｉ及びＴｔｉ＋１０を抽出する。そして、機械学習部２１２が、時間ｔｉの時点までの受付待ち人数の推移の部分と、感染リスクの値Ｔｔｉ及びＴｔｉ＋１０との複数の組を学習データとして生成する。
　次に、ステップＳ３４で、機械学習部２１２が、生成した学習データを用いて推定モデル２２２のパラメータを機械学習する。そして、機械学習部２１２が、パラメータが機械学習された推定モデル２２２を、上記ステップＳ３１で選択した運営体制のパターンと対応付けて所定の記憶領域に記憶する。次に、ステップＳ３５で、機械学習部２１２が、運営体制の全パターンについて処理が終了したか否かを判定する。未処理の運営体制のパターンが存在する場合には、処理はステップＳ３１に戻り、機械学習部２１２が未処理の運営体制を選択して、Ｓ３１以降の処理を繰り返す。一方、運営体制の全パターンの処理が終了した場合、機械学習処理は終了する。
　次に、図１７を参照して、第２実施形態における運営時処理について説明する。なお、第２実施形態における運営時処理について、第１実施形態における運営時処理と同様の処理については、同一のステップ番号を付して詳細な説明を省略する。
　ステップＳ２１で、取得部１３が、受付待ち人数を取得する。次に、ステップＳ２２２で、推定部２１４が、取得部１３により取得された受付待ち人数の推移を、現在の運営体制についての推定モデル２２２に入力する。これにより、推定部２１４が、推定モデル２２２から出力される感染リスクの推定結果（Ｔｔｉ及びＴｔｉ＋１０）を取得する。そして、以降、第１実施形態と同様に、ステップＳ２４～Ｓ２８の処理が実行される。
　以上説明したように、第２実施形態に係るアラート通知装置は、第１実施形態と同様に作成した受付待ち人数の推移の各々と、感染リスクの推移の各々との関係を示すシナリオから学習データを生成し、推定モデルを機械学習する。そして、アラート通知装置は、現時点までの受付待ち人数の推移を取得し、推定モデルに入力することにより、取得した受付待ち人数の推移に対する現時点以降の１以上の時点における感染リスクを推定する。そして、アラート通知装置は、推定した感染リスクが予め定めた閾値を超える場合に、アラートを通知する。これにより、第１実施形態と同様に、受付における感染リスクのアラートを通知することができる。
　なお、上記各実施形態では、感染リスクを示す指標として、一人当たりの延べ接触時間を用いる場合について説明したが、これに限定されない。例えば、図１８に示すように、作成部は、シミュレーション結果から、受付待ちの人数及び延べ接触時間と共に、感染者との接触時間毎の接触者数を計算する。図１８では、接触時間毎の接触者数の一例として、接触者と１０秒以上接触している接触者数を計算した例を示している。そして、作成部は、現時点以降の１以上の時点における、閾値となる接触時間の接触者数を、感染リスクを示す指標としてもよい。この感染リスクを示す指標を用いることにより、一定時間以上感染者との接触がある接触者の数の増加による感染リスクの拡大を予測することができる。なお、図１８の例では、時間を横軸、接触時間を縦軸、接触時間毎の人数を濃度で表しており、現時点及び１０分後の時点における、１００時間以上の接触者数を感染リスクを示す指標とする場合を示している。
　また、上記各実施形態では、運営体制の支援情報を、アラートの通知と共に通知する場合について説明したが、これに限定されない。運営体制の支援情報は、受付の運営を開始する前における運営体制の決定時にも有用な情報として利用することができる。
　また、上記各実施形態では、開示の技術を、災害避難所の受付の運営に適用した場合について説明したが、これに限定されない。開示の技術は、スーパーマーケットのレジ、テーマパークへの入場等、人が集まる受付業務に対して適用可能である。
　また、上記各実施形態では、アラート通知プログラムが記憶部に予め記憶（インストール）されている態様を説明したが、これに限定されない。開示の技術に係るプログラムは、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリ等の記憶媒体に記憶された形態で提供することも可能である。
１０、２１０  アラート通知装置
１１   作成部
２１２ 機械学習部
１３   取得部
１４、２１４  推定部
１５   通知部
２１   シナリオＤＢ
２２２ 推定モデル
４０   コンピュータ
４１   ＣＰＵ
４２   メモリ
４３   記憶部
４９   記憶媒体
５０、２５０  アラート通知プログラム

Claims (20)

  1. 　受付待ち人数の第１の推移を取得し、
    　感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
    　推定した前記指標が閾値を超える場合に、アラートを通知する、
    　ことを含む処理をコンピュータに実行させることを特徴とするアラート通知プログラム。
  2. 　前記推定する処理は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移毎の前記関係のうち、前記受付待ち人数の第１の推移に対応する特定の関係を特定する処理を含む、
    　ことを特徴とする請求項１に記載のアラート通知プログラム。
  3. 　前記推定する処理は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいた機械学習により生成したモデルを用いて、前記受付待ち人数の第１の推移に対する現時点以降の１以上の時点における感染リスクを示す指標を推定する処理を含む、
    　ことを特徴とする請求項１に記載のアラート通知プログラム。
  4. 　前記感染者に関する情報の条件は、感染率と、前記受付周辺に発生させる感染者の初期配置とを含み、
    　前記人物発生分布の条件は、前記受付周辺に人物を発生させる配置と、タイミングと、前記配置及び前記タイミング毎の発生人数とを含み、
    　前記受付の運営体制の条件は、受付の数、受付の配置、及び受付毎の要員数の少なくとも１つを含み、
    　前記推定する処理は、前記人物発生分布の条件、及び前記受付の運営体制の条件の各々を異ならせたパターン毎に、前記感染率を設定し、かつ前記感染者の初期配置の条件を異ならせて前記受付周辺の人流をシミュレーションして得られる前記感染リスクの推移の各々の平均に基づいて、前記パターン毎の前記関係を特定する処理を含む、
    　ことを特徴とする請求項２又は請求項３に記載のアラート通知プログラム。
  5. 　前記パターン毎に特定した前記関係のうち、特定の前記人物発生分布の条件についての前記受付の運営体制毎のパターンについて特定された前記関係を通知する、
    　ことを含む処理を前記コンピュータに実行させることを特徴とする請求項４に記載のアラート通知プログラム。
  6. 　前記受付待ち人数の推移を取得する処理は、センシングデバイスが検知した前記受付待ち人数を取得する処理を含み、
    　前記推定する処理は、検出された前記受付待ち人数が、前記センシングデバイスの観測限界値に到達している場合、前記関係における前記受付待ち人数の推移の各々の上限を前記観測限界値に変換するか、又は、取得した前記受付待ち人数の第１の推移のうち、前記受付待ち人数が前記観測限界値に到達した時点以前の前記受付待ち人数の推移を用いて、前記感染リスクを示す指標を推定する、
    　ことを特徴とする請求項１～請求項５のいずれか１項に記載のアラート通知プログラム。
  7. 　前記感染リスクを示す指標は、感染者との接触の度合いに基づく指標である、
    　ことを特徴とする請求項１～請求項６のいずれか１項に記載のアラート通知プログラム。
  8. 　受付待ち人数の第１の推移を取得し、
    　感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
    　推定した前記指標が閾値を超える場合に、アラートを通知する、
    　ことを含む処理を実行する制御部を含むことを特徴とするアラート通知装置。
  9. 　前記制御部は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移毎の前記関係のうち、前記受付待ち人数の第１の推移に対応する特定の関係を特定する処理を含む、
    　ことを特徴とする請求項８に記載のアラート通知装置。
  10. 　前記制御部は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいた機械学習により生成したモデルを用いて、前記受付待ち人数の第１の推移に対する現時点以降の１以上の時点における感染リスクを示す指標を推定する、
    　ことを特徴とする請求項８に記載のアラート通知装置。
  11. 　前記感染者に関する情報の条件は、感染率と、前記受付周辺に発生させる感染者の初期配置とを含み、
    　前記人物発生分布の条件は、前記受付周辺に人物を発生させる配置と、タイミングと、前記配置及び前記タイミング毎の発生人数とを含み、
    　前記受付の運営体制の条件は、受付の数、受付の配置、及び受付毎の要員数の少なくとも１つを含み、
    　前記制御部は、前記人物発生分布の条件、及び前記受付の運営体制の条件の各々を異ならせたパターン毎に、前記感染率を設定し、かつ前記感染者の初期配置の条件を異ならせて前記受付周辺の人流をシミュレーションして得られる前記感染リスクの推移の各々の平均に基づいて、前記パターン毎の前記関係を特定する、
    　ことを特徴とする請求項９又は請求項１０に記載のアラート通知装置。
  12. 　前記制御部は、前記パターン毎に特定した前記関係のうち、特定の前記人物発生分布の条件についての前記受付の運営体制毎のパターンについて特定された前記関係を通知する、
    　ことを特徴とする請求項１１に記載のアラート通知装置。
  13. 　前記制御部は、
    　前記受付待ち人数の推移を取得する処理として、センシングデバイスが検知した前記受付待ち人数を取得することを含む処理を実行し、
    　検出した前記受付待ち人数が、前記センシングデバイスの観測限界値に到達している場合、前記関係における前記受付待ち人数の推移の各々の上限を前記観測限界値に変換するか、又は、取得した前記受付待ち人数の第１の推移のうち、前記受付待ち人数が前記観測限界値に到達した時点以前の前記受付待ち人数の推移を用いて、前記感染リスクを示す指標を推定する、
    　ことを特徴とする請求項８～請求項１２のいずれか１項に記載のアラート通知装置。
  14. 　前記感染リスクを示す指標は、感染者との接触の度合いに基づく指標である、
    　ことを特徴とする請求項８～請求項１３のいずれか１項に記載のアラート通知装置。
  15. 　受付待ち人数の第１の推移を取得し、
    　感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
    　推定した前記指標が閾値を超える場合に、アラートを通知する、
    　ことを含む処理をコンピュータが実行することを特徴とするアラート通知方法。
  16. 　前記推定する処理は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移毎の前記関係のうち、前記受付待ち人数の第１の推移に対応する特定の関係を特定する処理を含む、
    　ことを特徴とする請求項１５に記載のアラート通知方法。
  17. 　前記推定する処理は、前記感染者に関する情報、前記人物発生分布、及び前記受付の運営体制の各々の条件を設定して、感染者の配置を含む前記受付周辺の人流をシミュレーションすることにより特定された受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいた機械学習により生成したモデルを用いて、前記受付待ち人数の第１の推移に対する現時点以降の１以上の時点における感染リスクを示す指標を推定する処理を含む、
    　ことを特徴とする請求項１５に記載のアラート通知方法。
  18. 　前記感染者に関する情報の条件は、感染率と、前記受付周辺に発生させる感染者の初期配置とを含み、
    　前記人物発生分布の条件は、前記受付周辺に人物を発生させる配置と、タイミングと、前記配置及び前記タイミング毎の発生人数とを含み、
    　前記受付の運営体制の条件は、受付の数、受付の配置、及び受付毎の要員数の少なくとも１つを含み、
    　前記推定する処理は、前記人物発生分布の条件、及び前記受付の運営体制の条件の各々を異ならせたパターン毎に、前記感染率を設定し、かつ前記感染者の初期配置の条件を異ならせて前記受付周辺の人流をシミュレーションして得られる前記感染リスクの推移の各々の平均に基づいて、前記パターン毎の前記関係を特定する処理を含む、
    　ことを特徴とする請求項１６又は請求項１７に記載のアラート通知方法。
  19. 　前記パターン毎に特定した前記関係のうち、特定の前記人物発生分布の条件についての前記受付の運営体制毎のパターンについて特定された前記関係を通知する、
    　ことを含む処理を前記コンピュータが実行することを特徴とする請求項１８に記載のアラート通知方法。
  20. 　受付待ち人数の第１の推移を取得し、
    　感染者に関する情報、人物発生分布、及び受付の運営体制の少なくとも１つがそれぞれ異なる場合の受付待ち人数の推移の各々と、感染リスクの推移の各々との関係に基づいて、取得した前記受付待ち人数の第１の推移に応じた感染リスクを示す指標を推定し、
    　推定した前記指標が閾値を超える場合に、アラートを通知する、
    　ことを含む処理をコンピュータに実行させることを特徴とするアラート通知プログラムを記憶した記憶媒体。
PCT/JP2020/032440 2020-08-27 2020-08-27 アラート通知プログラム、装置、及び方法 WO2022044217A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022545166A JPWO2022044217A1 (ja) 2020-08-27 2020-08-27
PCT/JP2020/032440 WO2022044217A1 (ja) 2020-08-27 2020-08-27 アラート通知プログラム、装置、及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2020/032440 WO2022044217A1 (ja) 2020-08-27 2020-08-27 アラート通知プログラム、装置、及び方法

Publications (1)

Publication Number Publication Date
WO2022044217A1 true WO2022044217A1 (ja) 2022-03-03

Family

ID=80354911

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/032440 WO2022044217A1 (ja) 2020-08-27 2020-08-27 アラート通知プログラム、装置、及び方法

Country Status (2)

Country Link
JP (1) JPWO2022044217A1 (ja)
WO (1) WO2022044217A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014186447A (ja) * 2013-03-22 2014-10-02 Nec Corp 感染危険エリア特定システム、感染危険エリア特定方法、及びプログラム
US20170352119A1 (en) * 2016-06-03 2017-12-07 Blyncsy, Inc. Tracking proximity relationships and uses thereof
WO2020012886A1 (ja) * 2018-07-13 2020-01-16 パナソニックＩｐマネジメント株式会社 感染リスク評価方法、感染リスク評価システム、及び感染リスク評価プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014186447A (ja) * 2013-03-22 2014-10-02 Nec Corp 感染危険エリア特定システム、感染危険エリア特定方法、及びプログラム
US20170352119A1 (en) * 2016-06-03 2017-12-07 Blyncsy, Inc. Tracking proximity relationships and uses thereof
WO2020012886A1 (ja) * 2018-07-13 2020-01-16 パナソニックＩｐマネジメント株式会社 感染リスク評価方法、感染リスク評価システム、及び感染リスク評価プログラム

Also Published As

Publication number Publication date
JPWO2022044217A1 (ja) 2022-03-03

Similar Documents

Publication Publication Date Title
CN109858461B (zh) 一种密集人群计数的方法、装置、设备以及存储介质
JP4658788B2 (ja) 画像処理装置、画像処理方法およびプログラム
CN110009364B (zh) 一种行业识别模型确定方法和装置
CN109214337B (zh) 一种人群统计方法、装置、设备及计算机可读存储介质
CN108256404B (zh) 行人检测方法和装置
US20100027875A1 (en) Automated learning for people counting systems
JP6489170B2 (ja) 解析装置、解析方法及びプログラム
CN110084155B (zh) 一种密集人数计数的方法、装置、设备以及存储介质
CN111767888A (zh) 对象状态检测方法、计算机设备、存储介质和电子设备
CN112750030B (zh) 风险模式识别方法、装置、设备及计算机可读存储介质
CN114388137A (zh) 城市流感发病趋势预测方法、系统、终端以及存储介质
CN110807117B (zh) 一种用户关系预测方法及装置、计算机可读存储介质
CN110519324B (zh) 一种基于网络轨迹大数据的人物追踪方法与系统
CN110990455A (zh) 大数据识别房屋性质的方法与系统
WO2022044217A1 (ja) アラート通知プログラム、装置、及び方法
CN111310647A (zh) 自动识别跌倒模型的生成方法和装置
CN113128012A (zh) 灾害保障资源计算方法、装置、计算机装置及存储介质
CN110390226B (zh) 人群事件识别方法、装置、电子设备及系统
CN116761185A (zh) 一种基于信令预测日活跃用户的方法、系统及介质
Sari et al. Victim Localization Using Modular IoT Platform for Disaster Management
JP7251630B2 (ja) 学習装置、推論装置、学習方法、推論方法、及び学習プログラム
CN112669352A (zh) 一种对象识别方法、装置及设备
CN113743293A (zh) 跌倒行为检测方法、装置、电子设备及存储介质
CN116958149B (zh) 医疗模型训练方法、医疗数据分析方法、装置及相关设备
CN109961202B (zh) 一种信息处理方法及其装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20951470

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022545166

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20951470

Country of ref document: EP

Kind code of ref document: A1