2021-006657

第２ 原査定の概要

原査定（令和３年２月２４日付け拒絶査定）の概要は、次のとおりである。

この出願の請求項１～３，５，６に係る発明は、以下の引用文献１に記載された発明に基いて、また、同請求項４に係る発明は、同引用文献１，２に記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。

第３ 本願発明

本願請求項１～６に係る発明（以下、それぞれ「本願発明１」～「本願発明６」という。）は、令和４年２月２１日に提出された手続補正書により補正された特許請求の範囲の請求項１～６に記載された事項により特定される、次のとおりの発明である（下線は補正箇所を示す。）。

「【請求項１】

パブリッシュ／サブスクライブ型のメッセージの送受信をパブリッシャ又はサブスクライバである複数のクライアント装置との間で行なうサーバ装置において、

前記メッセージの対象である１又は複数のトピックと対応付けられた文字列であるラベルを記憶する記憶部と、

前記クライアント装置から受信した前記メッセージにおけるプロトコル上の１つのフィールドに、前記ラベルを含む制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断する判断部と、

続きを表示（全15行）

該判断部により制御文が含まれていると判断された場合、該制御文に含まれる前記ラベルの解析を行なう解析部と、

解析結果に基づき特定されるラベルに対応するトピックを対象として前記メッセージに対応する処理を実行するメッセージ処理部と

を備えることを特徴とするサーバ装置。

【請求項２】

前記制御文は、ラベルに対する条件式を含み、

前記解析部は、該条件式によりトピックを抽出する抽出部を有し、

前記メッセージ処理部は、抽出されたトピックを対象としてメッセージを送信する

ことを特徴とする請求項１に記載のサーバ装置。

【請求項３】

前記１つのフィールドは、前記メッセージにおけるトピックフィールドである

請求項１又は２に記載のサーバ装置。」

【請求項４】

パブリッシュ／サブスクライブ型のメッセージの送受信により、情報端末装置から制御対象デバイスの動作を制御する制御システムにおいて、

請求項１から請求項３のいずれか１つに記載のサーバ装置を含み、

前記トピックは、前記制御対象デバイスを識別するデバイスのラベルであり、

前記情報端末装置はクライアント装置として、前記制御文を含む前記メッセージを前記サーバ装置へ送信し、

前記メッセージ処理部は、受信した前記メッセージへの前記解析部による解析結果に基づき特定されるラベルに対応するトピックへ前記制御文を含む前記メッセージを発行する

ことを特徴とする制御システム。

【請求項５】

通信部及び記憶部を備えるコンピュータに、パブリッシュ／サブスクライブ型のメッセージの送受信を実行させるコンピュータプログラムにおいて、

前記コンピュータに、

前記メッセージの対象である１又は複数のトピックに対応付けられた文字列であるラベルを記憶させておき、

前記通信部により受信した前記メッセージにおけるプロトコル上の１つのフィールドに、前記ラベルを含む制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断するステップ、

該ステップにより制御文が含まれていると判断された場合、該制御文に含まれる前記ラベルの解析を行なうステップ、及び、

解析結果に基づき特定されるラベルに対応するトピックを対象として前記メッセージに対する処理ステップ

を実行させることを特徴とするコンピュータプログラム。

【請求項６】

パブリッシュパブリッシュ／サブスクライブ型のメッセージの送受信をパブリッシャ又はサブスクライバである複数のクライアント装置との間で行なうサーバ装置における通信方法において、

前記サーバ装置は、

前記メッセージの対象である１又は複数のトピックに対応付けられた文字列であるラベ

ルを記憶しておき、

前記クライアント装置から受信した前記メッセージにおけるプロトコル上の１つのフィールドに、前記ラベルを含む制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断し、

制御文が含まれていると判断された場合、該制御文に含まれる前記ラベルの解析を行ない、

解析結果に基づき特定されるラベルに対応するトピックを対象として前記メッセージに対する処理を行なう

ことを特徴とする通信方法。」

第４ 引用文献の記載、引用発明等

１ 引用文献１

（１）原査定の拒絶の理由にて引用された引用文献１には、図面とともに、次の記載がある（下線は当審による。以下同様。）。

