JP2018133762A

JP2018133762A - Ａｐｉ仲介装置及びサービスの利用動作設定方法

Info

Publication number: JP2018133762A
Application number: JP2017027700A
Authority: JP
Inventors: 健一橿渕; Kenichi Kashibuchi
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2017-02-17
Filing date: 2017-02-17
Publication date: 2018-08-23

Abstract

【課題】同一サービスの利用又は動作設定に係るユーザ及び第三者事業者の負担を改善する。
【解決手段】ＡＰＩ仲介装置３は、通信キャリアのサービスに対するユーザの設定情報を記憶しておくユーザ情報記憶部１５と、そのユーザによる通信キャリアの変更を検出する通信キャリア変更検出部１７と、通信キャリアの変更を検出した後、記憶していたユーザの設定情報を用いて同一のサービスの利用又は動作を設定するためのＡＰＩリクエストを生成するＡＰＩリクエスト生成部１８と、生成したＡＰＩリクエストを変更後の通信キャリアのＡＰＩ提供装置５へ送信するＡＰＩリクエスト処理部１１と、を備える。
【選択図】図１

Description

本発明は、ＡＰＩリクエストを制御する技術に関する。

ソフトウェアの機能をＡＰＩ（Application Programming Interface）として他の装置へ提供する装置として、例えば通信キャリアが提供するＡＰＩ提供装置がある（特許文献１，２など）。また、複数の通信キャリアが提供するＡＰＩを容易に利用するための装置として、例えば第三者事業者が提供するＡＰＩ利用装置、更にはＡＰＩ利用装置とＡＰＩ提供装置との間でＡＰＩを仲介する所有者不在又は所有者任意のＡＰＩ仲介装置がある（非特許文献１など）。

特開２０１６−１５１７８０号公報特開２０１６−１５１８８１号公報

"API Exchange"、GSMA、［online］、［平成29年2月9日検索］、＜URL: http://www.gsma.com/personaldata/api-exchange＞

ここで、複数の通信キャリアが自社通信キャリアのユーザ向けに同様のサービスを提供しており、各通信キャリアのＡＰＩ提供装置から、そのサービスの利用・動作を設定するためのＡＰＩが第三者事業者のＡＰＩ利用装置へ提供されている状況を考える。このとき、そのサービスの利用・動作設定を行ったユーザが通信キャリアを変更（転出及び転入）した場合、そのユーザは第三者事業者のＡＰＩ利用装置へその旨を通知し、そのＡＰＩ利用装置はＡＰＩ仲介装置を介して、変更後の通信キャリアが提供する設定ＡＰＩを実行してサービスの利用・動作設定を再度行う必要があった。

本発明は、上記事情を鑑みてなされたものであり、同一サービスの利用又は動作設定に係るユーザ及び第三者事業者の負担を改善することを目的とする。

以上の課題を解決するため、請求項１に係るＡＰＩ仲介装置は、通信キャリアのサービスに対するユーザの設定情報を記憶しておく記憶部と、前記ユーザが通信キャリアを変更した後、前記設定情報を用いて生成した同一のサービスの利用又は動作を設定するためのＡＰＩリクエストを変更後の通信キャリアのＡＰＩ提供装置へ送信する送信部と、を備えることを特徴とする。

請求項２に係るサービスの利用動作設定方法は、ＡＰＩ仲介装置で行うサービスの利用動作設定方法において、前記ＡＰＩ仲介装置が、通信キャリアのサービスに対するユーザの設定情報を記憶部に記憶しておくステップと、前記ユーザが通信キャリアを変更した後、前記設定情報を用いて生成した同一のサービスの利用又は動作を設定するためのＡＰＩリクエストを変更後の通信キャリアのＡＰＩ提供装置へ送信するステップと、を行うことを特徴とする。

本発明によれば、同一サービスの利用又は動作設定に係るユーザ及び第三者事業者の負担を軽減することができる。

