特許 7406015 アプリケーション要求処理方法、システム、電子機器及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-18

(45)【発行日】2023-12-26

(54)【発明の名称】アプリケーション要求処理方法、システム、電子機器及び記憶媒体

(51)【国際特許分類】

   H04W 28/24 20090101AFI20231219BHJP

   H04W 88/14 20090101ALI20231219BHJP

   H04W 92/14 20090101ALI20231219BHJP

   H04W 92/24 20090101ALI20231219BHJP

   H04W 88/18 20090101ALI20231219BHJP

【ＦＩ】

H04W28/24

H04W88/14

H04W92/14

H04W92/24

H04W88/18

【請求項の数】 10

(21)【出願番号】P 2022580274

(86)(22)【出願日】2021-05-18

(65)【公表番号】

(43)【公表日】2023-07-20

(86)【国際出願番号】 CN2021094397

(87)【国際公開番号】W WO2021258923

(87)【国際公開日】2021-12-30

【審査請求日】2022-12-23

(31)【優先権主張番号】202010589409.7

(32)【優先日】2020-06-24

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】陳剛

(72)【発明者】

【氏名】張偉

(72)【発明者】

【氏名】姜志誠

【審査官】伊東 和重

(56)【参考文献】

【文献】3GPP TS29.513，3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3 (Release 16)，V16.3.0，3GPP，2020年03月27日，pp.43-46

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

アプリケーション要求処理方法であって、
同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各前記アプリケーション要求のサービスルールを含む全体のサービスルールを形成することを含む
アプリケーション要求処理方法。

【請求項2】

前記の同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、全体のサービスルールを形成することは、
同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なる場合、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加することを含む
請求項１に記載のアプリケーション要求処理方法。

【請求項3】

前記の同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なる場合、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加することの前に、
同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローが同じであり、且つ要求パラメータが異なる場合、前記ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なると判定することをさらに含む
請求項２に記載のアプリケーション要求処理方法。

【請求項4】

前記の同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、全体のサービスルールを形成することの後に、
前記全体のサービスルールをＳＭＦに発行し、前記ＳＭＦに前記全体のサービスルールを実行させることをさらに含む
請求項１に記載のアプリケーション要求処理方法。

【請求項5】

ＰＣＦ側に適用される
ことを特徴とする請求項１に記載のアプリケーション要求処理方法。

【請求項6】

前記アプリケーション要求は、ＱｏＳ保証、データオフロード、ＩＰＴＶ、およびバックグラウンドデータストリームを含む
請求項１に記載のアプリケーション要求処理方法。

【請求項7】

アプリケーション要求処理システムであって、
ＮＥＦとＰＣＦとを含み、
前記ＮＥＦは、ＡＦにより送信されたアプリケーション要求を受信し、前記アプリケーション要求に応じてサービスルールの許可を前記ＰＣＦに要求するように構成され、
前記ＰＣＦは、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各前記アプリケーション要求のサービスルールを含む全体のサービスルールを形成するように構成されている
アプリケーション要求処理システム。

【請求項8】

ＳＭＦをさらに含み、
前記ＰＣＦはさらに、前記全体のサービスルールを前記ＳＭＦに発行するように構成され、
前記ＳＭＦは、前記全体のサービスルールを実行するように構成されている
請求項７に記載のアプリケーション要求処理システム。

【請求項9】

電子機器であって、
少なくとも１つのプロセッサと、
前記少なくとも１つのプロセッサと通信可能に接続されたメモリと、を含み、
前記メモリには前記少なくとも１つのプロセッサにより実行できる指令が記憶され、前記指令が前記少なくとも１つのプロセッサにより実行された場合、前記少なくとも１つのプロセッサによって請求項１から６の何れか一項に記載のアプリケーション要求処理方法を実行できる
電子機器。

【請求項10】

コンピュータプログラムを記憶しているコンピュータ可読記憶媒体であって、前記コンピュータプログラムがプロセッサにより実行された場合、請求項１から６の何れか一項に記載のアプリケーション要求処理方法を実現する
コンピュータ可読記憶媒体。

【発明の詳細な説明】

【関連技術の相互参照】

【0001】

本願は出願番号が２０２０１０５８９４０９．７で、出願日が２０２０年６月２４日である中国特許出願に基づいて提出され、その中国特許出願の優先権を主張し、その中国特許出願の全文を援用により本願に組み入れる。

【技術分野】

【0002】

本願は、通信技術の分野に関し、特にアプリケーション要求処理方法、システム、電子機器及び記憶媒体に関する。

【背景技術】

【0003】

第三世代パートナーシッププロジェクト（３ＧＰＰ）には、第５世代（５ｔｈ ｇｅｎｅｒａｔｉｏｎ）移動通信ネットワークとして５Ｇネットワークを導入した。現在、３ＧＰＰが提案しているサービスベースインターフェースに基づくネットワークアーキテクチャは図１に示されており、その中で、ポリシー制御機能（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ、ＰＣＦ）はＱｏＳ、課金、アクセスおよびモビリティ、ユーザ機器（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ，ＵＥ）などのポリシー制御を行い、ネットワーク露出機能（Ｎｅｔｗｏｒｋ Ｅｘｐｏｓｕｒｅ Ｆｕｎｃｔｉｏｎ、ＮＥＦ）は第三者アプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ、ＡＦ）に５Ｇコアネットワークのポリシー制御能力を開放し、第三者ＡＦ要求に対して認証と翻訳を行い、ＡＦは、アプリケーション層のサービス情報をＰＣＦに提供し、ポリシー許可をＰＣＦに要求し、セッション管理機能（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ、ＳＭＦ）はパケットデータユニット（Ｐａｃｋｅｔ ｄａｔａ ｕｎｉｔ，ＰＤＵ）セッション情報をＰＣＦに提供し、ＰＣＦからＰＤＵセッションポリシーを取得し、ユーザプレーン機能（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ、ＵＰＦ）に発行して実行させる。

