JP6939849B2 - 管理装置および管理方法 - Google Patents

Description

本発明の実施形態は、管理装置および管理方法に関する。

従来、所定の目的を達成するために複数のユーザが参加するシステムを管理する管理装置がある。この種のシステムとして、例えば、農作物に被害を及ぼすイノシシやシカ等の害獣を猟師が捕獲した場合に自治体等に申請することで報奨金を得るシステムがある。

特開２００１−１４８９５７号公報

しかしながら、従来のシステムでは、ユーザの利便性について更なる改善の余地があった。

本発明が解決しようとする課題は、ユーザの利便性を向上させることができる管理装置および管理方法を提供することを目的とする。

実施形態に係る管理装置は、受付部と、発行部と、管理部とを具備する。前記受付部は、ユーザから所定のアプリケーションを介して、前記ユーザが利用可能な機能が異なる複数の集団それぞれへの加入情報を受け付ける。前記発行部は、前記機能が異なる複数の集団それぞれに対応した識別情報を発行する。前記管理部は、前記受付部によって受け付けられた前記加入情報に前記識別情報を紐づけ、前記ユーザを前記複数の集団それぞれに登録して管理する。

図１は、実施形態に係る支援システムの構成例を示す図である。 図２は、実施形態に係る管理装置の構成例を示すブロック図である。 図３は、機能情報の一例を示す図である。 図４は、コミュニティ情報の一例を示す図である。 図５は、グループ情報の一例を示す図である。 図６は、ユーザ情報の一例を示す図である。 図７は、申請情報の一例を示す図である。 図８は、アプリケーションにより提供される画面を示す図である。 図９は、コミュニティへの加入処理を示す図である。 図１０は、グループへの加入処理を示す図である。 図１１は、報奨金の申請処理を示す図である。 図１２は、実施形態に係る支援システムＳのコミュニティ登録処理の処理手順を示すシーケンス図である。 図１３は、実施形態に係る支援システムＳのグループ登録処理の処理手順を示すシーケンス図である。

以下で説明する実施形態に係る管理装置１は、受付部３１と、管理部３３とを具備する。受付部３１は、ユーザから所定のアプリケーションを介して、ユーザが使用可能な機能が異なる複数の集団それぞれへの加入情報を受け付ける。管理部３３は、受付部３１によって受け付けられた加入情報に基づいて、ユーザを複数の集団それぞれに登録して管理する。

以下で説明する実施形態に係る管理部３３は、複数の集団として、所定の申請を行う申請機能を利用可能な集団と、申請機能を利用できない集団とを管理する。

以下で説明する実施形態に係る管理部３３は、申請機能を利用可能な一の集団の中で、申請機能によって行った申請を承認する承認機能を利用可能な承認集団を管理する。

以下で説明する実施形態に係る管理部３３は、申請機能を利用できない集団を、当該集団に属するユーザ間での情報共有機能を利用可能な集団として管理する。

以下で説明する実施形態に係る管理部３３は、ユーザ属性に応じた加入条件が異なる複数の集団を管理する。

以下で説明する実施形態に係る管理部３３は、集団に属するユーザが共有可能な情報が異なる複数の集団を管理する。

以下、図面を参照して、実施形態に係る管理装置および管理方法について説明する。実施形態において同一の部位には同一の符号を付し、重複する説明は省略される。

図１は、実施形態に係る支援システムの構成例を示す図である。図１に示す支援システムＳは、害獣等の捕獲対象となる動物を捕獲した猟師（ユーザの一例）による自治体への報奨金の申請および自治体における報奨金に関する情報の管理等を支援するためのシステムである。なお、本実施形態では、捕獲動物に対する報奨金の申請を行うための支援システムＳを一例として挙げるが、これに限らず、複数のユーザが所定の目的のために加入するシステムであれば任意のシステムを採用可能である。

図１に示すように支援システムＳは、管理装置１と、複数の端末装置１０と、自治体端末１００とを有する。また、管理装置１、端末装置１０および自治体端末１００は、所定のネットワークＮを介して通信可能に接続されている。

管理装置１は、支援システムＳに加入しているユーザ（猟師や農家）の情報や、報奨金の申請に関する情報を管理するサーバである。管理装置１は、各ユーザの端末装置１０に対して支援システムＳの各機能を利用するための所定のアプリケーションを配信する。

端末装置１０は、ユーザが所持する端末である。例えば、端末装置１０は、スマートフォン、タブレットおよびデジタルカメラ等の携帯型の端末装置である。端末装置１０は、管理装置１からダウンロードしたアプリケーションを介して、支援システムＳにおける各機能を利用する。なお、端末装置１０を扱うユーザは、猟師に限らず、農家や、自治体の職員、他業種のユーザであってもよい。つまり、支援システムＳに加入可能なユーザは、報奨金の申請を行うユーザ（猟師）に限らず、報奨金の申請を行わないユーザ（農家等）であってもよい。また、猟師が捕獲する動物は、報奨金の対象となる動物であるイノシシや、シカ、鳥類等の害獣であるが、これに限らず、報奨金とは無関係に捕獲対象となる動物であってもよい。

自治体端末１００は、報奨金の申請を承認する自治体に設置され、自治体の職員が扱う端末装置である。例えば、自治体端末１００は、デスクトップ型や、ノート型のＰＣ（Personal Computer）である。自治体端末１００は、管理装置１や、端末装置１０から報奨金の申請に関する各種情報を取得する。

ここで、支援システムＳにおける報奨金の申請処理の流れについて説明する。支援システムＳでは、まず、猟師は、害獣を捕獲した場合、端末装置１０のアプリケーションを起動し、アプリケーションのカメラ機能を使って害獣の全体または一部を撮影する。つづいて、猟師は、報奨金を申請するための情報として、撮像日時や、撮像場所等を画像に付加した申請情報を、アプリケーションを介して管理装置１へ送信する。管理装置１は、猟師の端末装置１０から受信した申請情報を猟師の識別情報と紐付けて記憶する。また、管理装置１は、申請情報に紐付くシリアルナンバー（例えば、図７に示す申請ＩＤ等）を発行し、申請情報と紐付けて記憶するとともにシリアルナンバーを端末装置１０へ通知する。また、猟師は、捕獲した害獣の一部（例えば、尻尾等）を証憑物として、管理装置１から通知されたシリアルナンバーとともに自治体へ提出する。自治体は、証憑物およびシリアルナンバーを猟師から受け付けた場合、自治体端末１００を介して管理装置１へシリアルナンバーの照合を依頼する。管理装置１は、自治体端末１００から送信されてきたシリアルナンバーと、管理装置１が記憶しているシリアルナンバーとを照合し、照合結果を自治体端末１００へ送信する。そして、自治体の職員は、シリアルナンバーが一致していた場合、報奨金の申請を承認し、承認する旨および報奨金の支払いが完了した旨の情報を管理装置１へ通知する。そして、管理装置１は、自治体端末１００から送信された情報に基づいて申請情報を更新する。

