JP2008134715A - 情報処理システムおよび情報処理方法 - Google Patents

Abstract

【課題】管理対象者の行動、および連携した関係者の活動を一括して管理することのできる情報処理システムを提供する。
【解決手段】受信した管理対象者の個人情報を、当該管理対象者を一意に識別する識別情報と対応させて個人情報データベース２１０に記憶する入会処理部１１０と、管理対象者が参加するか否かの情報を受信して、参加登録データベース２５０に登録する参加登録処理部１３０と、管理対象者が携帯し、当該管理対象者を一意に識別する識別情報を記憶するタグ４００から識別情報を読取るタグ読取り処理部３０１と、読取った前記識別情報を、当該管理対象者の出席情報として参加登録データベース２５０に登録する出欠処理部１４０と、帰宅する管理対象者の最適ルートを検索して、地域の防犯のためにパトロールを行うパトロール員、および当該管理対象者に前記検索したルートを通知する帰宅ルート検索部１５３を備える。
【選択図】図３

Description

本発明は、情報処理システムおよび情報処理方法に関する。

昨今の事件の多発を背景として、地域社会から行政に対して早急かつ効果的な対応が求められている。特に事件による児童の被害は増加傾向にあり、学校内や登下校時の安全確保は、極めて重大な課題となっている。そのため、保護者、学校、自治体、警察など、地域ぐるみで連携した防犯対策の必要性が高まっている。

２００６年５月に文部科学省および厚生労働省から、全児童が放課後を安全に過ごせる居場所づくりの推進として「放課後子どもプラン」が発表されている。それに伴い、２００７年度以降から、学童保育と地域子ども教室との一体化およびそれらの連携によって、全国約２３，０００の小学校区において、放課後の児童の居場所をつくる施策が開始される。

これらの状況を踏まえ、現在、ＩＣ（Integrated Circuit）タグなどのＩＴ（Information Technology）技術を活用した児童の出欠管理や、児童の登下校情報を保護者へメールするサービス、ボランティアの運用サービスなどが広がりつつある。
特許文献１は、ボランティアサービスなどの一つのサービス依頼に対して、依頼者の条件とサービス提供者の条件とをコーディネータがマッチングさせて、適切な一人のサービス提供者を紹介する技術が開示されている。
また、特許文献２は、ＷＷＷ（World Wide Web）ブラウザを利用し、一つのサービスを複数のサービス提供者（グループ）に依頼する技術が開示されている。
特開２００２−２０３１３２号公報 特開２００５−２５８９８４号公報

しかしながら、児童が放課後に過ごす場所や、その居場所において開催されるイベントで児童を指導する指導者の活動スケジュール、児童の帰宅時刻、児童の帰宅ルートなどは、学校の担任教師やコーディネータなどの手作業によって、それぞれが別々に管理されていた。そのため、非効率な作業が多く、また、連絡ミスなどにより不要な作業が発生することもあった。

特許文献１では、複数のサービス依頼に対する複数の提供者を一度にマッチングする手段はないため、複数のイベントをまとめて企画して、それにマッチングする複数の提供者を決める必要がある場合には、マッチング作業が煩雑になるという課題がある。
特許文献２では、複数のサービス依頼を同時に処理する手段はない。また、グループ内メンバの資格などの付加要件を考慮して様々なサービス（イベント）への人員配置を一括して設定する手段もない。

つまり、前記した技術はいずれも、児童の放課後の行動や、それに伴う地域社会の住民の連携活動を一括して管理できるものではなかった。

そこで、本発明は、管理対象者の行動や、関係者の活動を一括して管理することで、事務処理の負担を軽減し、管理対象者の安全を確保することのできる情報処理システムを提供することを目的とする。

前記課題を解決するためになされた本発明に係る情報管理システムは、受信した個人情報を記憶させる入会処理部と、サービスに参加するか否かの情報を登録する参加登録処理部と、前記管理対象者が携帯する記憶媒体から取得した識別情報を当該管理対象者の出席情報として登録する出欠処理部と、帰宅する前記管理対象者の帰宅のための最適ルートを検索して、当該管理対象者、および地域の防犯のためにパトロールを行うパトロール員に前記検索したルートを通知する帰宅ルート検索部とを備えることを特徴とする。
なお、本発明のその他の態様については、後記する実施の形態において説明する。

本発明に係る情報処理システムおよび情報処理方法によれば、管理対象者の行動や、関係者の活動を一括して管理することで、事務処理の負担を軽減し、管理対象者の安全を確保することができる。

以下、本発明を実施するための最良の形態（以下「実施形態」とする）について図面を参照しながら説明する。なお、同じ要素には同じ符号を付し、重複する説明を省略する。

本実施形態では、管理対象者としての児童が、放課後や春・夏・冬休みなどに、学童保育、放課後子ども教室、地域子ども教室などで「児童見守りサービス（以下、単に「サービス」と適宜記載）」を受ける場合を例として説明する。児童見守りサービスを行う施設（以下、「施設」と適宜記載）では、勉強会、野球などのイベントが開催され、児童は希望に応じてそのイベントに参加することができる。児童が施設から帰宅する際には、自宅から保護者などが迎えに来る場合と、帰宅時刻の同じ児童が帰宅ルート毎に集団で帰宅する場合とがある。

まず、図１を用いて本発明の実施形態の児童見守りサービス支援システム（情報処理システム）Ｓの概要を説明する。図１は、本実施形態における児童見守りサービス支援システムの構成を示す図である。

本実施形態における児童見守りサービス支援システムＳは、管理対象者である児童に携帯させる児童端末（端末）５００および児童の名札などに貼付されたＩＣタグ４００、このＩＣタグ４００に記憶される児童ＩＤ（識別情報）を読み取る機能を持つリーダ（識別情報取得部）３００、児童の保護者が操作する保護者端末６００、児童見守りサービス支援システムＳの運用を行うコーディネータが操作するコーディネータ端末７００、イベントの指導員が操作する指導員端末８００、防犯の為に地域のパトロールを行うパトロール員が操作するパトロール員端末９００、情報の格納や各種処理を行うサーバ１、それらを情報送受信可能に接続するネットワーク９から主に構成される。

ＩＣタグ４００は、小学校に通う児童が身につける名札などに貼付され、児童を一意に識別する識別情報としての児童ＩＤが格納される記憶媒体である。
児童端末５００は、サーバ１からの通知を無線通信で受信可能な携帯電話などの端末であり、児童が携帯する。
保護者端末６００は、一般的なコンピュータであり、児童の保護者が、児童見守りサービスへの児童の入会登録や、イベントへの参加の申込などを行うために操作する。
コーディネータ端末７００は、一般的なコンピュータであり、コーディネータが、児童見守りサービス支援システムＳを運用する際に操作する。
指導員端末８００は、一般的なコンピュータであり、児童見守りサービスを行う施設で開催されるイベントにおいて児童を指導監督する指導員がスケジュールの可否情報をサーバ１に送信する際などに操作する。なお、指導員は、地域によっては、保育士、教師ＯＢなどが行う場合もある。
パトロール員端末９００は、一般的なコンピュータや携帯端末などであり、児童帰宅時に帰宅ルート周辺の防犯パトロールを行うパトロール員が、サーバ１からのパトロール要請などの通知を受信するために操作する。なお、パトロール員は、地域によっては、例えば警官ＯＢや地域住民などが行う場合もある。
サーバ１は、ネットワーク９を介して入力された情報を格納したり、各種処理を行なって情報を送信したりする機能を持つ。

図２は、本実施形態における児童見守りサービス支援システムの処理概要を示すシーケンス図である。

まず、保護者端末６００は、保護者による児童見守りサービスへの入会手続のための操作に従って、入会登録要求をサーバ１に送信し、サーバ１は入会登録処理（Ａ）を行う。この入会登録処理（Ａ）の詳細な説明は、図１０を用いて後記する。

コーディネータ端末７００は、コーディネータによる、児童見守りサービスを行う施設で開催されるイベントを登録するための操作に従って、イベント登録要求をサーバ１に送信する。これにより、サーバ１でイベント登録処理（Ｂ）が行われる。その際には、イベント毎に配置する指導員が選択されるので、その情報に基づいた指導依頼を指導員端末８００に通知する。このイベント登録処理（Ｂ）の詳細な説明は、図１２を用いて後記する。

保護者端末６００は、保護者による児童見守りサービスへの児童の参加（出席）登録手続のための操作に従って、参加登録要求をサーバ１に送信する。これにより、サーバ１では参加登録処理（Ｃ）が行われる。この参加登録処理（Ｃ）の詳細な説明は、図１５を用いて後記する。

また、保護者端末６００は、保護者による、参加登録情報修正のための操作に従って、情報変更要求をサーバ１に送信する。これにより、サーバ１では情報変更処理（Ｄ）が行われる。この情報変更処理（Ｄ）の詳細な説明は、図１７を用いて後記する。

児童見守りサービスを行う施設に設置されるリーダ３００は、児童が施設に到着した際にリーダ３００にかざす名札から、名札に貼付されるＩＣタグ４００の児童ＩＤを取得し、サーバ１に出席登録要求として送信する。これにより、サーバ１は出席登録処理（Ｅ）を行う。この出席登録処理（Ｅ）の詳細な説明は、図２０を用いて後記する。

サーバ１は、児童の帰宅予定時刻の所定時間前（例えば、15分前）になると、帰宅準備処理（Ｆ）を行うことによって、児童の携帯する児童端末５００にアラートを通知する。これにより、児童は帰宅時刻を忘れることなく帰宅準備を始めることができる。
また、サーバ１は、下校時の帰宅グループのメンバに欠員が出た場合などに、当該グループのメンバの帰宅ルート検索処理を行う。ここで、通常とは異なる帰宅ルートを検索した場合には、児童端末５００および保護者端末６００に帰宅ルート変更を通知する。また、必要に応じてパトロール員端末９００に引率又はパトロール要請を送信する。この帰宅準備処理（Ｆ）の詳細な説明は図２３を用い、帰宅ルート検索処理の詳細な説明は図２５を用いて後記する。

また、リーダ３００は、施設から児童が帰宅する際に出席時と同様にリーダ３００に自身の名札をかざすことによって、ＩＣタグ４００の児童ＩＤを読み取り、サーバ１に帰宅登録要求として送信する。これにより、サーバ１は帰宅登録処理（Ｇ）を行う。この帰宅登録処理（Ｇ）の詳細な説明は、図２７を用いて後記する。
以下、サーバ１の各機能および各処理の流れを詳細に説明する。

