JP2019522384A - リソースアクセスの制御方法及び装置 - Google Patents

Abstract

リソースアクセスの制御方法及び装置を提供し、該方法は、請求元から目標リソースへのアクセス請求を受信するステップ（S600）と、前記アクセス請求への検証を行うステップ（S610）と、請求元に目標リソースへのアクセスを許可するかどうかを確認するステップ（S620）とを含み、その中、当該アクセス請求への検証を行うステップは、目標リソースに関する業務状態の有効性を確認すること（S610）を含む。本発明に開示された方法および装置によれば、請求元のアクセス請求について処理する際に、請求元がアクセスを請求している目標リソースに対応する業務状態に組み合わせて、請求元のアクセス請求を受け入れるかどうかを確認することができ、アクセス制御方式の合理性を高め、ユーザー体験を多様化させることができる。

Description

本開示は、ネットワーク技術に関し、具体的には、リソースアクセスの制御方法及び装置に関する。

ネットワーク技術の発展に伴い、豊かなネットワークリソースを利用し様々なアプリケーションが開発され、人々の仕事と生活のニーズに大きな利便性をもたらしてきた。特に、「インターネット+」概念の提出によって、インターネットと様々な伝統的な産業を深く統合し、新しい発展エコロジーを創造してきた。例えば、インターネットビジネスでは、伝統的な業務は主に時間によって制限されている。例えば、電話業務、ホテル業務、賃貸業務などでは、ユーザーが関連業務を契約したら、業務有効期間内に、関連リソースに訪問することができる。

しかし、現在に、業務に対するリソース管理は、時間（アクセス可能時間など）、場所（GPSにアクセスする範囲）またはIPアドレス（アクセスするIPアドレス）などの要素しか考慮せず、業務自体の状態が考慮されていない。

上記の問題を解決するために、本開示は、リソースアクセスを制御する方法及び装置を提出し、ネットワーク特にモノのインターネット業務が多様性を持っている特性について、目標リソースの業務状態と組み合わせてリソースアクセスを制御し、アクセス制御方式の合理性を高め、アクセスポリシーの設定を簡素化し、ユーザー体験を向上させてきた。

本発明の第１の態様によれば、リソースアクセスの制御方法を提供し、請求元から目標リソースへのアクセス請求を受信するステップと、前記アクセス請求への検証を行うステップと、請求元に目標リソースへのアクセスを許可するかどうかを確認するステップとを含み、その中、当該アクセス請求への検証を行うステップは、目標リソースに関する業務状態の有効性を確認することを含む。

本発明の第２の態様によれば、リソースへのアクセス方法を提供し、目標リソースへのアクセス請求を送信するステップと、前記アクセス請求に対する検証が通ることを待つステップと、目標リソースへのアクセスを許可するかどうかを示す応答を受信するステップとを含み、その中、アクセス請求に、目標リソースの業務状態に対する検証をトリガする識別子を含む。

本発明の第３の態様によれば、リソースアクセス制御装置を提供し、請求元から目標リソースへのアクセス請求を受信する受信部と、目標リソースに関する業務状態の有効性を確認することを含む、前記アクセス請求への検証を行うプロセッサと、アクセス請求に対する検証結果に基づいて、請求元に目標リソースへのアクセスを許可するかどうかの応答を送信する送信部とを含む。

本発明の第４の態様によれば、リソースアクセス装置を提供し、目標リソースへのアクセス請求を送信する送信部と、目標リソースへのアクセスを許可するかどうかを示すための応答を受信する受信部と、送信したアクセス請求に、目標リソースの業務状態についての検証をトリガする識別子を添加し、かつ、受信部により目標リソースへのアクセスを許可する応答を受信した場合、目標リソースにアクセスするように該リソースアクセス装置を制御するプロセッサとを含む。

本発明の実施形態の技術策をより明確に説明するために、以下、実施形態の図面を簡単に説明する。なお、以下の説明における図面は、本発明のいくつかの実施形態の単なる例示であり、本発明を限定するものではない。
モノのインターネットの一共通アーキテクチャの模式図である。 図１に対応できる一論理構造の模式図である。 本開示の一実施例によるCSEBaseの元に構築したAEのリソース構造の模式図である。 本開示の一実施例によるリソースアクセスを制御する模式的プロセスを示す。 本開示の他の実施例によるリソースアクセスを制御する模式的プロセスを示す。 本開示の一実施例によるリソースアクセスを制御する方法の模式的フローを示す。 本開示の一実施例によるリソースアクセスを制御する装置の模式的ブロック図である。 本開示の他の実施例による制御装置の模式的ブロック図である。 本開示の一実施例によるリソースアクセスの方法の模式的フローを示す。 本開示の一実施例によるリソースアクセス装置の模式図である。 本開示の一実施例によるリソースへのアクセス装置の模式図である。

以下、添付図面を参照して本発明の実施の形態における技術策を明確かつ完全に説明する。なお、記載された実施形態は、本発明の一部であり、すべての実施形態ではない。本発明の実施形態に基づいて、当業者によって創作的な労働を行わずに得られる他の全ての実施形態も、本発明の範囲内にある。

本発明者には知られているように、現在、リソースアクセスに対する制御は、主に3つの方法がある：属性ベースのアクセス制御、役割ベースのアクセス制御、および動的授権のアクセス制御。