ここで、従来の支援システムは、上記した報奨金の申請を行うためのシステムに過ぎないため、ユーザにとって利便性が高いとは言えず、改善の余地があった。つまり、従来の支援システムは、猟師の報奨金申請に特化したシステムであり、猟師以外のユーザにとっては利用価値が高いものではなかった。より広義に言えば、従来のシステムは、所定の目的を行うために加入した複数のユーザにとって、所定の目的を行うための機能に特化していることから、他のユーザにとって利便性が高いとは言えなかった。

そこで、実施形態に係る管理方法では、ユーザが利用可能な機能が異なる複数の集団を設定し、各ユーザを複数の集団それぞれに登録して管理する。以下では、「集団」を、「コミュニティ」、「サブコミュニティ」および「グループ」と記載することとする。図１を用いて、実施形態に係る管理方法について具体的に説明する。

なお、図１では、自治体および猟師を含む集団（以下、コミュニティ）と、農家および猟師を含む集団（以下、グループ）とが設定されることとする。各ユーザは、コミュニティおよびグループに加入する場合に、端末装置１０からアプリケーションを介して管理装置１へ加入情報を送信する。加入情報には、例えば、ユーザ個人に関する情報（氏名や、住所、業種等）や、加入したいコミュニティまたはグループの情報が含まれる。そして、管理装置１は、受け付けた加入情報に基づいて、各ユーザをコミュニティおよびグループに登録して管理する。

図１に示す例において、「コミュニティ」および「グループ」は、ユーザが利用可能な機能が異なる集団である。具体的には、「コミュニティ」は、自治体へ報奨金の申請を行う申請機能を利用可能な集団であり、「グループ」は、自治体へ報奨金の申請を行う申請機能を利用できない集団である。また、「グループ」は、「グループ」に属するユーザ間での情報共有機能を利用可能なグループである。また、「コミュニティ」は、自治体を介し自治体が把握したユーザにのみＩＤが発行され、「グループ」は、すべてのユーザに対してＩＤを発行可能である。つまり、「コミュニティ」は、限定したユーザーのみで構成されるのに対し、「グループ」は、構成するユーザの制限がない（誰でも作成、参加できる）。すなわち、「コミュニティ」の機能は、限定したユーザのみが利用可能であり、「グループ」の機能は、加入されすれば、あらゆるユーザが利用可能である。換言すれば、「コミュニティ」および「グループ」は、機能を利用するためにユーザに課される条件（加入条件）が異なる。なお、「コミュニティ」および「グループ」で利用可能な機能や、加入条件等については、図３〜図５で後述する。

これにより、例えば、猟師Ａおよび猟師Ｂは、「コミュニティ」に属することで、自治体へ報奨金の申請を行うことができ、さらに、猟師Ａ、猟師Ｂおよび農家は、「グループ」に属することで、他の猟師や農家等との間で狩猟に関する情報等を共有できる。また、報奨金の申請を行わない農家は、「グループ」に加入して猟師との情報共有が可能となることで、例えば、害獣の出現を猟師に知らせたり、現在の狩猟の状況等を猟師から聞いたりできる。

すなわち、実施形態に係る管理方法では、ユーザが利用可能な機能が異なる複数のグループを管理することで、支援システムＳでユーザが利用可能な機能が拡張する。これにより、例えば、報奨金の申請を行わないユーザにとっても、報奨金の申請を行うユーザにとっても、利便性を高めることができる。

なお、上記した複数の集団（コミュニティおよびグループ）の機能は、あくまでも一例である。なお、複数の集団の他の機能については、後述する。また、集団の種類数は、２つ（コミュニティおよびグループ）に限定されず、３つ以上の集団であってもよい。さらに、一の集団の中に、複数の集団（後述するサブコミュニティ）が存在してもよいが、かかる点の詳細については後述する。

次に、図２を用いて、実施形態に係る管理装置１の構成について説明する。図２は、実施形態に係る管理装置１の構成例を示すブロック図である。図２に示すように、管理装置１は、通信部２と、制御部３と、記憶部４とを具備する。

通信部２は、無線通信処理や有線通信処理を行うためのネットワークデバイスである。例えば、通信部２は、図１に示したネットワークＮを介して端末装置１０や、自治体端末１００との間で各種情報を送受信する。

記憶部４は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、又は、ハードディスク、光ディスク等の記憶装置によって実現される。実施形態に係る記憶部４は、機能情報４１と、コミュニティ情報４２と、グループ情報４３と、ユーザ情報４４と、申請情報４５とを記憶する。

ここで、記憶部４が記憶する機能情報４１、コミュニティ情報４２、グループ情報４３、ユーザ情報４４および申請情報４５について説明する。

機能情報４１は、各グループにおいて、ユーザが利用可能な機能の内容に関する情報である。図３は、機能情報４１の一例を示す図である。図３に示すように、機能情報４１は、「単位」、「機能」といった項目を有する。

「単位」は、集団の単位を示す情報である。「機能」は、ユーザが利用可能な機能を示す情報である。

図３に示す例において、ユーザは、「コミュニティ」に加入した場合、「報奨金最終申請」機能および「申請情報閲覧」機能を利用可能となる。また、ユーザは、「サブコミュニティ」に加入した場合、「報奨金１次申請」機能を利用可能となる。また、ユーザは、「グループ」に加入した場合、「狩猟情報共有」機能、「罠情報共有」機能および「チャット機能」を利用可能となる。