図３は、本実施形態におけるサーバの機能ブロックと、サーバにネットワークを介して接続される各端末の構成を示す図である。
サーバ１は、処理部１００、および記憶部２００を備える。処理部１００は、記憶部２００に記憶される図示しない児童見守りサービス支援プログラムが、処理部１００であるＣＰＵ（Central Processing Unit）上に展開されることで実現される。

処理部１００は、入会処理部１１０、イベント登録処理部１２０、参加登録処理部１３０、出欠処理部１４０、帰宅準備処理部１５０、通信処理部１６０を含んで構成される。

入会処理部１１０は、入会登録情報登録部１１１およびＩＤ生成部１１２を含んで構成される。入会登録情報登録部１１１は、保護者端末６００から入力された児童の入会登録情報を、記憶部２００の個人情報データベース（以下、「ＤＢ」と記載）２１０に登録する。ＩＤ生成部１１２は、入会登録情報である各児童の情報を識別するための識別情報である児童ＩＤを生成して、受信した入会登録情報と対応させて個人情報ＤＢ２１０に記憶する。

イベント登録処理部１２０は、イベント登録部１２１および指導員配置部１２２を含んで構成される。イベント登録部１２１は、コーディネータ端末７００から入力されたイベントの情報をイベントＤＢ２２０に登録する。指導員配置部１２２は、コーディネータ端末７００から入力されたイベントの情報に適合する指導員を検出し、コーディネータ端末７００に出力する。

参加登録処理部１３０は、参加登録部１３１、出席簿編集部１３２、確認メール配信部１３３、カレンダー生成部１３４、情報変更部１３５を含んで構成される。参加登録部１３１は、保護者端末６００から入力された児童のサービスへの参加予定情報やイベントへの参加予定情報を、児童ＩＤ毎に記憶部２００の参加登録ＤＢ２５０に登録する。出席簿編集部１３２は、参加登録ＤＢ２５０に児童の到着時刻（予定）を登録する。確認メール配信部１３３は、保護者端末６００へ参加登録情報の確認メールを送信する。カレンダー生成部１３４は、参加登録ＤＢ２５０の情報からカレンダー形式のファイルを生成して保護者端末６００へ送信する。情報変更部１３５は、保護者端末６００から入力された参加変更情報に基づいて参加登録ＤＢ２５０を更新する。

出欠処理部１４０は、出席登録部１４１、帰宅時刻登録部１４２、到着時刻登録部１４３、到着アラート送信指示部１４４、帰宅登録部１４５を含んで構成される。出席登録部１４１は、参加登録ＤＢ２５０の情報を用いて、リーダ３００からの出席登録要求に含まれる児童ＩＤに該当する児童が当日参加予定か否かを判別する。帰宅時刻登録部１４２は、コーディネータ端末７００から入力された帰宅時刻（予定）の情報を、参加登録ＤＢ２５０に登録する。到着時刻登録部１４３は、出席登録要求を受信した時刻の情報を、到着時刻（実績）として参加登録ＤＢ２５０に登録する。到着アラート送信指示部１４４は、到着予定時刻になっても到着しない児童の児童端末５００に、アラートを送信する。帰宅登録部１４５は、リーダ３００からの帰宅登録要求を受信した時刻情報を、参加登録ＤＢ２５０に帰宅時刻（実績）として登録する。

帰宅準備処理部１５０は、帰宅アラート送信指示部１５１、帰宅時刻別一覧表示部１５２、および帰宅ルート検索部１５３を含んで構成される。帰宅アラート送信指示部１５１は、帰宅時刻の所定時間前に、児童端末５００にアラートを通知する。帰宅時刻別一覧表示部１５２は、コーディネータ端末７００に帰宅時刻毎の児童の情報を表示する。帰宅ルート検索部１５３は、児童の帰宅ルートを検索する。

通信処理部１６０は、受信部１６１、配信受付処理部１６２および送信部１６３を含んで構成される。受信部１６１は、ネットワーク９から受信した情報を、処理部１００の各処理部１１０〜１５０に出力する。配信受付処理部１６２は、処理部１００の各処理部１１０〜１５０から出力されてきたアラートやメールの配信指示を受け付け、送信部１６３に指示する。送信部１６３は、配信受付処理部１６２からの指示により、記憶部２００の情報を参照して、該当の端末にメールまたはアラートを送信する。以降、この説明を適宜省略する。

記憶部２００は、不揮発性の記憶媒体であり、児童の個人情報が記憶される個人情報ＤＢ２１０、児童見守りサービスを行う施設で開催されるイベントの情報が記憶されるイベントＤＢ２２０、イベントで利用する施設の情報が記憶される施設ＤＢ２３０、指導員の個人情報などが記憶される指導員ＤＢ２４０、児童の参加情報などが記憶される参加登録ＤＢ２５０、パトロール員の個人情報などが記憶されるパトロール員ＤＢ２６０、一般的な地理情報システム（ＧＩＳ：Geographic Information System）である地図ＤＢ２７０を含んで構成される。

図４は、記憶部の個人情報ＤＢ内に格納されるテーブルの例を示す図である。個人情報ＤＢ２１０は、児童の個人情報が格納される。
（ａ）に示す児童情報マスタテーブル２１０１は、児童を一意に識別する児童ＩＤ、児童名、児童の通う小学校、児童の所属する学年、学級、保護者がＷｅｂ上でログインする際のパスワード（ＰＷ）の項目を備える。
（ｂ）に示す保護者情報マスタテーブル２１０２は、児童ＩＤ、児童の保護者名、児童の住所、電話番号、緊急連絡先１（名称、電話番号）、緊急連絡先２（名称、電話番号）の項目を備える。
（ｃ）に示すメール配信情報マスタテーブル２１０３は、児童ＩＤ、アラートやメール送信先となる児童端末５００の児童メールアドレス、保護者端末６００の保護者メールアドレスの項目を備える。
（ｄ）に示す特記事項情報マスタテーブル２１０４は、児童ＩＤ、児童名、特記事項の項目を備える。
（ｅ）に示す児童宅情報マスタテーブル２１０５は、児童ＩＤ、住所、児童の住所から一義的に決定される通学基本ルートの項目を備える。
なお、図４の（ａ）〜（ｅ）に示した各マスタテーブル２１０１〜２１０５は、児童ＩＤでリンクされている。

図５は、記憶部のイベントＤＢ内に格納されるテーブルの例を示す図である。イベントＤＢ２２０は、児童見守りサービスを行う施設で開催されるイベントの情報が格納される。
（ａ）に示すイベント基本情報マスタテーブル２２０１は、イベントを一意に識別するイベントＩＤ、イベント名、イベント参加費用（費用）、イベントの開催曜日を識別する開催ＩＤ、イベントの開始時刻、終了時刻、イベントで利用する施設を一意に識別する施設ＩＤ、イベントの指導員に必要な要件を識別する要件ＩＤの項目を備える。
（ｂ）に示す開催日マスタテーブル２２０２は、開催ＩＤ、開催曜日の項目を備える。
（ｃ）に示すイベントスケジュールテーブル２２０３は、イベントＩＤ、スケジュールの項目を備え、日付毎のイベント有無を示す情報を記憶する。
なお、図５の（ａ）、（ｂ）に示した各テーブル２２０１，２２０２は、開催ＩＤでリンクされている。
また、図５の（ａ）、（ｃ）に示した各テーブル２２０１，２２０３は、イベントＩＤでリンクされている。

図６は、記憶部の施設ＤＢ内に格納されるテーブルの例を示す図である。施設ＤＢ２３０は、イベントで利用する施設の情報が格納される。
（ａ）に示す施設基本情報マスタテーブル２３０１は、施設を一意に識別する施設ＩＤ、施設名、利用最大人数、備品の項目を備える。
（ｂ）に示す他団体施設利用マスタテーブル２３０２は、団体を一意に識別する団体ＩＤ、団体名、施設ＩＤ、開催ＩＤの項目を備える。
なお、図５の（ａ）に示したイベント基本情報マスタテーブル２２０１と、図６の（ａ）に示した施設基本情報マスタテーブル２３０１とは、施設ＩＤでリンクされている。

図７は、記憶部の指導員ＤＢ内に格納されるテーブルの例を示す図である。指導員ＤＢ２４０は、指導員の個人情報などが格納される。
（ａ）に示す指導員要件マスタテーブル２４０１は、職業、資格、属性などの要件を一意に識別する要件ＩＤ、要件の項目を備える。
（ｂ）に示す指導員マスタテーブル２４０２は、指導員を一意に識別する指導員ＩＤ、指導員がＷｅｂ上でログインする際のパスワード（ＰＷ）、指導員の氏名、住所、電話番号、メールアドレス、指導員の保有する要件（要件ＩＤ）、指導可能日時としての日時ＩＤ（日時マスタテーブル２４０３参照）毎の可否（可能日時）、指導可能頻度としての頻度ＩＤ（頻度マスタテーブル２４０４参照）の項目を備える。
（ｃ）に示す日時マスタテーブル２４０３は、日時ＩＤ、曜日と時間帯を示す日時の項目を備える。
（ｄ）に示す頻度マスタテーブル２４０４は、頻度ＩＤ、ひと月の活動頻度の項目を備える。
（ｅ）に示す指導員スケジュールテーブル２４０５は、指導員ＩＤ、スケジュールの項目を備え、日付毎に指導（活動）有無を示すスケジュール情報を記憶する。
（ｆ）に示す指導員配置テーブル２４０６は、日付、イベントＩＤ、指導員ＩＤ、指導員へ指導依頼済みか否かを示す情報（依頼）、指導依頼に対する回答の有無および内容を示す情報（回答）、指導員の出欠の有無を示す情報（出欠）の項目を備える。
なお、図５（ａ）に示すイベント基本情報マスタテーブル２２０１と、図７（ａ）に示す指導員要件マスタテーブル２４０１とは、要件ＩＤでリンクされている。
また、図７（ａ）〜（ｆ）に示す各テーブルは、指導員ＩＤ、要件ＩＤ、日時ＩＤ、頻度ＩＤなどでリンクされている。