システム構成を示す図である。ＡＰＩ仲介装置３の全体処理フローを示す図である。ＡＰＩリクエスト処理部１１の処理フローを示す図である。ＡＰＩレスポンス処理部１２の処理フローを示す図である。通信キャリア判定部１３の処理フローを示す図である。設定結果保存部１４の処理フローを示す図である。ユーザ情報の例を示す図である。通信キャリア情報取得部１６の処理フローを示す図である。通信キャリア情報の例を示す図である。通信キャリア変更検出部１７の処理フローを示す図である。ＡＰＩリクエスト生成部１８の処理フローを示す図である。ＡＰＩ仕様変換部１９の処理フローを示す図である。設定受付部２０の処理フローを示す図である。ＡＰＩ仕様情報の例を示す図である。本実施の形態と従来例との概説図である。

上記課題を解決するため、本発明は、ＡＰＩ仲介装置において、通信キャリアのサービスに対するユーザの設定情報を記憶しておき、通信キャリアの変更を検出した場合、その記憶していたユーザの設定情報を用いて変更後の通信キャリアの同一サービスに対してサービスの利用及び動作設定処理を自ら行う。これにより、ユーザ及び第三者事業者によるサービスの再申請処理が不要になり、同一サービスの利用・動作設定に係るユーザ及び第三者事業者の負担を軽減することができる。以下、本発明を実施する一実施の形態について図面を用いて説明する。

本実施の形態に係るシステム構成を図１に示す。このシステム構成では、１つのＡＰＩ利用装置１と、１つのＡＰＩ仲介装置３と、２つのＡＰＩ提供装置５と、１つの設定入力装置７と、１つのユーザ端末９と、を備えて構成される。これら各装置の総数は例であり、例えばＡＰＩ提供装置５を３つ以上備えてもよい。

ユーザ端末９は、例えば携帯電話やスマートフォンなど、エンドユーザにより使用され、通信キャリアで提供されるサービスを実行するためのクライアント端末である。

ＡＰＩ利用装置１は、第三者事業者により管理され、通信キャリアのＡＰＩ提供装置５で提供されるＡＰＩを活用して実現される第三者事業者のサービスをユーザ端末９へ提供する装置である。例えば、Ｗｅｂサーバが提供するＷｅｂサービスに係るユーザインターフェース（Ｗｅｂサービスの利用・動作に関する設定を行うための設定画面）を提供する。

ここで、通信キャリアの提供サービスを利用したい場合、ユーザにより、そのサービスを利用・動作するための申請処理が行われる。このとき、ＡＰＩ利用装置１では、ユーザにより指定されたサービスの利用・動作を設定するためのＡＰＩリクエストをＡＰＩ仲介装置３を介して通信キャリアへ送信する処理が行われる。

ＡＰＩ仲介装置３は、定期的に各ＡＰＩ提供装置５へそれぞれアクセスして通信キャリア情報（顧客情報を含む）を取得し、ユーザが利用中の通信キャリアを特定して、ＡＰＩ利用装置１からのＡＰＩリクエストを現在利用中の通信キャリアのＡＰＩ提供装置５へ中継する機能を備える。なお、ＡＰＩ仲介装置３の所有者又は管理者は不在又は任意であり、例えば、ＡＰＩ利用装置１の第三者事業者、ＡＰＩ提供装置５の通信キャリア、その他の独立事業者で管理等してもよい。

２つのＡＰＩ提供装置５は、それぞれ、互いに異なる２社の通信キャリアにより管理され、各通信キャリアの提供サービスの利用・動作を設定するためのＡＰＩをＡＰＩ仲介装置３を介してＡＰＩ利用装置１へ提供する機能を備える。また、２つのＡＰＩ提供装置５は、それぞれ、自社通信キャリアの通信網を介してサービス提供装置に接続されており、ＡＰＩ利用装置１からのＡＰＩリクエストをサービス提供装置へ送信し、そのＡＰＩリクエストで要求されたサービスに対してユーザ設定情報を設定する機能を備える。

設定入力装置７は、各通信キャリアでそれぞれ使用されるＡＰＩリクエスト及びＡＰＩレスポンスのＡＰＩ仕様情報をＡＰＩ仲介装置３に入力する機能を備える。