「報奨金最終申請」は、報奨金を得るための最終的な申請を行うことができる機能である。「申請情報閲覧」は、後述する申請情報４５を閲覧できる機能である。「報奨金１次申請」は、報奨金を得るための１次申請を行うことができる機能である。「狩猟情報供給」機能は、狩猟情報を共有できる機能である。狩猟情報とは、例えば、捕獲対象の害獣の出現情報（出現報告や、出現場所、出現時間、動物種等）や、猟師の狩猟スケジュール情報（狩猟を行う日、場所、時間等）等といった情報である。「罠情報共有」機能は、罠情報を供給できる機能である。罠情報とは、猟師が設置した罠に関する情報（設置位置や、罠の種類、捕獲の有無）である。「チャット機能」は、他のユーザとチャットできる機能である。なお、「報奨金最終申請」機能および「報奨金１次申請」機能を利用した報奨金の申請処理については後述する。

なお、図３に示す集団の単位および機能は、あくまでも一例である。集団の単位が２つであってもよく、４つ以上であってもよい。

次に、コミュニティ情報４２は、集団の単位である「コミュニティ」および「サブコミュニティ」に関する情報である。図４は、コミュニティ情報４２の一例を示す図である。図４に示すように、コミュニティ情報４２は、「コミュニティＩＤ」、「サブコミュニティＩＤ」、「加入条件」および「加入者数」といった項目を有する。

「コミュニティＩＤ」は、各コミュニティを識別する識別情報である。「サブコミュニティＩＤ」は、各サブコミュニティを識別する識別情報である。「加入条件」は、コミュニティまたはサブコミュニティへの加入条件に関する情報である。「加入者数」は、コミュニティまたはサブコミュニティへの加入者数に関する情報である。

図４に示す例において、コミュニティＩＤ「Ｃ１」で識別されるコミュニティは、サブコミュニティＩＤ「ＳＣ１１」および「ＳＣ１２」で識別される２つのサブコミュニティを含んで構成される。また、コミュニティＩＤ「Ｃ１」で識別されるコミュニティへ加入するためには、「○○市の猟師」であることが加入条件となる。また、コミュニティＩＤ「Ｃ１」で識別されるコミュニティは、サブコミュニティＩＤ「ＳＣ１１」のサブコミュニティに「３０」人の猟師が加入しており、サブコミュニティＩＤ「ＳＣ１２」のサブコミュニティに「５０」人の猟師が加入している。つまり、コミュニティＩＤ「Ｃ１」のコミュニティには、合計８０人の猟師が加入していることを示している。

また、図４に示す例において、コミュニティＩＤ「Ｃ２」で識別されるコミュニティは、サブコミュニティを有さないコミュニティであり、「○○県の猟師」が「５００」人加入していることを示している。

次に、グループ情報４３は、集団の単位である「グループ」に関する情報である。図５は、グループ情報４３の一例を示す図である。図５に示すように、グループ情報４３は、「グループＩＤ」、「加入条件」および「加入者数」といった項目を有する。

「グループＩＤ」は、各グループを識別する識別情報である。「加入条件」は、グループへの加入条件に関する情報である。「加入者数」は、グループへの加入者数に関する情報である。

図５に示す例において、グループＩＤ「Ｇ１」で識別されるグループは、加入条件が無く、誰でも加入可能であり、「４０」人のユーザが加入していることを示す。また、図５に示す例において、グループＩＤ「Ｇ２」で識別されるグループは、「○○地区」の「１５」人のユーザが加入していることを示す。

次に、ユーザ情報４４は、ユーザに関する情報である。図６は、ユーザ情報４４の一例を示す図である。図６に示すように、ユーザ情報４４は、「ユーザＩＤ」、「業種」および「所属先」といった項目を有する。

「ユーザＩＤ」は、ユーザを識別する識別情報である。「業種」は、ユーザの業種に関する情報である。「所属先」は、ユーザの所属先（コミュニティ、サブコミュニティおよびグループ）に関する情報である。

図６に示す例において、ユーザＩＤ「Ｕ１」で識別されるユーザは、「猟師」であり、所属先が、コミュニティＩＤ「Ｃ１」のコミュニティ、サブコミュニティＩＤ「ＳＣ１１」のサブコミュニティおよびグループＩＤ「Ｇ１」のグループであることを示している。

また、図６に示す例において、ユーザＩＤ「Ｕ２」で識別されるユーザは、「猟師」であり、所属先が、コミュニティＩＤ「Ｃ１」および「Ｃ２」のコミュニティ、サブコミュニティＩＤ「ＳＣ１２」のサブコミュニティおよびグループＩＤ「Ｇ２」のグループであることを示している。つまり、ユーザＩＤ「Ｕ２」で識別されるユーザは、複数のコミュニティに属している。

また、図６に示す例において、ユーザＩＤ「Ｕ３」で識別されるユーザは、「農家」であり、所属先が、グループＩＤ「Ｇ２」のグループであることを示している。つまり、ユーザＩＤ「Ｕ３」で識別されるユーザは、コミュニティおよびサブコミュニティの加入条件に合致していないため、コミュニティおよびサブコミュニティには加入していない。

次に、申請情報４５は、猟師であるユーザから送信される情報であり、報奨金を申請するための情報である。図７は、申請情報４５の一例を示す図である。図７に示すように、申請情報４５は、「申請ＩＤ」、「申請先ＩＤ」、「ユーザＩＤ」、「位置情報」、「捕獲個体情報」、「承認」および「支払い」といった項目を有する。

「申請ＩＤ」は、各申請情報４５を識別する識別情報である。「申請先ＩＤ」は、申請先となるコミュニティおよびサブコミュニティの識別情報を示す情報である。「ユーザＩＤ」は、申請者であるユーザを識別する識別情報である。「位置情報」は、捕獲個体を捕獲した位置情報である。「捕獲個体情報」は、捕獲個体に関する情報である。「承認」は、申請先のコミュニティおよびサブコミュニティの承認状態を示す図である。「支払い」は、自治体が猟師に対して報奨金を支払い済みであるか否かを示す情報である。