図８は、記憶部の参加登録ＤＢ内に格納されるテーブルの例を示す図である。参加登録ＤＢ２５０は、児童の参加（出席）有無などの情報が格納される。
（ａ）に示す出席簿テーブル２５０１は、日付毎の児童の児童見守りサービスへの参加の有無などの情報が記憶され、日付、児童ＩＤ、児童名、参加予定、参加するイベント（イベントＩＤ）、児童の到着時刻（予定）、到着時刻（実績）、児童の帰宅時刻（予定）、帰宅時刻（実績）、保護者による迎えの有無の項目を備える。
（ｂ）に示す授業終了時刻マスタテーブル２５０２は、各学年別、曜日別の時間割の情報に基づく、授業終了の時刻が登録される。
図８の（ａ）に示す出席簿テーブル２５０１は、図４（ａ）と児童ＩＤでリンクされ、図５（ａ）とイベントＩＤでリンクされている。

図９は、記憶部のパトロール員ＤＢ内に格納されるテーブルの例を示す図である。パトロール員ＤＢ２６０は、パトロール員の個人情報などが格納される。
（ａ）に示すパトロール員マスタテーブル２６０１は、パトロール員を一意に識別するパトロール員ＩＤ、パトロール員がＷｅｂ上でログインする際のパスワード（ＰＷ）、パトロール員の氏名、住所、電話番号、メールアドレス、パトロール可能な地区範囲を示すエリアＩＤ、パトロール可能日時としての日時ＩＤ（日時マスタテーブル２４０３参照）毎の可否（可能日時）、パトロール可能な頻度としての頻度ＩＤ（頻度マスタテーブル２４０４参照）の項目を備える。
（ｂ）に示すエリアマスタテーブル２６０２は、エリアＩＤ、パトロールする地区範囲を示すエリアの項目を備える。
（ｃ）に示すパトロール員スケジュールテーブル２６０３は、パトロール員ＩＤ、スケジュールの項目を備え、日付毎にパトロール（活動）有無を示すスケジュール情報を記憶する。
図９の（ａ）に示すパトロール員マスタテーブル２６０１は、（ｂ）エリアマスタテーブル２６０２とエリアＩＤでリンクされ、図７の（ｃ）に示す日時マスタテーブル２４０３と日時ＩＤでリンクされ、図７の（ｄ）に示す頻度マスタテーブル２４０４と頻度ＩＤでリンクされている。
また、図９の（ｃ）に示すパトロール員スケジュールテーブル２６０３は、（ａ）のパトロール員マスタテーブル２６０１とリンクされている。

これらのＤＢの詳細な内容およびＤＢを用いた処理の説明は、図１０〜図２７において後記する。

図３に戻って、児童の名札などに貼付されるＩＣタグ４００は、児童を識別する識別情報としての児童ＩＤを記憶する記憶部４０１を備える。
リーダ３００は、タグ情報取得部３０１と通信処理部３０２とを備え、ＩＣタグ４００の記憶部４０１に記憶された児童ＩＤをタグ情報取得部３０１が取得し、通信処理部３０２がネットワーク９を介してサーバ１に送信する。

続いて、サーバ１で実行される各処理（図２のＡ〜Ｇ）を、順を追って詳細に説明する。

Ａ．入会登録処理
まず、保護者は、保護者端末６００を用いて、児童の児童見守りサービス入会手続を行う。図１０は、サーバの入会登録処理を示すフローチャートである。図１０に沿って、適宜図１〜図４を参照しながら説明する。

保護者の操作により、保護者端末６００から送信された入会登録要求を受信（Ｓ１００）したら、サーバ１の入会処理部１１０の入会登録情報登録部１１１は、Ｗｅｂブラウザなどを用いて、保護者端末６００に入会登録画面を表示させる（Ｓ１０１）。
図１１は、入会登録処理時に保護者端末６００に表示される画面の一例である。保護者は、図１１（ａ）に示すように、児童名、児童の通う小学校、児童の所属する学年と学級、保護者名、住所、電話番号、緊急連絡先、児童メールアドレス、保護者メールアドレス、Ｗｅｂログイン用パスワード、特記事項などを入力し、画面右下の「確定」ボタンを押下する。これにより、保護者端末６００によって入力された入会登録情報が、サーバ１に送信される。

サーバ１は、入会登録情報を受信する（Ｓ１０２）。サーバ１の入会登録情報登録部１１１は、受信した入会登録情報を確認し、受信情報に問題があるか否かを判別する（Ｓ１０３）。ここでの入会登録情報の確認の一例としては、例えば、教育委員会から取得した学区内在住の児童情報が記載された名簿などの審査用データを予め記憶部２００に格納しておき、その審査用データと受信情報との照合を行うことが考えられる。これにより、受信した入会登録情報は、本サービスを利用可能な条件を満たしているか否かを判別する。
判別の結果、受信情報に問題があった場合には（Ｓ１０３→Ｎｏ）、ステップＳ１０２の処理に戻る。ここで、問題の内容を保護者端末６００の画面上に表示させてもよい。

一方、受信情報に問題が無かった場合には（Ｓ１０３→Ｙｅｓ）、サーバ１のＩＤ生成部１１２は、児童を一意に識別するための児童ＩＤを生成する。そして、ステップＳ１０４で生成した児童ＩＤに対応付けて、ステップＳ１０２で受信した入会登録情報を記憶部２００の個人情報ＤＢ２１０に登録する（Ｓ１０５）。これにより、サーバ１の個人情報ＤＢ２１０に、児童の情報および児童ＩＤが登録される。
図４（ａ）〜（ｅ）は、児童の個人情報および児童ＩＤが記憶された一例を示している。なお、児童宅情報マスタテーブル２１０５（図４（ｅ））の通学基本ルートについては、児童宅の住所から一義的に決定されるものとする。

続いて、サーバ１は、保護者端末６００に登録完了画面を表示させて（Ｓ１０６）、処理を終了する。
図１１（ｂ）は、保護者端末６００に表示される登録完了画面の一例である。登録された個人情報に加えて、ステップＳ１０４で生成された児童ＩＤが符号１１０１で示すように表示されている。なお、本実施形態では、図４における児童ＩＤと、保護者によるＷｅｂログイン用のＩＤは同一とし、以降、保護者は保護者端末６００から児童ＩＤとパスワードを入力することで、サーバ１にログインし、本システムの機能（児童見守りサービス）を利用可能とする。
保護者が「終了」ボタンを押下すると、登録完了画面が閉じる。

この処理の後で、個人情報ＤＢ２１０に登録された児童ＩＤを記憶したＩＣタグ４００が貼付された名札が、児童に配布される。児童は、以降、この名札を身に付けるなどして、本サービスを利用する。

Ｂ．イベント登録処理
コーディネータは、コーディネータ端末７００を用いて、児童見守りサービスを行う施設などで実施されるイベントの登録手続を行う。図１２は、サーバのイベント登録処理を示すフローチャートである。図１２に沿って、適宜図１〜図７を参照しながら説明する。なお、ここでは、翌月である６月のイベントを登録する場合を想定して説明する。

コーディネータの操作により、コーディネータ端末７００から送信されたイベント登録要求を受信（Ｓ２００）したら、サーバ１のイベント登録部１２１は、Ｗｅｂブラウザなどを用いて、コーディネータ端末７００にイベント登録画面を表示させる（Ｓ２０１）。

図１３は、イベント登録処理時にコーディネータ端末に表示される画面の一例である。図１３（ａ）では、例として６月のカレンダーが表示され、開催するイベントが日付毎に複数選択可能となっている。例えば、６月１日の「イベント１」としては、右側のプルダウンボタンを押下すると、教室遊び、なわとび、・・・がプルダウンメニューで選択可能となっている。ここで、選択可能に表示するイベントの候補は、イベントＤＢ２２０のイベント基本情報マスタテーブル２２０１の開催ＩＤを参照して、その日に開催可能なイベントを抽出して表示する。

また、イベント基本情報マスタテーブル２２０１とリンクされる施設ＤＢ２３０の施設基本情報マスタテーブル２３０１や、他団体施設利用マスタテーブル２３０２などを参照することで、その日に利用可能な施設で開催するイベントを検出して、表示させてもよい。また、外部の施設予約システムなどと連携することで、施設予約システムの予約情報を取得し、施設が利用可能かどうかを判別して表示させることも考えられる。さらに、外部の天気情報システムなどと連携することで、天気予報によりグラウンドが使用不可と判断される場合には、当該イベントを選択項目として表示させないこととしてもよい。
これによれば、他システムとの情報の共有化が図れ、事務作業を軽減し、施設を効率的に共同利用することが可能となる。

コーディネータが日毎に開催するイベントを入力し、画面右下の「指導員配置」ボタンを押下する。それにより、コーディネータ端末７００において入力したイベント情報（日毎に選択されたイベントのイベントＩＤ）がサーバ１に送信される。
サーバ１はイベント情報を受信し（Ｓ２０２）、イベント登録部１２１は、受信したイベント情報を、イベントＤＢ２２０のイベントスケジュールテーブル２２０３に記憶する。

そして、指導員配置部１２２は、イベント毎に配置する指導員を検索する（Ｓ２０３）。
ここで、指導員の検索方法としては、イベント基本情報マスタテーブル２２０１の要件ＩＤと指導員マスタテーブル２４０２の要件ＩＤとを照合して要件に適合する指導員を抽出し、さらに、イベント基本情報マスタテーブル２２０１の開催ＩＤと指導員マスタテーブル２４０２の可能日時および頻度ＩＤを参照して設定される。その条件としては、指導員の活動機会をなるべく均等にする為に、指導員マスタテーブル２４０２の検索開始レコードをランダムに変更する方法や、あるいは、活動の多かった指導員については（活動実績は、指導員配置テーブル２４０６の出欠を参照して算出）、翌月は活動回数を下げる方法を取ることとしてもよい。

また、指導員の検索方法の別の例として、各指導員の活動意欲を加味した方法をとることも考えられる。図１４は、図１２のステップＳ２０３で指導員を検索する際に、各指導員の意欲を検索条件に加味して行う場合の処理を示すフローチャートである。ステップＳ２０３１は、図１２のＳ２０２の後に実施され、ステップＳ２０３２→Ｎｏで図１２のステップＳ２０４の処理に続く。

まず、指導員配置部１２２は、頻度条件「ｆ０７」のメンバから指導員を検索する（Ｓ２０３１）。つまり、指導員マスタテーブル２４０２の頻度ＩＤ「ｆ０７」である指導員について、要件や可能日時を参照して、各イベントの指導員を検索する。頻度ＩＤ「ｆ０７」の指導員は、頻度マスタテーブル２４０４によれば、「何回でもよい」というように、活動意欲の高い指導員である。
頻度ＩＤ「ｆ０７」の指導員だけで検索した結果、指導員が未定のイベントが存在する場合には（Ｓ２０３２→Ｙｅｓ）、指導員配置部１２２は、未定のイベントについて、頻度条件「ｆ０ｎ」（ｎ＝６，５，４，…１）のメンバから指導員を検索する（Ｓ２０３３）。つまり、頻度ＩＤ「ｆ０６」、「ｆ０５」、・・・「ｆ０１」というように、順に検索して指導員を検索する。

