(57)【要約】      （修正有）【課題】  複数の学校の学生について学業成績や異動を一括管理でき、その情報にリンクさせて奨学金支払いや返還の状況をも管理できる学生基本台帳管理方法を提供する。【解決手段】  学生支援機構１には学生基本台帳データベース３を備え、学校２のそれぞれに入学手続を行う窓口８と各学生の入学、学業成績及び異動の情報を学生支援機構１に通知する通知手段９とを備え、窓口８で作成した個人情報を上記学生支援機構１に通知するステップと、学生支援機構１で個人情報に基づいて当該学生の欄を学生基本台帳データベース３に開設して学校と年度を当該学生の欄に書き込むステップと、学校から通知される学業成績を当該学生の欄に追加していくステップと、学校から通知される卒業の情報と年度を当該学生の欄に追加する卒業書き込みのステップと、任意の学生について学生基本台帳データベース３を検索して学業成績又は異動を読み出すステップとを有する。【選択図】  図１
2006164139.tif 000002
【特許請求の範囲】
【請求項１】
どの学校にも属さず独立した学生支援機構に学生のデータを格納するための学生基本台帳データベースを備え、一方、複数の学校のそれぞれに入学手続を行う窓口を備えると共に各学生の入学、学業成績、異動及び卒業の情報を上記学生支援機構に通知する通知手段を備え、上記窓口で作成した当該学生の個人情報を上記学生支援機構に通知する入学手続のステップと、上記学生支援機構で上記個人情報に基づいて当該学生の欄を上記学生基本台帳データベースに開設して当該学生が入学した学校と年度を当該学生の欄に書き込む学生登録のステップと、上記学校から通知される当該学生の学業成績情報に基づき学業成績を当該学生の欄に追加していく成績記入のステップと、上記学校から通知される当該学生の異動の情報と年度を当該学生の欄に追加する異動書き込みのステップと、上記学校から通知される当該学生の卒業の情報と年度を当該学生の欄に追加する卒業書き込みのステップと、任意の学生について上記学生基本台帳データベースの当該学生の欄を検索して当該学生の学業成績、異動又は卒業の情報を読み出す検索のステップとを有することを特徴とする学生基本台帳管理方法。
【請求項２】
上記学生支援機構で学歴証明書の交付願いを受け付ける学歴証明書交付願いのステップと、上記検索のステップによる読み出し結果に基づいて学歴証明書を交付する学歴証明書交付のステップを有することを特徴とする請求項１記載の学生基本台帳管理方法。
【請求項３】
上記学生支援機構で学生の就職先の通知を受け取る就職先通知のステップと、通知された就職先を当該学生の欄に追加する就職先書き込みのステップを有することを特徴とする請求項１又は２記載の学生基本台帳管理方法。
【請求項４】
上記学生支援機構に奨学生のデータを格納するための奨学管理データベースを備え、上記窓口で入学手続に併せて奨学申請を行った学生について個人情報を上記学生支援機構に通知する奨学申請のステップと、上記学生支援機構で上記個人情報に基づいて当該奨学生の欄を上記奨学管理データベースに開設する奨学生登録のステップと、上記奨学管理データベース内の奨学生について上記学生基本台帳データベースに対し上記検索のステップを用い当該奨学生の現在状況（学業成績と異動）を確認する確認のステップと、所定の支給日が来るたびに当該奨学生の現在状況が所定の奨学金支給条件を満たしていれば所定額の奨学金を支給する奨学金支給のステップとを有することを特徴とする請求項１〜３いずれか記載の学生基本台帳管理方法。
【請求項５】
上記学生支援機構に奨学金の返還に関するデータを格納するための返還管理データベースを備え、上記奨学管理データベースに登録されている奨学生について上記確認のステップにより確認した現在状況が所定の奨学金返還条件を満たす奨学生（以後、返還対象者となる）を抽出する返還対象者抽出のステップと、当該返還対象者の欄を上記奨学管理データベースから上記返還管理データベースに移設する返還管理開始のステップと、上記返還管理データベースに登録されている返還対象者に対して所定の時期に所定額の返還を請求する請求書を発行する返還請求のステップと、請求書発行後、所定の期日までに返還金が入金されなかった又は入金されたときに当該返還対象者の欄に返還実績情報（入金金額、未納期間、返還残額など）を書き込む返還実績情報更新のステップとを有することを特徴とする請求項４記載の学生基本台帳管理方法。
【請求項６】
上記返還管理データベースに記録されている返還実績情報に基づいて返還実績が所定の不良基準に達した返還対象者（以下、返還不良者と呼ぶ）を抽出する返還不良者抽出のステップと、その返還不良者について上記学生基本台帳データベースの当該学生（返還不良者）の欄に返還不良の情報を書き込む返還不良書き込みのステップを有することを特徴とする請求項５記載の学生基本台帳管理方法。
【請求項７】
上記学生支援機構に保証料に関するデータを格納するための保証料管理データベースを備え、上記奨学申請に併せて保証申請を行った奨学生（以下、保証奨学生と呼ぶ）についてその個人情報に基づいて当該保証奨学生の欄を保証料管理データベースに開設する保証登録のステップと、上記奨学金支給のステップを実施するときに、上記保証料管理データベースを参照して当該奨学生が保証奨学生であれば支給額から所定の保証料を天引きし、天引き額を上記保証料管理データベースに累積する保証料付替えのステップとを有することを特徴とする請求項４〜６いずれか記載の学生基本台帳管理方法。
【請求項８】
上記学生支援機構に求償権に関するデータを格納するための求償権管理データベースを備え、上記返還管理データベースに記録されている返還実績情報に基づいて返還実績が所定の代位弁済基準に達した返還対象者（以下、負債者と呼ぶ）を抽出する負債者抽出のステップと、当該負債者の欄を上記返還管理データベースから上記求償権管理データベースに移設する代位弁済申請のステップと、上記返還管理データベースに記録されていた当該負債者の返還残額を上記求償権管理データベースに移して負債額として記録する代位弁済実行のステップと、その負債者について上記学生基本台帳データベースの当該学生（負債者）の欄に負債者であるという情報を書き込む負債者書き込みのステップとを有することを特徴とする請求項５又は６記載の学生基本台帳管理方法。
【請求項９】
所定の時期に上記求償権管理データベースに登録されている負債者に対して返済を請求する請求書を発行する返済請求のステップと、返済金が入金受領されたときに当該負債者の負債額を減じる返済実績情報更新のステップとを有することを特徴とする請求項８記載の学生基本台帳管理方法。
【請求項１０】
記学歴証明書交付願いのステップが行われた際に行う上記検索のステップの結果、当該学生の欄に返還不良又は負債者の情報が記載されていた場合、上記学歴証明書交付のステップを取り止める交付停止のステップを有することを特徴とする請求項６又は８記載の学生基本台帳管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の学校の学生について学業成績や異動、卒業を一括管理でき、その情報にリンクさせて奨学金支払いや返還の状況をも管理できる学生基本台帳管理方法に関する。
【背景技術】
【０００２】
学校（４年制・２年制大学、高等学校、義務教育、全日制、定時制、通信制を問わず、大学院、専門学校も含む）において、学生の氏名、生年月日、住所などの個人を特定できる情報（個人情報）を学籍名簿に記載し、その学籍名簿に学業成績（科目ごとの評価、取得単位数、特記事項など）や異動（休学、復学、転校、転科など）、卒業（卒業、退学、死亡など）を追記していくことは一般に行われている。近年では、こうした学籍名簿がコンピュータを利用したデータベースとして作られる。特許文献２や特許文献３には在学生に対して学生証を発行する技術が示されているが、これを発展させて在学生や卒業生が卒業証明書、成績証明書、在学証明書などの学歴証明書を必要とするときに、データベースを個人情報で検索してその読み出し結果に基づいて学歴証明書を交付できるようにすると便利である。
【０００３】
一方、学生に対し奨学金を支給する種々の支援者（企業、財団、公的機関、個人、学校など）が存在し、奨学金を必要とする学生からの申し込みを受けて奨学金を支給することが行われている。奨学金は返還を必要としないものもあれば、卒業後直ちにあるいは所定の猶予期間の後に返還を必要とするものもある。こうした奨学金の支給や返還の管理は支援者において奨学生名簿を作成して行われている。これに関する先行技術文献はないが、奨学生名簿も前述した学籍名簿と同様にデータベース化しておくと便利である。
【０００４】
【特許文献１】特開平１１−２５９５６３号公報
【特許文献２】特開平１０−３５０５号公報
【特許文献３】特開２００１−２８２９３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、学校はそれぞれ他の学校から独立した機関であって、学籍名簿データベースも当然、学校ごとに独自のものが構築される。従って、学歴証明書交付の申請も当該学校に対して行われ、当該学校が学歴証明書を交付している。既に卒業して遠隔地にいる卒業生が学歴証明書をもらうには、その学校に請求をしなければならない。こうした手続を電子化し、個人のパソコンからウェブ上の窓口にアクセスして、あるいはコンビニエンスストアなどの代理窓口から申請や交付ができるようにすることは技術的に可能である。ところが、近年、学生人口の減少に伴い学校の統廃合が加速されつつある。廃校によって学校が無くなってしまうと、過去の卒業生は学歴証明書の交付を受けられなくなる。これは社会的問題になりつつある。
【０００６】
また、従来、学籍名簿をそれぞれの学校が保有し管理しているので、上記の手続を電子化するにしてもその電子化窓口の開設はそれぞれの学校で行わなくてはならず、労力の無駄が大きい。そして、近年のように学校規模が縮小するなかで、学籍名簿の管理業務や学歴証明書の交付業務及びこれらに要する費用を軽減したいという要望がある。
【０００７】
また、従来、学校ごとに学籍名簿や学歴証明書を作成しているため、学歴証明書の様式（紙の大きさ、書式レイアウト、記載項目）が学校ごとに異なってしまう。このように学歴証明書の様式がまちまちであると、企業の採用人事などで複数の学生から学歴証明書を集めて比較審査を行うときに比較がやりにくい。
【０００８】
以上のように、学校ごとに学生の学業成績や異動を管理する従来の方法には、種々の問題がある。これに対して、地域住民の個人情報を一括して国全体を対象とする住民基本台帳に登録しておくことで、住民票の発行を簡便にする方法が特許文献１に開示されている。
【０００９】
しかし、住民基本台帳の技術を学籍名簿に応用して複数の学校の学生について学業成績や異動、卒業を一括管理しようとしても、複数の学校を統括する母体（つまり複数の学校の学生を登録するデータベースを設備し管理する機関）がないため、実現が困難である。
【００１０】
また、住民管理の分野では、住民が自治体間を移動するという事情を踏まえ、その移動によらず安定した情報であるコード番号のみを住民基本台帳で管理し、住民票や印鑑登録証明は移動先の自治体でを交付する。これに対し、学生が学校間を移動することはなく、その半面、学生の学業成績や異動、卒業は絶えず新しく変化していく。こうした変化する情報を一括管理し、証明書の交付も各々の大学で行うのでなく一本化しようというのが本発明の目的である。このような違いのため、住民基本台帳の技術は本発明に応用することはできない。
【００１１】
一方、奨学金に関する問題点は以下の通りである。
【００１２】
支援者は学校とは独立した存在である。従って、支援者が保有する奨学生名簿と学校の学籍名簿とは相互に全く無関係である。同一人物（つまり個人情報が同じ）であっても奨学生名簿には奨学生としてのデータが記録され、学籍名簿には学生としてのデータが記録され、奨学生名簿から学籍名簿を参照することはできない。このため、支援者が学業成績を把握することはできないし、奨学生に異動、卒業があったときも、奨学生からの自己申告がない限り、支援者が異動、卒業を把握することができない。学業成績や異動、卒業が把握できないということは、奨学生の現在状況が所定の奨学金支給条件を満たしているかどうか、あるいは奨学生の現在状況が所定の奨学金返還条件を満たして返還対象者となったかどうかを迅速かつ的確に知ることができないということである。こうした理由で返還金の回収が遅滞することによって奨学金資金源の運用効率が低下することは好ましくない。
【００１３】
また、奨学金返還に関する管理においても、返還対象者が現在、返還可能な状況にあるか否か（例えば、就労しているか否か）を支援者が把握できないのが現状である。その一方で、学校を卒業しても長らく就職せず奨学金返還が困難な人が多く存在したり、就職してもその報告を怠り奨学金返還を逃れるというケースも見られる。このため、奨学金資金源が不足する傾向にある。
【００１４】
そこで、本発明の目的は、上記課題を解決し、複数の学校の学生について学業成績や異動、卒業を一括管理でき、その情報にリンクさせて奨学金支払いや返還の状況をも管理できる学生基本台帳管理方法を提供することにある。
【課題を解決するための手段】
【００１５】
上記目的を達成するために本発明は、どの学校にも属さず独立した学生支援機構に学生のデータを格納するための学生基本台帳データベースを備え、一方、複数の学校のそれぞれに入学手続を行う窓口を備えると共に各学生の入学、学業成績、異動及び卒業の情報を上記学生支援機構に通知する通知手段を備え、上記窓口で作成した当該学生の個人情報を上記学生支援機構に通知する入学手続のステップと、上記学生支援機構で上記個人情報に基づいて当該学生の欄を上記学生基本台帳データベースに開設して当該学生が入学した学校と年度を当該学生の欄に書き込む学生登録のステップと、上記学校から通知される当該学生の学業成績情報に基づき学業成績を当該学生の欄に追加していく成績記入のステップと、上記学校から通知される当該学生の異動の情報と年度を当該学生の欄に追加する異動書き込みのステップと、上記学校から通知される当該学生の卒業の情報と年度を当該学生の欄に追加する卒業書き込みのステップと、任意の学生について上記学生基本台帳データベースの当該学生の欄を検索して当該学生の学業成績、異動又は卒業の情報を読み出す検索のステップとを有するものである。
【００１６】
上記学生支援機構で学歴証明書の交付願いを受け付ける学歴証明書交付願いのステップと、上記検索のステップによる読み出し結果に基づいて学歴証明書を交付する学歴証明書交付のステップを有してもよい。
【００１７】
上記学生支援機構で学生の就職先の通知を受け取る就職先通知のステップと、通知された就職先を当該学生の欄に追加する就職先書き込みのステップを有してもよい。
【００１８】
上記学生支援機構に奨学生のデータを格納するための奨学管理データベースを備え、上記窓口で入学手続に併せて奨学申請を行った学生について個人情報を上記学生支援機構に通知する奨学申請のステップと、上記学生支援機構で上記個人情報に基づいて当該奨学生の欄を上記奨学管理データベースに開設する奨学生登録のステップと、上記奨学管理データベース内の奨学生について上記学生基本台帳データベースに対し上記検索のステップを用い当該奨学生の現在状況（学業成績と異動）を確認する確認のステップと、所定の支給日が来るたびに当該奨学生の現在状況が所定の奨学金支給条件を満たしていれば所定額の奨学金を支給する奨学金支給のステップとを有してもよい。
【００１９】
上記学生支援機構に奨学金の返還に関するデータを格納するための返還管理データベースを備え、上記奨学管理データベースに登録されている奨学生について上記確認のステップを行うことにより現在状況が所定の奨学金返還条件を満たす奨学生（以後、返還対象者となる）を抽出する返還対象者抽出のステップと、当該返還対象者の欄を上記奨学管理データベースから上記返還管理データベースに移設する返還管理開始のステップと、上記返還管理データベースに登録されている返還対象者に対して所定の時期に所定額の返還を請求する請求書を発行する返還請求のステップと、請求書発行後、所定の期日までに返還金が入金されなかった又は入金されたときに当該返還対象者の欄に返還実績情報（入金金額、未納期間、返還残額など）を書き込む返還実績情報更新のステップとを有してもよい。
【００２０】
上記返還管理データベースに記録されている返還実績情報に基づいて返還実績が所定の不良基準に達した返還対象者（以下、返還不良者と呼ぶ）を抽出する返還不良者抽出のステップと、その返還不良者について上記学生基本台帳データベースの当該学生（返還不良者）の欄に返還不良の情報を書き込む返還不良書き込みのステップを有してもよい。
【００２１】
上記学生支援機構に保証料に関するデータを格納するための保証料管理データベースを備え、上記奨学申請に併せて保証申請を行った奨学生（以下、保証奨学生と呼ぶ）についてその個人情報に基づいて当該保証奨学生の欄を保証料管理データベースに開設する保証登録のステップと、上記奨学金支給のステップを実施するときに、上記保証料管理データベースを参照して当該奨学生が保証奨学生であれば支給額から所定の保証料を天引きし、天引き額を上記保証料管理データベースに累積する保証料付替えのステップとを有してもよい。
【００２２】
上記学生支援機構に求償権に関するデータを格納するための求償権管理データベースを備え、上記返還管理データベースに記録されている返還実績情報に基づいて返還実績が所定の代位弁済基準に達した返還対象者（以下、負債者と呼ぶ）を抽出する負債者抽出のステップと、当該負債者の欄を上記返還管理データベースから上記求償権管理データベースに移設する代位弁済申請のステップと、上記返還管理データベースに記録されていた当該負債者の返還残額を上記求償権管理データベースに移して負債額として記録する代位弁済実行のステップと、その負債者について上記学生基本台帳データベースの当該学生（負債者）の欄に負債者であるという情報を書き込む負債者書き込みのステップとを有してもよい。
【００２３】
所定の時期に上記求償権管理データベースに登録されている負債者に対して返済を請求する請求書を発行する返済請求のステップと、返済金が入金受領されたときに当該負債者の負債額を減じる返済実績情報更新のステップとを有してもよい。
【００２４】
上記学歴証明書交付願いのステップが行われた際に行う上記検索のステップの結果、当該学生の欄に返還不良又は負債者の情報が記載されていた場合、上記学歴証明書交付のステップを取り止める交付停止のステップを有してもよい。
【発明の効果】
【００２５】
本発明は次の如き優れた効果を発揮する。
【００２６】
（１）複数の学校の学生について学業成績や異動、卒業を一括管理できる。
【００２７】
（２）複数の学校の学生の学業成績や異動、卒業の情報にリンクさせて奨学金支払いや返還の状況をも管理できる。
【発明を実施するための最良の形態】
【００２８】
以下、本発明の一実施形態を添付図面に基づいて詳述する。
【００２９】
図１に、本発明に係る学生基本台帳管理方法を用いた学生基本台帳管理システムの概要を示す。
【００３０】
まず、この学生基本台帳管理システムに必要な社会的機関（法人など）と、各社会的機関に設置されるハードウェアについて説明する。
【００３１】
必要な社会的機関は支援者と学校である。支援者は、背景技術の欄に例示したどの支援者でも本システムを実施できるが、ここでは、支援者を学生支援機構１という名称で呼ぶことにする。本システムを日本で構築する場合、学生支援機構１は文部科学省の管理下に置かれた独立行政法人であることが好ましい。学校は背景技術の欄に例示したどの学校でも対象とできるが、ここでは、説明を簡単にするため、大学２のみを対象とすることにする。図１には大学２が１つしか書かれていないが、これは本システムに加入している複数（全ての大学が加入するのが望ましい）の大学のうちのひとつを表している。管理の対象となる学生Ｓは海外からの留学生も含むが、ここでは、説明を簡単にするため、日本在住で日本国籍のある人とする。社会人Ｓ’は学生Ｓと同一人物である。
【００３２】
学生支援機構１には、学生基本台帳データベース３、奨学管理データベース４、返還管理データベース５、保証料管理データベース６、求償権管理データベース７が設置される。これらのデータベース３〜７の記憶内容（データ）については後に詳細を説明する。なお、保証料管理データベース６と求償権管理データベース７は、学生支援機構１とは法的及び経済的に独立した別の管理組織に設けるのが好ましい。
【００３３】
また、図示してはいないが、学生支援機構１には、卒業証明書、成績証明書、在学証明書などの各種学歴証明書を所定の様式（紙の大きさ、書式レイアウト、記載項目）で印刷すること、償還請求書、返済請求書などの各種請求書を印刷すること、これらの印刷物を封書化すると共に宛名を印刷することなどが可能な印刷機が設置される。さらに、学生支援機構１には、上記データベース３〜７を職員がマニュアルで検索したり、データベース３〜７を保守管理したりするための管理端末装置が設置される。さらに、学生支援機構１には、後述する各大学の端末装置や事業所の端末装置と高いセキュリティを維持してデータ通信するための通信機器が設けられる。これら、印刷機、管理端末装置、通信機器については、一般的なものを使用できるので、詳細は説明しない。
【００３４】
また、これらのデータベース３〜７を制御して後述する本発明の各ステップを実行するコンピュータ装置が学生支援機構１に設置され、このコンピュータ装置にはデータベース３〜７を検索するための検索エンジンが搭載されるが、コンピュータ装置や検索エンジンには特に特徴がないので、図示していない。
【００３５】
各大学２には、入学手続及び奨学申請を行う窓口８と、各学生に関する種々の情報を学生支援機構１に通知する通知手段９とが設置される。窓口８とは、各大学において入学手続を行う場所に設置された端末装置のことである。ウェブ上で入学手続を行う電子窓口も窓口に含む。通知手段９は各大学の管理部署に設置された端末装置のことである。窓口８と通知手段９を同じ端末装置で実現することもできる。なお、大学２には背景技術の欄で述べた大学独自の学籍名簿データベース１０を備えてもよく、この学籍名簿データベース１０から吸い上げた種々の情報を学生支援機構１に通知するようにしてもよい。しかし、業務と費用を軽減する目的からすれば、大学２には学籍名簿データベース１０を置かず、随時、端末装置から学生支援機構１の学生基本台帳データベース３にアクセスするように構成するのが好ましい。この場合、例えば、大学２で学生証を発行するに際し、学生証の発行に必要なデータを学生基本台帳データベース３から取得すればよい。
【００３６】
本システムに関与するもう一つの社会的機関は就職先である。人は様々な就職先に就職するので、ここでは、代表として事業所１１が存在するものとする。事業所１１には、学生支援機構に対して学歴証明書の交付願いや就職先通知を送信するための端末装置（図示せず）が設置される。事業所１１の端末装置は、本システムのために特別なハードウェア及びソフトウェアを具備する必要はなく、一般的なパソコン及び通信ソフトがあればよい。それは、学生支援機構１が開設したウェブページにアクセスすることで手続が始められるからである。なお、本システムを効果的に運用するためには、事業所１１が人を採用するときに卒業証明の取得することを義務づけるよう法制化しておくことが望ましい。
【００３７】
次に、本システムでは、各端末装置で入力・通知されるデータや各データベース３〜７に記録されるデータに特色があるので、それぞれのデータについて説明する。
【００３８】
図２に示されるように、窓口８で作成されるデータには、入学手続及び奨学申請する学生の個人情報がある。個人情報とは、その学生個人を特定する情報のことであり、少なくとも氏名と生年月日を含む。このほかに、学生の現住所、戸籍、扶養者あるいは保護者の氏名と連絡先などが個人情報に含まれるとよい。通信手段９から学生支援機構１に送る入学手続の情報には、窓口８で作成した個人情報に大学名（学部、学科、キャンパス名なども含む）と入学年度が付加される。通信手段９から学生支援機構１に送る奨学申請の情報は、基本的に入学手続の情報と同じであるが、扶養者の年収など奨学生認定の審査に関わる情報が付加されてもよい。
【００３９】
図３に示されるように、入学以後に大学で作成されるデータには、学業成績の情報と異動の情報と卒業の情報がある。学業成績の情報には、少なくとも科目ごとの評価、取得単位数が含まれ、さらには、賞罰などの特記事項が含まれてもよい。学業成績の情報は学期末、年度末の評価が確定したときに個人情報と共に通信手段９から学生支援機構１に通知される。異動の情報は、休学、復学、転校、転科などの身分変化を表した情報である。卒業の情報は、卒業、退学、死亡などの身分変化を表した情報である。異動の情報及び卒業の情報は、その変化が生じた時点で随時、個人情報と共に通信手段９から学生支援機構１に通知される。
【００４０】
図には示さないが、事業所１１から学生支援機構１に送るデータとして、学歴証明書の交付願いに必要なデータ（就職する学生の個人情報、事業所名など）、学生の就職先を通知するデータ（個人情報、事業所名、配属部署など）がある。
【００４１】
図４に示されるように、学生基本台帳データベース３に記録されるデータには、ＩＤ、学生の個人情報、既に述べた大学名、入学年度等の情報、学業成績の情報、異動の情報、卒業の情報、そして後述する就職先、返還不良、負債者等の情報などがある。入学手続の際に、個人情報に基づいて当該学生の欄を開設することで登録が行われ、同時に大学名、入学年度等が書き込まれる。以後は主としてＩＤまたは個人情報でもって検索が行われ、学業成績、異動、卒業、就職先、返還不良、負債者等の情報が随時、追加・更新される。ＩＤ及び個人情報は、後述する他のデータベースにも転写されて使用される。
【００４２】
なお、個人情報は、個人固有情報と属性情報に分けてもよい。個人固有情報とは絶対に変わらない情報のことであり、生年月日と性別（例外有り）がこれに該当する。属性情報とは、変化があり得る情報のことであり、住所、氏名、戸籍、結婚の有無などがこれに含まれる。
【００４３】
図５に示されるように、奨学管理データベース４に記録されるデータには、学生基本台帳データベース３と同様のＩＤ、個人情報及び大学名、入学年度がある。奨学申請の際に、個人情報に基づいて当該奨学生の欄を開設することで登録が行われる。奨学管理データベース４の奨学生の欄には、奨学金支給実績（支給額、支給期間、支給累積額など）の情報を随時追加することができる。なお、奨学管理データベース４と学生基本台帳データベース３とに同じ個人情報を持つ欄があることで、両データベースから同一人物のデータを検索することができる。しかし、同姓同名、同一生年月日を持つ複数の人が存在することも考慮する必要がある。そこで、登録時に奨学管理データベース４における当該奨学生の欄と学生基本台帳データベース３における当該学生の欄との間にリンク（紐付け）を形成しておくと、その後、奨学管理データベース４の任意の奨学生について学生基本台帳データベース３の当該学生の欄を容易にかつ間違いなく検索することができる。ＩＤを利用してリンクを形成してもよい。
【００４４】
図６に示されるように、返還管理データベース５に記録されるデータには、奨学管理データベース４から移設されたＩＤ、個人情報及び大学名、入学年度、奨学金支給実績などがある。奨学管理データベース４に記録されている現在状況が所定の奨学金返還条件を満たした奨学生は、以後、返還対象者となり、奨学管理データベース４の当該奨学生の欄が返還管理データベース５に返還対象者の欄として移設される。奨学管理データベース４と学生基本台帳データベース３との間にあったリンクは移設後も維持されるので、返還管理データベース５の任意の返還対象者について学生基本台帳データベース３の当該学生の欄を検索することができる。返還管理データベース５の返還対象者の欄には、請求書発行実績（請求額、日付など）の情報、返還実績（入金金額、未納期間、返還残額など）の情報が随時書き込まれる。
【００４５】
図７に示されるように、保証料管理データベース６に記録されるデータには、ＩＤ、個人情報及び大学名、入学年度がある。奨学申請の際に併せて保証申請を行うと、個人情報に基づいて当該保証奨学生の欄を開設することで登録が行われる。保証料管理データベース６の保証奨学生の欄には、天引き額と累積天引き額が随時書き込まれる。
【００４６】
図８に示されるように、求償権管理データベース７に記録されるデータには、返還管理データベース５から移設されたＩＤ、個人情報及び大学名、入学年度、奨学金支給実績、返還実績などがある。返還管理データベース５に記録されている返還実績が所定の代位弁済基準に達すると、その返還対象者は、以後、負債者となり、返還管理データベース５の当該返還対象者の欄が求償権管理データベース７に負債者の欄として移設される。返還管理データベース５と学生基本台帳データベース３との間にあったリンクは移設後も維持されるので、このリンクを用いて求償権管理データベース７の任意の負債者について学生基本台帳データベース３の当該学生の欄を検索することができる。求償権管理データベース７の負債者の欄には、返済請求書発行実績（請求額、日付など）の情報、返済実績（入金受領日付、負債額など）が随時書き込まれる。
【００４７】
なお、本実施の形態においては、返還金及び負債にかかる金利並びに手数料については省略してある。
【００４８】
以上説明したシステム構成を踏まえ、図１の学生基本台帳管理システムの動作を手順に従って説明する。
【００４９】
まず、第一のケースとして、学生Ｓが大学２の窓口８で入学手続を行い、奨学申請は行わないケースを説明する。
【００５０】
学生Ｓが氏名、生年月日等を窓口８に提出すると、窓口８では端末装置によりその提出内容に基づいて個人情報を作成する。通知手段９は図２の入学手続の情報を学生支援機構１へ送信する（入学手続のステップ）。学生支援機構１では、受信した個人情報に基づいて当該学生の欄を学生基本台帳データベース３に開設し、図４のように、当該学生が入学した学校と年度を当該学生の欄に書き込む。これにより学生Ｓが登録されたことになる（学生登録のステップ）。
【００５１】
その後、年月が経過するに従い、大学２の通知手段９は、各学生Ｓについて図３の学業成績の情報を学生支援機構１へ通知する。これを受けて学生支援機構１では、通知された当該学生の学業成績情報に基づき学業成績を学生基本台帳データベース３の当該学生の欄に追加する（成績記入のステップ）。
【００５２】
また、大学２の通知手段９は、学生Ｓに異動があったとき、当該学生の異動の情報を学生支援機構１へ通知する。これを受けて学生支援機構１では、通知された当該学生の異動の情報と年度を学生基本台帳データベース３の当該学生の欄に追加する（異動書き込みのステップ）。
【００５３】
同様に、大学２の通知手段９は、学生Ｓが卒業や退学したとき、当該学生の卒業の情報を学生支援機構１へ通知する。これを受けて学生支援機構１では、通知された当該学生の異動の情報と年度を学生基本台帳データベース３の当該学生の欄に追加する（卒業書き込みのステップ）。
【００５４】
これら学業成績、異動情報、卒業情報の追加は、学生Ｓが大学２に在籍している間、継続的に行われ、卒業、退学、その他により、在籍が終了するまで続けられる。
【００５５】
学生支援機構１では、学生Ｓが大学２に在籍している間も、在籍が終了した後も、任意の学生について学生基本台帳データベース３の当該学生の欄を検索することができる。すなわち、当該学生の欄に書かれている学業成績や異動、卒業の情報を読み出すことができる（検索のステップ）。読み出した学業成績や異動、卒業の情報がその時点での当該学生の現在状況を表している。
【００５６】
現在在籍する又は過去に在籍した学生Ｓは、いつでも個人的にあるいは大学を通じて学生支援機構１に対して学歴証明書交付願いを出すことができる。また、学生Ｓが就職しようとしている事業所１１から学生支援機構１に対して学歴証明書交付願いを出すことができる。図１には事業所１１が行う例が示されている。これを受けて学生支援機構１では、学歴証明書の交付願いを受け付ける（学歴証明書交付願いのステップ）。なお、このステップにおいては、交付願いを出した人が本人であることを証明する何らかの方法が必要であるが、それについては本実施の形態では省略してある。他のステップについても、データのセキュリティについては省略してある。
【００５７】
学生支援機構１では、既に説明した検索のステップを行い、学生基本台帳データベース３から当該学生Ｓの学業成績や異動の情報を読み出す。この読み出し結果に基づいて、図示しない印刷機により所定の様式にて学歴証明書を印刷し、交付する（学歴証明書交付のステップ）。このとき、学歴証明書には、卒業証明書、成績証明書、在学証明書などの種類があって、それぞれ記入する内容が異なるが、学生基本台帳データベース３には全ての種類の学歴証明書に必要な情報が記録されているので、その中から種類ごとに必要な情報を取り出して印刷に供すればよい。
【００５８】
このようにして、学歴証明書が願い人（図１の例では事業所１１）に郵送にて交付される。なお、従来のように大学が個別に学歴証明書を交付する場合、学歴証明書には学長印が押捺されるが、本システムでは学生支援機構１が学歴証明書を交付するので、学歴証明書には学生支援機構長印が押捺される。この押捺印の権威を保証するために、学生支援機構１は法律によって認定されていることが望ましい。また、学歴証明書には偽造の防止策なども必要であるが、それについては本実施の形態では省略してある。
【００５９】
その後、学生Ｓが事業所１１に採用されると、事業所１１あるいは学生Ｓ本人が学生支援機構１へ就職先を通知する。学生支援機構１では、通知された就職先を端末装置入力する（就職先通知のステップ）。そして、学生支援機構１では、通知された就職先を学生基本台帳データベース３の当該学生の欄に追加する（就職先書き込みのステップ）。就職先が追加されたことにより、以後、検索のステップを行うと、当該学生の現在状況として、前述の学業成績や異動の情報に加えて就職したという事象及び就職先が分かることになる。
【００６０】
次に、第二のケースとして、学生Ｓが大学２の窓口８で入学手続と奨学申請を行うケースを説明する。入学手続については第一のケースと同じ流れになる。窓口８では、入学手続で作成した個人情報を奨学申請に使用する。また、奨学申請に関しては認定審査情報も窓口８で作成する。通知手段９は図２の奨学申請の情報を学生支援機構１へ送信する（奨学申請のステップ）。学生支援機構１では、受信した奨学申請の情報（個人情報と認定審査情報）に基づいて当該奨学生の欄を上記奨学管理データベースに開設する（奨学生登録のステップ）。なお、実際には認定審査を行って認定された学生Ｓのみが奨学生となるが、認定審査については本実施の形態では省略してある。
【００６１】
このとき、好ましくは、学生支援機構１において、奨学管理データベース４における当該奨学生の欄と学生基本台帳データベース３における当該学生の欄との間にリンクを形成する（リンク付けのステップ）。ここで、リンク（紐付け）とは奨学管理データベース４中のひとまとまりのデータと学生基本台帳データベース３中のひとまとまりのデータとを１対１で対応付けて一方を指定すれば他方が自動的に決まるようにすることである。簡単には、学生基本台帳データベース３に学生Ｓを登録するたびに通し番号を付けておき、奨学管理データベース４には学生基本台帳データベース３の通し番号をそのまま用いることでリンクができる。
【００６２】
その後、学生支援機構１では、奨学管理データベース４内の奨学生について、個人情報を用いて、あるいはリンクを利用して前述の検索のステップを用い当該奨学生の現在状況（学業成績、異動、卒業など）を確認することができる（確認のステップ）。具体例を挙げれば、当該氏名、生年月日の学生Ｓが確認当日、何年生であるいは既に卒業していてどの科目の単位をどの評価で取得しているかを確認することができる。
【００６３】
学生支援機構１では、所定の支給日が来るたびに当該奨学生の現在状況が所定の奨学金支給条件を満たしていれば所定額の奨学金を支給する（奨学金支給のステップ）。奨学金支給条件は学生支援機構１が人為的取り決めで定める事項なので詳しく言及しないが、例えば、休学すれば支給を停止するといったものである。こうした条件を学生基本台帳データベース３の学業成績、異動及び卒業の情報と比較可能な形式でデータ化しておけばよい。
【００６４】
このようにして奨学生は奨学金を受け取ることができる。奨学生が卒業すると、前述の卒業書き込みのステップにより学生基本台帳データベース３の当該学生の欄に卒業の情報として卒業が書き込まれるので、奨学金支給のステップにおいて奨学金支給条件が不成立になり、支給が停止される。
【００６５】
卒業した奨学生が就職をする際には、既に述べた学歴証明書交付願いのステップ、学歴証明書交付のステップ、就職先通知のステップが行われる。従って、学生基本台帳データベース３の当該学生の欄に就職先が書き込まれる。図１では、就職を果たした学生Ｓを社会人Ｓ’で示してある。
【００６６】
学生支援機構１では、奨学管理データベース４に登録されている奨学生について前述の確認のステップを行うことにより現在状況が所定の奨学金返還条件を満たす奨学生（以後、返還対象者となる）を抽出する（返還対象者抽出のステップ）。奨学金返還条件は学生支援機構１が人為的取り決めで定める事項なので詳しく言及しないが、例えば、卒業してかつ就職し、その職種が公務員、教職員でないことである。こうした条件を学生基本台帳データベース３の異動の情報及び就職先の情報と比較可能な形式でデータ化しておけばよい。
【００６７】
学生支援機構１では、当該返還対象者の欄を奨学管理データベース４から返還管理データベース５に移設する。これは実質的に、返還対象者に対して返還管理が開始されたことを意味する。（返還管理開始のステップ）。なお、卒業によって奨学金の支給が停止された奨学生であっても、就職が決まらない奨学生は、前述の返還対象者抽出のステップで抽出されることがないので、当該奨学生の欄は返還管理データベース５には移設されず、奨学管理データベース４に残留することになる。
【００６８】
学生支援機構１では、返還管理データベース５に登録されている返還対象者に対して所定の時期に所定額の返還を請求する請求書を発行する（返還請求のステップ）。請求書は郵送等により返還対象者（図１の社会人Ｓ’）に届けられる。返還対象者が所定の金融機関に払い込みを行うと、その入金という事象が学生支援機構１に伝えられる。学生支援機構１では、請求書発行後、所定の期日までに返還金が入金されなかった又は入金されたときに、返還管理データベース５の当該返還対象者の欄に返還実績情報（入金金額、未納期間、返還残額など）を書き込む（返還実績情報更新のステップ）。
【００６９】
返還が順調に進み、返還対象者が満額を返還すると、返還管理データベース５の返還残額がゼロになる。このとき学生支援機構１では、満額返還を果たした返還対象者の欄を抹消すると共に、学生基本台帳データベース３の当該学生の欄に満額返還を書き込む。
【００７０】
しかしながら、順調に奨学金返還が進むとは限らない。そこで、学生支援機構１では、返還管理データベース５に記録されている返還実績情報に基づいて返還実績が所定の不良基準に達した返還対象者（以下、返還不良者と呼ぶ）を抽出する（返還不良者抽出のステップ）。不良基準は学生支援機構１が人為的取り決めで定める事項なので詳しく言及しないが、技術的には、その不良基準を返還実績情報と比較可能な形式でデータ化しておけばよい。
【００７１】
学生支援機構１では、返還不良者について個人情報を用いて、あるいは上記リンクを利用して学生基本台帳データベース３の当該学生（返還不良者）の欄に返還不良の情報を書き込む（返還不良書き込みのステップ）。学生基本台帳データベース３には、就職先が記録されているので、返還不良が書き込まれたときに、その就職先の情報を参照して事業所１１へ催促の通知を出すようにしてもよい。また、返還不良者が転職するとき、学歴証明書交付願いのステップや就職先通知のステップが行われると、新たな就職先が直ちに判明するので、時間を空けず継続して催促を行うことも可能である。
【００７２】
ここで、返還不良者に対しては学歴証明書の交付を停止するなどの強い措置も可能である。すなわち、学歴証明書交付願いのステップが行われた際に行う検索のステップの結果、当該学生の欄に返還不良又は負債者の情報が記載されていた場合、交付停止のステップを実行する。交付停止のステップでは、当該学生（願い人）に対する学歴証明書交付を拒否し、返還あるいは返済を強く迫るようにする。学歴証明書が交付されないと当該学生が就職等で不利になることから、返還あるいは返済が促進されることが期待できる。
【００７３】
このようにして、返還不良者を抽出することで通常の返還請求よりも積極的な催促を行うことができる。しかし、それでも返還が滞る場合、奨学金資金源を保全する目的で、別途資金源からの代位弁済が行われる。すなわち、学生支援機構１では、返還管理データベース５に記録されている返還実績情報に基づいて返還実績が所定の代位弁済基準に達した返還対象者（以下、負債者と呼ぶ）を抽出する（負債者抽出のステップ）。代位弁済基準は学生支援機構１が人為的取り決めで定める事項なので詳しく言及しないが、技術的には、その代位弁済基準を返還実績情報と比較可能な形式でデータ化しておけばよい。
【００７４】
学生支援機構１では、当該負債者の欄を返還管理データベース５から求償権管理データベース７に移設する（代位弁済申請のステップ）。同時に、返還管理データベース５に記録されていた当該負債者の返還残額を求償権管理データベース７に移して負債額として記録する（代位弁済実行のステップ）。これまで説明した奨学金支給と返還は奨学金資金源における金の出入りであったが、ここでは別途資金源からの代位弁済が行われたことになる。よって、返還残額はゼロになり、返還は完了したことになる。
【００７５】
しかし、その一方で、学生支援機構１には求償権が発生し、負債者は負債を負うことになる。学生支援機構１では、その負債者について個人情報または上記リンクを利用して学生基本台帳データベース３の当該学生（負債者）の欄に負債者であるという情報を書き込む（負債者書き込みのステップ）。学生支援機構１は求償権者となるので、その法的立場に基づき、前述した返還不良者に対する催促よりも、より積極的な回収策を講じることが可能になる。
【００７６】
その後、学生支援機構１では、所定の時期に求償権管理データベース７に登録されている負債者に対して返済を請求する請求書を発行する（返済請求のステップ）。もし、返済金が入金受領された場合、学生支援機構１では、求償権管理データベース７の当該負債者の負債額を減じる（返済実績情報更新のステップ）。このステップは負債額がゼロになるまで継続される。
【００７７】
代位弁済は奨学金資金源を保全するひとつの方法であるが、本システムでは保証というもうひとつの方法でも奨学金資金源を保全する。すなわち、学生支援機構１では、奨学申請の際に、併せて保証申請を行った奨学生（以下、保証奨学生と呼ぶ）については、その個人情報に基づいて当該保証奨学生の欄を保証料管理データベース６に開設する（保証登録のステップ）。その後、奨学金支給のステップを実施するたびに、保証料管理データベース６を参照して当該奨学生が保証奨学生であれば支給額から所定の保証料を天引きし、天引き額を上記保証料管理データベースに累積する（保証料付替えのステップ）。
【００７８】
この結果、保証奨学生については、奨学金支給が開始されてから停止されるまでの間、保証料が累積されることになる。こうして保証料を累積した保証奨学生は、その後、返還対象者となったときに、奨学金返還の過程で返還対象者の都合により所定の期日までに返還金が入金されない場合があっても、累積保証料から返還金を下ろすことができる。従って、保証をつけておいた返還対象者は返還不良者になることを免れることができる。一方、学生支援機構１にとっては返還の順調な進行が継続されることになる。
【００７９】
以上で、図１の学生基本台帳管理システムの動作説明を終わる。本システムの利点は次の通りである。
【００８０】
どの学校にも属さず独立した学生支援機構に学生のデータを格納するための学生基本台帳データベースを備え、複数の学校（できれば全ての学校）の学生のデータを格納するようにしたので、学歴証明書交付に関わる手続を電子化できるという単純な効果だけにとどまらず、学校の統廃合によって卒業した学校が消滅しても学歴証明書が交付できるという大きな利点が得られる。
【００８１】
学校における学籍名簿の管理業務や学歴証明書の交付業務及びこれらに要する費用を軽減することができ、学校にとっても有益である。
【００８２】
学生支援機構が全ての学校の学歴証明書を交付するので、学歴証明書の様式が統一できるようになり、企業の採用人事などで複数の学生から学歴証明書を集めて比較審査を行うときに比較がやりやすくなる。
【００８３】
奨学管理データベース内の奨学生について学生基本台帳データベースから当該奨学生の現在状況を確認できるようにしたので、奨学生の現在状況が所定の奨学金支給条件を満たしているかどうか、あるいは奨学生の現在状況が所定の奨学金返還条件を満たして返還対象者となったかどうかを迅速かつ的確に知ることが可能となる。この結果、奨学金資金源の運用効率が向上する。
【００８４】
返還対象者や負債者の就職先が学生基本台帳データベースから追跡できるので、返還請求や返済請求が確実に行える。
【００８５】
奨学金支給額から保証料を天引きして蓄えるようにしたので、返還対象者が一時的に返還ができなくなった場合でも返還の順調な進行が継続される。この結果、奨学金資金源を保全することができる。
【００８６】
別途資金源からの代位弁済を行うようにしたので、奨学金資金源を保全することができる。
【００８７】
次に、本発明の学生基本台帳管理システムにおいて、奨学生に関するイベント発生の様子を順序立てて図９に示す。
【００８８】
まず、本人から学生支援機構に対して奨学金を受けたい旨の申請（＃１）を行う。これに対して学生支援機構は審査を行い、ＯＫであれば奨学生としての登録がなされる。ＯＫでない場合は図９には無関係となるので、ＯＫの場合のみ説明を続ける。通常の場合、当該奨学生の学歴が満了するまで奨学金の支給（＃２）が続けられる。
【００８９】
奨学生の学歴が満了し奨学金の支給が終了すると、その後は、返還の開始を待つことになる。就職して安定な収入を得るなど、現在状況が所定の奨学金返還条件を満たすと、その奨学生は、返還対象者となる。返還対象者と学生支援機構との間で返還計画の合意が得られると、その返還計画に従って返還の請求行為（＃３）が開始される。返還対象者は返還請求に応じて銀行振込等により、定められた額を返還する（＃４）。この返還が順調に進んで返還が満了すれば、次のステップへ進むことはない。
【００９０】
返還の途中に事故（返還がなされないこと）が発生（＃５）すると、返還対象者への督促（＃５−１）かまたは代弁手配（＃５−２）が行われる。督促に応じて返還があれば、再び＃３，＃４の流れに戻る。しかし、督促に対する応答がない場合には代弁手配に移行する。
【００９１】
代弁手配を受けて代位弁済が申請される（＃６）。代位弁済の審査の後、代位弁済が支払われる（＃７）。このことによって、債権は求償権へと変わる。
【００９２】
次に、求償権が請求される（＃８）。求償権請求に対し負債者は支払い（＃９）を行わなければならない。ここでまた事故が発生（＃１０）した場合、つまり負債者が支払いをしない場合は、本発明の学生基本台帳管理システムで取り扱う範囲を超えるので、これ以上は説明しない。
【００９３】
一方、事故の発生（＃５，＃１０）は学生基本台帳データベースへフィードバックされる（＃１１）。その後、本人（事故者）から、またはその代理人（例えば、本人を雇用するために学歴証明書を求めている会社）から学歴証明書の交付が申請されたとき、交付を拒否する（＃１２）。
【００９４】
以上のイベント＃１〜＃１２に関して、図１の学生基本台帳管理システムが実行するステップは既に述べたとおりである。
【００９５】
次に、データベース３〜７のより具体的な実施の形態を説明する。
【００９６】
これまで説明してきた複数のデータベース３〜７は、これらを統合した１つの大きな統合データベースにより実現することができる。統合データベースは、マスタと呼ばれるデータ種別の大きな区分を複数設け、それぞれのマスタに属するテーブルと呼ばれるデータ種別の小さな区分を設け、それぞれのテーブルにそのテーブルに属するデータを格納できるようにしたものである。
【００９７】
図１０に、統合データベースにおける学生１人分の全データの構造を示す。なお、現実に使用するデータの全てを網羅して開示することは出願人の本意ではないので、マスタ、テーブル、素情報（図１１）に関しては名称をいくつか例示するにとどめる。
【００９８】
図示のように、学生１人のデータは、個人基本マスタ、学種基本マスタ、奨学学種マスタ、返還学種基本マスタ、請求履歴マスタ等の複数のマスタに区分される。このうち奨学学種マスタには「奨学」というさらに大きな区分が付される。また、返還学種基本マスタ以下の複数のマスタは「返還」というさらに大きな区分でくくられる。各マスタには固有の略号が割り当てられる。
【００９９】
個人基本マスタは個人基本情報、本人住所氏名履歴情報、勤務先情報等の複数のテーブルに区分される。学種基本マスタは学種基本情報、口座情報等の複数のテーブルに区分される。その他のマスタについても１つ以上のテーブルに区分される。各テーブルには固有のテーブルＩＤが割り当てられる。
【０１００】
ひとつのテーブルには、情報の最小単位である素情報を複数格納することができる。例として、図１１に示されるように、個人基本情報のテーブルには、貸与種別コード、奨学生学種コード、奨学生採用年度、奨学生通し番号、奨学生番号ＣＤ、奨学生学種記号、奨学生漢字氏名、奨学生カナ氏名、奨学生検索用カナ氏名等の数十項目以上の素情報を格納することができる。また、図１２に示されるように、学種基本情報のテーブルには、貸与種別コード、奨学生学種コード、奨学生採用年度、奨学生通し番号、奨学生番号ＣＤ、奨学生キー番号Ｘ、奨学生併用番号等の数十項目以上の素情報を格納することができる。各素情報にはタイプ、桁数などが規定されている。
【０１０１】
なお、これらの例示から分かるように、異なるテーブルに同じ素情報を重複して格納することを妨げない。
【０１０２】
図４〜図８で説明してきた各種の情報が図１１の素情報の形態で図１０の統合データベースの適宜なテーブルに格納されることになる。そして、本発明の各ステップにおいて、これらのテーブルに対して素情報が新たに書き加えられたり、読み出されたり、更新されたりすることになる。
【図面の簡単な説明】
【０１０３】
【図１】本発明の学生基本台帳管理方法を用いた学生基本台帳管理システムの概要図である。
【図２】図１の学生基本台帳管理システムにおいて窓口で作成されるデータの内容を示すデータ構成図である。
【図３】図１の学生基本台帳管理システムにおいて入学以後に大学で作成されるデータの内容を示すデータ構成図である。
【図４】図１の学生基本台帳データベースにおいて１つの学生の欄に記録されるデータの内容を示すデータ構成図である。
【図５】図１の奨学管理データベースにおいて１つの奨学生の欄に記録されるデータの内容を示すデータ構成図である。
【図６】図１の返還管理データベースにおいて１つの返還対象者の欄に記録されるデータの内容を示すデータ構成図である。
【図７】図１の保証料管理データベースにおいて１つの保証奨学生の欄に記録されるデータの内容を示すデータ構成図である。
【図８】図１の求償権管理データベースにおいて１つの返還対象者の欄に記録されるデータの内容を示すデータ構成図である。
【図９】本発明におけるイベント発生を示す図である。
【図１０】本発明に用いる統合データベースにおける学生１人分のデータ構造図である。
【図１１】本発明に用いる個人基本情報テーブルに格納する素情報の一部を挙げた図である。
【図１２】本発明に用いる学生基本情報テーブルに格納する素情報の一部を挙げた図である。
【符号の説明】
【０１０４】
１  学生支援機構
２  大学
３  学生基本台帳データベース
４  奨学管理データベース
５  返還管理データベース
６  保証料管理データベース
７  求償権管理データベース
【図１】
2006164139.tif 000003
【図２】
2006164139.tif 000004
【図３】
2006164139.tif 000005
【図４】
2006164139.tif 000006
【図５】
2006164139.tif 000007
【図６】
2006164139.tif 000008
【図７】
2006164139.tif 000009
【図８】
2006164139.tif 000010
【図９】
2006164139.tif 000011
【図１０】
2006164139.tif 000012
【図１１】
2006164139.tif 000013
【図１２】
2006164139.tif 000014