【0004】

しかしながら、ＡＦが同一ユーザの同一サービスに対して前後複数のアプリケーション要求を開始する場合、ＮＥＦは複数のＡＦ許可セッションをそれぞれＰＣＦと確立し、ＰＣＦは同一サービスに対して複数のサービスルールを発行することを決定するが、複数のサービスルールが受信されると、ＳＭＦは優先度の高いサービスルールを選択して実行するため、優先度の低いサービスルールは実行できず、対応するアプリケーション要求に応答できない。

【発明の概要】

【発明が解決しようとする課題】

【0005】

本願の実施形態の目的は、同一ユーザの同一サービスにおける複数のアプリケーション要求にすべて応答することを可能にするアプリケーション要求処理方法、システム、電子機器及び記憶媒体を提供することである。

【課題を解決するための手段】

【0006】

本願の実施形態はアプリケーション要求処理方法を提供し、前記アプリケーション要求処理方法は、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各前記アプリケーション要求のサービスルールを含む全体のサービスルールを形成することを含む。

【0007】

また、本願の実施形態は、ＮＥＦとＰＣＦとを含むアプリケーション要求処理システムをさらに提供し、前記ＮＥＦは、ＡＦにより開始されたアプリケーション要求を受信し、前記アプリケーション要求に応じてサービスルールの許可を前記ＰＣＦに要求するように構成され、前記ＰＣＦは、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各前記アプリケーション要求のサービスルールを含む全体のサービスルールを形成するように構成されている。

【0008】

本願の実施形態は電子機器をさらに提供し、前記電子機器は、少なくとも１つのプロセッサと、前記少なくとも１つのプロセッサと通信可能に接続されたメモリと、を含み、前記メモリには前記少なくとも１つのプロセッサにより実行できる指令が記憶されており、前記指令が前記少なくとも１つのプロセッサにより実行された場合、前記少なくとも１つのプロセッサにより上記に記載のアプリケーション要求処理方法を実行できる。

【0009】

本願の実施形態はコンピュータ可読記憶媒体をさらに提供し、前記コンピュータ可読記憶媒体はコンピュータプログラムを記憶しており、前記コンピュータプログラムがプロセッサにより実行された場合、上記に記載のアプリケーション要求処理方法を実現する。

【図面の簡単な説明】

【0010】

一つ又は複数の実施形態をそれに対応する添付図面中の画像によって例示的に示し、これらの例示的な説明は、実施形態に対する限定を構成するわけではない。

【図1】本願の第１実施形態により提供されるアプリケーション要求処理方法の応用シナリオを例示する図（サービスベースインターフェースに基づくネットワークアーキテクチャ図）である。

【図2】本願の第１実施形態により提供されるアプリケーション要求処理方法の模式フローチャートである。

【図3】本願の第２実施形態により提供されるアプリケーション要求処理方法の模式フローチャートである。

【図4】従来技術において、ＰＣＦがＡＦに対してまずＱｏＳ保証のアプリケーション要求を送信してから、さらにデータオフロードのアプリケーション要求を送信する模式的な決定フローチャートである。

【図5】本願の第２実施形態により提供されるアプリケーション要求処理方法において、ＰＣＦ側がＡＦに対してまずＱｏＳ保証のアプリケーション要求を開始してから、さらにデータオフロードのアプリケーション要求を開始する模式的な決定フローチャートである。

【図6】従来技術において、ＰＣＦがＡＦに対してまずデータオフロードのアプリケーション要求を開始してから、さらにＱｏＳ保証のアプリケーション要求を開始する模式的な決定フローチャートである。

【図7】本願の第２実施形態により提供されるアプリケーション要求処理方法において、ＰＣＦ側がＡＦに対してまずデータオフロードのアプリケーション要求を開始してから、さらにＱｏＳ保証のアプリケーション要求を開始する模式的な決定フローチャートである。

【図8】本願の第３実施形態により提供されるアプリケーション要求処理システムのモジュール構成模式図である。

【図9】本願の第３実施形態により提供されるアプリケーション要求処理システムの別のモジュール構成模式図である。

【図10】本願の第４実施形態により提供される電子機器の構造模式図である。

【発明を実施するための形態】

【0011】

本願の実施形態の目的、技術案及び利点をより明らかにするために、以下では、添付図面を組み合わせて本願の各実施形態を詳しく説明する。しかしながら、当業者であれば、本願の各実施形態において、読み手に本願をよりよく理解してもらうために多くの技術的詳細が提示されていることを理解することができる。しかし、これらの技術的詳細及び以下の各実施形態に基づく様々な変更及び修正がなくとも、本願の保護を求める技術案を実現することができる。以下の各実施形態の区分は、説明の便宜のためになされており、本願の具体的な実施形態にいかなる限定を構成すべきではなく、各実施形態は、矛盾しない限り、組み合わせたり互いを引用したりすることができる。