これによれば、指導員の活動意欲に応じて活動回数を設定するので、活動意欲の高い指導員を優先的に設定することができる。よって、活動意欲が高いにもかかわらず活動の場が少ないために活動意欲が低下してしまうことを防ぐことができる。

図１２に戻って、指導員配置部１２２は、コーディネータ端末７００に指導員配置リスト画面を表示させる（Ｓ２０４）。
図１３（ｂ）は、コーディネータ端末７００に表示される指導員配置リスト画面の一例である。図１３（ｂ）では、図１３（ａ）でコーディネータが入力したイベントと、各イベントの右側に備えられた枠にステップＳ２０３で検索した指導員ＩＤが表示される。なお、指導員ＩＤの代わりに、指導員の氏名が表示されてもよい。

コーディネータは、コーディネータ端末７００に表示された指導員配置リスト画面（図１３（ｂ））を確認したら、必要に応じて適宜指導員の修正を行い、画面右下の「依頼メール」ボタンを押下する。それにより、コーディネータ端末７００において入力した指導員配置情報とメール配信指示がサーバ１に送信される。なお、コーディネータによる指導員の修正は、指導員マスタテーブル２４０２の要件ＩＤおよび可能日時の情報に基づき、当日当該イベントで活動可能な指導員をプルダウンメニューなどで表示することで、コーディネータに選択させることとしてもよい。
サーバ１は、メール配信指示と指導員配置情報を受信する（Ｓ２０５）。
そして、指導員配置部１２２は、受信した指導員配置情報を、指導員ＤＢ２４０の指導員スケジュールテーブル２４０５に記憶する。ここで、活動（指導）の場合は「１」が入力され、それ以外の場合は「０」が入力される。また、「１」の代わりに、当該指導員が指導するイベントのイベントＩＤが入力されることとしてもよい。

サーバ１の指導員配置部１２２は、指導員スケジュールテーブル２４０５を用いて各指導員の活動頻度を算出する。そして、前記算出した指導員毎の活動頻度と、指導員マスタテーブル２４０２に記憶される各指導員の頻度条件（頻度ＩＤ）とを比較し、活動日数が頻度条件を超えていないか判別する（Ｓ２０６）。この処理によって、コーディネータの修正で、各指導員の活動頻度が頻度条件を超えていないかを判別する。頻度条件を超える活動日数の指導員が存在した場合（Ｓ２０６→Ｎｏ）、指導員配置部１２２は、当該指導員が設定されている当該日付のイベントについて、候補となる他の指導員を検索し（Ｓ２０７）、ステップＳ２０４に戻って、コーディネータ端末７００に指導員配置リストを表示する。このとき、コーディネータ端末７００に、指導員を再設定する必要があることを示すメッセージを表示し、指導員配置リスト画面の、当該日付の指導員の枠を強調表示させるなどしてもよい。これにより、コーディネータは頻度条件を超える活動日数となっていた指導員が変更されたことを確認し、必要に応じて別の指導員に変更することができる。

なお、図７の指導員要件マスタテーブル２４０１において、中学生、高校生、高齢者は、正規の指導員としてではなく、補助的人材として位置づけることも考えられる。つまり、各イベントのメイン指導員として要件「０１０」〜「０６０」の指導員を設定後、中学生、高校生、高齢者などのメンバを可能日時条件で設定するようにする。そして、活動実績が一定レベルを超えたらメイン指導員として配置できるように要件ＩＤを変更することとしてもよい。これにより、より多彩な地域人材を活用することができる。

図１２に戻って、ステップＳ２０６で頻度条件を越える活動日数の指導員が存在しなかった場合（Ｓ２０６→Ｙｅｓ）、指導員配置部１２２は、指導員マスタテーブル２４０２のメールアドレスの情報を参照して、指導員端末８００へ、指導依頼する日付およびイベントの情報を記載した指導依頼メールを送信する（Ｓ２０８）。同時に、指導員配置部１２２は、指導員配置テーブル２４０６に日付、イベントＩＤ、指導員ＩＤ、依頼「ＯＫ」の情報を記憶する。

指導員は、指導員端末８００を用いて受信した指導依頼メールを確認し、日付毎イベント毎の指導の可否を示す指導可否メールをサーバ１に送信する。

サーバ１が指導員端末８００から指導依頼メールに対する指導可否メールを受信（Ｓ２０９）したら、指導員配置部１２２は、各日毎のイベントの指導が可か否かを判別する（Ｓ２１０）。指導可でなかった場合（Ｓ２１０→Ｎｏ）、指導員配置部１２２は、指導員配置テーブル２４０６の当該日付、当該イベントＩＤ、当該指導員ＩＤの「回答」の項目に「ＮＧ」を登録してから、ステップＳ２０７の処理を行う。つまり、当該指導員が設定されていた当該日付のイベントについて、候補となる他の指導員を検索する。
一方、指導可であった場合（Ｓ２１０→Ｙｅｓ）、指導員配置部１２２は、指導員配置テーブル２４０６の当該日付、当該イベントＩＤ、当該指導員ＩＤの「回答」の項目に「ＯＫ」を登録することで更新（Ｓ２１１）して、処理を終了する。

これにより、サーバ１のイベントＤＢ２２０に、イベントの情報と指導員の配置情報が登録される。なお、このイベント登録処理は、翌月の予定を入力するだけでなく、適宜変更可能としてもよい。例えば、イベントへの参加状況や天気などにより、イベントの開催に変更がある場合には、イベント登録の処理と同様に変更を行い、その変更に伴う指導員配置の変更を行う。

なお、ステップＳ２０８、Ｓ２０９の他の方法として、指導員端末８００に、Ｗｅｂブラウザなどを用いて指導員スケジュールテーブル２４０５の情報をカレンダー形式で表示させ、指導員は日付毎の可否を、Ｗｅｂブラウザを介して入力することとしてもよい。入力された可否情報は、指導員ＤＢ２４０の指導員配置テーブル２４０６の「回答」の項目に「ＯＫ」又は「ＮＧ」などで記憶される。これにより、各指導員の回答状況をコーディネータが確認することも可能である。

指導員配置テーブル２４０６の出欠の項目については、例えば指導員ＩＤの情報を記憶するＩＣタグが貼付されたカードなどを指導員に配布し、指導員が出勤（活動）時にカードをリーダ３００にかざす。それによりリーダ３００が取得した指導員ＩＤを、サーバ１で指導員配置テーブル２４０６の出欠の項目に記憶することで、指導員の出勤管理を行うことが可能である。

Ｃ．参加登録処理
続いて、保護者は、保護者端末６００を用いて、児童見守りサービスへの児童の参加登録手続を行う。図１５は、サーバの参加登録処理を示すフローチャートである。図１５に沿って、適宜図１〜図８を参照しながら説明する。なお、ここでは、翌月である６月のイベントに参加登録する場合を想定して説明する。
本処理の前に、保護者は、児童ＩＤおよびＷｅｂログイン用パスワードを送信することで、保護者端末６００を用いてサーバ１にログイン済みであるものとする。

保護者の操作により、保護者端末６００から送信された参加登録要求を受信（Ｓ３００）したら、サーバ１の参加登録部１３１は、保護者端末６００のＷｅｂブラウザなどを用いて参加申込画面を表示させる（Ｓ３０１）。

図１６は、参加登録処理時に保護者端末に表示される画面の一例である。図１６（ａ）において、６月のカレンダーが表示されており、参加申込情報として、日付毎に、「参加予定」、「イベント」、「帰宅時刻」、「迎え」の項目がそれぞれプルダウンメニューで選択可能となっている。各項目について説明すると、「参加予定」は児童見守りサービスへの参加予定の有無を設定する。「イベント」は、児童が児童見守りサービスに出席する場合に参加するイベントを設定する。ここでは、イベントスケジュールテーブル２２０３を参照し、開催されるイベントが日付毎に候補として表示される。「帰宅時刻」は児童の帰宅予定時刻を設定する。例えば、イベントの終了時刻が１８：００であっても、習い事などの都合で１７：００に帰宅させたい場合などに適宜指定する。「迎え」は保護者による児童迎えが有るか否かを設定する。つまり、保護者迎えが有る場合には、児童は児童グループでの集団下校はしないことになる。
保護者は、保護者端末６００を用いて、参加申込情報を日付毎に設定する。

図１６（ａ）の参加申込画面において、「参加費」ボタンを押下すると、符号１６０１で示すように、現時点でのイベント参加費が表示されるようにしてもよい。具体的には、「参加費」ボタンが押下されると、保護者端末６００は、児童の参加するイベントの情報（イベント登録情報）をサーバ１に送信する。そして、サーバ１は、受信したイベント登録情報と、イベント基本情報マスタテーブル２２０１に記憶されている費用の情報とを用いて、イベント参加費を算出し、保護者端末６００に送信する。これにより、符号１６０１で示すように、保護者端末６００の参加申込画面に、サーバ１で算出されたイベント参加費が表示される。
これにより保護者は、イベント参加費を確認しながら、児童のイベント参加を設定することができる。

保護者は、参加申込画面の入力が完了したら、画面右下の「申込」ボタンを押下する。これにより、保護者端末６００において入力した参加予定情報、イベントＩＤ、帰宅予定時刻、迎えの有無などの参加申込情報がサーバ１に送信される。

サーバ１は、参加申込情報を受信する（Ｓ３０２）。サーバ１の参加登録部１３１は、受信した参加申込情報を確認し、問題があるか否かを判別する（Ｓ３０３）。ここで問題がある場合とは、例えば、不正な帰宅時刻などが設定されている場合などであるが、予め参加申込情報入力の時点で不正な情報は設定できないようにしておいてもよい。その場合、ステップＳ３０３の処理は不要となる。

ステップＳ３０３の判別の結果、受信情報に問題が無かった場合には（Ｓ３０３→Ｙｅｓ）、ステップＳ３０４の処理に進む。一方、問題があった場合には（Ｓ３０３→Ｎｏ）、ステップＳ３０２の処理に戻る。ここで、問題の内容を保護者端末６００の画面上に表示させてもよい。

