JP7278725B2 - プログラム及び情報処理装置 - Google Patents

Description

本発明は、プログラム及び情報処理装置に関する。

インターネット等の通信ネットワークを介して商品を販売するＥＣ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｍｍｅｒｃｅ）サイトやサービスが広く展開されている。この種のサービスでは、通常、ユーザがパーソナルコンピュータやスマートフォン等の端末装置を利用してショッピングサイトにアクセスする。そして、そのサイトが提供する商品のカタログ等がユーザの端末装置に表示される。ここで、ユーザは、表示されたカタログを参照して所望の商品を電子商取引用のショッピングカート（買い物カゴ）に登録した後、決済処理を行い注文することができる。ショッピングサイトを運営している商品販売業者は、ユーザからの注文に従って対応する商品を指定された送り先に発送する。

既製品を注文するサービス以外にも、フォトアルバム作成アプリケーションを使って、ユーザの端末装置でフォトアルバムを作成し、オンライン注文するサービスがある（特許文献１参照）。

特開２０１７－１１７４１０号公報

インターネット等のネットワークを介した注文を行う場合、ネットワークトラブルなどでユーザの端末装置から、商品販売業者のサーバーに必要な情報が送信できない場合がある。このような場合、必要な情報が送信されるまで通信をリトライすることが考えられる。しかしながら、通信が成功するまで何度もリトライを行うと、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを消費してしまう。

そこで、本発明は、ネットワークトラブルなどで一時的にネットワーク通信ができない事象が発生した場合に、適切に通信処理を実行することを目的とする。

本発明の一態様のプログラムは、情報処理装置のコンピュータに、第１のユーザ操作が行われた場合、画像データを用いて所定のデータの編集を行う編集ステップと、前記第１のユーザ操作と異なる種類の第２のユーザ操作が行われた場合、前記編集ステップでの編集を行った後の前記所定のデータを管理サーバーにアップロードするアップロードステップと、前記第１のユーザ操作が行われた場合は第１の通信リトライの条件を設定する一方、前記第２のユーザ操作が行われた場合は第２の通信リトライの条件を設定する設定ステップと、前記第１のユーザ操作が行われた場合は第１の通信を実行する一方、前記第２のユーザ操作が行われた場合は第２の通信を実行する通信ステップと、を実行させるプログラムであって、前記通信ステップにおいて、前記第１の通信が失敗した場合は、前記第１の通信リトライの条件に基づいて、前記第１の通信のリトライが実行される一方、前記第２の通信が失敗した場合は、前記第２の通信リトライの条件に基づいて、前記第２の通信のリトライが実行される、ことを特徴とする。

情報処理システム構成図である。 アルバム作成・注文のフローである。 アルバム作成アプリケーションが提供する表示画面である。 アルバム作成アプリケーションが提供する表示画面の画面遷移を示す模式図である。 アルバム作成アプリケーションの動作を示すフローチャートである。 各種通信ができなかった場合の影響度を示した表である。 通信処理フローと通信パラメータ設定のフローチャートである。 通信パラメータ設定で設定する通信設定を示す表である。 各種通信ができなかった場合の影響度を示した表である。 通信パラメータ設定のフローチャートである。 通信パラメータ設定で設定する通信設定を示す表である。 通信パラメータ設定のフローチャートである。 通信処理フローのフローチャートである。 通信パラメータ設定のフローチャートである。 お知らせ情報取得に関するフローチャートである。 お知らせ情報に関連する表示画面である。 スタンプアップデートに関連する表示画面である。 スタンプアップデートに関するフローチャートである。 各種通信ができなかった場合の影響度を示した表である。

以下、添付図面を参照して本発明の実施形態の詳細を説明する。なお、以下の実施形態は特許請求の範囲に係る本発明を限定するものでなく、また、実施形態で説明されている特徴の組み合わせすべてが本発明の解決手段に必須のものとは限らない。

＜＜第１の実施形態＞＞
第１の実施形態では、ユーザがアルバム作成アプリケーションを用いてフォトアルバム（フォトブック）のデータを作成し、発注する場合の例に説明する。

＜システム全体概要＞
まず、図１を用いて、本実施形態に係る情報処理システムについて説明する。情報処理システムは、ユーザが使用する端末であるスマートフォン１００と、フォトアルバムの注文管理及びフォトアルバムの作成を行う会社の管理サーバー１２０、プッシュ通知サーバー１３０と、を有する。これらはインターネット等のネットワーク１３０を介して接続される。

スマートフォン１００には、アルバム作成アプリケーション（以下、単に「アルバム作成アプリ」とも呼ぶ）がインストールされている。このアルバム作成アプリを用いて、ユーザは、写真等の画像データからフォトアルバム（以下、単に「アルバム」とも呼ぶ）のデータを作成することが可能である。なお、本実施形態ではユーザの端末を示す情報処理装置としてスマートフォン１００を例に説明しているが、ＰＣやタブレット端末等でもよい。スマートフォン１００は、インターネット等のネットワーク１１０を介して、管理サーバー１２０にアルバムデータをアップロードしたり、ユーザのアルバム作成アプリ上での操作に関する操作情報を送信したりすることが可能である。

管理サーバー１２０は、スマートフォン１００から送信されたアルバムデータに基づき、決済処理とアルバム作成のための処理を行う。また、操作情報を基に、スマートフォン１００に対して所定の通知を行うかどうかの判定を行う。判定処理の詳細は、図７を用いて後述する。スマートフォン１００に対する通知は、ユーザ単位（スマートフォン単位）で通知を送ることができるものであれば良く、例えばプッシュ通知やＥメールが挙げられる。以下の例では、プッシュ通知を例に説明する。なお、プッシュ通知とは、ユーザの情報処理装置が外部のサーバーと連携してユーザにリアルタイムに情報を通知する通知方式である。プッシュ通知を利用すれば、アプリが起動していない状態でも、プッシュ通知の配信者側はアプリに紐付いた情報をユーザの情報処理装置に通知することができる。例えば、Ａｎｄｒｏｉｄ（登録商標）ＯＳでプッシュ通知を利用するためには、専用のプッシュ通知配信サーバーを利用する方法（Ｆｉｒｅｂａｓｅ Ｃｌｏｕｄ Ｍｅｓｓａｇｉｎｇ （ＦＣＭ））がある。ｉＯＳでプッシュ通知を利用する場合も同様に、専用のプッシュ通知配信サーバーを利用する方法がある（Ａｐｐｌｅ Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（ＡＰＮｓ））。
その他にも、プッシュ通知を可能とする一般的な技術としてＬｏｎｇ ＰｏｌｌｉｎｇやＷｅｂ Ｓｏｃｋｅｔ、Ｓｅｒｖｅｒ－ｓｅｎｔ ｅｖｅｎｔｓ等の技術が知られている。いずれも、プッシュ通知配信者が配信者の意図したタイミングでリアルタイムにユーザの情報処理装置に通知を送ることができる。

管理サーバー１２０は、通知を実施すると判定した場合、プッシュ通知依頼をプッシュ通知サーバー１３０（プッシュ通知配信サーバ）に送信する。プッシュ通知サーバーは、プッシュ通知依頼の内容に従い、指定された端末（スマートフォン１００）にプッシュ通知を送信する。プッシュ通知を受信したスマートフォン１００は、受信したプッシュ通知に従い表示を行う。

＜スマートフォン１００の構成＞
情報処理装置であるスマートフォン１００は、ＣＰＵ１０１と、ＲＯＭ１０３と、ＲＡＭ１０２と、表示装置１０６と、入力装置１０７と、通信装置１０４と、を有し、それぞれがシステムバス１０９により接続される。

ＣＰＵ１０１は、中央演算装置であり、記憶装置１０８、ＲＯＭ１０３、ＲＡＭ１０２等に記憶されているオペレーションシステムプログラム（以下、ＯＳと略す）を実行することによりスマートフォン１００全体の制御を行う。また、ＣＰＵ１０１は、ＲＯＭ１０３やＲＡＭ１０２に記憶されているプログラムを実行することによって、スマートフォン１００の各機能構成を実現したり、情報の演算、加工等を実行したりする。ＲＯＭ１０３は、読み出し専用メモリであり、各プログラムが格納されている。ＲＡＭ１０２は、ランダムアクセスメモリであり、ＣＰＵ１０１のワークメモリとして用いられたり、各種データの一時格納領域として用いられたりする。以下にて説明する各フローチャートの処理は、記憶装置１０８に保存されているアルバム作成アプリのプログラムがＲＡＭ１０２にロードされ、ＲＡＭ１０２のプログラムがＣＰＵ１０１によって実行されることにより実現される。

表示装置１０６は、スマートフォン１００において出力された画像情報を表示する表示部である。入力装置１０７は、スマートフォン１００にユーザが入力を行う際に使用され、例えば、タッチパネルやキーボードなどが挙げられる。記憶装置１０８は、画像データやテンプレートなどを保存する記憶装置であり、例えば、フラッシュメモリやＳＳＤなどが挙げられる。本実施形態では、記憶装置１０８は、後述するアルバム作成アプリを記憶している。