【0012】

本願の第１実施形態はアプリケーション要求処理方法に関し、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する否かを判定することにより、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各アプリケーション要求のサービスルールを含む全体のサービスルールを形成する。異なるアプリケーション要求に基づいて全体のサービスルールを形成することで、異なるアプリケーション要求のサービスルールがすべて全体のサービスルール内にあるようにできるため、各アプリケーション要求のサービスルールがすべて実行可能になり、対応するアプリケーション要求にすべて応答することが可能になる。

【0013】

なお、図１に示す応用シナリオは、本願の実施形態により提供されるアプリケーション要求処理方法の一つの可能な応用シナリオであり、本願の実施形態により提供されるアプリケーション要求処理方法は、他の類似した応用シナリオにも適用可能である。また、図１に示すＰＣＦは、本願の実施形態により提供されるアプリケーション要求処理方法の一つの可能な実行主体とすることができる。図１において、ＲＡＮはアクセスネットワーク（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒ１）であり、ＮＳＳＦはネットワークスライス選択機能（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ）であり、ＡＵＳＦは認証サーバ機能（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ）であり、ＡＭＦはアクセス及びモビリティ管理機能（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）であり、ＵＤＭは統合データ管理機能（Ｕｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ）である。

【0014】

本願の実施形態により提供されるアプリケーション要求処理方法の具体的な流れは図２に示すように、具体的には、以下のステップを含む。

【0015】

Ｓ１０１において、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する否かを判定し、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、Ｓ１０２を実行し、そうでなければ、フローを終了する。

【0016】

なお、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する否かを判定する際には、１． 同一ユーザであるか否かの判定、２． 同一サービスであるか否かの判定、３． アプリケーション要求が同じであるか否かの判定、との三つの条件による判定が含まれることが理解できる。三つの条件による判定の基準は、実際の状況に応じて設定することができるが、ここでは具体的な限定はしない。例えば、同一ユーザであるか否かの判定については、ユーザのＩＰアドレスが同一であるか否かによって判定することができる。同一サービスであるか否かの判定については、サービスフローが同じであるか否かによって判定することができる。アプリケーション要求が同じであるか否かの判定については、アプリケーション要求に対応する要求パラメータが同じであるか否かによって判定することができる。また、三つの条件による判定は、個別に判定しても、組み合わせて判定しもよく、例えば同一サービスであるか否かとアプリケーション要求が同じであるか否かを一緒にして判定してもよい。

【0017】

なお、本願の実施形態における「同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する否かの判定結果がＮＯである場合、フローを終了する」は、このうちの１つの実施形態に過ぎない。実際の応用では、上記の判定結果がＮＯである場合、ユーザが異なる、サービスが異なる、アプリケーション要求が同じであるなど、複数の結果を表すことが可能であり、実際の状況に応じて、対応する後続のフローを構成することができる。また、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有するとは、同一ユーザが同一サービスで異なるアプリケーション要求を同時に有することを意味し、例えば、ある時刻で２つ以上の異なるアプリケーション要求を有し、異なるアプリケーション要求の間には発生する後先の順番があってもよい。

【0018】

Ｓ１０２において、各アプリケーション要求のサービスルールを含む全体のサービスルールを形成する。

【0019】

全体のサービスルールを形成する際には、新しく発生するアプリケーション要求のサービスルールに基づいて、既に発生したアプリケーション要求のサービスルールを更新してもよく、２つ以上のアプリケーション要求のサービスルールに基づいてサービスルールを作成してもよい。全体のサービスルールの具体的な形成方法は、実際の必要に応じて構成できるが、ここでは具体的な限定はしない。なお、全体のサービスルールを形成することは、図１に示されるＰＣＦが全体のサービスルールを決定することにより実現することができる。

【0020】

一つの具体的な例において、全体のサービスルールを形成することの後に、全体のサービスルールをＳＭＦに発行し、ＳＭＦに全体のサービスルールを実行させることをさらに含む。全体のサービスルールをＳＭＦに発行することで、全体のサービスルールが実行され、各アプリケーション要求に対して対応する応答が提供される。

【0021】

全体のサービスルールをＳＭＦに発行した後に、ＳＭＦが全体のサービスルールを実行するようにするために、一例において、以前に発行されたサービスルールを全体のサービスルールに置き換えてもよく、全体のサービスルールのルール優先度を最も高く設定して、ＳＭＦがルール優先度の最も高いサービスルールを実行する特性を利用して、全体のサービスルールをＳＭＦに実行させてもよい。

【0022】

なお、全体のサービスルールをＳＭＦに発行することは、全体のサービスルールを実行させるためであり、サービスルールを実行すべき主体が変更してＳＭＦではなくなった場合、変更後のサービスルール実行主体に全体のサービスルールを発行することができる。

【0023】

一つの具体的な例において、本願の実施形態により提供されるアプリケーション要求方法はＰＣＦ側に適用される。同様に、アプリケーション要求方法をＰＣＦ側に適用するのは、現在の５ＧネットワークのアーキテクチャではＰＣＦ側がサービスルールを許可する主体とされているからであり、更新されたアーキテクチャでサービスルールを許可する主体が変更してＰＣＦ側ではなくなった場合、変更後のサービスルールを許可する主体にアプリケーション要求方法を適用することができる。