ステップＳ３０４で、参加登録部１３１は、ステップＳ３０２で受信した参加登録情報を、参加登録ＤＢ２５０の出席簿テーブル２５０１に登録する。

そして、参加登録部１３１は、出席簿テーブル２５０１の情報を用いて、保護者端末６００に登録完了画面を表示させる（Ｓ３０５）。このとき、イベント参加費の月合計を、出席簿テーブル２５０１およびイベント基本情報マスタテーブル２２０１を用いて算出し、表示する。図１６（ｂ）は、保護者端末６００に表示される登録完了画面の一例である。符号１６０２に示すように、イベント参加費の合計が表示されている。なお、保護者が「終了」ボタンを押下すると、登録完了画面が閉じる。

続いて、ステップＳ３０６で、サーバ１の出席簿編集部１３２は、出席簿テーブル２５０１の到着時刻（予定）を登録して、処理を終了する。具体的には、出席簿編集部１３２は、児童情報マスタテーブル２１０１の当該児童の学年の情報から、授業終了時刻マスタテーブル２５０２を参照して授業終了時刻を取得し、到着時刻（予定）を登録する。例えば、児童ＩＤ「０１０１」の生徒は、個人情報ＤＢ２１０の児童情報マスタテーブル２１０１によれば学年「１」であり、出席簿テーブル２５０１の日付「060601」は「木曜日」であることから、授業終了時刻マスタテーブル２５０２より「15：00」を到着時刻（予定）として取得し、登録する。なお、到着時刻（予定）の設定には、施設までの移動時間などを授業終了時刻に適宜加えた上で登録してもよい。

これにより、出席簿テーブル２５０１に、日付毎、児童ＩＤ毎の、参加登録情報および到着時刻（予定）の情報が登録される。
図５（ａ）の出席簿テーブル２５０１は、情報が登録された状態を示しており、出席簿テーブル２５０１の１レコード目に記憶された情報は、図１６（ａ）の「６月１日」の情報に相当する。

Ｄ．情報変更処理
続いて、保護者が、保護者端末６００を用いて、既に登録した児童の参加登録情報を変更する情報変更手続について説明する。図１７は、サーバの情報変更処理を示すフローチャートである。図１７に沿って、適宜図１〜図８を参照しながら説明する。なお、本処理の前に、保護者は、児童ＩＤおよびＷｅｂログイン用パスワードを送信することで、保護者端末６００を用いてサーバ１にログイン済みであるものとする。

保護者の操作により、保護者端末６００から送信された情報変更要求を受信（Ｓ４００）したら、サーバ１の情報変更部１３５は、保護者端末６００のＷｅｂブラウザなどを用いて情報変更画面を表示させる（Ｓ４０１）。

図１８は、情報変更処理時に保護者端末に表示される画面の一例である。図１８（ａ）において、参加登録情報として登録された、当該児童の出席簿テーブル２５０１の情報が表示されている。
ここで、保護者が保護者端末６００を用いて必要に応じて各項目の変更を行い、画面右下の「確定」ボタンを押下する。これにより、保護者端末６００において情報変更を行った参加変更情報がサーバ１に送信される。このとき、変更された情報のみ送信してもよいし、ひと月分の参加予定情報、イベントＩＤ、帰宅予定時刻、迎えの有無の情報を送信することとしてもよい。
ここでは、例として「2006/6/6（火）［出欠（○）/イベント（勉強会）/帰宅時刻（18:00）/迎え（○）］」の情報を、「2006/6/6（火）［出欠（不参加）/イベント（−）/帰宅時刻（−）/迎え（−）］」に変更するものとして説明する。

サーバ１は、参加変更情報を受信する（Ｓ４０２）。サーバ１の情報変更部１３５は、受信した参加変更情報を確認し、問題があるか否かを判別する（Ｓ４０３）。このステップＳ４０３の処理は、参加登録処理におけるステップＳ３０３（図１５参照）の処理と同様である。

参加変更情報の内容確認の結果、受信情報に問題が無かった場合には（Ｓ４０３→Ｙｅｓ）、ステップＳ４０４の処理に進む。一方、問題があった場合には（Ｓ４０３→Ｎｏ）、ステップＳ４０２の処理に戻る。ここで、問題の内容を保護者端末６００の画面上に表示させてもよい。

ステップＳ４０４で、情報変更部１３５は、ステップＳ４０２で受信した参加変更情報に基づいて、参加登録ＤＢ２５０の出席簿テーブル２５０１を更新する（Ｓ４０４）。
そして、情報変更部１３５は、更新した出席簿テーブル２５０１の情報を用いて、保護者端末６００に変更完了画面（図１８（ｂ）参照）を表示させる（Ｓ４０５）。

続いて、ステップＳ４０６で、サーバ１の出席簿編集部１３２は、出席簿テーブル２５０１において、変更された日付について、参加「○」で到着時刻（予定）が未登録であった場合には、前記したステップＳ３０６の処理と同様に取得して、登録する。

情報変更部１３５は、コーディネータ端末７００と児童端末５００に参加登録情報の変更があったことを通知（Ｓ４０７）して、処理を終了する。さらに、必要に応じて保護者端末６００に通知してもよい。なお、コーディネータ端末７００のメールアドレスの情報は、図示しないＤＢに記憶されているものとする。
ここで、ステップＳ４０７の通知の際に変更内容を通知してもよい。例えば、「ＩＤ［0101］の［日立花子］さんの参加登録情報に変更がありました。2006/6/6（火）［出欠（○）/イベント（勉強会）/帰宅時刻（18:00）/迎え（○）］は、［出欠（×）/イベント（−）/帰宅時刻（−）/迎え（−）］に変更されました」というメールを送信することも考えられる。
これによれば、コーディネータおよび児童も、変更があったことを迅速に把握でき、情報の共有化が図れる。

図１８（ｂ）で、保護者が「変更」ボタンを押下した場合には、保護者端末６００からサーバ１に再度情報変更要求が送信される（Ｓ４００に戻る）。また、「終了」ボタンを押下した場合には、変更完了画面が閉じる。

以上説明した情報変更処理によれば、登録した参加登録情報を、保護者が簡易に変更することができる。これは、例えば児童が体調不良などにより、翌日の小学校を欠席し、そのまま児童見守りサービスも欠席する場合など、緊急の連絡にも対応可能である。また、変更したことをコーディネータおよび児童に通知するので、迅速に情報を把握することができる。
なお、情報変更手続を、児童の通う小学校の学級担任が行えるようにしてもよい。その場合には、小学校に設置される、ネットワーク９に接続可能な一般的なコンピュータを用いて、学級担任が当該児童の情報変更を行う。これによれば、保護者が情報変更を忘れた場合でも、学級担任とコーディネータとの情報の連携をスムーズに行うことができる。

前記説明した参加登録処理および情報変更処理において、以下のサービスを行うことも可能である。
例えば、参加登録情報確認サービスとして、サーバ１は、例えば毎週金曜などに、翌週１週間分の参加登録情報を確認用として保護者端末６００に通知してもよい。具体的には、サーバ１の確認メール配信部１３３は、参加登録ＤＢ２５０の出席簿テーブル２５０１から当該児童の翌週一週間分の情報を抽出して、個人情報ＤＢ２１０のメール配信情報マスタテーブル２１０３の保護者メールアドレス宛に送信する。また、児童メールアドレスに対して同様の情報を送信することも考えられる。これによれば、保護者および児童は、最新の参加登録情報を毎週確認することができる。さらに、保護者端末６００に送信するメールに、参加登録情報の情報変更画面を表示するサイトのＵＲＬ（Uniform Resource Locator）を記載してもよい。保護者は必要に応じて、当該ＵＲＬから児童ＩＤとＷｅｂログイン用パスワードでログインして参加登録情報を変更する。これにより、保護者は簡易に情報の修正を行うことができる。

また、参加登録情報を、デスクトップに表示するカレンダー形式で保護者へ提供することも考えられる。
具体的には、サーバ１のカレンダー生成部１３４が、出席簿テーブル２５０１の当該児童の情報を抽出し、カレンダー形式に変換して、保護者端末６００へ送信する。保護者端末６００では、受信したファイルを開いて壁紙として設定することで、デスクトップに参加登録情報が表示される。図１９は、保護者端末のデスクトップ上に表示されたカレンダー形式の参加登録情報を示す図である。これによれば、児童の参加予定を保護者は簡易に把握可能である。ここで、カレンダーファイルはメール配信情報マスタテーブル２１０３の保護者メールアドレスの情報を用いてメールで送信されてもよいし、Ｗｅｂブラウザを介して適宜ダウンロード可能としてもよい。

Ｅ．出席登録処理
児童は、小学校などの授業終了後、児童見守りサービスを行う施設に到着したら、出席登録手続を行う。図２０は、サーバの出席登録処理を示すフローチャートである。図２０に沿って、適宜図１〜図８を参照しながら説明する。なお、児童は名札（ＩＣタグ４００が貼付されている）を身につけて小学校に通うものとする。

児童が施設に到着して自身の名札をリーダ３００にかざすことで、ＩＣタグ４００の記憶部４０１に記憶される児童ＩＤが、リーダ３００のタグ情報取得部３０１に取得される。そして、リーダ３００が取得した児童ＩＤの情報は、リーダ３００の通信処理部３０２からサーバ１に出席登録要求として送信される。サーバ１はこの出席登録要求を受信する（Ｓ５００）。

続いて、サーバ１の出欠処理部１４０の出席登録部１４１は、参加登録ＤＢ２５０の出席簿テーブル２５０１を参照して、参加登録があるかどうか、つまり、当該児童ＩＤの児童が本日参加予定となっているか否かを判別する（Ｓ５０１）。例えば、「2006/6/1」に、出席登録要求として児童ＩＤ「0101」の情報を受信した場合には、出席登録部１４１は、参加登録ＤＢ２５０の出席簿テーブル２５０１を参照して、児童ＩＤ「0101」の「日立花子」は、参加「○」となっているので、参加予定であると判別する。参加予定となっていた場合には（Ｓ５０１→Ｙｅｓ）、ステップＳ５０５の処理に進む。

一方、参加予定となっていなかった場合には（Ｓ５０１→Ｎｏ）、出席登録部１４１は、コーディネータ端末７００に参加登録画面を表示させる（Ｓ５０２）。
図２１は、出席登録処理において、参加予定となっていない児童ＩＤを受信した場合に、出席登録部がコーディネータ端末に表示させる画面の一例を示す図である。ここでは、児童ＩＤ「0102」の「東西梅子」が、児童見守りサービスに2006/6/1は参加予定としていない（つまり、図８（ａ）の出席簿テーブル２５０１において、参加「×」で登録済み）にもかかわらず、当該児童が施設に来て名札をリーダ３００にかざした場合を説明する。