図１では、スマートフォン１００が表示装置１０６、入力装置１０７、記憶装置１０８を含むものとしたが、これに限定されず、これらはスマートフォン１００が備えていなくてもよい。また、これらはスマートフォン１００に接続される外部装置であってもよい。

通信装置１０４は、無線通信回路およびアンテナを含む通信デバイスであり、無線通信回線により公衆網に接続された無線基地局（不図示）と通信可能に接続する。また、公衆網への通信だけでなく、ＩＥＥＥ８０２．１１規格シリーズに準拠した無線ＬＡＮの無線通信方式に従って通信する能力を有してもよい。通信装置１０４は、無線ＬＡＮや公衆網等を介して管理サーバー１２０およびプッシュ通知サーバー１３０と通信可能に接続する。

＜管理サーバー１２０及びプッシュ通知サーバー１３０の構成＞
管理サーバー１２０及びプッシュ通知サーバー１３０は情報処理装置であり、スマートフォン１００と同様のハードウェア構成を備える。具体的には、ＣＰＵ、ＲＡＭ、ＲＯＭ、通信装置、記憶装置、表示装置、入力装置を備え、それぞれシステムバス１０９により接続される。各ハードウェア構成は、スマートフォン１００の構成と同様のため詳細は省略する。ただし、管理サーバー１２０は、複数の情報処理装置から構成されていてもよい。管理サーバー１２０は、通信装置を介してプリンタ（不図示）と接続されており、フォトアルバムの注文を受けて、プリンタへ印刷を指示する。また、管理サーバー１２０は、ネットワークを介してプッシュ通知サーバー１３０と接続されている。プッシュ通知サーバー１３０についても、複数の情報処理装置から構成されていてもよい。

＜フォトアルバムの注文の流れ＞
図２を用いて、フォトアルバムの注文の流れについて簡単に説明する。顧客であるユーザは、スマートフォン１００のアルバム作成アプリを用いて、フォトアルバムデータ２００を作成する。作成したアルバムデータ２００は、インターネット回線等のネットワーク１３０などを介して、管理サーバー１２０に送信される。アルバムデータ２００は、顧客が使用した写真やレイアウト情報、および、製本形態や紙種などの付随する情報を含む。さらに、アルバムの注文に関する注文関連情報（氏名、住所、電話番号、配送先等）も管理サーバーに送信される。管理サーバー１２０では、ネットワークを介してフォトアルバムデータ２００を受信すると、接続されているプリンタへ印刷を指示する。プリンタは、フォトアルバムデータ２００に基づき、紙等のメディアに印刷をし、製本してフォトアルバムを生成する。フォトアルバムが作成されると、注文関連情報に基づいてフォトアルバムは、宅配便などの物理的な配送方法を用いて顧客のもとに届けられる。

フォトアルバム２１０の決済方法は、特に限定されず、フォトアルバムデータ２００を作成して送信した後、電子決済などを用いて決済してもよいし、銀行振り込みなどで決済してもよい。さらに、配送方法も、特に限定されず、顧客がフォトアルバム制作会社に直接出向いて受け取ってもよいし、フォトアルバム制作会社と提携している別の小売フォトアルバム制作会社を経由して配送してもよい。

なお、上述の例では、管理サーバー１２０が直接注文を受け付け、さらにプリンタへの印刷指示を行っているが、本実施形態はこれに限らない。例えば、管理サーバー１２０とは別に注文管理サーバーと印刷管理サーバーが設けられてもよい。この場合、注文管理サーバーが、ユーザからの注文を受け付け、その注文に関する注文関連情報（氏名、住所、電話番号、配送先、ｅｔｃ．）を管理サーバー１２０に送信する。管理サーバー１２０は、別途スマートフォン１００から送信されるフォトアルバムのデータを受信し、注文管理サーバーから送信されたユーザの注文関連情報とフォトアルバムのデータを関連付けて注文情報として管理する。そして、管理サーバー１２０は、フォトアルバムのデータと注文関連情報から構成される注文情報を印刷管理サーバーへ送信する。印刷管理サーバーは、管理サーバー１２０から送信された注文情報を受信する。そして、印刷管理サーバーは、プリンタへフォトアルバムデータに基づく印刷を指示するとともに、作成されたフォトアルバムの配送管理を行う。

＜アルバム作成アプリの操作＞
次にアルバム作成アプリの操作方法について説明する。本実施形態では、記憶装置１０８に保存されたアルバム作成アプリは、表示装置１０６に表示されているアルバム作成アプリのアイコンがユーザによりタップ等の指定されることにより起動する。具体的には、記憶装置１０８に保存されているアルバム作成アプリのプログラムがＲＡＭ１０２にロードされ、ＲＡＭ１０２のプログラムがＣＰＵ１０１によって実行されて、アルバム作成アプリが起動する。

アルバム作成アプリは、フォトアルバムデータ２００を作成するためのアプリケーションであり、例えば、フォトアルバム制作会社が配布するものである。ユーザは、例えば、フォトアルバム制作会社がフォトアルバム作成サービスを提供しているＷｅｂページや、Ｗｅｂページにリンクが張ってあるアプリケーション配信サービスからアプリケーションをダウンロードすることができる。

図３と図４を用いてアルバム作成アプリの各画面と画面遷移について説明する。図３（ａ）～（ｉ）は、アルバム作成アプリケーションが提供する表示画面であり表示装置１０６に表示される。図４はその画面遷移を示した図である。

図３（ａ）に示す画面３１０は、アルバム作成アプリを起動することにより表示される画面であり、アルバムを新規作成するか、アルバムを再編集するかを選択するための画面である。「新しく作る」ボタン３１１が押下されると画面３２０に遷移する。「再編集・再注文はこちら」ボタン３１２が押下されると画面３８０に遷移する。

図３（ｂ）に示す画面３２０は作成するアルバムタイプを選択するための画面である。アルバムの大きさ、用紙の紙種（材質）やページ数等が異なるアルバムタイプを選択することができる。複数列挙されたアルバムタイプの中からいずれかのアルバムタイプの中の「これで作る」ボタン３２１が押下されると、画面３３０に遷移する。

図３（ｃ）に示す画面３３０は、記憶装置１０８等に保存された写真からアルバムに使用する写真を選択するための画面である。画面左側にフォルダリスト３３１、右側に選択中のフォルダ内にある画像リスト３３２が表示される。また、フッター部に「次に進む」ボタン３３３を有し、所定枚数の写真が選択された後に「次に進む」ボタン３３３が押下されると画面３４０に遷移する。

図３（ｄ）に示す画面３４０は、カバー写真選択画面であり、画面３３０で選択された画像のリストである選択画像リスト３４１から表紙画像と裏表紙画像を選択するための画面である。フッター部には「編集を始める」ボタン３４２を有する。表紙及び裏表紙の写真が選択された後に「編集を始める」ボタン３４２が押下されると、表示装置１０６の表示は、画面３５０に遷移する。

図３（ｅ）に示す画面３５０は、アルバム編集画面である。この画面で見開き（２ページ分）のアルバムレイアウト３５１が表示される。ユーザはレイアウトされた画像を確認しながらアルバムの編集を行うことができる。「戻る」ボタン３５２が押下されると、それまでのアルバムの編集内容が自動で保存され、画面３１０に遷移する。「仕上がりを確認する」ボタン３５３が押下されると、画面３６０に遷移する。

図３（ｆ）に示す画面３６０は、プレビュー画面である。プレビュー画面には、選択したアルバムタイプの形状と、レイアウトした写真が反映された、アルバムの完成イメージ３６１が表示される。フッター部には「カートに入れる」ボタン３６２を有する。「カートに入れる」ボタン３６２が押下された場合には、作成されたアルバム情報に基づき、アップロード用のアルバムデータが生成され、管理システムにアップロードされる。アップロードが完了すると画面３７０のようにアップロード完了のメッセージが表示される。「ＯＫ」ボタン３７１を押下された際にはＷｅｂブラウザを起動し、カート画面（不図示）が表示される。アップロード処理の詳細については、図５を用いて説明する。

図３（ｈ）に示す画面３８０は、編集中アルバム選択画面である。編集中アルバム選択画面には編集中アルバム３８１が列挙される。いずれかのアルバムが選択されると図４（ｉ）画面３９０のように「編集」ボタン３９１と「削除」ボタン３９２が表示される。「編集」ボタン３９１が押下されると画面３５０画面に遷移する。「削除」ボタン３９２が押下されると、選択中のアルバムが削除され、画面３８０に戻る。なお、編集中アルバムは、「編集をはじめる」ボタン３４２を押下して編集を開始したにもかかわらず、画面３６０における「カートに入れる」ボタン３６２を押下する前に操作をやめた場合、編集中アルバムとしてスマートフォン１００に保存される。また、一度カートに入れられた後に、再編集（コピーして編集）し、編集途中のアルバムについても、編集中アルバムとして保存される。これらの編集中アルバムは、画面３８０において編集中アルバム３８１として一覧表示される。つまり、編集中アルバムとは、画像がレイアウトされた後（画像の編集が開始した後）のデータである。よって、編集中アルバムとは、まだ編集が完了していない編集未完了データや、編集完了後のデータも含む。

