JP2024010419A - アクセス制御方法及びアクセス制御プログラム - Google Patents

Abstract

【課題】ＡＣＬを用いたアクセス制御を回避するアクセス制御方法及びアクセス制御プログラムを提供することを目的とする。【解決手段】アクセス制御方法は、システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応する第１のシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、処理をコンピュータが実行する。【選択図】図８

Description

本件は、アクセス制御方法及びアクセス制御プログラムに関する。

ユーザが利用中のシステムから異なるシステムのデータへアクセスするために、アクセス先システムがアクセス元システムからの要求に対して応答する際に、データへのアクセスを制御する技術が知られている（例えば特許文献１参照）。また、デジタルツインと呼ばれる技術が知られており（例えば特許文献２参照）、ユーザが利用中のシステムから、この技術を実装したデジタルツインシステムのデータへアクセスする際に、データへのアクセスを制御する技術も知られている。

なお、デジタルツインは、時々刻々と変化する実世界から大量のデータを収集し、実社会をサイバー空間上に仮想的に構築して再現する技術である。デジタルツインを利用することにより、仮想的な都市や人、事象が再現され、大規模なシミュレーションが実現可能となる。例えば、大量の車両の位置データを活用した渋滞回避や配送の効率化などが実現可能となる。

特開２０１５－１８７７７７号公報 米国特許出願公開第２０１９／０２９４９７８号明細書

ユーザが利用中のシステムからデジタルツインシステムのデータにアクセスする際のアクセス制御は、ＡＣＬ（Access Control List）と呼ばれる制御情報を用いて行われている。ＡＣＬにはデータへのアクセス権限を有する者、データに対して行える操作、データに対するアクセスの許可や拒否などが登録されている。ＡＣＬに登録された内容を更新する場合には、デジタルツインシステムのシステム管理者がその都度更新することが求められる。

しかしながら、実世界から大量のデータがデジタルツインシステムに流入する状況では、システム管理者がＡＣＬをその都度更新し、どこからどのデータへのアクセスを許可又は拒否するか登録することは極めて煩雑な作業となる。

例えば、企業の従業員の勤怠を管理するソフトウェアが実装されたシステムを利用して企業の総務部などが従業員の位置データを把握する場合、就業時間内であれば、システム管理者は位置データへのアクセスを許可する旨をＡＣＬに登録すればよい。一方で、就業時間外であれば、従業員のプライバシー確保の観点から、システム管理者は位置データへのアクセスを拒否する旨をＡＣＬに登録することが求められる。このような作業を就業日の度に行うことは極めて難しい。

そこで、１つの側面では、ＡＣＬを用いたアクセス制御を回避するアクセス制御方法及びアクセス制御プログラムを提供することを目的とする。

１つの実施態様では、アクセス制御方法は、システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応する第１のシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、処理をコンピュータが実行する。

ＡＣＬを用いたアクセス制御を回避することができる。

図１はアクセス制御システムの一例を説明する図である。 図２は複数のオブジェクトと主従関係の一例を説明する図である。 図３はアクセス制御装置のハードウェア構成の一例である。 図４（ａ）は第１実施形態に係るアクセス制御装置の機能構成の一例である。図４（ｂ）は第１実施形態に係るリレーションシップテーブルの一例である。 図５はＡＰＩサーバが実行する処理の一例を示すフローチャートである。 図６は第１実施形態に係るアクセス制御装置が実行する処理の一例を示すフローチャートである。 図７はＡＰＩリクエストと第１のＡＰＩレスポンスと第２のＡＰＩレスポンスの一例を説明する図である。 図８は第１実施形態に係るアクセス制御の一例を説明する図である。 図９（ａ）は比較例に係るアクセス制御装置の機能構成の一例である。図９（ｂ）はアクセスコントロールリストの一例である。 図１０は第２実施形態に係るアクセス制御装置が実行する処理の一部の一例を示すフローチャートである。 図１１は第２実施形態に係るアクセス制御の一例を説明する図である。 図１２（ａ）は第３実施形態に係るアクセス制御の一例を説明する図である。図１２（ｂ）は第３実施形態に係るリレーションシップテーブルの一例である。 図１３（ａ）は第４実施形態に係るアクセス制御の一例を説明する図である。図１３（ｂ）は第４実施形態に係るリレーションシップテーブルの一例である。

以下、本件を実施するための形態について図面を参照して説明する。

（第１実施形態）
図１に示すように、アクセス制御システムＳＴは、アクセス制御装置１００とデジタルツインシステム２００とアクセス元装置３００とを含んでいる。デジタルツインシステム２００は管理システムの一例である。アクセス制御装置１００はデジタルツインシステム２００とアクセス元装置３００との間に配置されている。アクセス制御装置１００はデジタルツインシステム２００と通信ネットワークＮＷ１を介して接続されている。アクセス制御装置１００はアクセス元装置３００と通信ネットワークＮＷ２を介して接続されている。通信ネットワークＮＷ１，ＮＷ２はＬＡＮ（Local Area Network）であってもよいし、インターネットであってもよい。

デジタルツインシステム２００はＡＰＩ（Application Programming Interface）サーバ２１０とオブジェクトＤＢ（DataBase）２２０を含んでいる。ＡＰＩサーバ２１０はアクセス制御装置１００から送信されたＡＰＩリクエストを受信する。ＡＰＩサーバ２１０は受信したＡＰＩリクエストに対応するＡＰＩレスポンスをアクセス制御装置１００に送信する。

ＡＰＩサーバ２１０は通信ネットワークＮＷ３を介して無線基地局ＢＳ１，ＢＳ２と接続されている。通信ネットワークＮＷ３は例えばインターネットを含んでいる。無線基地局ＢＳ１は、無線通信ＷＬを介して、例えば企業のＢオフィスで作業する従業員１０の携帯端末１１から送信されたデータを受信する。このように、無線基地局ＢＳ１は実世界のデータを受信する。携帯端末１１は、ＧＰＳ（Global Positioning Systems）を備えているため、ＧＰＳによって特定された携帯端末１１の位置データを従業員１０の位置データとして送信することができる。なお、携帯端末１１はスマートフォンであってもよいし、タブレット端末であってもよい。

企業の就業時間が終了すると、従業員１０は自宅に向けて移動し、自宅に滞在する。無線基地局ＢＳ２は、無線通信ＷＬを介して、自宅に滞在する従業員１０の携帯端末１１から送信された位置データを受信する。無線基地局ＢＳ１，ＢＳ２はそれぞれ従業員１０の位置データを受信すると、従業員１０の位置データをＡＰＩサーバ２１０に送信する。ＡＰＩサーバ２１０は従業員１０の位置データを受信すると、受信した位置データに基づいて、オブジェクトＤＢ２２０を更新する。

オブジェクトＤＢ２２０は複数のオブジェクトを記憶する。オブジェクトの各々は、Ｌｉｎｋｅｄ－Ｄａｔａ形式と呼ばれるデータ形式を用いて表現された場合、エンティティと呼ばれることがある。複数のオブジェクトは、図２に示すように、第１の利用者オブジェクト２１及び第２の利用者オブジェクト２２を含んでいる。また、複数のオブジェクトは、第１の場所オブジェクト３１、第２の場所オブジェクト３２、及び第３の場所オブジェクト３３を含んでいる。複数のオブジェクトは識別子（ｉｄ）によって識別されている。