【0024】

１つの具体的な例において、アプリケーション要求は、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ，サービス品質）保証、データオフロード、ＩＰＴＶ、およびバックグラウンドデータストリームを含むことができる。他の例において、他のアプリケーション要求も可能であり、本願の実施形態はこれについて具体的に限定しない。

【0025】

本願の実施形態により提供されるアプリケーション要求処理方法によれば、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する否かを判定することにより、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各アプリケーション要求のサービスルールを含む全体のサービスルールを形成する。同一ユーザの同一サービス上での異なるアプリケーション要求のサービスルールがすべて全体のサービスルール内にあるため、全体のサービスルールが実行された場合、各アプリケーション要求のサービスルールがすべて実行可能であるため、各アプリケーション要求にすべて応答することが可能である。

【0026】

本願の第２実施形態は、アプリケーション要求処理方法に関し、第２実施形態は第１実施形態とほぼ同じであるが、主な違いは以下の通りである。本願の実施形態において、前記の同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、全体のサービスルールを形成することは、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なる場合、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加することを含む。現在の要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加することで、全体のサービスルールを形成し、既存のアプリケーション要求のサービスルールを実行する時に、現在のアプリケーション要求のサービスルールも実行可能になり、さらに現在のアプリケーション要求に応答するため、各アプリケーション要求に対してすべて応答することが可能である。

【0027】

本願の実施形態により提供されるアプリケーション要求処理方法の具体的な流れは図３に示すように、具体的には、以下のステップを含む。

【0028】

Ｓ２０１において、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なるか否かを判定し、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なる場合、Ｓ２０２を実行し、そうでなければ、フローを終了する。

【0029】

既存のアプリケーション要求とは、既に発生し、且つサービスルールが実行されているアプリケーション要求である。現在のアプリケーション要求とは、受信されたばかりで、まだ実行主体（例えばＰＣＦ側）によってサービスルールの許可を決定されていないアプリケーション要求である。

【0030】

なお、同様に、本願の実施形態における「同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なるか否かの判定結果がＮＯである場合、フローを終了する」は、このうちの１つの実施形態に過ぎない。実際の応用では、上記の判定結果がＮＯである場合、ユーザが異なる、サービスが異なる、アプリケーション要求が同じであるなど、複数の結果を表すことが可能であり、実際の状況に応じて、対応する後続のフローを構成することができる。

【0031】

一つの具体的な例において、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なるか否かを判定することは、具体的には、同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローおよび要求パラメータが同じであるか否かを判定することであってもよい。

【0032】

一例において、判定の結果、同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローが同じであり、且つ要求パラメータが異なる場合、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なると判定する。一例において、同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローおよび要求パラメータが同じであるか否かを判定する前に、まずは、現在のアプリケーション要求に対応する許可セッションと既存のアプリケーション要求の許可セッションとが反復セッションであるか否かを判定し、反復セッションである場合、現在のアプリケーション要求を無視し、反復セッションではない場合、同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローおよび要求パラメータが同じであるか否かをさらに判定してもよい。

【0033】

Ｓ２０２において、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加する。

【0034】

一例において、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルールに追加することは、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求の許可済のサービスルール内に更新することで、サービスルールの更新を完成させ、全体のサービスルールを形成することであってもよい。また、現在のアプリケーション要求のサービスルールと既存のアプリケーション要求のサービスルールを組み合わせて新しいサービスルールを得て、該新しいサービスルールに基づいて全体のサービスルールを得てもよい。

【0035】

本願の実施形態により提供されるアプリケーション要求処理方法をより明確に説明するために、以下では、２つの一般的なアプリケーション要求であるＱｏＳ保証、データオフロードを例に挙げて説明する。

【0036】

図４を参照し、図４は、いくつかの状況において、ＰＣＦがＡＦに対してまずＱｏＳ保証のアプリケーション要求を送信してから、さらにデータオフロードのアプリケーション要求を送信する模式的な決定フローチャートである。具体的には、以下の通りである。

【0037】

１． ＳＭＦは、ＰＤＵセッション確立要求を開始し、ＰＣＦはＰＤＵセッション確立要求を受けて、ＰＤＵセッションを確立する。

【0038】

２． ＡＦは、サービスフロー、ＵＥのＩＰアドレス、アップリンクとダウンリンクの帯域幅などのパラメータを含むＱｏＳ保証のアプリケーション要求をＮＥＦに送信する。

【0039】

３． ＮＥＦは、構成に基づいてサービスとＱｏＳパラメータのマッピングを行う。

【0040】

４． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション１を確立し、ここで、ポリシー許可セッション１は、メディアコンポーネント、サービスフロー、およびＱｏＳ要求を含む。

【0041】

５． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション１をバインドし、サービス情報およびＱｏＳ情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ１の許可を決定し、ＰＣＣ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｃｈａｒｇｉｎｇ，ポリシー制御及び課金） Ｒｕｌｅ１はルール優先度、サービスフロー１およびＱｏＳルール１を含む。

【0042】

６． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0043】

７． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を実行して、無線側と専用ベアラを確立して、ＱｏＳ保証を行う。

【0044】