以上がアルバム作成アプリを用いてアルバムデータを生成する基本的なフローである。なお、図４を示すように、画面３４０において「編集をはじめる」ボタン３４２を指定した後、又は画面３９０において「再編集・再注文はこちら」ボタン３１２を指定した後、アルバム更新情報がスマートフォン１００から管理サーバー１２０へ送信される。さらに、図４には示されていないが、画面３９０において「削除」ボタン３９２が指定された後にもアルバム更新情報がスマートフォン１００から管理サーバー１２０へ送信される。アルバム更新情報の詳細については後述する。

＜アルバムアップロード処理＞
プレビュー画面３６０の「カートに入れる」ボタン３６２を押された後のアプリの処理について、図５のフローチャートで説明する。図５は、アップロード処理のフローを示すフローチャートである。以降、アルバム作成アプリを、各処理の主体として説明することもあるが、実際には、対応するアルバム作成アプリのプログラムをＣＰＵ１０１が実行することで、対応する機能が実現されることになる。なお、全ての処理は必ずしも一つのプロセス上で逐次的に実行されるものではなく、一度ＯＳ側に処理が移り、再度ＯＳから呼び出されるようなケースもあり得る。あくまでアルバム作成アプリの主要な処理を、便宜的にわかりやすく示したフローである。

まず、ステップＳ５０１で、アルバム作成アプリは、ユーザが作成したアルバム情報に基づき、アップロードのためのアルバムデータを作成する。

ステップＳ５０２では、アルバム作成アプリは、ステップＳ５０１の処理が成功したかを判定し、成功の場合はステップＳ５０３へ、失敗の場合はアップロード処理を中断し、ステップＳ５１１へ進む。

ステップＳ５１１では、アルバム作成アプリは、アップロードが失敗した旨のメッセージを記載したメッセージボックスを表示装置１０６に表示する。

ステップＳ５０３では、アルバム作成アプリは、管理サーバー１２０に対し、アルバムアップロードＵＲＬ取得の問合せを行う。具体的には、アルバム作成アプリは、通信装置１０４を介してアップロードＵＲＬを取得するための要求と取得を行う。

ステップＳ５０４では、アルバム作成アプリは、ステップＳ５０３の処理が成功したかを判定し、成功の場合はステップＳ５０５へ、失敗の場合はアップロード処理を中断し、ステップＳ５１１へ進む。

ステップＳ５０５では、アルバム作成アプリは、ステップＳ５０３により取得したＵＲＬ先に、ステップＳ５０１で作成したアルバムデータのアップロード処理を行う。具体的には、アルバム作成アプリは、通信装置１０４を介してアップロード処理を行う。

ステップＳ５０６では、アルバム作成アプリは、ステップＳ５０５の処理が成功したかを判定し、成功の場合はステップＳ５０７へ、失敗の場合はアップロード処理を中断し、ステップＳ５１１へ進む。

ステップＳ５０７では、アルバム作成アプリは、アップロードしたアルバムの決済処理を行うためのＷｅｂサイトのＵＲＬを管理サーバーに問合せ、取得する。具体的には、アルバム作成アプリは、通信装置１０４を介して決済用ＷｅｂサイトＵＲＬを取得するための要求と取得を行う。

ステップＳ５０８では、アルバム作成アプリは、ステップＳ５０７の処理が成功したかを判定し、成功の場合はステップＳ５０９へ、失敗の場合はアップロード処理を中断し、ステップＳ５１１へ進む。

ステップＳ５０９では、アルバム作成アプリは、アップロードが完了した旨のメッセージを記載したメッセージボックス（図３の画面３７０）を表示装置１０６に表示する。画面３７０の「ＯＫ」ボタン３７１が押下されると、Ｓ５０７により取得した決済用Ｗｅｂブラウザを起動し、カート画面が表示される。

ステップＳ５１０では、アルバム作成アプリは、後述するアルバム更新情報の送信を開始する。

＜アルバム更新情報の送信処理とプッシュ通知＞
次に、アルバム更新情報について説明する。本実施形態では、アルバム作成アプリは、アルバムデータの編集開始／再編集のタイミング、削除のタイミング、カート投入のタイミングにおいて、アルバム更新情報を管理サーバー１２０へ送信する。

編集開始／再編集のタイミングとしては、画面３４０の「編集を始める」ボタン３４２の押下と、画面３９０の「編集」ボタン３９１の押下のタイミングがある。各ボタンの押下に応答し、アルバム作成アプリは、アルバム更新情報として、現在の日時情報を管理サーバー１２０に送信する。

削除のタイミングとしては、画面３９０で「削除」ボタン３９２を押下したタイミングがある。「削除」ボタン３９２の押下に応答して、アルバム作成アプリは、削除処理後に残っている編集中アルバムの中で更新日時が最も新しいアルバムの更新日時の情報が、アルバム更新情報として、管理サーバー１２０に送信される。削除処理後に残っている編集中アルバムが無い場合は、アルバム作成アプリは、アルバム更新情報として空文字を管理サーバー１２０に送信する。

カート投入のタイミングとしては、画面３６０の「カートに入れる」ボタン３６２が押下後の画面３７０の表示が行われたタイミングがある。「カートに入れる」ボタン３６２の押下によりアルバムデータのアップロードが終了し、画面３７０が表示されたことに応答して、アルバム作成アプリは、アルバム更新情報として空文字を管理サーバー１２０に送信する。

なお、アルバム作成アプリがアルバム更新情報を管理サーバー１２０に送信する場合、通信処理は表示処理には表れないバックグラウンド処理として行われる。例えば、画面３４０の「編集を始める」ボタン３４２の押下に伴ってアルバム更新情報の送信を開始した場合、その送信の通信が完了せずとも、表示装置１０６の表示自体は、画面３５０に遷移する。よって、アルバム更新情報の通信処理が終わるまでユーザ操作が待機状態に入ることは無い。

スマートフォン１００からアルバム更新情報が送信されると、管理サーバー１２０は、スマートフォン１００から受信したアルバム更新情報をユーザ毎（端末毎）に記録する。つまり、管理サーバー１２０は、アルバム更新情報として日時情報を受信した場合には、その日時を記録し、空文字を受信した場合には空文字を記録する。アルバム更新情報はユーザごとに管理するため、ユーザと紐づけて記録される。

管理サーバー１２０は、定期的にアルバム更新情報が記録された記録領域をチェックし、所定の通知条件を満たすか判定する。具体的には、記録されているアルバム更新情報の日時が所定の期間に達したか判定する。例えば、所定の期間として１０日が設定されている場合、管理サーバー１２０は、毎日、記録領域をチェックし、記録されている更新日時が１０日前の日時であると、所定の期間に達したと判定する。そして、対応するユーザに対してプッシュ通知を行うと決定する。プッシュ通知を行うと決定した場合は、管理サーバー１２０は、プッシュ通知サーバー１３０に、対象のユーザに対するプッシュ通知依頼を送信する。なお、プッシュ通知の内容は、管理サーバー１２０によって設定され、例えば、アルバム更新情報が所定の期間に達したと判定された場合のプッシュ通知は、編集中アルバムが存在することをユーザに知らせるための通知である。管理サーバー１２０は、プッシュ通知依頼を送信した場合には、管理サーバー１２０に記録されている更新情報を日時情報から空文字に更新する。

なお、管理サーバー１２０は、記録領域をチェックした際、記録されている更新日時が空文字の場合は、所定の期間に達したかの判定は行わず、プッシュ通知依頼も送信しない。

プッシュ通知サーバー１３０は、管理サーバー１２０からのプッシュ通知依頼が発行されると、プッシュ通知サーバー１３０からスマートフォン１００にプッシュ通知を行う。スマートフォン１００は、プッシュ通知を受信するとその通知内容を表示する。具体的には、プッシュ通知として「編集中のアルバムが有ります」というメッセージが表示される。プッシュ通知のメッセージは、スマートフォン１００のＯＳが表示する。

ここで、一時的な通信障害などにより、各種通信ができなかった場合について説明する。図６は、通信処理種別ごとに、通信が行われなかった場合の影響度を示した表である。影響度は、各通信が行われなかった場合に生じるユーザの混乱の影響を鑑みて、決定されたものである。なお、この影響度は、アルバム作成アプリの開発者が検討して決定したものであり、条件に応じて変更してもよい。

まず、図６において、Ｎｏ．１～３のアルバムアップロードＵＲＬ取得、アルバムデータアップロード、ショッピングカートＵＲＬ取得に関しては、図５のフローで説明したとおり、各処理が失敗した場合には、エラーメッセージが表示される。つまり、Ｎｏ．１～３の通信処理はアルバム注文のためのメイン処理であり、これらが一時的な通信障害により実行できない場合には、すぐにユーザに通知する必要がある。よって、スマートフォン１００にエラーメッセージを表示しており、ユーザはエラーメッセージにより通信が失敗したことを認識することができる。つまり、ユーザにとっては、アルバムデータ自体のアップロード処理が完了していない事実に対しては通信環境を整える等の動作が必要になるものの、その事実を正確に把握できるため、ユーザを混乱させるという観点での影響は低い。よって、影響度は「低」となっている。