１. 属性ベースのアクセス制御では、リソース属性を設定することによってリソースアクセスを制御し、その中、アクセス制御リストを定義することによってリソースアクセスを制御することができ、アクセス制御リストには複数のパラメータを含み、例えば、リソースアクセスが許可される請求元、リソースアクセスを許可する関連条件、及び実行が許可される操作権限などを示すことができる。

２．役割ベースのアクセス制御では、役割を設定することによってリソースへのアクセスを制御することができ、異なる役割はアクセス権限が異なる。ユーザーは複数個の役割が付与されることができ、役割制御は役割サーバによって統一的に管理される。

３．動的授権のアクセス制御では、動的授権によって動的なアクセス制御を行うことができる。上記の二種のアクセス制御方法を元として、動的授権サーバDAS(Dynamic Access Server)によってアクセス権限の動的申請を実現し、請求元の申請手続きを簡単化にした。

図１は、モノのインターネットの一共通アーキテクチャの模式図である。図１に示すように、M２Mは、センシング層、ネットワーク層、アプリケーション層という三層に分けられ、その中、センシング層は、各種のセンサーによって構成され、例えば、赤外線センサー、電子タグ、カードリーダー、センサー、カメラ、GPSなどのセンサー端末を含む。センシング層は、モノのインターネットにおけるオブジェクト識別、情報収集のソースである。ネットワーク層は、インターネット、放送網、ネットワーク管理システム、クラウドコンピューティングプラットフォームなどの多様なネットワークで構成され、モノのインターネット全体の中心であり、センシング層で獲得した情報を伝送して処理する役割を担う。アプリケーション層は、モノのインターネットとユーザーの間のインターフェイスであり、それは業界のニーズと組み合わせて、モノのインターネットのインテリジェントなアプリケーションを達成する。

それに応じて、図２に示すように、モノのインターネットアーキテクチャのアプリケーション層に対応して、各設備及びセンサーのアプリケーション実体（AE）によりアプリケーションの管理およびアプリケーションと交互するための標準化インタフェースが提供される。アプリケーション層とネットワーク層の間に対応する業務層では、公共業務実体（CSE）がリソースの共有と相互運用性をサポートする。そのようなアーキテクチャの一つのメリトーとして、データの「プロデューサ」とデータの「コンシューマ」を安全に接続し、設定可能なポリシーを利用して、どのアプリケーションとユーザーがどのデバイスやセンサーにアクセスできるかを定義することができる。言い換えれば、リソースアクセス制御ポリシーを設定することによって、請求元のリソースアクセス請求に応答し対応するリソースを提供するかどうかを決定することができる。

上記のように、従来のリソースへのアクセス制御方法は、アクセス時間、役割時間などのような時間要素、アクセスされるアプリケーションのGPS範囲のような位置要素、アクセスされるアプリケーションのIPアドレスなどのようなネットワークアドレス要素を考慮して、前払い業務のリソースアクセス制御のニーズを満たしたが、多くの後払い業務のリソースアクセスは、時間、場所などによって個別に決定されるものではなく、業務状態と組み合わせて考慮してリソースアクセスを制御する必要がある。

そのため、本開示の実施例によれば、業務の運営状態と組み合わせてリソースアクセスを制御することが提案される。以下、モノのインターネット（M2M）の構造下に、本開示実施例の原理について詳細に説明する。具体的に、M２M下のアプリケーション実体AEをリソースへのアクセス請求を送信する請求元とし、公共業務実体（CSE）を相応のリソースを提供するサーバーとし、どのようにリソースの業務状態に応じてリソースアクセスを制御するかを説明する。なお、理解すべきところは、本開示の原理は、この特定の場合に限定されるものではなく、実際に、M2Mを通じて、CSEおよびAEによって提供されるリソースおよびサービスについてのアクセス制御のためのメカニズムを提案した。他のネットワークアーキテクチャおよびネットワークプロトコルを採用する場合にも本開示の原理を実現することができる。したがって、本開示の原理は、モノのインターネットでのアプリケーション実体及び公共業務実体に適用することに限定されず、ネットワークリソースアクセスを制御する任意の適切なネットワーク実体に適用することができる。

本開示の一実施態様では、アプリケーション実体AEに対応するアクセス制御ポリシー<accessControlPolicy>リソース中のパラメータを拡張し、リソースアクセスを制御するときに業務状態を考慮する必要があることを示す。実際に、CSEもアクセス制御ポリシー（ACP）を利用してリソースへのアクセスを制御することが可能である。本実施例では、リソースアクセス制御リストを補正することによって、リソースの相応な業務状態に基づいてリソースアクセスを制御することができる。具体的に、リソース<accessControlPolicy>は、１組のアクセス制御規則を表示する属性privilegesと selfPrivilegesを含み、該組アクセス制御規則は、どの実体が特定の言語環境（accessControlContexts）でのどのような操作権限を有することを定義し、CSEは該組規則を利用して特定リソースへのアクセス決定を行う。

下記の表１に示すように、リソース<accessControlPolicy>中のprivileges属性中のaccessControlContextsパラメータを拡張し、アクセス制御は業務状態を考慮する必要があるかどうかを示すサブパラメータaccessControlServiceStateを添加する。例えば、１は、アクセス制御が業務状態を考慮する必要があることを指し、０は、アクセス制御が業務状態を考慮しないことを指す。また、accessControlServiceruleを添加し、予め設定している業務情報規則を示すこともでき、その業務情報規則は、前記業務のライフサイクルにおける各業務状態情報の中の少なくとも一つを含む。