８． ＡＦは、要求の需要に応じてユーザサービスについてサービスオフロード（すなわち、データオフロードを開始するアプリケーション要求）を行い、データオフロードのアプリケーション要求はすなわ、サービス影響ルーティング（サービスフロー、サービス影響ルーティングなどのパラメータを含む）の初期化である。

【0045】

９． ＮＥＦは、構成サービスと影響ルーティングパラメータに基づいてマッピングを完成させる。

【0046】

１０． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション２を確立し、ここで、ポリシー許可セッション２は、メディアコンポーネント、サービスフロー、ＤＮＡＩ、およびサービスルーティング情報を含む。

【0047】

１１． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション２をバインドし、サービス情報およびサービス影響ルーティング情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ２の許可を決定し、ＰＣＣ Ｒｕｌｅ２はルール優先度、サービスフロー１およびサービス影響ルーティングルール１を含む。

【0048】

１２． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ２をＳＭＦに発行する。

【0049】

１３． ＳＭＦは、ＰＣＣ Ｒｕｌｅ２を受信すると、ＰＣＣ Ｒｕｌｅ１とＰＣＣ Ｒｕｌｅ２を比較し、２つのルールのサービスフローが同じであるため、ＳＭＦは優先度の高いサービスルールを選択して実行し、選択しなかったサービスルールを実行しない。例えば、ルールＰＣＣ Ｒｕｌｅ１の優先度がＰＣＣ Ｒｕｌｅ２より高い場合、ＳＭＦはＰＣＣ Ｒｕｌｅ１のみを実行し、ＰＣＣ Ｒｕｌｅ２は実行されず、データオフロードのアプリケーション要求は応答されない。ルールＰＣＣ Ｒｕｌｅ１の優先度がＰＣＣ Ｒｕｌｅ２より低い場合、ＳＭＦはＰＣＣ Ｒｕｌｅ２のみを実行し、ＱｏＳ保証のアプリケーション要求は応答されない。

【0050】

ＳＭＦが優先度の高いサービスルールを選択して実行するため、優先度の低いサービスルールが実行されず、対応するアプリケーション要求に応答できない。

【0051】

図５を参照し、図５は本願の実施形態により提供されるアプリケーション要求処理方法において、ＰＣＦ側がＡＦに対してまずＱｏＳ保証のアプリケーション要求を開始してから、さらにデータオフロードのアプリケーション要求を開始する模式的な決定フローチャートである。具体的には、以下の通りである。

【0052】

１． ＳＭＦは、ＰＤＵセッション確立要求を開始し、ＰＣＦはＰＤＵセッション確立要求を受けて、ＰＤＵセッションを確立する。

【0053】

２． ＡＦは、サービスフロー、ＵＥのＩＰアドレス、アップリンクとダウンリンクの帯域幅などのパラメータを含むＱｏＳ保証のアプリケーション要求をＮＥＦに送信する。

【0054】

３． ＮＥＦは、構成に基づいてサービスとＱｏＳパラメータのマッピングを行う。

【0055】

４． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション１を確立し、ここで、ポリシー許可セッション１は、メディアコンポーネント、サービスフロー、およびＱｏＳ要求を含む。

【0056】

５． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション１をバインドし、サービス情報およびＱｏＳ情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ１の許可を決定し、ＰＣＣ Ｒｕｌｅ１はルール優先度、サービスフロー１およびＱｏＳルール１を含む。

【0057】

６． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0058】

７． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を実行して、無線側と専用ベアラを確立して、サービスのＱｏＳを保証する。

【0059】

８． ＡＦは、要求の需要に応じてユーザサービスについてサービスオフロード（すなわち、データオフロードを開始するアプリケーション要求）を行い、データオフロードのアプリケーション要求はすなわ、サービス影響ルーティング（サービスフロー、サービス影響ルーティングなどのパラメータを含む）の初期化である。

【0060】

９． ＮＥＦは、構成サービスと影響ルーティングパラメータに基づいてマッピングを完成させる。

【0061】

１０． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション２を確立し、ここで、ポリシー許可セッション２は、メディアコンポーネント、サービスフロー、ＤＮＡＩ、およびサービスルーティング情報を含む。

【0062】

１１． ＰＣＦは、ポリシー許可セッション２の確立要求を受信すると、サービス許可の決定を行う。具体的には、以下のことを含むことができる。

【0063】

（１）確立されたＰＤＵセッションにポリシー許可セッション２をバインドする。

【0064】

（２）ポリシー許可セッション２の確立要求と以前にＰＤＵセッションにバインドされた許可セッション要求のサービスフローが同じであり（一致し）、且つ、（サービスフロー以外の）他の許可要求パラメータが異なる（反復セッションではない）と判定された場合、サービスルールを更新する決定を検討する。

【0065】

（３）許可セッション情報に基づいてＰＣＣ Ｒｕｌｅ１の更新を決定し、サービスデータオフロードルールを追加し、更新後のＰＣＣ Ｒｕｌｅ１にルール優先度、サービスフロー１、ＱｏＳルール１、およびサービス影響ルーティングルール１を含ませる。

【0066】

１２． ＰＣＦは、更新後のポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0067】

１３． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を受信すると、ルールを実行し、ＵＰＦを選択してデータをデータネットワークにオフロード（データオフロードを実現）し、以前のサービスデータのＱｏＳ保証ポリシーを維持する。

【0068】

データオフロードのアプリケーション要求のサービスルールに基づいて、既存のＱｏＳ保証のサービスルールを更新し、更新後のサービスルールにＱｏＳ保証のサービスルールとデータオフロードのサービスルールとの両方を含ませることにより、ＱｏＳ保証とデータオフロードとの２つの異なるアプリケーション要求にすべて応答できるように、ＱｏＳ保証を実現すると同時にデータオフロードを実現する。

【0069】

図６を参照し、図６はいくつかの状況において、ＰＣＦがＡＦに対してまずデータオフロードのアプリケーション要求を開始してから、さらにＱｏＳ保証のアプリケーション要求を開始する模式的な決定フローチャートであり、具体的には以下のとおりである。

【0070】

１． ＳＭＦは、ＰＤＵセッション確立要求を開始し、ＰＣＦはＰＤＵセッション確立要求を受けて、ＰＤＵセッションを確立する。

【0071】

２． ＡＦは、要求の需要に応じてユーザサービスについてサービスオフロード（すなわち、データオフロードを開始するアプリケーション要求）を行い、データオフロードのアプリケーション要求はすなわ、サービス影響ルーティング（サービスフロー、サービス影響ルーティングなどのパラメータを含む）の初期化である。

【0072】

３． ＮＥＦは、構成サービスと影響ルーティングに基づいてパラメータマッピングを完成させる。

【0073】

４． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション１を確立し、ここで、ポリシー許可セッション１は、メディアコンポーネント、サービスフロー、ＤＮＡＩ、およびサービスルーティング情報を含む。

【0074】

５． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション１をバインドし、サービス情報およびサービス影響ルーティング情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ１の許可を決定し、ＰＣＣ Ｒｕｌｅ１はルール優先度、サービスフロー１およびサービス影響ルーティングルール１を含む。

【0075】

６． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0076】

７． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を実行し、ＵＰＦを選択してサービスデータをデータネットワークにオフロード（データオフロードを実現）する。

【0077】

８． ＡＦは、サービスフロー、ＵＥのＩＰアドレス、アップリンクとダウンリンクの帯域幅などのパラメータを含むＱｏＳ保証のアプリケーション要求をＮＥＦに送信する。

【0078】

９． ＮＥＦは、構成に基づいてサービスとＱｏＳパラメータのマッピングを行う。

【0079】

１０． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション２を確立し、ここで、ポリシー許可セッション２は、メディアコンポーネント、サービスフロー、およびＱｏＳ要求を含む。

【0080】

１１． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション２をバインドし、サービス情報およびＱｏＳ情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ２の許可を決定し、ＰＣＣ Ｒｕｌｅ２はルール優先度、サービスフロー１およびＱｏＳルール１を含む。

【0081】

１２． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ２をＳＭＦに発行する。

【0082】

１３． ＳＭＦは、ＰＣＣ Ｒｕｌｅ２を受信すると、ＰＣＣ Ｒｕｌｅ１とＰＣＣ Ｒｕｌｅ２を比較し、２つのルールのサービスフローが同じであるため、ＳＭＦは優先度の高いサービスルールを選択して実行し、選択しなかったサービスルールを実行しない。例えば、ルールＰＣＣ Ｒｕｌｅ１の優先度がＰＣＣ Ｒｕｌｅ２より高い場合、ＳＭＦはＰＣＣ Ｒｕｌｅ１のみを実行し、ＰＣＣ Ｒｕｌｅ２は実行されず、ＱｏＳ保証のアプリケーション要求は応答されない。ルールＰＣＣ Ｒｕｌｅ１の優先度がＰＣＣ Ｒｕｌｅ２より低い場合、ＳＭＦはＰＣＣ Ｒｕｌｅ２のみを実行し、データオフロードのアプリケーション要求は応答されない。

【0083】

ＳＭＦが優先度の高いサービスルールを選択して実行するため、優先度の低いサービスルールが実行されず、対応するアプリケーション要求に応答できない。

【0084】

図７を参照し、図７は本願の実施形態により提供されるアプリケーション要求処理方法において、ＰＣＦ側がＡＦに対してまずデータオフロードのアプリケーション要求を開始してから、さらにＱｏＳ保証のアプリケーション要求を開始する模式的な決定フローチャートである。具体的には、以下の通りである。

【0085】

１． ＳＭＦは、ＰＤＵセッション確立要求を開始し、ＰＣＦはＰＤＵセッション確立要求を受けて、ＰＤＵセッションを確立する。

【0086】

２． ＡＦは、要求の需要に応じてユーザサービスについてサービスオフロード（すなわち、データオフロードを開始するアプリケーション要求）を行い、データオフロードのアプリケーション要求はすなわ、サービス影響ルーティング（サービスフロー、サービス影響ルーティングなどのパラメータを含む）の初期化である。

【0087】

３． ＮＥＦは、構成サービスと影響ルーティングパラメータに基づいてマッピングを完成させる。

【0088】

４． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション１を確立し、ここで、ポリシー許可セッション１は、メディアコンポーネント、サービスフロー、ＤＮＡＩ、およびサービスルーティング情報を含む。

【0089】

５． ＰＣＦは、確立されたＰＤＵセッションにポリシー許可セッション１をバインドし、サービス情報およびサービス影響ルーティング情報に基づいてサービスルールＰＣＣ Ｒｕｌｅ１の許可を決定し、ＰＣＣ Ｒｕｌｅ１はルール優先度、サービスフロー１およびサービス影響ルーティングルール１を含む。