一方、図６において、Ｎｏ．４のアルバム更新情報送信に関しては、バックグランドで行われる送信処理である。よって、送信が失敗してもエラーメッセージは表示されない。そのため、状況によっては適切ではないプッシュ通知が送信されてしまうことがあり、ユーザを混乱させる。例えば、画面３９０の「削除」ボタン３９２が押下され、編集中のアルバムデータが存在しなくなった場合について説明する。この場合、「削除」ボタン３９２押下後にアルバム更新情報として空文字が管理サーバー１２０に送信されなかったら、管理サーバー１２０には、前回送信された日時情報がアルバム更新情報として記録されたままとなる。よって、編集中アルバムが無いにもかかわらず、所定期間経過すると、管理サーバー１２０から「編集中のアルバムが有ります」というプッシュ通知が送信されることがある。このような場合、ユーザはなぜこのような通知が行われるのか分からず混乱する。よって、Ｎｏ．６のアルバム更新情報送信については、影響度は「高」となっている。

＜通信処理フロー＞
次に、図７及び図８を用いて通信処理について説明する。本実施形態の通信処理は、図６の表に基づき、各通信処理の影響度に応じて通信パラメータを変える。図７は通信処理のフローチャートである。以降、アルバム作成アプリを、各処理の主体として説明することもあるが、実際には、対応するアルバム作成アプリのプログラムをＣＰＵ１０１が実行することで、対応する機能が実現されることになる。また、全ての処理は必ずしも一つのプロセス上で逐次的に実行されるものではなく、一度ＯＳ側に処理が移り、再度ＯＳから呼び出されるようなケースもあり得る。あくまでアルバム作成アプリの主要な処理を、便宜的にわかりやすく示したフローである。

まず、図７（ａ）のステップＳ７０１で、アルバム作成アプリは、現在実行しようとしている通信処理（対象の通信処理）の通信条件を設定する。図７（ｂ）に通信条件の設定の詳細処理のフローチャートを示す。ステップＳ７１１で、アルバム作成アプリは、対象の通信処理の種別を確認する。ここで言う通信処理種別とは、図６のＮｏ．１～４の通信処理種別を指す。

ステップＳ７１２では、アルバム作成アプリは、通信処理種別がアルバム更新情報の送信か判定し、アルバム更新情報送信の場合はステップＳ７１３へ、そうでない場合はステップＳ７１４へ進める。

ステップＳ７１３では、アルバム作成アプリは、通信条件を、図８で示す通信設定２に設定する。一方、ステップＳ７１４では、通信条件を、図８で示す通信設定１に設定する。つまり、対象の通信処理が、図６におけるＮｏ．１～３の通信処理種別に該当する場合は、通信設定１に、対象の通信処理が、ＮＯ．４の通信処理種別に該当する場合は、通信設定２に設定される。通信条件の設定が終了したら、図７（ａ）のステップＳ７０２に進む。

ステップＳ７０２では、アルバム作成アプリは、ＲＡＭ１０２に記録されている、通信回数を示すパラメータの値をゼロに設定する。そして、ステップＳ７０３では、対象の通信処理を実行する。なお、アルバム作成アプリが行う通信処理は、スマートフォン１００の通信装置１０４を用いた通信を示す。

ステップＳ７０４では、ステップＳ７０３で実行した通信処理が成功したか判定する。成功した場合は図７のフローを終了し、通信処理が失敗の場合は、ステップＳ７０５に進む。

ステップＳ７０５では、アルバム作成アプリは、通信した回数を記録するパラメータの値に１を足しＲＡＭ１０２に記録する。

ステップＳ７０６では、アルバム作成アプリは、ステップＳ７０５で記録した通信した回数と、ステップＳ７０１で設定した通信設定の通信リトライ回数を比較する。通信した回数が設定されたリトライ回数以下であった場合はステップＳ７０７へ、そうでない場合は図７のフローを終了する。つまり、対象の通信処理が、図６におけるＮｏ．１～３の通信処理種別に該当する場合は、通信設定１のリトライ回数（３回）以下か判定し、３回を超えた場合はフローを終了し、３回以下の場合はＳ７０７へ進む。また、対象の通信処理が、ＮＯ．４の通信処理種別に該当する場合は、通信設定２のリトライ回数（２０回）以下か判定し、２０回を超えた場合はフローを終了し、２０回以下の場合はＳ７０７へ進む。

ステップＳ７０７では、ステップＳ７０１で設定した通信設定のリトライ間隔の時間だけ待機する。設定したリトライ間隔の時間が経過したらステップＳ７０３へ進み、再度通信処理の再試行を行う。つまり、対象の通信処理が、図６におけるＮｏ．１～３の通信処理種別に該当する場合は、通信設定１のリトライ間隔（０．５ｓｅｃ）分だけ待機する。対象の通信処理が、ＮＯ．４の通信処理種別に該当する場合は、通信設定２のリトライ間隔（３ｓｅｃ）分だけ待機する。ステップＳ７０３へ進んだ後は、通信処理を再度実行し、Ｓ７０４以降の処理に進む。

このように、ユーザへの影響度を鑑み、対象の通信処理の通信条件を変更することで、対象の通信処理に応じた通信リトライを実行することが可能となる。これにより、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを大量に消費してしまうことを抑制できる。

なお、上述の例では、影響度により変更する通信パラメータとして、通信リトライ回数とリトライ間隔のみを設定しているが、本実施形態はこれらのみに限定するものではない。例えば、通信パラメータとして、タイムアウト時間やパケットサイズ等の通信パラメータを用いてもよい。また、通信パラメータとして、ＵＤＰ（（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ））かＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）かを示す通信プロトコルの指定を含んでいてもよい。また、ｈｔｔｐかｈｔｔｐｓかを示す通信プロトコルの指定を含んでもよい。

さらに、本実施形態のアルバム作成アプリの表示画面や画面遷移は、図３及び図４に示した例に限定するものではない。例えば、画面３６０で「カートに入れる」ボタン３６２が押下されたことに応答して、プッシュ通知連携のためのカート投入操作としてアルバム更新情報の送信を行ってもよい。そしてその後、スマートフォン１００にはカート画面（不図示）を表示するフローとしても良い。またこの場合、カート画面内に「購入」ボタン設置し、「購入」ボタンを押した後に、実際のアルバムデータのアップロード処理を行い、決済画面に進むフローでもよい。

＜＜第２の実施形態＞＞
次に、第２の実施形態を説明する。本実施形態は、プッシュ通知に関連するアルバム更新情報の送信について、アルバム更新情報送信時のユーザ操作の種類によって通信条件を変える点が第１の実施形態と異なる。本実施形態のシステム構成やハードウェア構成は第１の実施形態と同様であるため省略する。また、各フローについても第１の実施形態と同じ部分は説明を省略し、通信パラメータの設定のように第１の実施形態と異なる部分を主に説明する。

図９（ａ）（ｂ）は、アルバム更新情報送信について、アルバム更新情報送信時のユーザ操作と、アルバム更新情報送信が失敗した場合の影響度との関係を示す表である。

本実施形態では、通信の成否に関わらず、発生する事象が変わらない項目に対しては影響度を「無」に設定する。通信が失敗したことで、単にユーザに通知がされない場合に対しては影響度を「低」に設定する。通信が失敗したことで、ユーザにとって間違ったメッセージではないが、配信者が期待した動作ではないタイミングでメッセージが送信される場合に対しては影響度を「中」に設定する。また、通信が失敗したことで、ユーザにとって、間違った内容のメッセージを通知してしまう場合に対しては影響度を「高」に設定する。以下、まず図９（ａ）について具体的に説明する。

図９（ａ）において、Ｎｏ．１、２は、編集開始／再編集に関するユーザ操作に応じて実行されるはずのアルバム更新情報の送信が行われなかった場合の影響度を示す。編集開始／再編集のタイミングとしては、画面３４０の「編集を始める」ボタン３４２の押下と、画面３９０の「編集」ボタン３９１の押下のタイミングがある。各ボタンの押下に応答し、アルバム作成アプリは、アルバム更新情報として、現在の日時情報を管理サーバー１２０に送信する。Ｎｏ．１とＮｏ．２との違いは、管理サーバー１２０に既にアルバム更新情報として日時情報が記録されているか否かの違いである。

Ｎｏ．１の場合、編集開始／再編集に伴うアルバム更新情報が送信されず、且つ、管理サーバー１２０の記録領域にはアルバム更新情報として日時情報が記録されていない。このような場合、ユーザがアルバムデータの生成を始め、途中で中断した場合でも、管理サーバー１２０の記録領域にはアルバム更新情報として日時情報がない状態となる。そのため、このままの状態では、設定された所定期間が経過しても管理サーバー１２０からプッシュ通知依頼は発行されない。

Ｎｏ．２の場合、編集開始／再編集に伴うアルバム更新情報が送信されず、且つ、管理サーバー１２０の記録領域にはアルバム更新情報として、例えば過去に実行されたユーザ操作に伴う日時情報が記録されている。このような場合、ユーザがアルバムデータの生成を始め、途中で中断した場合、現在の操作に伴うアルバム更新情報は送信されなかったとしても、管理サーバー１２０の記録領域にはアルバム更新情報として過去の日時情報が登録されたままの状態となる。つまり、古い日時情報が記録されたままとなる。そのため、このままの状態では、設定された所定期間が経過するよりも前に、管理サーバー１２０からプッシュ通知依頼が発行されてしまう。