次に、ＡＰＩ仲介装置３の機能について説明する。本実施の形態において、ＡＰＩ仲介装置３は、図１に示す通り、ＡＰＩ利用装置１又はＡＰＩリクエスト生成部１８からのＡＰＩリクエストを処理するＡＰＩリクエスト処理部１１と、ＡＰＩ提供装置５からのＡＰＩレスポンスを処理するＡＰＩレスポンス処理部１２と、ユーザが利用中の通信キャリアを判定する通信キャリア判定部１３と、ＡＰＩリクエスト及びＡＰＩレスポンスから抽出されるユーザ設定情報を保存させる設定結果保存部１４と、そのユーザ設定情報と後述する通信キャリア情報とを記憶するユーザ情報記憶部１５と、ユーザが利用中の通信キャリアに関する通信キャリア情報を取得する通信キャリア情報取得部１６と、通信キャリアの変更を検出する通信キャリア変更検出部１７と、通信キャリアの変更を検出後、記憶していたユーザ設定情報を用いてＡＰＩリクエストを生成するＡＰＩリクエスト生成部１８と、各通信キャリアのＡＰＩ仕様情報に基づきＡＰＩリクエストの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換するＡＰＩ仕様変換部１９と、設定入力装置７で入力された各通信キャリアのＡＰＩ仕様情報を受け付ける設定受付部２０と、そのＡＰＩ仕様情報を記憶するＡＰＩ仕様記憶部２１と、を備えて構成される。

次に、ＡＰＩ仲介装置３の動作について説明する。ここでは、ＡＰＩ利用装置１と各ＡＰＩ提供装置５は、直接的・間接的を問わず、予めサービス利用・動作設定用のＡＰＩを利用する締結契約に基づき動作するものとする。また、通信キャリアを変更しても変わらないユーザ識別子（電話番号などの不変の値・一意の値）が存在し、サービス利用・動作設定用のＡＰＩリクエストには該ユーザ識別子が含まれるものとする。

まず、ＡＰＩ仲介装置３の全体動作（サービスの利用動作設定方法）について説明する。ＡＰＩ仲介装置３の全体処理フローを図２に示す。

最初に、ステップＳ１において、ＡＰＩ仲介装置３は、各通信キャリアの顧客情報に関する顧客情報ＡＰＩを使用し、各通信キャリアのＡＰＩ提供装置５を介して、定期的に各ユーザが利用中の通信キャリアに関する通信キャリア情報（顧客情報を含む）を取得する。

次に、ステップＳ２において、ＡＰＩ仲介装置３は、ＡＰＩ利用装置１からサービス利用・動作設定用のＡＰＩリクエストを受信した後、そのＡＰＩリクエストに含まれるユーザ識別子と通信キャリア情報とを参照してユーザが利用中の通信キャリアを特定し、その利用中のＡＰＩ提供装置５に対してＡＰＩリクエストを転送する。

次に、ステップＳ３において、ＡＰＩ仲介装置３は、転送先の通信キャリアから返信されたＡＰＩレスポンスが正常応答である場合、そのＡＰＩレスポンスに対応するＡＰＩリクエストを解析し、そのＡＰＩリクエスト及びＡＰＩレスポンスから抽出したユーザ設定情報を記憶する。

最後に、ステップＳ４において、ＡＰＩ仲介装置３は、ユーザによる通信キャリアの変更を検出後、変更前と同様のサービスをユーザに提供するため、記憶していたユーザ設定情報を用いて変更後の通信キャリアのサービス（変更前のサービスと同等のサービス）の利用・動作を設定するためのＡＰＩリクエストを自ら生成し、変更後の通信キャリアのＡＰＩ提供装置５へ送信する。

なお、ステップＳ１において、ＡＰＩ仲介装置３は、各通信キャリアが個々に管理する通信キャリア情報（顧客情報を含む）へアクセスする代わりに、複数の通信キャリアが共同で保有する顧客情報の共有データをＡＰＩなどを介して取得してもよい。また、ユーザが通信キャリアを変更した後に、変更後の通信キャリアが通信キャリア情報をＡＰＩ仲介装置３へ通知してもよい。

また、ステップＳ２において、ＡＰＩ仲介装置３は、各通信キャリアが使用するＡＰＩの仕様が異なる場合、ＡＰＩリクエスト及びＡＰＩレスポンスの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換してもよい。