「[0009]Topics are often specified hierarchically, for example using the character string format“root/topicA/topicX”where topicA is one of the available topics in the first level of the hierarchy underneath the root node and topicX is one of the available topics in the second level of the hierarchy underneath topicA, and the‘/’character is a separator between the topic names of the different levels of the hierarchy. FIG. 1 shows a simple topic tree in which the first level of the tree underneath the root node has two topics topicA and topicB, and the second level of the tree underneath topicA has a number of topics topicX, topicY and topicZ. A subscriber SUBSCRIBER1 (SUB.1 in FIG. 1) has subscribed to receive messages published on the topic“root/topicA/topicX”, and their subscription is associated with the respective node of the topic tree. The elements of the topic string within a received message are each compared in turn with the set of nodes at the respective level of the topic tree until a node of the tree is identified that matches the received topic string, or it is determined that there is no match. When a match is identified, the publication is forwarded to the subscribers that have registered to receive publications on that topic (subject to checking any filters based on message properties or message content that has been specified within the particular subscriptions).」

（当審訳： [0009]トピックスはしばしば階層的に特定され、例えば、文字列フォーマット“root/topicA/topicX”を用い、ここで、topicAはルートノードの下の階層の第１のレベルに利用可能なトピックスの一つであり、また、topicXはtopicAの下の階層の第２のレベルにおいて利用可能なトピックスの一つであり、‘/’記号は、階層の異なるレベルのトピック名の間のセパレータである。図１は、ルートノードの下部であるツリーの第１のレベルが、２つのトピックスtopicA及びtopicBを有し、topicAの下部であるツリーの第２のレベルが、いくつかのトピックスtopicX、topicY及びtopicZを有している、単純なトピックツリーを示す。サブスクライバSUBSCRIBER1（図１におけるSUB.1）は、トピック“root/topicA/topicX”上にパブリッシュされたメッセージを受信するようにサブスクライブしており、それらのサブスクリプションは、トピックツリーの各ノードに関連付けられている。受信されたメッセージ内のトピック文字列の要素は、それぞれ、ツリーのノードが受信されたトピック文字列と一致すると識別されるまで、又は一致が存在しないと判定されるまで、トピックツリーの各層の一連のノードと順次比較される。一致が識別された場合、そのパブリケーションが、そのトピックに関するパブリケーションを受信することを登録したサブスクライバに転送される（メッセージのプロパティ又は特定のサブスクリプション内で特定されたメッセージのコンテンツに基づいてあらゆるフィルタをチェックすることを条件として）。）

「[0038]FIG. 2 shows a simple publish/subscribe messaging network in which the present invention may be implemented. Such networks are known in the art. A set of publishers 10,20 running on respective data processing systems 30,40 are able to publish messages that can be received by multiple subscribers 90, 100, 110, by the publishers sending messages to an intermediate publish/subscribe message broker 50. The publishers and subscribers do not need direct connections between them and do not need each other's address information. Instead, the publishers send messages to the broker 50, including information such as message topics within their published messages. In this example, the publishers 10,20 are application programs that rely on message transfer functions of underlying messaging infrastructure products 150,160 that hold network address and other communication information for the broker 50.

[0039]In this example, the message broker is implemented on a data processing system 60 that is separate from the publisher systems 30,40 and separate from subscriber's systems 120,130,140. The message broker comprises a subscription matching engine 70 and an associated stored subscription list 80. Subscribers register with the broker 50 and indicate their interest in particular information such as by specifying a particular message topic or topics. The subscribers' requirements are stored at the broker. In one embodiment, a broker can also store network addresses and protocol requirements for individual subscriber systems and the broker can initiate a connection; but in a preferred embodiment the broker merely stores names of subscriber systems and of their subscriptions, and the network and communications information is held at the subscriber's system and is used when the subscriber initiates a connection to the broker.

[0040]The subscription matching engine 70 at the broker 50compares subsequently received publications with stored subscriptions to determine which received publications match the requirements of which subscribers, and the broker forwards the publications to the interested subscribers. Although only a small number of publishers and subscribers are shown in FIG. 1, there may be many publishers and many subscribers within the network and the publish/subscribe broker may be part of a distributed broker network,」

（当審訳： [0038]図２は、本発明が実施され得る単純なパブリッシュ／サブスクライブメッセージングネットワークを示す図である。このようなネットワークは、当技術分野で知られている。それぞれのデータ処理システム30、40上で稼働するパブリッシャ10、20の組が、複数のサブスクライバ90、100、110によって受信され得る、中間のパブリッシュ／サブスクライブメッセージブローカ50にメッセージを送信するパブリッシャによるメッセージを、パブリッシュすることができる。パブリッシャ及びサブスクライバは、それらの間に直接的な接続を必要とせず、相互のアドレス情報を必要としない。その代わりに、パブリッシャはブローカ50に、パブリッシュされたメッセージ内にメッセージトピック等の情報を含むメッセージを送信する。この例では、パブリッシャ10、20は、ネットワークアドレスやブローカ50のための他の通信情報を保持する基礎となるメッセージング基盤製品150、160のメッセージ転送機能に依存するアプリケーションプログラムである。