図２１（ａ）によれば、符号２１０１に示すように、児童ＩＤ「0102」の「東西梅子」のレコードが強調表示されており、当該レコードの参加予定項目が「×」と示されている。この参加予定項目には、図５（ａ）の出席簿テーブル２５０１の参加項目の情報が示される。
コーディネータは、児童に確認したり、必要に応じて保護者に確認するなどして、参加登録を行う。なお、図２１（ａ）の「保護者情報表示」ボタンを押下すると、個人情報ＤＢ２１０の保護者情報マスタテーブル２１０２を参照して、当該児童ＩＤの保護者情報が表示される。これにより、コーディネータは、表示された電話番号に電話して、当該児童の参加可否を確認することができる。

当該児童を参加させる場合には、コーディネータは、コーディネータ端末７００を用いて図２１（ａ）の「参加登録」ボタンを押下する。これにより、不参加者参加要求がサーバ１に送信され、サーバ１の出席登録部１４１はこの不参加者参加要求を受信して、出席簿テーブル２５０１の参加予定に「○」を登録する（Ｓ５０３）。
続いて、サーバ１の出席登録部１４１は、図２１（ｂ）に示すイベント参加の登録が可能なイベント参加登録画面を表示する。
コーディネータは、当該児童がイベントに参加する場合には、参加するイベントをプルダウンメニューから選択し、「登録」ボタンを押下する。これにより、コーディネータ端末７００からイベント参加登録要求がサーバ１へ送信される。サーバ１の出席登録部１４１は、イベント参加登録要求を受信して、イベント参加登録要求に設定されたイベントＩＤを出席簿テーブル２５０１のイベントＩＤに登録する（Ｓ５０４）。ここで、出席登録部１４１は、当該児童が本サービスに参加することと、必要に応じて参加イベントの情報を保護者端末６００に通知してもよい。
これにより、不参加となっていた児童が当日になって参加することになった場合でも、対応可能である。

続いて、サーバ１の帰宅時刻登録部１４２は、出席簿テーブル２５０１において、当該児童ＩＤの帰宅時刻（予定）が登録済みか否かを判別する（Ｓ５０５）。登録済みであった場合には（Ｓ５０５→Ｙｅｓ）、ステップＳ５０９の処理に進む。
一方、登録済みでなかった場合には（Ｓ５０５→Ｎｏ）、帰宅時刻登録部１４２は、コーディネータ端末７００に帰宅時刻受付画面を表示させる（Ｓ５０６）。
図２２は、出席登録処理において、帰宅時刻（予定）が登録済みで無かった場合に、帰宅時刻登録部がコーディネータ端末に表示させる画面の一例を示す図である。図２２（ａ）では、児童ＩＤ「0101」の「日立花子」の帰宅時刻（予定）が登録されていないことが示され、帰宅時刻が選択可能となっている。
コーディネータは、児童と相談の上、帰宅時刻を選択する。ここでは、「18：00」を選択して、「登録」ボタンを押下すると、コーディネータ端末７００からサーバ１に、帰宅時刻（予定）情報が送信される。サーバ１の帰宅時刻登録部１４２は、帰宅時刻（予定）情報を受信したら（Ｓ５０７）、出席簿テーブル２５０１の帰宅時刻（予定）に登録する（Ｓ５０８）。

到着時刻登録部１４３は、ステップＳ５００で出席登録要求を受信した時刻を、出席簿テーブル２５０１の到着時刻（実績）に登録して（Ｓ５０９）、コーディネータ端末７００に出欠管理画面を表示し（Ｓ５１０）、処理を終了する。
図２２（ｂ）は、コーディネータ端末７００に表示される出欠管理画面の一例を示す図である。ここでは、符号２２０１および符号２２０２で示すように、ＩＤ（児童ＩＤ）「0101」の「日立花子」において、到着時刻（実績）に「14：50」、帰宅時刻（予定）に「18：00」が登録されている。

図２２（ｂ）の出欠管理画面において、コーディネータが「学年別」ボタンを押下すると、出欠管理画面で表示される児童が、学年別に表示される。また、コーディネータが「終了」ボタンを押下すると、出欠管理画面が閉じる。

なお、児童が名札を忘れた場合には、コーディネータが予備のＩＣタグ４００をリーダ３００にかざすことによって、当該児童の到着時刻（実績）の情報を適宜入力可能としてもよい。

また、ステップＳ５０６において、帰宅時刻受付画面をコーディネータ端末７００に表示させて、コーディネータに入力させることとしたが、これに限らず、例えば５年生以上などの高学年に限っては、リーダ３００に接続された一般的なコンピュータのキーボードやタッチパネルなどから、児童自身が帰宅時刻（予定）を入力することで、当該コンピュータからサーバ１へ帰宅時刻（予定）情報を送信してもよい。

また、この出席登録処理において、到着予定時刻が到来しても児童が出席登録手続を行っていない場合に、当該の児童の携帯する児童端末５００に対してアラートを送信することもできる。
具体的には、到着アラート送信指示部１４４が、出席簿テーブル２５０１を参照して、参加予定「○」で、かつ、現在時刻が出席簿テーブル２５０１の到着時刻（予定）を過ぎているにもかかわらず、到着時刻（実績）が未登録である児童ＩＤを検出し、当該児童ＩＤの児童メールアドレスに対し、例えば「開始時刻が過ぎています！」などのメッセージを送信してもよい。
それによれば、児童が児童見守りサービスを行う施設に行くことをうっかり忘れていた場合でも、注意喚起することができる。

Ｆ．帰宅準備処理（帰宅ルート検索処理）
通常、児童見守りサービスを行う施設から児童が帰宅する場合は、同じ帰宅ルートに所属するグループ毎に集まって帰宅する。しかしながら、保護者迎えが有る場合や、習い事などで途中で帰宅する場合など、全員が同じ時刻に帰宅できないことがある。通常の帰宅ルートでグループ全員が帰宅できない場合（例えば少人数で帰宅する場合や、低学年だけで帰宅する場合）には、防犯のために、帰宅ルートの変更などを検討する必要がある。
以下、帰宅準備処理について詳細に説明する。

図２３は、サーバの帰宅準備処理を示すフローチャートである。図２３に沿って、適宜図１〜図８を参照しながら説明する。

サーバ１の帰宅準備処理部１５０の帰宅アラート送信指示部１５１は、出席簿テーブル２５０１を参照して、帰宅時刻（予定）の所定時間前（例えば、15分前）に、児童端末５００へアラートを通知する（Ｓ６０１）。この所定時間は、コーディネータが適宜設定可能としてもよい。
具体的には、帰宅アラート送信指示部１５１が、現在時刻が「17：45」のときに、帰宅時刻（予定）「18：00」となっている児童ＩＤを検出し、当該児童ＩＤのメールアドレスに対し、例えば「帰宅時刻15分前」などのメッセージを送信する。児童は、児童端末５００が受信したメッセージを開封して内容を確認する。

帰宅時刻別一覧表示部１５２は、出席簿テーブル２５０１を参照して、コーディネータ端末７００の画面上に、帰宅時刻別一覧画面を表示させる（Ｓ６０２）。図２４は、帰宅準備処理において、コーディネータ端末に表示される画面の一例と、児童への通知を示す図である。
図２４（ａ）では、帰宅時刻が「18：00」である児童の一覧が表示されている。なお、帰宅時刻はプルダウンメニューで選択可能となっており、コーディネータは適宜指定して表示を変更することができる。
ここで、ステップＳ６０１で送信したアラートを、児童が確認したという情報（例えば、メールの開封通知など）をサーバ１が受信することで、アラートに気づかない児童に対して、再度アラートを通知してもよい。図２４（ａ）の表によれば、アラートに気づかない児童は太枠で強調表示されている。これは、例えば、児童端末５００からのメール開封確認などの情報をサーバ１が受信し、児童が確認したか否かを判別することで実現可能である。

太枠で強調表示された、アラートに気づかない児童には、再度アラートを送信してもよい。その場合には、コーディネータが、コーディネータ端末７００を用いて、当該児童を選択し「通知」ボタンを押下することにより、サーバ１は児童端末５００に対してアラートを送信する。
なお、図２４（ｂ）では、児童の持つ児童端末５００が、警告音と共に、受信したメッセージを音声で児童に通知している様子が示されている。

これによれば、従来はコーディネータおよび指導員が、帰宅時刻毎に、児童一人一人に声をかけて帰宅を促してしていた手間を、大幅に削減することができる。

続いて、帰宅ルート検索部１５３は、帰宅ルートの検索が必要か否かを判別する（Ｓ６０３）。帰宅ルートの検索が必要か否かの判別条件は、例えば以下のとおりである。
個人情報ＤＢ２１０の児童宅情報マスタテーブル２１０５において、通学基本ルートの同じ児童（以下、「グループ」と記載）全員が、以下の条件を満たす場合に、帰宅ルートの検索は必要ないと判別（Ｓ６０３→Ｎｏ）され、処理が終了する。
・出席簿テーブル２５０１の到着時刻（実績）に情報あり
・出席簿テーブル２５０１の帰宅時刻（予定）が一致
・迎えが「×」
つまり、前記条件を満たす場合とは、通常のグループのメンバ全員で帰宅するということであり、この場合、児童は、通常帰宅ルートで帰宅することとなる。
一方、上記条件が１つ以上満たされなかった場合には（Ｓ６０３→Ｙｅｓ）、帰宅ルート検索処理を行って（Ｓ６０４）から、終了する。以下、帰宅ルート検索処理を詳細に説明する。

＜帰宅ルート検索処理＞
図２５は、サーバの帰宅ルート検索処理を示すフローチャートである。図２５に沿って、適宜図１〜図９を参照しながら説明する。
なお、パトロール員は、前記したように、児童の帰宅時間帯にあわせてパトロールを行い、必要に応じて、施設から児童宅までの引率なども行うものとする。