第１の利用者オブジェクト２１及び第２の利用者オブジェクト２２はデジタルツインシステム２００を利用するシステム利用者を管理するオブジェクトである。例えば、第２の利用者オブジェクト２２はデジタルツインシステム２００を利用する従業員１０を管理するオブジェクトである。すなわち、第２の利用者オブジェクト２２において、従業員１０には識別子「ｕｓｅｒ１」が割り当てられている。第１の場所オブジェクト３１、第２の場所オブジェクト３２、及び第３の場所オブジェクト３３は場所を管理するオブジェクトである。例えば、第２の場所オブジェクト３２はＢオフィスを管理するオブジェクトである。第３の場所オブジェクト３３は自宅を管理するオブジェクトである。

第１の利用者オブジェクト２１及び第２の利用者オブジェクト２２と、第１の場所オブジェクト３１、第２の場所オブジェクト３２、及び第３の場所オブジェクト３３とは、リレーションシップ「ｉｓＩｎ」やリレーションシップ「ｏｗｎｅｄＢｙ」によって関連付けられている。リレーションシップは、第１の利用者オブジェクト２１及び第２の利用者オブジェクト２２と、第１の場所オブジェクト３１、第２の場所オブジェクト３２、及び第３の場所オブジェクト３３との主従関係を表している。すなわち、リレーションシップは主従関係の一例である。

例えばリレーションシップ「ｉｓＩｎ」により、第２の利用者オブジェクト２２と第２の場所オブジェクト３２は関連付けられている。リレーションシップ「ｉｓＩｎ」の場合、破線の矢印の矢先が位置する第２の場所オブジェクト３２が従オブジェクトに相当する。破線の矢印の矢元が位置する第２の利用者オブジェクト２２が主オブジェクトに相当する。第２の利用者オブジェクト２２と第２の場所オブジェクト３２の主従関係により、従業員１０がＢオフィスに滞在していることが特定される。リレーションシップ「ｏｗｎｅｄＢｙ」の場合、矢印による主従関係は逆になる。

また、リレーションシップ「ｏｗｎｅｄＢｙ」により、第２の利用者オブジェクト２２と第３の場所オブジェクト３３は関連付けられている。この場合、矢印の矢元が位置する第３の場所オブジェクト３３が従オブジェクトに相当する。矢印の矢先が位置する第２の利用者オブジェクト２２が主オブジェクトに相当する。第２の利用者オブジェクト２２と第３の場所オブジェクト３３の主従関係により、従業員１０が自宅を所有又は支配していることが特定される。

ここで、ＡＰＩサーバ２１０が従業員１０の位置データを無線基地局ＢＳ２から受信すると、ＡＰＩサーバ２１０は受信した位置データに基づいて、第２の利用者オブジェクト２２の位置データを更新する。具体的には、ＡＰＩサーバ２１０は第２の利用者オブジェクト２２のロケーション（location）におけるＢオフィスの位置を緯度と経度で表す位置データ「Ｎ２，Ｅ２」から自宅の位置を緯度と経度で表す位置データ「Ｎ１，Ｅ１」に更新する。また、ＡＰＩサーバ２１０は、位置データの更新と併せて、リレーションシップ「ｉｓＩｎ」に関連付けられた識別子「ｏｆｆｉｃｅ２」を識別子「ｕｓｅｒ１ｈｏｍｅ」に更新する。

これにより、第２の利用者オブジェクト２２の主従関係が変更される。具体的には、第２の利用者オブジェクト２２と第２の場所オブジェクト３２の主従関係から第２の利用者オブジェクト２２と第３の場所オブジェクト３３の主従関係に変更される。第２の利用者オブジェクト２２と第３の場所オブジェクト３３の主従関係により、従業員１０が自宅に滞在していることが特定される。

図１に戻り、アクセス制御装置１００はアクセス元装置３００からのデジタルツインシステム２００へのアクセスを制御する。アクセス元装置３００は例えばサーバ装置などのコンピュータである。アクセス元装置３００には例えば企業に所属する従業員１０の勤怠を管理するアプリケーションソフトウェア（以下、勤怠管理アプリという）が実装（具体的にはインストール）されている。勤怠管理アプリは例えば企業の総務部や人事部などが従業員１０の出退勤や勤務状況などを管理するために利用される。

勤怠管理アプリは例えば総務部の権限でデジタルツインシステム２００にアクセスする。より詳しくは、勤怠管理アプリは総務部の権限で第２の利用者オブジェクト２２の位置データにアクセスする。勤怠管理アプリが位置データにアクセスすると、アクセス制御装置１００はその位置データへのアクセスの許否を動的に判断する。詳細は後述するが、アクセス制御装置１００は、ＡＣＬを利用せずに、リレーションシップによって特定される複数のオブジェクトの関係性に基づいて、アクセスの許否を判断する。例えば、従業員１０がＢオフィスに滞在していれば、アクセス制御装置１００は位置データへのアクセスを許可する。従業員１０が自宅に滞在していれば、アクセス制御装置１００は位置データへのアクセスを拒否する。

このように、アクセス制御装置１００は、複数のオブジェクトの関係性に基づいて、位置データへのアクセスの許否を動的に判断する。このため、ＡＣＬを用いたアクセス制御を回避でき、ＡＣＬの更新といった煩雑な作業を回避することができる。なお、本実施形態では、勤怠管理アプリが総務部の権限でデジタルツインシステム２００にアクセスする。このため、デジタルツインシステム２００のシステム利用者には従業員１０だけでなく、総務部も含まれる。したがって、図２に示すように、第１の利用者オブジェクト２１はデジタルツインシステム２００を利用する総務部を管理するオブジェクトである。

次に、図３を参照して、アクセス制御装置１００のハードウェア構成について説明する。なお、携帯端末１１やＡＰＩサーバ２１０、アクセス元装置３００は基本的にアクセス制御装置１００のハードウェア構成と同様のハードウェア構成であるため、詳細な説明は省略する。

アクセス制御装置１００は、プロセッサとしてのＣＰＵ（Central Processing Unit）１００Ａと、メモリとしてのＲＡＭ（Random Access Memory）１００Ｂ及びＲＯＭ（Read Only Memory）１００Ｃを含んでいる。アクセス制御装置１００は、ネットワークＩ／Ｆ（インタフェース）１００Ｄ及びＨＤＤ（Hard Disk Drive）１００Ｅを含んでいる。ＣＰＵ１００Ａに代えて、ＧＰＵ（Graphics Processing Unit）をプロセッサとして採用してもよい。ＨＤＤ（Hard Disk Drive）１００Ｅに代えて、ＳＳＤ（Solid State Drive）を採用してもよい。

アクセス制御装置１００は、必要に応じて、入力Ｉ／Ｆ１００Ｆ、出力Ｉ／Ｆ１００Ｇ、入出力Ｉ／Ｆ１００Ｈ、ドライブ装置１００Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ１００Ａからドライブ装置１００Ｉまでは、内部バス１００Ｊによって互いに接続されている。すなわち、アクセス制御装置１００はコンピュータによって実現することができる。

入力Ｉ／Ｆ１００Ｆには入力装置７１０が接続される。入力装置７１０としては例えばキーボードやマウス、タッチパネルなどがある。出力Ｉ／Ｆ１００Ｇには表示装置７２０が接続される。表示装置７２０としては例えば液晶ディスプレイなどがある。入出力Ｉ／Ｆ１００Ｈには半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばＵＳＢ（Universal Serial Bus）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ１００Ｈは半導体メモリ７３０に記憶されたアクセス制御プログラムを読み取る。入力Ｉ／Ｆ１００Ｆ及び入出力Ｉ／Ｆ１００Ｈは例えばＵＳＢポートを備えている。出力Ｉ／Ｆ１００Ｇは例えばディスプレイポートを備えている。

ドライブ装置１００Ｉには可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばＣＤ（Compact Disc）－ＲＯＭ、ＤＶＤ（Digital Versatile Disc）といったリムーバブルディスクがある。ドライブ装置１００Ｉは可搬型記録媒体７４０に記録されたアクセス制御プログラムを読み込む。ネットワークＩ／Ｆ１００Ｄは例えばＬＡＮポートや通信回路などを備えている。ネットワークＩ／Ｆ１００Ｄは通信ネットワークＮＷ１，ＮＷ２と接続されている。

ＲＡＭ１００ＢにはＲＯＭ１００Ｃ、ＨＤＤ１００Ｅ、半導体メモリ７３０の少なくとも１つに記憶されたアクセス制御プログラムがＣＰＵ１００Ａによって一時的に格納される。ＲＡＭ１００Ｂには可搬型記録媒体７４０に記録されたアクセス制御プログラムがＣＰＵ１００Ａによって一時的に格納される。格納されたアクセス制御プログラムをＣＰＵ１００Ａが実行することにより、ＣＰＵ１００Ａは後述する各種の機能を実現し、また、後述する各種の処理を含むアクセス制御方法を実行する。なお、アクセス制御プログラムは後述するフローチャートに応じたものとすればよい。

図４を参照して、アクセス制御装置１００の機能構成について説明する。なお、図４（ａ）ではアクセス制御装置１００の機能の要部が示されている。

図４（ａ）に示すように、アクセス制御装置１００は記憶部１１０、処理部１２０、及び通信部１３０を備えている。記憶部１１０は上述したＲＡＭ１００ＢとＨＤＤ１００Ｅのいずれか一方又は両方によって実現することができる。処理部１２０は上述したＣＰＵ１００Ａによって実現することができる。通信部１３０は上述したネットワークＩ／Ｆ１００Ｄによって実現することができる。

記憶部１１０、処理部１２０、及び通信部１３０は互いに接続されている。ここで、記憶部１１０はリレーションシップ記憶部１１１を含んでいる。処理部１２０は、送受信部１２１、オブジェクト判断部１２２、及びアクセス制御部１２３を含んでいる。

リレーションシップ記憶部１１１は上述したリレーションシップを記憶する。図４（ｂ）に示すように、リレーションシップはリレーションシップテーブルにより管理される。リレーションシップテーブルでは、リレーションシップを識別するリレーションシップＩＤごとに、リレーションシップＩＤとリレーションシップとリレーションシップに応じた処理の組み合わせが管理される。例えば、リレーションシップＩＤ「Ｒ０１」のリレーションシップ「ｉｓＩｎ」には処理「上位探索」が関連付けられている。詳細は後述するが、処理「上位探索」は、図２を参照して説明した矢印の矢先が位置するオブジェクトを上位のオブジェクトとして探索することを表している。

送受信部１２１はアクセス元装置３００から送信されたＡＰＩリクエストを受信する。ＡＰＩリクエストを受信することにより、送受信部１２１は第１の利用者オブジェクト２１に対応する総務部から第２の利用者オブジェクト２２に格納されている位置データへのアクセスを受け付ける。送受信部１２１はＡＰＩリクエストを受信すると、ＡＰＩリクエストをＡＰＩサーバ２１０に送信する。送受信部１２１はＡＰＩサーバ２１０からＡＰＩリクエストに応じて送信されたＡＰＩレスポンスを受信する。

オブジェクト判断部１２２は、送受信部１２１が位置データへのアクセスを受け付けた場合、第２の利用者オブジェクト２２を起点として、リレーションシップを辿った中に、第１の利用者オブジェクト２１があるか否かを判断する。アクセス制御部１２３は、リレーションシップを辿った中に、第１の利用者オブジェクト２１がある場合、位置データへのアクセスを許可する。アクセス制御部１２３は、リレーションシップを辿った中に、第１の利用者オブジェクト２１がない場合、位置データへのアクセスを拒否する。なお、送受信部１２１、オブジェクト判断部１２２、及びアクセス制御部１２３の詳細については後述する。

次に、図５を参照して、ＡＰＩサーバ２１０の動作について説明する。なお、ＡＰＩサーバ２１０は、図５に示すフローチャートの処理を定期的に（例えば５分など数分単位で）実行する。まず、ＡＰＩサーバ２１０は携帯端末１１から送信された従業員１０の位置データを受信する（ステップＳ１）。位置データを受信すると、ＡＰＩサーバ２１０は、受信した位置データに基づいて、第２の利用者オブジェクト２２の位置データを更新する（ステップＳ２）。位置データは従業員１０を識別する識別子「ｕｓｅｒ１」を含んでいる。このため、ＡＰＩサーバ２１０はオブジェクトＤＢ２２０から第２の利用者オブジェクト２２を特定することができる。このように、ＡＰＩサーバ２１０は、従業員１０の移動に基づいて、位置データを動的に更新する。

更新後、ＡＰＩサーバ２１０は、オブジェクトＤＢ２２０を参照し、第１の場所オブジェクト３１、第２の場所オブジェクト３２、第３の場所オブジェクト３３の各ロケーション（location）における位置データを検索する（ステップＳ３）。そして、ＡＰＩサーバ２１０は、更新後の位置データに近接する位置データの有無を判断する（ステップＳ４）。位置データ同士が近接するか否かは、例えば、更新後の位置データの半径数十センチメートル以内にいずれかの位置データがあるか否かにより判断することができる。

更新後の位置データに近接する位置データがない場合（ステップＳ４：ＮＯ）、ＡＰＩサーバ２１０は後続の処理をスキップして、処理を終了する。更新後の位置データに近接する位置データがある場合（ステップＳ４：ＹＥＳ）、ＡＰＩサーバ２１０は、リレーションシップ「ｉｓＩｎ」を更新し（ステップＳ５）、処理を終了する。

例えば、更新後の位置データとＢオフィスの位置を表す位置データとが近接（又は一致）していれば、ＡＰＩサーバ２１０は、第２の利用者オブジェクト２２のリレーションシップ「ｉｓＩｎ」の識別子を識別子「ｏｆｆｉｃｅ２」に更新する（図２参照）。更新後の位置データと自宅の位置を表す位置データとが近接（又は一致）していれば、ＡＰＩサーバ２１０は、第２の利用者オブジェクト２２のリレーションシップ「ｉｓＩｎ」の識別子を識別子「ｕｓｅｒ１ｈｏｍｅ」に更新する。このように、ＡＰＩサーバ２１０は、携帯端末１１から送信される従業員１０の位置データに基づいて、複数のオブジェクトの関係性を動的に更新する。

次に、図６及び図７を参照して、アクセス制御方法を実行するアクセス制御装置１００の動作について説明する。

まず、図６に示すように、送受信部１２１はアクセス元装置３００から送信されたＡＰＩリクエストを受信する（ステップＳ１１）。図７に示すように、アクセス元装置３００からアクセス制御装置１００にＡＰＩリクエストが送信される場合、ＵＲＬ（Uniform Resource Locator）が指定されて送信される。本実施形態では、識別子「ｕｓｅｒ１」と位置データの格納先を表す項目「ｌｏｃａｔｉｏｎ」が関連付けられたＵＲＬ「ｕｓｅｒ１／ｌｏｃａｔｉｏｎ」が指定される。当該ＵＲＬにより、第２の利用者オブジェクト２２に格納されている位置データへのアクセスが特定される。また、ＡＰＩリクエストには、位置データを取得する命令「ＧＥＴ」とアクセス元を判別する識別子「ｓｏｕｍｕ」が格納されている。ＵＲＬとＡＰＩリクエストにより、送受信部１２１は勤怠管理アプリが総務部の権限で従業員１０の位置データを要求していると判断する。なお、送受信部１２１は、後続の判断処理のために、識別子「ｓｏｕｍｕ」を保持する。

ＡＰＩリクエストを受信すると、送受信部１２１はＡＰＩリクエストをＡＰＩサーバ２１０に送信する（ステップＳ１２）。ＡＰＩリクエストを送信する際、図７に示すように、送受信部１２１はＵＲＬ「ｕｓｅｒ１／ｌｏｃａｔｉｏｎ」をＵＲＬ「ｕｓｅｒ１」に変換する。すなわち、送受信部１２１は位置データへのアクセスを求めるＡＰＩリクエストを、第２の利用者オブジェクト２２へのアクセスを求めるＡＰＩリクエストに変換する。これは、位置データがリレーションシップによりオブジェクトと関連付けられていないためである。ＡＰＩリクエストを変換することにより、位置データの取得が要求された場合であっても、オブジェクト同士のリレーションシップを辿ることができる。なお、送受信部１２１は第２の利用者オブジェクト２２へのアクセスを求めるＡＰＩリクエストを受信した場合、このＡＰＩリクエストを変換せずに直接的にＡＰＩサーバ２１０に送信する。送受信部１２１は、ＡＰＩリクエストの変換の有無に関わらずに、アクセス元を判別する識別子「ｓｏｕｍｕ」を除外したＡＰＩリクエストを送信する。

ＡＰＩリクエストを送信すると、送受信部１２１は第１のＡＰＩレスポンスを受信する（ステップＳ１３）。より詳しくは、送受信部１２１はＡＰＩリクエストに対応する第１のＡＰＩレスポンスをＡＰＩサーバ２１０から受信する。図７に示すように、ＵＲＬとして識別子「ｕｓｅｒ１」が特定されているため、ＡＰＩリクエストに対応する第１のＡＰＩレスポンスには、第２の利用者オブジェクト２２が有するデータが格納される。従業員１０がＢオフィスに滞在していれば、第１のＡＰＩレスポンスには、識別子「ｕｓｅｒ１」、Ｂオフィスの位置を表す位置データ「Ｎ２，Ｅ２」、リレーションシップ「ｉｓＩｎ」と関連付けられた識別子「ｏｆｆｉｃｅ２」が格納される。

第１のＡＰＩレスポンスを受信すると、オブジェクト判断部１２２は識別子が一致するか否かを判断する（ステップＳ１４）。より詳しくは、オブジェクト判断部１２２は第１のＡＰＩレスポンスに格納された識別子と、送受信部１２１が保持する識別子が一致するか否かを判断する。本実施形態では、第１のＡＰＩレスポンスには識別子「ｏｆｆｉｃｅ２」が格納されている。一方、送受信部１２１は識別子「ｓｏｕｍｕ」を保持している。このため、本実施形態では、オブジェクト判断部１２２は識別子が一致しないと判断する。

識別子が一致しない場合（ステップＳ１４：ＮＯ）、オブジェクト判断部１２２はリレーションシップ（図６においてＲｓと記載）があるか否かを判断する（ステップＳ１５）。より詳しくは、オブジェクト判断部１２２は、第１のＡＰＩレスポンスにリレーションシップがあるか否かを判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｉｓＩｎ」が格納されている。このため、本実施形態であれば、オブジェクト判断部１２２はリレーションシップがあると判断する。

リレーションシップがある場合（ステップＳ１５：ＹＥＳ）、オブジェクト判断部１２２はリレーションシップテーブルを検索し（ステップＳ１６）、リレーションシップが一致するか否かを判断する（ステップＳ１７）。すなわち、オブジェクト判断部１２２は、リレーションシップ記憶部１１１を参照し、リレーションシップテーブル（図４（ｂ）参照）に第１のＡＰＩレスポンスに格納されたリレーションシップと一致するリレーションシップの有無を判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｉｓＩｎ」が格納されている。一方、リレーションシップテーブルにはリレーションシップ「ｉｓＩｎ」が格納されている。したがって、本実施形態であれば、オブジェクト判断部１２２はリレーションシップが一致すると判断する。

リレーションシップが一致する場合（ステップＳ１７：ＹＥＳ）、ステップＳ１２の処理に戻り、送受信部１２１はＡＰＩリクエストをＡＰＩサーバ２１０に送信する。この場合、図７に示すように、送受信部１２１は、第１のＡＰＩレスポンスに格納されたリレーションシップ「ｉｓＩｎ」と関連付けられた識別子「ｏｆｆｉｃｅ２」をＵＲＬに指定して、ＡＰＩリクエストを送信する。すなわち、送受信部１２１は第２の場所オブジェクト３２へのアクセスを求めるＡＰＩリクエストを送信する。このように、アクセス制御装置１００は、リレーションシップに基づいて、第２の利用者オブジェクト２２を起点に、第２の場所オブジェクト３２を辿る。

ＡＰＩリクエストを送信すると、ステップＳ１３の処理により、送受信部１２１はＡＰＩリクエストに対応する第１のＡＰＩレスポンスをＡＰＩサーバ２１０から受信する。図７に示すように、ＵＲＬとして識別子「ｏｆｆｉｃｅ２」が特定されているため、ＡＰＩリクエストに対応する第１のＡＰＩレスポンスには、第２の場所オブジェクト３２が有するデータが格納される。したがって、第１のＡＰＩレスポンスには、識別子「ｏｆｆｉｃｅ２」、Ｂオフィスの位置を表す位置データ「Ｎ２，Ｅ２」、リレーションシップ「ｏｗｎｅｄＢｙ」と関連付けられた識別子「ｓｏｕｍｕ」が格納される。第２の場所オブジェクト３２によれば、Ｂオフィスは総務部によって所有又は支配されている。

第１のＡＰＩレスポンスを受信すると、ステップＳ１４の処理により、オブジェクト判断部１２２は第１のＡＰＩレスポンスに格納された識別子と、送受信部１２１が保持する識別子が一致するか否かを判断する。本実施形態では、第１のＡＰＩレスポンスには識別子「ｏｆｆｉｃｅ２」が格納されている。一方、送受信部１２１は識別子「ｓｏｕｍｕ」が保持している。このため、本実施形態では、オブジェクト判断部１２２は識別子が一致しないと判断する。

識別子が一致しない場合、オブジェクト判断部１２２は、ステップＳ１５の処理により、第１のＡＰＩレスポンスにリレーションシップがあるか否かを判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｏｗｎｅｄＢｙ」が格納されている。このため、本実施形態であれば、オブジェクト判断部１２２はリレーションシップがあると判断する。

リレーションシップがある場合、ステップＳ１６，Ｓ１７の処理により、オブジェクト判断部１２２はリレーションシップテーブルを検索し、リレーションシップが一致するか否かを判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｏｗｎｅｄＢｙ」が格納されている。一方、リレーションシップテーブルにはリレーションシップ「ｏｗｎｅｄＢｙ」が格納されている（図４（ｂ）参照）。したがって、本実施形態であれば、オブジェクト判断部１２２はリレーションシップが一致すると判断する。

リレーションシップが一致する場合、ステップＳ１２の処理に戻り、送受信部１２１はＡＰＩリクエストをＡＰＩサーバ２１０に送信する。この場合、図７に示すように、送受信部１２１は、第１のＡＰＩレスポンスに格納されたリレーションシップ「ｏｗｎｅｄＢｙ」と関連付けられた識別子「ｓｏｕｍｕ」をＵＲＬに指定して、ＡＰＩリクエストを送信する。すなわち、送受信部１２１は第１の利用者オブジェクト２１へのアクセスを求めるＡＰＩリクエストを送信する。このように、アクセス制御装置１００は、リレーションシップに基づいて、第２の利用者オブジェクト２２を起点に、第１の利用者オブジェクト２１をさらに辿る。

ＡＰＩリクエストを送信すると、ステップＳ１３の処理により、送受信部１２１はＡＰＩリクエストに対応する第１のＡＰＩレスポンスをＡＰＩサーバ２１０から受信する。図７に示すように、ＵＲＬとして識別子「ｓｏｕｍｕ」が特定されているため、ＡＰＩリクエストに対応する第１のＡＰＩレスポンスには、第１の利用者オブジェクト２１が有するデータが格納される。したがって、第１のＡＰＩレスポンスには、識別子「ｓｏｕｍｕ」、・・・、所有（ｏｗｎ）「ｏｆｆｉｃｅ１，…」が格納される。第１の利用者オブジェクト２１によれば、総務部がＢオフィスとＡオフィスを所有又は支配する。

第１のＡＰＩレスポンスを受信すると、ステップＳ１４の処理により、オブジェクト判断部１２２は第１のＡＰＩレスポンスに格納された識別子と、送受信部１２１が保持する識別子が一致するか否かを判断する。本実施形態では、第１のＡＰＩレスポンスには識別子「ｓｏｕｍｕ」が格納されている。一方、送受信部１２１は識別子「ｓｏｕｍｕ」が保持している。このため、本実施形態では、オブジェクト判断部１２２は識別子が一致すると判断する。

識別子が一致する場合（ステップＳ１４：ＹＥＳ）、アクセス制御部１２３はアクセスを許可する（ステップＳ１８）。この場合、アクセス制御部１２３は第２のＡＰＩレスポンスを生成する（ステップＳ１９）。より詳しくは、図７に示すように、アクセス制御部１２３は、アクセス元装置３００から送信されたＡＰＩリクエストに対応する第２のＡＰＩレスポンスを生成する。

第２のＡＰＩレスポンスには、従業員１０がＢオフィスに滞在していることを表す位置データ「Ｎ２，Ｅ２」が格納されている。第２のＡＰＩレスポンスに位置データ「Ｎ２，Ｅ２」を格納する場合、例えば、アクセス制御部１２３は、まず、送受信部１２１が過去に受信した複数の第１のＡＰＩレスポンスの中から、識別子「ｕｓｅｒ１」が格納された第１のＡＰＩレスポンスを特定する。そして、アクセス制御部１２３は特定した第１のＡＰＩレスポンスに格納された位置データ「Ｎ２，Ｅ２」を抽出し、抽出した位置データ「Ｎ２，Ｅ２」を第２のＡＰＩレスポンスに格納すればよい。

アクセス制御部１２３が第２のＡＰＩレスポンスを生成すると、送受信部１２１は第２のＡＰＩレスポンスを送信する（ステップＳ２０）。すなわち、送受信部１２１はアクセス元装置３００から送信されたＡＰＩリクエストに対応する第２のＡＰＩレスポンスをアクセス元装置３００に送信する。送受信部１２１が第２のＡＰＩレスポンスを送信すると、アクセス制御装置１００は処理を終了する。

このように、勤怠管理アプリが総務部の権限で従業員１０の位置データの取得を要求した場合、アクセス制御装置１００は第２の利用者オブジェクト２２を起点として、リレーションシップを辿った中に、第１の利用者オブジェクト２１があるか否かを判断する。アクセス制御装置１００は、リレーションシップを辿った中に、第１の利用者オブジェクト２１がある場合、位置データへのアクセスを許可し、位置データを送信する。これにより、勤怠管理アプリを利用する総務部は従業員１０の位置を把握することができる。

ここで、従業員１０がＢオフィスから自宅に移動して、従業員１０が自宅に滞在すると、第２の利用者オブジェクト２２の位置データ「Ｎ２，Ｅ２」は位置データ「Ｎ１，Ｅ１」に更新される（図２参照）。また、第２の利用者オブジェクト２２のリレーションシップ「ｉｓＩｎ」に関連付けられた識別子「ｏｆｆｉｃｅ２」は識別子「ｕｓｅｒ１ｈｏｍｅ」に更新される（図２参照）。

この結果、図７において、ＵＲＬとして識別子「ｕｓｅｒ１」が指定されたＡＰＩリクエストに対応する第１のＡＰＩレスポンスでは、位置データ「Ｎ１，Ｅ１」が格納される。また、この第１のＡＰＩレスポンスでは、リレーションシップ「ｉｓＩｎ」に識別子「ｕｓｅｒ１ｈｏｍｅ」が関連付けられる。

したがって、ステップＳ１４の処理では、送受信部１２１は識別子「ｓｏｕｍｕ」が保持していると、第１のＡＰＩレスポンスに格納された識別子「ｏｆｆｉｃｅ２」と一致しない。このため、オブジェクト判断部１２２は識別子が一致しないと判断する。識別子が一致しない場合、オブジェクト判断部１２２は、ステップＳ１５の処理により、第１のＡＰＩレスポンスにリレーションシップがあるか否かを判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｉｓＩｎ」が格納されている。このため、本実施形態であれば、オブジェクト判断部１２２はリレーションシップがあると判断する。

リレーションシップがある場合、ステップＳ１６，Ｓ１７の処理により、オブジェクト判断部１２２はリレーションシップテーブルを検索し、リレーションシップが一致するか否かを判断する。本実施形態であれば、第１のＡＰＩレスポンスにはリレーションシップ「ｉｓＩｎ」が格納されている。一方、リレーションシップテーブルにはリレーションシップ「ｉｓＩｎ」が格納されている。したがって、本実施形態であれば、オブジェクト判断部１２２はリレーションシップが一致すると判断する。

リレーションシップが一致するため、ステップＳ１２の処理に戻り、送受信部１２１はＡＰＩリクエストをＡＰＩサーバ２１０に送信する。この場合、送受信部１２１は、第１のＡＰＩレスポンスに格納されたリレーションシップ「ｉｓＩｎ」と関連付けられた識別子「ｕｓｅｒ１ｈｏｍｅ」をＵＲＬに指定して、ＡＰＩリクエストを送信する。すなわち、送受信部１２１は第３の場所オブジェクト３３へのアクセスを求めるＡＰＩリクエストを送信する。このように、アクセス制御装置１００は、リレーションシップに基づいて、第２の利用者オブジェクト２２を起点に、第３の場所オブジェクト３３を辿る。

ＡＰＩリクエストを送信すると、ステップＳ１３の処理により、送受信部１２１はＡＰＩリクエストに対応する第１のＡＰＩレスポンスをＡＰＩサーバ２１０から受信する。ＵＲＬとして識別子「ｕｓｅｒ１ｈｏｍｅ」が特定されているため、ＡＰＩリクエストに対応する第１のＡＰＩレスポンスには、第３の場所オブジェクト３３が有するデータが格納される。したがって、第１のＡＰＩレスポンスには、識別子「ｕｓｅｒ１ｈｏｍｅ」、・・・、リレーションシップ「ｏｗｎｅｄＢｙ」と関連付けられた識別子「ｕｓｅｒ１」が格納される。第３の場所オブジェクト３３によれば、従業員１０によって自宅が所有又は支配されている。

第１のＡＰＩレスポンスを受信すると、ステップＳ１４の処理により、オブジェクト判断部１２２は第１のＡＰＩレスポンスに格納された識別子と、送受信部１２１が保持する識別子が一致するか否かを判断する。本実施形態では、第１のＡＰＩレスポンスには識別子「ｕｓｅｒ１」が格納されている。一方、送受信部１２１は識別子「ｓｏｕｍｕ」が保持している。このため、本実施形態では、オブジェクト判断部１２２は識別子が一致しないと判断する。

このように、本実施形態では、ステップＳ１４乃至Ｓ１７が繰り返されると、識別子「ｕｓｅｒ１」か識別子「ｕｓｅｒ１ｈｏｍｅ」が繰り返され、送受信部１２１が保持する識別子「ｓｏｕｍｕ」と一致しない。このため、このようなループ処理に至る場合には、ループ回数が所定回数に到達すると、本実施形態では、ステップＳ１５の処理において、オブジェクト判断部１２２はリレーションシップがないと判断する（ステップＳ１５：ＮＯ）。または、ループ回数が所定回数に到達すると、本実施形態では、ステップＳ１７の処理において、オブジェクト判断部１２２はリレーションシップが一致しないと判断する（ステップＳ１７：ＮＯ）。

リレーションシップがない場合、または、リレーションシップが一致しない場合、アクセス制御部１２３はアクセスを拒否する（ステップＳ２１）。この場合、送受信部１２１はアクセス元装置３００にエラーを通知する（ステップＳ２２）。エラーを通知すると、アクセス制御装置１００は処理を終了する。

このように、勤怠管理アプリが総務部の権限で従業員１０の位置データの取得を要求しても、アクセス制御装置１００は第２の利用者オブジェクト２２を起点としてリレーションシップを辿った中に、第１の利用者オブジェクト２１がない場合がある。この場合、アクセス制御装置１００は位置データへのアクセスを拒否する。これにより、従業員１０がＢオフィスから自宅に移動して自宅に滞在すれば、従業員１０のプライバシーを確保することができる。

図８を参照して、従業員１０の位置データに対するアクセスの許可と拒否をさらに説明する。図８に示す位置データ２２Ａは、Ｌｉｎｋｅｄ－Ｄａｔａ形式と呼ばれるデータ形式を用いて表現された場合、プロパティと呼ばれることがある。

まず、図８の上段に示すように、オブジェクトＤＢ２２０は、企業の総務部１５をシステム利用者として管理する第１の利用者オブジェクト２１と従業員１０をシステム利用者として管理する第２の利用者オブジェクト２２を記憶する。また、オブジェクトＤＢ２２０は、Ａオフィスを管理する第１の場所オブジェクト３１とＢオフィスを管理する第２の場所オブジェクト３２と従業員１０の自宅を管理する第３の場所オブジェクト３３を記憶する。

第１の利用者オブジェクト２１と第１の場所オブジェクト３１及び第２の場所オブジェクト３２はリレーションシップ「ｏｗｎｅｄＢｙ」４１によって主従関係が定義されている。第２の利用者オブジェクト２２と第３の場所オブジェクト３３はリレーションシップ「ｏｗｎｅｄＢｙ」４２によって主従関係が定義されている。従業員１０がＢオフィスに滞在しているため、第２の利用者オブジェクト２２と第２の場所オブジェクト３２はリレーションシップ「ｉｓＩｎ」４３によって主従関係が定義されている。第２の利用者オブジェクト２２には従業員１０の位置データ２２Ａが格納されている。

このような、従業員１０がＢオフィスに滞在している場合に、勤怠管理アプリが総務部１５の権限で第２の利用者オブジェクト２２に格納された従業員１０の位置データ２２Ａにアクセスする。この場合、第２の利用者オブジェクト２２を起点に、リレーションシップを辿った中に、第１の利用者オブジェクト２１があるため、アクセス制御装置１００は位置データ２２Ａに対するアクセスを許可する。

一方、図８の下段に示すように、従業員１０がＢオフィスから自宅に移動し、自宅に滞在すると、第２の利用者オブジェクト２２と第３の場所オブジェクト３３はリレーションシップ「ｉｓＩｎ」４３によって主従関係が新たに定義される。このような、従業員１０が自宅に滞在している場合に、勤怠管理アプリが総務部１５の権限で第２の利用者オブジェクト２２に格納された従業員１０の位置データ２２Ａにアクセスする。この場合、第２の利用者オブジェクト２２を起点に、リレーションシップを辿った中に、第１の利用者オブジェクト２１がない。このため、アクセス制御装置１００は位置データ２２Ａに対するアクセスを拒否する。

このように、アクセス制御装置１００は、複数のオブジェクトの関係性を辿ってアクセス権限があることを判断し、判断結果に基づいて、アクセスの許否を動的に制御する。本実施形態であれば、アクセス制御装置１００は、第２の利用者オブジェクト２２を起点として、リレーションシップを辿った中に、第１の利用者オブジェクト２１があるか否かを、総務部１５の権限に基づいて再帰的に判断する。これにより、アクセス制御装置１００はアクセスの許否を動的に制御する。

図９を参照して、比較例を説明する。なお、図４（ａ）を参照して説明した第１実施形態に係るアクセス制御装置１００と同様の構成には対応する符号を付し、その詳細な説明は省略する。図９（ａ）に示すように、比較例に係るアクセス制御装置４００は記憶部４１０、処理部４２０、及び通信部４３０を備えている。記憶部４１０はＡＣＬ記憶部４１１を含んでいる。処理部４２０は、送受信部４２１及びアクセス制御部４２３を含んでいる。

ＡＣＬ記憶部４１１はアクセスコントロールリストを記憶する。図９（ｂ）に示すように、アクセスコントロールリストではアクセスコントロールポリシーを識別するポリシーＩＤごとに複数のアクセスコントロールポリシーが管理される。アクセスコントロールポリシーはアクセスコントロールエントリと呼ばれることもある。アクセスコントロールリストはデジタルツインシステム２００のシステム管理者により設定される。アクセスコントロールポリシーは、アクセス制御、アクセス権限、アクセス対象、操作権限といった複数の項目を含んでいる。

例えば、ポリシーＩＤ「Ｐ０４」のアクセスコントロールポリシーは、アクセス制御「許可」、アクセス権限「総務部」、アクセス対象「従業員：状態」、操作権限「Ｒｅａｄ－ｏｎｌｙ」を含んでいる。このアクセスコントロールポリシーによれば、総務部１５の権限であれば、従業員１０の現在の状態（プレゼンス）に対し、勤怠管理アプリは読み込みのアクセスだけが許可される。現在の状態は、例えば従業員１０の現在の位置データなどを含んでいる。

ここで、当該アクセスコントロールポリシーについて、従業員１０が出勤してから退勤するまでの間に限り、勤怠管理アプリからのアクセスを許可する場合、システム管理者はアクセスコントロールリストを再設定する操作が求められる。例えば、図９（ｂ）に示すように、従業員１０が退勤してから出勤するまでの間は、従業員１０のプライバシー確保の観点から、システム管理者はアクセスコントロールポリシーのアクセス制御「許可」をアクセス制御「拒否」に再設定する。これにより、勤怠管理アプリからのアクセスが拒否される。

このようなシステム管理者による設定操作は、様々なアクセスコントロールポリシーを個別に設定することが要求されるため、システム管理者にとって極めて煩雑な作業になりかねない。また、本実施形態では、勤怠管理アプリを一例としてアクセスコントロールポリシーが設定されているが、例えば経理部の権限で利用する給与管理アプリや、人事部の権限で利用する人事評価アプリなどが併用された場合、膨大な設定作業につながるおそれがある。

