(57)【特許請求の範囲】
【請求項１】
ＩＰネットワーク上のアドレス空間のアドレス表記に用いるプレフィックス長ごとに、当該プレフィックス長に係るセグメントのリストを保持するリスト保持手段と、
上記リスト保持手段が保持しているプレフィックス長ごとのリストを参照することにより、上記アドレス空間で割当可能なセグメントを探索することが可能なセグメント探索手段と
を有することを特徴とするアドレス情報管理装置。
【請求項２】
新たに割当てるセグメントに係るプレフィックス長の入力を受付ける割当セグメント受付手段をさらに備え、
上記セグメント探索手段は、上記リスト保持手段のリストを参照し、上記アドレス空間上で割当可能な、上記割当セグメント受付手段で受付けた入力プレフィックス長のセグメントを探索する
ことを特徴とする請求項１に記載のアドレス情報管理装置。
【請求項３】
上記セグメント探索手段が探し出したセグメントについて、割当済となるように、上記リスト保持手段が保持するリストを更新するセグメント割当手段をさらに有することを特徴とする請求項２に記載のアドレス情報管理装置。
【請求項４】
上記探索手段で、探し出したセグメントが、上記入力プレフィックス長が示すセグメントよりもサイズの大きいセグメントだった場合、上記セグメント割当手段は、その探し出したセグメントを分割して、上記入力プレフィックス長分のセグメントだけが割当済となるように、上記リスト保持手段が保持するリストを更新することを特徴とする請求項３に記載のアドレス情報管理装置。
【請求項５】
割当済のセグメントの返却を受付ける返却セグメント受付手段と、
上記返却セグメント受付手段が受け付けた返却セグメントが、上記アドレス空間上で未割当となるように、上記リスト保持手段が保持するリストを更新するセグメント返却手段と
をさらに有することを特徴とする請求項１〜４のいずれかに記載のアドレス情報管理装置。
【請求項６】
上記セグメント返却手段は、上記返却セグメント受付手段で受付けた返却セグメントを、上記アドレス空間上で未割当の領域とする際に、上記アドレス空間上で上記返却セグメントと統合可能な未割当セグメントがあった場合、上記返却セグメントと上記統合可能な未割当セグメントとを統合したセグメントとして、上記リスト保持手段が保持するリスト上に登録更新することを特徴とする請求項５に記載のアドレス情報管理装置。
【請求項７】
上記セグメント探索手段は、上記アドレス空間上で、上記入力プレフィックス長以上のプレフィックス長の未割当セグメントが探し出せない場合、上記入力プレフィックス長により近いプレフィックス長の未割当セグメントを含む上記入力プレフィックス長の候補セグメントを探索することを特徴とする請求項２に記載のアドレス情報管理装置。
【請求項８】
上記セグメント探索手段は、探し出した１又は複数の候補セグメントのうち、所定の条件に対応する候補セグメントを、ユーザへ提案する提案セグメントと決定し、提案セグメントに係る提案情報を出力することを特徴とする請求項７に記載のアドレス情報管理装置。
【請求項９】
上記所定の条件の入力を受付ける条件入力手段をさらに備え、
上記セグメント探索手段は、上記条件入力手段により入力された入力条件を上記所定の条件として用いる
ことを特徴とする請求項８に記載のアドレス情報管理装置。
【請求項１０】
コンピュータを、
ＩＰネットワーク上のアドレス空間のアドレス表記に用いるプレフィックス長ごとに、当該プレフィックス長に係るセグメントのリストを保持するリスト保持手段と、
上記リスト保持手段が保持しているプレフィックス長ごとのリストを参照することにより、上記アドレス空間で割当可能なセグメントを探索することが可能なセグメント探索手段と
して機能させることを特徴とするアドレス情報管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アドレス情報管理装置及びプログラムに関し、例えば、ＩＰネットワーク上のアドレス空間の管理に適用し得る。
【背景技術】
【０００２】
例えば、国、企業、通信キャリアの内部設備等では、複数のサブネットワークからなるＩＰネットワーク（例えば、プライベートアドレスを用いたネットワーク）を構築する。ＩＰネットワーク上に存在する通信端末、サーバ、通信機器等には、ＩＰアドレスが割り振られているが、通信端末等の増大に伴い、ＩＰアドレスの管理が煩雑となる。
【０００３】
また、動的にＩＰアドレスを割り振る従来技術として、ＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）がある。ＤＨＣＰに対応したサーバは、クライアントからのＩＰアドレスの要求に対してＩＰアドレスを割り振ることができる。しかし、ＤＨＣＰサーバは、各サブネットワーク内でのＩＰアドレスの割り振りは可能であるが、各サブネットに割り振るアドレス空間上の領域（セグメント）を管理することはできないため、各サブネットワークごとの管理は管理者が行わなくてはならない。
【０００４】
そこで、このような問題を解決する技術として特許文献１の記載技術がある。特許文献１の記載技術は、各サブネットワークで使用されるＩＰアドレス及びそれに関連する情報が保存されたマスターテーブルを有し、ＩＰアドレスの利用状況を検索することができる。ＩＰアドレスの利用状況の検索は、検索指定された条件のセグメントに割り当てられているＩＰアドレスの一覧を表示するというものである。
【０００５】
しかしながら、上述した特許文献１の記載技術は、ネットワーク全体の各サブネットワークのＩＰアドレスのセグメント及びそれに関連する情報を保存したマスターテーブルを有するので、ＩＰアドレスのセグメントの払い出しは可能であるが、未割当のセグメントがどこなのかをユーザが把握することは困難であるという問題も生じ得る。
【０００６】
そのため、ＩＰアドレスの割り振り状況を視覚的に判別しやすくし、ＩＰアドレスのプレフィックス単位での登録、更新、削除等を簡単な操作でユーザが行うことができる従来技術として、特許文献２に記載のアドレス情報管理システムがある。
【０００７】
特許文献２のアドレス情報管理システムは、ユーザがＧＵＩの操作画面で、未使用のＩＰアドレスのセグメントを見つけセグメント割当を行うものである。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００８−２２７７５６号公報
【特許文献２】特開２０１２−７００４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献２の記載技術を利用した場合、ユーザは、未使用のセグメントを見つけ出す必要があるが、未割当のセグメントが点在している場合、利用者が所望するサイズのセグメントを見つけ出すことは容易ではなかった。
【００１０】
そのため、ＩＰアドレス空間上で、任意のサイズの割当可能なセグメントを容易に探索することができるアドレス情報管理装置及びプログラムが望まれている。
【課題を解決するための手段】
【００１１】
第１の本発明は、ＩＰネットワーク上のアドレス空間を管理するアドレス情報管理装置において、（１）上記アドレス空間のアドレス表記に用いるプレフィックス長ごとに、当該プレフィックス長に係るセグメントのリストを保持するリスト保持手段と、（２）上記リスト保持手段が保持しているプレフィックス長ごとのリストを参照することにより、上記アドレス空間で割当可能なセグメントを探索することが可能なセグメント探索手段とを有することを特徴とする。
【００１２】
第２の本発明のアドレス情報管理プログラムは、コンピュータを、（１）ＩＰネットワーク上のアドレス空間のアドレス表記に用いるプレフィックス長ごとに、当該プレフィックス長に係るセグメントのリストを保持するリスト保持手段と、（２）上記リスト保持手段が保持しているプレフィックス長ごとのリストを参照することにより、上記アドレス空間で割当可能なセグメントを探索することが可能なセグメント探索手段として機能させることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、ＩＰアドレス空間上で、任意のサイズの割当可能なセグメントを容易に探索するアドレス情報管理装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】第１の実施形態のサーバ（アドレス情報管理装置）を備えるアドレス情報管理システムの構成を示すブロック図である。
【図２】第１の実施形態に係る未割当領域リストのデータ構造を概念的に示した説明図である。
【図３】第１の実施形態に係るセグメント割当部の動作を示したフローチャートである。
【図４】第１の実施形態に係るサーバ（セグメント割当部）が出力するセグメント割当要求受付画面の構成例について示した説明図である。
【図５】第１の実施形態に係る未割当領域リストの遷移について示した説明図である。
【図６】第１の実施形態に係るセグメント返却部の動作を示したフローチャートである。
【図７】第１の実施形態に係るサーバ（セグメント返却部）が出力するアドレス返却受付画面の構成例について示した説明図である。
【図８】第２の実施形態のサーバ（アドレス情報管理装置）を備えるアドレス情報管理システムの構成を示すブロック図である。
【図９】第２の実施形態に係る未割当領域リストのデータ構造を概念的に示した説明図である。
【図１０】第２の実施形態に係る割当済領域リストのデータ構造を概念的に示した説明図である。
【図１１】第２の実施形態に係るＩＰネットワークのアドレス空間を、視覚的（マトリクス形式）に表した説明図である。
【図１２】第２の実施形態に係るサーバ（セグメント割当部）が出力するセグメント割当要求受付画面の構成例について示した説明図である。
【図１３】第２の実施形態に係る割当領域提案部の動作を示したフローチャートである。
【図１４】第２の実施形態に係るセグメント割当部が行う処理に係る各値の例について示した説明図である。
【発明を実施するための形態】
【００１５】
（Ａ）第１の実施形態
以下、本発明によるアドレス情報管理装置及びプログラムの第１の実施形態を、図面を参照しながら詳述する。以下では、実施形態に係るアドレス情報管理装置をサーバに適用した場合について説明する。また、第１の実施形態では、ＩＰｖ４のＩＰアドレスをセグメント単位で払い出す場合の実施形態を例示して説明する。しかし、ＩＰアドレスはＩＰｖ４に限定されるものではなく、ＩＰｖ６の場合にも本発明を適用することができる。
【００１６】
（Ａ−１）第１の実施形態の構成
図１は、第１の実施形態のアドレス情報管理装置としてのサーバ１０を備えるアドレス情報管理システム１の構成を示すブロック図である。
【００１７】
図１において、第１の実施形態のアドレス情報管理システム１は、サーバ１０、及びブラウザ端末２０を有している、
サーバ１０は、管理対象となっているＩＰネットワーク（以下、「ＩＰネットワークＮ」と呼ぶ）のＩＰアドレス空間の各領域（セグメント）について割当状況を管理している。そして、サーバ１０は、通信によりブラウザ端末２０と接続しており、ブラウザ端末２０に対して、ＩＰネットワークＮのアドレス空間上のセグメント（アドレス空間上の領域、ＩＰアドレスの集合）の割当や返却を受付けるための操作画面（Ｗｅｂ画面）を提供することができる。そして、サーバ１０は、ユーザによる操作画面（Ｗｅｂ画面）の操作に応じて、セグメントの割当や返却の処理を行う。
【００１８】
ブラウザ端末２は、例えば、既存のＷｅｂブラウザを備えるＰＣ等の端末を用いて実現することができる。具体的には、ブラウザ端末２０は、Ｗｅｂブラウザ等のソフトウェアを実行するための制御部２１、ユーザインタフェースとしての入出力部２２、及びサーバ１０と通信することができる通信部２３を有している。入出力部２２は、例えば、マウス、キーボード、ディスプレイ等のＷｅｂ画面に係る表示及び入力受付を行うことができるデバイスにより構成される。なお、ブラウザ端末２を配置する台数は限定されないものである。
【００１９】
サーバ１０は、ＩＰネットワークＮ上のアドレス空間（セグメント）を管理するための装置（アドレス情報管理装置）であり、セグメント割当部１１、セグメント返却部１２、及びアドレス情報記憶部１３を有している。
【００２０】
サーバ１０は、例えば、ＰＣやワークステーション等のコンピュータに、実施形態のアドレス情報管理プログラムをインストールすることにより実現するようにしてもよく、その場合でも、サーバ１０の機能的構成は、図１のように示すことができる。
【００２１】
アドレス情報記憶部１３は、ＩＰネットワークＮ上のアドレス空間を管理するためのデータとして未割当領域リスト１３ａを記憶している。未割当領域リスト１３ａのデータ構造の詳細については、後述する。
【００２２】
セグメント割当部１１は、ブラウザ端末２０から、ＩＰネットワークＮ上のセグメントの割当要求（ユーザによるＷｅｂ画面に対する操作）を受付ける。セグメント割当部１１は、ＣＩＤＲ（Ｃｌａｓｓｌｅｓｓ  Ｉｎｔｅｒ−Ｄｏｍａｉｎ  Ｒｏｕｔｉｎｇ）の形式でＩＰアドレスを表示する際のプレフィックス長（プレフィックスのビット数）により、ユーザが所望するセグメントのサイズ（以下、「ユーザ希望サイズ」と呼ぶ）を受付ける。セグメント割当部１１は、ユーザ希望サイズ以上のセグメントが未割当（空いている）か否かを、未割当領域リスト１３ａの内容から確認する。そして、セグメント割当部１１は、ユーザ希望サイズ以上のセグメントが未割当となっている場合には、ユーザ希望サイズのセグメントを確保する更新を未割当領域リスト１３ａに対して行い、さらに、ブラウザ端末２０に対して確保したセグメントの先頭アドレス（以下、「セグメントアドレス」と呼ぶ）とプレフィックス長の出力（ｗｅｂ画面に対する表示）を行う。
【００２３】
セグメント返却部１２は、ユーザから、返却に係るセグメント（以下、「返却セグメント」と呼ぶ）の情報（セグメントアドレスおよびプレフィックス長による表記）を受付けて、当該セグメントについて解放（未割当状態とする）するように未割当領域リスト１３ａの内容を更新する処理を行う。ただし、セグメント返却部１２は、返却に係る返却セグメントと、他の未割当セグメントとが統合可能な場合には、それらのセグメントを統合する更新処理を、未割当領域リスト１３ａに対して行う。
【００２４】
次に、未割当領域リスト１３ａのデータ構造の詳細について説明する。
【００２５】
未割当領域リスト１３ａは、ＩＰネットワークＮ上のアドレス空間における利用状況を管理するためのデータベースであり、例えば、図２のような構造で表すことができる。
【００２６】
図２では、未割当領域リスト１３ａで管理される、未割当領域（空き領域）のデータ構造を概念的に示している。
【００２７】
図２に示すように、未割当領域リスト１３ａでは、アドレス空間の未割当領域を、プレフィックス長ごとのセグメントアドレスのリスト（以下、「プレフィックスリストＬ」とも呼ぶ）で表している。各プレフィックスリストＬは、当該プレフィックスリストに係るプレフィックス長を示すデータＤと、当該プレフィックスリストを構成する１又は複数のセグメントのセグメントアドレスＳＡを有するものとする。
【００２８】
ＩＰｖ４の場合、ＩＰアドレスが３２ビットで表されるので、プレフィックス長は１〜３１のいずれかの数値となる。なお、ＩＰｖ６の場合、ＩＰアドレスが１２８ビットで表されるので、プレフィックス長は１〜１２７のいずれかの値となる。ここでは、サーバ１０により管理対象となっているＩＰネットワークＮのＩＰアドレスはＩＰｖ４により表されているものとする。そして、以下では、ＩＰネットワークＮ上のプレフィックス１〜３１に対応するプレフィックスリストをＬ１〜Ｌ３１と呼ぶものとする。
【００２９】
そして、図２ででは、ＩＰネットワークＮ上のプレフィックスリストＬ２０、Ｌ２１、Ｌ２２を抽出して図示している。図２では、未割当領域リスト１３ａの構造をツリー構造で図示しているが、具体的なデータ構造は限定されないものであり、各プレフィックスリストＬの構成はテーブル形式としてもよい。また、未割当領域リスト１３ａにおいて、各プレフィックスリストＬに係るプレフィックス長を管理する構成は限定されないものであり、図２のようにデータＤを用いる管理ではなく、プレフィックスリストの名称（識別子）等により管理するようにしてもよい。
【００３０】
図２のプレフィックスリストＬ２０（プレフィックス長が２０のプレフィックスリスト）には、プレフィックス長を示すデータＤ２０（２０）、及び３つのセグメントアドレスＳＡ２０１（１９２．１６８．０．０）、ＳＡ２０２（１９２．１６９．２４０．０）、ＳＡ２０３（１９２．１６８．６４．０）が登録されている。例えば、プレフィックスリストＬ２０のセグメントアドレスＳＡ２０２（１９２．１６９．２４０．０）は、ＣＩＤＲ記法で表すと「１９２．１６９．２４０．０／２０」のセグメントを表している。「１９２．１６９．２４０．０／２０」のセグメントには、１９２．１６８．２４０．０から１９２．１６８．２５５．２５５までの４０９６のＩＰアドレスが含まれている。
【００３１】
また、図２のプレフィックスリストＬ２１には２つのセグメントアドレスＳＡ２１１（１９２．１６８．２４８．０）、ＳＡ２１２（１９２．１６９．２３２．０）が登録されている。
【００３２】
さらに、図２のプレフィックスリストＬ２２には、セグメントアドレスが一つも登録されていないので、ＩＰネットワークＮ上で、プレフィックスが２２のセグメントはすべて割当済（空いていない）ことを示している。
【００３３】
（Ａ−２）第１の実施形態の動作
次に、以上のような構成を有する第１の実施形態のアドレス情報管理システム１を構成するサーバ１０の動作を説明する。
【００３４】
（Ａ−２−１）セグメント割当処理
まず、サーバ１０において、ユーザの要求に応じて、ＩＰネットワークＮのアドレス空間上の未割当領域から、セグメントを割り当てる処理を、図３のフローチャートを用いて説明する。
【００３５】
まず、ここでは、ブラウザ端末２０からサーバ１０にアクセスがあり、ユーザ希望サイズを指定したセグメント割当要求があったものとする。具体的には、サーバ１０は、ブラウザ端末２０からのアクセスに応じて、ブラウザ端末２０に、例えば、図４のようなＷｅｂ画面を表示させる。図４は、ユーザから割当要求に係るユーザ希望サイズの入力を受付けるための画面（以下、「セグメント割当要求受付画面」と呼ぶ）である。
【００３６】
図４に示すセグメント割当要求受付画面では、ユーザ希望サイズ（プレフィックス長）の入力を受付けるためのフィールドＦ１０１と、フィールドＦ１０１に入力された値をユーザ希望サイズとして、サーバ１０にアドレス割当要求を行うためのボタンＢ１０１と、サーバ１０からの処理結果を表示するためのフィールドＦ１０２とが配置されている。
【００３７】
そして、サーバ１０では、ブラウザ端末２０（Ｗｅｂブラウザ）からの要求に応じて、セグメント割当部１１により、図３のフローチャートの処理が実行される。
【００３８】
図３のフローチャートの処理では、プレフィックス長を示す変数Ｐ１を用いるものとする。なお変数Ｐ１の初期値はユーザ希望サイズとする。
【００３９】
まず、セグメント割当部１１は、未割当領域リスト１３ａから、変数Ｐ１に対応するプレフィックスリストを参照し、当該プレフィックスリストで未割当のセグメントの有無を確認する（Ｓ１０１）。そして、セグメント割当部１１は、未割当のセグメントが検出できた場合には、後述するステップＳ１０４から動作し、そうでない場合には後述するステップＳ１０２から動作する。
【００４０】
上述のステップＳ１０１で、未割当のセグメントが検出できなかった場合には、セグメント割当部１１は、変数Ｐ１をデクリメント（１減算）する（Ｓ１０２）。
【００４１】
そして、セグメント割当部１１は、変数Ｐ１が０か否かを確認する（Ｓ１０３）。変数Ｐ１が０の場合には、セグメント割当部１１は、ＩＰネットワークＮでユーザ希望サイズに該当する未割当領域は存在しないものと判定し、セグメント割当処理を終了する。この場合、セグメント割当部１１は、ユーザ希望サイズに該当する未割当領域は存在しない旨をブラウザ端末２０のＷｅｂ画面（セグメント割当要求受付画面のフィールドＦ１０２）に表示出力させる。具体的には、セグメント割当部１１は、例えば、「希望するプレフィックス長のセグメントは空いていません」というメッセージを、セグメント割当要求受付画面のフィールドＦ１０２に出力するようにしてもよい。
【００４２】
一方、変数Ｐが０でない場合には、セグメント割当部１１は、上述のステップＳ１０１の処理に移行する。
【００４３】
上述のステップＳ１０１で、未割当のセグメントが検出できた場合には、セグメント割当部１１は、変数Ｐ１に対応するプレフィックスリストから、いずれかのセグメントアドレスを取り出す（Ｓ１０４）。このとき、セグメント割当部１１は、取り出したセグメントアドレスのデータを、当該プレフィックスリストから削除することになる。
【００４４】
そして、セグメント割当部１１は、取り出したセグメントのサイズ（取り出したセグメントアドレスに係るプレフィックス長）が、ユーザ希望サイズと同一か否かを確認する（Ｓ１０５）。
【００４５】
上述のステップＳ１０５で、取り出したセグメントのサイズがユーザ希望サイズと一致する場合には、セグメント割当部１１は、当該セグメントを今回割当てるセグメントとして決定して、セグメント割当処理を終了する。
【００４６】
一方、上述のステップＳ１０５で、取り出したセグメントのサイズがユーザ希望サイズと一致しない場合には、当該セグメントは、ユーザ希望サイズより大きいため、セグメント割当部１１は、ユーザ希望サイズと一致するサイズに分割する処理を行う（Ｓ１０６）。このとき、当該セグメントのサイズとユーザ機能サイズのプレフィックスが２ビット以上異なる場合には、セグメント割当部１１は、複数回のセグメント分割を行う必要がある。
【００４７】
そして、セグメント割当部１１は、分割したセグメントのうち１つを選択（複数回分割した場合にはプレフィックスの値が最も小さいセグメントから順に選択）して、セグメント返却部１２に返却させる処理を行う（Ｓ１０７）。このとき、セグメント割当部１１は、返却に係るセグメントのセグメントアドレスおよびプレフィックス長をセグメント返却部１２に通知する。
【００４８】
そして、セグメント割当部１１は、返却処理の後に残ったセグメントが１つ（ユーザ希望サイズのセグメントが１つ）だけであるか否かを確認する（Ｓ１０８）。
【００４９】
残ったセグメントがユーザ希望サイズのセグメント１つだけだった場合、セグメント割当部１１は、当該セグメントを今回割当てるセグメントとして決定して、セグメント割当処理を終了する。一方、残ったセグメントが複数の場合には、セグメント割当部１１は、上述のステップＳ１０７の処理に戻って返却処理を行う。
【００５０】
そして、上述のステップＳ１０５、又はステップＳ１０８で、今回割当てるセグメントが決定された場合、セグメント割当部１１は、割当てたセグメントに係る情報（セグメントアドレスおよびプレフィックス長）をブラウザ端末２０のＷｅｂ画面（セグメント割当要求受付画面のフィールドＦ１０２）に表示出力させる。
【００５１】
次に、セグメント割当部１１のアドレス割当の具体例として、図３のフローチャートの処理において、未割当領域リスト１３ａの初期状態が、図２に示す内容だった場合について説明する。
【００５２】
ここでは、ブラウザ端末２０を利用するユーザにより、セグメント割当要求受付画面で、フィールドＦ１０１にユーザ希望サイズとして「２２」が入力され、ボタンＢ１０１が押下されたものとする。
【００５３】
この場合、変数Ｐ１の初期値は２２となる。そして、最初にセグメント割当部１１は、ステップＳ１０１において、プレフィックスリストＬ２２を参照することになる。図２に示すように、当初は、プレフィックスリストＬ２２には、未割当のセグメントは登録されていないため、ここでは、セグメント割当部１１は後述するステップＳ１０２に進むことになる。そして、ステップＳ１０２で、変数Ｐ１が２１にデクリメントされる。
【００５４】
そして、セグメント割当部１１では、再びステップＳ１０１の処理が行われる。プレフィックスリストＬ２１には、セグメントアドレスＳＡ２１１、ＳＡ２１２が登録されているため、セグメント割当部１１はステップＳ１０４に進むことになる。
【００５５】
そして、セグメント割当部１１は、ステップＳ１０４で、プレフィックスリストＬ２１からセグメントアドレスＳＡ２１１（１９２．１６８．２４８．０）を取り出したものとする。この時点で、セグメント割当部１１は、未割当領域リスト１３ａのプレフィックスリストＬ２１から、セグメントアドレスＳＡ２１１（１９２．１６８．２４８．０）を消去する。
【００５６】
そして、取り出したセグメント（ＳＡ２１１；「１９２．１６８．２４８．０／２１」）に係るプレフィックスは、ユーザ希望サイズ（２２）と異なるため、セグメント割当部１１は、ステップＳ１０５から、ステップＳ１０６の処理に進むことになる。
【００５７】
そして、セグメント割当部１１は、ステップＳ１０７の処理において、ステップＳ１０６で取り出したセグメント「１９２．１６８．２４８．０／２１」を２つに分割して、ユーザ希望サイズのセグメント（／２２のセグメント）とする。具体的には、セグメント割当部１１は、取り出された「１９２．１６８．２４８．０／２１」のセグメントを、「１９２．１６８．２４８．０／２２」と「１９２．１６８．２５２．０／２２」の２つに分割する。
【００５８】
そして、セグメント割当部１１は、ステップＳ１０７において、ステップＳ１０７で分割されたセグメントの一方について返却処理（セグメント返却部１２に通知）する。ここでは、セグメント割当部１１は、「１９２．１６８．２４８．０／２２」を返却したものとする。
【００５９】
そして、残ったセグメントは、「１９２．１６８．２５２．０／２２」だけであるため、セグメント割当部１１は、ステップＳ３０８において、その残ったセグメントを今回割当てるセグメントとして決定することになる。
【００６０】
セグメント割当部１１は、ブラウザ端末２０（Ｗｅｂブラウザ）に、割当てたセグメントに係る情報（セグメントアドレスおよびプレフィックス）を通知して、Ｗｅｂ画面（セグメント割当要求受付画面のフィールドＦ１０２）に表示させる。具体的には、例えば、セグメント割当部１１は、セグメント割当要求受付画面のフィールドＦ１０２に、「１９２．１６８．２５２．０／２２が割り当てられました。」と表示するようにしてもよい。
【００６１】
また、上述の例により、「１９２．１６８．２５２．０／２２」が割り当てられた後の未割当領域リスト１３ａの内容は、図５のように更新される。図５では、「１９２．１６８．２４８．０／２１」（Ｌ２１のＳＡ２１１）が取り出されて分割され、「１９２．１６８．２４８．０／２２」（Ｌ２２のＳＡ２２１）が返却された状態となっている。
【００６２】
（Ａ−２−２）セグメント返却処理
次に、サーバ１０において、ＩＰネットワークＮのアドレス空間上で、割当済のセグメントの返却処理について、図６のフローチャートを用いて説明する。
【００６３】
まず、ここでは、ブラウザ端末２０からサーバ１０にアクセスがあり、セグメントの返却要求があったものとする。具体的には、サーバ１０は、ブラウザ端末２０からのアクセスに応じて、ブラウザ端末２０に、例えば、図７のようなＷｅｂ画面を表示させる。図７は、ユーザから返却要求に係るセグメントの情報（セグメントアドレスおよびプレフィックス長）の入力を受付けるための画面（以下、「アドレス返却受付画面」と呼ぶ）である。
【００６４】
図７に示すアドレス返却受付画面では、返却するセグメントに係るセグメントアドレスの入力を受付けるためのフィールドＦ２０１と、当該セグメントに係るプレフィックス長の入力を受付けるためのフィールドＦ２０２と、フィールドＦ２０１、Ｆ２０１に入力された返却セグメントについてサーバ１０に返却要求するためのボタンＢ２０１とが配置されている。
【００６５】
そして、サーバ１０では、ブラウザ端末２０（Ｗｅｂブラウザ）からの要求に応じて、セグメント返却部１２により、図６のフローチャートの処理が実行される。なお、セグメント割当部１１から、上述のステップＳ１０７の処理で依頼されるセグメント返却処理も同様に、図６のフローチャートの処理により実行される。
【００６６】
図６のフローチャートの処理では、現在処理対象となっているセグメントを「処理対象セグメントＸ１」と呼ぶものとする。なお処理対象セグメントＸ１の初期値は、返却セグメントの内容となる。
【００６７】
まず、セグメント返却部１２は、処理対象セグメントＸ１が、上位プレフィックスにおいて属するセグメント（以下、「上位プレフィックスセグメントＸ２」と呼ぶ）を求める。そして、セグメント返却部１２は、処理対象セグメントＸ１が、上位プレフィックスセグメントＸ２の先頭に該当するか否かを判定する（Ｓ２０１）。
【００６８】
上位プレフィックスセグメントＸ２とは、処理対象セグメントＸ１よりも１つ上位のプレフィックス長（処理対象セグメントＸ１のプレフィックス長をデクリメントしたもの）のセグメントであって、処理対象セグメントＸ１を包含するセグメントのことである。すなわち、処理対象セグメントＸ１は、上位プレフィックスセグメントＸ２の一部を構成することになる。例えば、「１９２．１６８．２５２．０／２２」が処理対象セグメントＸ１だった場合、上位プレフィックスセグメントＸ２は「１９２．１６８．２４８．０／２１」となる。しかし、この場合、処理対象セグメントＸ１「１９２．１６８．２５２．０／２２」は、上位プレフィックスセグメントＸ２「１９２．１６８．２４８．０／２１」の先頭ではない。
【００６９】
そして、セグメント返却部１２は、上述のステップＳ２０１で、処理対象セグメントＸ１が上位プレフィックスセグメントＸ２の先頭だった場合には、後述するステップＳ２０２から動作し、そうでない場合には、後述するステップＳ２０５から動作する。
【００７０】
そして、上述のステップＳ２０１で、処理対象セグメントＸ１が上位プレフィックスセグメントＸ２の先頭だった場合には、セグメント返却部１２は、処理対象セグメントＸ１と同じプレフィックス長であって、アドレス空間上で処理対象セグメントＸ１の後方（次）に隣接するセグメント（以下、「後方セグメントＸ３」と呼ぶ）が、未割当セグメントとなっているか否かを確認する（Ｓ２０２）。
【００７１】
そして、セグメント返却部１２は、上述のステップＳ２０２で後方セグメントＸ３が未割当セグメントとなっている場合には、後述するステップＳ２０３から動作し、そうでない場合には、後述するステップＳ２０８から動作する。
【００７２】
後方セグメントＸ３が未割当セグメントとなっている場合には、セグメント返却部１２は、未割当領域リスト１３ａのプレフィックスリストから後方セグメントＸ３を取り出して（Ｓ２０３）、処理対象セグメントＸ１と統合（接続）したセグメントを求める処理を行う（Ｓ２０４）。
【００７３】
言い換えると、セグメント返却部１２は、処理対象セグメントＸ１と後方セグメントＸ３とを統合したセグメントとして、上位プレフィックスセグメントＸ２を求めることになる。なお、ステップＳ２０４では、セグメント返却部１２は、上述のステップＳ２０１で求めた上位プレフィックスセグメントＸ２をそのまま、統合後のセグメントとして用いるようにしてもよい。
【００７４】
そして、セグメント返却部１２は、処理対象セグメントＸ１を、ステップＳ２０４で求めた統合後のセグメントとして、上述のステップＳ２０１から動作する。
【００７５】
一方、上述のステップＳ２０１で、処理対象セグメントＸ１が上位プレフィックスセグメントＸ２の先頭でなかった場合には、セグメント返却部１２は、処理対象セグメントＸ１と同じプレフィックス長であって、アドレス空間上で処理対象セグメントＸ１の前方に隣接するセグメント（以下、「前方セグメントＸ４」と呼ぶ）が、未割当セグメントとなっているか否かを確認する（Ｓ２０５）。
【００７６】
そして、セグメント返却部１２は、上述のステップＳ２０５で前方セグメントＸ４が未割当セグメントとなっている場合には、後述するステップＳ２０６から動作し、そうでない場合には、後述するステップＳ２０８から動作する。
【００７７】
前方セグメントＸ４が未割当セグメントとなっている場合には、セグメント返却部１２は、未割当領域リスト１３ａのプレフィックスリストから前方セグメントＸ４を取り出して（Ｓ２０６）、処理対象セグメントＸ１と統合したセグメントを求める処理を行う（Ｓ２０７）。そして、セグメント返却部１２は、処理対象セグメントＸ１を、ステップＳ２０７で求めた統合後のセグメントとして、上述のステップＳ２０１から動作する。
【００７８】
なお、ステップＳ２０７では、セグメント返却部１２は、上述のステップＳ２０１で求めた上位プレフィックスセグメントＸ２をそのまま統合後のセグメントとして用いるようにしてもよい。
【００７９】
そして、上述のステップＳ２０２又はステップＳ２０５で、後方セグメントＸ３又は前方セグメントＸ４が未割当セグメントとなっていなかった場合には、セグメント返却部１２は、処理対象セグメントＸ１を未割当とする更新処理（未割当領域リスト１３ａの対応するプレフィックスリストに追加する処理）を行う（Ｓ２０８）。
【００８０】
以上の処理により、セグメント返却部１２は、返却セグメントの返却処理を行う。
【００８１】
次に、セグメント返却部１２のセグメント返却処理の具体例として、図６のフローチャートの処理において、未割当領域リスト１３ａの初期状態が、図５に示す内容だった場合について説明する。
【００８２】
ここでは、ブラウザ端末２０を利用するユーザにより、アドレス返却受付画面で、図７に示すように、返却セグメントとして「１９２．１６８．２５２．０／２２」が入力され、ボタンＢ２０１が押下されたものとする。
【００８３】
この場合、処理対象セグメントＸ１の初期値は「１９２．１６８．２５２．０／２２」となる。そして、最初にセグメント割当部１１は、ステップＳ２０１において、上位プレフィックスセグメントＸ２として、「１９２．１６８．２４８．０／２１」というセグメントを求める。しかし、処理対象セグメントＸ１「１９２．１６８．２５２．０／２２」は、上位プレフィックスセグメントＸ２「１９２．１６８．２４８．０／２１」の先頭ではないため、ここでは、セグメント返却部１２は、ステップＳ２０５に進むことになる。
【００８４】
そして、セグメント返却部１２は、ステップＳ２０５において、処理対象セグメントＸ１「１９２．１６８．２５２．０／２２」の前方セグメントＸ４「１９２．１６８．２４８．０／２２」が、プレフィックスリストＬ２２に未割当セグメントとして登録されているか否かを確認する。図５の状態では、プレフィックスリストＬ２２に、セグメントアドレスＳＡ２２１として「１９２．１６８．２４８．０／２２」のセグメントは登録されている。したがって、セグメント返却部１２は、ステップＳ２０５において、前方セグメントＸ４は未割当セグメントとなっていると判定してステップＳ２０６、Ｓ２０７の処理を行うことになる。
【００８５】
そして、セグメント返却部１２は、ステップＳ２０６において、前方セグメントＸ４「１９２．１６８．２４８．０／２２」（プレフィックスリストＬ２２のＳＡ２２１）を取り出す（プレフィックスリストＬ２２からＳＡ２２１を削除する）。そして、セグメント返却部１２は、ステップＳ２０７において、前方セグメントＸ４「１９２．１６８．２４８．０／２２」と、処理対象セグメントＸ１「１９２．１６８．２５２．０／２２」とを統合して、「１９２．１６８．２４８．０／２１」という統合セグメントを生成する。
【００８６】
そして、セグメント返却部１２は、統合セグメント「１９２．１６８．２４８．０／２１」を、処理対象セグメントＸ１として、上述のステップＳ２０１に移行する。
【００８７】
そして、セグメント返却部１２は、ステップＳ２０１において、上位プレフィックスセグメントＸ２として「１９２．１６８．２４０．０／２０」を求める。しかし、処理対象セグメントＸ１「１９２．１６８．２４８．０／２１」は、上位プレフィックスセグメントＸ２「１９２．１６８．２４０．０／２０」の先頭ではないため、ここでは、セグメント返却部１２は、ステップＳ２０５に進むことになる。
【００８８】
そして、セグメント返却部１２は、ステップＳ２０５において、処理対象セグメントＸ１「１９２．１６８．２４８．０／２１」の前方セグメントＸ４「１９２．１６８．２４０．０／２１」が、プレフィックスリストＬ２１に未割当セグメントとして登録されているか否かを確認する。ここでは、プレフィックスリストＬ２１に、前方セグメントＸ４「１９２．１６８．２４０．０／２１」は、未割当セグメントとして登録されていないため、セグメント返却部１２は、ステップＳ２０５において、前方セグメントＸ４は未割当セグメントとなっていないと判定して、ステップＳ２０８の処理に移行する。
【００８９】
そして、セグメント返却部１２は、ステップＳ２０８において、処理対象セグメントＸ１「１９２．１６８．２４８．０／２１」を、プレフィックスリストＬ２１に未割当セグメントとして登録して返却処理を終了する。そして、上記の返却処理実行後の未割当領域リスト１３ａの空きアドレスの管理状況は図２のようになる。
【００９０】
（Ａ−３）第１の実施形態の効果
第１の実施形態によれば、以下のような効果を奏することができる。
【００９１】
サーバ１０では、プレフィックス長ごとのセグメントリストを用いることにより、少ない処理量と記憶容量で、ＩＰネットワークＮ上の割当状況（例えば、未割当セグメント）の管理を容易に行うことができる。
【００９２】
ＩＰアドレス空間は非常に膨大であり、社内や通信キャリア内のインフラで利用するプライベート空間も膨大である。セグメントの割当が隙間なく行うことができれば、未割当のセグメント数は非常に少なくなるが、実際にはセグメントの出し入れが多いと、アドレス空間で分断化（フラグメンテーション）が発生する場合がある。アドレス空間で極端な分断化が発生すると、未割当のセグメントに関する情報は膨大となる。その場合、従来技術では、メモリ上のみで管理することは困難であるため、ＩＰアドレス空間を管理するためのデータベースを構築する必要があった。例えば、特許文献１の記載技術では、未割当のセグメントは、データベースに「ＩＤ、セグメントサイズ、ＩＰアドレス」として登録される。そして、特許文献１の記載技術では、例えば、リストの探索はセグメントサイズに「２０」などの値に一致するエントリを検索することにより実現することができる。
【００９３】
これに対して、第１の実施形態のサーバ１０では、プレフィックス長ごとのセグメントリストを管理するだけでよいので、データベース構造を採用しなくても、容易にＩＰアドレス空間のセグメントを管理することができる。
【００９４】
（Ｂ）第２の実施形態
以下、本発明によるアドレス情報管理装置及びプログラムの第１の実施形態を、図面を参照しながら詳述する。以下では、実施形態に係るアドレス情報管理装置をサーバに適用した場合について説明する。また、第１の実施形態では、ＩＰｖ４のＩＰアドレスをセグメント単位で払い出す場合の実施形態を例示して説明する。しかし、ＩＰアドレスはＩＰｖ４に限定されるものではなく、ＩＰｖ６の場合にも本発明を適用することができる。
【００９５】
（Ｂ−１）第２の実施形態の構成
図８は、第２の実施形態のアドレス情報管理装置としてのサーバ１０Ａを有するアドレス情報管理システム１Ａの構成を示すブロック図である。
【００９６】
第２の実施形態のアドレス情報管理システム１Ａでは、サーバ１０がサーバ１０Ａに置き換わっている点で第２の実施形態と異なっている。
【００９７】
また、第２の実施形態のサーバ１０Ａでは、割当領域提案部１４が追加されている点で、第１の実施形態と異なっている。また、第２の実施形態のアドレス情報記憶部１３では、未割当領域リスト１３ａに加えて、割当済領域リスト１３ｂが記憶されている点で第１の実施形態と異なっている。
【００９８】
割当領域提案部１４は、セグメント割当部１１の処理においてユーザ希望サイズのセグメントが空いていない場合に、効率的に確保可能なユーザ希望サイズのセグメントの候補（以下、「提案セグメント」と呼ぶ）を検出し、その提案セグメントに係る情報を提案情報として出力（例えば、ブラウザ端末２０ｗｅｂ画面に表示出力）する提案処理を実行するものである。具体的には、割当領域提案部１４は、すでに割当済のセグメントの一部を解放することで、ユーザ希望サイズの領域が未割当となるセグメントを、提案セグメントとして検出する。
【００９９】
第１の実施形態のアドレス情報記憶部１３では、ＩＰネットワークＮ上のアドレス空間に未割当セグメントを管理するための未割当領域リスト１３ａを記憶していた。これに対して、第２の実施形態のアドレス情報記憶部１３では、未割当領域リスト１３ａに加えて、割当済のセグメントを管理するための割当済領域リスト１３ｂについても記憶している点で第１の実施形態と異なっている。そして、以下では、割当済領域リスト１３ｂにおいて、プレフィックス長１〜３１に対応するプレフィックスリストをプレフィックスリストＬｘ（Ｌｘ１〜Ｌｘ３１）と呼ぶものとする。そして、各プレフィックスリストＬｘは、プレフィックス長を示すデータＤｘと、１又は複数のセグメントに係るセグメントアドレスＳＡｘのデータを有するものとする。
【０１００】
図９は、この実施形態の未割当領域リスト１３ａの内容例について示した説明図である。図１０は、未割当領域リスト１３ａの内容を図９の内容とした場合の割当済領域リスト１３ｂの内容例について示している。
【０１０１】
図９では、未割当領域リスト１３ａに登録されているプレフィックスリストＬ２２〜Ｌ２４について示している。また、図１０では、割当済領域リスト１３ｂに登録されているプレフィックスリストＬｘ２０〜Ｌｘ２４について示している。
【０１０２】
図１０に示す割当済領域リスト１３ｂのプレフィックスリストＬｘ２０〜Ｌｘ２４は、それぞれ割当済のセグメントに係るセグメントアドレスの一覧を示している。
【０１０３】
図１０では、プレフィックスリストＬｘ２０に、セグメントアドレスＳＡｘ２０１が登録されている。また、プレフィックスリストＬｘ２１では、セグメントアドレスＳＡｘ２１１が登録されている。さらに、プレフィックスリストＬｘ２２では、セグメントアドレスＳＡｘ２２１、ＳＡｘ２２２が登録されている。さらにまた、プレフィックスリストＬｘ２３では、セグメントアドレスＳＡｘ２３１、ＳＡｘ２３２、ＳＡｘ２３３が登録されている。また、プレフィックスリストＬｘ２４では、セグメントアドレスＳＡｘ２４１が登録されている。
【０１０４】
例えば、プレフィックスリストＬｘ２０では、セグメントアドレスＳＡｘ２２１として「１９２．１６８．１６．０」が登録されている。これは、「１９２．１６８．１６．０／２０」は割当済のセグメントであることを示している。
【０１０５】
そして、図１１は、図９、図１０のプレフィックスリストで表されるアドレス空間について、特許文献２と同様の方式で視覚的（マトリクス形式）に表した説明図となっている。
【０１０６】
図１１に示すマトリクスでは、「１９２．１６８．０．０／１８」を構成するセグメントを１６行×３２列のマトリクス形式で表している。そして、図１１では、１行で、プレフィックス長が２２のセグメントを表している。図１１では、マトリクスの各行の左側に、当該行に対応するセグメント（プレフィックス長が２２のセグメント）のアドレスをＣＩＤＲ記法で示している。例えば、図１１ではマトリクスの一番上の行から順に「１９２．１６８．０．０／２２」、「１９２．１６８．４．０／２２」、「１９２．１６８．８．０／２２」、…、「１９２．１６８．６０．０／２２」と記載している。
【０１０７】
そして、図１１では、マトリクスにおいて未割当の領域のセルを白く表し、割当済の領域のセルに所定のパターン（模様）が付されている。具体的には、図１１のマトリクスでは、図９に示すプレフィックスリストＬｘ２０〜Ｌｘ２４を構成するセグメントアドレスＳＡｘ２０１、ＳＡｘ２１１、ＳＡｘ２２１、ＳＡｘ２２２、ＳＡｘ２３１、ＳＡｘ２３２、ＳＡｘ２３３、ＳＡｘ２４１のそれぞれに対応するセグメントＳＥＧ２０１、ＳＥＧ２１１、ＳＥＧ２２１、ＳＥＧ２２２、ＳＥＧ２３１、ＳＥＧ２３２、ＳＥＧ２３３、ＳＥＧ２４１の領域に所定のパターンが付されている。
【０１０８】
なお、セグメント割当部１１、及びセグメント返却部１２は、未割当領域リスト１３ａの内容を更新する際には、未割当領域リスト１３ａの内容に対応するように、割当済領域リスト１３ｂの内容も更新するものとする。すなわち、サーバ１０Ａにおいて、未割当領域リスト１３ａの内容と、割当済領域リスト１３ｂの内容とは、同期が取れた状態が維持されるものとする。
【０１０９】
（Ｂ−２）第２の実施形態の動作
次に、以上のような構成を有する第２の実施形態のアドレス情報管理システム１Ａを構成するサーバ１０Ａの動作について第１の実施形態と異なる部分のみを説明する。
【０１１０】
セグメント割当部１１及びセグメント返却部１２の動作については、第１の実施形態とほぼ同様であるので、以下では、割当領域提案部１４の動作を中心について説明する。
【０１１１】
まず、ここでは、ブラウザ端末２０からサーバ１０Ａにアクセスがあり、ユーザ希望サイズを指定したセグメント割当要求があったものとする。具体的には、サーバ１０Ａは、ブラウザ端末２０からのアクセスに応じて、ブラウザ端末２０に、例えば、図１２のようなセグメント割当要求受付画面（Ｗｅｂ画面）を表示させる。
【０１１２】
図１２に示す提案セグメント要求受付画面では、ユーザ希望サイズの入力を受付けるためのフィールドＦ３０１と、提案要求に係る条件を入力するためのフィールドＦ３０２、Ｆ３０３と、セグメントの割当（割当て可能な未割当セグメントが無い場合には提案セグメントの提案）を要求するためのボタンＢ３０１と、サーバ１０からの処理結果を表示出力するためのフィールドＦ３０４が配置されている。
【０１１３】
そして、サーバ１０Ａでは、ブラウザ端末２０（Ｗｅｂブラウザ）からの要求に応じて、セグメント割当部１１により、セグメントの割当処理（図３のフローチャート）の処理が行われたが、ユーザ希望サイズの未割当セグメントが検出できなかったため、割当領域提案部１４による提案処理（図１３のフローチャートの処理）が開始されたものとする。
【０１１４】
なお、図１３のフローチャートの処理では、プレフィックスを示す変数Ｐ２を用いるものとする。
【０１１５】
まず、割当領域提案部１４は、変数Ｐ２の初期値として、ブラウザ端末２０（セグメント割当要求受付画面）から入力されたユーザ希望サイズを設定する（Ｓ３０１）。
【０１１６】
次に、割当領域提案部１４は、変数Ｐ２が閾値（３１）以下であるか否かを判定する（Ｓ３０２）。割当領域提案部１４は、変数Ｐ２が閾値（３１）以下である場合には、後述するステップＳ３０３から動作し、そうでない場合には、これ以上提案セグメントを検出することはできないと判定して処理を終了する。なお、管理するＩＰネットワークＮのアドレス形式がＩＰｖ６だった場合、ステップＳ３０２における閾値は１２７となる。
【０１１７】
上述のステップＳ３０２で、変数Ｐ２が閾値（３１）以下である場合には、割当領域提案部１４は、Ｐ２をインクリメントする（Ｓ３０３）。
【０１１８】
そして、割当領域提案部１４は、未割当領域リスト１３ａを検索して、プレフィックス長がＰ２の未割当セグメントが存在するか否かを確認する（Ｓ３０４）。
【０１１９】
上述のステップＳ３０４で、１つも該当する未割当のセグメントが検出できない場合、割当領域提案部１４は、上述のステップＳ３０２から動作する。一方、割当領域提案部１４は、上述のステップＳ３０４で検出したセグメントのそれぞれについて、後述するステップＳ３０５〜Ｓ３０７の処理を実行する。以下では、上述のステップＳ３０４で検出された任意のセグメントを検出セグメントＸ５と呼ぶものとする。
【０１２０】
ステップＳ３０５で、割当領域提案部１４は、ユーザ希望サイズのプレフィックス長で示されるサブネットマスクアドレスＹ１、及び検出セグメントＸ５を２進数に変換してそれらの論理積を取ったアドレスを算出する。そして、割当領域提案部１４は、算出したアドレスをセグメントアドレスとし、プレフィックス長をユーザ希望サイズとするセグメントを、ユーザに提案するセグメントの候補（以下、「候補セグメントＸ６」と呼ぶ）として保持する。
【０１２１】
例えば、ユーザ希望サイズのプレフィックス長が２１だった場合、サブネットマスクアドレスＹ１は、「２５５．２５５.２４８．０」であり、これを２進数で表記すると「１１１１１１１１ １１１１１１１１ １１１１１０００ ００００００００」となる。
【０１２２】
次に、ステップＳ３０６で、割当領域提案部１４は、割当済領域リスト１３ｂから、候補セグメントＸ６に含まれる割当済のセグメントを検索する。
【０１２３】
割当領域提案部１４は、例えば、以下のような方法で、候補セグメントＸ６に含まれる割当済のセグメントを検索するようにしてもよい。
【０１２４】
割当領域提案部１４は、例えば、割当済領域リスト１３ｂにおいて、ユーザ希望サイズよりもプレフィックス長が長いプレフィックスリストに登録されたセグメントアドレスのそれぞれについて、後述するＶ１、Ｖ２、Ｖ３を算出し、Ｖ１、Ｖ２、Ｖ３が以下の（１）式の関係となる場合、当該セグメントアドレスに係るセグメントが候補セグメントＸ６に含まれるものと判定するようにしてもよい。
【０１２５】
以下の（１）式において「Ｖ１」は、候補セグメントＸ６のセグメントアドレスを１０進数に変換した値である。また、「Ｖ２」は、候補セグメントＸ６のディレクテッドブロードキャストアドレス（候補セグメントＸ６の末尾のＩＰアドレス）を１０進数変換した値である。さらに、「Ｖ３」は、検出セグメントＸ５のセグメントアドレスを１０進数に変換した値である。なお、Ｖ１、Ｖ２、Ｖ３は、８ビットごとに区切ったアドレス表記（１９２．１６８．８．０）ではなく、１つの１０進数の数値である。
【０１２６】
Ｖ１≦Ｖ２＜Ｖ３  …（１）
次に、ステップＳ３０７で、割当領域提案部１４は、候補セグメントＸ６について、割当済セグメントの分布状況に基づき、提案セグメントとするか否かの判定を行う。割当領域提案部１４が候補セグメントＸ６について、提案セグメントとするか否かの判定をする方式は限定されないものであるが、例えば、割当済セグメントの数やサイズ、候補セグメントＸ６に対する割当済セグメントの比率等に基づいて判定するようにしてもよい。具体的には、ここでは、例として、図１２の提案セグメント要求受付画面に示すように、提案セグメントの条件として、割当済セグメントの最大数（フィールドＦ３０２）と、割当済セグメントの最大サイズ（フィールドＦ３０３）が設定されるものとする。
【０１２７】
例えば、割当済セグメントの最大数が１、割当済セグメントの最大サイズが「／２４」だった場合を想定する。この場合、候補セグメントＸ６に、２個以上の割当済セグメントが存在した場合や、２４以上のプレフィックス長の割当済セグメントが存在する場合には、当該候補セグメントＸ６は提案セグメントの条件に当てはまらないものとして判定されることになる。
【０１２８】
以上のステップＳ３０５〜Ｓ３０７の処理により、割当領域提案部１４では提案セグメントが検出される。
【０１２９】
そして、割当領域提案部１４は、上述のステップＳ３０５〜Ｓ３０７のループ処理により、検出された提案セグメントを確認する（Ｓ３０８）。１つも提案セグメントが確認できなかった場合には、割当領域提案部１４は、上述のステップＳ３０２から動作する。一方、１つ以上の提案セグメントが確認できた場合には、割当領域提案部１４は、その提案セグメントに係る情報を出力（ブラウザ端末２０のＷｅｂ画面に出力）して処理を終了する。
【０１３０】
次に、割当領域提案部１４のセグメント返却処理の具体例として、図１３のフローチャートの処理において、未割当領域リスト１３ａ、割当済領域リスト１３ｂの初期状態が、図９、図１０に示す内容だった場合について説明する。
【０１３１】
ここでは、ブラウザ端末２０を利用するユーザにより、アドレス割当要求受付画面で、フィールドＦ３０１（ユーザ希望サイズ）に「／２１」、フィールドＦ３０２（割当済セグメントの最大数）に「１」、フィールドＦ３０３（割当済セグメントの最大サイズ）に「／２４」がそれぞれ入力され、提案要求に係るボタンＢ３０１が押下されたものとする。そして、サーバ１０では、ブラウザ端末２０からの要求に応じて、セグメント割当部１１により、セグメントの割当処理（図３のフローチャート）の処理が行われたものとする。
【０１３２】
プレフィックス「／２１」のＩＰアドレスの割り当てに必要となる領域は、プレフィックス長「／２２」の領域の２倍となる。図１１では、１セルがプレフィックス長「／２７」分の領域、１行がプレフィックス長「／２２」分の領域を示す（図１１の詳細については特許文献２を参照）。したがって、ＩＰネットワークＮ上で、プレフィックス長「／２１」分のセグメントを新たに割当てようとした場合、図１１において、連続する２行分の未割当領域が必要となる。
【０１３３】
したがって、サーバ１０Ａでは、ユーザ希望サイズの未割当セグメントが検出できないため、割当領域提案部１４による提案処理（図１３のフローチャートの処理）が開始されることになる。
【０１３４】
まず、割当領域提案部１４は、ステップＳ３０１で、変数Ｐ２にはユーザ希望サイズ「２１」を設定する。
【０１３５】
そして、この時点で、Ｐ１は３１以下なので、割当領域提案部１４は、ステップＳ３０２からステップＳ３０３に進み、Ｐ１をインクリメント（２１→２２）する。
【０１３６】
そして、割当領域提案部１４は、ステップＳ３０４で、未割当領域リスト１３ａのプレフィックスリストＬ２２を参照して、未割当セグメントの登録を確認する。図９に示すように、この時点で未割当領域リスト１３ａのプレフィックスリストＬ２２には、ＳＡ２２１「１９２．１６８．０．０」、ＳＡ２２２「１９２．１６８．８．０」、ＳＡ２２３「１９２．１６８．３６．０」、ＳＡ２２４「１９２．１６８．４４．０」、ＳＡ２２５「１９２．１６８．６０．０」の５つが存在する。したがって、割当領域提案部１４は、セグメントアドレスＳＡ２２１〜ＳＡ２２５に係るセグメントを検出セグメントＸ５として、ステップＳ３０５〜Ｓ３０７のループ処理を行うことになる。
【０１３７】
図１４は、セグメントアドレスＳＡ２２１〜ＳＡ２２５の各セグメントを検出セグメントＸ５とした場合に、割当領域提案部１４の処理（ステップＳ３０５〜Ｓ３０７のループ処理）で求められる各値（Ｖ１、Ｖ２、Ｖ３）、及び割当済セグメントの内容について示した説明図である。
【０１３８】
ここでは、図１４に示すように、割当済セグメントの最大数が１、割当済セグメントの最大サイズ（プレフィックス長）が「／２４」というユーザ定義条件を満たす候補セグメントＸ６は、「１９２．１６８．５６．０／２１」（割当済セグメント：「１９２．１６８．５７．０／２４」）のセグメントだけとなる。
【０１３９】
したがって、この場合割当領域提案部１４は、「１９２．１６８．５６．０／２１」を提案セグメントとして出力する。具体的には、割当領域提案部１４は、図１２に示すセグメント割当要求受付画面のフィールドＦ３０４に、「希望サイズのセグメントは検出できませんでしたが、提案セグメントとして「１９２．１６８．５６．０／２１」（割当済セグメント：「１９２．１６８．５７．０／２４」）が検出されました」というメッセージを出力するようにしてもよい。その際、割当領域提案部１４は、提案セグメント及びその周辺の割当状況について視覚的に表した画像（例えば、図１１の画像）を出力するようにしてもよい。
【０１４０】
（Ｂ−３）第２の実施形態の効果
第２の実施形態によれば、以下のような効果を奏することができる。
【０１４１】
ＩＰネットワークＮ上で、ユーザ希望サイズの未割当セグメントが存在しない場合には、一部の割当済領域の解放を行う必要があるが、割当領域提案部１４では、未割当領域リスト１３ａを検索することで、ユーザ希望サイズにより近い未割当セグメントを含むセグメント（ユーザ希望サイズのセグメント）を候補セグメントＸ６として検出することができる。また、割当領域提案部１４では、ユーザ定義条件に基づいて、候補セグメントＸ６から提案セグメントを抽出することで、ユーザの所望する条件に合った提案セグメントを出力することができる。
【０１４２】
例えば、ユーザ希望サイズの未割当セグメントが存在しない場合でも、割当済の領域を少し解放するだけで、ユーザ希望サイズのセグメントを確保できる場合があるため、このような場合割当領域提案部１４による提案処理はユーザにとって大きな利便性の向上につながる。
【０１４３】
（Ｃ）他の実施形態
本発明は、上記の各実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【０１４４】
（Ｃ−１）上記の各実施形態のサーバに、さらに、特許文献２のアドレス情報管理システムに係るサーバと同様の機能に対応させるようにしてもよい。例えば、ユーザの操作に応じて、本発明のアドレス情報管理装置のようにプレフィックス長に基づいたセグメント割当を要求する画面と、特許文献２のように視覚的なＧＵＩ（マトリクス）を用いて利用したいセグメントを指定することが可能な画面とを切替えて表示可能とするようにしてもよい。その場合、本発明のアドレス情報管理装置（サーバ）に係るプレフィックスリスト（未割当領域リスト、及び又は割当済領域リスト）と、特許文献２のサーバに係るデータベースとの間で、同一のアドレス空間を示すように更新処理（同期処理）されるようにしてもよい。
【０１４５】
これにより、ＩＰネットワークＮ上で未割当の領域が多い場合には、ユーザは特許文献２の方式によりセグメントの割当を行い、未割当の領域が少ない場合等に本発明の方式によりセグメントの割当処理や提案処理を利用することができる等、利便性が向上する。
【０１４６】
（Ｃ−２）上記の各実施形態では、セグメント割当部及びセグメント返却部は、未割当領域リストを用いて、未割当のセグメントを管理しているが、割当済領域リストを用いて割当済のセグメントを管理することで、間接的に未割当のセグメントの検出及び管理を行うようにしてもよい。
【０１４７】
また、第２の実施形態において、サーバは、未割当領域リスト及び割当済領域リストを保持しているが、いずれか一方のリストだけを保持し、必要に応じて他方のリストを生成して利用するようにしてもよい。
【０１４８】
（Ｃ−３）上記の各実施形態のサーバにおいて、セグメント返却部については省略するようにしてもよい。また、第２の実施形態のサーバでは、セグメント割当部及びセグメント返却部を省略して、割当領域提案部１４だけを備えるようにしてもよい。
【０１４９】
また、第１の実施形態において、セグメント割当部１１では、割当可能なセグメントの情報だけを出力して、実際の未割当領域リストの更新については実行しない（例えば、ユーザ自身が手動で行う）ようにしてもよい。
【０１５０】
（Ｃ−４）上記の各実施形態では、サーバは、割当てたセグメントの情報や、提案セグメントの情報等の出力情報を、ブラウザ端末（Ｗｅｂ画面）に出力するようにしているが、他の出力方法に対応するようにしてもよい。例えば、サーバは、出力情報を、所定の電子メールアドレス宛てに出力（メール送信）するようにしてもよい。
【符号の説明】
【０１５１】
１…アドレス情報管理システム、１０…サーバ、１１…セグメント割当部、１２…セグメント返却部、１３…アドレス情報記憶部、１３ａ…未割当領域リスト、２０…ブラウザ端末、２１…制御部、２２…入出力部、２３…通信部。
【要約】
【課題】  ＩＰアドレス空間上で、任意のサイズの割当可能なセグメントを容易に探索することができるアドレス情報管理装置を提供する。
【解決手段】  本発明は、ＩＰネットワーク上のアドレス空間を管理するアドレス情報管理装置に関する。そして、アドレス情報管理装置は、アドレス空間のアドレス表記に用いるプレフィックス長ごとに、当該プレフィックス長に係るセグメントのリストを保持するリスト保持手段と、リスト保持手段が保持しているプレフィックス長ごとのリストを参照することにより、アドレス空間で割当可能なセグメントを探索することが可能なセグメント探索手段とを有することを特徴とする。
【選択図】      図１【図１】
0005432346.tif 000002
【図２】
0005432346.tif 000003
【図３】
0005432346.tif 000004
【図４】
0005432346.tif 000005
【図５】
0005432346.tif 000006
【図６】
0005432346.tif 000007
【図７】
0005432346.tif 000008
【図８】
0005432346.tif 000009
【図９】
0005432346.tif 000010
【図１０】
0005432346.tif 000011
【図１１】
0005432346.tif 000012
【図１２】
0005432346.tif 000013
【図１３】
0005432346.tif 000014
【図１４】
0005432346.tif 000015