(58)【調査した分野】(Int.Cl.,DB名)
第3の国において、1台以上のエッジ機器と通信可能に接続されたエッジサーバで稼働するアプリケーションのオンラインストア販売を管理する、前記第3の国に対応する海外対応アプリケーション販売管理サーバシステムであって、
前記第3の国に設置された前記エッジ機器及び前記エッジサーバを使用するユーザの備えるユーザ端末に対して通信ネットワークを介して通信可能に接続され、
オンラインストア販売登録される前記アプリケーションを記憶するアプリDBと
前記アプリDBに記憶されたオンラインストア販売登録された前記アプリケーションのみを購入可能とするオンラインストア販売を管理する管理制御部と、
前記アプリケーションを前記エッジサーバに配信する配信制御部と、
を備え、
前記管理制御部は、
前記ユーザから前記ユーザ端末を介して購入要求された前記アプリケーションが前記第3の国を除く国のアプリ開発者である3rdパーティの開発した3rdアプリであるか否かを判定する発注処理部と、
前記発注処理部により、購入要求された前記アプリケーションが3rdパーティの開発した3rdアプリであると判定された場合、前記ユーザに対して前記ユーザ端末を介して、前記3rdパーティによる承認待ちであることを通知するとともに、
前記3rdパーティに対して、前記ユーザから購入要求された前記3rdアプリの前記ユーザへの販売を承認するか否か判定する顧客チェック要求を前記3rdパーティの連絡先に通知することで、前記3rdパーティによる前記3rdアプリの販売の承認を得る販売承認処理部と、
を備える、
海外対応アプリケーション販売管理サーバシステム。
前記第3の国は、日本を除いたホワイト国であり、前記3rdパーティの居住国は、日本又は前記第3の国を除くホワイト国である、請求項1から請求項6のいずれか1項に記載の海外対応アプリケーション販売管理サーバシステム。
前記管理制御部は、日本に設置されるハードウェア資源に設けられた前記第3の国に対応する専用領域に設ける、請求項1から請求項7のいずれか1項に記載の海外対応アプリケーション販売管理サーバシステム。
【発明を実施するための形態】
【0012】
本実施形態において、それぞれの国又は国家間の共同体(地域共同体)の輸出管理法令が適用されるエリアをリージョン(Region)ともいう。例えば、日本は、日本の輸出管理法令が適用される日本や米国の輸出管理法令が適用される米国はそれぞれ1つのリージョンである。
ここで、日本をリージョン0(ゼロ)として、n(n≧1)を海外の各リージョンを示す添え字とすると、後述するように、第3の国としてのリージョンn(n≧1)毎に、海外対応アプリケーション販売管理システムとしてのアプリケーション販売管理システム1000−n(以下「販売管理システム1000−n」ともいう)を設けることができる。以下、特に断らない限り、n≧1とする。
例えば、日本国内に設けられるアプリケーション販売管理システム1000(日本)、米国内に設けられるアプリケーション販売管理システム1000(米国)等が、挙げられる。
【0013】
図1は、本実施形態における海外のリージョンn(n≧1)に対応して設けられるアプリケーション販売管理システム1000−nの基本的構成を示す概略図である。
図1に示すように、アプリケーション販売管理システム1000−nは、海外対応アプリケーション販売管理サーバシステムとしてのアプリケーション販売管理サーバシステム10−n(以下「販売管理サーバシステム10−n」ともいう)と、販売登録制御部としてのストア登録サーバ300と、エッジサーバ400−nと、エッジ機器500−nと、端末600−n(ユーザ端末)とを含む。販売管理サーバシステム10−n、ストア登録サーバ300、エッジ機器500−n、及び端末600−nは、ネットワークN1−nで通信可能に接続される。ネットワークN1−nは、例えば、インターネットや、VPN(Virtual Private Network)、公衆電話網等である。ネットワークN1における具体的な通信方式や、有線接続及び無線接続のいずれであるか等については、特に限定されない。
また、リージョンnには、販売管理サーバシステム10−nを運営管理する1つの運営管理企業2−nが予め設定されている。通常、運営管理企業2−nは、リージョンnに居住する(以下「属する」ともいう)企業(例えば、法人)である。
【0014】
販売管理サーバシステム10−n及びストア登録サーバ300は、リージョンnに対応する、それぞれ独立した専用サーバシステムである。ここで、専用サーバシステムは、必ずしも物理的に独立したサーバ装置に限られない。例えば、リージョンnに対応する専用の領域が確保された、所定のサーバ又は所定のクラウド等に含まれる独立した仮想サーバであってもよい。その場合、リージョンnに対応する当該専用領域に確保される販売管理サーバシステム10−n及びストア登録サーバ300の管理・運用は、運営管理企業2−nにより行われる。
【0015】
販売管理サーバシステム10−nは、例えば、
図1に示すように、管理制御部としての管理サーバ100−nと、配信制御部としての配信サーバ200−nと、アプリDBとしてのアプリケーションDB(「アプリDB」ともいう)250−nによって構成されている。
ここで、管理サーバ100−nは、物理的に、必ずしもリージョンn内に設置する必要はなく、リージョンn以外のリージョン(例えば日本等)内に設置してもよい。これに対して、少なくとも、ストア販売可能な状態(「ストア販売登録」又は「ストア登録」ともいう)とされたアプリケーションの格納されている、配信サーバ200−n及び又は後述するアプリDB250−nは、リージョンn内に設置することが好ましい。サーバ等の配置については、後述する。
【0016】
ストア登録サーバ300−nは、アプリ開発者が開発したアプリケーションが所定の条件を満たす場合に、販売管理サーバシステム10−nにおいてストア販売可能とするためのストア販売登録するサーバである。ストア登録サーバ300の詳細については後述する。
【0017】
エッジサーバ400−nは、リージョンn内に設置される(以下「リージョンnに属する」ともいう)ものに限定される。より具体的には、販売管理サーバシステム10−nとネットワークN1−nを介して通信可能に接続されるエッジサーバnは、リージョンnに属するものに限られる。リージョンn以外の他のリージョンm(m≠n)に属するエッジサーバ400−mは、販売管理サーバシステム10−nと通信することはできない。より具体的には、リージョンn以外の他のリージョンm(m≠n)に属するエッジサーバ400−mは、販売管理サーバシステム10−nから、サーバアプリケーションを購入することはできない。
ここで、エッジサーバ400−n上で稼働するサーバアプリケーションとしては、例えば、後述するエッジ機器500−nに係る動作状態を示すデータ、生産状況を示すデータ、生産物の品質状況を示すデータ、稼働状況を示すデータ等を収集し、情報処理をするもの等が一例として挙げられるが、これに限定されるものではない。また、以下の説明において、アプリケーション販売管理システム1000−nで販売管理するサーバアプリケーションを、単にアプリケーション又はアプリともいう。
このように、エッジサーバ400−nは、販売管理サーバシステム10−nから購入したアプリケーションを実行させることにより、1台以上のエッジ機器500−nから、例えば、当該エッジ機器500−nに係る動作状態を示すデータ、生産状況を示すデータ、生産物の品質状況を示すデータ、稼働状況を示すデータ等を収集し、当該アプリケーションに係る所定の情報処理をするサーバであるともいえる。
【0018】
エッジ機器500−nとは、リージョンn内の例えば工場等の製造現場に設置された、CNC工作機械、産業機器、産業用ロボット等を含む製造装置、及び画像センサ、PLC(programmable logic controller)等の製造装置に付帯する機器を指す。例えば、1台以上のエッジ機器500−nは、例えば、工場のラインやセルを構成する。
そうすると、エッジ機器500−nは、エッジサーバ400−nに対するクライアントの機能を有するとも言える。エッジサーバ400−nと、1台以上のエッジ機器500−nとは、例えば、ユーザ3−nの工場施設等に設置され、LAN(Local Area Network)等のネットワークを介して通信可能に接続されている。
【0019】
販売管理サーバシステム10−nは、エッジサーバ400−nで稼働するサーバアプリケーションの購入を希望する、リージョンnに属するユーザ3−nに対して販売管理処理を実行することを支援するためのオンラインストアシステムである。
後述するように、ユーザ3−nは、例えば端末600−nを介して、管理サーバ100−nに対して、希望するサーバアプリケーションの購入要求をすることで、所定の条件を満たした場合に管理サーバ100−nから当該サーバアプリケーションに係るシリアル番号を取得することができる。そうすることで、ユーザ3−nは、シリアル番号に基づいて、配信サーバ200−nに対して、当該サーバアプリケーションをエッジサーバ400−nに配信(インストール)させることができる。
【0020】
端末600−nは、例えば、パーソナルコンピュータ(PC)である。端末600−nは、管理サーバ100−nと通信可能に接続され、例えば、エッジサーバ400−nで稼働するサーバアプリケーションの購入を希望する、リージョンnに属するエンドユーザ等により使用される端末である。ここで、ユーザ3−nが使用する端末600−nは、工場施設内に有していても、工場施設外に有していてもよいが、リージョンnに属するものとする。そして、ユーザ3−nは、端末600−nを介して、販売管理サーバシステム10−nにアクセスし、当該ユーザ3−nの購入することが可能なアプリケーションの内容を閲覧することができる。また、ユーザ3−nは、端末600−nを介してアプリケーションを発注することができる。
なお、予め設定された条件(資格等)を満たすユーザ3−nに対してのみ、販売管理サーバシステム10−nに対してアクセスをするためのユーザID(IDentification)が与えられる。詳細については、後述する。
【0021】
[リージョンnに属する販売管理サーバシステム10−nの構成]
次に、リージョンnに対応して設けられる(「リージョンnに属する」ともいう)販売管理サーバシステム10−nの構成について説明する。本実施例で説明する販売管理サーバシステム10−nは、リージョンnに属するアプリケーション開発者(以下「アプリ開発者」ともいう)が開発したアプリを当該リージョンnに属するユーザ3−nにストア販売するのみならず、当該リージョンn以外の日本を含むリージョンm(m≧0かつm≠n)に属するアプリ開発者の開発したアプリを、販売管理サーバシステム10−nを介して販売する(輸出する)構成を含む。
簡単のために、以下、nを省略して説明する。したがって、以下に説明するリージョンは、特に断らない限り、日本以外の海外のリージョンn(n≧1)(例えば、米国等の外国)を意味する。すなわち、販売管理サーバシステム10(管理サーバ100、配信サーバ200、及びアプリDB250)は、当該リージョンn(例えば、米国等の外国)に対応して設けられる。なお、特に断らない限り、ストア登録サーバ300は、当該リージョン(例えば、米国等の外国)に対応して設けられる。また、特に断らない限り、エッジサーバ400、エッジ機器500、端末600、及びユーザ3は、それぞれ、日本以外の海外の所定のリージョンn(n≧1)(例えば、米国等の外国)に属するものを意味する。
また、当該リージョン以外のリージョンとして、特に断らない限り、リージョン0(ゼロ)すなわち、日本を例として説明する。すなわち、以下の説明では、特に断らない限り、日本に属する(居住する)アプリ開発者の開発したサーバアプリケーションを、日本以外のリージョンn(例えば、米国等の外国)に属する販売管理サーバシステム10−nを介して当該リージョンnに属するユーザ3−nに対して販売する(輸出する)場合の構成を例示する。
しかしながら、本実施例は、日本及び日本以外のリージョンn(例えば、米国等の外国)に限られない。前述したように、リージョンnに属するアプリ開発者が開発したアプリを当該リージョンnに属するユーザ3−nにストア販売するのみならず、当該リージョンn以外のリージョンm(m≠n)に属するアプリ開発者の開発したアプリを、販売管理サーバシステム10−nを介して販売する(輸出する)場合に適用することができる。
【0022】
次に、販売管理サーバシステム10に含まれる機能について説明する。
図2A及び
図2Bは、それぞれ、本実施形態における販売管理サーバシステム10に含まれる管理サーバ100、及び配信サーバ200の機能ブロック図である。なお、これらのサーバにおけるユーザインタフェース(UIF)及び電子メール等は、対応するリージョンに関わらず、表示言語を切り替えて表示可能とする。具体的には、例えばリージョン毎にデフォルトロケールを設定するものとする。例えば、リージョンnに属するユーザ、アプリ開発者、運営管理企業(管理者、担当者)等に対して提供されるUI及び電子メール等は、リージョンnにおける表示言語により提供することができる。また、リージョンn以外の国(例えば日本)のアプリ開発者(「3rdパーティ」ともいう)等に提供されるUI及び電子メール等は、当該リージョン(例えば日本)における表示言語により提供することができる。なお、以下に例として示すUI等は、仮に日本語で記載しているが、リージョンnにおいては、デフォルトとして、リージョンnにおける表示言語で表示される。
図2Aに示すように、管理サーバ100は、制御部110と、記憶部120と、通信部130とを備える。同様に、
図2Bに示すように配信サーバ200は、制御部210と、記憶部220と、通信部230とを備える。
制御部110及び制御部210は、CPUであってよく、それぞれ記憶部120及び記憶部220に記憶された各種プログラムを実行することにより、それぞれ管理サーバ100及び配信サーバ200を統括制御する。
通信部130及び通信部230は、ネットワークを介して外部機器(例えば、エッジサーバ400、端末600等)とデータの送受信を行う通信制御デバイスである。
【0023】
管理サーバ100において、制御部110は、記憶部120に記憶されたプログラムに基づく機能部として、閲覧情報提供部111と、発注処理部112と、販売承認処理部113と、配信管理処理部114と、契約更新処理部115と、を備える。記憶部120は、制御部110により実行されるプログラムの他、アプリ管理情報記憶部121と、ユーザ記憶部122と、配信管理記憶部124と、アプリ開発者情報記憶部125と、受注状況管理情報記憶部126と、を備える。
また、配信サーバ200において、制御部210は、記憶部220に記憶されたプログラムに基づく機能部として、配信処理部214を備える。記憶部220は、制御部210により実行されるプログラムの他、配信データ記憶部224を備える。
制御部110及び制御部210の各機能部の説明の前に、まず、記憶部120、記憶部220、及びアプリDB250について説明する。
図2Cは、本実施形態における管理サーバ100の記憶部120の一例を示す図である。
図2Dは、本実施形態における配信サーバ200の記憶部220の一例を示す図である。また、
図2Eは、アプリDB250の一例を示す図である。
【0024】
<アプリ管理情報記憶部121>
図2Cに示すように、アプリ管理情報記憶部121は、当該リージョン内において購入可能なアプリに関する管理情報(メタデータ)を記憶する記憶領域である。本実施形態では、アプリ管理情報記憶部121には、アプリケーションプログラムそのものは格納されず、後述するアプリDB250に格納されているものとする。
図2Cに示すように、アプリ管理情報記憶部121は、アプリIDに対応付けて、一例として、アプリケーション名(及び/又は商品名)、対象機種情報と、入力情報、アプリケーションの説明文、価格情報、アプリ開発者情報(アプリ開発者IDを含む)、ストア販売が可能か、対面販売が必要か、を示す販売形態情報、ストア販売に際して当該アプリ開発者による顧客チェックを必要とするか否かを示す顧客チェック有無情報等のデータを記憶することができる。なお、アプリ管理情報記憶部121に記憶されるデータは、これに限られない。例示したデータ項目の一部と他のデータ項目を記憶するようにしてもよい。
【0025】
アプリIDは、アプリケーションを識別するための識別情報である。
対象機種情報は、当該アプリケーションの入出力対象となるエッジ機器500の機種情報であり、例えば、CNC工作機械、産業機器、産業用ロボット等の機種名である。
入力情報は、エッジ機器500から入力する入力データ情報等を含むエッジ機器情報である。
アプリケーションの説明文には、アプリケーションの仕様に関する説明として、ライセンスに関する説明が含まれる。ライセンスに関する説明としては、例えば、そのアプリケーションを使用するエッジ機器500を指定するものであるか否かといった、エッジ機器500の指定有無、同時に使用するエッジ機器500の台数分の購入が必要であるか、又は台数に制限がない、といった同時使用台数に関すること等を含む。また、アプリケーションの使用に関して、契約更新の有無に関する説明をも含む。
価格情報は、アプリケーションの販売価格に関する情報である。
アプリ開発者情報は、当該アプリケーションの開発者に係る情報であって、例えば、アプリ開発者ID、所属する国籍(又はリージョンID)等を含むようにしてもよい。
販売形態情報は、当該アプリケーションがストア販売可能か、又は対面販売が必要か、を示す情報である。ここで、対面販売とは、当該アプリケーションを、購入を希望するユーザに対して、ストア販売ではなく、アプリ開発者が当該ユーザに対して直接販売する方式を意味する。したがって、対面販売が必要とされるアプリは、後述する管理サーバ100から提供される発注画面を介して発注することはできない。
顧客チェック有無情報は、当該アプリのストア販売に際して当該アプリの開発者による顧客チェックを要するか否かを示す情報である。例えば、当該アプリの開発者が当該リージョン以外の、例えば輸出管理を厳格に実施しているホワイト国等(例えば、日本)に属し、当該アプリの販売が当該アプリの開発者にとって輸出行為に相当する場合に、その国(例えば日本)の輸出貿易管理令に基づく顧客チェックを要する。
ここで、当該リージョン以外のリージョン、例えば輸出管理を厳格に実施しているホワイト国等(例えば日本)から輸入される輸入アプリについて、簡単に説明する。
【0026】
<輸出貿易管理法令>
例えば日本で開発されたアプリを海外のリージョン(例えば、米国)で販売可能な状態にする(すなわち、例えば、アプリを当該リージョン内に設置されたアプリDB250に配信可能な状態に登録、すなわちストア販売登録することは、当該アプリを日本からリージョン(例えば、米国)に輸出する行為に該当する。
輸出管理を厳格に実施している日本においては、武器の開発につながる輸出を「輸出貿易管理令」で規制している。例えば、リージョン(例えば、米国)内で販売対象となる、エッジサーバ400で稼働するサーバアプリケーションは、工作機械の稼働等に関連するアプリであり、武器の開発につながる可能性があるとも考えられる。このため、アプリをリージョン(例えば、米国)で販売可能な状態にする(例えば、アプリを当該リージョン内に設置されたアプリDB250に配信可能な状態に登録、すなわちストア販売登録する)ためには、当該アプリを製造した者、すなわち、当該アプリの開発者は、当該アプリを当該リージョンに輸出する場合に、輸出貿易管理令に該当するか否かを判断(該非判定)する必要がある。このため、当該アプリを製造した者、すなわち、当該アプリの開発者は、「該非判定書」を作成する必要がある。
次に、当該アプリの開発者により該非判定書が作成された後、当該アプリを当該リージョンに輸出する者、例えば、開発者自らが輸出する場合や当該アプリを開発者から仕入れて輸出する者等は、該非判定書を入手して、その内容を確認した上で、例えば、経済産業大臣に対して、輸出貿易管理上の許可を得る必要がある。
なお、当該アプリが「非該当」と判定されている場合、特に経済産業大臣に対して、輸出貿易管理上の許可を得る必要はない。
当該アプリが「該当」と判定されている場合には、当該リージョンがホワイト国の場合には、包括許可(例えば特別一般包括許可)を得ることができる。また、当該リージョンが非ホワイト国の場合には、当該アプリの在庫販売に該当するストア販売は許可されず、当該アプリを販売するためには、対面販売(すなわち、その都度、当該アプリの輸出許可を得ること)が必要となる。
輸出貿易管理令に係る手続きについては、当業者にとって公知であり、詳細な説明は省略する。
【0027】
以上の手続きを経由した後、例えば日本で開発されたアプリを海外のリージョン(例えば、米国)でストア販売登録する(すなわち、アプリを当該リージョン内に設置されたアプリDB250に配信可能な状態に登録する)ための手続きを始めることができる。
具体的には、当該アプリの輸出者は、当該アプリを当該リージョンにおける販売管理サーバシステム10を運営する(当該リージョンに属する)運営管理企業2に対して、当該アプリの登録申請を行うことができる。
なお、当該アプリの輸出者により開発された(例えば日本で開発された)アプリを海外のリージョン(例えば、米国)でストア販売登録する(すなわち、アプリを当該リージョン内に設置されたアプリDB250に配信可能な状態にする)ための一実施例であるストア登録サーバ300の処理については、後述する。
【0028】
<顧客チェック>
アプリの輸出者(例えば、アプリ開発者)は、例えば日本で開発されたアプリを海外のリージョン(例えば、米国)でストア販売登録した後においても、当該アプリの受注が発生する毎に、個別に受注先が懸念顧客でないか、を確認する必要がある。
具体的には、例えば、日本で開発されたアプリをリージョン(例えば、米国)でストア販売登録した(すなわち、アプリを当該リージョン内に設置された配信サーバ200に配信可能な状態に登録した)後に、リージョン(例えば、米国)に属する顧客から、当該アプリの購入要求があった場合、輸出者(例えば、アプリ開発者)は、当該顧客が例えば、大量破壊兵器等の開発等を行う(行っていた)か否か、又は外国ユーザーリスト掲載の企業・組織か否か、を個別にチェックする必要がある。ここで、外国ユーザーリストとは、経済産業省が輸出貿易管理令に基づいて作成する、輸出された貨物や技術が大量破壊兵器、生物兵器、化学兵器、輸送用ミサイル等の開発、製造等に使われる懸念がある外国の企業名、組織名を列記した表を意味する。
顧客チェックの結果、当該顧客が懸念顧客に該当する場合、当該アプリを販売しないようにすることが求められる。
当該アプリの輸出者(例えば、アプリ開発者)が、当該アプリの受注が発生する度に、顧客チェックを行う際の販売管理サーバシステム10(管理サーバ100及び配信サーバ200)の処理内容の詳細については、後述する。
【0029】
<ユーザ記憶部122>
ユーザ記憶部122は、販売管理サーバシステム10と通信可能に接続されるエッジサーバ400が設置されたユーザ3に関する情報を記憶する記憶領域である。なお、エッジサーバ400を設置するためには、当該ユーザ3は、予め設定される所定の条件(資格等)を満たすことが前提である。エッジサーバ400が設置されたユーザ3は、販売管理サーバシステム10に対してアクセスが許可されるユーザである。すなわち、販売管理サーバシステム10にアクセスをするためのユーザIDが付与される。なお、ユーザ3として、エンドユーザ以外に、システムインテグレータ及び工作機械メーカ等の専門業者を含む中間業者を含んでもよい。
【0030】
図2Cに示すように、ユーザ記憶部122は、ユーザIDに対応付けて、ユーザ名、ユーザ情報、エッジサーバ情報等を記憶している。
ユーザIDは、ユーザを識別するための識別情報である。
ユーザ情報は、一例として、当該ユーザの名称、代表者名、住所、電話番号、メールアドレス、URL、ユーザレベル、発注権限等、当該ユーザに関する情報を含むようにしてもよい。ユーザ情報は、これらに限られない。例示したデータ項目の一部と他のデータ項目を含むようにしてもよい。なお、これらのユーザ情報は、例えば当該ユーザに対して初めてエッジサーバを設置する際に生成され、その後、例えば当該ユーザ情報の変更に係る事態(例えば、エッジサーバの増設等)が発生する度に、更新されるようにしてもよい。
ここで、ユーザレベルは、そのユーザの属性によって決められる。本実施形態では、ユーザレベルには、ユーザレベル1(「ch1」ともいう)からユーザレベル3(「ch3」ともいう)までの3段階があるものとして説明する。より具体的には、エンドユーザであることを示すユーザレベル1(ch1)、例えば、販売店、システムインテグレータ等を含む専門業者(中間業者)であることを示すユーザレベル2(ch2)、及び、例えば、工作機械メーカ、設備メーカ等を含む専門業者(中間業者)であることを示すユーザレベル3(ch3)が例示される。以下の説明において、ユーザレベル2を下位中間業者、ユーザレベル3を上位中間業者ともいう。
また、発注権限は、ユーザIDによって識別されるユーザ(専門業者(中間業者)又はエンドユーザ)が販売管理サーバシステム10に対して、アプリケーションの購入要求を直接行うことが許可されているか否かを識別するための情報である。ユーザが発注権限を有する場合にのみ、そのユーザは、販売管理サーバシステム10に対して、アプリケーションの購入要求を直接行うことができる。
【0031】
エッジサーバ情報とは、特にユーザがエンドユーザの場合に、当該ユーザに係る工場又は製造現場等に設置されているエッジサーバ400に関する情報であって、アプリケーションの配信先となるエッジサーバ400を特定する情報である。前述したように、エッジサーバ400は、当該アプリケーション販売管理システム1000の提供されるリージョン内に設置されている。エッジサーバ情報は、一例として、エッジサーバ400を識別するエッジサーバID、当該エッジサーバの設置場所、及び当該エッジサーバ400のIPアドレス等の通信ネットワーク上のアドレス情報等を含むようにしてもよい。なお、エッジサーバIDは、当該ユーザに係る例えば工場等において、1つ以上のエッジサーバ400を有する場合に、各エッジサーバ400を識別するために必要となる。
また、エッジサーバ情報として、当該エッジサーバ400との間で入出力を行う可能性のある当該エッジサーバ400のクライアント候補となるエッジ機器500に関する情報を含むようにしてもよい。エッジ機器500に関する情報としては、エッジ機器500を識別するエッジ機器ID、エッジ機器500の機種名、エッジ機器500の通信ネットワーク上のアドレス(例えばIPアドレス)等を含んでもよい。
なお、エッジサーバ情報は、これらに限られない。例示したデータ項目の一部と他のデータ項目を含むようにしてもよい。
【0032】
<配信管理記憶部124>
管理サーバ100における記憶部120に含まれる配信管理記憶部124は、任意のエッジサーバ400に対して配信されたアプリケーション(又は対面販売されたアプリケーション)に関する配信管理情報を配信先のエッジサーバ400に対応付けて記憶する記憶領域である。
図2Cに示すように、配信管理記憶部124は、配信されたアプリケーション情報と配信先のエッジサーバ400とを紐付けて記憶する。配信管理記憶部124は、例えば、配信先のエッジサーバ400を識別するエッジサーバID及び配信されたアプリケーションを識別するアプリIDをそれぞれ検索キーとするとともに、配信先のエッジサーバ400のエッジサーバIDと、配信されたアプリケーションのアプリIDとを含むデータを検索キー(複合キー)とする配信管理レコードを記憶する。配信管理レコードには、一例として、上記検索キーの他、配信されたアプリケーションの商品名、受注番号、受注日時、シリアル番号(ライセンスキー)、ライセンス、購入日(ライセンス取得日)、配信日等を記憶する。なお、図示しないが、次回契約更新日、次回契約更新通知日、次回契約更新通知先アドレス、通知済フラグ等、配信されたアプリケーションを管理するためのデータを記憶するようにしてもよい。なお、配信管理レコードに含むデータはこれらに限られない。例示したデータ項目の一部と他のデータ項目を含むようにしてもよい。
【0033】
受注番号とは、例えば、当該ユーザ3からの当該アプリを購入要求を受けてから、当該アプリを配信するまでの処理状況(処理状態)を管理するための番号である。
受注日時とは、当該ユーザ3からの当該アプリを購入要求を受信した日時である。
シリアル番号(ライセンスキー)は、購入をしたアプリケーションに対応するシリアル番号である。
ライセンスは、当該エッジサーバ400に配信した当該アプリケーションのライセンスに関して、例えば、当該アプリケーションとの接続及び/又は入出力が許可されるエッジ機器500に関する情報である。
購入日は、当該アプリケーションのシリアル番号を通知した日(すなわち、ユーザがライセンスを取得した日)である。
配信日は、当該アプリケーションを当該エッジサーバ400に配信した日である。
次回契約更新日は、現在のライセンス契約を引き続き継続契約する場合の次回の契約予定日である。
次回契約更新通知日は、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザに対して現在のライセンス契約を引き続き継続契約するか否かの確認通知を行う候補日である。
次回契約更新通知先アドレスは、例えば当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザの端末600のアドレス及び/又は当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザの電子メールアドレスである。
通知済フラグは、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザに対して現在のライセンス契約を引き続き継続契約するか否かの確認通知をしたか否かを示すフラグであり、通知をした場合に通知済みであることを示すためにフラグを、例えばオンにする。
こうすることで、配信されたアプリケーション毎に、当該アプリケーションがどのエッジサーバ400に、いつ購入要求を受けたか、いつ配信されているか、また、エッジサーバ400において、当該アプリケーションがいつ契約更新日となるか、といった情報を簡単に検索することができる。
【0034】
<アプリ開発者情報記憶部125>
アプリ開発者情報記憶部125は、アプリ開発者IDに対応付けて、アプリ開発者名、国籍(リージョン名)、住所、URL、連絡先メールアドレス等を含むアプリ開発者情報を記憶する。なお、アプリ開発者情報を、アプリ管理情報記憶部121に含まれるアプリ開発者情報として管理してもよい。
【0035】
<受注状況管理情報記憶部126>
受注状況管理情報記憶部126は、ユーザ3からアプリの購入要求を受けた場合に、当該アプリの購入要求を受けてからの当該購入要求に関する処理状況、及び処理結果を管理するための受注状況管理情報を記憶する。
受注状況管理情報は、受注番号に対応付けて、例えば、受注日時、受注したアプリID、アプリ名称(商品名)、受注先(すなわち、当該アプリを注文した者)のユーザID、承認ステータス、配信ステータス、アプリ開発者ID等を含むようにしてもよい。ここで、承認ステータス、アプリ開発者IDについては、当該アプリの販売に際して、アプリ開発者による顧客チェックが必要な場合に生成される。
承認ステータスは、当該アプリ開発者が販売管理サーバシステム10の属するリージョン以外のリージョン(例えば日本)に属している場合であって、当該アプリの受注先が、当該アプリを販売するに際して懸念顧客か否かの顧客チェック状況を管理するための管理情報である。ここで、承認ステータスは、例えば、承認不要(顧客チェックの不要なもの)、未承認(すなわち、顧客チェック中の状態)、承認済み(顧客チェックの結果、懸念顧客でないと判定された状態)、拒否済み(顧客チェックの結果、懸念顧客と判定された状態)等を含むことができる。
なお、承認不要、及び承認済みの場合、後述するように発注処理部112は、当該ユーザ3に対して購入完了手続き可能となった旨を例えばメール等により通知することができる。また、拒否済みの場合、後述するように発注処理部112は、当該ユーザ3に対して購入不可となった旨を例えばメール等により通知することができる。
なお、受注状況管理情報を、当該アプリのアプリ開発者により顧客チェックが必要なものと、顧客チェックが不要なものと、識別できるように、例えば、識別フラグを設けたり、また受注番号の一部に識別するための符号を設けるようにしてもよい。そうすることで、アプリ開発者による顧客チェックが必要とされる(された)受注に関する受注状況履歴情報を容易に抽出することができる。
また、当該アプリのアプリ開発者が当該リージョンに属さない場合にのみ、受注状況管理情報を作成するようにしてもよい。なお、受注状況管理情報に含むデータはこれらに限られない。例示したデータ項目の一部と他のデータ項目を含むようにしてもよい。
【0036】
<配信データ記憶部224>
図2Dに示すように、配信サーバ200の記憶部220は配信データ記憶部224を備える。配信データ記憶部224は、ユーザから購入要求されたアプリを配信するために設けられる記憶部である。配信データ記憶部224は、配信されるアプリのシリアル番号(ライセンスキー)に対応付けて、配信するアプリID、商品名、アプリケーション、アクセス申告リスト、ライセンス、購入要求したユーザのユーザID、配信先のエッジサーバ400のIDとIPアドレス等の通信ネットワーク上のアドレス等を含むようにしてもよい。
なお、配信データ記憶部224は、アプリケーション本体を含まず、後述する配信処理部214により、アプリDB250から配信させるようにしてもよい。
【0037】
<アプリDB250>
図2Eは、アプリDB250の一例を示す図である。
図2Eに示すように、アプリDB250には、当該リージョン(例えば、米国)でストア販売登録されたアプリがアプリIDに対応付けて記憶される。具体的には、後述するアプリ登録部313により、アプリ開発者が開発したアプリであって、運営管理企業2において所定の条件を満たすことが認証されたアプリが、アクセス申告リストとともに登録される。なお、この他、アプリケーションの商品名、アプリケーションの説明文、アプリケーションのライセンスに関する説明文、及びアプリケーションのバージョン番号等、適宜登録してもよい。
なお、当該リージョン以外の国(例えば日本)のアプリ開発者(以下「3rdパーティ」ともいう)の開発したアプリ(以下「3rdアプリ」ともいう)をストア販売可能なアプリとして、アプリDB250に登録するためには、さらに、アプリ開発者が当該リージョン以外の国(例えば日本)の輸出管理法令の該非判定を実施して、該非判定書とともに、アプリ開発者の国籍、名前、輸出管理規定判定結果(済/不要)等を含む該非判定リストとともに登録される。
アプリDB250に記憶される3rdアプリは、基本的に、非該当と判定されたアプリ、及び該当と判定されたアプリはホワイト国向けで輸出許可貿易管理上の許可を得たアプリに限られる。したがって、該当と判定されたアプリは、非ホワイト国においてストア販売は不可であって、アプリDB250には登録できない。
アプリDB250は、配信サーバ200に含まれるようにしてもよい。例えば、記憶部220に含まれるようにしてもよい。また、配信サーバ200とは別にアプリDB250をDBサーバとしてもよい。
【0038】
なお、アプリDB250は、以下の理由から、当該リージョン内に設置することが好ましい。
3rdパーティの居住国を日本として、アプリがストア販売されるリージョンを米国とした例に基づいて説明するが、この組み合わせ以外の場合も同様である。
仮に、アプリDB250を日本国内に配置した場合、アプリDB250に記憶されたアプリケーションは、米国のユーザに配信される度に、輸出管理規定が適用されることになる。そうすると、3rdパーティは、アプリケーションが米国のユーザに配信される度に、常に該非判定及び該非判定が「該当」の場合に、経済産業大臣から輸出許可を得る手続きが必要となり、3rdパーティにとって非常に煩雑になる。
さらに、米国に居住するアプリ開発者が開発したアプリをアプリDB250に記憶させる場合に、米国から日本への輸出に該当し、逆にアプリDB250に記憶されたアプリを米国のユーザに配信する場合、日本から米国への輸出に該当することとなり、米国及び日本双方における輸出許可が必要となり、非常に煩雑な処理となる。これを避けるためには、米国法では、米国の開発者の開発したアプリをEndpoint暗号化することが必須となる。そうすると、Endpoint暗号化対応で相当の開発経費が必要となり、好ましくない。さらに、Endpoint暗号化対応することで、日本に設置したアプリDB250を介してのアプリの出し入れは、米国では輸出入に当たらないが、例えばホワイト国であるヨーロッパの国や韓国では、Endpoint暗号化した場合であっても、日本に設置したアプリDB250を介してのアプリの出し入れは、輸出入に該当すると判断される。このため、Endpoint暗号化対応は、米国以外の国には適用できない極めて例外的な解決策となり、合理的ではない。
これに対して、米国内にアプリDB250を設置する場合、米国内では、アプリDB250を介しての米国の開発者の開発したアプリの出し入れについて、輸出入の問題が発生しない。また、日本から輸出する場合においても、米国内に設置されたアプリDB250にストア販売可能な状態にするときにのみ、輸出管理規定が適用される(該非判定及び該当の場合には輸出許可が必要となる)こととなり、もっとも合理的で適切な運用となる。
以上の理由から、アプリDB250を日本以外の米国内に設置することが好ましい。本実施例では、少なくとも、アプリDB250を当該リージョン内に設置する構成を実施例として説明する。なお、配信サーバ200がアプリDB250を備える場合、配信サーバ200を当該リージョン内に設置する。また、アプリDB250を配信サーバ200と物理的に異なるDBサーバとする場合、当該DBサーバを当該リージョン内に設置する。
なお、管理サーバ100については、前述したように、例えば、当該リージョンに対応する専用の領域が確保された、所定のサーバ又は所定のクラウド等に含まれる独立した仮想サーバであって、リージョンnに対応する当該専用領域に確保される仮想サーバの管理・運用が、運営管理企業により行われるようにすることで、当該リージョン内のみならず、例えば日本に設置しても輸出入に係る問題は発生しない。
以上、本実施例における一例として、管理サーバ100の記憶部120、配信サーバ200の記憶部220、及びアプリDB250について説明した。
次に、管理サーバ100及び配信サーバ200におけるそれぞれの制御部110及び制御部210の備える各機能部について説明する。
【0039】
まず、アプリが、リージョン(例えば米国)に属するアプリ開発者により開発されたアプリであるか、又は当該リージョン外、例えば日本で開発されたアプリであるかに関わらず、アプリがリージョン(例えば、米国)でストア販売登録された後の、管理サーバ100及び配信サーバ200に係る機能について説明する。
図2Aに示したように、管理サーバ100は、閲覧情報提供部としての閲覧情報提供部111と、発注処理部としての発注処理部112と、販売承認処理部としての販売承認処理部113と、配信管理処理部としての配信管理処理部114と、契約更新処理部としての契約更新処理部115と、を備える。
また、
図2Bに示したように、配信サーバ200は、配信処理部としての配信処理部214を備える。
なお、ストア販売の対象でなく、対面販売の必要なアプリである場合には、後述するように閲覧情報提供部111において、その旨の情報を提供するようにしてもよい。
【0040】
<閲覧情報提供部111>
閲覧情報提供部111は、閲覧情報提供機能と、販売価格情報提供機能と、を有する。
より具体的には、閲覧情報提供部111は、端末600から受信した、ユーザ3からのアプリケーション情報(アプリケーション商品情報)に対する閲覧要求に対して、当該ユーザ3が閲覧可能なアプリケーション情報(アプリケーション商品情報)を提供する。
閲覧情報提供部111は、アプリ管理情報記憶部121を参照し、ログインしたユーザ全てに提供されるアプリケーション(一般向けアプリ171)に関するアプリケーション商品情報を抽出し、端末600に対して提供してもよい。
その際、閲覧情報提供部111は、アプリ管理情報記憶部121に記憶した顧客チェック有無情報を参照して、当該アプリケーションのストア販売に際して当該アプリ開発者による顧客チェックを必要とする場合には、その旨の情報を併せて提供する。
【0041】
[価格情報の閲覧]
さらに、閲覧情報提供部111は、端末600から受信した、ユーザ3からのアプリケーションの価格情報(アプリケーション販売価格情報)の問合せ又は閲覧に対して、当該ユーザ3に予め設定されたユーザレベルに対応する価格情報を提供するようにしてもよい。具体的には、エンドユーザには、エンドユーザ価格情報のみを提供し、専門業者(中間業者)等には、エンドユーザ価格情報及び専門業者(中間業者)向けの卸価格情報を提供する。このため、閲覧情報提供部111は、ユーザ記憶部122を参照し、受信した閲覧要求に含まれるユーザIDに対するユーザのユーザレベルを確認する。
そして、閲覧情報提供部111は、抽出したアプリケーション情報及びユーザのレベルに応じた当該アプリの価格情報を含む、閲覧用画面160を生成し、端末600に対して提供する。なお、閲覧情報提供部111は、複数のアプリケーションを抽出した場合、アプリケーション一覧画面を生成して、端末600に送信してもよい。そして、端末600から1つのアプリケーションに係る選択を受け付けた場合に、閲覧情報提供部111は、選択されたアプリケーションに関する情報をアプリ管理情報記憶部121から抽出し、閲覧用画面160を生成するようにしてもよい。
【0042】
図3は、本実施形態における端末に表示される閲覧用画面の例を示す図である。
図3に示すように、閲覧用画面160は、例えばアプリID161aと、アプリ商品名161bと、アプリ開発者162と、当該アプリケーションのストア販売に際して当該アプリ開発者による顧客チェックの必要の有無163と、アプリケーションの説明文165と、アプリケーションのライセンスに関する説明文166と、を含むようにしてもよい。そして、説明文166は、抽出した価格情報166aと、ライセンス数量166bと、ライセンス説明情報166cと、エッジサーバID指定部166dとを含み、これらをまとめてライセンスに関する情報として提供する。閲覧用画面160には、ライセンスに関する説明文166を含むので、各ユーザは、必要なライセンスに関する情報を確認することができる。
また、閲覧用画面160は、発注用画面を兼ねるようにしてもよい。その場合、発注が可能なように、ライセンス数量166b、及びエッジサーバID指定部166d等を表示するようにしてもよい。
なお、閲覧情報提供部111は、閲覧用画面160に、発注権限を有するユーザには、発注ができるように購入ボタン等を表示させてもよい。また、閲覧情報提供部111は、例えば、ユーザのアプリケーションの閲覧中に、ユーザにより購入候補とするアプリケーションが選択された場合、選択されたアプリケーションID等を一時的に記憶させる購入候補記憶部(いわゆる「カート」)(図示せず)に記憶させるようにしてもよい。そして、閲覧情報提供部111は、ユーザからの指定により、購入候補記憶部(カート)(図示せず)に記憶されたアプリケーションID(商品名)を発注するための購入ボタン等をアプリケーション毎に、又は一括して表示する閲覧用画面160を発注用画面として表示させてもよい。
なお、購入ボタン等を表示する場合には、アプリケーション毎に、当該アプリケーションのストア販売に際して当該アプリ開発者による顧客チェックの必要の有無を併せて表示することが好ましい。
【0043】
<発注処理部112>
発注処理部112は、顧客チェック機能と、配信許可通知機能と、発注画面出力機能と、を有する。
発注処理部112は、発注権限を有するユーザからアプリケーションの購入要求を端末600から受信したことに応答して、購入要求されたアプリ毎に受注番号を作成して、例えば、受注日時、受注したアプリID、アプリ名称(商品名)、受注先(すなわち、当該アプリを注文した者)のユーザID等を含む受注状況管理情報レコードを生成する。なお、購入要求されたアプリの料金の支払いについては公知の方法(例えば、クレジット、口座自動引き落とし等)により確認されるものとする。
発注処理部112は、当該受注案件が承認済み(又は承認不要)とされた場合、購入要求に対応したアプリケーションのシリアル番号(ライセンスキー)を生成するとともに、アプリIDと配信先となるエッジサーバ400のエッジサーバIDと、シリアル番号(ライセンスキー)を含む発注処理データを、後述する配信サーバ200の配信処理部214に引き継ぐものとする。
このため、発注処理部112は、購入要求されたアプリ毎に当該アプリのストア販売に際して当該3rdパーティ(アプリ開発者)による顧客チェックの必要の有無を判定する。購入要求されたアプリについて当該3rdパーティ(アプリ開発者)による顧客チェックが必要と判定した場合、アプリ開発者による承認待ちであることを端末600を介してユーザに対して通知する。
図4にアプリ開発者による承認待ちであることを表示する画面の一例を示す。
図4に示すように、ユーザに通知する文面の一例としては、「ご注文いただいた商品は、開発元企業の承認が必要です。購入いただいた商品を配信する際に必要となるシリアルコードは承認時に払い出されます。承認後、Eメールをお送りしますので、購入完了手続き(承認確認)を行ってください」が挙げられるが、これに限られない。承認待ちであること、購入完了でないこと、承認後の結果を後日連絡すること、及び承認後に購入完了手続き(承認確認)を行うことがわかる文言であればよい。そうすることで、発注処理部112は、当該アプリの受注状況管理情報を後述する販売承認処理部113に引き継ぐことができる。
【0044】
購入要求されたアプリのストア販売に際して顧客チェック不要と判定した場合、発注処理部112は、当該ユーザからの購入料金の支払いを確認したうえで、当該アプリケーションの配信先となるエッジサーバ400のエッジサーバIDと、クライアント対象となるエッジ機器500の台数等に応じて、購入を要求したアプリケーションのシリアル番号(ライセンスキー)を生成し、アプリIDと配信先となるエッジサーバ400のエッジサーバIDと、シリアル番号(ライセンスキー)を含む発注処理データを作成し、購入を要求したアプリケーションのシリアル番号(ライセンスキー)をユーザに対して通知するとともに、発注処理データを配信サーバ200(配信処理部214)に引き継ぐ。
なお、発注処理部112は、配信許可に係る情報として、例えば、アプリケーションのシリアル番号(ライセンスキー)を表示させる専用画面(図示せず)にログインするためのID及びパスワードを含む電子メールを、アプリケーションの購入要求をしたユーザに送信するようにしてもよい。そうすることで、ユーザが、専用画面を表示させた上で、電子メールに記載のID及びパスワードを使用してログインすると、発注処理部112は、シリアル番号(ライセンスキー)を、専用画面に表示させるようにしてもよい。それにより、発注権限を有するユーザの端末600を、第三者がなりすまして使用した場合であっても、第三者にシリアル番号を知られずに済み、セキュリティが向上した仕組みで運用できる。
【0045】
顧客チェックが必要と判定されて、後述する販売承認処理部113に引き継がれた受注案件が販売承認処理部113において3rdパーティ(アプリ開発者)により承認済とされて 、発注処理部112に引き継がれた場合について説明する。
発注処理部112は、上記と同様に、当該ユーザからの購入料金の支払いを確認したうえで、当該アプリケーションの配信先となるエッジサーバ400のエッジサーバIDと、クライアント対象となるエッジ機器500の台数等に応じて、購入を要求したアプリケーションのシリアル番号(ライセンスキー)を生成し、アプリIDと配信先となるエッジサーバ400のエッジサーバIDと、シリアル番号(ライセンスキー)を含む発注処理データを作成する。
具体的には、発注処理部112は、当該アプリを購入要求したユーザの連絡先(例えばメールアドレス)に対して、アプリ開発者による顧客チェックが完了(承認済み)したことを知らせるための電子メール(「承認メール」という)等を送信する。なお、電子メールは、PUSH型メールとすることが好ましい。そして、発注処理部112は、当該ユーザからの購入料金の支払いを確認したうえで、アプリケーションのシリアル番号(ライセンスキー)を生成し、アプリIDと配信先となるエッジサーバ400のエッジサーバIDと、シリアル番号(ライセンスキー)を含む発注処理データを作成し、配信サーバ200(配信処理部214)に引き継ぐ。
また、発注処理部112は、当該アプリの購入が承認済み(又は承認不要)である場合、上記と同様に、例えば、承認メールに、当該アプリケーションの購入完了手続きするための発注画面にログインするためのID及びパスワードをアプリケーションの購入要求をしたユーザに送信するようにしてもよい。そうすることで、ユーザが、専用画面を表示させた上で、電子メールに記載のID及びパスワードを使用してログインすると、発注処理部112は、シリアル番号(ライセンスキー)を、専用画面に表示させるようにしてもよい。
【0046】
また、顧客チェックが必要と判定されて販売承認処理部113に引き継がれた受注案件が販売承認処理部113においてアプリ開発者により拒否済みとされて 、発注処理部112に引き継がれた場合、発注処理部112は、購入要求したユーザの連絡先(例えばメールアドレス)に対して、当該アプリの購入が拒否済みとなり、購入手続きが終了されることを知らせるための電子メール(「拒否メール」という)等を送信する。これにより、当該受注案件に係る処理は終了する。
【0047】
<販売承認処理部113>
販売承認処理部113は、例えば、アプリ開発者に対して、承認ステータスの管理機能(承認処理状況の見える化)を提供する(承認処理状況の見える化)。
販売承認処理部113は、発注処理部112により作成された当該アプリの受注番号に対応付けて生成された受注状況管理情報に基づいて、アプリ開発者への商品受注履歴情報の提供及び商品販売承認管理のための管理用画面の提供等を実行する。
【0048】
販売承認処理部113は、発注処理部112から受注状況管理情報を引き継ぐと、3rdパーティ(アプリ開発者)の連絡先に対して、商品受注したこと、3rdパーティ(アプリ開発者)による承認が必要であることを知らせるための電子メール等を送信する。具体的には、販売承認処理部113は、引き継いだ受注状況管理情報に含まれるアプリ開発者IDに基づいて、アプリ開発者情報記憶部125を参照して、連絡先メールアドレス等を取得し、当該メールアドレス先に前述した電子メール等を送信するようにしてもよい。なお、電子メールは、PUSH型メールとすることが好ましい。なお、連絡先としては、アプリ開発者又はそのエージェントが予め登録されているものとする。
また、後述する受注状況管理画面を表示させるためのURL等を含む電子メールを送信するようにしてもよい。そうすることで、3rdパーティ(アプリ開発者)又はそのエージェントは、3rdパーティ(アプリ開発者)又はそのエージェントの備える端末(図示せず)を介して、当該URLを用いてアクセスすることで、(ユーザ認証を介して)、迅速に当該アプリ開発者の開発したアプリに関する受注状況管理画面を表示させることができる。
【0049】
販売承認処理部113は、3rdパーティ(アプリ開発者)又はそのエージェントからの要求に応じて、3rdパーティ(アプリ開発者)又はそのエージェントの備える端末(図示せず)に対して、商品受注確認用のユーザインタフェース(以下「受注状況管理画面」ともいう)を提供する。具体的には、販売承認処理部113は、受注状況管理情報記憶部126に記憶された受注状況管理情報に含まれるアプリ開発者IDに基づいて、当該アプリ開発者IDに係る受注状況管理情報を全て抽出し、例えば、受注日時順にソートすることで、アプリの受注状況をその履歴を含めて、例えばリスト形式で表示することができる。
図5Aに3rdパーティ(アプリ開発者)又はそのエージェントに対して提供される受注状況管理画面1130の一例を示す。
図5Aに示すように、3rdパーティ(アプリ開発者)又はそのエージェントに対して提供する受注状況管理画面1130は、当該アプリ開発者による顧客チェックの必要とされる(及び必要とされた)全てのアプリの受注状況をその履歴を含めて、例えばリスト形式で表示可能としてもよい。なお、1画面に全ての受注状況管理情報を表示できない場合、
図4に示すように、3rdパーティ(アプリ開発者)のユーザにより画面の順序番号が押下されることにより他の画面を表示することができる。なお、画面の順序番号の押下操作に換えて、スクロール可能に表示してもよい。
受注状況管理画面1130は、一例として、当該3rdパーティ(アプリ開発者)の受注番号1131、受注日時1132、商品名1133、受注先(注文企業コード)1134、承認ステータス欄1135、操作欄1136、及び受注状況管理情報を検索するための検索条件入力欄1137等を含むようにしてもよい。
【0050】
受注先(注文企業コード)欄1134には、企業情報表示ボタン1134aを表示してもよい。そうすることで、アプリ開発者により当該企業情報表示ボタン1134aが押下されることに応答して、販売承認処理部113は、ユーザ記憶部122に記憶された当該ユーザ(受注先)に関するユーザ情報1134bを提供するようにしてもよい。
図5Bにユーザ(受注先)に関するユーザ情報1134bをポップアップ画面により提示する一例を示す。
図5Bには、提示するユーザ情報1134bの一例として、企業コード1134b1、企業名1134b2、企業代表者1134b3、住所1134b4を表示する例を示すが、これに限られない。ユーザ情報1134bとして、任意の情報を表示するようにしてもよい。また、ユーザ情報として、当該ユーザの製造現場にエッジサーバを設置した際に、運営管理企業2により登録されたユーザ情報を提供するようにしてもよい。
【0051】
承認ステータス欄1135には、顧客チェック進捗状況に合わせて、3rdパーティ(アプリ開発者)により入力される状態である、未承認(顧客確認中)、承認済み(懸念顧客でないとの顧客確認済み)、拒否済み(懸念顧客であるとの顧客確認済み)、及び承認不要(顧客チェック不要)が、その顧客チェック進捗状況に合わせて、3rdパーティ(アプリ開発者)により入力される。
3rdパーティ(アプリ開発者)による入力操作を支援するために、当該受注案件の承認ステータスが未承認の場合に、操作欄1136に、承認ボタン1136a及び拒否ボタン1136bを表示するようにしてもよい。そうすることで、3rdパーティ(アプリ開発者)は、顧客チェック待ちの案件を容易に確認することができるとともに、承認又は拒否を操作欄1136に表示されたボタン操作(例えば押下操作、タップ操作等)により、簡単に顧客チェック結果を入力することができる。アプリ開発者により承認ボタン1136aが押下(又はタップ)されることで、後述するように、アプリ購入要求者は当該アプリ(商品)の購入手続きを完了することができ、当該アプリのシリアル番号を取得することができる。なお、承認不要の場合も、後述するように、アプリ購入要求者は当該アプリ(商品)の購入手続きを完了することができ、当該アプリのシリアル番号を取得することができる。
逆に、3rdパーティ(アプリ開発者)により拒否ボタン1136bが押下(又はタップ)されることで、アプリ購入要求者は懸念顧客と判定され、当該アプリ(商品)を購入できないことが決定し、購入手続きを終了する。
より具体的には、3rdパーティ(アプリ開発者)により承認ボタン1136aが押下(又はタップ)されると、販売承認処理部113は、当該受注状況管理情報の承認ステータス欄1135に「承認済み」を記録し、当該アプリの受注状況管理情報を発注処理部112に引き継ぐ。同様に、3rdパーティ(アプリ開発者)により拒否ボタン1136bが押下されると、販売承認処理部113は、当該受注状況管理情報の承認ステータス欄1135に「拒否済み」を記録し、当該アプリの受注状況管理情報を発注処理部112に引き継ぐ。
そうすることで、前述したように、発注処理部112は、当該受注番号に対応する発注処理を再開することが可能となる。
【0052】
なお、図示しないが、受注状況管理画面1130に配信ステータス欄を含めてもよい。配信ステータス欄には、配信進捗状況に合わせて例えば配信処理部214により入力される状態である。例えば、シリアル番号未送信、シリアル番号送信済み、未配信、配信済み等が、その配信進捗状況に合わせて、入力されるようにしてもよい。また、シリアル番号送信日、配信日を含むようにしてもよい。そうすることで、3rdパーティ(アプリ開発者)又はそのエージェントは、承認済み後の、配信状況を確認することができる。
【0053】
検索条件入力欄1137は、例えばタップ操作がされることにより、検索条件入力のためのポップアップ画面1137aを提供してもよい。
図5Cに検索条件入力欄の一例を示す。
図5Cに示すように、受注先(注文企業)の入力欄1137b、商品名の入力欄1137c、受注番号の入力欄1137d、受注日時の範囲の入力欄1137e、承認ステータスの入力欄1137f、及びこれらから複数の条件を(AND又はOR)組み合わせた複合検索等をするための画面を提供してもよい。なお、企業検索ボタン11371は、注文企業の入力欄で指定した企業を検索するためのボタンであり、検索ボタン11372は、複合検索するためのボタンである。
【0054】
なお、販売承認処理部113は、例えば、運営管理企業2の管理者に対して、運営管理端末(図示せず)を介して、受注状況管理情報記憶部126に記憶された受注状況管理情報を検索/照会する機能を提供するようにしてもよい。そうすることで、運営管理企業2の管理者においても、例えば、未承認の状態の受注案件を確認すること(見える化)ができる。
【0055】
<配信処理部214>
配信サーバ200の備える配信処理部214は、管理サーバ100(発注処理部112)から引き継いだ発注処理データに基づいて、対応するアプリをアプリDB250から抽出し、配信データを作成し、配信データ記憶部224に記憶する。ここで、配信データは、シリアル番号(ライセンスキー)に対応付けて、配信するアプリID,商品名、ライセンス、購入要求したユーザのユーザID、配信先のエッジサーバ400のIDとIPアドレス等の通信ネットワーク上のアドレス等を含む。
配信処理部214は、当該アプリを購入したユーザから端末600を介して、シリアル番号(ライセンスキー)とともにアプリケーションの配信要求を受信すると、当該シリアル番号(ライセンスキー)に基づいて、配信データ記憶部224を参照することで、配信するアプリID及び配信先のエッジサーバ400を特定し、当該アプリケーションをアプリDB250から配信先のエッジサーバ400に配信する。より具体的には、配信処理部214は、端末600から受信した、ユーザからのアプリケーションの配信要求に応答して、シリアル番号(ライセンスキー)から、配信するアプリケーションと、ライセンスと、当該アプリケーションを配信するエッジサーバ400と、を特定し、特定されたエッジサーバ400に対して、ライセンスと、シリアル番号(ライセンスキー)に対応付けられたアプリIDに基づいてアプリDB250から取得したアプリケーションと、を配信する。ここで、ライセンスとは、例えば、当該アプリケーションのクライアント(すなわち接続及び/又は入出力対象)となるエッジ機器500に関する使用許諾情報である。ライセンスは、アプリケーションに含んでエッジサーバ400に対して配信してもよい。また、ライセンスは、アプリケーションとは別にエッジサーバ400に対して配信してもよい。
このようにすることで、ユーザは、購入したアプリケーションを特定されたエッジサーバ400に対してダウンロードさせることができる。
このように、配信処理部214は、配信要求に含まれるシリアル番号(ライセンスキー)に基づいて、アプリケーション及びエッジサーバ400を特定するので、シリアル番号を知り得る特定のユーザのみが配信要求を行うことができる。つまり、第三者が配信要求を行っても、シリアル番号を知らないため、アプリケーションが配信されることがない。また、シリアル番号はアプリケーションの配信先となるエッジサーバ400を特定することからも、第三者がシリアル番号を知り得たとしても、アプリケーションを特定されるエッジサーバ400以外のサーバに配信させることはできない。
配信処理部214は、配信されたアプリケーション情報と配信先のエッジサーバ400に対応付けて、配信されたアプリケーションに関する配信管理情報を生成して、管理サーバ100(配信管理処理部114)に引き継ぐ。ここで、配信管理情報は、配信先のエッジサーバ400のエッジサーバIDと、配信されたアプリケーションのアプリIDとを含むデータを検索キー(複合キー)として、例えば、配信されたアプリケーションの商品名、受注番号、シリアル番号(ライセンスキー)、ライセンス、購入日(ライセンス取得日)、配信日を含む。
なお、配信処理部214は、例えば、運営管理企業2の管理者に対して、運用管理端末(図示せず)を介して、配信データ記憶部224に記憶された配信データを検索/照会する機能を提供するようにしてもよい。
【0056】
<配信管理処理部114>
配信管理処理部114は、アプリケーションの配信管理情報を管理する
配信管理処理部114は、配信処理部214から配信管理情報を引き継いで、配信されたアプリケーション情報と配信先のエッジサーバ400とを紐付けて記憶する。配信管理処理部114は、前述したように、例えば、配信先のエッジサーバ400を識別するエッジサーバID及び配信されたアプリケーションを識別するアプリIDをそれぞれ検索キーとするとともに、配信先のエッジサーバ400のエッジサーバIDと、配信されたアプリケーションのアプリIDとを含むデータを検索キー(複合キー)とする配信管理レコードを配信管理記憶部124に記憶する。
配信管理処理部114は、例えば、運営管理企業2の管理者等に対して、運用管理端末(図示せず)を介して、配信管理記憶部124に記憶された配信管理レコードを検索/照会する機能を提供する。こうすることで、配信されたアプリケーション毎に、当該アプリケーションがどのエッジサーバ400に配信されているか、また、エッジサーバ400において、当該アプリケーションがいつ契約更新日となるか、といった情報を簡単に検索することができる。
また、エッジサーバ400毎に、当該エッジサーバ400に配信されたアプリケーションのうち、どのアプリケーションがいつ契約更新日となるか、といった情報を簡単に検索することができる。さらに、アプリケーション毎及び/又はエッジサーバ400毎に、次回契約更新通知先アドレス(例えば端末600及び/又は電子メールアドレス等)に対して、次回契約更新日に先立つ次回契約更新通知日に、アプリケーションの契約更新の確認通知を行うことができる。
【0057】
<契約更新処理部115>
契約更新処理部115は、契約更新通知手段に対応する機能を有する。
契約更新処理部115は、配信管理記憶部124を参照し、エッジサーバ400にダウンロード済のアプリケーションの契約更新のための通知を、例えば、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザに対して行う。なお、契約更新処理部115が通知をする端末は、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザの有する端末600であってもよいし、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザが有する他の端末(例えば、携帯端末等)であってもよい。また、通知方法は、例えば、メニュー画面に表示してもよいし、電子メール等によって行ってもよい。
より具体的には、契約更新処理部115は、所定のタイミング(例えば、週に1回や月に1回等)で、配信管理記憶部124を参照し、次回契約更新通知日が到来し、かつ、通知済フラグによって通知していないエッジサーバ400のエッジサーバID及びアプリIDを抽出する。
契約更新処理部115は、当該アプリケーションの購入者及び/又は当該アプリケーションのライセンス先のユーザに対して、アプリIDに対応するアプリケーションの契約更新が必要な旨を通知する。
したがって、契約更新処理部115は、ユーザの契約更新洩れを防止し、ユーザに対して忘れずに更新を行わせることができる。
なお、ライセンス更新に際して、当該アプリのストア販売に際して当該アプリ開発者による顧客チェックが必要な場合、前述した発注時の処理と同様に、アプリ開発者による顧客チェック処理を行うようにしてもよい。
以上、アプリが、リージョン(例えば米国)に属するアプリ開発者により開発されたアプリであるか、又は当該リージョン外、例えば日本で開発されたアプリであるかに関わらず、アプリがリージョン(例えば、米国)でストア販売登録された後の、管理サーバ100及び配信サーバ200に係る機能について説明した。
【0058】
以上、アプリが、リージョン(例えば米国)に属するアプリ開発者により開発されたアプリであるか、又は当該リージョン外、例えば日本で開発されたアプリであるかに関わらず、アプリがリージョン(例えば、米国)でストア販売登録された後の、当該リージョンに対応する販売管理サーバシステム10に含まれる機能ブロックについて説明した。
【0059】
次に、販売管理サーバシステム10における処理フローについて説明する。
まず、アプリケーションの閲覧に係る処理フローについて説明する。
図6は、本実施形態における販売管理サーバシステム10の閲覧情報提供処理の一例を示すフローチャートである。
【0060】
アプリケーション情報を閲覧するため、各ユーザは、端末600を操作して、販売管理サーバシステム10に対してログインする。ここで、ログインについては、公知の手法を用いて行い、例えば、ユーザの個人情報や、ID、パスワード等を含むパスワード管理ファイル等を用いて、ユーザ認証を行い、正当なユーザであることを確認する。そして、ユーザは、端末600に表示された図示しないメニュー画面から、アプリケーションの閲覧を選択する。
ステップS10において、管理サーバ100(閲覧情報提供部111)は、端末600が送信した閲覧要求を受信する。
ステップS11において、管理サーバ100(閲覧情報提供部111)は、端末600に対してユーザ3が閲覧可能なアプリケーションの一覧画面を提供する。
ステップS12において、端末600から指定されたアプリケーション名(商品名)を受信する。
ステップS13において、管理サーバ100(閲覧情報提供部111)は、アプリ管理情報記憶部121を参照して、指定されたアプリケーション名に係るアプリケーション情報(アプリケーション商品情報)の表示画面を提供する。ここで、アプリケーション情報(アプリケーション商品情報)の表示画面には、価格情報、アプリ開発者による顧客チェックの必要の有無、購入ボタン等を表示させることができる。
ステップS14において、管理サーバ100(閲覧情報提供部111)は、端末600からユーザからの指示を受信する。
ステップS15において、管理サーバ100(閲覧情報提供部111)は、ユーザからの指示内容を判定する。購入ボタンが押下された場合、
図7に示すステップS20に移る。戻りの指示がなされた場合、ステップS10に戻る。終了の指示がなされた場合、閲覧情報提供処理を終了する。
【0061】
次に、アプリケーションの購入依頼に係る処理フローについて説明する。
図7は、本実施形態における販売管理サーバシステム10の顧客からの購入依頼に対する受注処理の一例を示すフローチャートである。
ステップS20において、管理サーバ100(発注処理部112)は、ユーザからの購入要求に基づいて、購入要求されたアプリの受注番号を生成して、受注状況管理情報レコードを作成する。
ステップS21において、管理サーバ100(発注処理部112)は、購入要求されたアプリのストア販売に際して3rdパーティ(アプリ開発者)による顧客チェックの必要の有無を判定する。必要な場合(YES)、ステップS22に移る。必要でない場合(NO)、ステップS23に移る。
【0062】
ステップS22において、管理サーバ100(発注処理部112)は、アプリ開発者による承認待ちであることを端末600を介してユーザに対して案内し、当該受注状況管理情報レコードとともに処理を販売承認処理部113(
図8に示すステップS30)に引き継ぐ。
【0063】
ステップS23において、管理サーバ100(発注処理部112)は、ユーザからの購入料金の支払い状況を確認する。支払いが確認された場合(YES)、ステップS24に移る。支払いが確認できない場合(NO)、当該受注状況管理情報レコードを料金待ちとして、ステップS23に戻る。
ステップS24において、管理サーバ100(発注処理部112)は、購入を要求したアプリケーションのシリアル番号(ライセンスキー)を生成し、アプリIDと配信先となるエッジサーバ400のエッジサーバIDと、シリアル番号(ライセンスキー)を含む発注処理データを作成する。
ステップS25において、管理サーバ100(発注処理部112)は、購入を要求したアプリケーションのシリアル番号(ライセンスキー)をユーザに対して通知して、当該発注処理データとともに処理を配信サーバ200(配信処理部214)に引き継ぎ、受注処理を終了する。
【0064】
次に、顧客チェックが必要と判定されて(
図7に記載のステップ22から)販売承認処理部113に引き継がれた受注案件の販売承認に係る処理フローについて説明する。
図8は、本実施形態における販売管理サーバシステム10の販売承認に係る処理の一例を示すフローチャートである。なお、以下の処理フローでは、企業情報表示ボタンの押下に応答したユーザ(受注先)に関する情報を提示する処理、及び検索条件入力に応答した照会処理については、省略している。
【0065】
ステップS30において、管理サーバ100(販売承認処理部113)は、3rdパーティ(アプリ開発者)の連絡先に対して、商品受注したこと、3rdパーティ(アプリ開発者)による顧客チェックが必要であることを知らせるための電子メール等を送信する。
【0066】
ステップS31において、管理サーバ100(販売承認処理部113)は、3rdパーティ(アプリ開発者)からの要求に応じて、3rdパーティ(アプリ開発者)又はそのエージェントの備える端末(図示せず)に対して、商品受注確認用のユーザインタフェース(受注状況管理画面)を提供する。
ステップS32において、管理サーバ100(販売承認処理部113)は、3rdパーティ(アプリ開発者)又はそのエージェントの備える端末(図示せず)からユーザインタフェース(受注状況管理画面)を介して、顧客チェック結果を取得する。
ステップS33において、管理サーバ100(販売承認処理部113)は、押下された操作ボタンに基づく顧客チェック結果の内容を判定する。拒否ボタンが押下された場合、ステップS34に移る。承認ボタンが押下された場合、ステップS35に移る。
ステップS34において、管理サーバ100(販売承認処理部113)は、アプリ購入要求者を懸念顧客として、当該受注状況管理情報の承認ステータス欄に「拒否」を記録し、当該アプリの受注状況管理情報を発注処理部112に引き継ぐ。具体的には、
図9に記載のステップS40に移る。なお、変形例として
図9に記載のステップS41に直接移るようにしてもよい。
【0067】
ステップS35において、管理サーバ100(販売承認処理部113)は、当該受注状況管理情報の承認ステータス欄に「承認済み」を記録し、当該アプリの受注状況管理情報を発注処理部112に引き継ぐ。具体的には、
図9に記載のステップS40に移る。なお、変形例として
図9に記載のステップS42に直接移るようにしてもよい。
【0068】
次に、アプリケーションの販売承認処理部113からの引継ぎ処理に係る処理フローについて説明する。
図9は、本実施形態における販売管理サーバシステム10の、後述する販売承認処理後の処理の一例を示すフローチャートである。
ステップS40において、管理サーバ100(発注処理部112)は、販売承認処理部113から、引き継いだ当該受注状況管理情報レコードの承認ステータス欄が「承認済み」か、又は「拒否」か、を判定する。「拒否」の場合ステップS41に移る。「承認済み」の場合、ステップS42に移る。
ステップS41において、管理サーバ100(発注処理部112)は、アプリ購入要求者を懸念顧客として、購入要求したユーザの連絡先(例えばメールアドレス)に対して、当該アプリの購入が拒否済みとなり、購入手続きが終了されることを知らせるための電子メール(「拒否メール」)等を送信する。管理サーバ100(発注処理部112)は、当該受注状況管理情報レコードを拒否済みとして、処理を終了する。これにより、当該受注案件に係る処理は終了する。
【0069】
ステップS42において、管理サーバ100(発注処理部112)は、当該アプリを購入要求したユーザの連絡先(例えばメールアドレス)に対して、アプリ開発者による顧客チェックが完了(承認済み)したことを知らせるための電子メール(「承認メール」という)等を送信する。
ステップS43において、管理サーバ100(発注処理部112)は、ユーザからの購入完了手続き要求を確認する。購入完了手続き要求があった場合、
図7に記載のステップS24に移る。
【0070】
次に、アプリケーションの配信に係る処理フローについて説明する。
図10は、本実施形態における販売管理サーバシステム10のアプリケーション配信処理の一例を示すフローチャートである。
アプリケーションの配信依頼をするため、例えば、ユーザは、端末600を操作して、端末600に表示された図示しないメニュー画面から、例えば、アプリケーションの配信を選択し、遷移した配信用画面(図示せず)にエッジサーバ400に配信するアプリケーションのシリアル番号を入力して、配信要求を販売管理サーバシステム10に対して送信する。
【0071】
ステップS50において、配信サーバ200(配信処理部214)は、端末600からアプリケーションの配信要求を受信する。
ステップS51において、配信サーバ200(配信処理部214)は、配信要求に含まれるシリアル番号に基づき、配信データ記憶部224を参照して、アプリケーション及びアプリケーションを配信するエッジサーバ400を特定する。
【0072】
ステップS52において、配信サーバ200(配信処理部214)は、特定されたエッジサーバ400に対して、特定されたアプリケーションを配信する。
ステップS53において、配信サーバ200(配信処理部214)は、エッジサーバ400へのアプリケーションの配信を完了したことに応じて、配信要求を送信した端末600に、配信完了の旨を送信する。その後、配信サーバ200(配信処理部214)は、本件の処理を終了する。
【0073】
以上により、アプリケーション販売管理システム1000において、エッジサーバ400で稼働させるアプリケーションを、販売管理サーバシステム10から購入してダウンロードすることができる。
その際、顧客から3rdアプリの購入要求があった場合に、当該顧客が懸念顧客でないことを当該アプリの開発者である3rdパーティは、速やかに顧客チェックを行うことができる。
以上、販売管理サーバシステム10における処理フローについて説明した。
【0074】
以上のように、本実施例で記載した、第3の国としての海外の国において運営するアプリケーションストアである海外対応アプリケーション販売管理サーバシステムとしての販売管理サーバシステム10によると、例えば日本又は前記海外の国以外の国で開発されたアプリケーションが、当該アプリケーションストアの運営管理者である運営管理企業2により現地ストア販売登録された後(具体的には例えば、アプリケーション販売管理システムの配信サーバに登録された後)に、顧客から当該アプリケーションの購入要求があった場合に、日本又は前記海外の国以外の国の当該アプリケーション開発者が速やかに顧客チェックを行うことができる。また、アプリを購入するユーザ(顧客)及び運営管理企業2の担当者も、ユーザによるアプリ購入要求後に3rdパーティによる顧客チェックが必要とされた場合において、3rdパーティによる顧客チェックの進捗状況及びその結果を把握することができ、全ての関係者に対して、顧客チェックの進捗状況の「見える化」を図ることができる。
【0075】
以上説明したように、本実施形態は、第3の国(例えば、米国)において提供されるアプリケーションストアである海外対応アプリケーション販売管理サーバシステム10において、管理サーバ100により、第3の国に居住する顧客であるユーザから購入要求されたアプリケーションが3rdパーティの開発した3rdアプリであると判定された場合、3rdパーティに対して、ユーザから購入要求された3rdアプリのユーザへの販売を承認するか否か判定する顧客チェック要求(懸念顧客か否かのチェック)を3rdパーティの連絡先に通知する。
これにより、3rdアプリの日本又は第3の国以外の国に居住するアプリケーション開発者である3rdパーティは、3rdアプリの受注を速やかに知ることができる。
また、管理サーバ100は、3rdパーティの連絡先の備える端末に対して、前記受注状況管理情報を提供することができる。
これにより、3rdパーティは、自身の責任で顧客チェック管理を容易に行うことができる。
【0076】
また、管理サーバ100は、第3の国に居住する顧客であるユーザから購入要求されたアプリケーションが3rdパーティの開発した3rdアプリであると判定した場合、ユーザに対してユーザ端末を介して、3rdパーティによる承認待ちであることを通知する。
管理サーバ100は、3rdパーティによる3rdアプリの販売の承認を得た場合、3rdアプリの販売が承認済みであることをユーザに通知する。
管理サーバ100は、3rdパーティにより当該ユーザに対して3rdアプリの販売が拒否された場合、3rdアプリの販売が拒否済みであることをユーザに通知する。
これにより、第3の国に居住する顧客であるユーザは、3rdパーティの開発した3rdアプリの購入要求後に、3rdパーティによる当該顧客チェック状況(承認待ち、承認済み、又は拒否済み)を容易に把握することができる。
【0077】
また、管理サーバ100は、さらに、3rdパーティによる3rdアプリの販売の承認を得た場合、3rdアプリの配信許可情報であるシリアル番号をユーザに対して発行し、配信サーバ200は、ユーザの備えるユーザ端末から、配信許可情報であるシリアル番号を受信したことに応じて、配信許可情報に対応付けられた3rdアプリを、ライセンスとともにエッジサーバに配信する。
これにより、3rdパーティの開発した3rdアプリは、懸念顧客に該当しない顧客エッジサーバに対して3rdアプリを速やかにインストールすることができる。
【0078】
また、第3の国においてオンラインストア販売登録される前記アプリケーションを記憶するアプリDBは、第3の国に設置されることが好ましい。これにより、第3の国に居住する開発者により開発されたアプリは、第3国内における移動にとどまり、輸出入管理の対象外であり、3rdパーティにより開発される3rdアプリのみが輸出入管理の対象となることで、輸出入に係る運用が容易になる。
これに対して、管理サーバ100は、後述するように、例えば、日本国内に物理的なハードウェア資源(例えば、サーバ又はクラウド)を設置し、ハードウェア資源をリージョンn(n≧1)毎に専用領域nを設けて、当該専用領域nには、リージョンnに対応する管理サーバ100−nを例えばIaaS(Infrastructure as a Service)として設定してもよい。そうすることで、インフラとしてのハードウェア資源の保守作業を一括して運用することができるとともに、保守費用等を削減することができる。詳細は、後述する。
また、第3の国は、日本を除いたホワイト国であり、前記3rdパーティの居住国は、日本又は第3の国以外のホワイト国としてもよい。これにより、ホワイト国における海外対応アプリケーション販売管理サーバシステム10を共通化することが可能となる。
【0079】
<ストア登録サーバ300>
次に、アプリケーション販売管理システム1000において、アプリケーションを当該販売管理サーバシステム10にストア販売登録するための一実施例であるストア登録制御部としてのストア登録サーバ300の機能について説明する。
具体的には、リージョン(例えば米国)に属するアプリ開発者又は3rdパーティが開発したアプリケーションをリージョン(例えば、米国)でストア販売登録する(すなわち、アプリを当該リージョン内に設置された配信サーバ200に配信可能な状態に登録する)際のアプリケーション販売管理システム1000の備える機能部(ストア登録サーバ300)について説明する。
【0080】
前述したように、3rdパーティが開発したアプリケーションを海外のリージョン(例えば米国)における販売管理サーバシステム10を介してストア販売するためには、3rdパーティは、当該アプリを当該リージョンに輸出する場合に、輸出貿易管理令に該当するか否かを判断(該非判定)する必要がある。このため、3rdパーティは、まず「該非判定書」を作成する必要がある。
【0081】
当該アプリが「非該当」と判定される場合、輸出貿易管理上の許可を得る必要はなく、3rdパーティは、該非判定書とともに3rdパーティ(アプリ開発者)の国籍、名前、輸出管理規定判定結果(この場合、「非該当」)等を含む輸出管理リストとともに、アプリケーションと、後述する当該アプリケーションに係るアクセス申告リストと、を運営管理企業2に対して提出することができる。
【0082】
当該アプリが「該当」と判定されている場合には、当該リージョン(すなわち、3rdパーティからの輸出先)がホワイト国(例えば米国)の場合には、輸出貿易管理者(例えば、経済産業大臣)に対して、輸出貿易管理上の許可(例えば特別一般包括許可)を得る必要がある。そうすることで、3rdパーティは、該非判定書とともに3rdパーティ(アプリ開発者)の国籍、名前、輸出管理規定判定結果(この場合、「該当」)、輸出貿易管理上の許可証の控え等を含む輸出管理リストとともに、アプリケーションと、後述する当該アプリケーションに係るアクセス申告リストと、を当該リージョンに属する運営管理企業2に対して提出することができる。
なお、輸出先のリージョンが非ホワイト国の場合には、通常、当該アプリのストア販売(=在庫販売)は許可されず、当該アプリを販売するためには、対面販売(すなわち、その都度、当該アプリの輸出許可を得ること)が必要となる。
【0083】
3rdパーティの行う、アプリの該非判定及び当該アプリの輸出許可申請等の作業を支援するシステムについては、当業者にとって公知であり、本実施形態におけるアプリケーションを当該販売管理サーバシステム10にストア販売登録するためのストア登録サーバ300は、3rdパーティの行う、アプリの該非判定及び当該アプリの輸出許可申請等の作業を支援するものではない。3rdパーティは、公知の技術を適用して、適宜アプリの該非判定及び当該アプリの輸出許可申請等を行うものとする。
以上を前提として、アプリケーション販売管理システム1000におけるストア登録サーバ300の備える機能部について説明する。
図11は、ストア登録サーバ300の機能ブロック図である。
【0084】
<ストア登録サーバ300>
ストア登録サーバ300は、アプリ開発者(当該リージョンに属するアプリ開発者及び当該リージョンに属さない3rdパーティ)が開発したアプリケーションと、アクセス申告リストと、を受け付けて審査を行い、承認されたアプリケーションを、アクセス申告リストに対応付けて、前述したアプリDB250に登録するサーバである。なお、アプリ開発者が3rdパーティの場合、ストア登録サーバ300は、さらに前述した輸出管理リストをアプリケーションと対応付けて、アプリDB250に登録する。
【0085】
図11に示すように、ストア登録サーバ300は、制御部310と、記憶部320と、通信部330と、を備える。
制御部310は、例えば、CPUであり、記憶部320に記憶された各種プログラムを実行することにより、ストア登録サーバ300を統括制御する。
例えば、CPUは、アプリケーションと、アクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び該非判定リストと、を受け付ける処理(以下、「アプリ受付処理」という。)のためのプログラムを実行する。また、CPUは、受け付けたアプリケーションとアクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を審査する処理(以下、「アプリ審査処理」という)のためのプログラムを実行する。また、CPUは、アプリ審査処理の結果に基づいて当該アプリをアプリDB250に登録する処理(以下、「アプリ登録処理」という。)のためのプログラムを実行する。また、CPUは、アプリDB250に登録された登録アプリ管理情報を照会する処理(以下、「登録アプリ管理処理」という。)のためのプログラムを実行する。
このように、アプリ受付処理、アプリ審査処理、アプリ登録処理、及び登録アプリ管理処理のためのプログラムを実行することにより、CPUには、機能的構成として、アプリ受付部としてのアプリ受付部311と、アプリ審査部としてのアプリ審査部312と、アプリ登録部としてのアプリ登録部313と、登録アプリ管理部としての登録アプリ管理部314と、が形成される。
【0086】
アプリ受付部311は、アプリ開発者の開発したアプリケーションと、当該アプリケーションに係るアクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を受け付ける。なお、この他、アプリ開発者の居住国とその名前、アプリケーションの説明文、アプリケーションのライセンスに関する説明文を受け付けてもよい。ここで、アプリ受付部311は、ストア登録サーバ300に通信可能に接続された端末(例えば、アプリ開発者又はそのエージェント側に設置された端末、又はストア登録サーバ300に通信可能に接続された管理用端末等)からネットワークを介して、アプリケーションと、アクセス申告リストと、アプリ開発者が3rdパーティの場合における該非判定書及び輸出管理規定判定結果等を含む輸出管理リスト、を受け付けてもよい。
また、アプリ受付部311は、アプリケーションとアクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を格納したコンピュータ可読記録媒体を所定の入力インタフェースを介して入力して、受け付けてもよい。ここで、コンピュータ可読記録媒体としては、例えば、磁気記録媒体(例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば、光磁気ディスク)、光ディスク(例えば、CD−ROM、DVD,Blu−Ray Disc(登録商標))等、当業者にとって公知の媒体を含む。
アプリ受付部311は、特に、アプリ開発者が3rdパーティの場合に、受け付けたデータに、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストを含んでいることを確認する。アプリ開発者が3rdパーティであって、受け付けたデータに、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストを含んでいない場合、例えば、エラーメッセージを返すようにしてもよい。そして、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストを受付待ち状態としてもよい。また、当該受け付けたデータを不受理として不受理処分を行い、返却するようにしてもよい。
【0087】
アクセス申告リストは、アプリケーションをエッジサーバで実行する際に使用する、エッジ機器の機能の使用の有無及び/又はエッジ機器の処理データに対するアクセスの有無を示すリストである。具体的には、アクセス申告リストは、エッジ機器500に係る機能の使用の有無及び/又はエッジ機器500の処理データに関するアクセスの有無を示す。なお、「製造装置」とは、エッジ機器500に該当するものであり、アプリ開発者がCNC工作機械、産業機器、産業用ロボット等を指定する。また、アクセス申告リストは、予め決められたフォームになっており、アプリ開発者は、このフォームにしたがってアクセスの有無を、例えばチェックボックスにチェックすることで設定する。
【0088】
より具体的には、エッジ機器500の処理データとして、例えば、エッジ機器500に係る動作状態を示すデータ、生産状況を示すデータ、生産物の品質状況を示すデータ、稼働状況等のイベント(履歴)を示すデータ等がある。これらの処理データは、予めデータモデル化(すなわち、標準化)されており、このように標準化されたデータモデルに基づいてアクセスの有無を設定することを可能にしている。そうすることで、アプリ開発者は、標準化されたモデルに基づき、アクセスの有無を正確に申告することができ、また、アプリ審査側は、アプリ開発者の恣意的な言い回しを排除することで、審査処理を標準化することができる。また、エッジ機器500に係る処理データへのアクセスをするための標準化されたインタフェースを提供することができる。
【0089】
アプリ審査部312は、アプリ受付部311が受け付けたアプリケーションとアクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストとを審査する。
アクセス申告リストの審査の場合、例えば、アプリ審査部312は、アプリケーションのソースコードの分析に基づいて、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致するか否かを審査するようにしてもよい。また、アプリ審査部312は、アプリケーションをエッジサーバ400で実行させることによる動作分析に基づいて、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致するか否かを審査するようにしてもよい。
また、アプリ審査部312は、アプリ開発者が3rdパーティの場合において、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、及び必要に応じてアクセス申告リストと、に基づいて、当該アプリが当該リージョン(例えば、米国)でストア販売可能であることを確認する。具体的には、例えば、アプリ審査部312は、アプリ開発者が3rdパーティの場合に、当該アプリのID及び商品名とともに輸出管理リスト、及び必要に応じてアクセス申告リスト、をアプリ審査の管理者(又は担当者)の端末(図示せず)に、輸出管理リスト確認画面(図示せず)を表示するようにしてもよい。そして、ストア販売可能であることの確認結果を管理者(又は担当者)に入力させるようにしてもよい。そうすることで、当該アプリが当該リージョン(例えば、米国)でストア販売可能であることが確認される。
【0090】
以上の説明において、アプリ開発者が3rdパーティの場合において、アプリ受付部311は、アプリケーションとアクセス申告リストと、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を受け付け、アプリ審査部312は、アプリケーションとアクセス申告リストと、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストとを審査する例について説明したが、これに限られない。
例えば、アプリ開発者が3rdパーティの場合において、アプリ審査部312は、まず、アプリケーションとアクセス申告リストと、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、に基づいて、該非判定書及び輸出管理規定判定結果が適切であるか否かを確認して、適切であると確認された場合に、アプリ審査部312は、例えばアプリケーションのソースコードの分析に基づいて、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致するか否かを審査するようにしてもよい。また、アプリ審査部312は、アプリケーションをエッジサーバ400で実行させることによる動作分析に基づいて、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致するか否かを審査するようにしてもよい。
【0091】
アプリ登録部313は、アプリ審査部312による審査の結果、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致すると判定された場合、さらにアプリ開発者が3rdパーティの場合に当該アプリが当該リージョン(例えば、米国)でストア販売可能と判定された場合、当該アプリケーションを、販売管理サーバシステム10で配信管理することを承認する。そして、アプリ登録部313は、承認されたアプリケーションと、アクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を対応付けて、アプリDB250に登録する。アプリ登録部313は、ストア登録サーバ300に通信可能に接続された端末(例えば、アプリ開発者側に設置された端末、又はストア登録サーバ300に通信可能に接続された管理用端末等)を介して、登録されたこと、すなわちアプリがリージョン(例えば、米国)でストア販売登録されたことを通知する。なお、アプリ登録部313は、電子メールを用いて通知するようにしてもよい。
【0092】
登録アプリ管理部314は、アプリDB250にストア登録されたアプリに関する登録管理情報を照会するアプリ登録管理画面3140を提供する。
図12にアプリ登録管理画面の一例を示す。
図12に示すように、アプリ登録管理画面には、登録されたアプリについて、登録日時3141、アプリ開発者名3142、アプリ開発者居住国3143、商品名3144、居住国における輸出管理規定判定結果3145、該非判定書の控え(リンク情報)3146等を表示する。なお、アプリ登録管理画面に表示される項目はこれに限られない。必要に応じて、適宜項目を追加してもよい。
そうすることで、運営管理企業2の担当者は、ストア登録されたアプリの登録状況を容易に確認することができる。なお、図示しないが、任意の項目を検索項目として、任意の検索条件により検索できるようにしてもよい。例えば、登録日時の範囲を条件指定して検索することで、その間にストア登録されたアプリを確認することができる。また、アプリ開発者の居住国を条件指定して検索することで、指定した国に居住する3rdパーティにより開発されたアプリのストア登録状況を確認することができる。
【0093】
以上、アプリケーション販売管理システム1000におけるストア登録サーバ300に含まれる機能ブロックについて説明した。
【0094】
次に、アプリケーション販売管理システム1000におけるストア登録サーバ300における処理フローについて説明する。
図13は、本実施形態におけるストア登録サーバ300におけるストア販売登録に係る処理の一例を示すフローチャートである。
以下に説明する処理フローでは、ステップS61において、ストア登録サーバ300のアプリ受付部311は、ストア販売登録に必要なデータを、アプリ開発者の端末(図示せず)からネットワークを介して受け付ける手順を例示しているが、これに限定されない。前述したように、例えば、ストア販売登録に必要なデータを格納したコンピュータ可読記録媒体を、運営管理企業2の担当者により、所定の入力インタフェースを介してストア登録サーバ300に入力(受け付け)してもよい。ここで、ストア販売登録に必要なデータとは、少なくともアプリケーションと、アクセス申告リストと、を含み、さらに、アプリ開発者が3rdパーティ(アプリ開発者)の場合、該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を含むデータを指す。
また、アプリ受付部311は、ネットワークではなく、ストア販売登録に必要なデータを格納したコンピュータ可読記録媒体を、所定の入力インタフェースを介して受け付け(入力)してもよい。
【0095】
ステップ60において、ストア登録サーバ300(アプリ受付部311)は、アプリ開発者から、ストア販売登録に必要なデータを受信(又は入力)する。
ステップS61において、ストア登録サーバ300(アプリ受付部311)は、アプリ開発者が3rdパーティか否かを判定する。アプリ開発者が3rdパーティの場合(YES)、ステップS62に移る。アプリ開発者が3rdパーティでない場合(すなわち、当該リージョンに居住する場合)、ステップS67に移る。
【0096】
ステップS62において、ストア登録サーバ300(アプリ審査部312)は、当該アプリのID及び商品名とともに輸出管理リスト、及び必要に応じてアクセス申告リストに基づいて輸出管理リスト確認画面(図示せず)を作成して、アプリ審査の管理者(又は担当者)の端末(図示せず)に表示する。
ステップS63において、ストア登録サーバ300(アプリ審査部312)は、端末(図示せず)を介して、輸出管理リストが「適切」と判定されるとステップS64に移る。輸出管理リストが「不適切」と判定されると、ステップS67に移る。
【0097】
ステップS64において、ストア登録サーバ300(アプリ審査部312)は、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセス内容と、アクセス申告リストに示されたアクセスの有無とが一致するか否かを審査する。一致すると判定された場合(YES)、ステップS65に移る。一致しないと判定された場合(NO)、ステップS67に移る。
ステップS65において、ストア登録サーバ300(アプリ登録部313)は、アプリケーションと、アクセス申告リストと、アプリ開発者が3rdパーティの場合において該非判定書及び輸出管理規定判定結果等を含む輸出管理リストと、を対応付けて、アプリDB250に登録する。
ステップS66において、ストア登録サーバ300(アプリ登録部313)は、アプリ開発者に対して、端末又は電子メール等を介して、アプリが当該リージョン(例えば、米国)でストア販売登録されたことを通知する。その後、ストア登録サーバ300(アプリ登録部313)は、本件の処理を終了する。
【0098】
ステップS67において、ストア登録サーバ300(アプリ登録部313)は、アプリ開発者に対して、端末又は電子メール等を介して、アプリが当該リージョン(例えば、米国)でストア販売登録不可と判定されたことを通知する。その後、ストア登録サーバ300(アプリ登録部313)は、本件の処理を終了する。
以上、アプリケーション販売管理システム1000におけるストア登録サーバ300における処理フローを説明した、
以上のように、本実施例に記載した、海外対応アプリケーション販売管理システムにおけるストア登録サーバ300は、運営管理企業2が、3rdパーティにより開発された3rdアプリを3rdパーティからの申請により現地ストア販売登録する場合、当該アプリに係る該非判定書及び貿易管理規定判定結果を容易に確認することができ、ストア販売登録されたアプリケーションは、審査を経て承認されたものであるので、信頼性が高いものであることが担保される。
【0099】
以上説明したように、本実施形態は、第3の国(例えば、米国)において、オンラインストア販売登録された前記アプリケーションのみを購入可能とする海外対応アプリケーション販売管理システム1000において、ストア登録サーバ300は、第3の国以外の国に居住するアプリ開発者である3rdパーティにより開発された3rdアプリをストア販売登録する場合、3rdアプリと、3rdアプリの該非判定書及び貿易管理規定判定結果を含む輸出管理リストと、を受け付け、3rdアプリが第3の国でストア販売可能と判定された場合、3rdアプリと3rdアプリに係る該非判定書及び貿易管理規定判定結果を含む輸出管理リストと、を対応付けて、アプリDB250に登録する。
これにより、第3の国において運用し提供される海外対応アプリケーション販売管理システム1000において、3rdパーティからの申請により3rdパーティにより開発された3rdアプリを現地ストア販売登録する場合、運営管理企業2は、当該3rdアプリに係る該非判定書及び貿易管理規定判定結果を容易に確認することができる。
【0100】
ストア登録サーバ300は、3rdアプリが第3の国においてストア登録された場合、3rdパーティの連絡先に対して、ストア登録されたことを通知する。
これにより、3rdパーティは、ストア販売登録を申請した3rdアプリのストア販売登録状況を容易に把握することができる。
【0101】
ストア登録サーバ300は、海外対応アプリケーション販売管理システム1000を運営する運営管理企業2の担当者の端末(図示せず)に、アプリDB250にストア登録されたアプリに関する登録管理情報を提供する。具体的には、ストア登録サーバ300は、ストア販売登録されたすべてのアプリケーションに対応付けて、アプリの登録日時、アプリ開発者名、アプリ開発者居住国、アプリの商品名、居住国輸出管理規定の判定情報(済み、又は不要)、判定書控え(リンク先)等の登録管理情報を提供する。
これにより、運営管理企業2の担当者は、ストア登録された任意のアプリに係る書誌情報を容易に把握することができる。
【0102】
また、第3の国においてオンラインストア販売登録されるアプリケーションを記憶するアプリDBは、第3の国に設置されることが好ましい。これにより、第3の国に居住する開発者により開発されたアプリは、第3国内における移動にとどまり、輸出入管理の対象外であり、3rdパーティにより開発される3rdアプリのみが輸出入管理の対象となることで、輸出入に係る運用が容易になる。
【0103】
第3の国は、日本を除いたホワイト国であり、前記3rdパーティの居住国は、日本又は第3の国以外のホワイト国としてもよい。これにより、ホワイト国における海外対応アプリケーション販売管理サーバシステム10を共通化することが可能となる。
【0104】
最後に、エッジサーバ400の構成について簡単に説明する。
図14は、本実施形態におけるエッジサーバ400の機能ブロック図である。
エッジサーバ400は、制御部410と、記憶部420と、通信部430とを備える。
制御部410は、例えばCPUであり、記憶部420に記憶された各種プログラム及び販売管理サーバシステム10からダウンロードしたアプリケーションを実行することにより、エッジサーバ400を統括制御する。
【0105】
本実施形態では、制御部410は、記憶部420に記憶されたアプリケーションに基づく機能部として、アプリ実行部411と、ライセンス制御部412と、アクセス制御部413と、不正アプリ通知部414と、を備える。
アプリ実行部411は、アプリケーションの起動要求に基づいて、記憶部420に記憶されたアプリケーションを実行する。
ライセンス制御部412は、アプリケーションに係るライセンスに基づいて、アプリケーションとエッジ機器500との接続及び/又は入出力を制御する。
【0106】
より具体的には、アプリ実行部411により、記憶部420に記憶されたアプリケーションが起動されると、ライセンス制御部412は、当該アプリケーションに対応するライセンスを読み込む。ライセンス制御部412は、読み込んだライセンスに基づいて、当該アプリケーションの入出力先であるクライアントとして許可されるエッジ機器500を特定する。より具体的には、例えばライセンス制御部412は、ライセンスに基づいて、当該アプリケーションに対して接続要求をするエッジ機器500が、ライセンスに規定する条件を満たすものであるか否かを判断する。
ライセンス制御部412は、当該エッジ機器500が、ライセンスに規定する条件を満たす場合、当該アプリケーションに対する接続要求を許可して、当該アプリケーションとの入出力を制御する。
ライセンス制御部412は、当該エッジ機器500が、ライセンスに規定する条件を満たさない場合(例えば、ライセンスを超えている場合)、当該アプリケーションに対する接続要求を拒否して、当該アプリケーションとの入出力を禁止する。
こうすることで、ライセンス制御部412は、配信されたライセンスにしたがって、エッジサーバ400に配信されたアプリケーションとエッジ機器500との接続及び/又は入出力を制御することができる。
【0107】
アクセス制御部413は、アプリ実行部411が実行したアプリケーションに対応付けられたアクセス申告リストの内容に基づいて、アプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データへのアクセスを監視する。そして、アクセス制御部413は、アクセス申告リストでアクセス有と申告されたエッジ機器500に係る機能の使用及び/又はエッジ機器500の処理データへのアクセスのみを許可する。
また、アクセス制御部413は、アクセス申告リストでアクセス無と申告されたエッジ機器500の機能の使用の要求及び/又はエッジ機器500の処理データに対するアクセス要求を検出した場合に、不正アクセス要求を検出したとして、エラーメッセージ、警報等を表示するとともに、当該アプリケーションを強制停止させることが好ましい。
さらに、アクセス制御部413は、販売管理サーバシステム10からアプリケーションの不正情報を受信すると、当該アプリケーションが実行されている場合には、当該アプリケーションを強制停止させる。
なお、アクセス制御部413は、不正アクセス要求を検出した場合や、アプリケーションの不正情報を受信した場合には、以降において、このアプリケーションの起動をさせないようにすることが好ましい。
【0108】
不正アプリ通知部414は、アプリケーションがアクセス申告リストの申告に反するアクセス要求を検出した場合に、販売管理サーバシステム10に対して当該アプリケーションに係る不正アクセスを検知した旨の通知をする。
【0109】
記憶部420は、制御部410により実行されるアプリケーションを記憶する。記憶部420は、販売管理サーバシステム10から配信されたアプリケーション本体及び当該アプリケーションに係るライセンスを記憶する。
通信部430は、ネットワークN1を介して外部機器(例えば、販売管理サーバシステム10等)とデータの送受信を行い、ネットワークN2を介してエッジ機器500等とデータの送受信を行う通信制御デバイスである。
【0110】
このように、エッジサーバ400は、アクセス申告リストに基づいて、実行するアプリケーションのエッジ機器500の機能の使用及び/又はエッジ機器500の処理データに対するアクセスを監視するので、不正なアクセスができない仕組みにでき、セキュリティ性をより向上することができる。
以上、アプリケーション販売管理システム1000におけるエッジサーバ400について説明した。
【0111】
上記のアプリケーション販売管理システム1000に含まれる各装置のそれぞれは、ハードウェア、ソフトウェア又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラム(アプリケーション)を読み込んで実行することにより実現されることを意味する。
本発明で使用するプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non−transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体(例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ)、光磁気記録媒体(例えば、光磁気ディスク)、CD−ROM(Read Only Memory)、CD−R、CD−R/W、半導体メモリ(例えば、マスクROM、PROM(Programmable ROM)、EPROM(Erasable PROM)、フラッシュROM、RAM(random access memory))を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【0112】
また、上述した実施形態は、本発明の好適な実施形態ではあるが、上記実施形態のみに本発明の範囲を限定するものではなく、本発明の要旨を逸脱しない範囲において種々の変更を施した形態での実施が可能である。
【0113】
[システム構成]
具体例として、管理サーバ100、配信サーバ200、ストア登録サーバ300、及びエッジサーバ400は、一般的なサーバに、本実施形態を実現するためのプログラム(アプリケーション)を組み込むことにより実現できる。
また、管理サーバ100、配信サーバ200、ストア登録サーバ300は、所定のサーバ又は所定のクラウド等に含まれる独立した仮想サーバであってもよい。
【0114】
図15は、サーバ配置の一例を示す図である。
図15に示すように、リージョン0(ゼロ)である日本国内に物理的なハードウェア資源(例えば、サーバ又はクラウド)を設置し、ハードウェア資源をリージョンn(n≧1)毎に専用領域nを設けて、当該専用領域nには、リージョンnに対応する管理サーバ100−nを例えばIaaS(Infrastructure as a Service)として設定してもよい。
そうすることで、インフラとしてのハードウェア資源の保守作業を一括して運用することができるとともに、保守費用等を削減することができる。
なお、配信サーバ200−n及びアプリDB250−nは、前述したように、輸出入管理を簡易化するために、それぞれリージョンn内に設置することが好ましい。
また、
図15にはストア登録サーバ300−nを図示していないが、ストア登録サーバ300−nは、ストア登録するアプリを物理的に受け付けることからすると、配信サーバ200−nと同様に、それぞれリージョンn内に設置することが好ましい。
【0115】
また、ハードウェア構成として、管理サーバ100、配信サーバ200、及びストア登録サーバ300からなる分散システムを例示したが、これに限られない。例えば、各サーバに含まれる各機能部をそれぞれ通信可能に接続するようにサーバに分散させてもよい。分散システムは、当業者にとって公知の技術であり、当業者は、必要に応じて適宜機能の分散化を図ることができる。
【0116】
上述した実施形態では、配信許可情報としてシリアル番号(ライセンスキー)を用いる例で説明したが、これに限定されない。配信許可情報は、アプリケーションの配信を許可する情報であればよい。
【0117】
上述した実施形態では、販売管理サーバシステム10の記憶部120に各種の情報を記憶するものを説明したが、記憶部の各種の情報は、あくまで例示であって、他の情報を含むものであってもよい。また、データの保有方法についても、一例にすぎない。