Ｎｏ．１、２のどちらも管理サーバー１２０は実情とは違う判定をすることになるが、ユーザの混乱という意味では、Ｎｏ．２のほうがＮｏ．１より影響が大きい。つまり、Ｎｏ．１はプッシュ通知が届かないだけであり、これによるユーザの混乱は招かないが、Ｎｏ．２の場合、ユーザはまだ編集直後のタイミングで通知が届いてしまう可能性がある。よって、ユーザにとっては煩わしく感じる可能性があるため、影響度はＮｏ．１よりも高い「中」に設定されている。

図９（ａ）において、Ｎｏ．３～６は、削除に関するユーザ操作に応じて実行されるはずのアルバム更新情報の送信が行われなかった場合の影響度を示す。削除のタイミングとしては、画面３９０で「削除」ボタン３９２を押下したタイミングがある。「削除」ボタン３９２の押下に応答して、アルバム作成アプリは、削除処理後に残っている編集中アルバムの中で更新日時が最も新しいアルバムの更新日時の情報が、アルバム更新情報として、管理サーバー１２０に送信される。削除処理後に残っている編集中アルバムが無い場合は、アルバム作成アプリは、アルバム更新情報として空文字を管理サーバー１２０に送信する。

Ｎｏ．３は、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されていない場合を示す。この場合、現在の操作に伴うアルバム更新情報の送信の成否にかかわらず、プッシュ通知が行われないことに変わりはないため、影響度は「無」となる。

Ｎｏ．４は、削除処理後に残っている編集中アルバムがなく、且つ、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されている場合を示す。この場合、ユーザとしては、編集中アルバムがない（画面３８０に表示されるアルバムはない）にもかかわらず、管理サーバー１２０に記録された過去の日時情報に基づき所定期間経過したら「編集中のアルバムがあります」とのプッシュ通知が届く。よって、ユーザを混乱させる可能性が高いため、影響度は「高」となる。

Ｎｏ．５とＮｏ．６はいずれも、削除処理後に残っている編集中アルバムが１以上あり、且つ、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されている場合を示す。ただし、Ｎｏ．５は、ユーザ操作として、更新日時が最も新しい編集中アルバムではないアルバムを削除した場合を示し、Ｎｏ．６は、ユーザ操作として、更新日時が最も新しい編集中アルバムを削除した場合を示す。管理サーバー１２０は、上述したとおり、アルバムごとではなく、ユーザごと（スマートフォン１００ごと）にアルバム更新情報を管理している。よって、管理サーバー１２０はアルバム単位での区別はしておらず、スマートフォン１００から届く最も新しいアルバム更新情報を記録する。そのため、Ｎｏ．５は、現在の操作に伴うアルバム更新情報の送信の成否にかかわらず、プッシュ通知が行われないことに変わりはないため、影響度は「無」となる。一方、Ｎｏ．６は、設定された所定期間が経過するよりも前に、管理サーバー１２０からプッシュ通知依頼が発行される可能性があるため、影響度は「中」となる。

図９（ａ）において、Ｎｏ．７～９は、カート投入に関するユーザ操作に応じて実行されるはずのアルバム更新情報の送信が行われなかった場合の影響度を示す。カート投入のタイミングとしては、画面３６０の「カートに入れる」ボタン３６２が押下後の画面３７０の表示が行われたタイミングがある。「カートに入れる」ボタン３６２の押下によりアルバムデータのアップロードが終了し、画面３７０が表示されたことに応答して、アルバム作成アプリは、アルバム更新情報として空文字を管理サーバー１２０に送信する。

Ｎｏ．７は、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されていない場合を示す。この場合、現在の操作に伴うアルバム更新情報の送信の成否にかかわらず、プッシュ通知が行われないことに変わりはないため、影響度は「無」となる。

Ｎｏ．８は、カート投入後に残っている編集中アルバムが１以上あり、且つ、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されている場合を示す。この場合、設定された所定期間が経過するよりも前に、管理サーバー１２０からプッシュ通知依頼が発行される可能性があるため、影響度は「中」となる。

Ｎｏ．９は、カート投入後に残っている編集中アルバムがなく、且つ、管理サーバー１２０にアルバム更新情報として過去の日時情報が記録されている場合を示す。この場合、編集中アルバムがない（画面３８０に表示されるアルバムはない）にもかかわらず、管理サーバー１２０に記録された過去の日時情報に基づき所定期間経過したら「編集中のアルバムがあります」とのプッシュ通知が届く。よって、ユーザを混乱させる可能性が高いため、影響度は「高」となる。

以上を鑑みると、図９（ａ）において、編集開始／再編集の場合は更新情報の送信に失敗したとしても、影響度は最大でも「中」となる。一方、削除の場合と、カート投入の場合の影響度は最大で「高」となる。よって、本実施形態では、図９（ｂ）に示すように、編集開始／再編集の場合の影響度は「中」、削除とカート投入の場合の影響度は「高」と決定する。つまり、本実施形態では、適切ではないプッシュ通知を減らすために、更新情報送信時のユーザ操作に応じて影響度を決定する。

＜通信処理フロー＞
次に、本実施形態の通信処理について説明する。基本的な通信フローは、第１の実施形態で説明した図７（ａ）と同様であるが、図７（ａ）のステップＳ７０１における通信条件を設定する処理は図１０に示すフローに基づいて実行される。ステップＳ７０１のサブフロー以外は、第１の実施形態のフローと同じ動作をするため、説明を省略する。

図１０では、まず、ステップＳ１００１で、アルバム作成アプリは、通信処理の種別を確認する。これは第１の実施形態で説明した図７（ｂ）ステップＳ７１１と同様の処理である。ステップＳ１００２では、通信処理種別がアルバム更新情報送信かどうか判定し、アルバム更新情報送信の場合はステップＳ１００３へ、そうでない場合はステップＳ１００５へ進める。

ステップＳ１００３では、アルバム作成アプリは、アルバム更新情報送信時のユーザ操作を確認する。本実施形態において、アルバム更新情報送信時のユーザ操作とは、図９（ｂ）の更新情報送信時のユーザ操作の項目に挙げている操作であり、編集開始／再編集、削除、カート投入のいずれかである。

ステップＳ１００４では、アルバム作成アプリは、ステップＳ１００３で確認したユーザ操作に応じて判定処理を行い、編集開始／再編集の場合はステップＳ１００６へ、削除またはカート投入の場合はステップＳ１００７へ進む。

ステップＳ１００５では、アルバム作成アプリは、通信条件の設定を、図１１で示す通信設定２に設定する。ステップＳ１００６では、アルバム作成アプリは、通信条件の設定を、図１１で示す通信設定３に設定する。ステップＳ１００７では、アルバム作成アプリは、通信条件の設定を、図１１で示す通信設定４に設定する。つまり、図９（ｂ）において、影響度が「中」に設定された編集開始／再編集のユーザ操作については、リトライ回数は２０回、リトライ間隔は３ｓｅｃに設定される。図９（ｂ）において、影響度が「高」に設定された削除のユーザ操作と、カート投入のユーザ操作については、リトライ回数は３０回、リトライ間隔は３ｓｅｃに設定される。

その後の処理は、第１の実施形態と同様であり、設定された通信設定に従って、アルバム作成アプリは、通信リトライを実行する。このように、本実施形態においても、ユーザへの影響度を鑑み、対象の通信処理の通信条件を変更することで、対象の通信処理に応じた通信リトライを実行することが可能となる。これにより、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを大量に消費してしまうことを抑制できる。

さらに、本実施形態では、プッシュ通知に関連するアルバム更新情報の送信時のユーザ操作の種類に応じて、影響度を変えている。よって、ユーザ側の操作状況と、ユーザへ送信されるプッシュ通知動作との乖離を減少することができる。

＜第３の実施形態＞
次に第３の実施形態について説明する。本実施形態が第２の実施形態と異なる特徴点は、プッシュ通知に関連するアルバム更新情報送信の通信条件の設定において、ユーザ操作後の編集中のアルバム数と、操作したアルバムの日時と、をさらに判定基準として加える点である。それ以外は、第２の実施形態と同様であるため、説明を省略する。

本実施形態は、図９（ａ）に示す表において、「更新情報送信時のユーザ操作」、「ユーザ操作後の編集中アルバムの数」および「操作したアルバムの日時」に基づき影響度を決定する。つまり、第２の実施形態では、図９（ｂ）に示す３パターンの影響度を考慮して通信条件を決定したが、本実施形態では図９（ａ）を６パターンに分け、各影響度を考慮してより詳細に通信条件を決定する。具体的には、本実施形態では、図９（ａ）に示す削除操作について、さらにＮｏ．４～６の３パターン分け、カート投入操作については、さらにＮｏ．８とＮｏ．９の２パターンに分けて影響度を考慮している。図９（ａ）の各ケースと影響度については、第２の実施形態に記載した説明と同様であるため省略する。

＜通信処理フロー＞
次に、本実施形態の通信処理について説明する。基本的なフローは、第１の実施形態で説明した図７（ａ）と同様であるが、図７（ａ）のステップＳ７０１における通信条件を設定する処理は図１２に示すフローに基づいて実行される。ステップＳ７０１内のサブフロー以外は、第１及び第２の実施形態のフローと同じ動作をするため、説明を省略する。