図７に示す例において、申請ＩＤ「Ａ１」で識別される申請情報４５は、ユーザＩＤ「Ｕ１」のユーザが送信した情報であり、「イノシシ、メス、・・・」を位置情報「＃１」で捕獲したことを示している。なお、位置情報「＃１」は、例えば、緯度経度によって表すことができる。また、申請ＩＤ「Ａ１」で識別される申請情報４５は、サブコミュニティＩＤ「ＳＣ１１」のサブコミュニティによる承認およびコミュニティＩＤ「Ｃ１」のコミュニティによる承認が完了し、報奨金を支払い済みであることを示している。

また、図７に示す例において、申請ＩＤ「Ａ２」で識別される申請情報４５は、サブコミュニティによる承認が無く、コミュニティＩＤ「Ｃ２」のコミュニティによる承認が完了し、報奨金の支払いが終わっていないことを示している。

また、図７に示す例において、申請ＩＤ「Ａ３」で識別される申請情報４５は、サブコミュニティＩＤ「ＳＣ１１」のサブコミュニティによる承認が完了しているものの、コミュニティＩＤ「Ｃ１」のコミュニティによる承認が完了していないため、報奨金の支払いが終わっていないことを示している。

制御部３は、各種の処理手順等を規定したプログラム及び所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部３は、受付部３１、発行部３２、管理部３３および申請部３４を具備する。

受付部３１は、ユーザ（端末装置１０）や自治体（自治体端末１００）から各種情報を受け付ける。例えば、受付部３１は、ユーザから所定のアプリケーションを介して、複数の集団（コミュニティ、サブコミュニティおよびグループ）それぞれへの加入情報を受け付ける。加入情報には、例えば、ユーザ個人に関する情報（氏名や、住所、業種等）や、加入したいコミュニティまたはグループの情報（例えば、ＩＤ）が含まれる。

また、受付部３１は、ユーザ（端末装置１０）や自治体（自治体端末１００）から各種要求を受け付ける。例えば、受付部３１は、ユーザ（端末装置１０）や自治体（自治体端末１００）から、申請情報４５の閲覧要求を受け付ける。

発行部３２は、各識別情報（ＩＤ）を発行する例えば、発行部３２は、ユーザが利用可能な機能が異なる複数の集団それぞれに対応した識別情報を発行する。具体的には、発行部３２は、コミュニティＩＤおよびグループＩＤを発行する。また、発行部３２は、端末装置１０から加入情報を受け付けた場合に、加入情報と紐付くユーザＩＤを発行する。

管理部３３は、受付部３１によって受け付けられた加入情報に基づいて、ユーザを複数の集団それぞれに登録して管理する。具体的には、管理部３３は、加入情報に含まれるユーザ個人の情報をユーザ情報４４として記憶するとともに、加入情報に基づいてユーザが加入したい集団（コミュニティ、サブコミュニティおよびグループ）を特定し、かかる集団の識別情報（ＩＤ）をユーザ情報４４に紐付ける。これにより、コミュニティや、サブコミュニティ、グループへのユーザの登録が完了する。そして、管理部３３は、登録が完了した場合には、登録した集団の機能（図３参照）を端末装置１０で利用可能となったことをユーザへ通知する。

また、管理部３３は、コミュニティに登録したユーザや自治体から「申請情報閲覧」機能を使って申請情報４５の閲覧要求を受け付けた場合、ユーザや自治体に対して申請情報４５を送信する。例えば、管理部３３は、自治体へ申請情報４５を送信する場合、当該自治体を申請先とする申請情報４５をすべて送信してもよく、あるいは、自治体から申請情報４５の指定（例えば、未承認や、未支払いの状態の申請情報４５等）があった場合には、指定された申請情報４５のみを送信してもよい。

また、管理部３３は、ユーザへ申請情報４５を送信する場合、当該ユーザが申請した申請情報４５のみを送信してもよく、当該ユーザが所属する集団の申請情報４５を送信してもよい。

なお、図３に示したように、管理部３３は、コミュニティ、サブコミュニティおよびグループを管理する。具体的には、管理部３３は、所定の申請（報奨金の申請）を行う申請機能を利用可能な集団（コミュニティおよびサブコミュニティ）と、申請機能を利用できない集団（グループ）とを管理する。これにより、農家等の報奨金申請を行わないユーザにとっては、不要な申請機能を利用できないようにすることで、アプリケーションの機能が無駄に複雑にならないようにできる。このため、アプリケーションに不慣れなユーザであっても抵抗感無くアプリケーションを使用することができる。

さらに、図３に示したように、管理部３３は、報奨金の申請機能を利用できないグループについては、当該グループに属するユーザ間での情報共有機能を利用可能なグループとして管理する。これにより、例えば、農家等の報奨金を申請しないユーザにとっても、グループに加入することで、猟師から有用な猟師情報を得られるため、例えば、害獣対策を的確に行うことができるようになる。

また、コミュニティおよびグループの関係で見た場合、管理部３３は、集団に属するユーザが共有可能な情報が異なる複数の集団、具体的には、管理装置１が有する申請情報４５を共有可能なコミュニティと、各ユーザが有する情報（狩猟情報や罠情報）を共有可能なグループとを管理する。これにより、新たな情報共有を実現できるとともに、集団毎に共有できる情報を限定することで、情報が不必要に拡散しすぎることを防止できる。

また、図４に示すように、管理部３３は、コミュニティおよびサブコミュニティの関係のように、申請機能を利用可能な一の集団（コミュニティ）の中で、申請機能によって行った申請を承認する承認機能を利用可能な複数の承認集団（サブコミュニティ）を管理する。なお、コミュニティおよびサブコミュニティによる申請処理については、図１０で後述する。

また、図４および図５に示したように、管理部３３は、コミュニティについては、加入条件として業種が猟師であることを前提として設定し、一方、グループについては、加入条件として業種を設定しない。つまり、コミュニティは、猟師のみが加入でき、グループは、任意のユーザが加入できる。また、図４および図５で示したように、管理部３３は、コミュニティ間の加入条件や、グループ間の加入条件を異なるようにしてもよい。このように、管理部３３は、異なる加入条件の集団を管理することで、各ユーザが不適な集団に加入されることを防止できるため、各集団を適切なユーザで構成することができる。