図３は、CSEBaseの元に構築したAEのリソース構造を概略的に示した。図３に示すように、AEのリソース<accessControlPolicy>の<privileges>属性下に、サブパラメータaccessControlServiceStateを添加して、リソース<container>のサブリソース<containerInstance>において、業務状態情報を保存してもよい。リソース<container>の属性accessControlPolicyIDsには、リソース<accessControlPolicy>の識別子リストを含み、リソース<accessControlPolicy>に定義される権限によって、誰かどの目的で（例えば、取得、更新、削除など）該属性を含むリソースにアクセスすることを許可するかを確定する。AEのリソース<container>は、他の実体と情報を共有し、潜在的にデータを追跡するために使用できる。よって、AEのリソース<container>のサブリソース<containerInstance>に保存されている業務状態情報は、他のAEに知られることができる。例として、サブリソース<containerInstance>にAEに関する業務注文情報、業務サービス情報などの情報を含むことができる。

図４は、本開示の一実施例によるリソースアクセスを制御する模式的プロセスを示す。図４に示すように、AEによって送信されたリソースアクセス請求を受信したら、CSEは、<accessControlPolicy>に規定されるアクセスポリシーに満たすかどうかを判断し、目標リソースの関連業務状態が有効かどうかを判断することを含む。有効の場合、リソースアクセスを許可とし、そうでない場合、リソースアクセスを不可とする。リソースアクセスを許可する場合、CSEは、AEにリソースアクセス応答を送信する。

選択的に、CSEは、受信したAEからのリソースアクセス請求に基づいて、該AEに対応するリソース<accessControlPolicy>の属性<privileges>のサブパラメータaccessControlServiceState が設定されたかどうかを確認する。該サブパラメータが設定された場合、アクセスするリソースに関する業務状態を考慮する必要がある。

選択的に、目標リソースに関する業務状態の有効性を確認するために、CSEは保存している業務状態の情報を予め設定した業務情報規則と比較する。

選択的に、業務情報規則は、業務の各状態に対応する情報を含む。例えば、業務の各状態とは、限定するではないが、下記の状態を含む：該業務に対するユーザーの予約完成、該業務についてユーザが既に支払い済み、ユーザのために該業務を実行中、業務実行済みだがユーザ未払い、業務実行済みかつユーザ支払い済み等。選択的に、ある業務例えビデオオンデマンドについて、関連業務状態によってユーザが既にビデオの視聴請求を送信したが、まだ支払っていないと判明したら、ユーザの視聴請求を拒否し、関連業務状態によってユーザが既に手付金を支払ったと判明したら、該ユーザが該ビデオのクリップを視聴することを許可してもよく、関連業務状態によってユーザが既に全額支払ったと判明したら、該ユーザーが該ビデオ全体を見ることを許可してもよい。

選択的に、業務情報規則は、業務のターゲットユーザーの個人情報を含んでもよい。例えば、業務のターゲットユーザーの範囲は１８以上のユーザーとし、または、業務はユーザーのその前の消費レベルーに基づいて優先順位を設定し、あるいは、業務はユーザに対して例えばビデオのダウンロード、コメント投稿、または新品情報のプッシュなどの権限を設定する。選択的に、保存している業務状態の情報によってユーザの年齢は１８歳未満であることを示す場合、該AEからのリソースアクセス請求を拒否してもよく、または、保存している業務状態の情報によってユーザの優先順位が該業務に対応する優先度閾値より高いことを示す場合、該AEからのリソースアクセス請求を許可してもよく、あるいは、保存している業務状態の情報によってユーザの権限が低いことを示す場合、該ユーザのコメント投稿の請求を拒否し、または該ユーザの新品情報の購読請求を拒否する。

選択的に、上記業務情報規則は組み合わせて用いてもよいし、単独で用いてもよく、ここに限定することとしない。

選択的に、受信したAEからのリソースアクセス請求と、AEがアクセスしようとする目標リソースに関連するアクセス制御ポリシーに基づいて、該AEについてどのアクセス制御ポリシーをさらに適用する必要があるかを判断してもよい。例えば、業務状態を考慮の上に、該AEに対応するリソース<accessControlPolicy>の属性<privileges>のその他のサブパラメータ、例えば<accessControlTimeWindow>、 <accessControlLocationRegion>または<accessControlIpIPAddress>に応じて、AEのリソースアクセス請求に応答することができる。AEがaccessControlPolicyに規定されるアクセスポリシーを満たすと判断した場合、AEにリソースアクセス応答を送信し、目標リソースへのアクセスを許可する。

選択的に、AEが以前にCSEとの業務接続を確立していない場合、AEからCSEに登録請求を送信することによって関連の接続を確立することができる。具体的に、図４に示すように、AEからCSEに登録請求を送信し、AEからの登録請求を受信し、かつ、AEについて検証を行ったら、CSEが該AEのために関連のリソースを作成する。業務状態に応じたリソースアクセス制御メカニズムを実現するために、上記のように、リソースアクセスの制御にターゲットリソースの業務状態を考慮する必要があることを示すように、AEのために作成したリソースにおいて、リソース<accessControlPolicy>の privileges属性中の accessControlContextsパラメータを拡張し、その中にaccessControlServiceStateアブパラメータを添加する。また、AEのために作成したリソース<container>のサブリソース<containerInstance>を業務状態情報の保存に使用してもよい。AEの登録請求に応答して、CSEは、対応するリソースが作成された後にAEに登録応答を送信することで、CSEとAEとの間に業務接続を確立する。選択的に、図４に示すように、２つのAE、即ちAE 1とAE２はそれぞれCSEに登録請求を送信し、CSEはそれぞれ対応するリソース<AE1>および<AE2>を作成し、登録応答をそれぞれAE1およびAE2に送信することで、AE1およびAE2のそれぞれと業務接続を確立する。