図１２では、まず、ステップＳ１２０１で、アルバム作成アプリは、通信処理の種別を確認する。これは第１及び第２の実施形態で説明した図７（ｂ）のステップＳ７０１や図１０ステップＳ１００１と同様の処理である。ステップＳ１００２では、アルバム作成アプリは、通信処理種別がアルバム更新情報送信かどうか判定し、アルバム更新情報送信の場合はステップＳ１２０４へ、そうでない場合はステップＳ１２０７へ進める。

ステップＳ１２０３では、アルバム作成アプリは、更新情報送信時のユーザ操作確認を確認する。これは第２の実施形態で説明した図１０ステップＳ１００３と同様の処理である。

ステップＳ１００４では、アルバム作成アプリは、ステップＳ１２０３で確認したユーザ操作に応じて判定処理を行い、編集開始／再編集の場合はステップＳ１２１０へ、削除の場合はステップＳ１２０５へ、カート投入の場合はステップＳ１２０８へ進む。

ステップＳ１２０５では、アルバム作成アプリは、編集中のアルバム数を確認する。なお、編集中のアルバム数とは、ユーザのスマートフォン１００内において、アルバム作成アプリを用いて作成したカート投入前のデータである。具体的には、図３及び図４の画面３４０において「編集をはじめる」ボタン３４２を押下して編集を開始したにもかかわらず、画面３６０における「カートに入れる」ボタン３６２を押下する前に操作をやめた編集後のアルバムがある。このようなデータは、編集中アルバムとしてスマートフォン１００に保存される。また、一度カートに入れられた後に、再編集（コピーして編集）し、編集途中のアルバムについても、編集中アルバムとして保存される。保存された編集中アルバムは、画面３８０において、一覧表示される。

ステップＳ１２０６では、アルバム作成アプリは、ステップＳ１２０５で確認した編集中アルバム数の判定処理を行う。編集中アルバム数がゼロの場合はステップＳ１２１３へ、１以上の場合はステップＳ１２０７へ進む。つまり、削除操作を行った後にもう編集中アルバムが残っていない場合（図９（ａ）のＮｏ．４のケース）はＳ１２１３へ進み、削除操作を行った後にまだ編集中アルバムが残っている場合（図９（ａ）のＮｏ．５、６）のケースはＳ１２０７へ進む。

ステップＳ１２０７では、アルバム作成アプリは、削除操作が行なわれたアルバムの更新日時と、スマートフォン１００内に保存されているその他の編集中アルバムの更新日時とを比較する。削除操作が行われたアルバムの更新日時とは、削除操作が行われたアルバムをアルバムＡとすると、アルバムＡに対して以前編集操作が行われた時の日時を示す。削除操作により、更新日時が最も新しい編集中アルバムを削除した場合はステップＳ１２１２へ、そうではない場合はステップＳ１２１１へ進む。つまり、図９（ａ）のＮｏ．５のケースはＳ１２１１へ、Ｎｏ．６のケースはＳ１２１２へ進む。

なお、本実施形態では削除操作が行なわれた場合、ＲＡＭ１０２に削除操作が行われたアルバムの更新日時を記憶し、ステップ１２０７の処理が終了するまでは保存するものとする。

ステップＳ１２０８では、アルバム作成アプリは、Ｓ１２０５と同様に編集中のアルバム数を確認する。そして、ステップＳ１２０９では、ステップＳ１２０８で確認した編集中のアルバム数の判定処理を行う。編集中アルバム数がゼロの場合はステップＳ１２１３へ、１以上の場合はステップＳ１２１２へ進む。。つまり、カート投入操作を行った後にもう編集中アルバムが残っていない場合（図９（ａ）のＮｏ．９のケース）はＳ１２１３へ進み、カート投入操作を行った後にまだ編集中アルバムが残っている場合（図９（ａ）のＮｏ．８のケース）はＳ１２１２へ進む。

ステップＳ１２１１では、アルバム作成アプリは、通信条件の設定を、図１１で示す通信設定１に設定する。ステップＳ１２１０では、アルバム作成アプリは、通信条件の設定を、図１１で示す通信設定２に設定する。ステップＳ１２１２では、通信条件の設定を、図１１で示す通信設定３に設定する。ステップＳ１２１３では、通信条件の設定を、図１１で示す通信設定４に設定する。

その後の処理は、第１の実施形態及び第２の実施形態と同様であり、設定された通信設定に従って、アルバム作成アプリは、通信リトライを実行する。このように、本実施形態においても、ユーザへの影響度を鑑み、対象の通信処理の通信条件を変更することで、対象の通信処理に応じた通信リトライを実行することが可能となる。これにより、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを大量に消費してしまうことを抑制できる。

さらに、本実施形態では、プッシュ通知に関連するアルバム更新情報の送信時のユーザ操作の種類だけでなく、そのユーザ操作が行われた際のその他の編集中アルバムの状況に応じて、影響度を変えている。これにより、ユーザ側の状況とプッシュ通知動作との乖離をより減少することができる。

＜＜第４の実施形態＞＞
次に第４の実施形態について説明する。本実施形態が第３の実施形態と異なる特徴点は次の２点である。１点目は、端末（スマートフォン１００）上のアプリがプッシュ通知に関連するアルバム更新情報送信を行った際に、管理サーバー１２０が記録している情報またはそれと同等の情報を端末上にも保存する点である。２点目は、通信条件を設定する際に、その端末上の保存した情報を判定基準の１つとする点である。上記２点以外の構成は第３の実施形態と同じであるため、説明を省略する。

本実施形態は、図９（ａ）に示す表において、「更新情報送信時のユーザ操作」、「ユーザ操作後の編集中アルバムの数」、「操作したアルバムの日時」、及び「管理システムに日時が記録されているか」に基づき影響度を考慮して通信条件を決定する。つまり、本実施形態では、図９（ａ）に示す９パターンの場合分けに基づいて通信条件を決定する。図９（ａ）のＮｏ．１～Ｎｏ．９の各ケースと影響度については、第２の実施形態に記載した説明と同様であるため省略する。

＜通信処理フロー＞
次に、本実施形態の通信処理について説明する。本実施形態の基本的な通信処理フローを図１３のフローチャートで示す。なお、図１３において、Ｓ７０１～Ｓ７０７は図７で示したステップと同様であり、Ｓ７０１のサブフローを図１４に示す。つまりステップＳ７０１内のサブフローとステップＳ１３００の処理の有無以外は、第３の実施形態のフローと同じ動作をするため、共通する部分については説明を省略する。

本実施形態では、図１３において、ステップＳ７０４の判定において、ステップＳ７０３で実行した通信処理が成功したと判定された場合、ステップＳ１３００の処理に進む。

ステップＳ１３００では、アルバム作成アプリは、ステップＳ７０３の送信処理がアルバム更新情報の送信であった場合に、送信したアルバム更新情報である日時情報をＵｐｄａｔｅＤａｔｅＴｉｍｅ変数の値としてスマートフォン１００の記憶装置１０８に保存する処理を行う。

次に、図１３のＳ７０１に示すサブフローについて、図１４のフローチャートを用いて説明する。

まず、ステップＳ１３０１で、アルバム作成アプリは、通信処理の種別を確認する。これは第１～第３の実施形態で説明した図７（ｂ）のステップＳ７０１、図１０のステップＳ１００１、図１２ステップＳ１２０１と同様の処理である。ステップＳ１３０２では、アルバム作成アプリは、通信処理種別がアルバム更新情報送信かどうか判定し、アルバム更新情報送信の場合はステップＳ１３０３へ、そうでない場合はステップＳ１３１３へ進める。

ステップＳ１３０３では、アルバム作成アプリは、アルバム更新情報送信時のユーザ操作確認を確認する。これは第２及び第３の実施形態で説明した図１０のステップＳ１００３や図１２のステップＳ１２０３と同様の処理である。

ステップＳ１３０４では、アルバム作成アプリは、ステップＳ１３０３で確認したユーザ操作に応じて判定処理を行い、編集開始／再編集の場合はステップＳ１３０５へ、削除の場合はステップＳ１３０６へ、カート投入の場合はステップＳ１３１０へ進む。

ステップＳ１２０５では、アルバム作成アプリに記録されている更新一時情報であるＵｐｄａｔｅＤａｔｅＴｉｍｅ変数の値を参照し、現在日時に対する経過時間が所定期間内であるかを判定する。所定期間内であればステップＳ１３１５へ、所定期間を超えている場合はステップＳ１３１３へ進む。

ステップＳ１３０６では、アルバム作成アプリは、ステップＳ１２０５と同様にＵｐｄａｔｅＤａｔｅＴｉｍｅが所定期間内かどうかの判定を行う。所定期間内であればステップＳ１３０７へ、所定期間以上経過している場合はステップＳ１３１５へ進む。

ステップＳ１３０７では、アルバム作成アプリは、その時点での編集中のアルバム数を確認する。

ステップＳ１３０８では、ステップＳ１３０７で確認したアルバム数がゼロであるか判定し、ゼロの場合はステップＳ１３１６へ、ゼロでない場合はステップＳ１３０９へ進む。