申請部３４は、ユーザによる報奨金の申請処理を行う。具体的には、申請部３４は、ユーザから申請情報４５が送信されてきた場合に、記憶部４に記憶されたユーザ情報４４に基づいて、報奨金の申請先や、申請書類、申請用のシリアルナンバーを端末装置１０へ送信する。例えば、申請部３４は、ユーザ情報４４における「コミュニティＩＤ」および「サブコミュニティＩＤ」のコミュニティおよびサブコミュニティを申請先としてユーザに通知する。また、申請部３４は、申請先に応じた申請書類を予め記憶しておき、決定した申請先の申請書類をユーザの端末装置１０へ配信する。また、申請部３４は、申請情報４５毎に申請ＩＤを発行し、シリアルナンバーとしてユーザの端末装置１０へ通知する。これにより、ユーザである猟師は、捕獲個体の証憑物とともに、申請書類およびシリアルナンバーを自治体へ提出する。

そして、申請部３４は、自治体からシリアルナンバーの照合依頼があった場合、自治体端末１００を介して送信されたシリアルナンバー（申請ＩＤ）と、記憶部４に記憶された申請ＩＤとを照合し、双方の申請ＩＤが一致するか否かの照合結果を自治体端末１００へ送信する。

そして、申請部３４は、照合結果に基づいて報奨金の申請を承認した旨の通知が自治体からあった場合に、申請情報４５の「承認」の項目を更新する。また、申請部３４は、自治体から報奨金の支払いが完了した旨の連絡があった場合には、申請情報４５の「支払い」の項目を更新する。

次に、図８を用いて、アプリケーションを介して端末装置１０へ提供される画面について説明する。図８は、アプリケーションにより提供される画面を示す図である。図８では、メインメニュー、コミュニティ機能メニューおよびグループ機能メニューの画面をそれぞれ示している。なお、図８に示す画面は、管理装置１によって生成されて端末装置１０へ提供されてもよく、あるいは、管理装置１が画面生成用のプログラムを端末装置１０へ提供し、端末装置１０がかかるプログラムに基づいて画面を生成してもよい。

図８の左図に示すように、端末装置１０は、ユーザによるログイン後（例えば、ユーザＩＤおよびパスワード入力後）、メインメニューの画面を表示する。具体的には、メインメニューには、「日誌」、「コミュニティ機能」、「グループ機能」、「ログアウト」および「デバッグメニュー」等の機能を利用するための項目が表示される。

「日誌」は、ユーザが日誌を書き込むための項目である。「コミュニティ機能」は、コミュニティ機能を利用するための項目である。「グループ機能」は、グループ機能を利用するための項目である。「ログアウト」は、ログアウトするための項目である。「デバッグメニュー」は、デバッグ処理を行うためのメニューを表示するための項目である。

以下、「コミュニティ機能」および「グループ機能」が選択された場合に表示される画面について説明する。

＜コミュニティ機能＞
図８に示すように、ユーザが「コミュニティ機能」を選択する操作を行った場合、コミュニティ機能メニューを表示する。図８では、ユーザによるコミュニティ申請が行われていない場合のコミュニティ機能メニューを示している。

具体的には、図８の右図上段に示すように、「コミュニティ申請」の機能が選択可能に表示され、「新規申請」、「マイ申請」、「班長」、「メンバー」および「お知らせ」の機能については、選択不可（図８では、網掛け表示）の状態で表示されている。なお、選択不可の状態を表現する方法は、網掛けに限らず、例えば、文字の濃淡を薄くする等の表示態様を変更してもよい。あるいは、選択不可の機能については、非表示としてもよい。

ここで、「新規申請」は、猟師であるユーザが害獣などを捕獲した場合に自治体に報奨金を申請する機能である。「マイ申請」は、ログインしたユーザの現在の報奨金申請状況を確認する機能である。「班長」は、コミュニティにおける班長に関する情報を表示したり、班長に連絡（電話あるいはメール等）したりする機能である。「メンバー」は、コミュニティに登録されたメンバーに関する情報を表示したり、メンバーに連絡したりする機能である。「お知らせ」は、コミュニティが配信する情報を確認する機能である。

図８に示すコミュニティ機能メニューにおいて、端末装置１０は、ユーザが「コミュニティ申請」を選択した場合、コミュニティ申請を行うための画面を表示することで、自治体（あるいは管理装置１）に対してコミュニティ申請を行う。

そして、端末装置１０は、コミュニティ申請が完了した場合（コミュニティ登録完了した場合）、選択不可であった「新規申請」、「マイ申請」、「班長」、「メンバー」および「お知らせ」を選択可能の状態に変更する。つまり、端末装置１０は、コミュニティ申請が完了した場合、アプリにおいて利用可能な機能を拡張する。

＜グループ機能＞
図８の左図に示すメインメニューにおいて、ユーザが「グループ機能」を選択する操作を行った場合、グループ機能メニューを表示する。図８では、ユーザによるグループ申請が行われていない場合のグループ機能メニューを示している。

具体的には、図８の右図下段に示すように、「グループ申請」の機能が選択可能に表示され、「グループ伝言」、「狩猟情報共有」、「罠情報共有」および「お知らせ」の機能については、選択不可（図８では、網掛け表示）の状態で表示されている。なお、選択不可の状態を表現する方法は、網掛けに限らず、例えば、文字の濃淡を薄くする等の表示態様を変更してもよい。あるいは、選択不可の機能については、非表示としてもよい。

ここで、「グループ伝言」は、グループに登録されたメンバーに所定の情報を伝言する機能である。「狩猟情報共有」は、グループに登録されたメンバーと狩猟情報を共有する機能である。「罠情報共有」は、グループに登録されたメンバーと罠情報を共有する機能である。「お知らせ」は、グループのメンバーや、グループのメンバーが所属するコミュニティが配信する情報を確認する機能である。

図８に示すグループ機能メニューにおいて、端末装置１０は、ユーザが「グループ申請」を選択した場合、グループ申請を行うための画面を表示することで、管理装置１に対してグループ申請を行う。

そして、端末装置１０は、グループ申請が完了した場合（グループ登録完了した場合）、選択不可であった「グループ伝言」、「狩猟情報共有」、「罠情報共有」および「お知らせ」を選択可能の状態に変更する。つまり、端末装置１０は、グループ申請が完了した場合、アプリにおいて利用可能な機能を拡張する。