[0039]この例では、メッセージブローカは、パブリッシャシステム30、40から分離し、かつサブスクライバのシステム120、130、140から分離した、データ処理システム60上で実施される。メッセージブローカは、サブスクリプションマッチングエンジン70、及び関連する記憶されたサブスクリプションリスト80からなる。サブスクライバは、ブローカ50に登録し、また、特定のメッセージトピック又はトピックスを特定することなどにより、それらの特定の情報への関心を表す。サブスクライバの要求は、ブローカに記憶される。一実施形態では、ブローカは、個々のサブスクライバシステムのネットワークアドレス及びプロトコル要件を格納することもでき、また、ブローカは、接続を開始することができる； しかし、好ましい実施形態では、ブローカは、単にサブスクライバシステムの名称及びそれらのサブスクリプションを記憶するだけであり、ネットワークや通信の情報が、サブスクライバのシステムにおいて保持され、サブスクライバがブローカに接続を開始する際に使用される。

[0040]ブローカ50におけるサブスクリプションマッチングエンジン70は、受信されたどのパブリケーションがどのサブスクライバの要求と一致するかを決定するために、連続的に受信されたパブリケーションを記憶されたパブリケーションと比較し、ブローカはパブリケーションを関心のあるサブスクライバに転送する。図１には少数のパブリッシャ及びサブスクライバしか示されていないが、ネットワーク内に多数のパブリッシャ及び多数のサブスクライバが存在してもよく、パブリッシュ／サブスクライブブローカは分散ブローカネットワークの一部であってもよい。）

「[0046]An embodiment of the invention is described below with reference to FIGS. 3 to 5. FIG. 3 is a schematic representation of the structure of a typical message, including a set of message header fields and a message body (the data‘payload’of the message). The message header may include a number of different fields including, for example: message format information; a topic field; an indication of the required quality of service (either persistent or non-persistent, to control whether the message should be saved to nonvolatile storage to be recoverable in the event of a failure), and a retain flag (to indicate whether the broker should retain a copy of this publication, to enable the latest publication for this topic to be made available to future subscribers to this topic). Additional header fields are known in the art.

[0047]For example a publisher application can invoke a send operation on an existing connection to a publish/subscribe broker to publish a message, using an API call such as:

[0048]publish(topic, data, persistence, retain)