ステップＳ１３０９では、削除操作を行ったアルバムの更新日時と端末内に記録されている編集中アルバムの更新日時を比較する。削除した編集中アルバムの更新日時が最も新しい日時の場合、すなわち、更新日時が最も新しいアルバムを削除した場合はステップＳ１３１５へ、そうではない場合はステップＳ１３１４へ進む。

なお、図示しないが、本実施形態では削除操作を行う場合、ＲＡＭ１０２に削除したアルバムの更新日時を記憶し、ステップ１３０９の処理が終了するまでは保存するものとする。

ステップＳ１３１０では、ステップＳ１２０５と同様にＵｐｄａｔｅＤａｔｅＴｉｍｅが所定期間内かどうかの判定を行う。所定期間内であればステップＳ１３１１へ、所定期間以上経過している場合はステップＳ１３１５へ進む。

ステップＳ１３１１では、その時点での編集中のアルバム数を確認する。

ステップＳ１３１２では、ステップＳ１３１１で確認したアルバム数がゼロであるか判定し、ゼロの場合はステップＳ１３１６へ、ゼロでない場合はステップＳ１３１５へ進む。

ステップＳ１３１３では、通信条件の設定を、図１１で示す通信設定２に設定する。ステップＳ１３１４では、通信条件の設定を、図１１で示す通信設定１に設定する。ステップＳ１３１５では、通信条件の設定を、図１１で示す通信設定３に設定する。ステップＳ１３１６では、通信条件の設定を、図１１で示す通信設定４に設定する。

その後の処理は、第１の実施形態及び第２の実施形態と同様であり、設定された通信設定に従って、アルバム作成アプリは、通信リトライを実行する。

このように、本実施形態では、ユーザ操作のタイミングにおいて、管理サーバーにアルバム更新情報として日時情報が既に記録されているかを考慮する。管理サーバーに日時情報が既に記録されているかは、図１３のステップＳ１３００で記録したアルバム更新情報により判断する。管理サーバー１２０は、日時情報が所定期間を過ぎている場合は、プッシュ通知依頼を発行し、記録されている日時情報を削除する。よって、アルバム作成アプリは、アプリが記録した日時情報を参照し、現在日時に対する経過時間が所定期間を過ぎる前であれば管理サーバー１２０にも日時情報が記録されていると判定する。一方、アルバム作成アプリは、所定期間以上過ぎているか又はアルバム作成アプリに日時情報が記録されていない場合には、管理サーバー１２０にも日時情報が記録されていないと判定する。

このように、本実施形態においても、ユーザへの影響度を鑑み、対象の通信処理の通信条件を変更することで、対象の通信処理に応じた通信リトライを実行することが可能となる。これにより、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを大量に消費してしまうことを抑制できる。

さらに、本実施形態では、通信処理が成功した場合、送信されたアルバム更新情報をユーザのローカル端末に記録し、次の通信処理の条件設定時に参照する。これにより、ユーザ側の状況とプッシュ通知動作との乖離をより減少することができる。

＜＜第５の実施形態＞＞
次に第５の実施形態について説明する。本実施形態では、プッシュ通知ではなく、アルバム作成アプリの機能に関する通知を行う例について説明する。本実施形態におけるシステム構成、フォトアルバムデータの注文、フォトアルバムアプリの操作、アプリの画面フロー、およびアルバムアップロード処理は第１の実施形態と同じ構成であるため、説明を省略する。
本実施形態では、第１の実施形態では説明していないアルバム作成アプリの機能として、お知らせ機能、スタンプ機能および、スタンプアップデート機能を有する。以下、本実施形態の詳細について説明する。

本実施形態のアルバム作成アプリは、管理サーバー１２０に保存されているお知らせファイルをダウンロードして、スマートフォン１００の表示装置１０６に表示するメッセージ機能を有する。図１５は、管理サーバー１２０からお知らせファイルを取得するフローチャートである。アルバム作成アプリの起動に応じて、図１５の処理が実行される。

ステップＳ１５０１では、アルバム作成アプリは、管理サーバー１２０に保存されているお知らせファイルのリストを、管理サーバーに問合せ、取得する。

ステップＳ１５０２では、アルバム作成アプリは、管理サーバー１２０から取得したお知らせファイルのリストと、ＲＯＭ１０３に記録されているアルバム作成アプリが既に取得済みのお知らせファイルと、を比較する。そして、未取得のファイルがある場合はステップＳ１５０３へ、無い場合はフローを終了する。

ステップＳ１５０３では、アルバム作成アプリは、未取得のお知らせファイルをダウンロードし、ＲＯＭ１０３に記録する。

ステップＳ１５０４では、アルバム作成アプリは、図１６（ａ）に示す、「新しいお知らせがあります」のポップアップメッセージ１６１１を表示し、フローを終了する。

図１６はお知らせに関連する画面表示を示す模式図である。図１６（ａ）は、新しいお知らせファイルが取得されたタイミングで表示されるポップアップメッセージ１６１１が表示された画面である。ユーザが「確認する」ボタン１６１２を押下すると図１６（ｂ）の画面に遷移する。ユーザが「後で確認する」ボタン１６１３を押下すると、ポップアップメッセージ１６１１が閉じて元の画面に戻る。図１６（ｂ）はお知らせリストの画面である。いずれかのお知らせを選択すると、図１６（ｃ）のように選択されたお知らせの本文が表示される。

本実施形態のアルバム作成アプリでは、アルバム編集機能の一つとしてスタンプ機能を有する。スタンプ機能は、予め用意された画像をアルバムの任意の位置に貼り付けることができる機能である。アルバム編集画面３５０において、スタンプボタン３５４が押下されると、図１７（ａ）に示すスタンプ選択画面１７１０が表示される。画面１７１０の左側にスタンプのカテゴリリスト１７１１が、右側に選択されたカテゴリのスランプリスト１７１２が表示される。ユーザがスタンプを選択し、ＯＫボタン１７１３を押下すると、画面３３０にもどり、選択したスタンプがアルバムに貼り付けられた状態になる。このスタンプは、管理サーバー１２０側にカテゴリ毎にまとめて保存されており、不定期に追加されていく。アルバム作成アプリは管理サーバー１２０に問合せ、スタンプがアップデートされたか確認する。

図１８は、アルバム作成アプリがスタンプのアップデートを実行する処理を示すフローチャートである。アルバムアプリがアルバム編集画面３５０に遷移するタイミングで、図１８の処理が実行される。

ステップＳ１８０１では、アルバム作成アプリは、管理サーバー１２０に記録されているスタンプの最終更新日時を取得する。

ステップＳ１８０２では、アルバム作成アプリは、管理サーバー１２０から取得した最終更新日時と、ＲＯＭ１０３に記録されている前回アルバム作成アプリが取得した最終更新日時とを比較する。そして、最終更新日時が前回アップデート確認した日時よりも新しい場合はステップＳ１８０３へ、そうでない場合はフローを終了する。また、取得した最終更新日時をＲＯＭ１０３に記録する。

ステップＳ１８０３では、アルバム作成アプリは、取得できるスタンプのカテゴリリストを取得し、ＲＡＭ１０２に記録する。

ステップＳ１８０４では、アルバム作成アプリは、図１７（ｂ）の「新しいスタンプがダウンロード可能です」のメッセージを含むポップアップメッセージ１７２１を表示する。ポップアップメッセージの中の「今すくダウンロード」ボタン１７２２が押下されると図１７（ｃ）の画面に遷移し、「後でダウンロード」ボタンが押下されるとポップアップメッセージ１７２１の表示が消え、元の画面に遷移する。

図１７（ｃ）の画面では、ポップアップメッセージで「下記のカテゴリのスタンプをダウンロードします」と記載された文章が表示される。またその下に、図１８ステップＳ１８０３で取得したスタンプのカテゴリリストと、ＲＯＭ１０３に保存されているスタンプカテゴリと、を比較した結果、未取得と判定されたスタンプカテゴリのリスト１７３２を表示している。ＯＫボタン１７３３が押下されると、図１７（ｄ）の画面が表示される。キャンセルボタン１７３４が押下されるとポップアップメッセージ１７３１が消え、元の画面に戻る。

図１７（ｄ）はスタンプがＤＬ中であることを示すポップアップメッセージ１７４１が表示された画面である。ダウンロードが終了した場合、またはダウンロード途中でキャンセルボタンＳ１７４２が押下された場合、ポップアップメッセージ１７４１が消え、元の画面が表示される。

ここで、一時的な通信障害などにより、各種通信ができなかった場合の影響度について説明する。図１９は、本実施形態において、各種通信ができなかった場合のユーザへの影響度を示す表である。

アルバムアップロードＵＲＬ取得、アルバムデータアップロード、ショッピングカートＵＲＬ取得、スタンプダウンロードに関しては、失敗した場合エラーメッセージが表示される。よって、ユーザもその状況を認識することができるため、この場合はユーザの混乱は少ないと考えられるため、影響度は「低」と設定されている。

一方、お知らせリスト取得、お知らせダウンロードに関しては、場合によってはサーバー停止情報、障害情報などの重要なお知らせがユーザに伝わらない可能性がある。よって、ユーザの混乱が想定されるため、影響度は「高」と設定されている。