次に、図９を用いて、ユーザがコミュニティへ加入する場合の支援システムＳにおける処理について説明する。図９は、コミュニティへの加入処理を示す図である。

図９に示すように、まず、管理装置１は、例えば、未加入者からの要求に応じて、端末装置１０へアプリケーションを提供する（ステップＳ１）。また、管理装置１は、例えば、自治体からのコミュニティ作成依頼に応じて、新たなコミュニティを開設するとともに、支援システムＳにおける利用規約を送信する（ステップＳ２）。このとき、管理装置１は、開設したコミュニティを識別するコミュニティＩＤを自治体端末１００へ通知する。

つづいて、自治体は、自治体が把握している猟師（ユーザ）に対して、コミュニティＩＤを通知する（ステップＳ３）。この通知方法は、自治体端末１００から端末装置１０にメールで通知してもよいし、自治体からユーザにコミュニティＩＤが記載された紙を郵送してもよい。また、管理装置１からアプリケーションを介して、コミュニティＩＤを通知してもよい。なお、自治体が把握している猟師とは、例えば、書類等により自治体に猟師の申請を行っているユーザである。つまり、ステップＳ３では、自治体または管理装置１は、ユーザに対して、猟師登録した自治体のコミュニティＩＤを通知する。なお、管理装置１は、猟師登録した自治体のコミュニティＩＤを通知する場合に限らず、猟師登録していない自治体を含めて、現在登録されているコミュニティＩＤの一覧をユーザへ配信するようにしてもよい。

つづいて、ユーザは、端末装置１０によって、配信されたコミュニティＩＤとともに、加入情報を管理装置１へ送信する（ステップＳ４）。つづいて、管理装置１は、加入情報を記憶するとともに自治体端末１００へ送信する（ステップＳ５）。そして、自治体端末１００は、加入情報に基づいてユーザが加入条件を満たしている場合に、コミュニティへの加入を承認し、管理装置１は加入情報とコミュニティＩＤの紐づけて管理する。管理装置１はユーザに対してコミュニティへの加入が完了した旨を通知する。これにより、ユーザは、コミュニティの機能（図３参照）を端末装置１０で利用可能となる。

なお、管理装置１は、コミュニティの一覧を配信する際に、記憶部４に記憶された情報に基づいて、加入条件を満たすコミュニティの一覧のみを配信するようにしてもよい。

次に、図１０を用いて、ユーザがグループへ加入する場合の支援システムＳにおける処理について説明する。図１０は、グループへの加入処理を示す図である。なお、図１０では、農家および猟師がグループに加入する場合について説明する。また、図１０において、ステップＳ１１−１、ステップＳ１２〜ステップＳ１４は、グループ作成シーケンスであり、ステップＳ１１−２、ステップＳ１５〜ステップＳ１６は、グループ加入シーケンスである。

図１０に示すように、まず、管理装置１は、農家および猟師それぞれに、アプリケーションを提供する（ステップＳ１１−１，Ｓ１１−２）。つづいて、農家（猟師でも可）は、端末装置１０のアプリケーションを介して、加入情報とともにグループ作成申請を送信する（ステップＳ１２）。

つづいて、管理装置１は、新たなグループＩＤを発行するとともに、加入情報とグループＩＤとを紐付けて管理する（ステップＳ１３）。つづいて、管理装置１は、端末装置１０のアプリケーションを介して農家へ登録完了通知を送信する（ステップＳ１４）。この登録完了通知では、利用可能なグループ機能が拡張した旨の情報が含まれる。つまり、図８に示したハッチング部のグループ機能（グループ伝言、狩猟情報共有、罠情報共有、お知らせ）が利用可能となる。

次に、グループ加入シーケンスでは、猟師は、端末装置１０のアプリケーションを介して、既存のグループ一覧から加入したグループを選択して参加申請を行う（ステップＳ１５）。このとき、端末装置１０は、加入情報を併せて送信する。つまり、猟師は、グループの機能を使用するための申請を管理装置１に対して行う。

そして、管理装置１は、ユーザから参加申請を受け付けた場合、選択されたグループのグループＩＤと加入情報とを紐付けて管理するとともに、参加完了通知を行う（ステップＳ１６）。この登録完了通知では、利用可能なグループ機能が拡張した旨の情報が含まれる。つまり、図８に示したハッチング部のグループ機能（グループ伝言、狩猟情報共有、罠情報共有、お知らせ）が利用可能となる。

これにより、猟師のグループへの加入が完了し、グループの機能（図３参照）を端末装置１０で利用可能となる。つまり、図１０に示すように、グループの機能である情報共有機能により、ユーザ間で情報共有が可能となる。

なお、例えば、ユーザＡが新たなグループを作成し、作成したグループＩＤをユーザＢに連絡（電話、メール等の各種連絡手段を使用可能）することで、ユーザＢがグループの一覧の中から該当するグループを検索して参加することも可能である。

また、図１０では、管理装置１がグループの一覧をユーザへ提供する場合を示したが、例えば、グループＩＤを有しているユーザから他のユーザへグループＩＤを含むグループ情報を送信し、当該他のユーザは、かかるグループＩＤのグループへ参加する申請を行ってもよい。これにより、知人のユーザのみがグループへ参加できるため、見ず知らずのユーザがグループに参加することを防ぐことができる。

次に、図１１を用いて、支援システムＳにおける報奨金の申請処理について説明する。図１１は、報奨金の申請処理を示す図である。図１１では、猟師は、コミュニティＡ、サブコミュニティＡおよびコミュニティＢに加入していることとする。また、図１１では、猟師が、コミュニティＡおよびサブコミュニティＡへ申請して承認をもらう経路（承認ルート：紙面左側の経路）と、コミュニティＢのみへ申請して承認をもらう承認ルート（紙面右側の経路）とを使って申請する場合を説明する。

まず、コミュニティＡおよびサブコミュニティＡへ申請する承認ルートについて説明する。なお、コミュニティＡにおいて承認するユーザは、自治体の職員であり、サブコミュニティＡにおいて承認するユーザは、例えば、予め設定された猟師（以下、承認者と記載する）である。