図４に示すように、CSEとの業務接続を確立した後、CSEは、業務状態情報を即時に取得することができる。そして、関連する業務状態情報を対応のAEのリソース<container>のサブリソース<containerInstance>の中に保存してもよい。また、上記のように、AE1およびAE2がお互いにそれぞれのリソース<container>の<containerInstance>に格納された業務状態情報を取得できように、AEのリソース<container>は、他の実体と情報を共有し、潜在的にデータを追跡することに用いられてもよい。

本開示の上述実施例によれば、リソースアクセス制御リストを拡張しかつアクセス制御業務状態識別子を添加することによって、請求元のリソースアクセス請求に対して処理する際に、目標リソースに対応する業務運営状態と組み合せて請求元の目標リソースへのアクセスを許可するかどうかを確認することができ、アクセス制御方式の合理性を高め、ユーザー体験を多様化させることができる。

また、本開示の他の実施例によれば、リソースアクセス制御方法を提供し、その中、リソースアクセスを制御する際に、請求元に対応する目標リソースの業務状態だけではなく、請求元の役割も考慮する。つまり、リソースの業務実行状態と請求元に割り当てられた役割とを組み合わせることによって、請求元からのリソースアクセス請求を受け入れるかどうかを決定することが可能である。そのため、下記の表２に示すように、リソース<role>の構造を拡張し、その中に、業務依存性識別子serviceDependenceを添加してもよい。

選択的に、該業務依存性識別子serviceDependenceは、アクセス制御に業務状態を考慮する必要があるかどうかを指示し、例えば、１は、リソースアクセス制御が業務状態に依存することを指し、０は、リソースアクセス制御が業務状態に依存しないことを指す。そして、予め設定している業務情報規則を示すために、accessControlServiceruleを添加することもできる。その中、業務情報規則は、業務のライフサイクルにおける各業務状態情報の中の少なくとも一つを含む。

以下、図５を参照し、それを詳細に説明する。図５に示すように、役割ベース制御の場合、請求元（例えばAE）が送信したリソースアクセス請求を受信したら、請求元の役割情報を検証する必要がある。具体的に、請求元AEがリソースアクセス請求を送信し、該リソースアクセス請求にはAEの役割情報を含む。その中、役割情報は、リソースアクセス制御が業務状態に依存することを示す業務依存性識別子、及びAEの役割IDなどのようなAEに関するその他の属性を含む。ホストCSEは、AEが送信したリソースアクセス請求を受信したら、PDP（Policy Decision Point、ポリシー決定点）にAEに関する役割情報を含めているアクセス確認請求を送信し、換言すれば、ホストCSEはPDPにアクセス制御決定請求を送信する。CSEが送信したアクセス確認請求を受信したら、PDPは、その中に含めているAEの役割情報に基づいてPIP（Policy Information Point、ポリシー情報点）にRole属性請求を送信することで、PIPが役割リポジトリ（role Repository）から該AEに対応する＜role＞リソース情報を取得するようにする。PIPが役割リポジトリから＜role＞リソースの獲得に対する応答を受信し、該AEに対応する＜role＞リソース情報を取得したら、それをrole属性応答としてPDPに送信する。このようにして、PDPがAEの役割IDに基づいて役割リポジトリから該AEに割り当てた役割割り当て情報を取得する。その後に、PDPが請求元AEの役割を検証し、そして役割と業務状態に基づいてアクセス制御決定を出す。選択的に、検証とは、限られることではないが下記のことを含むことができる：役割が有効な当局によって発行されるかどうか、役割の所有者が請求元と同じかどうか、該役割がまだ有効かどうかなど。検証を通った場合、PDPはアクセス制御決定を出し、CSEにアクセス確認応答を送信する。CSEがアクセス確認応答を受信したら、CSEはリソースの対応する業務状態を確認することができる。具体的に、ホストとしてのCSEが、請求された目標リソースの関連業務状態は有効であるかどうかを確認し、そしてPDPから送信してきたアクセス制御決定と組み合わせて、リソースアクセスを許可するかどうかを確認する。リソースの業務状態は有効であって、かつPDPからリソースアクセスを許可するような決定を返送した場合、CSEがAEのリソースアクセスを許可し、AEに対して肯定的なリソースアクセス応答を送信する。選択的に、CSEは、前に受信したAEのリソースアクセス請求に含まれる業務状態識別子に基づいて、リソースアクセスを制御する際に業務状態を考慮する必要があるかどうかを判定する。例えば、業務状態識別子によって、目標リソースに対して業務状態を考慮する必要がないことを示す場合、CSEは、PDPによって発行された肯定的なアクセス制御決定に基づいて、AEの目標リソースへのアクセスを許可することができる。その一方、業務状態識別子によって、目標リソースに対して業務状態を考慮する必要があることを示す場合、CSEは、目標リソースに対応の関連業務状態が有効であるかどうかを判断し、有効であり、且つPDPによって発行された肯定的なアクセス制御決定を受信したら、リソースアクセスを許可とし、その逆、関連業務状態が有効ではなくまたは肯定的なアクセス制御決定を受信していなければ、CSEはAEのリソースアクセス請求を拒否し、AEの目標資源へのアクセスを許可しないこととする。