図２３のステップＳ６０３の処理に続き、サーバ１の帰宅準備処理部１５０の帰宅ルート検索部１５３は、コーディネータ端末７００に、帰宅予定時刻別の児童宅地図と通学基本ルートを表示させる（Ｓ６０４０）。なお、地図の表示には地理情報システム（ＧＩＳ）などの地図ＤＢ２７０を参照し、児童宅の情報は個人情報ＤＢ２１０を参照する。
図２６は、帰宅ルート検索処理において、コーディネータ端末に表示される画面の一例を示す図である。図２６（ａ）は、「18:00」に帰宅する児童の通学基本ルートを表示しており、これによれば、Ａルート（通学基本ルート「Ａ」）とＢルート（通学基本ルート「Ｂ」）とが視覚的に把握可能となっている。そして、出席簿テーブル２５０１から取得した、児童の住所を示す住宅マーク内には、児童ＩＤ、欠席者であれば「欠」、迎え有りであれば「迎」と表示される。また、各住宅マークにカーソルを当てることで、児童の氏名や学年などの情報が表示されるようにしてもよい。なお、図２４（ａ）の「下校ルート」ボタンを押下した場合にも、図２６（ａ）の画面を表示する。

コーディネータが、図２６（ａ）の画面で「最適ルート検索」ボタンを押下することで、コーディネータ端末７００からサーバ１へ最適ルート検索要求が送信され、サーバ１はこれを受信する（Ｓ６０４１）。
帰宅ルート検索部１５３は、各通学基本ルートのグループにおいて、高学年児童不在の通学基本ルート（グループ）が存在するか否かを判別する（Ｓ６０４２）。なお、本実施形態では例として、５年生以上の児童を高学年とし、２年生以下の児童を低学年とする。
全ての通学基本ルートに高学年児童が含まれる場合には（Ｓ６０４２→Ｎｏ）、帰宅ルート検索部１５３は、各グループの児童に低学年の児童を含むか否かを判別する（Ｓ６０４３）。低学年の児童を含まない場合には（Ｓ６０４３→Ｎｏ）、児童は通常どおりの通学基本ルートで帰宅することとなり、帰宅ルート検索部１５３は処理を終了する。

一方、ステップＳ６０４３で、低学年の児童が含まれているグループが存在した場合には（Ｓ６０４３→Ｙｅｓ）、帰宅ルート検索部１５３は、当該グループについて、最適ルートを検索する（Ｓ６０４４）。具体的には、低学年児童が最後に一人とならないように、出発地（小学校や施設）から最も離れている高学年児童宅を最終目的地と設定し、最短距離となるルートを検索する。なお、この場合、可能な限り他の通学基本ルートに同行させるようにしてもよい。
図２６（ｂ）は、帰宅ルート検索部１５３が、検索を行った結果決定された最適ルートをコーディネータ端末７００に表示させた画面の一例である。ここでは、図２６（ａ）に示す通学基本ルートＢ（Ｂルート）で帰宅するグループが、欠席や迎えなどによってメンバが減少したため、ルートの検索を行い、最短距離となるルートに変更したことが示されている。

帰宅ルート検索部１５３は、ステップＳ６０４４で検索を行った結果決定された最適ルートを、個人情報ＤＢ２１０を参照して、児童端末５００および保護者端末６００にメールなどで通知する（Ｓ６０４５）。

帰宅ルート検索部１５３は、ルートの変更に伴い、パトロール員のパトロールエリアも最適ルートに合わせて変更する。パトロール員のパトロールエリアの変更は、パトロール員ＤＢ２６０のパトロール員マスタテーブル２６０１、エリアマスタテーブル２６０２、およびパトロール員スケジュールテーブル２６０３を参照して決定する。
そして、パトロール員ＤＢ２６０を参照して、パトロール員端末９００に「通学ルート変更」と「パトロールエリア変更依頼」をメールにて通知し（Ｓ６０４６）、処理を終了する。

一方、ステップＳ６０４２で、通学基本ルートに高学年児童が含まれていないグループが存在した場合（Ｓ６０４２→Ｙｅｓ）、帰宅ルート検索部１５３は、当該グループ以外の通学基本ルートのグループのメンバに、高学年児童が含まれているか否かを判別する（Ｓ６０４７）。高学年児童が含まれていた場合には（Ｓ６０４７→Ｙｅｓ）、帰宅ルート検索部１５３は、高学年児童の含まれる通学基本ルートの中で、最も近い距離のルートのメンバに、当該グループの児童を追加して（Ｓ６０４８）、ステップＳ６０４４以降の処理を実施する。

一方、ステップＳ６０４７で、他の通学基本ルートのグループにも、高学年児童が含まれていない場合には（Ｓ６０４７→Ｎｏ）、帰宅ルート検索部１５３は、パトロール員ＤＢ２６０を参照して、引率可能なパトロール員が存在するか否かを判別する（Ｓ６０４９）。具体的には、パトロール員ＤＢ２６０のパトロール員マスタテーブル２６０１の対応エリア、可能日時、頻度ＩＤと、パトロール員スケジュールテーブル２６０３を検索して、引率可能なパトロール員を検出する。引率可能なパトロール員が存在した場合には（Ｓ６０４９→Ｙｅｓ）、当該パトロール員に、パトロール員ＤＢ２６０を参照して引率依頼を通知し（Ｓ６０５０）、処理を終了する。この場合、パトロール員端末９００にメールを送信してもよいし、緊急を要する場合には、コーディネータが電話などで通知してもよい。

一方、ステップＳ６０４９で、引率可能なパトロール員が存在しない場合には（Ｓ６０４９→Ｎｏ）、帰宅ルート検索部１５３は、パトロール員ＤＢ２６０を参照してパトロール員にパトロール強化依頼をメールなどで通知し（Ｓ６０５１）、処理を終了する。これにより、パトロール員は、当該ルート周辺のパトロールを通常よりも強化する。また、当日活動予定でないが活動可能なパトロール員へ通知して、パトロール員を増やしてもよい。さらに、地元の警察などに連絡して、防犯体制をさらに強化させることも考えられる。
また、児童の移動時間を、児童の歩く早さと距離から算出して予測し、帰宅ルート付近のパトロール員や「子ども１１０番の家」の住民などに対し、例えば「１８時３０分に○○バス停付近にパトロール願う」などのメッセージを通知してもよい。それにより、児童の帰宅時の安全性をさらに強化することができる。

なお、本実施形態では、ステップＳ６０４５のように、帰宅ルートに変更が発生した時にのみ、パトロール員端末９００に通知することとして説明したが、これに限らず、パトロール員の希望により、通常のパトロールの際にも、パトロール員スケジュールテーブル２６０３を参照して、当日パトロールの活動を行うこととなっているパトロール員端末９００にその都度通知することとしてもよい。
また、帰宅ルートの数をコーディネータが設定した上で、最適ルート検索処理を行ってもよいし、当日のパトロール員の活動状況などを加味した上で帰宅ルートの数を増減させてもよい。

この帰宅ルート検索は、児童見守りサービスからの帰宅の際だけでなく、通常の学校授業が終了した際の集団下校時などにも適用することができる。また、前記した帰宅ルート検索は、外部の不審者関連システムと連携可能にして、不審者発生時には、不審者が発生した場所および近辺を通らないようなルートを検索してもよい。

Ｇ．帰宅登録処理
児童は、帰宅時刻（予定）になったら、帰宅登録手続を行って帰宅する。帰宅登録手続は、具体的には、前記した出席登録手続と同様に、児童が自身の名札をリーダ３００にかざすことで行われる。図２７は、サーバの帰宅登録処理を示すフローチャートである。図２７に沿って、適宜図１〜図３、図８を参照しながら説明する。

児童が名札をリーダ３００にかざすことにより、ＩＣタグ４００の記憶部４０１に記憶される児童ＩＤが、リーダ３００のタグ情報取得部３０１に取得され、取得した児童ＩＤの情報が、リーダ３００の通信処理部３０２からサーバ１に帰宅登録要求として送信される。これにより、サーバ１は帰宅登録要求を受信する（Ｓ７００）。
なお、サーバ１がリーダ３００から受信した児童ＩＤが、帰宅登録要求か出席登録要求かの判別は、例えば、サーバ１の出欠処理部１４０が出席簿テーブル２５０１の当該児童ＩＤの到着時刻（実績）を参照することで判別してもよい。また、別の方法として、ＩＣタグ４００に出席フラグを設け、かつ、リーダ３００に、ＩＣタグ４００への書き込み機能を持たせることとしてもよい。具体的には、リーダ３００は、ＩＣタグ４００から出席フラグ「オフ」の情報を取得した場合には、これから行うのは出席登録要求であると判別し、サーバ１へは児童ＩＤと共に出席フラグ「オン」の情報を送信する（出席登録要求）。そして、ＩＣタグ４００の出席フラグに「オン」を書き込む。
一方、ＩＣタグ４００から出席フラグ「オン」の情報を取得した場合には、これから行うのは帰宅登録要求であると判別し、サーバ１へは児童ＩＤと共に出席フラグ「オフ」の情報を送信する（帰宅登録要求）。そして、ＩＣタグ４００の出席フラグに「オフ」を書き込む。これにより、サーバ１は、リーダ３００から受信した情報が出席登録要求か、帰宅登録要求かを判別可能となる。

サーバ１の帰宅登録部１４５は、出席簿テーブル２５０１において、受信した児童ＩＤの帰宅時刻（実績）に、ステップＳ７００で帰宅登録要求を受信した時刻を登録する（Ｓ７０１）。

これによれば、児童の帰宅時刻（実績）が記憶されるので、もし児童の帰宅が遅くなった場合でも、施設を何時に出発したかを把握することができる。

以上説明した児童見守りサービス支援システムＳによれば、入会登録処理（Ａ）において、児童見守りサービスへの入会手続を行う。イベント登録処理（Ｂ）において、児童見守りサービスを行う施設で開催されるイベントを登録する。参加登録処理（Ｃ）において、児童見守りサービスへの日毎の児童の参加（出席）登録手続を行う。情報変更処理（Ｄ）において、参加登録の情報を修正する。出席登録処理（Ｅ）において、児童の出席情報を登録する。帰宅準備処理（Ｆ）において、児童の帰宅準備を促し、また、必要に応じて帰宅ルートを変更し、児童や関係者に通知する。帰宅登録処理（Ｇ）において、児童の帰宅情報を登録する。
これにより、管理対象者である児童の行動や、関係者の活動を一括して管理することで、事務処理の負担を軽減し、帰宅時における児童の安全を確保することができる。

なお、児童見守りサービス支援システムＳにおいて、保護者、コーディネータ、指導員が用いる端末は、一般的なコンピュータを例として説明したが、これに限らず、携帯端末を用いてもよい。それによれば、迅速な情報の伝達が可能となるので、柔軟な防犯体制をとることが容易となる。