まず、猟師は、害獣を捕獲した場合に、端末装置１０のアプリケーションを介して、害獣の画像を撮像し、かかる画像を含む申請情報４５を送信する（ステップＳ２１）。管理装置１は申請情報を受信すると申請ＩＤを発行し、申請情報と紐付けて記憶するとともに申請ＩＤを猟師へ送信する。猟師は、申請情報４５を送信後、管理装置１から発行される申請ＩＤとともに、害獣の一部を切り取った証憑物をサブコミュニティＡへ提出する（ステップＳ２２）。

つづいて、サブコミュニティＡの承認者は、端末装置１０を介して、管理装置１に記憶された申請ＩＤおよび申請情報を取得し、証憑物とともに提出された申請ＩＤと照合し、一致した場合には、端末装置１０を介して、１次承認した旨を管理装置１へ通知する（ステップＳ２３）。なお、申請ＩＤの照合は、端末装置１０が行ってもよく、管理装置１が行ってもよい。また、管理装置１は、１次承認の通知を受け付けると、記憶部４に記憶された申請情報４５の「承認」を更新する。

つづいて、サブコミュニティＡの承認者は、１次承認が完了した場合、証憑物をコミュニティへ提出する（ステップＳ２４）。コミュニティＡの承認者である自治体の職員は、端末装置１０を介して、管理装置１に記憶された申請ＩＤおよび申請情報を取得し、証憑物とともに提出された申請ＩＤと照合し、一致した場合には、端末装置１０を介して、最終承認した旨を管理装置１へ通知する（ステップＳ２５）。

つづいて、コミュニティＡの承認者は、自治体端末１００を介して、管理装置１に対して申請情報４５の閲覧要求を行い、管理装置１に記憶された申請情報４５を参照する（ステップＳ２６）。

そして、コミュニティＡの承認者は、参照した申請情報４５について、最終承認まで完了した場合、サブコミュニティＡに報奨金を支給する（ステップＳ２７）。つづいて、サブコミュニティＡの承認者は、猟師に対して報奨金を支給し（ステップＳ２８）、処理を終了する。

このように、コミュニティおよびサブコミュニティを設定して申請処理を行うことで、例えば、証憑物の偽造等による不正な申請を防止できる。

次に、コミュニティＢのみへ申請処理する場合（紙面右側の経路）について説明する。具体的には、まず、猟師は、害獣を捕獲した場合に、端末装置１０のアプリケーションを介して、害獣の画像を撮像し、かかる画像を含む申請情報４５を送信する（ステップＳ３１）。また、猟師は、申請情報４５を送信後、管理装置１から発行される申請ＩＤとともに、害獣の一部を切り取った証憑物をコミュニティＢへ提出する（ステップＳ３２）。

コミュニティＢの承認者は、端末装置１０を介して、管理装置１に記憶された申請ＩＤを取得し、証憑物とともに提出された申請ＩＤと照合し、一致した場合には、端末装置１０を介して、最終承認した旨を管理装置１へ通知する（ステップＳ３３）。

つづいて、コミュニティＢの承認者は、自治体端末１００を介して、管理装置１に対して申請情報４５の閲覧要求を行い、管理装置１に記憶された申請情報４５を参照する（ステップＳ３４）。

そして、コミュニティＢの承認者は、参照した申請情報４５について、最終承認まで完了した場合、猟師に対して報奨金を支給し（ステップＳ３５）、処理を終了する。

次に、図１２を用いて、実施形態に係る支援システムＳのコミュニティ登録処理の流れについて説明する。図１２は、実施形態に係る支援システムＳのコミュニティ登録処理の処理手順を示すシーケンス図である。なお、図１２に示す「猟師」は、猟師が所持する端末装置１０の動作を示し、「自治体」は、自治体端末１００の動作を示す。

まず、図１２に示すように、まず、猟師の端末装置１０は、管理装置１からアプリケーションをダウンロードする（ステップＳ１０１）。

つづいて、管理装置１は、自治体からコミュニティ作成要求に応じて、コミュニティＩＤを発行する（ステップＳ１０２）。

つづいて、自治体端末１００は、端末装置１０に対してコミュニティＩＤを通知する（ステップＳ１０３）。

つづいて、端末装置１０は、ユーザによって選択されたコミュニティＩＤとともに、加入情報を管理装置１へ送信することでコミュニティへの加入申請を行う（ステップＳ１０４）。つづいて、管理装置１は、加入情報を記憶するとともに、該当するコミュニティに加入情報を送信する（ステップＳ１０５）。

つづいて、自治体端末１００は、コミュニティの加入申請を承認する（ステップＳ１０６）。

つづいて、自治体端末１００は、コミュニティの加入申請を承認した場合、承認した旨を示す承認通知を端末装置１０へ行う（ステップＳ１０７−１）。また、自治体端末１００は、ステップＳ１０７−１と並行して、管理装置１へユーザのコミュニティへの登録を要求する（ステップＳ１０７−２）。

つづいて、管理装置１は、コミュニティへの登録要求があった場合に、ユーザをコミュニティへ登録する処理を行う（ステップＳ１０８）。具体的には、管理装置１は、加入情報とコミュニティＩＤとを紐づけて管理するとともに、記憶部４に記憶されたコミュニティ情報４２、グループ情報４３およびユーザ情報４４を更新する。

つづいて、端末装置１０は、自治体端末１００から承認通知を受け付けた場合、拡張機能を利用可能にする処理を行う（ステップＳ１０９）。すなわち、端末装置１０は、図３に示す「コミュニティ」の機能（コミュニティ機能メニュー）をユーザが利用可能となるようにする。

次に説明するステップＳ１１０〜Ｓ１１３までの処理は、端末装置１０を所持する猟師を班長（サブコミュニティの「１次承認」を行うユーザ）として設定する場合に行われる。つまり、端末装置１０を所持する猟師を班長として設定しない場合には、ステップＳ１０９までで処理が終了することとなる。

ステップＳ１１０以降の処理について説明する。自治体端末１００は、端末装置１０を所持する猟師のコミュニティへの加入を承認後、報奨金の申請のための承認ルートを設定する（ステップＳ１１０）。具体的には、自治体端末１００は、報奨金の申請を自治体（コミュニティの承認者）のみが承認する承認ルートにするか、自治体および班長（サブコミュニティの承認者）が承認する承認ルートにするかを選択する。