注意すべきところは、図５には、CSEをPDP、PIPと別々に３つの独立実体を示したが、PDPとPIPは、該CSEに集積して一体化されてもよく、本開示の実施例では、それについて限定しないこととする。

選択的に、前に発信者AEに役割を割り当てられていない場合、役割ベースのリソースアクセス制御を実行するために、以下の方法によってAEに役割を割り当てることができる。具体的に、図５に示すように、AEが役割承認者、例えば役割リポジトリまたはホストであるCSEに、役割申請の請求を送信し、役割承認者が、役割割り当てポリシーに基づいて当該役割を発信者(例えば、請求元としてのAE)に割り当ててもよいかを確定する。選択的に、承認者は、直接に発信者に役割を割り当てることもできる。よって、役割承認者は、発信者AEが登録したCSEの下に対応のリソース<role>を作成する。上述のように、役割ベースのリソースアクセス制御中に対応の目標リソースの業務状態を考慮するために、作成したリソース<role>にパラメータserviceDependenceを含む。選択的に、デフォルトの場合、リソースアクセス制御を行う際にリソースの業務状態を考慮する必要があることを示すように、その値を“１”と予め設定することができる。その後に、発信者AEは、CSEから割り当てられるリソース<role>を取得することで、役割承認者によって割り当てられた役割情報を取得してもよい。

上述のように、本実施例では、発信者AEから送信されたリソースアクセス請求を受信したら、その中に含まれる業務依存性識別子serviceDependenceが設定されたかどうかを確認することで、リソースアクセスを制御する際に、目標リソースの業務状態を考慮することをトリガしてもよい。serviceDependenceが業務状態を考慮する必要があるように設定したことを確認したら、リソースの対応の業務状態の有効性を確認する必要がある。

業務状態の有効性を確認する場合、上記の本開示の実施例に記載の状況を参照して実行することができる。例えば、CSEによって目標リソースに関する業務運営状態を取得し、それと予め設定した業務情報規則と比較して、目標リソースの業務状態の有効性を確認することができる。

選択的に、本開示の上記の実施例に挙げたことに加えて、業務情報規則は、例えば、業務の開始、実行、終了などの実行状態も含むことができる。インテリジェントホームの場合、例えば、ユーザはモノのインターネットを介して洗濯機の動作を遠隔制御することができる。例えば、洗濯機は、組み込まれたアプリケーションを介してアプリケーション固有ノードADN-AEとして構成することができ、そして、家庭用ゲートウェイ（サービスプラットフォームとデータを交換するCSEとして設定可能）を通じてユーザのスマートフォン（発信者AEとして設定可能）との間で無線接続を行うことができる。該例において、発信者AEがCSEにリソースアクセス請求を送信し、洗濯機を制御するように目標リソースへのアクセスを請求する。CSEはまず発信者AE（スマートフォンの該アプリケーションに対応する）の役割を検証し、該AEの役割情報が、以前にサービスプラットフォームを介して該AEに割り当てられた役割情報と一致する場合、検証を通ることとする。また、AEの目標リソースへのアクセス、例え洗濯機への制御を実現するために、本開示の実施例によれば、業務情報規則について目標リソースに対応する業務状態の有効性を検証する必要もある。例えば、本例において、業務情報規則は、限定されるものではないが下記の業務状態情報を含むことができる：標準洗浄、素早い洗浄、穏やかな洗浄または強い洗浄のような、洗濯プログラムがまだ設定されていない；洗濯プログラムは設定されているが、洗濯機の起動時期はまだ設定されていない；洗濯機が既に起動し、洗濯プログラムは具体的に、洗濯、すすぎ、脱水などのどこまで進すむことも設定した。よって、CSEは目標リソースに対応する業務状態に基づいて、発信者AE（例えば、スマートフォンの該アプリケーション）が対応するリソースアクセス、例えば、対応の操作を実行することを許可する。例えば、業務状態として、まだ洗濯プログラム設定されていないとなっている場合、AEがユーザーのニーズに応じて適切な洗濯プログラムを設定することを許可することができる；洗濯プログラムは設定されているが、洗濯機がまだ起動されていない場合、AEに洗濯プログラムの変更や洗濯機の開始時間の設定を許可することができる；あるいは、洗濯機が起動されている場合、AEが洗濯機の現在の洗濯状態を取得し、必要に応じてある段階のプログラムを変更することを許可することができる。

本開示の上記実施例によれば、リソース<role>の構造を拡張し、業務依存性識別子serviceDependenceを添加することで、請求元のリソースアクセス請求について処理する際に、該目標リソースに対応する業務運営状態と組み合わせて、請求元の目標リソースへのアクセスを許可するかどうかを確認することができ、アクセス制御方式の合理性を高め、ユーザー体験を多様化させることができる。

図６は、本開示の一実施例によるリソースアクセスを制御する方法の模式的フローを示した。図６に示すように、該方法は、S600において、請求元からの目標リソースへのアクセス請求を受信するステップと、S610において、前記アクセス請求の検証を行うステップと、S620において、請求元の目標リソースへのアクセスを許可するかどうかを確認するステップとを含み、当該アクセス請求の検証は、目標リソースに関する業務状態の有効性を確認することを含む。

選択的に、該方法は、目標リソースに関する業務状態の情報を取得して保存するステップを、さらに含む。

選択的に、該方法は、目標リソースに関する業務状態の有効性を確認するように、保存した業務状態の情報を予め設定されている業務情報規則と比較するステップをさらに含む。

選択的に、前記業務情報規則は、業務に対応する各状態の情報を含む。

選択的に、前記業務情報規則は、業務が向けられるユーザの情報を含む。

選択的に、該方法は、目標リソースに関する業務状態が有効であると確認した場合、請求元に目標リソースへのアクセスを許可する応答を送信するステップをさらに含む。

選択的に、該方法は、請求元のアクセス請求に応じて、請求元の役割の有効性を検証するステップをさらに含む。

選択的に、該方法は、請求元の役割の有効性が検証に通っていない場合、請求元のアクセス請求を拒否する拒否をさらに含む。

選択的に、該方法は、アクセス制御ポリシーに関するリソースを作成し、その中にアクセス制御業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証するかどうかを示すステップをさらに含む。

選択的に、該方法は、役割に関するリソースを作成し、その中に業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証するかどうかを示すステップをさらに含む。

選択的に、該方法は、請求元からのアクセス請求を受信した場合、役割リポジトリから当該請求元に対応する役割割り当て情報を取得することで、請求元の役割の有効性を検証するステップをさらに含む。

選択的に、業務の各状態として、下記の少なくとも１項を含む：該業務に対して、ユーザ予約済み；該業務に対して、ユーザが前払金を支払い済み；ユーザのために該業務を実行中；業務が既に実行済みとなっているがユーザはまだ未払い；業務が既に実行済みであり、ユーザも支払い済みなど。

選択的に、業務が向けているユーザの情報は、下記の少なくとも１項を含む：該業務への参加を許可できるユーザーの範囲、該業務に参加するユーザーの優先度、および該業務に参加するユーザーの権限。

図７は、本開示の一実施例によるリソースアクセスを制御するための装置の模式的ブロック図である。図７に示すように、該装置は、請求元からの目標リソースへのアクセス請求を受信する受信部700と、前記アクセス請求の検証を行うプロセッサ710と、アクセス請求に対する検証結果に基づいて、請求元の目標リソースへのアクセスを許可するかどうの応答を送信する送信部720とを備え、当該アクセス請求に対する検証は、目標リソースに関する業務状態の有効性を確認することを含む。

選択的に、上記装置は、目標リソースに関する業務状態の情報を保存するためのメモリを内蔵または外付けてもよい。

選択的に、上記装置中のプロセッサは、保存されている業務状態の情報を予め設定される業務情報規則と比較することで、目標リソースに関する業務状態の有効性を確認する。

選択的に、前記業務情報規則は、業務に対応する各状態の情報を含む。

選択的に、前記業務情報規則は、業務が向けられるユーザの情報を含む。

選択的に、上記装置中のプロセッサは、さらに、目標リソースに関する業務状態が有効であると確認した場合、請求元にリソースへのアクセスを許可する応答を送信するように送信部を指示する。

選択的に、上記装置中のプロセッサは、さらに、請求元のアクセス請求に基づいて、請求元の役割の有効性を検証する。

選択的に、上記装置中のプロセッサは、さらに、請求元の役割の有効性が検証を通っていない場合、請求元のアクセス請求を拒否する。

選択的に、上記装置中のプロセッサは、さらに、アクセス制御ポリシーに関するリソースを作成し、その中にアクセス制御業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証するかどうかを示す。

選択的に、上記装置中のプロセッサは、さらに、役割に関するリソースを作成し、その中に業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証するかどうかを示す。

選択的に、上記装置中のプロセッサは、さらに、請求元からのアクセス請求を受信した場合、役割リポジトリから当該請求元に対応する役割割り当て情報を取得することで、請求元の役割の有効性を検証する。

図８は、本開示の他の実施例による制御装置の模式的ブロック図である。図８に示すように、該制御装置は、プロセッサ810、プロセッサと接続するメモリ820及びトランシーバ800とを備え、メモリ820にはコマンドを格納し、プロセッサ810はメモリ820に格納されたコマンドを運用するとき、下記のステップを実行するように配置される：トランシーバ800に、請求元からの目標リソースへのアクセス請求を受信するように指示するステップと、プロセッサ810により該アクセス請求を検証するステップと、アクセス請求に対する検証の結果によって、プロセッサは、トランシーバ800に、請求元の目標リソースへのアクセスを許可するかどうかの応答を請求元に発信するように指示するステップ。ただし、該アクセス請求を検証することは、目標リソースに関する業務状態の有効性を確認することを含む。

図９は、本開示の一実施例によるリソースアクセスの方法の模式的フローを示した。図９に示すように、該方法は、S900において、目標リソースへのアクセス請求を送信するステップと、S910において、前記アクセス請求に対する検証が通ることを待つステップと、S920において、目標リソースへのアクセスを許可するかどうかを示す応答を受信するステップとを含み、その中、アクセス請求に、目標リソースの業務状態を検証することをトリガする識別子を含む。