また、スタンプデータ最終更新日時取得、スタンプリスト取得に関しては、取得に失敗した場合、ユーザはスタンプがアップデートされていること自体を知ることができない。よって、影響度は「中」と設定されている。

本実施形態のアルバム作成アプリが行う通信処理のフローは第１の実施形態で説明した図７（ａ）を用いる。ただし、図７（ａ）のステップＳ７０１の通信条件の設定においては、図７（ｂ）を用いずに、図１９の設定を用いる。つまり、図１９において影響度が「低」の通信に対しては図１１の通信設定２を、影響度が「中」の通信に対しては図１１の通信設定３を、影響度が「高」の通信に対しては図１１の通信設定４を設定する処理を行う。その他の処理は第１の実施形態と同様である。

このように、本実施形態においても、ユーザへの影響度を鑑み、対象の通信処理の通信条件を変更することで、対象の通信処理に応じた通信リトライを実行することが可能となる。これにより、リトライ処理自体やそれに伴うバッテリー消費などで端末のリソースを大量に消費してしまうことを抑制できる。

＜他の実施形態＞
上述した実施形態では、アプリとして、写真等の画像データをテンプレートにレイアウト処理し、アルバムデータを生成するアルバム作成アプリについて説明した。しかしながら、本発明はこれに限定されない。例えば、画像データを用いてポスターやはがきのデータを作成するアプリでもよい。つまり、上述の各実施形態は、画像データの編集、削除を実行し、外部のサーバーにアップロード処理する様々なアプリに適用することができる。

上述した各実施形態は、以下の処理を実行することによっても実現される。すなわち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ、ＭＰＵ、ＧＰＵ等）がプログラムを読み出して実行する処理である。また、プログラムは、１つのコンピュータで実行させても、複数のコンピュータで連動させて実行させるようにしてもよい。また、上記した処理の全てをソフトウェアで実現する必要はなく、処理の一部または全部をＡＳＩＣ等のハードウェアで実現するようにしてもよい。また、ＣＰＵも１つのＣＰＵで全ての処理を行うものに限らず、複数のＣＰＵが適宜連携をしながら処理を行うものとしてもよい。

１００ スマートフォン
１２０ 管理サーバー
１３０ プッシュ通知サーバー

Claims (16)

1. 情報処理装置のコンピュータに、
   第１のユーザ操作が行われた場合、画像データを用いて所定のデータの編集を行う編集ステップと、
   前記第１のユーザ操作と異なる種類の第２のユーザ操作が行われた場合、前記編集ステップでの編集を行った後の前記所定のデータを管理サーバーにアップロードするアップロードステップと、
   前記第１のユーザ操作が行われた場合は第１の通信リトライの条件を設定する一方、前記第２のユーザ操作が行われた場合は第２の通信リトライの条件を設定する設定ステップと、
   前記第１のユーザ操作が行われた場合は第１の通信を実行する一方、前記第２のユーザ操作が行われた場合は第２の通信を実行する通信ステップと、
   を実行させるプログラムであって、
   前記通信ステップにおいて、前記第１の通信が失敗した場合は、前記第１の通信リトライの条件に基づいて、前記第１の通信のリトライが実行される一方、前記第２の通信が失敗した場合は、前記第２の通信リトライの条件に基づいて、前記第２の通信のリトライが実行される、
   ことを特徴とするプログラム。
2. 前記第１のユーザ操作が行われた場合に実行される前記第１の通信は、前記管理サーバーに対して、前記第１のユーザ操作に関連する日時情報を送信するための通信であり、
   前記管理サーバーは、前記情報処理装置から送信された前記第１のユーザ操作に関連する日時情報に基づき、所定の通知条件を満たした場合、通知サーバーに通知依頼を発行し、
   前記通知サーバーは、前記情報処理装置に対して前記通知依頼に基づく通知を送信する、
   ことを特徴とする請求項１に記載のプログラム。
3. 前記第１の通信リトライの条件および前記第２の通信リトライの条件は、前記通知サーバーから送信される通知に関する影響度に関連して設定されることを特徴とする請求項２に記載のプログラム。
4. 前記第１の通信リトライの条件における通信リトライ回数よりも、前記第２の通信リトライの条件における通信リトライ回数のほうが多いことを特徴とする請求項１に記載のプログラム。
5. 前記プログラムは、前記コンピュータに、
   第３のユーザ操作が行われた場合、前記編集ステップでの編集を行った後の前記所定のデータを削除する削除ステップをさらに実行させるプログラムであって、
   前記第３のユーザ操作が行われた場合、前記設定ステップでは第３の通信リトライの条件を設定し、かつ、前記通信ステップでは、第３の通信を実行し、前記第３の通信が失敗した場合は、前記第３の通信リトライの条件に基づいて、前記第３の通信のリトライが実行され、
   さらに、前記第１の通信リトライの条件における通信リトライ回数よりも、前記第３の通信リトライの条件における通信リトライ回数のほうが多いことを特徴とする請求項１に記載のプログラム。
6. 前記第２のユーザ操作が行われた後に、前記アップロードされたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されている場合と、前記第２のユーザ操作が行われた後に、前記アップロードされたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されていない場合とで、前記設定ステップで設定される前記第２の通信リトライの条件が異なる、ことを特徴とする請求項１に記載のプログラム。
7. 前記第３のユーザ操作が行われた後に、前記削除されたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されている場合と、前記第３のユーザ操作が行われた後に、前記削除されたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されていない場合とで、前記設定ステップで設定される前記第３の通信リトライの条件が異なる、ことを特徴とする請求項５に記載のプログラム。
8. 前記所定のデータは、アルバムのデータと、ポスターのデータと、はがきのデータとのいずれかである、ことを特徴とする請求項１乃至７のいずれか１項に記載のプログラム。
9. 第１のユーザ操作が行われた場合、画像データを用いて所定のデータの編集を行う編集手段と、
   前記第１のユーザ操作と異なる種類の第２のユーザ操作が行われた場合、前記編集手段での編集を行った後の前記所定のデータを管理サーバーにアップロードするアップロード手段と、
   前記第１のユーザ操作が行われた場合は第１の通信リトライの条件を設定する一方、前記第２のユーザ操作が行われた場合は第２の通信リトライの条件を設定する設定手段と、
   前記第１のユーザ操作が行われた場合は第１の通信を実行する一方、前記第２のユーザ操作が行われた場合は第２の通信を実行する通信手段と、
   を備え、
   前記通信手段は、前記第１の通信が失敗した場合は、前記第１の通信リトライの条件に基づいて、前記第１の通信のリトライを実行する一方、前記第２の通信が失敗した場合は、前記第２の通信リトライの条件に基づいて、前記第２の通信のリトライを実行する、
   ことを特徴とする情報処理装置。
10. 前記第１のユーザ操作が行われた場合に実行される前記第１の通信は、前記管理サーバーに対して、前記第１のユーザ操作に関連する日時情報を送信するための通信であり、
    前記管理サーバーは、前記情報処理装置から送信された前記第１のユーザ操作に関連する日時情報に基づき、所定の通知条件を満たした場合、通知サーバーに通知依頼を発行し、
    前記通知サーバーは、前記情報処理装置に対して前記通知依頼に基づく通知を送信する、
    ことを特徴とする請求項９に記載の情報処理装置。
11. 前記第１の通信リトライの条件および前記第２の通信リトライの条件は、前記通知サーバーから送信される通知に関する影響度に関連して設定されることを特徴とする請求項１０に記載の情報処理装置。
12. 前記第１の通信リトライの条件における通信リトライ回数よりも、前記第２の通信リトライの条件における通信リトライ回数のほうが多いことを特徴とする請求項９に記載の情報処理装置。
13. 前記情報処理装置は、第３のユーザ操作が行われた場合、前記編集手段での編集を行った後の前記所定のデータを削除する削除手段をさらに備え、
    前記第３のユーザ操作が行われた場合、前記設定手段では第３の通信リトライの条件を設定し、かつ、前記通信手段では、第３の通信を実行し、前記第３の通信が失敗した場合は、前記第３の通信リトライの条件に基づいて、前記第３の通信のリトライが実行され、
    さらに、前記第１の通信リトライの条件における通信リトライ回数よりも、前記第３の通信リトライの条件における通信リトライ回数のほうが多いことを特徴とする請求項９に記載の情報処理装置。
14. 前記第２のユーザ操作が行われた後に、前記アップロードされたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されている場合と、前記第２のユーザ操作が行われた後に、前記アップロードされたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されていない場合とで、前記設定手段で設定される前記第２の通信リトライの条件が異なる、ことを特徴とする請求項９に記載の情報処理装置。
15. 前記第３のユーザ操作が行われた後に、前記削除されたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されている場合と、前記第３のユーザ操作が行われた後に、前記削除されたデータとは異なるデータであり且つ前記編集が開始されたデータが前記情報処理装置に保存されていない場合とで、前記設定手段で設定される前記第３の通信リトライの条件が異なる、ことを特徴とする請求項１３に記載の情報処理装置。
16. 前記所定のデータは、アルバムのデータと、ポスターのデータと、はがきのデータとのいずれかである、ことを特徴とする請求項９乃至１５のいずれか１項に記載の情報処理装置。

Images