しかしながら、本実施形態によれば、アクセスコントロールリストを用いたアクセス制御が回避されている。このため、システム管理者による操作負担が抑制される。また、リレーションシップテーブルの情報量はアクセスコントロールリストの情報量に比べて小さい（又は少ない）ため、記憶部４１０の記憶容量と比べて小さな記憶容量を持つ記憶部１１０でアクセス制御装置１００を実現することができる。さらに、リレーションシップテーブルの情報量が小さいことにより、リレーションシップテーブルを利用するアクセス制御装置１００の処理負荷を、アクセスコントロールリストを利用する場合に比べて、低減することができる。

（第２実施形態）
次に、図１０及び図１１を参照して、本件の第２実施形態について説明する。まず、図１０に示すように、上述したステップＳ１７の処理において、リレーションシップが一致しない場合、オブジェクト判断部１２２は次のアクセス先を指定する（ステップＳ３１）。すなわち、第１のＡＰＩレスポンスに格納されたリレーションシップと、リレーションシップテーブルに格納されたリレーションシップが一致しない場合、オブジェクト判断部１２２は次のアクセス先を指定する。

例えば、オブジェクト判断部１２２がステップＳ１２乃至Ｓ１７の処理を繰り返す。これにより、図１１に示すように、第２の利用者オブジェクト２２を起点に、リレーションシップ「ｏｗｎeｄＢｙ」４４を辿った中に、企業の経理部をシステム利用者として管理する第３の利用者オブジェクト２３が現れる場合がある。さらに、第３の利用者オブジェクト２３を起点にリレーションシップ「ａＰａｒｔＯｆ」４５を辿ると、企業の一例である会社をシステム利用者として管理する第４の利用者オブジェクト２４が現れる場合がある。

ここで、リレーションシップテーブルで管理されていないリレーションシップ「ａＰａｒｔＯｆ」４５が第３の利用者オブジェクト２３に格納されていると、リレーションシップが一致しない。この場合、オブジェクト判断部１２２は、リレーションシップに基づいて、次のアクセス先を指定する。本実施形態では、オブジェクト判断部１２２は第４の利用者オブジェクト２４を指定する。

次のアクセス先を指定すると、オブジェクト判断部１２２はアクセス先があるか否かを判断する（ステップＳ３２）。アクセス先がある場合（ステップＳ３２：ＹＥＳ）、オブジェクト判断部１２２はステップＳ１７の処理を再び実行する。本実施形態では、第４の利用者オブジェクト２４があるため、オブジェクト判断部１２２はステップＳ１７の処理を再び実行する。

一方、アクセス先がない場合（ステップＳ３２：ＮＯ）、オブジェクト判断部１２２は未探索のアクセス先を指定し（ステップＳ３３）、オブジェクト判断部１２２はステップＳ１７の処理を再び実行する。例えば、本実施形態では、図１１に示すように、第４の利用者オブジェクト２４を起点にアクセス可能なアクセス先は存在しない。このため、オブジェクト判断部１２２は、リレーションシップに従って階層を１つずつ戻り、未探索のアクセス先として例えば第１の利用者オブジェクト２１を指定する。これにより、識別子「ｓｏｕｍｕ」が一致するため、アクセス制御部１２３はアクセスを許可する。

このように、第２実施形態によれば、リレーションシップテーブルで管理されていないリレーションシップが第１のＡＰＩレスポンスに格納されていても、アクセス制御装置１００は位置データ２２Ａに対するアクセスを動的に許可できる場合がある。

（第３実施形態）
次に、図１２を参照して、本件の第３実施形態について説明する。図１２（ａ）に示すように、オブジェクトＤＢ２２０は、個人をシステム利用者として管理する第５の利用者オブジェクト２５と東京都をシステム利用者として管理する第６の利用者オブジェクト２６を記憶する。また、オブジェクトＤＢ２２０は、ｂａｒ公園を管理する第４の場所オブジェクト３４とｆｏｏ公園を管理する第５の場所オブジェクト３５と公園を管理する第６の場所オブジェクト３６を記憶する。

第４の場所オブジェクト３４及び第５の場所オブジェクト３５と第６の場所オブジェクト３６はリレーションシップ「ｉｓＰｕｂｌｉｃ」４７によって主従関係が定義されている。第６の利用者オブジェクト２６と第６の場所オブジェクト３６はリレーションシップ「ｏｗｎｅｄＢｙ」４６によって主従関係が定義されている。個人がｂａｒ公園に滞在しているため、第５の利用者オブジェクト２５と第４の場所オブジェクト３４はリレーションシップ「ｉｓＩｎ」４３によって主従関係が定義されている。第５の利用者オブジェクト２５には個人の緊急連絡先を表す連絡先データ２５Ａが格納されている。

一方、第３実施形態に係るリレーションシップテーブルでは、図１２（ｂ）に示すように、第１実施形態で説明したリレーションシップ以外に、リレーションシップＩＤ「Ｒ０３」のリレーションシップ「ｉｓＰｕｂｌｉｃ」が管理されている。また、第３実施形態に係るリレーションシップテーブルでは、リレーションシップＩＤ「Ｒ０４」のリレーションシップ「ｉｓＰｒｉｖａｔｅ」が管理されている。リレーションシップ「ｉｓＰｕｂｌｉｃ」及びリレーションシップ「ｉｓＰｒｉｖａｔｅ」にはそれぞれ処理「応答」及び処理「拒否」が関連付けられている。

ここで、例えば個人が怪我により倒れた状態でｂａｒ公園に滞在している場合、救護アプリが消防庁の権限で第５の利用者オブジェクト２５に格納された個人の連絡先データ２５Ａにアクセスする。この場合、第５の利用者オブジェクト２５を起点に、リレーションシップを辿ると、第４の場所オブジェクト３４が現れる。

このような場合、第５の利用者オブジェクト２５の後に第４の場所オブジェクト３４を表すＵＲＬでＡＰＩサーバ２１０にＡＰＩリクエストを送信すると、送受信部１２１はＡＰＩリクエストに対応する第１のＡＰＩレスポンスを受信する。図示しないが、ＡＰＩサーバ２１０から送信される第１のＡＰＩレスポンスには、第４の場所オブジェクト３４を識別する識別子「ｙｏｙｏｇｉ」が格納されている。また、この第１のＡＰＩレスポンスには、リレーションシップ「ｉｓＰｕｂｌｉｃ」と関連付けられた識別子「ｐａｒｋ」が格納されている。識別子「ｐａｒｋ」は第６の場所オブジェクト３６の識別子である。

このように、リレーションシップ「ｉｓＰｕｂｌｉｃ」が格納された第１のＡＰＩレスポンスを送受信部１２１が受信した場合、オブジェクト判断部１２２による判断が省略され、アクセス制御部１２３は即時にリレーションシップテーブルを参照する。そして、アクセス制御部１２３はリレーションシップテーブルで管理されるリレーションシップ「ｉｓＰｕｂｌｉｃ」に処理「応答」が関連付けられていれば、連絡先データ２５Ａに対する救護アプリからのアクセスを許可する。

仮に、リレーションシップ「ｉｓＰｒｉｖａｔｅ」が格納された第１のＡＰＩレスポンスを送受信部１２１が受信した場合でも同様に、オブジェクト判断部１２２による判断が省略され、アクセス制御部１２３は即時にリレーションシップテーブルを参照する。そして、アクセス制御部１２３はリレーションシップテーブルで管理されるリレーションシップ「ｉｓＰｒｉｖａｔｅ」に処理「拒否」が関連付けられていれば、アクセスを拒否する。