また、ステップＳ４において、ＡＰＩ仲介装置３は、各通信キャリアの提供サービスの種別が同一か否かについて、例えば、サービスの種類を示すサービス種別識別子を各サービスに付与しておき、通信キャリアの変更前と変更後のサービスに係るサービス種別識別子を比較することによりサービスの同一性を判断してもよい。

続いて、ＡＰＩ仲介装置３を構成する各機能部の動作について説明する。

まず、ＡＰＩリクエスト処理部１１の動作について説明する。ＡＰＩリクエスト処理部１１の処理フローを図３に示す。

最初に、ステップＳ１１において、ＡＰＩリクエスト処理部１１は、ＡＰＩ利用装置１又はＡＰＩリクエスト生成部１８からＡＰＩリクエストを受信する。このＡＰＩリクエストには、少なくともユーザ識別子とサービスに対するユーザ設定情報とが含まれている。

次に、ステップＳ１２において、ＡＰＩリクエスト処理部１１は、そのＡＰＩリクエストに含まれる情報（ユーザ識別子を含む）を通信キャリア判定部１３へ送信し、リクエスト要求元のユーザが利用中の通信キャリアを判定する処理を要求する。

次に、ステップＳ１３において、ＡＰＩリクエスト処理部１１は、通信キャリア判定部１３から返信された利用中の通信キャリアの情報とＡＰＩリクエストに含まれる情報とをＡＰＩ仕様変換部１９へ送信し、ＡＰＩリクエストの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換する処理を要求する。

最後に、ステップＳ１４において、ＡＰＩリクエスト処理部１１は、仕様変換されたＡＰＩリクエストを利用中の通信キャリアのＡＰＩ提供装置５へ送信する。

次に、ＡＰＩレスポンス処理部１２の動作について説明する。ＡＰＩレスポンス処理部１２の処理フローを図４に示す。

最初に、ステップＳ２１において、ＡＰＩレスポンス処理部１２は、通信キャリアのＡＰＩ提供装置５からＡＰＩレスポンスを受信する。

次に、ステップＳ２２において、ＡＰＩレスポンス処理部１２は、そのＡＰＩレスポンスに含まれる情報をＡＰＩ仕様変換部１９へ送信し、ＡＰＩレスポンスの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換する処理を要求する。

次に、ステップＳ２３において、ＡＰＩレスポンス処理部１２は、そのＡＰＩレスポンスが正常な処理完了を示すか否かを判定する。例えば、ＡＰＩレスポンスに含まれるＡＰＩリクエストの処理結果（ＯＫ又はＮＧ）を元に判定する。

次に、ＡＰＩレスポンスが正常な処理完了を示す場合、ステップＳ２４において、ＡＰＩレスポンス処理部１２は、上記ＡＰＩレスポンスに対応するＡＰＩリクエストに含まれる情報（ユーザ設定情報を含む）を設定結果保存部１４へ送信し、その情報を保存する処理を要求する。一方、ＡＰＩレスポンスが正常な処理完了を示していない場合、ステップＳ２４をスキップしてステップＳ２５へ進む。

最後に、ステップＳ２５において、ＡＰＩレスポンス処理部１２は、ＡＰＩレスポンスをＡＰＩリクエスト元（ＡＰＩ利用装置１又はＡＰＩリクエスト生成部１８）へ送信する。

次に、通信キャリア判定部１３の動作について説明する。通信キャリア判定部１３の処理フローを図５に示す。

最初に、ステップＳ３１において、通信キャリア判定部１３は、ＡＰＩリクエスト処理部１１からのＡＰＩリクエストを解析し、対象ユーザのユーザ識別子を抽出する。

次に、ステップＳ３２において、通信キャリア判定部１３は、抽出したユーザ識別子を元に、その対象ユーザが利用中の通信キャリアの情報をユーザ情報記憶部１５から取得する。

次に、ステップＳ３３において、通信キャリア判定部１３は、そのユーザの通信キャリアの情報をユーザ情報記憶部１５から取得できたか否かを判定する。

次に、そのユーザの通信キャリアの情報をユーザ情報記憶部１５から取得できた場合、通信キャリア判定部１３は、取得した通信キャリアの情報をＡＰＩリクエスト処理部１１へ送信して処理を終了する。一方、そのユーザの通信キャリアの情報をユーザ情報記憶部１５から取得できない場合、ステップＳ３４において、ユーザ識別子を通信キャリア情報取得部１６へ送信し、そのユーザ識別子に対応する通信キャリアの情報を通信キャリアから取得する処理を要求してステップＳ３２へ戻る。