where each of‘persistence’and‘retain’are message properties as described above and are specified together with the topic information within header fields of the published message. The topic field of the published message may include a character string in which text elements are separated by a‘/’character. In a conventional publish/subscribe system implementing an hierarchical topic classification scheme, a publisher-specified topic string such as“root/topicA/topicX”is interpreted as a single hierarchical topic name and will only be identified as a match for subscriptions that specify the exact same topic string“root/topicA/topicX”(or an equivalent using wildcards such as“*/topicA/topicX”or“root/topicA/*”).

続きを表示（全13行）

[0049]Translating from a programming API to a message header is well known in the art. For example, in some known systems, messages have a header that contains the publish/subscribe attributes in XML-like format. A message published on topic root/topicA/topicX, could have the following within its message header:

［図：0001383850000001.jpg］

[0050]In a first embodiment of the present invention, an additional ‘match_scheme’tag is provided within an additional field of the message header. The‘match_scheme’field is provided to enable a publisher to specify the topic classification scheme they have implemented when specifying a topic string within the topic field. In this exemplary embodiment, a number of topic classification schemes can be specified by publishers and will be recognized by the publish/subscribe broker, including:

‘match_scheme=OR’which indicates that the publisher intends each of the separate elements of the specified topic string to be interpreted as independent tags (or‘keywords’) that can be compared with subscriptions using a matching algorithm that uses the Boolean OR operator.

‘match_scheme=AND’which indicates that the publisher intends each of the separate elements of the specified topic string to be interpreted as independent tags (or‘keywords’) that can be compared with subscriptions using a matching algorithm that uses the Boolean AND operator,

‘match_scheme-HI’which indicates that the publisher intends the specified topic string to be interpreted as a single hierarchical topic name that can be compared with subscriptions using an hierarchical topic matching algorithm.

[0051]Publishers can specify a topic string using the conventional format described above in which elements are separated by the‘/’character, and yet the intention of this topic string format can be different for different publishers. The particular publishers intent is captured within the match_scheme value.

[0052]For example a first publisher application may specify“2012_olympics/UK_olympic_teams/sailing”with‘match_scheme=HI’. The publisher's intention is that the broker and subscribers interpret this as the topic subcategory‘sailing’within category‘UK_olympic_teams’within the more general category‘2012_olympics’.

[0053]A second publisher may specify the same topic string“2012_olympics/UK_olympic_teams/sailing”with‘match_scheme=OR’, in which case this publlisher's intention is that the separate elements‘2012_olympics’,‘UK_olympic_teams’and‘sailing’can be matched separately. That is, the publisher's intention is that a subscription to any one of the topics‘2012_olympics’,‘UK_olympic_teams’and‘sailing’ will be identified as a match for the current publication.」

（当審訳： [0046]図３ないし５を参照して、本発明の実施形態が記述される。図３は、典型的なメッセージの構造の概略図であり、一組のメッセージヘッダフィールド及びメッセージ本文（メッセージのデータ‘ペイロード’）を含む。メッセージヘッダは、例えば：メッセージフォーマット情報；トピックフィールド；必要なサービス品質とされる品質の指示（永続的または非永続的のいずれかの、障害の場合に回復できるようにメッセージを不揮発性ストレージに保存すべきかどうかを制御するためもの）、及び保持フラグ（このトピックの最新のパブリケーションが、このトピックに対する将来のサブスクライバにとって利用可能とされることを可能にするために、ブローカがこのパブリケーションのコピーを保持すべきであるかどうかを示すためのもの）を含む、多数の異なるフィールドを含んでいてもよい。付加的なヘッダフィールドは、当該技術分野で知られている。

[0047]例えば、パブリッシャアプリケーションは、メッセージをパブリッシュするために、パブリッシュ／サブスクライブブローカとの既存の接続への送信動作を起動することができ、それは、次のようなAPIコールを使用して行う：

[0048]publish(topic, data, persistence, retain)。ここで‘persistence’及び‘retain’の各々は、上述のメッセージ特性であり、パブリッシュされたメッセージのヘッダフィールド内でトピック情報とともに特定される。パブリッシュされたメッセージのトピックフィールドは、テキスト要素が‘/’文字で区切られた文字列を含んでいてもよい。階層的なトピック分類方式を実施する従来のパブリッシュ／サブスクライブシステムにおいて、“root/topicA/topicX”のようなパブリッシャが特定されたトピック文字列は、単一の階層的トピック名として解釈され、全く同一のトピック文字列“root/topicA/topicX”（若しくは、“*/topicA/topicX”又は“root/topicA*/”のようなワイルドカードを用いた等価のもの）を特定するサブスクリプションに合致するものとして、唯一、識別されるだろう。

[0049]プログラミングAPIからメッセージヘッダへの翻訳は、当該技術分野で周知である。例えば、いくつかの既知のシステムでは、メッセージは、例えば、XMLのようなフォーマットにおけるパブリッシュ／サブスクライブ属性を含むヘッダを有する。トピック“root/topicA/topicX”上でパブリッシュされたメッセージは、そのメッセージヘッダ内に、次のものを備えている：

-----------------------------------

<psc>

<Command>Publish</Command>

<Topic>root/topicA/topicX</Topic>

</psc>

-----------------------------------

[0050]本発明の第１の実施形態では、追加の‘match_scheme’タグが、メッセージヘッダの追加フィールド内に設けられている。‘match_scheme’フィールドは、パブリッシャが、トピックフィールド内のトピック文字列を特定するときに、それらが実施したトピック分類スキームを特定することを可能とするために提供される。この例示的な実施形態では、多数のトピック分類スキームが、パブリッシャによって特定されることができ、パブリッシュ／サブスクライブブローカによって認識されるだろう。それは、次のものを含む：

‘match_scheme=OR’、これは、特定されたトピック文字列の区切られた要素のそれぞれが、ブーリアンOR演算子を用いたマッチングアルゴリズムを使用してサブスクリプションと比較され得る、独立したタグ（又は‘keywords’）として解釈されることを、パブリッシャが意図することを示す。

‘match_scheme=AND’、これは、特定されたトピック文字列の区切られた要素のそれぞれが、ブーリアンAND演算子を用いたマッチングアルゴリズムを使用してサブスクリプションと比較され得る、独立したタグ（又は‘keywords’）として解釈されることを、パブリッシャが意図することを示す。

‘match_scheme-HI’、これは、特定されたトピック文字列が、階層的トピックのマッチングアルゴリズムを使用してサブスクリプションと比較され得る、独立したタグ（又は‘keywords’）として解釈されることを、パブリッシャが意図することを示す。

[0051]パブリッシャは、要素が‘/’の文字で区切られている上述したような従来のフォーマットを使用してトピック文字列を特定することができ、また、さらにこのトピック文字列フォーマットの意図は、異なるパブリッシャについて異なり得る。特定のパブリッシャの意図は、‘match_scheme’の値の中にキャプチャされる。

[0052]例えば、第１のパブリッシャアプリケーションは、“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=HI’で特定し得る。パブリッシャの意図は、ブローカ及びサブスクライバが、より一般的なカテゴリ‘2012_olympics’の中のカテゴリ‘UK_olympic_teams’の中のトピックサブカテゴリ‘sailing’としてこれを解釈することである。

[0053]第２のパブリッシャは、同じトピック文字列“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=OR’で特定し得る、この場合では、このパブリッシャの意図は、個別の要素である‘2012_olympics’、‘UK_olympic_teams’及び‘sailing’は、個別にマッチングされ得るということである。すなわち、パブリッシャの意図は、トピック‘2012_olympics’、‘UK_olympic_teams’及び‘sailing’のいずれか１つへのサブスクリプションが、現在のパブリケーションにとっての一致として識別されるだろうということである。）

（図１）「

［図：0001383850000002.jpg］

」

（図２）「

［図：0001383850000003.jpg］

」

（図３）「

［図：0001383850000004.jpg］

」

（２）上記（１）から、引用文献１には、次の発明（以下、「引用発明」という。）が記載されていると認められる。

「パブリッシュ／サブスクライブメッセージングネットワークであって、

パブリッシャ10、20の組が、複数のサブスクライバ90、100、110によって受信され得るメッセージをパブリッシュし、パブリッシャはブローカ50に、パブリッシュされたメッセージ内にメッセージトピック等の情報を含むメッセージを送信し、

サブスクライバは、ブローカ50に登録し、また、特定のメッセージトピック又はトピックスを特定することなどにより、それらの特定の情報への関心を表し、ブローカは、単にサブスクライバシステムの名称及びそれらのサブスクリプションを記憶し、

ブローカ50は、受信されたどのパブリケーションがどのサブスクライバの要求と一致するかを決定するために、連続的に受信されたパブリケーションを記憶されたパブリケーションと比較し、ブローカはパブリケーションを関心のあるサブスクライバに転送し、

パブリッシュされたメッセージのトピックフィールドは、テキスト要素が‘/’文字で区切られた文字列を含み、

追加の‘match_scheme’タグが、メッセージヘッダの追加フィールド内に設けられ、‘match_scheme’フィールドは、パブリッシャが、トピックフィールド内のトピック文字列を特定するときに、それらが実施したトピック分類スキームを特定することを可能とするために提供され、多数のトピック分類スキームが、パブリッシャによって特定されることができ、パブリッシュ／サブスクライブブローカによって認識され、

例えば、第１のパブリッシャアプリケーションは、“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=HI’で特定し得、パブリッシャの意図は、ブローカ及びサブスクライバが、より一般的なカテゴリ‘2012_olympics’の中のカテゴリ‘UK_olympic_teams’の中のトピックサブカテゴリ‘sailing’としてこれを解釈することであり、

第２のパブリッシャは、同じトピック文字列“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=OR’で特定し得、この場合では、このパブリッシャの意図は、個別の要素である‘2012_olympics’、‘UK_olympic_teams’及び‘sailing’は、個別にマッチングされ得るということである、

パブリッシュ／サブスクライブメッセージングネットワーク。」

２ 引用文献２

原査定の拒絶の理由にて引用された引用文献２には、図面とともに、次の記載がある。

「【００１３】

本システムは、ブロードバンド接続経由でサービスプロバイダネットワークに結合された多数のエンドユーザデバイス、多数のエンドユーザデバイスとサービスプロバイダネットワークに結合された少なくとも第１のバックエンドエンティティと通信するように適合されたパブリッシュ／サブスクライブブローカを備える。第１のバックエンドエンティティは、パブリッシュ／サブスクライブブローカに接続して、エンドユーザデバイスのデバイス管理を行うために制御データチャネル経由で制御データをパブリッシュする、第１のクライアントソフトウェアアプリケーションを含む。エンドユーザデバイスのそれぞれは、パブリッシュ／サブスクライブブローカに接続し、制御データチャネルをサブスクライブし、制御データを受信し、そしてさらに制御データによる指示に基づいてデバイスデータおよびアクションデータをパブリッシュする、第２のクライアントソフトウェアアプリケーションを含む。バックエンドエンティティの承認は、具体的には制御データ署名を使用することによって確認される。

【００１４】

好適な実施形態において、サービスプロバイダネットワークは、インターネットサービスを、例えば、ネットワークサービスプロバイダネットワークに提供し、エンドユーザデバイスのデバイス管理を提供するネットワークであり、そしてパブリッシュ／サブスクライブブローカも、ネットワークサービスプロバイダネットワークを運営するネットワークサービスプロバイダによって提供される。各エンドユーザデバイスは具体的には、そのデバイス管理を行う管理コマンドを受信するために少なくとも１つの制御データチャネルをサブスクライブし、そして各エンドユーザデバイスは、そのデバイスデータをデバイスデータチャネル経由でパブリッシュし、アクションデータをアクションデータチャネル経由でパブリッシュする。」

第５ 対比・判断

１ 本願発明１について

（１）対比

ア 本願発明１と引用発明とを対比すると、次のことがいえる。

（ア）引用発明の

「パブリッシャ10、20の組が、複数のサブスクライバ90、100、110によって受信され得るメッセージをパブリッシュし、パブリッシャはブローカ50に、パブリッシュされたメッセージ内にメッセージトピック等の情報を含むメッセージを送信」する

との構成及び、

引用発明の「サブスクライバは、ブローカ50に登録し、また、特定のメッセージトピック又はトピックスを特定することなどにより、それらの特定の情報への関心を表し、ブローカは、単にサブスクライバシステムの名称及びそれらのサブスクリプションを記憶し、

ブローカ50は、受信されたどのパブリケーションがどのサブスクライバの要求と一致するかを決定するために、連続的に受信されたパブリケーションを記憶されたパブリケーションと比較し、ブローカはパブリケーションを関心のあるサブスクライバに転送」する

との構成について、後者の構成は、前者における「パブリッシャ10、20」のいずれかと「サブスクライバ90、100、110」のいずれかとの間で送受信される「メッセージ」が、「パブリッシュ／サブスクライブ型」のものであることを示すものであるといえる。

また、両構成から、「ブローカ50」は、「サブスクライバ」（「サブスクライバ90、100、110」のいずれか）の「要求」に従って、「メッセージ」を「サブスクライバ90、100、110」のいずれかに「転送」する通信を提供するという点で、「パブリッシャ10、20」及び「サブスクライバ90、100、110」はクライアントとして機能し、「ブローカ50」はサーバとして機能しているといえるから、引用発明の「パブリッシャ10、20」及び「サブスクライバ90、100、110」は、本願発明１の「パブリッシャ又はサブスクライバである複数のクライアント装置」に相当し、引用発明の「ブローカ50」は、本願発明１の「サーバ装置」に相当する。

以上のことから、引用発明は、本願発明１の

「パブリッシュ／サブスクライブ型のメッセージの送受信をパブリッシャ又はサブスクライバである複数のクライアント装置との間で行なうサーバ装置」

に相当する構成を含むものである。

（イ）引用発明の

「パブリッシュされたメッセージのトピックフィールドは、テキスト要素が‘/’文字で区切られた文字列を含み、

追加の‘match_scheme’タグが、メッセージヘッダの追加フィールド内に設けられ、‘match_scheme’フィールドは、パブリッシャが、トピックフィールド内のトピック文字列を特定するときに、それらが実施したトピック分類スキームを特定することを可能とするために提供され、多数のトピック分類スキームが、パブリッシャによって特定されることができ、パブリッシュ／サブスクライブブローカによって認識され、

例えば、第１のパブリッシャアプリケーションは、“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=HI’で特定し、パブリッシャの意図は、ブローカ及びサブスクライバが、より一般的なカテゴリ‘2012_olympics’の中のカテゴリ‘UK_olympic_teams’の中のトピックサブカテゴリ‘sailing’としてこれを解釈することであり、

第２のパブリッシャは、同じトピック文字列“2012_olympics/UK_olympic_teams/sailing”を‘match_scheme=OR’で特定し、この場合では、このパブリッシャの意図は、個別の要素である‘2012_olympics’、‘UK_olympic_teams’及び‘sailing’は、個別にマッチングされ得るということである」

との構成によれば、「パブリッシュ／サブスクライブブローカ」は、「パブリッシャ」から、プロトコル上の「トピックフィールド」及び「メッセージヘッダの追加フィールド」を含む「メッセージ」（「パブリッシュされたメッセージ」）を受信して、「メッセージヘッダの追加フィールド」の「‘match_scheme’タグ」が「‘match_scheme=HI’」であるか「‘match_scheme=OR’」であるかの解析を行い、その結果に基づき特定される「‘match_scheme’タグ」の内容（「トピック分類スキーム」）に基づいて、例えば「“2012_olympics/UK_olympic_teams/sailing”」である「トピック文字列」を対象として、「メッセージ」に対応する処理を実行するものであるといえる。

ここで、引用発明の「ブローカ50」及び「パブリッシュ／サブスクライブブローカ」は、同じものを指していることが明らかである。

そして、引用発明の「メッセージヘッダの追加フィールド」、「トピック文字列」は、それぞれ、本願発明１の「１つのフィールド」、「トピック」に相当する。

また、引用発明の「‘match_scheme’タグ」は、「メッセージ」の「トピック文字列」を対象とする処理をどのように行うかを特定するということができることから、本願発明１の「ラベル」と、「トピックに関するデータ」である点で共通している。もっとも、当該「‘match_scheme’タグ」は、「１又は複数」の「トピック文字列」と「対応付けられた」関係にはない（「‘match_scheme’タグ」は、これに「対応付けられた」「１又は複数」の「トピック文字列」の内容を特定するためのものではない）ことから、本願発明１の「ラベル」に相当するとはいえない。

これらの点について、上記（ア）も踏まえると、本願発明１の「サーバ装置」が

「前記クライアント装置から受信した前記メッセージにおけるプロトコル上の１つのフィールドに、前記ラベルを含む制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断する判断部と、

該判断部により制御文が含まれていると判断された場合、該制御文に含まれる前記ラベルの解析を行なう解析部と、

解析結果に基づき特定されるラベルに対応するトピックを対象として前記メッセージに対応する処理を実行するメッセージ処理部と

を備える」

ことに関して、引用発明と本願発明１とは、「サーバ装置」が

「前記クライアント装置からプロトコル上の１つのフィールドにトピックに関するデータが含まれている前記メッセージを受信する手段と、

前記データの解析を行なう解析部と、

解析結果に基づき特定される前記データに基づいて前記メッセージに対応する処理を実行するメッセージ処理部と

を備える」

という点で共通している。

イ したがって、本願発明１と引用発明とは以下の点で一致する。

（一致点）

「パブリッシュ／サブスクライブ型のメッセージの送受信をパブリッシャ又はサブスクライバである複数のクライアント装置との間で行なうサーバ装置において、

前記クライアント装置からプロトコル上の１つのフィールドにトピックに関するデータが含まれている前記メッセージを受信する手段と、

前記データの解析を行なう解析部と、

解析結果に基づき特定される前記データに基づいて前記メッセージに対応する処理を実行するメッセージ処理部と

を備えるサーバ装置。」

ウ また、本願発明１と引用発明とは以下の点で相違する。

（相違点１）

本願発明１では、「サーバ装置」が、「前記メッセージの対象である１又は複数のトピックと対応付けられた文字列であるラベルを記憶する記憶部」を備えるともに、「前記メッセージに対応する処理」の「対象」が「ラベルに対応するトピック」であるのに対して、引用発明では、「ブローカ50」が、「パブリッシャ」から受信する「メッセージ」の「メッセージヘッダの追加フィールド」に含まれる「‘match_scheme’タグ」の内容（「トピック分類スキーム」）に基づいて、例えば「“2012_olympics/UK_olympic_teams/sailing”」である「トピック文字列」を対象として、「メッセージ」に対応する処理を実行するものの、「‘match_scheme’タグ」は、「１又は複数」の「トピック文字列」と「対応付けられた」ものではなく、また、「メッセージ」に対応する処理の対象が「‘match_scheme’タグ」に「対応する」「トピック文字列」ではないので、「‘match_scheme’タグ」は本願発明１の「ラベル」には相当せず、よって、「ラベルを記憶する記憶部」を備えているとはいえない点。

（相違点２）

本願発明１では、「サーバ装置」が、「前記クライアント装置から受信した前記メッセージにおけるプロトコル上の１つのフィールドに、前記ラベルを含む制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断する判断部」を備えるとともに、「解析部」が「前記ラベルの解析を行う」ことについて、「該判断部により制御文が含まれていると判断された場合」に、「該制御文に含まれる前記ラベル」について行うものであるのに対して、引用発明では、「ブローカ50」が、「パブリッシャ」から「メッセージヘッダの追加フィールド」に「‘match_scheme’タグ」を含む「メッセージ」を受信するものの、「メッセージヘッダの追加フィールド」に「‘match_scheme’タグ」を含む「制御文」が含まれ得るものではなく、「ブローカ50」が、「メッセージヘッダの追加フィールド」に「制御文が含まれているか否かを、前記制御文の始まりを示す特定の文字列の有無によって判断する」ものでもなく、「‘match_scheme’タグ」の解析を「制御文が含まれていると判断された」ことを条件に行うものでもない点。

（２）判断

そこで、まず相違点１について検討する。

パブリッシュ／サブスクライブ型のメッセージの送受信を行うサーバ装置に、１又は複数のトピックと対応付けられた文字列であるラベルを記憶させた上で、サーバ装置が、クライアント装置から受信したメッセージに含まれるラベルに対応するトピックを対象として当該メッセージに対応する処理を実行するものとすることは、引用文献１，２のいずれにも記載されておらず、本願の出願日前において周知技術であったともいえない。

よって、相違点２について検討するまでもなく、本願発明１は、当業者であっても引用文献１，２に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

２ 本願発明２～６について

本願発明２～４は、本願発明１を減縮した発明である。また、本願発明５は、本願発明１に対応する発明特定事項について「コンピュータプログラム」の発明として特定したものであり、本願発明６は、本願発明１と発明のカテゴリが相違するのみである。

したがって、本願発明２～６も本願発明１と同様の理由により、当業者であっても引用文献１，２に記載された発明に基づいて容易に発明をすることができたものであるとはいえない。

第６ 原査定についての判断

令和４年２月２１日提出の手続補正書による補正の結果、本願発明１～６は、それぞれ相違点１に係る発明特定事項又はそれらに対応する発明特定事項を有するものとなっており、上記第５のとおり、引用文献１，２に記載された発明に基づいて当業者が容易に発明をすることができたものではない。したがって、原査定（上記第２）を維持することはできない。

第７ 当審拒絶理由について

１ 当審が令和４年１月１１日付けで通知した拒絶理由（以下、「当審拒絶理由」という。）の概要は次のとおりである。

（１）理由１（明確性）

この出願は、特許請求の範囲の記載が、特許法第３６条第６項第２号に規定する要件を満たしていない。

請求項１には、「パブリッシュ／サブスクライブ型のメッセージ」との記載及び「パブリッシュ又はサブスクリプションメッセージ」との記載があり、また、これらをそれぞれ受けた記載として、「前記メッセージ」、「前記パブリッシュ又はサブスクリプションメッセージ」との記載もある。この点は、請求項５，６についても同様である。

しかしながら、ここで、「パブリッシュ／サブスクライブ型のメッセージ」と「パブリッシュ又はサブスクリプションメッセージ」との関係（特に、それらの異同に関して、互いに異なるとすれば何が異なるのか）が不明である。

また、請求項１を引用する請求項２～４においても、請求項２の「メッセージ」、請求項４の「パブリッシュメッセージ」等、請求項１の「パブリッシュ／サブスクライブ型のメッセージ」又は「パブリッシュ又はサブスクリプションメッセージ」との関係が不明な記載が存在する。

（２）理由２（サポート要件）

この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。

請求項３には、「前記１つのフィールドは、パブリッシュ又はサブスクリプションメッセージにおけるトピックフィールド、又は、ペイロードフィールドである」との記載があり、この記載中の「前記１つのフィールド」に関して、請求項３が引用する請求項１の記載によれば、請求項３において、「ラベルを含む制御文が含まれている」、「１つのフィールド」は、「ペイロードフィールド」であり得る、すなわち、「ペイロードフィールド」が「ラベルを含む制御文」を含み得るものであるが、発明の詳細な説明には、「ペイロードフィールド」が「ラベルを含む制御文」を含むことについては記載も示唆もなく、本願出願日前の技術常識を参酌しても自明とはいえない。

２ これに対し、令和４年２月２１日に提出された手続補正書により補正された特許請求の範囲では、各請求項に記載されている「メッセージ」が、いずれも、「パブリッシュ／サブスクライブ型のメッセージ」を指していることが把握できるから、本願発明１～６は明確なものとなり、同じく請求項３において、「又は、ペイロードフィールド」との記載が削除されたことから、本願発明３，４は、発明の詳細な説明に記載したものとなった。

よって、当審拒絶理由は解消した。

第８ むすび

以上のとおり、原査定の理由によって、本願を拒絶することはできない。

また、他に本願を拒絶すべき理由を発見しない。

よって、結論のとおり審決する。