このような第３実施形態であっても、アクセスコントロールリストを回避したアクセス制御を実現することができる。また、第３実施形態によれば、リレーションシップの処理内容を拡張することで、即時応答や即時拒否可能なアクセス制御を実現することができる。

（第４実施形態）
次に、図１３を参照して、本件の第４実施形態について説明する。なお、第３実施形態と同一の構成には同一の符号を付して、その詳細な説明は省略する。図１３（ａ）に示すように、オブジェクトＤＢ２２０は、消防庁をシステム利用者として管理する第７の利用者オブジェクト２７をさらに記憶する。

第４の場所オブジェクト３４及び第５の場所オブジェクト３５と第６の場所オブジェクト３６はリレーションシップ「ｏｗｎｅｄＢｙ」４８によって主従関係が定義されている。第６の利用者オブジェクト２６と第７の利用者オブジェクト２７はリレーションシップ「ａＰａｒｔＯｆ」４９によって主従関係が定義されている。

一方、第４実施形態に係るリレーションシップテーブルでは、図１３（ｂ）に示すように、第１実施形態で説明したリレーションシップ以外に、リレーションシップＩＤ「Ｒ０５」のリレーションシップ「ａＰａｒｔＯｆ」が管理されている。リレーションシップ「ａＰａｒｔＯｆ」には処理「上位探索」が関連付けられている。

ここで、第３実施形態と同様に、個人が怪我により倒れた状態でｂａｒ公園に滞在している場合、救護アプリが消防庁の権限で第５の利用者オブジェクト２５に格納された個人の連絡先データ２５Ａにアクセスする。この場合、第５の利用者オブジェクト２５を起点に、リレーションシップを辿ると、第４の場所オブジェクト３４が現れる。また、第４の場所オブジェクト３４を起点に、リレーションシップを辿ると、第６の場所オブジェクト３６が現れる。第６の場所オブジェクト３６を起点に、リレーションシップを辿ると、第６の利用者オブジェクト２６が現れる。しかしながら、第６の利用者オブジェクト２６が消防庁の権限に相当する識別子「ｆｉｒｅ」を格納しているとは限らない。

このように、アクセス先であるオブジェクトの探索終了時にアクセスの許否に関する関係性が不明である場合、オブジェクト判断部１２２はアクセス元に相当するオブジェクトを探索する。そして、オブジェクト判断部１２２は探索途中のオブジェクトと共通の上位概念を有するオブジェクトの有無を判断する。本実施形態であれば、オブジェクト判断部１２２は、消防庁の権限に相当する識別子「ｆｉｒｅ」に基づいて、オブジェクトＤＢ２２０を参照する。

オブジェクト判断部１２２は識別子「ｆｉｒｅ」が格納された第７の利用者オブジェクト２７を発見すると、第７の利用者オブジェクト２７に格納されたリレーションシップ「ａＰａｒｔＯｆ」４９を辿り、第６の利用者オブジェクト２６を発見する。これにより、オブジェクト判断部１２２は第６の利用者オブジェクト２６が第７の利用者オブジェクト２７と第６の場所オブジェクト３６の共通の上位概念を有すると判断する。オブジェクト判断部１２２がこのように判断すると、アクセス制御部１２３は連絡先データ２５Ａに対する救護アプリからのアクセスを許可する。このような第４実施形態であっても、アクセスコントロールリストを回避したアクセス制御を実現することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応する第１のシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、処理をコンピュータが実行するアクセス制御方法。
（付記２）前記第１の利用者オブジェクトがない場合、前記アクセスを拒否する、ことを特徴とする付記１に記載のアクセス制御方法。
（付記３）前記第２の利用者オブジェクトへのアクセスを求める第１のリクエストを受け付けた場合、前記第１のリクエストを直接的に前記管理システムに送信する、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記４）前記データへのアクセスを求める第２のリクエストを受け付けた場合、前記第２のリクエストを前記第２の利用者オブジェクトへのアクセスを求める第１のリクエストに変換し、前記第１のリクエストを前記管理システムに送信する、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記５）前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを、前記第１のシステム利用者の権限に基づいて再帰的に判断する、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記６）前記管理システムは、前記複数のオブジェクトと前記主従関係をＬｉｎｋｅｄ－Ｄａｔａ形式を用いて管理する、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記７）前記管理システムは、前記複数のオブジェクトと前記主従関係を前記第２の利用者オブジェクトに対応する第２のシステム利用者の移動に基づいて更新する、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記８）前記主従関係を管理するテーブルの情報量は、アクセス制御に要するアクセスコントロールポリシーが設定されたリストの情報量より小さい、ことを特徴とする付記１又は２に記載のアクセス制御方法。
（付記９）システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応するシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、処理をコンピュータに実行させるためのアクセス制御プログラム。

２１ 第１の利用者オブジェクト
２２ 第２の利用者オブジェクト
２２Ａ 位置データ
３１ 第１の場所オブジェクト
３２ 第２の場所オブジェクト
３３ 第３の場所オブジェクト
４１，４２ リレーションシップ「ｏｗｎｅｄＢｙ」
４３ リレーションシップ「ｉｓＩｎ」
１００ アクセス制御装置
１１１ リレーションシップ記憶部
１２１ 送受信部
１２２ オブジェクト判断部
１２３ アクセス制御部
２００ デジタルツインシステム
２１０ ＡＰＩサーバ
２２０ オブジェクトＤＢ

Claims (8)

1. システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応する第１のシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、
   前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、
   処理をコンピュータが実行するアクセス制御方法。
2. 前記第１の利用者オブジェクトがない場合、前記アクセスを拒否する、
   ことを特徴とする請求項１に記載のアクセス制御方法。
3. 前記第２の利用者オブジェクトへのアクセスを求める第１のリクエストを受け付けた場合、前記第１のリクエストを直接的に前記管理システムに送信する、
   ことを特徴とする請求項１又は２に記載のアクセス制御方法。
4. 前記データへのアクセスを求める第２のリクエストを受け付けた場合、前記第２のリクエストを前記第２の利用者オブジェクトへのアクセスを求める第１のリクエストに変換し、前記第１のリクエストを前記管理システムに送信する、
   ことを特徴とする請求項１又は２に記載のアクセス制御方法。
5. 前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを、前記第１のシステム利用者の権限に基づいて再帰的に判断する、
   ことを特徴とする請求項１又は２に記載のアクセス制御方法。
6. 前記管理システムは、前記複数のオブジェクトと前記主従関係をＬｉｎｋｅｄ－Ｄａｔａ形式を用いて管理する、
   ことを特徴とする請求項１又は２に記載のアクセス制御方法。
7. 前記管理システムは、前記複数のオブジェクトと前記主従関係を前記第２の利用者オブジェクトに対応する第２のシステム利用者の移動に基づいて更新する、
   ことを特徴とする請求項１又は２に記載のアクセス制御方法。
8. システム利用者を管理する利用者オブジェクトと、場所を管理する場所オブジェクトと、を含む複数のオブジェクトと、前記利用者オブジェクトと前記場所オブジェクトとの主従関係と、を管理する管理システムに対して、前記複数のオブジェクトに含まれる第１の利用者オブジェクトに対応するシステム利用者から、前記複数のオブジェクトに含まれる第２の利用者オブジェクトに格納されているデータへのアクセスを受け付けた場合、前記第２の利用者オブジェクトを起点として、前記主従関係を辿った中に、前記第１の利用者オブジェクトがあるか否かを判断し、
   前記第１の利用者オブジェクトがある場合、前記アクセスを許可する、
   処理をコンピュータに実行させるためのアクセス制御プログラム。

Images