次に、設定結果保存部１４の動作について説明する。設定結果保存部１４の処理フローを図６に示す。

最初に、ステップＳ４１において、設定結果保存部１４は、ＡＰＩレスポンス処理部１２から送信されたＡＰＩリクエストに含まれる情報を解析し、対象ユーザのユーザ識別子を抽出する。

次に、ステップＳ４２において、設定結果保存部１４は、そのＡＰＩリクエストと該ＡＰＩリクエストに対応するＡＰＩレスポンスとを解析し、ＡＰＩリクエスト又はＡＰＩレスポンスに含まれるユーザ設定情報を抽出する。

最後に、ステップＳ４３において、設定結果保存部１４は、抽出したユーザ設定情報をユーザ識別子に関連付けてユーザ情報としてユーザ情報記憶部１５に記憶する。ユーザ情報の例を図７に示す。

次に、通信キャリア情報取得部１６の動作について説明する。通信キャリア情報取得部１６の処理フローを図８に示す。

最初に、ステップＳ５１において、通信キャリア情報取得部１６は、各通信キャリアが提供する顧客情報ＡＰＩを利用して通信キャリア情報（顧客情報を含む）を取得する。

最後に、ステップＳ５２において、通信キャリア情報取得部１６は、取得した通信キャリア情報をユーザ情報記憶部１５に記憶する。通信キャリア情報の例を図９に示す。通信キャリア情報には、ユーザ識別子と現在利用中（契約中）の通信キャリアの識別子とが関連付けて格納されている。

次に、通信キャリア変更検出部１７の動作について説明する。通信キャリア変更検出部１７の処理フローを図１０に示す。

最初に、ステップＳ６１において、通信キャリア変更検出部１７は、ユーザ情報記憶部１５を参照し、通信キャリア情報（図９）を元に通信キャリアが変更された全ユーザのユーザ識別子を抽出し、ユーザ情報（図７）を元に該ユーザ識別子に対応するユーザ設定情報を抽出する。

次に、ステップＳ６２において、通信キャリア変更検出部１７は、抽出したユーザ設定情報をＡＰＩリクエスト生成部１８へ送信し、ＡＰＩリクエストを生成する処理を要求する。

最後に、ステップＳ６３において、通信キャリア変更検出部１７は、抽出した全ユーザのユーザ設定情報についてＡＰＩリクエストの生成処理を要求したか否かを判定し、処理要求が完了した場合、ステップＳ６１へ戻り、処理要求が完了していない場合、ステップＳ６２へ戻る。ステップＳ６１〜ステップＳ６３は、定期的に繰り返し実行される。

次に、ＡＰＩリクエスト生成部１８の動作について説明する。ＡＰＩリクエスト生成部１８の処理フローを図１１に示す。

最初に、ステップＳ７１において、ＡＰＩリクエスト生成部１８は、通信キャリア変更検出部１７からのユーザ設定情報を元にユーザが利用中の全サービスに関する情報を抽出する。図７の場合、例えばユーザ利用中のサービスＸに対応するユーザの設定情報（amount:300 frequency:“monthly”など）を抽出する。

次に、ステップＳ７２において、ＡＰＩリクエスト生成部１８は、抽出したサービスを利用するため、そのサービスの利用・動作を設定するためのサービス利用・動作設定用のＡＰＩリクエストを生成する。

次に、ステップＳ７３において、ＡＰＩリクエスト生成部１８は、生成したＡＰＩリクエストをＡＰＩリクエスト処理部１１へ送信し、そのＡＰＩリクエストを送信する処理を要求する。

最後に、ステップＳ７４において、ＡＰＩリクエスト生成部１８は、抽出した全サービスについて処理が完了したか否かを判定し、処理が完了した場合、本処理を終了し、処理が完了していない場合、ステップＳ７２へ戻る。

次に、ＡＰＩ仕様変換部１９の動作について説明する。ＡＰＩ仕様変換部１９の処理フローを図１２に示す。