【0090】

６． ＰＣＦは、ポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0091】

７． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を実行し、ＵＰＦを選択してサービスデータをデータネットワークにオフロード（データオフロードを実現）する。

【0092】

８． ＡＦは、サービスフロー、ＵＥのＩＰアドレス、アップリンクとダウンリンクの帯域幅などのパラメータを含むＱｏＳ保証のアプリケーション要求をＮＥＦに送信する。

【0093】

９． ＮＥＦは、構成に基づいてサービスとＱｏＳパラメータのマッピングを行う。

【0094】

１０． ＮＥＦは、Ｎｐｃｆ＿ＰｏｌｉｃｙＡｕｔｈｏｒｉｚａｔｉｏｎ＿Ｃｒｅａｔｅを呼び出してポリシー許可セッション２を確立し、ここで、ポリシー許可セッション２は、メディアコンポーネント、サービスフロー、およびＱｏＳ要求を含む。

【0095】

１１． ＰＣＦは、ポリシー許可セッション２の確立要求を受信すると、サービス許可の決定を行う。具体的には、以下のことを含むことができる。

【0096】

（１）確立されたＰＤＵセッションにポリシー許可セッション２をバインドする。

【0097】

（２）ポリシー許可セッション２の確立要求と以前にＰＤＵセッションにバインドされた許可セッション要求のサービスフローが同じであり（一致し）、且つ、（サービスフロー以外の）他の許可要求パラメータが異なる（反復セッションではない）と判定された場合、サービスルールを更新する決定を検討する。

【0098】

（３）許可セッション情報に基づいてＰＣＣ Ｒｕｌｅ１の更新を決定し、サービスＱｏＳ保証ルールを追加し、更新後のＰＣＣ Ｒｕｌｅ１にルール優先度、サービスフロー１、サービス影響ルーティングルール１、およびＱｏＳルール１を含ませる。

【0099】

１２． ＰＣＦは、更新後のポリシールールＰＣＣ Ｒｕｌｅ１をＳＭＦに発行する。

【0100】

１３． ＳＭＦは、ＰＣＣ Ｒｕｌｅ１を受信すると、ルールを実行し、専用ベアラを確立してサービスのＱｏＳを保証（ＱｏＳ保証を実現）し、サービスデータを以前のデータネットワークにオフロードすること（データオフロード）を維持する。

【0101】

ＱｏＳ保証のアプリケーション要求のサービスルールに基づいて、既存のデータオフロードのサービスルールを更新し、更新後のサービスルールにデータオフロードのサービスルールとＱｏＳ保証のサービスルールとの両方を含ませることにより、データオフロードとＱｏＳ保証との２つの異なるアプリケーション要求にすべて応答できるように、データオフロードを実現すると同時にＱｏＳ保証を実現する。

【0102】

本願の実施形態により提供されるアプリケーション要求処理方法によれば、現在の要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加することで、全体のサービスルールを形成し、既存のアプリケーション要求のサービスルールを実行する時に、現在のアプリケーション要求のサービスルールも実行可能になり、さらに現在のアプリケーション要求に応答するため、各アプリケーション要求に対してすべて応答することが可能である。

【0103】

当業者であれば、上記の各種方法のステップ分けは、単に明確に説明するためになされたものであり、実装時に１つのステップに統合するか、又は一部のステップを複数のステップに再分割することができ、同一の論理的関係が含まれていれば、いずれも本願の保護範囲内に含まれること、アルゴリズム及びプロセスの中核となる設計を変更せずに、そのアルゴリズム又はプロセスに重要でない修正を加えたり、又は重要でない設計を導入したりしたものであれば、いずれも本願の保護範囲内に含まれることは、理解できるであろう。

【0104】

本願の第３実施形態は、図８に示すように、ＮＥＦ ３０１とＰＣＦ ３０２とを含むアプリケーション要求処理システムに関する。具体的には、以下の通りである。

【0105】

ＮＥＦ ３０１は、ＡＦにより送信されたアプリケーション要求を受信し、アプリケーション要求に応じてサービスルールの許可をＰＣＦ ３０２に要求するように構成され、
ＰＣＦ ３０２は、同一ユーザが同一サービス上で２つ以上の異なるアプリケーション要求を有する場合、各アプリケーション要求のサービスルールを含む全体のサービスルールを形成するように構成されている。

【0106】

図９を参照し、図９は本願の実施形態により提供されるアプリケーション要求処理システムの別のモジュール構成模式図である。すなわち、アプリケーション要求処理システムは、ＳＭＦ ３０３をさらに含み、具体的には、以下の通りである。

【0107】

ＰＣＦ ３０２はさらに、全体のサービスルールをＳＭＦ ３０３に発行するように構成されている。

【0108】

ＳＭＦ ３０３は、全体のサービスルールを実行するように構成されている。

【0109】

さらに、ＰＣＦ ３０２はさらに、同一ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なる場合、現在のアプリケーション要求のサービスルールを既存のアプリケーション要求のサービスルール内に追加するように構成されている。

【0110】