また、図３に示すサーバ１で実行される処理部１００および記憶部２００を、コンピュータにより読み取り可能な記録媒体に記録し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、本発明の実施形態に係る情報処理システムが実現されるものとしてもよい。

以上、本発明の好適な実施の形態について一例を示したが、本発明は前記した実施形態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
例えば、コーディネータが操作するコーディネータ端末７００は１台に限らず、複数台設置し、それぞれのコーディネータ端末７００からコーディネータが必要に応じて利用できるようにしてもよい。また、コーディネータが指導員の役割を担うことも考えられ、その場合にはコーディネータ端末７００と指導員端末８００は同一のコンピュータで実現可能である。

また、本実施形態では、監視対象者として小学校に通う児童を例として説明したが、これに限らず、保育園や幼稚園に通う子どもや、中学生、高校生にも適用可能である。

本実施形態における児童見守りサービス支援システムの構成を示す図である。 本実施形態における児童見守りサービス支援システムの処理概要を示すシーケンス図である。 本実施形態におけるサーバの機能ブロックと、サーバにネットワークを介して接続される各端末の構成を示す図である。 記憶部の個人情報ＤＢ内に格納されるテーブルの例を示す図である。 記憶部のイベントＤＢ内に格納されるテーブルの例を示す図である。 記憶部の施設ＤＢ内に格納されるテーブルの例を示す図である。 記憶部の指導員ＤＢ内に格納されるテーブルの例を示す図である。 記憶部の参加登録ＤＢ内に格納されるテーブルの例を示す図である。 記憶部のパトロール員ＤＢ内に格納されるテーブルの例を示す図である。 サーバの入会登録処理を示すフローチャートである 入会登録処理時に保護者端末６００に表示される画面の一例である。 サーバのイベント登録処理を示すフローチャートである。 イベント登録処理時にコーディネータ端末に表示される画面の一例である。 各指導員の意欲を検索条件に加味して行う場合の処理を示すフローチャートである。 サーバの参加登録処理を示すフローチャートである。 参加登録処理時に保護者端末に表示される画面の一例である。 サーバの情報変更処理を示すフローチャートである。 情報変更処理時に保護者端末に表示される画面の一例である。 保護者端末のデスクトップ上に表示されたカレンダー形式の参加登録情報を示す図である。 サーバの出席登録処理を示すフローチャートである。 出席登録処理において、参加予定となっていない児童ＩＤを受信した場合に、出席登録部がコーディネータ端末に表示させる画面の一例を示す図である。 出席登録処理において、帰宅時刻（予定）が登録済みで無かった場合に、帰宅時刻登録部がコーディネータ端末に表示させる画面の一例を示す図である。 サーバの帰宅準備処理を示すフローチャートである。 帰宅準備処理において、コーディネータ端末に表示される画面の一例と、児童への通知を示す図である。 サーバの帰宅ルート検索処理を示すフローチャートである。 帰宅ルート検索処理において、コーディネータ端末に表示される画面の一例を示す図である。 サーバの帰宅登録処理を示すフローチャートである。

符号の説明

１ サーバ
１００ 処理部
１１０ 入会処理部
１２０ イベント登録処理部
１３０ 参加登録処理部
１４０ 出欠処理部
１５０ 帰宅準備処理部
１６０ 通信処理部
２００ 記憶部
２１０ 個人情報ＤＢ
２２０ イベントＤＢ
２３０ 施設ＤＢ
２４０ 指導員ＤＢ
２５０ 参加登録ＤＢ
２６０ パトロール員ＤＢ
２７０ 地図ＤＢ
３００ リーダ
３０１ タグ情報取得部
３０２ 通信処理部
４００ ＩＣタグ
４０１ 記憶部
５００ 児童端末
６００ 保護者端末
７００ コーディネータ端末
８００ 指導員端末
９ ネットワーク
９００ パトロール員端末
Ｓ 児童見守りサービス支援システム（情報処理システム）

Claims (10)

1. 受信した管理対象者の帰宅ルートおよび前記管理対象者が携帯する端末のアドレスの情報を少なくとも含む個人情報を、前記管理対象者を一意に識別する識別情報と対応させて個人情報データベースに登録する入会処理部と、
   前記識別情報に対応する管理対象者の所定のサービスへの参加予定情報を受信して、当該識別情報と対応させて参加登録データベースに登録する参加登録処理部と、
   前記管理対象者が携帯し当該管理対象者の識別情報を記憶する記憶媒体から、前記識別情報を取得する識別情報取得部と、
   前記識別情報取得部が取得した識別情報を受信し、前記参加予定情報と照合して、当該管理対象者の前記サービスへの出席情報として前記参加登録データベースに登録する出欠処理部と、
   前記個人情報データベースの帰宅ルートが同じ識別情報のグループ毎に、前記参加登録データベースを参照し、帰宅ルート検索処理を必要とする条件が満たされた場合に、所定のルート検索条件に基づいて前記帰宅ルート検索処理を実行し、実行結果である最適帰宅ルートを、当該グループに所属する管理対象者の携帯する端末のアドレスへ通知し、
   地域の防犯のためにパトロールを行うパトロール員の、パトロール可能エリア、活動可能日、活動可能頻度、および前記パトロール員の使用するパトロール員端末のアドレスの情報を少なくとも含むパトロール員データベースを参照することで、前記パトロール可能エリア、活動可能日および活動可能頻度の情報と、前記最適帰宅ルートとに基づいて、パトロールを行うパトロール員を選択し、パトロール員の使用するパトロール員端末のアドレスへ前記最適帰宅ルートを通知する帰宅準備処理部
   を備えることを特徴とする情報処理システム。
2. 前記管理対象者とは、児童であること
   を特徴とする請求項１に記載の情報処理システム。
3. 前記個人情報は、児童の所属する学年の情報をさらに含み、
   前記所定のルート検索条件とは、
   出発地から最も離れている高学年児童宅を最終目的地とした最短距離
   であることを特徴とする請求項２に記載の情報処理システム。
4. 前記帰宅ルート検索処理を必要とする条件とは、前記個人情報データベースの帰宅ルートが同じ識別情報のグループ毎に、前記参加登録データベースについて下記（１）〜（３）のうち少なくとも１つが満たされなかった場合であることを特徴とする請求項１ないし請求項３のいずれか一項に記載の情報処理システム。
   （１）グループ内の全識別情報に出席情報が登録されている
   （２）グループ内の全識別情報の参加予定情報に含まれる帰宅予定時刻が同じ
   （３）グループ内の全識別情報の参加予定情報に含まれる迎えの有無の情報が無し
5. 前記参加登録処理部は、
   前記参加登録データベースの前記参加予定情報に含まれる帰宅予定時刻の所定時間前に、前記管理対象者の携帯する端末のアドレスへアラートを通知する帰宅アラート送信指示部
   をさらに備えることを特徴とする請求項１ないし請求項４のいずれか一項に記載の情報処理システム。
6. 前記サービスで開催されるイベント毎に、前記イベントで指導を行う指導員に必要な要件の情報を少なくとも含むイベントデータベースと、
   指導員毎に、活動可能日、活動可能頻度、保有する要件、前記指導員が使用する指導員端末のアドレスの情報を少なくとも含む指導員データベースとを備え、
   前記イベントの開催予定情報を受信したとき、前記開催予定情報に含まれる開催日時と、前記指導員データベースから取得した活動可能日および活動可能頻度との照合を行い、指導員の保有する要件と、前記イベントデータベースから取得した当該イベントで指導を行う指導員に必要な要件との照合を行うことで、前記イベントで指導を行う指導員を選択し、前記選択された指導員の使用する指導員端末のアドレスへ指導依頼を通知するイベント登録処理部
   をさらに備えることを特徴とする請求項１ないし請求項５のいずれか一項に記載の情報処理システム。
7. 前記参加登録データベースは、前記管理対象者の前記イベントへの参加予定情報をさらに含み、
   前記参加登録処理部は、
   受信した前記管理対象者の前記イベントへの参加予定情報を前記識別情報と対応させて前記参加登録データベースに登録する機能
   をさらに備えることを特徴とする請求項６に記載の情報処理システム。
8. 前記イベント登録処理部は、
   ネットワーク経由で通信可能に接続される施設予約システムに格納されている情報を取得することで、前記イベントを行う施設として情報を共有すること
   を特徴とする請求項６または請求項７に記載の情報処理システム。
9. 前記帰宅準備処理部は、
   ネットワーク経由で不審者関連情報を取得することで、前記不審者関連情報を前記所定のルート検索条件に加えて、前記帰宅ルート検索処理を実行すること
   を特徴とする請求項１ないし請求項８のいずれか一項に記載の情報処理システム。
10. サーバと、管理対象者が携帯する端末と、地域の防犯の為にパトロールを行うパトロール員が使用するパトロール員端末とを少なくとも含んで構成され、ネットワークを介して通信される情報処理システムに用いられる前記サーバの情報処理方法であって、
    受信した管理対象者の帰宅ルートおよび前記管理対象者が携帯する端末のアドレスの情報を少なくとも含む個人情報を、前記管理対象者を一意に識別する識別情報と対応させて個人情報データベースに登録し、
    前記識別情報に対応する管理対象者の所定のサービスへの参加予定情報を受信して、当該識別情報と対応させて参加登録データベースに登録し、
    前記管理対象者が携帯し当該管理対象者の識別情報を記憶する記憶媒体から、前記識別情報を取得し、
    前記取得した識別情報を受信し、前記参加予定情報と照合して、当該管理対象者の前記サービスへの出席情報として前記参加登録データベースに登録し、
    前記個人情報データベースの帰宅ルートが同じ識別情報のグループ毎に、前記参加登録データベースを参照し、帰宅ルート検索処理を必要とする条件が満たされた場合に、所定のルート検索条件に基づいて前記帰宅ルート検索処理を実行し、実行結果である最適帰宅ルートを、当該グループに所属する管理対象者の携帯する端末のアドレスへ通知し、
    地域の防犯のためにパトロールを行うパトロール員の、パトロール可能エリア、活動可能日、活動可能頻度、および前記パトロール員が使用するパトロール員端末のアドレスの情報を少なくとも含むパトロール員データベースを参照することで、前記パトロール可能エリア、活動可能日および活動可能頻度の情報と、前記最適帰宅ルートとに基づいて、パトロールを行うパトロール員を選択し、パトロール員の使用するパトロール員端末のアドレスへ前記最適帰宅ルートを通知する
    ことを特徴とする情報処理方法。

Images