そして、自治体端末１００は、自治体および班長が承認する承認ルートを選択した場合、班長となる猟師、すなわち、報奨金の１次申請の承認者を選択する（ステップＳ１１１）。

つづいて、自治体端末１００は、選択した承認者（猟師）の端末装置１０に対して、承認者として選択した旨を通知する（ステップＳ１１２）。

つづいて、端末装置１０は、自治体端末１００から承認者として選択した旨の通知を受け付け、ユーザから当該通知を承諾する操作があった場合に、承認者となることを承諾した旨を示す通知を自治体端末１００に対して行う（ステップＳ１１３）。

次に、図１３を用いて、実施形態に係る支援システムＳのグループ登録処理の流れについて説明する。図１３は、実施形態に係る支援システムＳのグループ登録処理の処理手順を示すシーケンス図である。図１３において、ステップＳ２０１〜ステップＳ２０５は、グループ作成シーケンスであり、ステップＳ２０６〜ステップＳ２１１は、グループ加入シーケンスである。

グループ作成シーケンスでは、図１３に示すように、まず、猟師（または、農家）の端末装置１０ａは、管理装置１からアプリケーションをダウンロードする（ステップＳ２０１）。

つづいて、端末装置１０ａは、管理装置１に対してグループ作成申請を行う（ステップＳ２０２）。つづいて、管理装置１は、グループ作成申請を受け付けた場合、新たなグループＩＤを発行する（ステップＳ２０３）。

つづいて、管理装置１は、グループＩＤを発行後、端末装置１０ａに対してグループの登録が完了したことを示す登録完了通知を行う（ステップＳ２０４）。

そして、端末装置１０ａは、登録完了通知を受信することで、アプリケーションにおける利用可能なグループ機能が拡張する（ステップＳ２０５）。

次に、グループ加入シーケンスでは、図１３に示すように、まず、猟師（または、農家）の端末装置１０ｂは、管理装置１からアプリケーションをダウンロードする（ステップＳ２０６）。

つづいて、管理装置１は、アプリケーションを介して、既存のグループ一覧を通知する（ステップＳ２０７）。端末装置１０ｂは、通知されたグループ一覧の中から、一のグループがユーザによって選択された場合、選択されたグループへの参加申請（上記したアプリ拡張申請および加入情報の送信）を行う（ステップＳ２０８）。

つづいて、管理装置１は、加入情報が所定の加入条件を満たす場合に、グループ申請を承認する（ステップＳ２０９）。つづいて、管理装置１は、グループ申請承認後、端末装置１０ｂへグループへの参加完了通知を行う（ステップＳ２１０）。

そして、端末装置１０ｂは、グループＩＤを受信することで、アプリケーションにおける利用可能なグループ機能が拡張する（ステップＳ２１１）。

上述したように、実施形態に係る管理装置１は、受付部３１と、発行部３２と、管理部３３とを具備する。受付部３１は、ユーザから所定のアプリケーションを介して、ユーザが使用可能な機能が異なる複数の集団それぞれへの加入情報を受け付ける。発行部３２は、機能が異なる複数の集団それぞれに対応した識別情報を発行する。管理部３３は、受付部３１によって受け付けられた加入情報に識別情報を紐づけ、ユーザを複数の集団それぞれに登録して管理する。これにより、ユーザの利便性を向上させることができる。

なお、上述した実施形態では、管理装置１がアプリケーションを端末装置１０に配信する場合について説明したが、例えば、アプリケーションを配信する他の配信サーバから端末装置１０に対してアプリケーションが配信されてもよい。

本発明の実施形態を説明したが、この実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。この実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。この実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ 管理装置
２ 通信部
３ 制御部
４ 記憶部
１０ 端末装置
３１ 受付部
３２ 発行部
３３ 管理部
３４ 申請部
４１ 機能情報
４２ コミュニティ情報
４３ グループ情報
４４ ユーザ情報
４５ 申請情報
１００ 自治体端末
Ｎ ネットワーク
Ｓ 支援システム

Claims (5)

1. ユーザから所定のアプリケーションを介して、前記ユーザが利用可能な機能が異なる複数の集団それぞれへの加入情報を受け付ける受付部と；
   前記機能が異なる複数の集団それぞれに対応した識別情報を発行する発行部と；
   前記受付部によって受け付けられた前記加入情報に含まれるユーザ情報を記憶部に記憶し、前記記憶部に記憶された前記ユーザ情報と前記識別情報を紐づけ、前記ユーザを前記複数の集団それぞれに登録することで、前記集団それぞれに対応した前記機能に関する処理を行う管理部と；
   を具備し、
   前記複数の集団は、報奨金の申請を行う申請機能を利用可能な集団と、前記申請機能を利用できない集団であって、当該集団に属するユーザ間での情報共有機能を利用可能な集団とを含む、管理装置。
2. 前記複数の集団は、
   前記申請機能を利用可能な一の集団の中で、前記申請機能によって行った申請を承認する承認機能を利用可能な複数の承認集団を含む
   請求項１に記載の管理装置。
3. 前記複数の集団は、
   ユーザ属性に応じた加入条件が異なる
   請求項１または２に記載の管理装置。
4. 前記複数の集団は、
   前記集団に属する前記ユーザが共有可能な情報が異なる
   請求項１〜３のいずれか１つに記載の管理装置。
5. コンピュータが実行する管理方法であって、
   ユーザから所定のアプリケーションを介して、前記ユーザが利用可能な機能が異なる複数の集団それぞれへの加入情報を受け付ける受付工程と；
   前記機能が異なる複数の集団それぞれに対応した識別情報を発行する発行工程と；
   前記受付工程によって受け付けられた前記加入情報に含まれるユーザ情報を記憶部に記憶し、前記記憶部に記憶された前記ユーザ情報と前記識別情報を紐づけ、前記ユーザを前記複数の集団それぞれに登録することで、前記集団それぞれに対応した前記機能に関する処理を行う管理工程と；
   を含み、
   前記複数の集団は、報奨金の申請を行う申請機能を利用可能な集団と、前記申請機能を利用できない集団であって、当該集団に属するユーザ間での情報共有機能を利用可能な集団とを含む、管理方法。

Images