JP6581859B2 - 情報処理装置、ソフトウェア配信システム、およびソフトウェア配信方法 - Google Patents
情報処理装置、ソフトウェア配信システム、およびソフトウェア配信方法 Download PDFInfo
- Publication number
- JP6581859B2 JP6581859B2 JP2015183041A JP2015183041A JP6581859B2 JP 6581859 B2 JP6581859 B2 JP 6581859B2 JP 2015183041 A JP2015183041 A JP 2015183041A JP 2015183041 A JP2015183041 A JP 2015183041A JP 6581859 B2 JP6581859 B2 JP 6581859B2
- Authority
- JP
- Japan
- Prior art keywords
- software
- server
- information processing
- processing apparatus
- downloaded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Stored Programmes (AREA)
Description
また、すでに携帯端末にインストールされて利用されているソフトウェアについて、バグやセキュリティホールを修正する場合や、機能向上のためのバージョンアップをする場合も、その修正内容や新しい機能を含めた最新版のソフトウェアが、サーバからネットワークを介して配信される(特許文献1参照)。
このようなネットワークを介した配信サービスは、CD−ROM等の記憶媒体を利用して最新版のソフトウェアを提供する場合に比べて、多くのユーザに提供する手間、時間及びコストを節約することができるため、広く利用されている。
パソコン等で利用するアプリケーションソフトやシステムソフトなどのように、ダウンロードした後すぐに自動的にインストールが実施されるものもあるが、今日の携帯電話やスマートフォンのシステムソフトを更新する場合などのように、ソフトウェアのダウンロードが完了した後、利用者の明示的なインストール要求の指示入力があった場合や、所定の設定時刻の経過後に、インストールが開始されるものがある(非特許文献1および2参照)。
ソフトウェアの配信の中止は、たとえば、開発者等がソフトウェアをアップロードしたサーバに対して、配信中止指示をすることや、アップロードしたソフトウェアそのものの削除指示をすることにより行うことができる。
たとえば、問題のあるソフトウェアをダウンロードしていない端末、ダウンロードの途中であってまだダウンロードが完了していない端末、ダウンロードが途中で中断されている端末などについては、その後のダウンロードが失敗に終わるような措置をとることで、不具合の発生を未然に防止できる。
この発明の情報処理装置において、前記確認要求部が、前記ダウンロードしたソフトウェアが前記サーバに存在することを確認した場合、前記制御部は、前記インストール実行部によって、前記ダウンロードされたソフトウェアのインストールを実行させることを特徴とする。
また、前記ダウンロードされたソフトウェアを記憶する記憶部を備え、前記確認要求部が前記サーバに確認要求をした結果、前記ダウンロードしたソフトウェアがサーバに存在しないことを確認した場合には、前記制御部は、前記記憶部に記憶されたソフトウェアを消去することを特徴とする。
また、前記ダウンロード実行部が、ソフトウェアを前記サーバからダウンロードした後、所定の時刻が到来した時、あるいは所定の時間が経過した後に、前記確認要求部が、前記サーバに対して、前記ダウンロードされたソフトウェアが存在するか否かを確認することを要求することを特徴とする。
また、前記制御部が、前記ダウンロードされたソフトウェアをインストールする時期がきたときに、前記ダウンロードされたソフトウェアと同一のソフトウェアを再度ダウンロードすることを、サーバに要求した後、前記同一のソフトウェアが受信されない場合に、前記インストール実行部によって前記ダウンロードされたソフトウェアのインストールを実行させないことを特徴とする。
また、前記情報処理装置が、前記ダウンロードしたソフトウェアがサーバに存在しないことを示す確認応答情報を受信した場合に、前記ダウンロードしたソフトウェアを消去するステップを有することを特徴とする。
また、前記情報処理装置が、前記ダウンロードされたソフトウェアのインストールを実行する指示入力がされた後に、前記確認要求をサーバに送信するステップを実行することを特徴とする。
また、前記情報処理装置が、ソフトウェアを前記サーバからダウンロードした後、所定の時刻が到来した時、あるいは所定の時間が経過した後に、前記確認要求をサーバに送信するステップを実行することを特徴とする。
前記情報処理装置が、前記ダウンロードされたソフトウェアをインストールする時期がきたときに、前記ダウンロードされたソフトウェアと同一のソフトウェアを再度ダウンロードすることを、前記サーバに要求した後、前記同一のソフトウェアが受信されない場合に、前記ダウンロードされたソフトウェアのインストールを実行させないことを特徴とする。
<この発明のソフトウェア配信システムの構成>
図1に、この発明のソフトウェア配信システムの一実施例の構成説明図を示す。
図1において、ソフトウェア配信システムは、サーバに記憶されたソフトウェアを情報処理装置に配信するシステムであり、主として、1つまたは複数個のサーバ11からなるファイルサーバ群10と、複数のパソコン21や携帯端末22からなる情報処理装置群20とから構成され、各サーバ11と、各パソコン等は、ネットワーク30を介して接続される。
サーバ(SV)11は、1つでもよいが、ネットワーク30に接続された複数個のサーバを利用できるようにしてもよい。
たとえば、複数のサーバによって、CDN(Contents Delivery Network)を構成して
もよい。
CDNに属するサーバに記憶されたソフトウェアをパソコンに配信する場合、同一ソフトウェアを記憶している別のサーバからダウンロードすることが可能となり、大容量のソフトウェア等を、スムーズに配信することができる。
この発明では、サーバ11に記憶されている種々のコンテンツのうち、ユーザの所有する情報処理装置にインストールされて実行されるソフトウェアを配信する場合について説明する。
情報処理装置群20に属する情報処理装置としては、たとえば、パソコン21、携帯端末22、車載端末などがある。また、家電機器、産業用機器、自動車などを制御するためのマイクロコンピュータも情報処理装置群20に属する情報処理装置に含めることができる。携帯端末22とは、携帯電話、スマートフォン、タブレット端末などユーザが携帯することが可能な小型軽量の端末を意味する。
ダウンロード要求を受信したサーバSV1では、パソコンTE1のユーザがダウンロードすることを許可された者であると判断した場合に、要求されたソフトウェアSFをパソコンTE1へ送信する。
受信したソフトウェアSFを利用可能な状態とするためには、たとえば、ユーザが、インストール指示入力を行う必要がある。
この発明では、ユーザがインストール指示入力をした場合、直ちに、そのソフトウェアSFのインストール動作を実行するのではなく、まず、サーバSV1に対して、ソフトウェアSFがサーバSV1の中に存在することを確認するための確認要求を送信することを特徴とする。
この確認要求に対して、たとえば、サーバSV1から、ソフトウェアSFが存在するという応答が返信された場合には、すでに受信していたソフトウェアSFのインストール動作を実行する。
一方、ソフトウェアSFがサーバSV1には存在しないという応答が返信された場合は、そのソフトウェアSFのインストールは行わず、受信していたソフトウェアSFを消去する。
図2に、この発明の情報処理装置の一実施例の構成ブロック図を示す。
図2において、情報処理装置20(以下、単に、端末またはTEとも呼ぶ)は、主として、制御部31、表示部32、入力部33、通信部34、ダウンロード実行部35、インストール実行部36、更新問合要求部37、ダウンロード要求部38、確認要求部39、記憶部41を備える。
制御部31は、この発明の端末TE20の各種機能を実行する部分である。
主として、CPU、ROM、RAM、I/Oコントローラ、タイマー等からなるマイクロコンピュータにより実現され、CPUがROM等に記憶されたプログラムに基づいて、各種ハードウェアを有機的に動作させることにより、通信機能、入力機能、表示機能、インストール機能などを実現させる。
入力部33は、TE20の所有者(ユーザ)が、データ入力や、所望の機能の選択入力を行う部分であり、たとえば、タッチパネル、キーボード、マウス等が用いられる。
通信部34は、ネットワーク30を介して、他の装置、特に、ソフトウェアを記憶したサーバSV11に接続し、データやソフトウェアなどの情報の送受信を行う部分である。
ネットワーク30は、既存のネットワークのいずれかを用いればよく、特に限定するものではない。
たとえば、一般的なスマートフォンの場合、携帯電話キャリアの通信網を経由したインターネット接続、WLANを経由したインターネット接続等の方法をとることができ、また、必要に応じて複数の通信方式や接続方法を自動的に切り替えるような実装をしてもよい。
ネットワークの通信方式は、無線通信でも、有線通信のどちらでもよく、通信媒体も任意のものを用いることができ、限定するものではない。
ファイル等のダウンロードは、TE20からのダウンロード要求をサーバSVに送信した後に、サーバSVから送信される形態であってもよく、あるいは、サーバSVから事前にダウンロードすることが許可されたTE20に対して、必要に応じてファイルが有る旨をプッシュする形態であってもよい。ダウンロードすることによって取得されたプログラムファイル等は、記憶部41に、記憶される。
取得されたソフトウェアをインストールする形態は種々の形態があり、ダウンロード直後に自動的にインストールが実行されるものや、記憶部41に一時記憶された後、所定の時刻が到来した時にインストールが実行されるもの、あるいはユーザの明示的なインストール要求入力があってはじめてインストールが実行されるものなどがある。
以下の実施例では、主として、ユーザからのインストール要求入力があった後、所定の確認処理が成功した場合に、インストールが実行されるものとする。
この問合せ要求は、入力部33を用いて、ユーザが更新の問合せ要求を意図する入力操作を行ったときに行ってもよく、あるいは、予め設定された日時や、数時間毎、数日毎など定期的な間隔で、自動的に行ってもよい。
ここで要求するソフトウェアは、TEですでにインストールされて利用されているソフトウェアであってもよく、新たに初めてダウンロードされるソフトウェアであってもよい。
ダウンロード要求の送信は、入力部33によって、ユーザがダウンロードを要求するための意図的な入力操作を行ったときに行ってもよいが、あるいは、サーバ等からの通知に基づいて新しい更新バージョンがあることがわかったときに、自動的にダウンロード要求を送信してもよい。
以下の実施例では、ダウンロードは完了したがインストールが未実施であるソフトウェアについて、主として、ユーザがインストール要求を意味する入力操作をした場合に、TE側でインストール動作を実行する前に、確認要求VREQが、サーバSVに送信される。
したがって、確認要求は、サーバSVから取得されて記憶部41に記憶されているソフトウェアであって、実行可能な状態とするためのインストール動作がまだ実施されていないソフトウェアについて、行われる。
確認要求VREQをサーバに送信するタイミングとしては、上記のように、ユーザが明示的なインストール要求の入力操作をした場合のほかに、ダウンロードを完了した直後、予め設定された時間が経過した後、あるいは、ユーザ等によって予め設定された時刻が到来した時などであってもよい。
この発明では、たとえば、端末TEを区別するための端末識別情報42や、サーバSVから取得されたソフトウェア51が、記憶される。
ソフトウェア51は、TEの動作を制御するオペレーティングシステムのシステムソフトウェアや、所定の機能を実行させるためのアプリケーションプログラムなどを意味する。
ソフトウェアは、所定の機能を実行させるために、1または複数個のモジュールプログラムから構成されるが、1つのソフトウェア51は、図2に示すように、少なくともそのソフトウェアを特定するために、ソフト名52、バージョン53、ファイル54、サーバ識別情報55が記憶される。
バージョン53は、ソフトウェアが開発された後何度も改良されている場合に、どの改良版であるかを区別するための情報である。
このバージョン53を確認することによって、現在インストールされているソフトウェアが最新版であるか、あるいは新たな改良版をダウンロードすべきかなどが判断できる。
ファイル54は、ソフトウェアの実体(プログラム)を意味する情報であり、一般的には、サーバからダウンロードされた形式のプログラムそのものをいう。
インストール動作をすることによって、このファイル54は、解凍、復号化などが行われ、実行可能な形式に変換される。
サーバ識別情報55は、ダウンロードされたソフトウェアが記憶されていたサーバを特定するための情報である。この情報55によって、ソフトウェアがどのサーバからダウンロードされたかがわかる。
記憶部41に記憶される情報は、上記ソフトウェア51に限るものではなく、この他にも、インストールを実行したか否か(インストール動作の有無)を示す情報や、現在のソフトウェアバージョン、ダウンロードやインストールを完了した時刻情報などを記憶してもよい。
図3に、この発明のサーバの一実施例の構成ブロック図を示す。
図3において、サーバSV11は、主として、制御部71、通信部72、問合応答部73、ソフトウェア検索部74、ソフトウェア送信部75、確認応答部76、更新問合要求受信部77、ダウンロード要求受信部78、確認要求受信部79、記憶部81を備える。
制御部71は、サーバSV11の各種機能を実行する部分であり、主として、CPU、ROM、RAM、I/Oコントローラ、タイマー等からなるマイクロコンピュータにより、実現される。
問合応答部73は、TEからSVに送信された更新問合要求KREQに対して、その応答情報を送信する部分である。更新問合要求KREQを受信すると、サーバSVは、問合要求のあったソフトウェアについて、更新の有無をチェックし、応答情報として、後述するような更新有無情報を、問合せ要求をしてきたTEに対して、送信する。
後述するように、TEから送信されたダウンロード要求に含まれるソフト名とバージョン情報とを利用して、記憶部81の中に格納された多数のソフトウェアの中から、要求されたソフトウェアを抽出する。
ソフトウェア送信部75は、TEから要求されソフトウェア検索部74によって抽出されたソフトウェアを、ダウンロード要求をしてきたTEに対して、送信する部分である。
確認要求VREQを受信すると、サーバSVは、確認要求されたソフトウェアと同一のソフト名およびバージョン情報を持つものが現在記憶部81に記憶されているか否かを確認し、後述するような確認応答情報を、確認要求を送信してきたTEに返信する。確認応答情報は、そのソフトウェアがサーバの中に現在存在しているか否かを示す情報である。
たとえば、確認要求されたソフトウェアがサーバに記憶されていない場合は、サーバに存在しないことを示す確認応答情報を、TEに返信する。
ダウンロード要求受信部78は、TEから送信されたダウンロード要求DREQを受信する部分である。後述するように、受信されたダウンロード要求DREQから、端末識別情報と、ソフト名と、バージョンとが、取得される。
確認要求受信部79は、TEから、ダウンロードされたソフトウェアの確認要求VREQを受信する部分である。
後述するように、受信された確認要求VREQから、端末識別情報と、ソフト名と、バージョンとが取得される。
記憶されるソフトウェア91は、種々の形態で記憶されるが、1つのソフトウェアには、たとえば、ソフト名92、バージョン93、ファイル94、配信端末情報95、保存先情報96などが記憶される。
ここで、ファイル94は、ソフト名92とバージョン93によって識別されるソフトウェア91の実体であり、配信端末情報95は、そのソフトウェア91が実際に配信された情報処理装置TEを示す情報である。保存先情報96は、ソフトウェアの所在を示す情報であり、たとえば、URLなどが用いられる。
記憶部81に記憶される情報は、上記ソフトウェア91に限定されるものではなく、この他に、インストールを実行したか否か(インストール動作の有無)を示す情報や、現在のソフトウェアバージョン、ダウンロードやインストールを完了した時刻情報などの情報が記憶される。
図4に、端末TEとサーバSVとの間で、送受信される情報の一実施例の説明図を示す。
ここでは、端末TEからサーバSVへ送信される情報として、更新問合要求KREQ、ダウンロード要求DREQ、確認要求VREQを示す。
また、サーバSVから端末TEへ送信される情報として、更新有無情報、更新ソフトウェア、確認応答情報を示す。
図4に示す各情報の内容は、一つの例であって、これに限るものではない。
更新問合要求KREQは、TEからSVへ送信される情報であり、所望のソフトウェアについて、新しい更新バージョンが存在するか否かを確認することを、サーバSVに対して要求する情報である。図4に示すように、たとえば、更新問合要求は、要求名=KREQ、サーバ識別情報=SV01、端末識別情報=TE001、ソフト名=PROG01、バージョン=VER−10から構成される。
更新有無情報は、SVからTEへ送信される情報であり、更新問合要求KREQに対する応答情報である。この情報によって、サーバの中に、新しい更新バージョンが有るかないかを、TEへ通知する。
図4に示すように、たとえば、新しい更新バージョン(VER−20)がサーバにあることを通知する場合は、応答名=KREQ−ANS、端末識別情報=TE001、ソフト名=PROG01、最新のバージョン=VER−20、更新ファイルの存在有無=有り、サーバ識別情報=SV01、保存先情報=URLという情報が、TEに対して送信される。
一方、更新バージョン(VER−10)がサーバにないことを通知する場合は、応答名=KREQ−ANS、端末識別情報=TE001、ソフト名=PROG01、最新のバージョン=VER−10、更新ファイルの存在有無=無し、サーバ識別情報=SV01という情報が、TEに対して送信される。
ダウンロード要求DREQは、TEからSVへ送信される情報であり、所定のバージョンのソフトウェアをダウンロードすることを、サーバに要求するための情報である。
図4に示すように、たとえば、「TE001」の端末が、バージョンが「VER−20」のソフトウェア「PROG01」のダウンロードを要求する場合は、要求名=DREQ、端末識別情報=TE001、ソフト名=PROG01、バージョン=VER−20、サーバ識別情報=SV01、保存先情報=URLから構成されるダウンロード要求DREQを、送信する。
更新ソフトウェアは、SVからTEへ送信される情報であり、ダウンロード要求DREQに対して、要求のあったソフトウェアそのものを、TEへ送るものである。ただし、送信データ量や転送時間の削減のため、現在TEに搭載されているソフトウェアと、最新バージョンのソフトウェアとの差分ファイルをTEへ送信してもよい。
図4に示すように、更新ソフトウェアには、たとえば、送信先を示す端末識別情報(TE001)、送信されるソフトウェアを示すソフト名(PROG01)、そのソフトウェアのバージョン(VER−20)、そのソフトウェアの実体を示すファイル(FL−soft)、送信元のサーバを特定するサーバ識別情報=SV01とが含まれる。
確認要求VREQは、TEからSVへ送信される情報であり、所望のソフトウェアをインストールしようとする前に、その同一バージョンのソフトウェアが、サーバSVに現在存在しているか否かを確認するための情報である。
図4に示すように、たとえば、「TE001」の端末TEが、ソフト名=「PROG01」のバージョン=「VER−20」が存在するか否かを、サーバに確認する場合は、要求名=VREQ、サーバ識別情報=SV01、端末識別情報=TE001、ソフト名=PROG01、バージョン=VER−20を含む確認要求VREQを、SVに送信する。
確認応答情報は、SVからTEへ送信される情報であり、確認要求VREQに対する応答情報である。
サーバが確認要求VREQを受信すると、対象となるソフトウェアがサーバに存在するか否かを確認した後、確認要求されたソフトウェアが存在する場合は、存在することを示す情報がTEに送信され、存在しない場合は、存在しないことを示す情報がTEに送信される。
図4に示すように、たとえば、「TE001」の端末TEから、ソフト名=PROG01のバージョン「VER−20」が、サーバに存在するか否かの確認を要求された場合において、サーバに存在することを確認した場合は、応答名=VREQ−ANS、存在有無=「有り」の確認応答情報が送信される。
一方、サーバに存在しないことを確認した場合は、応答名=「VREQ−ANS」、存在有無=「無し」の確認応答情報が送信される。
一方、存在有無=「無し」の確認応答情報を受信した場合は、サーバに、確認要求したバージョンのソフトウェアは存在しないので、インストール動作はせずに、そのソフトウェアそのものを消去する。
図5、図6および図7に、端末TEとサーバSVとの間で行われるソフトウェア配信処理の一実施例のシーケンス図を示す。
ここでは、端末TEにすでに配信されたソフトウェアが記憶されかつインストールも実行されて、実際に利用されているソフトウェアについて、サーバに更新の有無を問合せ、新しいバージョンの更新がある場合に、その更新ファイルをダウンロードし、存在確認をした後にインストールする場合について説明する。
図5に、実施例1の配信処理のシーケンス図を示す。
ステップT1において、TEのユーザが、入力部33を用いて、所望のソフトウェアの更新の有無を確認するための問合要求を意味する入力操作をしたとする。
このとき、更新問合要求部37が、通信部34を介して、図4に示すような更新問合要求KREQを、サーバSVに送信する。
受信したKREQから、ソフト名とバージョンとを取得して、そのソフトウェアについての更新ファイルが記憶部81の中に存在するか否かを、チェックする。
その端末TEに適用可能な新しい更新ファイルが存在する場合は、問合応答部73が、図4に示すように、バージョンに新しいバージョンを書き込み、保存先情報に記憶場所を示すURLを設定し、更新有無を「有り」とした更新有無情報を、KREQを送信してきたTEに、送信する。
一方、その端末TEに適用可能な新しい更新ファイルがなく、KREQに含まれたバージョンが現在最新バージョンであった場合は、更新有無を「無し」とした更新有無情報を、送信する。
受信した更新有無情報が「更新無し」の場合は、問合結果として、更新がないことを示すメッセージを、表示部32に表示する。
受信した更新有無情報が「更新有り」の場合は、問合結果として、更新があることと、更新ソフトウェアに関する情報(バージョン、保存先情報など)とを、表示部32に表示する。さらに、音声でユーザに通知してもよい。
これにより、ユーザは、現在利用しているソフトウェアについて、より新しいバージョンのソフトウェアが存在することを知ることができる。
ステップS2において、サーバのダウンロード要求受信部78が、ダウンロード要求DREQを受信する。
ソフトウェア検索部74が、受信したDREQから、ソフト名、バージョン、保存先情報を取得し、保存先情報によって特定される場所に記憶されている更新ソフトウェアのファイルを読み出す。そして、ソフトウェア送信部75が、読み出された更新ソフトウェアを、DREQを送信してきたTEに、送信する。
更新ソフトウェアのファイルFLを正常に受信した場合は、ダウンロードが完了したことを、表示部32に表示する。
さらに、ユーザにインストールの指示入力を求めるために、ダウンロードした更新ソフトウェアのインストールが可能であることを表示してもよい。
ステップT5において、入力部33によって、ユーザがインストールの開始を意味する指示入力操作をした場合、確認要求部39が、確認要求VREQを、サーバSVに送信する。ここでVREQには、少なくともインストールしようとしているソフトウェアを特定できる情報(例えばソフト名、バージョン等)が含まれる。
そのソフトウェアが、現在存在している場合は、確認応答部76が、存在有無を「有り」とした確認応答情報を、TEに送信する。
一方、確認要求されたバージョンのソフトウェアが存在しなかった場合は、存在有無を「無し」とした確認応答情報を、TEに送信する。
存在有無が「有り」の場合は、確認要求したバージョンのソフトウェアがサーバに存在することが確認されたので、インストール実行部36が、そのソフトウェアをインストールする処理を開始する。
一方、存在有無が「無し」の場合は、確認要求したバージョンのソフトウェアがサーバに存在していないことが確認されたので、制御部31は、インストール実行部36によって、ダウンロードされたソフトウェアのインストールを実行させないようにし、そのソフトウェアを、記憶部41から消去する。
このように、サーバにすでに存在しなくなったソフトウェアを、TEの記憶部41から消去しているので、ユーザがインストールの指示入力をすることによって、開発者等が不具合を認識して配信を中止しているにも関わらず、そのソフトウェアがインストールされて実行可能な状態となってしまうことを防止でき、TEに不具合が発生することを未然に防止できる。
(a)まず、ステップT1において、更新問合要求KREQの送信は、ユーザの入力を待ってから行うのではなく、予め設定された時間が経過するごとに、自動的に行ってもよい。時間の設定としては、一定時間(例えば12時間毎、1日毎など)にしてもよいし、例
えば更新問合要求KREQを送信した時に、次回の問合せまでの時間を例えば12時間〜24時間の中でランダムに決める、といった実装にしてもよい。後者の実装は、特定の時間帯にサーバへの問合せが集中することを避けたい場合に有効である。この場合には、一般にユーザが見ていない所での確認になるので、受信した更新有無情報が「更新有り」だった場合にのみその旨を表示部32に表示し、受信した更新有無情報が「更新無し」だった場合は、特に何もせずに、ステップT1へ戻り、次回の問合要求を待てばよい。
(b)また、ステップS1において、TEからKREQを受信した場合に、更新ファイルの有無をチェックするのではなく、サーバにソフトウェアの新しいバージョンの更新ファイルが記憶されたときに、そのソフトウェアをダウンロードしたことのあるTEに対して、更新ファイルがあることを知らせる情報を自動的に送信してもよい。
この更新ファイルがあることを知らせる情報の送信は、既存のSMSや電子メールを利用して、TEのユーザに知らせてもよい。特にSMSを利用する場合は、ユーザに通知すると共に、SMSの機能を利用して情報処理装置TE自体に対してダウンロード開始日時、更新開始日時の一方又は両方を設定してもよい。
あるいは、通信部34によって、無線通信を行う場合、ダウンロード要求DREQを送信する前に、電波状況をチェックし、エラーなく良好に送受信が可能な場合や、所定の高速無線通信が利用できる場合に、サーバにDREQを送信してもよい。
また、ダウンロードが正常に終了していない状態で、一定期間(たとえば、数日から数週間)が経過した場合は、一時的な通信障害のためにダウンロードに失敗したのではなく、サーバからソフトウェアが削除されダウンロードできない状態となっている場合もあり得るので、ダウンロードが終了した部分のファイルを消去し、ステップT1へ戻り、更新問合要求を送信するようにしてもよい。
また、更新ソフトウェアのファイル容量が大きい場合、サーバに、その更新ソフトウェアを複数のファイルに分割して保存している場合がある。このとき、ダウンロードの再開時に、分割された未受信のソフトウェアがまだサーバに残っていた場合は、残りの部分の分割ファイルを、ファイル単位でダウンロードするようにしてもよい。
図6に、実施例2の配信処理のシーケンス図を示す。
図5と同じ処理をするステップには、図5と同じステップ番号を付与している。
図6において、サーバSVのステップS1からS3、端末TEのステップT1からT5までの処理は、図5に示す実施例1と同様の処理を行う。
ここでは、実施例1と異なり、サーバSVは、TEから送信された確認要求VREQに対して、確認要求されたソフトウェアが存在する場合は、そのソフトウェア情報を送信し、存在しない場合は、ソフトウェアが無いことを示す無し応答情報を送信する。
ステップS3において、VREQを受信した後、サーバSVでは、確認要求されたソフトウェアが存在するか否かを確認する。
ステップS4において、ソフトウェアが存在する場合は、サーバに記憶されているそのソフトウェアの現在のバージョンを含むソフトウェア情報をTEに送信する。
ソフトウェア情報は、ソフトウェアを識別するための情報からなり、ソフトウェアの実体であるファイルを含まない情報であり、たとえば少なくとも、ソフト名、バージョン、ファイルサイズ、そのソフトウェアを適用可能なTEを特定する情報(適用可能なTEの機種名、OS名、OSバージョンなど)などの情報を含む。
両者のバージョンが一致する場合は、ダウンロードが完了した更新ソフトウェアを、インストールする。
一方、両者のバージョンが一致しない場合は、ダウンロードが完了していた更新ソフトウェアのファイルFLを消去する。
また、ステップS3の確認の結果、ソフトウェアが存在しない場合は、ステップS5において、確認要求されたソフトウェアが存在しないことを示す情報(無し応答情報)を、TEに送信する。
ステップT12において、TEが無し応答情報を受信した場合、ダウンロードが完了していた更新ファイルFLを消去する。
この実施例2では、端末TE側で、インストールしようとするソフトウェアと同じバージョンのソフトウェアがサーバにあることを確認し、なかった場合には、そのソフトウェアを消去するので、開発者等が不具合を認識して配信を中止したソフトウェアを、ユーザがインストールしてしまうことを防止できる。
図7に、実施例3の配信処理のシーケンス図を示す。
図5と同じ処理をするステップには、図5と同じステップ番号を付与している。
図7では、サーバSVのステップS1、S2、端末TEのステップT1からT4までの処理は、図5に示す実施例1と同様であるが、インストール指示入力があった後の処理(ステップS11、ステップT21、T22、T23)が異なる。
図7のステップT21において、ユーザがインストール指示入力を行った場合、ステップT3と同様に、ダウンロード要求DREQを送信する。
このダウンロード要求DREQのデータ内容としては、ステップT3で送信したのと同一のものを再送する。
もし、ステップS11におけるソフトウェア検索で、ダウンロード要求された同一バージョンの更新ソフトウェアが存在する場合は、その更新ソフトウェアが再送される。
このとき、ステップT22において、TEでは、ステップT4で受信したのと同じ更新ソフトウェアが受信されることになる。
そこで、受信開始時において、受信しようとする更新ソフトウェアが、以前受信したものと同一バージョンのソフトウェアであるか否かをチェックする。
同一バージョンのソフトウェアが再度受信されようとしている場合は、その受信を中断する。
同一バージョンのソフトウェアが再度受信できているということは、ステップT4においてダウンロードしたソフトウェアが、現在もなおサーバに存在するということを示しているので、インストールしても問題はないと考えられる。
したがって、すでにダウンロードは済んでいるので再度の受信は中断し、ダウンロードしていたソフトウェアのインストールを開始する。
ステップT23において、TEが無し応答情報を受信した場合、ステップT4においてダウンロードしていたソフトウェアのファイルFLを消去する。
また、TEにおいて、ステップT21でDREQを送信して一定時間経過した後、何も応答が返信されなかった場合は、DREQを何回か再送した後、ダウンロードすべきソフトウェアはサーバにないと判断し、ステップT4でダウンロードが完了していたソフトウェアのファイルFLを消去する。
以上のように、確認要求VREQを送信する代わりに、ダウンロード要求DREQを再送することにより、インストール処理をすべきか否かを判断することができ、再度のダウンロードが開始できなかった場合には、更新ソフトウェアのファイルを消去することによって、開発者等が不具合を認識して配信を中止したソフトウェアを、ユーザがインストールしてしまうことを防止できる。
上記した3つの実施例では、TEからダウンロード要求DREQを送信した場合、ステップT4において、要求したソフトウェアのファイル全体を受信することによって、ダウンロードを完了していた。
この実施例4では、要求したソフトウェアのファイル全体を受信してしまうのではなく、ファイルの一部分のみを残して、ダウンロードを中断し、その後インストールの開始要求があった時に、ダウンロードを再開し、その残った一部分を受信するようにする。
すなわち、ダウンロードすべきソフトウェアのファイルのうち、ほとんどの部分を受信するが、最後の所定容量分のファイルデータを受信せずに、ダウンロードを中断する。
ここで、所定容量分のファイルデータは、ダウンロードの再開時に、すぐにダウンロードが完了するようにするために、なるべく小容量であることが好ましい。
所定容量分のファイルデータとしては、たとえば、1バイトデータでもよく、転送単位である1パケットデータでもよい。
この実施例4では、図5などのステップT4において、ダウンロードが中断されるので、この時点では、受信された更新ソフトウェアは、まだインストールをすることのできない不完全な状態である。
ただし、ユーザに対しては、ダウンロードが完了したことを示すメッセージを表示しておくものとする。
あるいは、サーバSVにおいて、端末TEには、所定容量分のファイルデータが未送信であって、所定容量分のファイルデータ以外の部分がすでにダウンロードされていることを記憶しておいてもよい。
その後、図7のステップT21に示すように、ユーザによってインストールの指示入力がされた場合に、TEからSVへ、ダウンロードを中断していたソフトウェアのダウンロードを再開するためのダウンロード要求DREQを再送信する。このDREQには、ダウンロードを再開すべき未受信のファイルデータの部分を示す情報を含めてもよい。
TEが、未受信のファイルデータ部分を受信した場合、すでに受信していた部分と、今回受信したファイルデータ部分とを結合することにより、所望のソフトウェアのダウンロードが完了する。
そして、ダウンロードが完了した場合、ダウンロード要求したソフトウェアは現在もサーバSVに存在すると判断し、ただちに、インストール動作を開始する。
このとき、インストールを開始した場合は、ダウンロードが完了したことはユーザに知らせずに、インストールを開始したことのみを表示部32に表示してもよい。
すなわち、TEにおいて、たとえば、DREQを再送信した後、一定時間を経過しても、未受信のファイルデータ部分を受信することができなかった場合は、大半を受信していたソフトウェアが、サーバSVには存在しなくなったと判断し、そのソフトウェアのすでに受信していたファイルデータを、TEの記憶部41から消去する。
これにより、所望のソフトウェアがサーバSVに存在しなくなっている場合は、ダウンロードが未完了の状態のファイルが消去されるので、開発者等が不具合を認識して配信を中止したソフトウェアを、ユーザがインストールしてしまうことを防止できる。
この実施例4では、小容量の未受信のファイルデータ部分の受信の有無によって、インストール実行前の確認処理が行われるので、図5、図6の実施例で示したような確認要求VREQとその応答を送受信することが不要となる。
上述した実施例では、端末TEにダウンロードした後にインストールしようとしているソフトウェアについて、サーバに存在しない場合にはインストールを防止する方法を示した。同様に、端末TEにすでにバックアップしているソフトウェアについても、サーバに存在しないことを確認した場合には、使用できないようにTEを制御してもよい。これにより、バックアップされたソフトウェアについても安全に更新を行うことができ、TEに不具合が発生することを未然に防止できる。
特に、TEが、移動が困難な大型の機器や、故障した時には修理工場へ自走が困難になる自動車を制御するためのマイクロコンピュータの場合、ソフトウェアの書換えに失敗した場合に備え、その場で再度書換えを行って原状回復ができるように、バックアップのソフトウェアを準備しておく事が望ましい。
そこで、TEの記憶部にバックアップされたソフトウェアがすでに存在していた場合、バックアップされたソフトウェアが記憶部に存在していることを確認し、かつサーバにも存在していることを確認した場合に、新たに更新用のソフトウェアをインストールするようにする。
この場合、図5のステップT1において、TEからサーバSVに対して更新の有無を問い合わせる前に、まず、バックアップのソフトウェアについてサーバにあることを確認する。その後、改めて、これからインストールしたいソフトウェアがサーバにあることを確認し、インストールを開始するように実装するようにする。なお、確認の順番は逆であっても良く、先にインストールしたいソフトウェアがサーバにある事を確認してから、バックアップのソフトウェアについてサーバにあることを確認する実装であっても良い。
また、このように警告にとどめるだけでも良いが、有効なバックアップのソフトウェアを入手するまでは、インストールしようとしているソフトウェアをインストールさせないように実装するようにしてもよい。
以上のように、バックアップされたソフトウェアについても、サーバに存在の有無を確認することによって、移動が困難な大型の機器や、故障した時には修理工場へ自走が困難になる自動車を制御するためのマイクロコンピュータのソフトウェア更新の際に、より安全に、ソフトウェアの更新を行うことが可能となる。
(その他の実施形態1)サーバSVが複数台存在し、CDNが構成されている場合、同一ソフトウェアが、複数のサーバSVに同時に記憶されている場合がある。
この場合、ソフトウェア配信者がソフトウェアSFをアップロードしたり削除したりする場合、特定の管理サーバに対してアクセスし認証を行った上でアップロードしたり削除したりするのが普通である。管理サーバにソフトウェアSFが更新されたり、削除されたりした時には、そのソフトウェアSFと同一のソフトウェアが記憶されている他のサーバにおいても、ほぼリアルタイムで、更新あるいは削除する。
(その他の実施形態3)あるいは、端末側の設定として、ソフトウェアの有無の問合せは常に管理サーバに対して行うようにし、ソフトウェアのダウンロードは管理サーバから指定されたCDN上の適切なサーバからダウンロードするようにしてもよい。
上記実施形態では、主として、TEにすでにインストールされて利用されているソフトウェアを更新する場合に、TEからSVに対して、更新問合要求KREQを送信する例を示した。ただし、この発明は、ユーザが初めてTEに新たにインストールしようとしているソフトウェアを取得する場合にも適用することができる。
たとえば、ユーザが、SVにアクセスして、新規のソフトウェアを取得する手続を行った場合、TEからSVへ、そのソフトウェアの取得要求を送信する。このソフトウェアは、有償であるか、あるいは無償であるかは問わない。
取得要求を受信したSVは、取得要求のあったソフトウェアの現在のバージョンのファイルを、要求してきたTEに対して送信する。これにより、TEは、そのソフトウェアをダウンロードして、記憶部41に記憶する。
ダウンロード後すぐにインストールを実行する設定がされている場合や、ユーザがダウンロードと同時にインストールをすることを示す指示入力をした場合は、ダウンロードしたバージョンのソフトウェアがそのままインストールされる。
ただし、ダウンロードは完了したが、しばらく時間が経過した後にインストールを実行する場合や、時間をあけてユーザが改めてインストール作業をする場合は、前述の各実施例と同様に、ダウンロードからインストールまでの間にダウンロードされたバージョンのソフトウェアに不具合が見つかり、ソフトウェアの開発者等がインストールを中止させたい場合もある。したがって、しばらく時間が経過した後に、ユーザが新たに導入したソフトウェアのインストールの指示入力をした場合は、図5あるいは図6に示したステップT5から始まる一連の処理を行うようにする。
これにより、ユーザが初めてインストールしようとするソフトウェアについても、インストールの実行前に、サーバに同一のソフトが置かれていることの確認処理を行うことによって、開発者等が不具合を認識して配信を中止したソフトウェアを、ユーザがインストールしてしまうことを防止できる。
Claims (6)
- サーバから配信されるソフトウェアをインストールする情報処理装置であって、
ネットワークを介して、ソフトウェアを記憶したサーバに接続し、情報の送受信を行う通信部と、
前記サーバに記憶されたソフトウェアを、前記通信部によってサーバからダウンロードするダウンロード実行部と、
前記ダウンロードされたソフトウェアを、利用可能な状態にするインストールを実行するインストール実行部と、
前記ダウンロードされたソフトウェアのインストールを開始する前に、前記サーバに、前記ダウンロードされたソフトウェアが存在するか否かを確認することを要求する確認要求部と、制御部とを備え、
前記通信部によって、前記情報処理装置にインストールされるべきソフトウェアを記憶したサーバに接続し、
前記確認要求部が、情報処理装置にダウンロードされたソフトウェアであってかつ情報処理装置でインストールがまだ実施されていないソフトウェアが、前記サーバに存在するか否かを確認するための確認要求を、前記通信部によって前記サーバに送信し、
前記制御部は、前記確認要求部が前記サーバに確認要求をした結果、前記ダウンロードしたソフトウェアが前記サーバに存在しないことを確認した場合には、前記インストール実行部によって、前記ダウンロードされたソフトウェアのインストールを実行させないことを特徴とする情報処理装置。 - 前記ダウンロードされたソフトウェアを記憶する記憶部を備え、
前記確認要求部が前記サーバに確認要求をした結果、前記ダウンロードしたソフトウェアがサーバに存在しないことを確認した場合には、前記制御部は、前記記憶部に記憶された前記ダウンロードしたソフトウェアを消去することを特徴とする請求項1に記載の情報処理装置。 - サーバと、情報処理装置とが、ネットワークを介して接続され、前記サーバに記憶されたソフトウェアを前記情報処理装置に配信するソフトウェア配信システムであって、
前記情報処理装置が、ネットワークを介して、ソフトウェアを記憶したサーバに接続し、情報の送受信を行う通信部と、前記サーバに記憶されたソフトウェアを、前記通信部によってサーバからダウンロードするダウンロード実行部と、前記ダウンロードされたソフトウェアを利用可能な状態にするインストールを実行するインストール実行部と、前記サーバに前記ダウンロードされたソフトウェアが存在するか否かを確認することを要求する確認要求部と、制御部とを備え、
前記サーバが、ソフトウェアを記憶する記憶部と、前記情報処理装置から要求されたソフトウェアを要求してきた情報処理装置に送信するソフトウェア送信部と、前記情報処理装置から前記ダウンロードされたソフトウェアの確認要求を受信する確認要求受信部と、前記確認要求を受信した場合に、前記ダウンロードされたソフトウェアが現在サーバに存在するか否かを確認し、その確認結果を示す確認応答情報を、前記確認要求を送信してきた情報処理装置に返信する確認応答部とを備え、
前記通信部によって、前記情報処理装置にインストールされるべきソフトウェアを記憶したサーバに接続し、
前記ダウンロードされたソフトウェアのインストールを開始する前に、前記確認要求部が、情報処理装置にダウンロードされたソフトウェアであってかつ情報処理装置でインストールがまだ実施されていないソフトウェアが、前記サーバに存在するか否かを確認するための確認要求を、前記通信部によって前記サーバに送信し、
前記確認要求を受信したサーバの確認応答部は、前記ダウンロードされたソフトウェアが、サーバに現在記憶されているか否かを確認し、サーバに記憶されていない場合には、サーバに存在しないことを示す確認応答情報を、確認要求を送信してきた情報処理装置に返信し、
前記制御部が、前記ダウンロードされたソフトウェアがサーバに存在しないことを示す確認応答情報を受信した場合に、前記インストール実行部によって、前記ダウンロードされたソフトウェアのインストールを実行させないことを特徴とするソフトウェア配信システム。 - サーバと、情報処理装置とが、ネットワークを介して接続され、前記サーバに記憶されたソフトウェアを前記情報処理装置に配信するソフトウェア配信方法であって、
前記情報処理装置が、前記情報処理装置にインストールされるべきソフトウェアを記憶したサーバに接続するステップと、
前記情報処理装置が、前記サーバに対して、サーバに記憶された所望のソフトウェアをダウンロードすることを要求するステップと、
前記サーバが、前記要求されたソフトウェアを、要求してきた情報処理装置に送信するステップと、
前記情報処理装置が、サーバから送信されたソフトウェアをダウンロードするステップと、
前記情報処理装置が、すでにダウンロードされたソフトウェアのインストールを開始する前に、前記情報処理装置にダウンロードされたソフトウェアであってかつ情報処理装置でインストールがまだ実施されていないソフトウェアが、前記サーバに存在するか否かを確認するための確認要求を、サーバに送信するステップと、
前記サーバが、前記確認要求を受信した場合、確認要求されたソフトウェアがサーバに現在記憶されているか否かを確認するステップと、
前記確認ステップによって、確認要求されたソフトウェアがサーバに現在記憶されていないことが確認された場合に、サーバが、サーバに存在しないことを示す確認応答情報を、確認要求を送信してきた情報処理装置に返信するステップと、
前記情報処理装置が、前記ダウンロードされたソフトウェアがサーバに存在しないことを示す確認応答情報を受信した場合に、前記ダウンロードされたソフトウェアのインストールを実行しないステップとを有することを特徴とするソフトウェア配信方法。 - 前記情報処理装置が、前記ダウンロードしたソフトウェアがサーバに存在しないことを示す確認応答情報を受信した場合に、前記ダウンロードしたソフトウェアを消去するステップを有することを特徴とする請求項4に記載のソフトウェア配信方法。
- ネットワークを介して、情報処理装置にインストールされるべきソフトウェアを記憶したサーバに接続し、情報の送受信を行う通信機能と、
前記サーバに記憶されたソフトウェアを、前記通信機能によってサーバからダウンロードするダウンロード実行機能と、
前記ダウンロードされたソフトウェアを、利用可能な状態にするインストールを実行するインストール実行機能と、
前記ダウンロードされたソフトウェアのインストールを開始する前に、前記サーバに、情報処理装置にダウンロードされたソフトウェアであってかつ情報処理装置でインストールがまだ実施されていないソフトウェアが存在するか否かを確認するための確認要求を送信する確認要求機能と、
前記確認要求機能によって前記サーバに確認要求をした結果、前記ダウンロードしたソフトウェアが前記サーバに存在しないことを確認した場合には、前記インストール実行機能によって、前記ダウンロードされたソフトウェアのインストールを実行させないようにする制御機能とを、コンピュータに実現させるためのプログラム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014203095 | 2014-10-01 | ||
JP2014203095 | 2014-10-01 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2016071879A JP2016071879A (ja) | 2016-05-09 |
JP6581859B2 true JP6581859B2 (ja) | 2019-09-25 |
Family
ID=55864882
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015183041A Active JP6581859B2 (ja) | 2014-10-01 | 2015-09-16 | 情報処理装置、ソフトウェア配信システム、およびソフトウェア配信方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6581859B2 (ja) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6786942B2 (ja) * | 2016-08-08 | 2020-11-18 | 富士ゼロックス株式会社 | 情報処理装置及びプログラム |
JP6773980B2 (ja) * | 2017-04-07 | 2020-10-21 | 富士通クライアントコンピューティング株式会社 | 情報処理装置、情報処理方法、及び、情報処理プログラム |
JP2019062316A (ja) * | 2017-09-25 | 2019-04-18 | 東芝ライテック株式会社 | 家電制御システム |
US10776096B2 (en) * | 2018-01-12 | 2020-09-15 | Blackberry Limited | Method and system for controlling software updates on a network connected device |
JP2019133253A (ja) * | 2018-01-29 | 2019-08-08 | 富士通フロンテック株式会社 | 資源配付方法及び資源配付システム |
JP7506488B2 (ja) | 2020-02-25 | 2024-06-26 | 東芝テック株式会社 | 情報処理装置、情報処理システム及びプログラム |
JP7371585B2 (ja) | 2020-07-28 | 2023-10-31 | トヨタ自動車株式会社 | ソフトウェア更新装置、更新制御方法、更新制御プログラム及びサーバ |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001251525A (ja) * | 2000-03-03 | 2001-09-14 | Canon Inc | 情報処理装置、情報処理方法及びデバイスドライバプログラムを格納した記憶媒体 |
JP5063746B2 (ja) * | 2010-06-11 | 2012-10-31 | 株式会社ソニー・コンピュータエンタテインメント | 情報処理装置 |
JP2013105187A (ja) * | 2011-11-10 | 2013-05-30 | Murata Mach Ltd | 中継通信システム、中継サーバ及び中継通信方法 |
JP6013061B2 (ja) * | 2012-07-23 | 2016-10-25 | 株式会社東芝 | 情報処理装置および制御方法 |
-
2015
- 2015-09-16 JP JP2015183041A patent/JP6581859B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2016071879A (ja) | 2016-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6581859B2 (ja) | 情報処理装置、ソフトウェア配信システム、およびソフトウェア配信方法 | |
US10437680B2 (en) | Relay apparatus, relay method, and computer program product | |
JP5527146B2 (ja) | 端末装置及びプログラム | |
US20150220326A1 (en) | Mobile Terminal and Software Upgrade Method Thereof | |
US20170235566A1 (en) | System and method for efficient software replication | |
CN108780392B (zh) | 程序更新系统、配送装置以及程序更新方法 | |
WO2014018256A1 (en) | Wireless firmware upgrades to an alarm security panel | |
JP2009230399A (ja) | ファームウェア更新システムおよびファームウェア更新プログラム | |
US20160162278A1 (en) | System and method for applying an update to a device system via a system snapshot | |
WO2013168797A1 (ja) | ソフトウェア配信システム、ソフトウェア配信方法 | |
CN103973917A (zh) | 插件分发系统、图像处理设备及插件分发控制方法 | |
CN110580167A (zh) | 一种系统升级方法、智能设备及服务器 | |
WO2019038855A1 (ja) | 車載電子機器、サーバ装置、およびソフトウェア更新方法 | |
CN114040360A (zh) | 服务器、更新管理方法、非临时存储介质、软件更新装置、带服务器及软件更新装置的系统 | |
JP6510446B2 (ja) | 情報処理システム、情報処理装置及び情報処理方法 | |
WO2020044977A1 (ja) | アプリケーションプログラムおよびデータ転送システム | |
JP6622577B2 (ja) | 配信システム、及び配信システムの制御方法 | |
CN113939802A (zh) | 车辆控制装置、更新程序、程序更新系统以及写入装置 | |
JP2007280415A (ja) | 管理装置及びバージョン管理システム及びプログラムバージョン管理方法 | |
US11995429B2 (en) | Software update device, update control method, non-transitory storage medium, and server | |
CN114827127A (zh) | 文件管理方法、系统、云端服务器及终端设备 | |
JP4573181B2 (ja) | モジュール配信方法、プログラム及び配信サーバ | |
JP5407938B2 (ja) | プログラム管理システムおよびプログラム管理方法 | |
US20150205592A1 (en) | System and method for managing application program for terminal | |
US10540169B2 (en) | Electronic device configured to update program stored therein using difference data and program updating method using difference data |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180323 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20181227 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190108 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190305 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190820 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190902 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6581859 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |