【事件の表示】
　特願２０１４−５１４９１４「メッセージアカウントの選択的リンク」拒絶査定不服審判事件〔平成２４年１２月１３日国際公開、ＷＯ２０１２／１７０９７２、平成２６年　７月１７日国内公表、特表２０１４−５１７４１６、請求項の数（１０）〕について、次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は、特許すべきものとする。
【理　由】
第１　手続の経緯
　本願は、２０１２年（平成２４年）６月９日（パリ条約による優先権主張外国庁受理２０１１年（平成２３年）６月１０日、米国）を国際出願日とする出願であって、平成２８年５月１３日付けで拒絶理由が通知され、平成２８年８月１６日付けで手続補正がされ、平成２８年９月２日付けで拒絶査定（原査定）がされ、これに対し、平成２９年１月５日に拒絶査定不服審判の請求がされると同時に手続補正がされたものである。
第２　原査定の概要
　原査定（平成２８年９月２日付け拒絶査定）の概要は次のとおりである。
１．本願請求項１−１０に係る発明は、以下の引用文献１−３に基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明できたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
引用文献等一覧
　１．米国特許出願公開第２００８／０１３４２９５号明細書
　２．特開２００９−２１１７０４号公報（周知技術を示す文献）
　３．米国特許出願公開第２０１０／０３１８９２３号明細書（周知技術を示す文献）
第３　本願発明
　本願請求項１−１０に係る発明（以下、それぞれ「本願発明１」−「本願発明１０」という。）は、平成２９年１月５日付けの手続補正で補正された特許請求の範囲の請求項１−１０に記載された事項により特定される発明であり、以下のとおりの発明である。
「【請求項１】
　ユーザデバイスにおいてメッセージアカウントにアクセスする方法であって、
　前記ユーザデバイスにおいて複数のメッセージアカウントを提供するステップであって、前記複数のメッセージアカウントは、少なくとも第１のメッセージアカウント、第２のメッセージアカウント、第３のメッセージアカウント及び第４のメッセージアカウントを含む、ステップと、
　前記第１のメッセージアカウントと前記第２のメッセージアカウントとを選択するユーザ入力を受信するステップと、
　前記第１のメッセージアカウントと前記第２のメッセージアカウントとをリンクして、第１の結合メッセージボックスを作成するステップと、
　前記第３のメッセージアカウントと前記第４のメッセージアカウントとを選択するユーザ入力を受信するステップと、
　前記第３のメッセージアカウントと前記第４のメッセージアカウントとをリンクして、第２の結合メッセージボックスを作成するステップと、
　前記第１の結合メッセージボックスを、前記第１のメッセージアカウントと前記第２のメッセージアカウントとの双方からのメッセージのリストとして表示するステップと、
　前記第２の結合メッセージボックスを、前記第３のメッセージアカウントと前記第４のメッセージアカウントとの双方からのメッセージのリストとして表示するステップと、
　を含み、前記第１及び第２の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能であり、前記第１の結合メッセージボックスに関連付けられる第１のアイコン及び前記第２の結合メッセージボックスに関連付けられる第２のアイコンが、前記ユーザインタフェース上に同時に表示可能である、方法。
　　【請求項２】
　前記第１、第２、第３及び第４のメッセージアカウントは、電子メールアカウント、テキストメッセージアカウント、ソーシャルネットワークメッセージインボックス又はインスタントメッセージアカウントのうちの１つであり、
　前記第１及び第２の結合メッセージボックス内のメッセージは、時系列順に順序付けされて表示される、
　請求項１に記載の方法。
　　【請求項３】
　前記第１、第２、第３又は第４のメッセージアカウントのうちの少なくとも１つを、前記第１又は第２の結合メッセージボックスのうちの少なくとも一方でリンクさせるために、メッセージアカウントのリストから選択するのに使用可能な前記ユーザインタフェースを提供するステップ
　を更に含む、請求項１又は２に記載の方法。
　　【請求項４】
　前記第１のメッセージアカウントは第１のサービスプロバイダに関連付けられ、前記第２のメッセージアカウントは第２のサービスプロバイダに関連付けられる、
　請求項１乃至３のいずれかに記載の方法。
　　【請求項５】
　前記第１又は第２の結合メッセージボックスの少なくとも一方に名前を割り当てるステップを更に含む、
　請求項１乃至４のいずれかに記載の方法。
　　【請求項６】
　前記第１のアイコン及び前記第２のアイコンはそれぞれ、該アイコンに関連付けられる結合メッセージボックスの名前と、該アイコンに関連付けられる結合メッセージボックスを作成するようリンクされるメッセージアカウントの一方の名前と、該アイコンに関連付けられる結合メッセージボックスを作成するようリンクされるメッセージアカウントにおけるメッセージの数の合計を表す数と、のうちの１つ又は複数の表示を含む、
　請求項１乃至５のいずれかに記載の方法。
　　【請求項７】
　前記第１、第２、第３又は第４のメッセージアカウントのうちの１つをリンク解除するユーザ入力を受信したことに基づいて、対応するメッセージアカウントをリンク解除するステップを更に含む、
　請求項１乃至６のいずれかに記載の方法。
　　【請求項８】
　プロセッサによって実行されると、該プロセッサに、請求項１乃至７のいずれかに記載の方法を実行させるコンピュータプログラム。
　　【請求項９】
　メッセージアカウントを選択的にリンクすることが可能なデバイスであって、
　プロセッサと、
　コンピュータプログラムを格納するメモリと、
　を備え、
　前記コンピュータプログラムは、前記プロセッサによって実行されると、前記プロセッサに、
　　前記デバイスにおいて複数のメッセージアカウントを提供するステップと、
　　前記複数のメッセージアカウントのうちの第１のサブセットを識別する、受信したユーザ入力に基づいて、前記複数のメッセージアカウントの前記第１のサブセットをリンクして第１の結合メッセージボックスを作成するステップであって、該第１の結合メッセージボックスは、前記複数のメッセージアカウントのうちの前記第１のサブセット内のメッセージアカウントの各々からのメッセージを含む、ステップと、
　　前記複数のメッセージアカウントのうちの第２のサブセットを識別する、受信したユーザ入力に基づいて、前記複数のメッセージアカウントの前記第２のサブセットをリンクして第２の結合メッセージボックスを作成するステップであって、該第２の結合メッセージボックスは、前記複数のメッセージアカウントのうちの前記第２のサブセット内のメッセージアカウントの各々からのメッセージを含む、ステップと、
　を実行させ、前記第１及び第２の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能であり、前記第１の結合メッセージボックスに関連付けられる第１のアイコン及び前記第２の結合メッセージボックスに関連付けられる第２のアイコンが、前記ユーザインタフェース上に同時に表示可能である、デバイス。
　　【請求項１０】
　プロセッサによって実行されると、該プロセッサに結合メッセージボックスを提供する方法を実行させるコンピュータプログラムであって、前記方法が、
　複数のメッセージアカウントのリストを表示するステップと、
　リンクすべき第１のメッセージアカウントを選択するユーザ入力を受信するステップと、
　リンクすべき第２のメッセージアカウントを選択するユーザ入力を受信するステップと、
　前記第１のメッセージアカウントと前記第２のメッセージアカウントとをリンクして、第１の結合メッセージボックスを作成するステップと、
　リンクすべき第３のメッセージアカウントを選択するユーザ入力を受信するステップと、
　リンクすべき第４のメッセージアカウントを選択するユーザ入力を受信するステップと、
　前記第３のメッセージアカウントと前記第４のメッセージアカウントとをリンクして、第２の結合メッセージボックスを作成するステップと、
　前記第１及び第２の結合メッセージボックスの少なくとも一方に名前を割り当てるステップと、
　前記第１の結合メッセージボックスを、前記第１のメッセージアカウントと前記第２のメッセージアカウントの双方からのメッセージのリストとして表示するステップと、
　前記第２の結合メッセージボックスを、前記第３のメッセージアカウントと前記第４のメッセージアカウントの双方からのメッセージのリストとして表示するステップと、
　を含み、前記第１及び第２の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能であり、前記第１の結合メッセージボックスに関連付けられる第１のアイコン及び前記第２の結合メッセージボックスに関連付けられる第２のアイコンが、前記ユーザインタフェース上に同時に表示可能である、コンピュータプログラム。」
第４　引用文献、引用発明等
１．引用文献１について
　原査定の拒絶の理由に引用された引用文献１には、図面とともに次の事項が記載されている。
（１）「[0016] A user may have various different user accounts for different interactions via a network. For instance, a user may have a “Work” account to access business related e-mail and services and a “Personal” account to interact with friends and family via instant messaging, e-mail, forums, to access Internet content, and so forth. However, in order to access different accounts for different interactions using traditional account log-in techniques, the user may have to a “sign-off” from one account and then provide additional sign-in credentials to “sign-in” to another account, which may be time consuming and frustrating for the user.
[0017] Accordingly, authenticating linked accounts techniques are described in which an interface can be exposed to permit a user to link together a plurality of accounts, such that authentication to one of the linked accounts provides access to each linked account. In an implementation, a client interacts with an authentication service to indicate which accounts are to be linked. The authentication service may expose one or more interfaces through which a client may specify accounts to link (or de-link), and which causes the authentication service to store data describing the link. For example, a user may choose to link the “Work” account and the “Personal” account, and the authentication service can then store account linking data to describe the link, such as a unique link identifier matched to account identifiers for the “Work” account and the “Personal” account.
[0018] When a user or client is authenticated via the authentication service to one account in a set of linked accounts, the corresponding authentication data may include account linking data to reference the linked accounts. For instance, if a user provides valid credentials for the “Work” account, the authentication service can form authentication data, such as an authentication token, which may be used as proof of identity to the “Work” account. The authentication data (e.g., the token) may also include data to reference the linked accounts, such as the unique link identifier. When the user presents an authentication token to access services from one or more service providers, the service providers may utilize a link identifier included in the authentication token to identify linked accounts and to provide interactions with services corresponding to each linked account, based upon client authentication to the one account. Thus, the user may perform a single “sign-in” to the “Work” account, and based on the account linking, may receive access to each linked account (e.g., may interact with services and content corresponding to the “Work” account and the “Personal” account).」（段落［００１６］−［００１８］）
（当審訳：
［００１６］ユーザは、ネットワークを介して他の相互作用のために、様々な異なるユーザアカウントを有していてもよい。例えば、ユーザは、ビジネス関連の電子メール及びサービスにアクセスするための「ワーク」アカウント、並びに、インスタントメッセージング、電子メール、フォーラム、インターネットコンテンツへのアクセスを介して友人及び家族と対話するための「パーソナル」アカウントを有していてもよい。しかしながら、伝統的なアカウントログイン技術を用いて異なる相互作用のための異なるアカウントにアクセスするために、ユーザは、１つのアカウントから「サインオフ」し、次に別のアカウントに「サインイン」するために付加的なサインイン証明を提供しなくてはならず、これはユーザにとって時間がかかり、苛立たしいことかもしれない。
［００１７］したがって、
リンクされたアカウントを認証する技術は、リンクされたアカウントの１つへの認証によって、リンクされたアカウントそれぞれへのアクセスを提供するよう、ユーザに複数のアカウントを一緒にリンクすることを許すために公開させることができるインターフェイスとして記載される。実装において、クライアントは、どのアカウントがリンクされるかを示すために認証サービスと対話する。認証サービスは、クライアントがリンク（又は切り離し）するためにアカウントを特定し、これによって認証サービスにリンクを記述するデータを記憶させる、１又は複数のインターフェースを公開するようにすることができる。
ユーザが「ワーク」アカウントと「パーソナル」アカウントをリンクするように選択してもよく、認証サービスは、「ワーク」アカウント及び「パーソナル」アカウントの識別子のアカウントに合わせた固有のリンク識別子のようなリンクを記述するアカウントリンクデータを記憶することができる。
［００１８］ユーザ又はクライアントがリンクされたアカウントの組の１つのアカウントへの認証サービスを介して認証されると、対応する認証データは、リンクされたアカウントを参照するアカウントリンクデータを含むことができる。例えば、ユーザは、「ワーク」アカウントの有効な証明を提供した場合、認証サービスは、「ワーク」アカウントの身元の立証として用いることができる認証トークンのような認証データを形成することができる。認証データ（例えば、トークン）は、固有のリンク識別子のような、リンクされたアカウントを参照するためのデータを含むことができる。
ユーザが１つ又は複数のサービスプロバイダからのサービスにアクセスするために認証トークンを提示すると、サービスプロバイダは、認証トークンに含まれるリンク識別子を利用してリンクされたアカウントを識別し、１つのアカウントへのクライアント認証に基づいて、各リンクされたアカウントに対応するサービスとの対話を提供することができる。これにより、ユーザは、「ワーク」アカウントへのシングル「サインイン」を行うことができ、アカウントのリンクに基づいて、各リンクされたアカウントへのアクセスを受け取ることができる。
（２）「[0041] FIG. 3 depicts a procedure 300 in an exemplary implementation in which a client forms and accesses linked accounts. Interaction with an authentication service is initiated to create a link between a first account and one or more other accounts (block 302). For the purpose of example, assume a user “Bob” has three accounts “Bobwork”, “BobHome”, and “BobAlt” which may be with the same or different service providers 120(m). “Bob” may use these three accounts for different purposes and/or interactions such as one account for work, another for friends and family, and another for internet commerce. It may be convenient for “Bob” to link the separate accounts, such that “sign-in” to one of the accounts may provide access to each account, without further presentation of credentials. In an implementation, an authentication manager 110 module of authentication service 106 depicted in FIG. 2 may include functionality through which a client 102 may specify accounts 112(r) to link together one to another. For instance, authentication manager module 110 may expose a link application programming interface (Link API), or other network 104 interface, through which a client 102 may link accounts. In an implementation, the Link API may be configured according to Simple Object Access Protocol (SOAP) or other suitable communication protocol. To link accounts, a client 102 may access the Link API and designate accounts 112(r) to link, such as by providing account identifiers, account credentials, (user name and password), and so forth for each account to be linked. In response, the Link API may cause account link data 116 data to be formed and/or stored to form a link between the specified accounts 112(r). For example, the Link API may cause account link data 116 to be formed and stored in memory 208 as depicted in FIG. 2 to create a set of linked accounts. Thus, “Bob” may interact with authentication service 106 to specify a link between the three accounts “Bobwork”, “BobHome”, and “BobAlt”. In an implementation, account link data 116 data forming the link between the three accounts “Bobwork”, “BobHome”, and “BobAlt” may include a link identifier 228 matched to account identifiers 220 for each of the “linked” accounts 112(r).」（段落［００４１］）
（当審訳：
［００４１］図３は、クライアントがリンクされたアカウントを形成し、それにアクセスする、例示的な実施形態における手順３００を示す。認証サービスとの相互作用は、第１のアカウントと１又は複数の他のアカウントとの間のリンクを作成するために開始する（ブロック３０２）。例のために、ユーザ「Bob」は、同一又は異なるサービスプロバイダ１２０（ｍ）のものであってもよい３つのアカウント「Bobwork」、「BobHome」、「BobAlt」を有すると仮定する。「Bob」は、１つのアカウントを仕事のために、別のアカウントを友人及び家族のために、別のアカウントをインターネット商取引のために、というように、異なる用途及び／又は相互作用のためにこれら３つのアカウントを使用することができる。複数のアカウントの１つへ「サインイン」は、各アカウントへのアクセスを提供し、証明書のさらなる提示をせずにできるようになるよう、別個のアカウントをリンクすることは、「Bob」にとって便利である。実施形態では、図２に示す認証サービス１０６のモジュールである認証マネージャ１１０は、クライアント１０２が互いをリンクするためにアカウント１１２（ｒ）を指定できる機能を含むことができる。例えば、認証マネージャモジュール１１０は、リンクアプリケーションプログラミングインタフェース（Link API）、又は他のネットワーク１０４インターフェースを公開させて、これを介してクライアント１０２はアカウントをリンクすることができる。実施形態において、リンクＡＰＩはＳＯＡＰ(Simple Object Access Protocol)又は他の適切な通信プロトコルに従って構成することができる。リンクアカウントに対して、クライアント１０２は、リンクＡＰＩにアクセスし、リンクする各アカウントのアカウント識別子、アカウント証明書(ユーザ名とパスワード)等を提供することで、リンクするアカウント１１２（ｒ）を指定することができる。これに応答して、リンクＡＰＩは、指定されたアカウント１１２（ｒ）間のリンクを形成するため、アカウントリンクデータ１１６(ｒ)を形成し及び/又は格納する。例えば、リンクＡＰＩは、リンクされたアカウントのセットを作成するため、図２に示すようにアカウントリンクデータ１１６をメモリ２０８に形成及び格納してもよい。このように、「Bob」は、３つのアカウント「Bobwork」、「BobHome」、「BobAlt」との間のリンクを指定するために、認証サービス１０６と相互作用することもできる。実施形態において、３つのアカウント「Bobwork」、「BobHome」、「BobAlt」の間のリンクを形成するアカウントリンクデータ１１６は、「リンクされた」アカウント１１２（ｒ）ごとのアカウント識別子２２０に適合したリンク識別子２２８を含むことができる。）
（３）「[0046] Data is stored describing a link between a first account and at least one other account (block 404). For example, if Account A is linked with Accounts B and C by a client accessing an exposed Link API, the Link API may respond by creating a database record (e.g., account links data 116) having at least a unique link identifier 228 which is matched to an account identifier 220 for each of accounts A, B, C. Thus, the account identifiers 220 may be used to look-up the corresponding the link identifier 228 and vice versa. Additionally or alternatively, a unique link identifier 228 may be stored with account data 114 for each account A, B, C and the link between the accounts may be determined by matching the link identifier 228 for each account.」（段落［００４６］）
（当審訳：
［００４６］データは第１のアカウントと、少なくとも１つの他のアカウントとの間のリンクを記述するもので、格納される（ブロック４０４）。例えば、アカウントＡが、クライアントが公開されたリンクＡＰＩにアクセスすることによって、アカウントＢ及びＣとリンクされると、リンクＡＰＩは、アカウントＡ、Ｂ、Ｃのそれぞれのアカウント識別子２２０に適合する固有のリンク識別子２２８を少なくとも有するデータベースレコード（例えば、アカウントリンクデータ１１６）を生成することによって応答することができる。このように、アカウント識別子２２０は、対応するリンク識別子２２８と、その逆を参照するために用いられる。追加的または代替的に、固有なリンク識別子２２８は、各アカウントＡ、Ｂ、Ｃについてのアカウントデータ１１４とともに格納されてもよく、アカウント間のリンクは、各アカウントのリンク識別子２２８との一致によって決定することができる。）
（４）「[0049] FIG. 5 depicts a procedure 500 in an exemplary implementation in which authentication service exposes one or more interface to manage authentication to linked accounts. A plurality of link identifiers are stored, each link identifier corresponding to a plurality of account identifiers to form a respective set of linked accounts (block 502). One or more interfaces are exposed to manage authentication of a client to the set of linked accounts, such that the client upon providing credentials corresponding to one account in the set of linked accounts, receives access to each account in the set of linked accounts (block 504). For example, a variety of interfaces are contemplated which may be incorporated with an authentication service 106 to manage linked accounts and authentication to linked accounts. The one or more interfaces may be implemented via one or more of the authentication manager 110, linked account manager 214, service provider interface 216 of FIG. 2, and/or as stand alone modules. For example, the one or more interfaces may include functionality to link accounts, such as the Link API previously described may be incorporated with the linked account manager 214 of FIG. 2. Another example of functionality which may be provided by the one or more interfaces is functionality to de-link accounts. For instance, the de-linking functionality may be integrated with the Link API or may be implemented as a separate module of the linked account manager 214 or authentication service 106, such as a De-Link API. A client 102 accessing the De-Link API may indicate or select one or more linked accounts to remove from a set of linked accounts. De-Link API may respond by removing the associated account identifiers 220 from account linking data 116 corresponding to the set of linked accounts. The de-linked account or accounts may then be used as separate accounts, without the linking feature.」（段落［００４９］）
（当審訳：
［００４９］図５は、認証サービスが、リンクされたアカウント認証を管理するための１つ又は複数のインターフェースを公開する、例示的な実施形態における手順５００を示す。
複数のリンク識別子が格納されており、各リンク識別子は、リンクされたアカウントのそれぞれの組を形成するため、複数のアカウント識別子に対応する
（５）「[0057] FIG. 7 illustrates an exemplary implementation 700 of a user interface 236 of FIG. 2 that may be generated for client interaction with linked accounts. The user interface 236 provided by the service provider 120(m) in this instance is illustrated as incorporated within a user interface 702 for a communication module 108 of a client 102. 
・・・（中略）・・・
[0058] The address bar 706 shows communication module 108 directed to a service provider 120(m) specifically “websuite.com”. Websuite.com may be configured to provide a suite of services as previously discussed with respect to FIG. 1. In the implementation 700 of FIG. 7, interface 236 is depicted as email page for an email 124(2) service which may be provided by a service provider 120(m), e.g., websuite.com. The interface 236 may display email for multiple accounts 112(r) based upon the accounts 112(r) being linked as described herein. The interface includes an inbox 708 portion for listing of email messages and a display portion 710 to display a selected message. In an implementation, the inbox 708 may include e-mail messages from a plurality of linked accounts. In the illustrated example, assume a user “Adam” has accounts “AdamWork@websuite.com” and “AdamHome@websuite.com”, which have been linked such as via Link API exposed by authentication service 106. The interface 236 has portions 712(1), 712(2) each corresponding to a one of the linked accounts. Each of portions 712(1), 712(2) displays data corresponding to their respective accounts such as the account name, email messages, a user tile (e.g., factory image for “AdamWork” and house image for “AdamHome”); and so forth. In an implementation, a portion 714 may be provided which is selectable to manage linked accounts, such as to access a Link APT（当審注：「Link API」の誤記と認める。） or De-Link API to manage which accounts are linked.
[0059] Referring to FIG. 8 an exemplary embodiment 800 of another user interface for client interaction with linked accounts is shown. In this embodiment a user interface 236 configured for email is again shown, however separate portions for displaying email messages corresponding to each linked accounts are not provided. Rather, the messages are displayed together in a common inbox portion 802. The interface 236 may also include a portion 804 which indicates the set of linked accounts, in the depicted instance “AdarnIome”（当審注：“AdamHome”の誤記と認める。）, “AdamWork” and “Adam@isp.com”. A respective user tile 806 or other identifier for each account may also be displayed in the user interface 236 to visually identify the accounts. For instance, the factory image corresponding to “AdamWork” is displayed in the portion 804 with the listed account name, and is also displayed with each corresponding message in the inbox 802 portion. The same is true for the house and globe images corresponding to “AdamHome” and “Adam@isp.com” respectively. A variety of other arrangements of user interfaces 236 to provide interactions with linked accounts and corresponding services 124(s) are also contemplated.」（段落［００５７］−［００５９］）
（当審訳：
［００５７］図７は、リンクされたアカウントへのクライアントの相互作用のために生成することができる図２のユーザインターフェース２３６の例示的な実装７００を示す図である。ここでサービスプロバイダ１２０（ｍ）によって提供されるユーザインターフェース２３６は、クライアント１０２の通信モジュール１０８のユーザインターフェース７０２内に組み込まれたものとして示されている。
・・・（中略）・・・
［００５８］アドレスバー７０６は、サービスプロバイダ１２０（ｍ）、具体的には「websuite.com」に対する通信モジュール１０８を示している。Websuite.comは、図１を参照して上述したようにサービスの組を提供するように構成することができる。図７の実施例７００において、インタフェース２３６は、サービスプロバイダー１２０（ｍ）によって提供することができる電子メール１２４（２）サービス、例えば、websuite.com用の電子メールページとして示されている。インターフェース２３６は、本明細書で説明するようにリンクされているアカウント１１２（ｒ）に基づいて、複数のアカウント１１２（ｒ）のための電子メールを表示してもよい。インターフェースは、電子メールメッセージを一覧するための受信箱７０８部分と、選択されたメッセージを表示する表示部７１０を備えている。実施態様では、受信箱７０８は、リンクされた複数のアカウントからの電子メールメッセージを含むことができる。図示の例では、ユーザ「Adam」は、認証サービス１０６によって公開されたリンクＡＰＩ等を介してリンクされた、アカウント「AdamWork@websuite.com」および「AdamHome@websuite.com」を有している。インターフェース２３６は、それぞれがリンクされたアカウントの１つに対応する部分７１２（１）及び７１２（２）を有している。部分７１２（１）、７１２（２）のそれぞれは、アカウント名、電子メールメッセージ、ユーザタイル（例えば、「AdamWork」の工場の画像と「AdamHome」の家の画像)等のそれぞれのアカウントに対応するデータが表示される。一実施態様では、部分７１４は、どのアカウントがリンクされているかを管理するリンクＡＰＩ又は切り離しＡＰＩにアクセスする等、リンクされたアカウントを管理するために、選択可能に提供されてもよい。
［００５９］図８を参照して、
リンクされたアカウントへのクライアントの相互作用のための
ユーザインターフェースの例示的実施形態８００
各リンクされたアカウントに対応する電子メールメッセージを表示するための別々の部分は設けられていない。そうではなく、メッセージは、共通の受信箱部８０２に表示されている。インターフェース２３６は
、リンクされたアカウントの組を表示する部分８０４、図示例では「AdamHome」、「AdamWork」および「Adam@isp.com」を含むことができる。
　上記下線部の記載によれば、引用文献１には次の発明（以下、「引用発明」という。）が記載されていると認められる。
「リンクされたアカウントを認証する技術は、リンクされたアカウントの１つへの認証によって、リンクされたアカウントそれぞれへのアクセスを提供するよう、ユーザに複数のアカウントを一緒にリンクすることを許すために公開させることができるインターフェイスとして記載され、実装において、クライアントは、どのアカウントがリンクされるかを示すために認証サービスと対話し、認証サービスは、クライアントがリンク（又は切り離し）するためにアカウントを特定し、これによって認証サービスにリンクを記述するデータを記憶させ、１又は複数のインターフェースを公開するようにすることができ、例えば、ユーザが「ワーク」アカウントと「パーソナル」アカウントをリンクするように選択してもよく、認証サービスは、「ワーク」アカウント及び「パーソナル」アカウントの識別子のアカウントに合わせた固有のリンク識別子のようなリンクを記述するアカウントリンクデータを記憶することができ、
　複数のリンク識別子が格納されており、各リンク識別子は、リンクされたアカウントのそれぞれの組を形成するため、複数のアカウント識別子に対応し、
　ユーザが１つ又は複数のサービスプロバイダからのサービスにアクセスするために認証トークンを提示すると、サービスプロバイダは、認証トークンに含まれるリンク識別子を利用してリンクされたアカウントを識別し、１つのアカウントへのクライアント認証に基づいて、各リンクされたアカウントに対応するサービスとの対話を提供することができ、これにより、ユーザは、「ワーク」アカウントへのシングル「サインイン」を行うことができ、アカウントのリンクに基づいて、各リンクされたアカウントへのアクセスを受け取ることができ、
　リンクされたアカウントへのクライアントの相互作用のためのユーザインターフェースの例示的実施形態８００において、
　各リンクされたアカウントに対応する電子メールメッセージを表示するための別々の部分は設けられておらず、メッセージは、共通の受信箱部８０２に表示されており、
　インターフェース２３６は、リンクされたアカウントの組を表示する部分８０４、図示例では「AdamHome」、「AdamWork」および「Adam@isp.com」を含むことができる、方法。」
２．引用文献２について
　原査定の拒絶の理由に引用された上記引用文献２の段落【００１４】の記載からみて、当該引用文献２には、ユーザインターフェースからＡＰＩを介してアプリケーションにメッセージを提供するという技術的事項が記載されていると認められる。
３．引用文献３について
　原査定の拒絶の理由に引用された上記引用文献３の段落［００９９］及び図５（ａ）の記載からみて、当該引用文献３には、メールアカウントごとに新たに受信したメールの数を表示するという技術的事項が記載されていると認められる。
第５　当審の判断
１．本願発明１について
（１）対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
ア．引用発明の「クライアント」は、本願発明１の「ユーザデバイス」に相当する。
　また、引用発明において、「（クライアントのユーザインターフェースにおいて、）ユーザは、『ワーク』アカウントへのシングル『サインイン』を行うことができ、アカウントのリンクに基づいて、各リンクされたアカウントへのアクセスを受け取ることができ」るものであるから、引用発明の当該構成は、本願発明１の「メッセージアカウントにアクセスする」ことに相当する。
　したがって、本願発明１と引用発明とは、「ユーザデバイスにおいてメッセージアカウントにアクセスする方法」である点で一致する。
イ．引用発明においては、「リンクされたアカウントの組」の例として、「『AdamHome』、『AdamWork』および『Adam@isp.com』」の３つのアカウントが示され、これらリンクされるアカウントは、「リンクされたアカウントを認証する技術は、リンクされたアカウントの１つへの認証によって、リンクされたアカウントそれぞれへのアクセスを提供するよう、ユーザに複数のアカウントを一緒にリンクすることを許すために公開させることができるインターフェイスとして記載され、実装において、クライアントは、どのアカウントがリンクされるかを示すために認証サービスと対話」する構成によって「特定」されるものである。
　そして、引用発明においては、「各リンクされたアカウントに対応する電子メールメッセージを表示するための別々の部分は設けられておらず、メッセージは、共通の受信箱部８０２に表示され」る。
　したがって、本願発明１と引用発明とは、「前記ユーザデバイスにおいて複数のメッセージアカウントを提供するステップであって、前記複数のメッセージアカウントは、少なくとも第１のメッセージアカウント、第２のメッセージアカウントを含む、ステップ」、「前記第１のメッセージアカウントと前記第２のメッセージアカウントとを選択するユーザ入力を受信するステップと、前記第１のメッセージアカウントと前記第２のメッセージアカウントとをリンクして、第１の結合メッセージボックスを作成するステップ」及び「前記第１の結合メッセージボックスを、前記第１のメッセージアカウントと前記第２のメッセージアカウントとの双方からのメッセージのリストとして表示するステップ」を有する点で共通する。
　ここで、引用発明に例示される３つのアカウント「AdamHome」、「AdamWork」および「Adam@isp.com」のいずれか１つが本願発明１の「第１のメッセージアカウント」に、別の１つが本願発明１の「第２のメッセージアカウント」にそれぞれ相当する。
ウ．上記イ．で述べたとおり、引用発明において、リンクされるアカウントは、「リンクされたアカウントを認証する技術は、リンクされたアカウントの１つへの認証によって、リンクされたアカウントそれぞれへのアクセスを提供するよう、ユーザに複数のアカウントを一緒にリンクすることを許すために公開させることができるインターフェイスとして記載され、実装において、クライアントは、どのアカウントがリンクされるかを示すために認証サービスと対話」する構成によって「特定」されるものであるから、本願発明１と引用発明とは、「前記第１の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能であ」る点で共通する。
　したがって、本願発明１と引用発明との間には、次の一致点、相違点があるといえる。
（一致点）
「ユーザデバイスにおいてメッセージアカウントにアクセスする方法であって、
　前記ユーザデバイスにおいて複数のメッセージアカウントを提供するステップであって、前記複数のメッセージアカウントは、少なくとも第１のメッセージアカウント、第２のメッセージアカウントを含む、ステップと、
　前記第１のメッセージアカウントと前記第２のメッセージアカウントとを選択するユーザ入力を受信するステップと、
　前記第１のメッセージアカウントと前記第２のメッセージアカウントとをリンクして、第１の結合メッセージボックスを作成するステップと、
　前記第１の結合メッセージボックスを、前記第１のメッセージアカウントと前記第２のメッセージアカウントとの双方からのメッセージのリストとして表示するステップと、
　を含み、
　前記第１の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能である、方法。」
（相違点１）
　本願発明１の「複数のメッセージアカウント」は、「少なくとも…第３のメッセージアカウント及び第４のメッセージアカウントを含む」ものであり、本願発明１は、「前記第３のメッセージアカウントと前記第４のメッセージアカウントとを選択するユーザ入力を受信するステップ」、「前記第３のメッセージアカウントと前記第４のメッセージアカウントとをリンクして、第２の結合メッセージボックスを作成するステップ」、「前記第２の結合メッセージボックスを、前記第３のメッセージアカウントと前記第４のメッセージアカウントとの双方からのメッセージのリストとして表示するステップ」及び「前記…第２の結合メッセージボックスにおいてリンクされるメッセージアカウントが、前記複数のメッセージアカウントの中から、ユーザインタフェースを介して個々に選択可能であ」るとの構成を有するのに対し、引用発明においては、「リンクされたアカウント」に対応する「リンク識別子」が複数存在することは特定する一方、本願発明１のこれら構成を明示的に特定していない点。
（相違点２）
　本願発明１は、「前記第１の結合メッセージボックスに関連付けられる第１のアイコン及び前記第２の結合メッセージボックスに関連付けられる第２のアイコンが、前記ユーザインタフェース上に同時に表示可能である」との構成を有しているのに対し、引用発明は当該構成を有していない点。
（２）相違点についての判断
　事案に鑑みて、上記相違点２について先に検討する。
　上記「第４　引用文献、引用発明等」で述べたとおり、引用文献２には、ユーザインターフェースからＡＰＩを介してアプリケーションにメッセージを提供するという技術的事項が、引用文献３には、メールアカウントごとに新たに受信したメールの数を表示するという技術的事項が、それぞれ記載されている。
　しかしながら、相違点２に係る本願発明１の構成は、引用文献２−３に記載されておらず、示唆もされていない。
　また、相違点２に係る本願発明１の構成が、本願出願前に周知技術であったとも認められない。
　したがって、相違点１について判断するまでもなく、本願発明１は、当業者であっても引用発明及び引用文献２−３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
２．請求項２−１０について
　本願発明２−８は、本願発明１をさらに限定したものであり、本願発明９及び１０は、本願発明１のカテゴリーを変更したものであるから、いずれも本願発明１と同様に、当業者であっても引用発明及び引用文献２−３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
第６　原査定について
　審判請求時の補正により、本願発明１−１０は「前記第１の結合メッセージボックスに関連付けられる第１のアイコン及び前記第２の結合メッセージボックスに関連付けられる第２のアイコンが、前記ユーザインタフェース上に同時に表示可能である」という事項を有するものとなっており、当業者であっても、拒絶査定において引用された引用文献１−３に基づいて、容易に発明できたものとは認められない。したがって、原査定の理由を維持することはできない。
第７　むすび
　以上のとおり、原査定の理由によっては、本願を拒絶することはできない。
　また、他に本願を拒絶すべき理由を発見しない。
　よって、結論のとおり審決する。