選択的に、前記識別子は、アクセス請求を受信した側が保存している目標リソースに関する業務状態の情報を予め設定している業務情報規則と比較して、目標リソースに関する業務状態の有効性を確認することをトリガする。

選択的に、前記業務情報規則は、業務に対応する各状態の情報を含む。

選択的に、前記業務情報規則は、業務が向けられるユーザの情報を含む。

選択的に、該方法は、アクセス請求に、アクセス請求の送信元の役割の検証をトリガする識別子を含む。

選択的に、該方法は、ために、アクセス制御ポリシーリソースを作成するための請求を送信し、その中に、作成の際にアクセス制御業務状態識別子を添加して、目標リソースの業務状態の有効性を検証する必要があるかどうかを示すステップをさらに含む。

選択的に、該方法は、役割に関するリソースを作成する請求を送信し、その中に、作成の際に業務状態識別子を添加して、目標リソースに関する業務状態の有効性を検証する必要があるかどうかを示すステップをさらに含む。

図１０は、本開示の一実施例によるリソースアクセス装置の模式図である。図１０に示すように、該リソースアクセス装置は、目標リソースへのアクセス請求を送信する送信部と、目標リソースへのアクセスを許可することを示すための応答を受信する受信部と、送信したアクセス請求に、目標リソースの業務状態について検証することをトリガするための識別子を添加し、かつ、受信部により目標リソースへのアクセスを許可する応答を受信した場合、目標リソースにアクセスするように該リソースアクセス装置を制御するプロセッサと、を備える。

図１１は、本開示の一実施例によるリソースアクセス装置の模式図である。図１１に示すように、該リソースアクセス装置は、プロセッサ、プロセッサと接続するメモリ及びトランシーバとを備え、メモリにはコマンドを格納し、プロセッサは、メモリに格納されたコマンドを運用するとき、トランシーバに、目標リソースへのアクセス請求を送信するように指示し、トランシーバにより目標リソースへのアクセスを許可する応答を受信した場合、目標リソースにアクセスするように該リソースアクセス装置を制御し、ただし、プロセッサは、送信したアクセス請求に目標リソースの業務状態についての検証をトリガするための識別子を添加して、目標リソースの業務状態の有効性を検証する必要があることを指示する。

本開示の上記の実施例によれば、リソースアクセス制御リストを拡張し、アクセス制御業務状態識別子を添加することによって、請求元のアクセス請求について処理する際に、請求元がアクセスを請求している該目標リソースに対応する業務運用状態と組み合わせて、請求元の目標リソースへのアクセスを受け入れるかどうかを確認することができ、アクセス制御方式の合理性を高め、ユーザーの体験を多様化させることができる。

また、本開示の上記の実施例によれば、リソース<role>の構造を拡張し、業務依存性識別子を添加することによって、請求元のリソースアクセス請求について処理する際に、請求元の役割に対する検証、および該目標リソースに対応する業務運用状態に合わせて、請求元の目標リソースへのアクセスを受け入れるかどうかを確認することができ、アクセス制御方式の合理性を高め、ユーザーの体験を多様化させることができる。

当業者にとって、本明細書におけるブロック図は、本開示の原理を実施する例示的回路の概念図を表すことが理解されるであろう。 同様に、任意のフローチャート、流れ図、状態遷移図、擬似コードなどは、コンピュータ読取可能な媒体に実質的に表現され、コンピュータまたはプロセッサ（それらのコンピュータまたはプロセッサがはっきり表示されるかどうかに問いあわず）によって実行され得る様々なプロセスを表すことができる。揮発性状態（信号）および不揮発性状態（例えば、CD-ROM、DVD、Blue-ray、ハードドライブ、フラッシュメモリカード、または他のタイプの有形の記憶媒体上で）で、書き込まれたコンピュータ読取可能な媒体およびコードを実行することができる。

図面に示された様々な要素の機能が、専用のハードウェアおよび適切なソフトウェアと共にソフトウェアを実行することができるハードウェアを使用して提供されることができる。プロセッサによって提供される場合、該機能は、単一の専用プロセッサ、または単一の共通プロセッサ、あるいは共通され得る複数の独立したプロセッサのうちのいくつかによって提供され得る。また、「プロセッサ」または「制御部」という用語は、ソフトウェアを実行することができるハードウェアに限定されるものではなく、デジタル信号プロセッサ（「DSP」）ハードウェア、ソフトウェアを格納するための読み出し専用メモリ（「ROM」）、ランダムアクセスメモリ（「RAM」）および不揮発性メモリも含むことができる。

以上、いくつかの特定の実施例を説明した。しかし、これらの実施例に変更を加えることができることを理解されたい。例えば、異なる実施例の要素を、組み合わせ、補足、修正、および削除し、他の実施例を得ることができる。さらに、既に上で開示した構造およびプロセスの代わりに他の構造およびプロセスを使用し、他の実施例を得ることは、当業者には理解されるであろう。他の実施形態は、本開示の実施例と少なくとも実質的に同じ方法で、実質的に同じ機能を達成し、本開示の実施例に提供された効果と実質的に同じ効果を達成する。したがって、これらおよび他の実施例も、本発明の範囲内である。

本願は、２０１６年７月２９日に出願した中国特許出願第２０１６１０６２０５９９．８の優先権を主張し、上記中国特許出願に開示のすべての内容が本出願の一部として参照により本明細書に組み込まれることとする。