最初に、ステップＳ８１において、ＡＰＩ仕様変換部１９は、ＡＰＩリクエスト処理部１１又はＡＰＩレスポンス処理部１２からのデータが、ＡＰＩリクエストかＡＰＩレスポンスかを判定する。

次に、ＡＰＩリクエストの場合、ステップＳ８２において、ＡＰＩ仕様変換部１９は、その通信キャリアに対応するＡＰＩリクエストの仕様情報をＡＰＩ仕様記憶部２１から取得し、ステップＳ８３において、その仕様情報で受信したＡＰＩリクエストの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換する。

一方、ＡＰＩレスポンスの場合、ステップＳ８４において、ＡＰＩ仕様変換部１９は、該当の通信キャリアのＡＰＩレスポンスの仕様情報をＡＰＩ仕様記憶部２１から取得し、ステップＳ８５において、その仕様情報で受信したＡＰＩレスポンスの内容（ＡＰＩ仕様・ＡＰＩフォーマット）を変換する。

次に、設定受付部２０の動作について説明する。設定受付部２０の処理フローを図１３に示す。

最初に、ステップＳ９１において、設定受付部２０は、設定入力装置７で入力された各通信キャリアのＡＰＩの仕様情報を取得する。

最後に、ステップＳ９２において、設定受付部２０は、取得したＡＰＩ仕様情報をＡＰＩ仕様記憶部２１に記憶する。ＡＰＩ仕様情報の例を図１４に示す。図１４に示す通り、ＡＰＩのフォーマットは通信キャリア毎に異なるので、ユーザによる通信キャリアの変更が発生した場合には、そのフォーマットを変換する必要がある。

以上より、本実施の形態によれば、ＡＰＩ仲介装置３が、通信キャリアのサービスに対するユーザの設定情報を記憶しておき、そのユーザが通信キャリアを変更した後、その記憶していたユーザの設定情報を用いて生成した同一のサービスの利用・動作を設定するためのＡＰＩリクエストを変更後の通信キャリアのＡＰＩ提供装置５へ送信するので、ユーザが通信キャリアを変更した場合でも、ユーザ端末９及びＡＰＩ利用装置１はサービスの利用・動作設定について特段の対応を行うことなく従前のサービスと同じサービスを引き続き享受でき、同一サービスの利用・動作設定に係るユーザ及び第三者事業者の負担を軽減することができる（図１５参照）。

最後に、本実施の形態で説明したＡＰＩ仲介装置３は、コンピュータで実現できる。また、ＡＰＩ仲介装置３としてコンピュータを機能させるためのＡＰＩ仲介プログラム、そのＡＰＩ仲介プログラムの記憶媒体を作成することも可能である。

１…ＡＰＩ利用装置
３…ＡＰＩ仲介装置
５…ＡＰＩ提供装置
７…設定入力装置
９…ユーザ端末
１１…ＡＰＩリクエスト処理部（送信部）
１２…ＡＰＩレスポンス処理部
１３…通信キャリア判定部
１４…設定結果保存部
１５…ユーザ情報記憶部（記憶部）
１６…通信キャリア情報取得部
１７…通信キャリア変更検出部
１８…ＡＰＩリクエスト生成部
１９…ＡＰＩ仕様変換部
２０…設定受付部
２１…ＡＰＩ仕様記憶部

Claims

通信キャリアのサービスに対するユーザの設定情報を記憶しておく記憶部と、
前記ユーザが通信キャリアを変更した後、前記設定情報を用いて生成した同一のサービスの利用又は動作を設定するためのＡＰＩ（Application Programming Interface）リクエストを変更後の通信キャリアのＡＰＩ提供装置へ送信する送信部と、
を備えることを特徴とするＡＰＩ仲介装置。
ＡＰＩ仲介装置で行うサービスの利用動作設定方法において、
前記ＡＰＩ仲介装置が、
通信キャリアのサービスに対するユーザの設定情報を記憶部に記憶しておくステップと、
前記ユーザが通信キャリアを変更した後、前記設定情報を用いて生成した同一のサービスの利用又は動作を設定するためのＡＰＩ（Application Programming Interface）リクエストを変更後の通信キャリアのＡＰＩ提供装置へ送信するステップと、
を行うことを特徴とするサービスの利用動作設定方法。