さらに、ＰＣＦ ３０２はさらに、同一ユーザの現在のアプリケーション要求と既存のアプリケーション要求のサービスフローが同じであり、且つ要求パラメータが異なる場合、前記ユーザの同一サービス上での現在のアプリケーション要求が既存のアプリケーション要求と異なると判定するように構成されている。

【0111】

さらに、アプリケーション要求は、ＱｏＳ保証、データオフロード、ＩＰＴＶ、およびバックグラウンドデータストリームを含む。

【0112】

本実施形態は、第１実施形態及び第２実施形態に対応するシステム実施形態であり、本実施形態は第１実施形態及び第２実施形態と組み合わせて実施できることは、容易に理解できる。第１実施形態および第２実施形態で記載された関連する技術的詳細は、本実施形態においても有効であるため、重複を減らすためにここでは説明を省く。したがって、本実施形態で記載された関連する技術的詳細は、第１実施形態及び第２実施形態にも適用可能である。

【0113】

なお、本実施形態に係る各モジュールはいずれも論理モジュールであり、実際の応用において、１つの論理ユニットは１つの物理ユニットであってもよく、１つの物理ユニットの一部であってもよく、さらに、複数の物理ユニットの組み合わせで実現してもよい。また、本願の創造的な部分を強調するために、本願で提起された技術的課題の解決にあまり関係のない手段は本実施形態には導入されていないが、これは本実施形態に他の手段が存在しないことを示しているわけではない。

【0114】

本願の第４実施形態は電子機器に関する。図１０に示すように、少なくとも１つのプロセッサ４０１、少なくとも１つのプロセッサ４０１と通信可能に接続されたメモリ４０２とを含み、メモリ４０２には少なくとも１つのプロセッサ４０１により実行できる指令が記憶されており、指令が少なくとも１つのプロセッサ４０１により実行された場合、少なくとも１つのプロセッサ４０１により上記したアプリケーション要求処理方法を実行できる。

【0115】

ここで、メモリおよびプロセッサはバス方式で接続され、バスは任意の数の相互接続されたバスおよびブリッジを含むことができ、バスによって１つまたは複数のプロセッサとメモリの様々な回路が一つに接続される。バスはまた、周辺機器、電圧安定器、およびパワーマネジメント回路などの様々な他の回路を一つに接続することができるが、これらは当分野で周知なことであるので、本文ではこれ以上説明しない。バスインターフェースは、バスとトランシーバとの間のインターフェースを提供する。トランシーバは、１つの素子であってもよく、複数の受信機および送信機のような複数の素子であってもよく、伝送媒体上で様々な他の装置と通信するための手段を提供する。プロセッサによって処理されたデータはアンテナを介して無線媒体で伝送され、さらに、アンテナはまたデータを受信して、プロセッサにデータを伝送する。

【0116】

プロセッサは、バスの管理および通常の処理を担う以外にも、さらにタイミング、周辺インターフェース、電圧調整、電源管理、およびその他の制御機能を含む様々な機能を提供することができる。一方、メモリは、プロセッサによって操作を実行するときに使用されるデータを記憶するために使用されてもよい。

【0117】

本願の第５実施形態は、コンピュータプログラムを記憶しているコンピュータ可読記憶媒体に関する。コンピュータプログラムがプロセッサにより実行された時、上記の方法実施形態を実現する。該コンピュータ可読記憶媒体は情報（例えばコンピュータ可読指令、データ構造、コンピュータプログラムモジュールまたは他のデータ）を記憶するための任意の方法または技術において実施される、揮発性または不揮発性の、取り外し可能または取り外し不可能な媒体を含む。

【0118】

すなわち、当業者であれば、上記の実施形態の方法における全部または一部のステップを実施することは、プログラムによって関連するハードウェアに指令することによって実現できることは、理解できるであろう。このプログラムは１つの記憶媒体に記憶され、１つの装置（ワンチップコンピュータ、チップなどであってもよい）またはプロセッサ（ｐｒｏｃｅｓｓｏｒ）に本願の各実施形態に記載の方法の全部または一部のステップを実行させるためのいくつかの指令を含む。一方、前記した記憶媒体は、ＵＳＢメモリ、リムーバブルハードディスク、リードオンリーメモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスク等、プログラムコードを記憶可能な種々の媒体を含む。

【0119】

当業者であれば、上記に開示された方法における全部または一部のステップ、システム、装置内の機能モジュール／ユニットはソフトウェア（コンピューティング装置により実行できるコンピュータプログラムコードで実現できる）、ファームウェア、ハードウェア及びそれらの適切な組み合わせにより実施できることは明白である。ハードウェア実施形態において、以上の説明に記述された機能モジュール／ユニット間の区分は、物理的組立体の区分に必ずしも対応しているとは限らず、例えば、一つの物理的組立体は複数の機能を有してもよく、また、一つの機能またはステップは複数の物理的組立体が協力して実行できる。いくつかの物理的組立体またはすべての物理的組立体は、中央処理装置、デジタルシグナルプロセッサまたはマイクロプロセッサのようなプロセッサによって実行されるソフトウェアとして、あるいはハードウェアとして、あるいは特定用途向け集積回路のような集積回路として実施することができる。

【0120】

当業者であれば、上記の各実施形態は、本願を実施するための具体的な実施形態であり、実際の応用においては、本願の精神及び範囲を逸脱することなく、形式的に及び細部に様々な変更を加えることができることを理解することができる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】