７００ 受信部
７１０ プロセッサ
７２０ 送信部
８００ トランシーバ
８１０ プロセッサ
８２０ メモリ
１０００ 受信部
１０１０ プロセッサ
１０２０ 送信部
１１００ トランシーバ
１１１０ プロセッサ
１１２０ メモリ

Claims (20)

1. 請求元から目標リソースへのアクセス請求を受信するステップと、
   前記アクセス請求への検証を行うステップと、
   請求元の目標リソースへのアクセスを許可するかどうかを確認するステップと、を含み、
   その中、当該アクセス請求への検証を行うステップは、
   目標リソースに関する業務状態の有効性を確認することを含む、ことを特徴とするリソースアクセスの制御方法。
2. 目標リソースに関する業務状態の情報を取得するステップを
   さらに含むことを特徴とする請求項１に記載の制御方法。
3. 前記取得した業務状態の情報を業務情報規則と比較することで、目標リソースに関する業務状態の有効性を確認することを特徴とする請求項２に記載の制御方法。
4. 前記業務情報規則は、前記業務のライフサイクルにおける各業務状態情報の中の少なくとも一つを含むことを特徴とする請求項３に記載の制御方法。
5. 前記業務情報規則は、業務が向けられるユーザーの情報を含むことを特徴とする請求項３または４に記載の制御方法。
6. 目標リソースに関する業務状態が有効であると確認した場合、請求元に目標リソースへのアクセスを許可する応答を送信することを特徴とする請求項１乃至５のうちいずれか１項に記載の制御方法。
7. 請求元のアクセス請求に応じて、請求元のアクセス制御の有効性を検証するステップ
   をさらに含むことを特徴とする請求項１乃至５のうちいずれか１項に記載の制御方法。
8. 請求元のアクセス請求に応じて、請求元の役割の有効性を検証するステップ
   をさらに含むことを特徴とする請求項１乃至５のうちいずれか１項に記載の制御方法。
9. アクセス制御ポリシーに関するリソースを作成し、その中に業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証することを示すステップ
   をさらに含むことを特徴とする請求項１乃至６のうちいずれか１項に記載の制御方法。
10. 役割に関するリソースを作成し、その中に業務状態識別子を添加することで、目標リソースに関する業務状態の有効性を検証することを示すステップ
    をさらに含むことを特徴とする請求項７または８に記載の制御方法。
11. 請求元からのアクセス請求を受信した場合、役割リポジトリから当該請求元に対応する役割割り当て情報を取得して、請求元の役割の有効性を検証することを特徴とする請求項８に記載のリソースアクセスの制御方法。
12. 目標リソースへのアクセス請求を送信するステップと、
    前記アクセス請求に対する検証が通ることを待つステップと、
    目標リソースへのアクセスを許可するかどうかを示すための応答を受信するステップと、を含み、
    その中、アクセス請求には、目標リソースの業務状態に対する検証をトリガする識別子を含む、ことを特徴とするリソースへのアクセス方法。
13. 前記識別子は、アクセス請求を受信した側が保存している目標リソースに関する業務状態の情報を予め設定している業務情報規則と比較して、目標リソースに関する業務状態の有効性を確認するようにトリガすることを特徴とする請求項１２に記載のリソースへのアクセス方法。
14. 前記業務情報規則は、業務の各種状態に対応する情報を含むことを特徴とする請求項１３に記載のリソースへのアクセス方法。
15. 前記業務情報規則は、業務が向けられるユーザーの情報を含むことを特徴とする請求項１３または１４に記載のリソースへのアクセス方法。
16. アクセス請求には、アクセス請求の送信元の役割に対する検証をトリガする識別子を含むことを特徴とする請求項１２乃至１５にいずれか１項に記載のリソースへのアクセス方法。
17. 作成の際にアクセス制御業務状態識別子を添加するように請求することを含む、アクセス制御ポリシーリソースの作成の請求を送信して、目標リソースの業務状態の有効性を検証する必要があるかどうかを示すステップ
    をさらに含むことを特徴とする請求項１２乃至１５のうちいずれか１項に記載のリソースへのアクセス方法。
18. 作成の際に業務状態識別子を添加するように請求することを含む、役割に関するリソースの作成の請求を送信して、目標リソースに関する業務状態の有効性を検証する必要があるかどうかを示すステップ
    をさらに含むことを特徴とする請求項１２乃至１５のうちいずれか１項に記載のリソースへのアクセス方法。
19. 請求元から目標リソースへのアクセス請求を受信する受信部と、
    目標リソースに関する業務状態の有効性を確認することを含む、前記アクセス請求への検証を行うプロセッサと、
    アクセス請求に対する検証結果に基づいて、請求元に目標リソースへのアクセスを許可するかどうかの応答を送信する送信部と、
    を備えることを特徴とするリソースアクセス制御装置。
20. リソースアクセス装置であって、
    目標リソースへのアクセス請求を送信する送信部と、
    目標リソースへのアクセスを許可するかどうかを示す応答を受信する受信部と、
    送信したアクセス請求に、目標リソースの業務状態についての検証をトリガするための識別子を添加し、かつ、受信部により目標リソースへのアクセスを許可する応答を受信した場合、目標リソースにアクセスするように該リソースアクセス装置を制御するプロセッサと、
    を備えることを特徴とするリソースアクセス装置。