109年度民專訴字第5號｜智財：侵害專利權有關財產權爭議｜裁判日期：110 年 04 月 27 日

智慧財產法院民事判決 109年度民專訴字第5號原　　　告　雲端行動科技股份有限公司法定代理人　王葆華訴訟代理人　周金城律師鄭懷君律師陳曉雯律師輔　佐　人　謝門扇被告　睿點行動股份有限公司兼法定代理人　陳振榮共同訴訟代理人　黃信嘉劉允正律師陳哲宏律師上一人複代理人　　吳承芳律師上列當事人間侵害專利權有關財產權爭議事件，本院於中華民國110 年4 月13日言詞辯論終結，判決如下：主文原告之訴及假執行之聲請均駁回。訴訟費用由原告負擔。事實及理由一、原告主張：原告投入研發管理電子發票方法已有多年，於財政部積極推動電子發票實施之前，原告即創新提出透過行動載具管理電子發票之方法，並經申請專利後核准為中華民國第I554956 號「電子發票訊息傳送方法」發明專利（下稱系爭專利），專利權有效期間自民國105 年10月21日起至121 年5 月7 日止。詎原告於AppStore及Google Play 等線上平台，發現由被告睿點行動股份有限公司（下稱睿點公司）提供之「發票存摺」應用程式（下稱系爭產品）背後用以與系爭產品相連結之伺服器內所使用之方法（下稱系爭方法），功能顯然包括透過行動載具管理電子發票，涉嫌使用原告所有之系爭專利技術，已落入系爭專利請求項1 之文義範圍。原告曾於108 年8 月30日發函被告睿點公司表示似有專利侵權之虞，被告睿點公司一概否認，且自述所使用技術特徵與系爭專利並不相同，而專利公報為公眾可查閱之資訊，被告睿點公司為從事同一電子發票管理技術之產業者應相當熟悉相關技術，卻未查閱相關專利，且在經函知系爭專利存在及系爭方法侵害專利範圍後，迄今仍於上開線上平台展示系爭產品，並持續於系爭產品使用侵害系爭專利之系爭方法，顯係以故意或過失侵害原告之系爭專利，自應負損害賠償責任；而被告陳振榮為被告睿點公司之負責人，自應與被告睿點公司連帶負損害賠償責任。又系爭產品截至108 年10月18日下載數量已達300 萬次，而依原告進行每則推播廣告會向廠商收取新臺幣（下同）1 元費用，即向有下載APP 之手機用戶推播一則廣告則收取1 元對價，再考量被告睿點公司迄今仍持續使用系爭方法、每位用戶可收取多則推播廣告、系爭產品下載量仍在增加中、原告發函至今已逾12個月等事實，可認被告睿點公司因使用系爭方法所得利益至少為300 萬元（計算式：300 萬次×1 元＝300 萬元），原告請求被告等連帶賠償80萬元，當屬合理。爰依專利法第96條第2 項、第97條第1 項第1 款、公司法第23條第2 項之規定，提起本件訴訟，並聲明：㈠被告等應連帶給付原告80萬元及自起訴狀繕本送達翌日起至清償日止，按年息百分之5 計算之利息。㈡原告願供擔保，請准宣告假執行。二、被告等答辯：㈠本件申請專利範圍之解釋，經審酌專利說明書有關「發明所屬之技術領域」、「先前技術」及「發明段落」，可知系爭專利請求項1 並未定義何謂電子發票訊息、電子發票資料，惟依據系爭專利申請時所適用之100 年5 月12日修正之統一發票使用辦法第7 條第3 項、第8 條第1 項規定，以及99年11月15日修正之電子發票實施作業要點第2 條第1 項規定，電子發票應係指以網際網路或其他電子方式開立、傳輸或接收之統一發票，且依上述辦法第9 條第1 項前段及上述要點第5 條，可知電子發票記載上除應包含交易日期、品名、數量、單價、金額、銷售額、課稅別、稅額及總計等價格訊息外，尚應包含字軌號碼，文義上極為清楚明確，自不得為其他與上述基本意義不同之解釋。㈡系爭專利請求項1 特徵技術3 部分，其中系爭專利說明書第【0024】、【0025】段所謂之「電子發票平台」，按系爭專利申請時之通常知識，係95年12月6 日上線運作之財政部電子發票整合服務平台，而請求項1 中所謂「一電子發票訊息傳送服務要求」並非習知用語，乃係原告自行使用之新創詞彙，然該內容不僅就「要求發出者」之記載模糊不清（例如「其」究係指稱「電子發票平台」（即財政部電子發票整合服務平台）抑或尚有其他第三人之可能，另因請求項1 「接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」既為接收步驟，倘不知該要求自何發出、包含何種傳送內容（即至少包含有該載具識別碼與一電子發票資料）、何種傳送動作（即將傳送內容自何處傳送至何處及其他必要之動作），所屬技術領域之通常知識者實則無從實施接收步驟，且實務運作上，殊難想像財政部電子發票整合服務平台會「主動」向特定協力廠商伺服主機「提出」電子發票訊息傳送服務要求，更不用說其會記錄並提供其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息，故系爭專利說明書記載不明確、不充分，明顯違反充分揭露、可據以實現要件，亦違反請求項應明確並可為說明書支持之記載原則。又請求項1 係由「伺服主機」傳送電子發票資料至行動裝置，然於系爭專利說明書並無相關記載或說明，通篇未解釋如何由伺服主機傳送電子發票資料至行動裝置，反係於系爭專利說明書第【0026】段及圖4 提及電子發票資料乃係由「行動裝置作業系統類別之推播訊息服務主機」執行傳送動作，傳送電子發票資料之主體不同，所使用之傳送技術及方式自當不同，系爭專利請求項1 技術特徵「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號」無法為說明書所支持、甚至兩相抵觸，違反核准時專利法第26條第2 項規定甚明。再者，乙證10、11、21、22、23之組合或乙證10、11、21、35至38之組合均足以證明系爭專利請求項1 不具進步性。㈢原告所提出系爭產品於App Store 及Google Play 線上平台展示之頁面，僅係系爭產品之概述及使用者評論，並無任何有關系爭產品運作機制即系爭方法之內容；另原告所提出系爭產品實際運作畫面影片，並非連續操作步驟，其形式真正已有可疑，且該影片時長短短2 秒，僅為系爭產品前段使用者之操作畫面，亦無絲毫有關系爭方法之內容；而系爭產品畫面截圖、使用者管理畫面截圖及推撥通知畫面截圖，僅與系爭產品相關，無法推論出任何有關系爭方法之內涵，故原告所提出之證據均無從證明系爭方法是否侵害系爭專利請求項1 。又原告歷次書狀所為侵權主張及比對，並非第三鑑定機關所為，而係原告自行製作，本屬偏頗，不足為證，又其比對方法，有以系爭產品為對象，亦有以系爭方法為對象，論理前後矛盾，立場莫衷一是，反而證明原告不僅對於系爭專利請求項1 解釋存有錯誤認識，又其對系爭方法認知均係憑空捏造而得，是原告指摘被告等侵害系爭專利顯屬主觀臆測，自無足採。另原告於民事爭點整理狀之侵權比對表格。先不論該侵權比對表格仍係以系爭產品為比較標的，而非系爭方法，系爭專利請求項1 為一具有先後執行順序之使用方法，因此就原告提示之侵權比對證據亦應為得以呈現動態流程表現之使用說明，而非僅以單純靜態之頁面擷取即稱符合系爭專利請求項1 各步驟，而落入該範圍。再者，為遵循我國個人資料保護法等相關規範，坊間業者之產品隱私權或資料蒐集等政策聲明範圍大多制定的十分廣泛，難謂是否系爭產品確會蒐集特定，且縱有蒐集機器屬性資料，與是否用於系爭方法中，於事實面係屬二事，邏輯上不得逕以此反向推論。因此，原告關於系爭專利請求項1 之第一步驟比對內容，明顯出於臆測而不可採；而關於第二步驟及第三步驟內容，原告並未提出任何證據予以佐證「系爭產品之伺服主機」存有實施「接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」；以及「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號」之步驟內容。至於第四步驟，目前僅得由原證5 確認具有彈出訊息視窗，至於該訊息視窗之產生原理及背後機制為何，係無法直接由該影片直接無歧異地對等還原該彈出結果，乃執行系爭專利請求項1 之第四步驟所得結果。故原告在舉證不足且皆屬臆測前提下，當然無續以判斷系爭產品是否構成侵害系爭專利之必要。㈣原告主張被告陳振榮為公司負責人應連帶負損害賠償責任，惟並未舉證其如何執行職務致生其損害，或身為公司負責人於業務執行上有何違反法令情事，逕以毫無理由之侵權主張，欲向被告等論以連帶責任，自無可採。又原告聲稱所受「鉅額損害」究指為何？竟隻字未提，迄今亦未提出任何證據資料證明其損害，企圖混淆原告應先證明損害確係存在之舉證責任，況被告睿點公司推播電子發票訊息不論是對於消費者或廠商皆未收取任何費用，原告之訴顯無理由。㈤聲明： ⒈原告之訴及假執行之聲請均駁回。 ⒉如受不利益判決，被告願供擔保，請准宣告免為假執行。三、兩造不爭執事項（本院卷㈢第31頁）㈠原告為系爭專利之專利權人，專利權期間自105 年10月21日起至121 年5 月7 日止。㈡「發票存摺」產品（即系爭產品）係由被告睿點公司製作，並於App Store 及Google Play 等線上平台供大眾下載。四、系爭專利及系爭產品技術內容、被告等所提專利有效性之證據技術內容㈠系爭專利技術分析 ⒈系爭專利技術內容：一種電子發票訊息傳送方法，係在接收到電子發票訊息傳送服務要求時，依據電子發票訊息傳送服務要求中內含之載具識別碼，來查詢取得與載具識別碼相關連之一行動裝置的行動裝置作業系統類別與其推播訊息記號，之後，再依據查詢取得之行動裝置作業系統類別與推播訊息記號，來將電子發票訊息傳送服務要求中內含之電子發票資料傳送至推播訊息記號所代表之行動裝置上。因此，可藉由行動裝置之作業系統業者所提供之推播訊息服務，來將電子發票開立資料或電子發票中獎通知資料，免費且即時地傳送給消費者，一併解決了發票持有與對獎便利性之障礙（參系爭專利說明書摘要，本院卷㈠第85頁）。 ⒉爭專利申請專利範圍共計5 個請求項，其中請求項1 為獨立項，其餘均為附屬項。原告主張受侵害者為系爭專利請求項1 ，本件僅就此範圍審理，請求項1 之內容如下（系爭專利主要圖式如附圖一所示）：一種電子發票訊息傳送方法，適用於管理電子發票之一伺服主機，包括下列步驟：收集、記錄與一行動裝置相關連之一載具識別碼、一行動裝置作業系統類別與一推播訊息記號；接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料；依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及依據該行動裝置作業系統類別與該推播訊息記號，來將該電子發票資料傳送至該推播訊息記號所代表之該行動裝置上（參系爭專利說明書申請專利範圍，本院卷㈠第96頁）。㈡系爭產品技術內容原告主張系爭產品背後用以與系爭產品相連結之伺服器內所使用方法為侵權標的（即系爭方法）。而系爭產品係由被告睿點公司製作，有iOS 及Android 二種版本，於App Store 及Google Paly 等線上平台供使用者下載。使用者手機上安裝「發票存摺」應用程式後，首先會出現該應用程式之「使用者條款與隱私權政策」畫面，使用者必須按下【同意】才能繼續使用，若按【不同意】會離開應用程式。如果「使用者條款與隱私權政策」畫面按下【同意】，會進入應用程式首頁，使用者按下【註冊/登入】，則進入「新會員註冊/舊會員登入」畫面，⑴對於未申請過電子載具（手機條碼）之使用者，應用程式會在註冊/登入同時申請電子載具(手機條碼）；⑵對於已經申請過電子載具（手機條碼）之使用者，可選擇使用先前申請的電子載具登入，將進入「以電子載具登入」畫面，要求使用者輸入【手機號碼】、【驗證碼】，此驗證碼為向財政部電子發票整合服務平台申請電子載具（即手機條碼）時，該平台以簡訊發送至使用者手機的驗證碼。使用者按下【登入】，如果應用程式依據【手機號碼】、【驗證碼】成功於財政部電子發票整合服務平台取得【手機條碼】，則即可開始使用「發票存摺」應用程式。之後，如果在應用程式首頁按會員資料編輯，即進入「會員資料與設定」畫面，可以查詢到手機號碼、電子載具、電子載具驗證碼已經儲存於「發票存摺」應用程式中；如果在應用程式首頁按右上角，即進入「進階功能」畫面，可以開啟【載具發票推播提醒】功能，也可進一步設定推播是否有聲音、推播之顯示位置等（系爭產品主要操作圖式如附圖二所示，參本院卷㈠第505至509頁）。㈢被告等所提專利有效性之證據技術內容 ⒈乙證10（主要圖式如附圖三所示） ⑴乙證10為2011年12月1 日公告之我國第M417618 號「電子發票管理系統」新型專利，其公告日早於系爭專利申請日（ 101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證10之技術內容 ①乙證10揭露一種電子發票管理系統，尤指一種簡單便利且環保之電子發票管理系統。其主要係包含有一中央單元、複數個店家單元及複數個用戶裝置，用戶可利用一個人識別碼於店家單元建立帳戶儲存電子發票，並於店家單元與中央單元連線時將電子發票資料匯入對應於個人識別碼之總發票帳戶或建立對應於個人識別碼之總發票帳戶後匯入電子發票資料。中央單元與店家單元可提供用戶發票管理之功能。店家單元並可傳送發票代碼與消費明細表至一用戶裝置，供用戶對帳使用（參乙證10說明書摘要，本院卷㈠第161頁）。 ②乙證10揭露一種電子發票管理系統，包含有一中央單元24、複數個店家單元26~28 及複數個用戶單元29，中央單元具有一發票總資料庫及一發票管理平台，各店家單元分別具有一發票產生器、一店家平台及一店家資料庫，其中，發票產生器（收銀機或軟體）用以列印實體發票或產生電子發票（參乙證10說明書第2 圖及第7 頁，本院卷㈠第169 頁）。發票產生器亦具有識別碼讀取模組267 、287 、297 用以讀取或輸入用戶之個人識別碼293 ，實體發票與電子發票上之帳目經由店家平台263 、273 、283 整合並儲存於店家資料庫 265 、275 、285 中（參乙證10說明書第2 圖及第8 頁，本院卷㈠第170 頁）。當於識別碼讀取模組267 、277 、287 輸入一新的個人識別碼293 時，店家平台263 、273 、283 即根據該個人識別碼293 建立一對應於該識別碼293 之帳戶，並將帳戶之密碼經由第二線路221 傳送至用戶裝置291 ；而當次之消費所產生的電子發票將儲存於店家資料庫265 、275 、285 中並對應於該帳戶。電子發票產生模組269 、 279 、289 在產生電子發票的同時，也會產生對應於該發票之發票代碼，並將該發票代碼傳送至用戶裝置291 。用戶可經由網路連線至店家平台263 、273 、283 ，並以該密碼登入帳戶進行帳戶之管理，並可以該發票代碼查閱對應之電子發票。當店家單元26、27、28以第一線路22與中央單元24連線時，即將發票資料依對應之個人識別碼293 匯入發票總資料庫243 。若該個人識別碼293 在發票管理平台241 中尚無對應之總發票帳戶，則先於發票管理平台241 中建立對應於該個人識別碼293 之總發票帳戶，再將對應之發票資料匯入發票總資料庫243 （參乙證10說明書第2 圖及第9 頁，本院卷㈠第171 頁）。 ③當一消費者至一店家消費並結帳時，店員首先詢問是否使用電子發票，如步驟301 及303 ，若選擇使用電子發票，則請用戶提供個人識別碼，以識別碼讀取模組267 讀取或輸入該個人識別碼293 ，如步驟321 ，接下來判斷店家平台中，是否存在對應於該個人識別碼之帳戶，如步驟323 。⑴若已有帳戶，則產生對應於該次消費之電子發票、發票代碼及消費明細表，如步驟341 ，電子發票產生後，即將電子發票相關資訊儲存至店家資料庫265 並對應於該個人識別碼與該帳戶，如步驟361 ，當店家單元與中央單元連線時，即可將發票資料匯入發票總資料庫243 ，並對應於該個人識別碼與該帳戶，如步驟363 ，之後，店家單元可將發票代碼與消費明細表傳送至該用戶之用戶裝置，如步驟343 。此外，當店家單元與中央單元連線上傳發票資料時，若發票管理平台中不存在對應於該個人識別碼之總發票帳戶，則先於發票管理平台中建立對應於該個人識別碼之總發票帳戶，再匯入對應於該個人識別碼之發票資料。而發票管理平台建立該總發票帳戶後，亦可傳送該帳戶之密碼至該用戶裝置，以供用戶管理其總發票帳戶，如步驟365 。⑵若尚無帳戶，則建立一對應於該個人識別碼之帳戶，如步驟325 ，店家平台於建立帳戶後，將該帳戶之密碼傳送至該用戶之用戶裝置，以供用戶管理其帳戶，如步驟327 （參乙證10說明書第3 圖及第11至12頁，本院卷㈠第173 至174 頁）。乙證10揭露個人識別碼可選擇為身份證字號、電話號碼、電子郵件信箱、公司登記之統一編號、特定帳戶等等具有唯一性且可代表該用戶之識別碼；並揭露用戶可利用密碼登入店家平台或發票管理平台，檢視及管理對應的電子發票，進行消費統計、消費查詢、發票捐贈、或選擇是否使用發票對獎等功能（參乙證10說明書第12頁，本院卷㈠第174 頁）。 ⒉乙證11（主要圖式如附圖四所示） ⑴乙證11為2007年12月16日公開之我國第200745877 號「分散式運算之推拉式資訊服務系統」發明專利案，其公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證11之技術內容 ①乙證11揭露一種分散式運算之推拉式資訊服務系統包括有一資訊服務伺服器以及至少一客戶端裝置。該伺服器可至少藉由廣播而以推送的方式提供一第一種資訊、以及依據使用者的請求而以拉取的方式來提供第二種資訊。該客戶端裝置可以擷取該廣播的第一種資訊以及發出一拉取請求給該伺服器以取得該第二種資訊。該第一及第二種資訊是藉由壓縮且加密之純文字資料來傳送。該客戶端裝置更包括有一圖形人機介面模組以供將至少一部分的純文字資料轉換成一圖形其可供顯示於客戶端裝置。該拉取請求包括有一檢索請求其包含了欲檢索之至少一特定名詞以及一特定時段。任何儲存在伺服器中且符合該特定名詞與該特定時段的資訊都會被傳送給客戶端裝置以作為該檢索之結果。本發明之分散式運算之推拉式資訊服務系統更揭露一「智慧型拉取」概念，當使用者發出一拉取請求時，只有在客戶端裝置之記憶體中不存在的資訊才會被拉取，因此可大幅提高頻寬的使用效率（參乙證11說明書摘要，本院卷㈠第187頁）。 ②乙證11揭露一種分散式運算之推拉式資訊服務系統（20＋30），包括有一資訊服務伺服器20以及至少一客戶端裝置30（參乙證11說明書圖1 及第13頁，本院卷㈠第197 頁）。該伺服器20可至少藉由廣播而以推送的方式提供一第一種資訊、以及依據使用者的請求而以拉取的方式來提供第二種資訊。該客戶端裝置可以接收該廣播的第一種資訊以及發出一拉取請求給該伺服器以取得該第二種資訊。該第一及第二種資訊是藉由壓縮且加密之純文字資料來傳送（參乙證11說明書第14頁，本院卷㈠第198 頁）。該客戶端裝置30包括有一核心引擎可送出一授權給該伺服器20（參乙證11說明書第17頁，本院卷㈠第201 頁），更包括有一圖形人機介面模組以供將至少一部分的純文字資料轉換成一圖形其可供顯示於客戶端裝置30（參乙證11說明書第16頁，本院卷㈠第200 頁）。該伺服器20包括有一客戶資料庫228 ，儲存有客戶端裝置之客戶資料，這客戶資料至少包括了客戶端裝置的授權有效性資料（參乙證11說明書第20頁，本院卷㈠第204 頁）。 ③在客戶端裝置30與伺服器20之間的資料流通常可被區分為四個種類：授權、推送、拉取、及維持連線。（A ）授權資料流：由一使用者61藉由該使用者介面33來操作客戶端裝置30並將他/ 她的帳號、密碼、及IMEI硬體機碼（或是例如UID 之另一獨一號碼）經由智慧傳輸模組226 傳給伺服器20之授權帳單模組225 。該授權帳單模組225 確認這些資訊並把伺服器的網路位址及通訊埠連同使用者61的使用授權資料一併經智慧傳輸模組226 傳回給客戶端裝置30。之後，客戶端裝置30在接收到這些資訊後結束授權程序。（B ）推送資料流：在客戶端使用者61經由該授權資料流確認其授權有效性後，該客戶端裝置30可以開始執行下列流程。首先，該客戶端裝置30傳送它的個人編輯目錄資訊及存取權給伺服器20的智慧傳輸模組226 。然後，當該智慧傳輸模組226 接收到這些目錄資訊及使用者61之存取權時，其開始過濾由即時資料廣播模組223 根據這目錄資訊與存取權所傳來的資料，然後再將過濾後之資料推送給客戶端裝置30。此推送資料流將於客戶端裝置30關閉連結後結束（參乙證11說明書第21至23頁，本院卷㈠第205 至207 頁）。 ④分散式運算之推拉式資訊服務系統更揭露一「智慧型推送」的概念，亦即只有使用者61真正要求的資訊才會即時性地被推送到客戶端裝置30。不同於那些不具時效性的履歷性資訊例如新聞或技術分析等，此種藉由「智慧型推送」來傳送的資訊通常是那些極具時效性或者是只有在使用者提出該要求的當時才具有意義的資訊。一旦使用者停止觀看螢幕時，例如切換視窗到其他功能或者是系統切換成螢幕保護狀態時，則伺服器20若還繼續推送此種資料給客戶端裝置30的話將變成一件毫無意義的事。因此，此所述之「智慧型推送」將會在使用者發出請求時開始傳送即時資料、並在使用者61任一時間離開當時顯示之視窗後立即結束。因此，只有最被感興趣的資訊或資料會在最佳時機會被推送，所以頻寬的使用將大幅提昇效率（乙證11說明書第23頁，本院卷㈠第207 頁）。 ⒊乙證21（主要圖式如附圖五所示） ⑴乙證21為蘋果公司（Apple Inc.）100年版本之「本地及推播通知編程指南」（Local and Push Notification Programming Guide ）第10、28、29、33、34頁影本（乙證40為該指南完整文件，乙證42則為引用內容之中文節譯本）。該指南每頁之頁尾均標示「0000-00-00∣ⒸApple Inc. All Rights Reserved」，堪認為2011年8月9日公開，其公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證21之技術內容 ①乙證21係蘋果公司為不特定iOS 應用程式開發者撰寫之程式設計指南，內容包括指導開發者如何將蘋果公司提供的推播功能應用於自行開發的應用程式中。 ②蘋果推播通知服務（簡稱APNs）是用來將信息傳播到iPhone、iPad和iPod等裝置之伺服主機，每個蘋果裝置都會建立一個經過認證和加密的IP來與APNs連線，並通過持續連接來接收通知。如果應用程式為運行時收到該應用程式的通知，則該裝置會提醒用戶該應用程式有數據在等待用戶閱讀（參乙證42第28頁第3 至5 行，本院卷㈡第408 頁）。供應商（Provider，通常是APP 開發商）在其伺服器中產生要發出推播訊息（Notification），其中包含客戶端應用程式的裝置標記（Device Token）和負載資料，供應商透過持續且安全的管道與APNs連線，將通知傳送到APNs，而APNs再將通知傳送到目標之蘋果裝置（參乙證42第28頁第6 至8 行，本院卷㈡第408 頁）。蘋果推播通知服務將推播通知從指定的供應商傳輸到指定的裝置，推播通知是一條短訊息，包含兩個主要數據：裝置標記和負載資料。裝置標記類似於電話號碼，包含使APNs能找到安裝了這個客戶端應用程式的裝置信息。負載資料規定了如何向用戶裝置上的應用程式發出指定警示（參乙證42第28頁第14至17行，本院卷㈡第408頁）。 ③附圖五圖式中圖3-1 為推播訊息傳送的過程，首先，訊息提供者（Provider）傳送推播訊息給蘋果公司的推播訊息服務主機（APNs），然後APNs再將推播傳送到iOS 裝置（iPhone），最後iOS 再將推播傳給接收的iOS 的應用程式（ClientApp ）。APNs是利用裝置標記（Device Token）來知道推播訊息要給的iOS 裝置，Token 的產生方式如下圖，首先，一個安裝了APP 客戶端應用程式（Client App）之iOS 蘋果手機，告訴APNs其允許接收推播通知，APNs就產生了該蘋果手機之裝置標記（device token）並回復該蘋果手機，該蘋果手機再把裝置標記（device token）回復應用程式，蘋果手機的應用程式最後把裝置標記（device token）回復給供應商（Provider）（參乙證42第33頁第3 至4 行，本院卷㈡第410頁）。 ④附圖五圖式中圖3-3 為設備標記（device token）產生及傳送順序，⑴iOS蘋果手機告訴APNs其允許接收推播通知（SSL安全連線），⑵APNS回復蘋果手機設備標記（device token），⑶蘋果手機把設備標記（device token）回復應用程式，⑷應用程式把設備標記（device token）回復給供應商（Provider），供應商後續傳送給APNs以便傳遞到裝置的每個推播通知都必須附上從該裝置上的應用程式取得的裝置標記，以便於使用裝置標記中包含的裝置ID來確定要通知的目標裝置（參乙證42第34頁第5 至7 行，本院卷㈡第411 頁）。⒋乙證22（主要圖式如附圖六所示） ⑴乙證22為Palm Web OS 98年有關推播通知演講截圖影本，該截圖為Youtube 在2009年2 月21日公開「Palm Pre KeynoteCES 2009（8/13）-webOS Notifications」影片之第35秒及1分55秒的畫面。乙證22之Youtube影片總長度5分25秒，網址為https://www.youtube.com/watch?v=zplVSI0M93o，迄至本件言詞辯論終結時，該Youtube影片尚未失效，且第35 秒及1分55秒的畫面內容與乙證22相符。乙證22之影片公開日早於系爭專利申請日（101年5月8日），可為系爭專利之先前技術。 ⑵依附圖六所示，乙證22影片第35秒及1 分55秒處，在Palm web OS手機之螢幕底部出現與電子郵件或即時通訊相關之系統推播通知。 ⒌乙證23（主要圖式如附圖七所示） ⑴乙證23為「Android 1.0 作業系統」於Android 開發者指南（Android Developer ）網站部分網頁影本，該網頁畫面顯示谷歌（Google）公司在2008年10月公開「Android 1.0 作業系統」於其開發者平台網站，提供getDeviceID 指令，迄至本件言詞辯論終結時，該等網頁仍存在且畫面內容與乙證23相符，可知Android 1.0 版提供getDeviceID 開發者工具，getDeviceID 開發者工具之公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證23第3 頁揭露Android 1.0 版提供getDeviceID 開發者工具，開發者可利用該指令，要求APP 端回傳裝置端識別碼，如IMEI（國際行動裝置辨識碼）、MEID（用於CDMA手機通訊之行動裝置識別碼）或ESN 碼（用於CDMA手機通訊之電子序列號）（本院卷㈠第305頁）。 ⒍乙證35（主要圖式如附圖八所示） ⑴乙證35為2011年11月24日公開之美國第2011/0000000A1號「Managing Notification Messages」發明專利案，其公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術（乙證44、45為乙證35之我國及中國大陸對應案公開本，作為中譯本）。 ⑵乙證35之技術內容 ①乙證35揭露一種產生識別一用戶端器件內之一用戶端應用程式之一副主題識別符的方法及裝置。該用戶端應用程式可與一或多個應用程式伺服器中所代管之一伺服器應用程式相關聯。可自該用戶端應用程式向該等應用程式伺服器註冊通知服務以將與該用戶端應用程式相關聯的識別符轉遞至該伺服器應用程式，從而使該伺服器應用程式能夠將通知訊息推送至選擇性地用於該用戶端應用程式的該用戶端器件。當自該應用程式伺服器接收到一通知訊息時，若該通知訊息攜載該用戶端應用程式之一副主題識別符，則該通知訊息可經檢查以便將該通知訊息直接轉遞至該用戶端應用程式，而不調用該用戶端器件中之其他應用程式（參乙證44說明書摘要，本院卷㈡第419頁）。 ②段落【0035】揭露「圖1 為說明用於訊息通知之網路系統之一實施例的方塊圖。網路系統100 可包括經由網路107 耦接至一或多個器件（諸如，行動器件109 〈例如，iphone器件〉）之一或多個伺服器（或主機）（諸如，應用程式伺服器101 、通知伺服器105 〈例如，APN 蘋果推送網路伺服器〉）。在一實施例中，網路107 可允許通知伺服器105 、行動器件109 及/ 或應用程式伺服器101 之間經由開放式網際網路、企業內部網路、防火牆防護安全網路、廣域蜂巢式網路（例如，3G網路）等的網路連接（例如，用於發送一推送通知）。網路107 可為有線的、無線的（諸如，Wi-Fi 、藍芽，等）或兩者之組合。」（參本院卷㈡第431頁）。 ③段落【0038】揭露「在一實施例中，應用程式111 可將器件符記（device token）115 及副主題113 轉遞至一對應之伺服器應用程式117 ，用於使應用程式伺服器101 將通知訊息推送至行動器件109 。應用程式伺服器101 繼而可回覆以主題103 ，從而使行動器件109 聽取以接收自應用程式伺服器101 推送之通知訊息。該等通知訊息可內嵌有副主題113 以允許行動器件109 在不調用器件中之其他用戶端應用程式的情況下直接將訊息遞送至由副主題113 識別之應用程式111 。」（參本院卷㈡第432至433頁）。 ④圖3 及段落【0043】揭露「在一實施例中，通知服務註冊儲存體303 可儲存用於來自伺服器應用程式117 或在應用程式伺服器101 中所代管之其他伺服器應用程式之訊息通知的自經註冊之用戶端器件所接收的器件符記及相關聯資料」、「當將通知訊息推送至由器件符記識別之用戶端器件時，伺服器應用程式117 可（例如）經由通知模組301 將器件符記連同其相關聯資料及主題103 轉遞至通知伺服器105 」，由上述內容可知，應用程式伺服器101 中具有通知服務註冊儲存體303 ，用以儲存用於來自伺服器應用程式117 之訊息通知的自經註冊之用戶端器件所接收的器件符記（device token）及相關聯資料，器件符記（device token）為辨識用戶端器件之唯一識別碼以供發送推播訊息（參本院卷㈡第434 至435 頁）。 ⑤圖4 及段落【0044】至【0048】揭露「圖4 為說明根據本文中所描述之實施例的在行動器件與應用程式伺服器之間的例示性訊息交換之順序圖。在一實施例中，行動器件109 、應用程式伺服器101 及通知105 可經由圖1 之網路107 彼此耦接。在向應用程式伺服器101 註冊訊息通知之前（例如，在情形401 之前），行動器件109 可（例如）經由通知伺服器105 自推送服務接收器件符記（諸如，圖1 之器件符記115 ）」、「在一實施例中，行動器件109 之用戶端應用程式（例如，行動郵件）可起始與應用程式伺服器101 中所代管之對應伺服器應用程式（例如IMAP伺服器）的網路連接以註冊來自伺服器應用程式之訊息通知。在順序401 處，用戶端應用程式可起始行動器件109 與應用程式伺服器101 之間的網路連接以發送用於查詢伺服器應用程式支援哪些能力的查詢請求。作為回應，在順序403 處，伺服器應用程式可（例如）基於包括XAPPLEUSHSERVICE指示符之協定而回覆以指示推送選項之可用性的指示符。在順序405 處，用戶端應用程式繼而可將來自行動器件109 之命令發送至應用程式伺服器 101 以註冊訊息推送或通知。該命令可包括具有用以允許伺服器應用程式定址行動器件109 及/ 或用戶端應用程式之名稱或識別符的參數。在一實施例中，該等參數可基於包括行動器件109 之器件符記的名稱值。視情況，該等參數可包括由行動器件109 內之用戶端應用程式所唯一地擁有之副主題（例如，「com.apple.mobilemail」）。在順序407處，應用程式伺服器可回覆以識別應用程式伺服器101之主題。主題可為一字串（例如，「com.google.push」），其可用以識別自應用程式伺服器101 經由由多個伺服器共用之推送服務推送的訊息。可經由經建立用於在行動器件109 與應用程式伺服器101 之間註冊訊息通知的同一網路連接來交換額外的應用程式特定異動。當行動器件109 正等候來自應用程式伺服器101 之通知時，此網路連接可斷開。隨後，伺服器應用程式可（例如）回應於某些應用程式特定事件的發生（諸如，IMAP伺服器中新郵件之到達）而產生待推送至行動器件109 之通知訊息。伺服器應用程式可與器件符記及與該器件符記相關聯之傳遞資料一起來封裝通知訊息，例如，該傳遞資料包括經註冊（或經儲存）用於行動器件109 之用戶端應用程式的副主題。在順序409 處，應用程式伺服器101 可經由通知伺服器105 將具有識別應用程式伺服器101 之主題的通知訊息發送至行動器件109 。在順序411 處，通知伺服器105繼而可經由推送網路服務將通知訊息推送至行動器件109。在通知訊息到達時，行動器件109 可在將訊息轉遞至所關注之用戶端應用程式之前驗證訊息之主題及/ 或器件符記。若該驗證失敗（例如，主題並未訂用及/ 或器件符記不匹配本端器件符記），則行動器件109 可忽略該訊息。視情況，行動器件109 可自通知訊息之有效負載提取副主題以將通知訊息僅遞送至由該副主題所命名之用戶端應用程式而不轉遞至訂用該主題之其他應用程式。若用戶端應用程式處於睡眠狀態下或當前不執行以接收通知訊息，則行動器件109 可調用用戶端應用程式。繼而，在順序413 處，用戶端應用程式可起始與應用程式伺服器101 中之對應伺服器應用程式的連接以執行應用程式特定異動（例如，擷取郵件訊息）」（參本院卷㈡第435 至437 頁）。 ⑥段落【0049】至【0053】揭露「圖5 為說明用以使得行動器件能夠將通知訊息投送至所識別之用戶端應用程式的程序之一實施例的流程圖。例示性程序500 可由一處理邏輯執行，該處理邏輯可包含硬體（電路、專用邏輯等）、軟體（諸如在專用機器上執行之軟體）或兩者之組合。舉例而言，程序500 可由圖1 之系統100 之一些組件執行。在區塊501 處，程序500 之處理邏輯可產生用於駐存於由器件符記識別之用戶端器件中之用戶端應用程式的應用程式識別符（例如，副主題），該用戶端應用程式執行與由一或多個應用程式伺服器代管之伺服器應用程式的異動，該一或多個應用程式伺服器係由一伺服器識別符（例如主題）識別。」、「在一實施例中，在區塊503 處，程序500 之處理邏輯可向用戶端應用程式註冊來自應用程式伺服器之訊息通知服務。程序500 之處理邏輯可將與用戶端應用程式相關聯之識別符（例如，包括用戶端應用程式識別符之副主題及用戶端器件之器件符記）轉遞至應用程式伺服器中所代管之伺服器應用程式，以便使得伺服器應用程式能夠將通知訊息推送至用於用戶端應用程式的用戶端器件。」、「在區塊505 處，回應於自應用程式伺服器接收到通知訊息，程序500 之處理邏輯可判定該通知訊息是否攜載應用程式識別符。在一實施例中，程序500 之處理邏輯可自通知訊息提取符記及主題（例如，基於名稱值）以驗證通知訊息是否預期被行動器件接收。在一實施例中，程序500 之處理邏輯可識別來自通知訊息之有效負載的應用程式識別符（例如，副主題）。」、「若識別了應用程式識別符或副主題，則在區塊507 處，程序500 之處理邏輯可將通知訊息轉遞至由副主題識別之用戶端應用程式，而不將通知訊息轉遞至訂用通知訊息之主題的其他應用程式。程序500 之處理邏輯可在用戶端器件中訂用該主題之多個用戶端應用程式當中選擇由該副主題識別之用戶端應用程式。否則，若在通知訊息中未找到副主題，則程序500 之處理邏輯可將通知訊息轉遞至訂用用於用戶端應用程式之主題的每一用戶端應用程式以判定是否處理通知訊息（例如基於該訊息中所攜載之內容）。」（參本院卷㈡第437 至439 頁）。 ⒎乙證36（主要圖式如附圖九所示） ⑴乙證36為2005年11月24日公開之日本第0000-000000A號「購買歷史信息利用方法及其系統和裝置」發明專利案，其公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術（乙證39為乙證36之中譯本）。 ⑵乙證36之技術內容 ①乙證36提供一種購買歷史信息利用方法及其系統和裝置，使得無需在商店中安裝用於將購買歷史訊息存儲在IC卡中之設備，而可以直接自用戶終端裝置或在終端裝置中運行的軟件獲取用戶以現金購買商品時之購買歷史信息。當用戶以現金購買換取商品時，商品銷售者的管理裝置2 會發行一個唯一號碼，並將其打印在收據上，並讓用戶知道該號碼，並且與包括唯一號碼的商品的購買有關的購買歷史信息通過通信網路4 被傳送並存儲到信息提供者的服務器裝置3 。當用戶通過通信網路4 從終端裝置1 向服務器裝置3 發送唯一號碼時，服務器裝置3 通過通信網路4 向終端裝置1 發送與該唯一號碼相對應的購買歷史信息（參乙證39說明書摘要及解決方案，本院卷㈡第117頁）。 ②附圖九中之圖1 至4 及段落【0047】、【48】揭露「當用戶以現金換取產品時，商品銷售者的管理裝置2 之唯一號碼發布手段發布22唯一號碼（步驟1 被稱為s1，以下相同），並通過收據通知用戶並被傳遞到購買信息傳送手段23，使購買信息傳送手段23具備包括唯一號碼的產品的購買有關的購買歷史信息，並經由通信控制手段21利用通信網絡4 傳送到信息提供者的服務器裝置3 （s2）。信息提供者服務器裝置3 的購買信息存儲手段32通過通信控制手段經由通信網絡4 接收包括唯一號碼的購買歷史信息，並將其存儲（s3）。當接收唯一號碼的用戶端裝置1 通過通信網絡4 訪問信息提供者服務器裝置3 並發送唯一號碼時（s4），信息提供者服務器裝置之購買信息發送手段33通過通信控制手段31經由通信網絡4 接收唯一號碼，並從購買信息存儲手段32中搜索與該唯一號碼相對應的購買歷史信息，將與該唯一號碼相對應的購買歷史信息通過通信網絡4 被發送到終端裝置1 （s5）」（參本院卷㈡第137 至138 頁）。換言之，當用戶購買產品後，產品銷售者的管理裝置2 會發行一個唯一編號，並將其印在收據上，並讓用戶知道該號碼（s1），並且與包括唯一號碼的商品的購買有關的購買歷史信息通過通信網絡4 被傳送（s2）並存儲到信息提供者的服務器裝置3 （s3）。當用戶通過通信網絡4 從終端設備1 向伺服器設備3 發送唯一號碼時，伺服器設備3 檢索出該對應於唯一編號的購買履歷信息，服務器裝置3 通過通信網絡4 向客戶端設備1 或在該客戶端設備上運行的軟體發送與該唯一號碼相對應的購買歷史信息（s4）。 ⒏乙證37 ⑴乙證37為2010年11月18日財政部公告並生效之「實體消費通路開立電子發票試辦作業要點」，公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證37之第3 條名詞定義「（7 ）歸戶：指以買受人或載具識別碼作為辨識資訊以儲存電子發票於整合服務平台」（參本院卷㈡第65頁）。 ⒐乙證38（主要圖式如附圖十所示） ⑴乙證38為Amazon SNS開發者指南（Amazon simple notification service developer guide）第38、39頁（乙證41為完整文件，乙證43為引用內容之中文節譯本），該指南每頁之頁尾均標示「API Version 0000-00-00」，堪認為2010年3 月31日公開，其公開日早於系爭專利申請日（101 年5 月8 日），可為系爭專利之先前技術。 ⑵乙證38之技術內容 ①Amazon SNS行動推播通知可以將推播通知直接傳送到行動裝置上的應用程式，傳送到行動終端的推播通知訊息在應用程式中可以以訊息警示，標示更新甚至聲音警示來顯示。應用程式開發人員可以使用以下任一個有支援的推播通知服務來將推播通知傳送到行動裝置。即Amazon裝置訊息傳送AmazonDevice Messaging（ADM ）、蘋果推播通知服務Apple PushNotification Service（APNS）、百度雲端推播Baidu Cloud Push（Baidu ）、谷歌雲端訊息傳遞（安卓）Google Cloud Messaging for Android（GCM ）、微軟推播通知服務（Windows 手機）Microsoft Push Notification Service for Windows Phone （MPNS）、Windows 推播服務通知Windows Push Notification Services（WNS ）（參本院卷㈡第71、413 頁）。 ②推送通知服務（如APNS和GCM ）保持與每個註冊的應用程式和關聯的行動裝置連接，以使用其服務（參乙證43第38頁第1 至2 行，本院卷㈡第413 頁）。當應用程式和行動裝置註冊時，Amazon SNS會回復其裝置標記（device token）。Amazon SNS使用裝置標記（device token) 來建立行動終端節點，使其可以向行動裝置直接推送通知消息（參乙證43第39頁第1 至2 行，本院卷㈡第414 頁）。要開始使用Amazon SNS 移動推送通知，您首先需要一個有使用以下支援的推播通知服務的行動終端應用程式：ADM 、APNS、Baidu 、GCM 、MPNS或WNS 。註冊並配置應用程式使用這些任一個服務後，即可配置Amazon SNS以將推送通知消息發送到行動終端。使用推送通知服務註冊應用程式需要幾個步驟。Amazon SNS需要您提供給推送通知服務的一些信息，以便將直接推送通知消息發送到行動終端。一般來說，您需要有與推播通知服務連接的憑證，從推播通知服務接收到的裝置標記或註冊ID（代表您的行動設備和行動應用程式）及在推播通知服務中註冊的行動應用程式。具體名稱將根據所使用的推播通知服務而不同，例如，使用APNS當作推播通知服務時，需要裝置標記，或者，當使用GCM 時，相同的裝置標記稱為註冊ID。裝置標記和註冊ID是行動應用程式和裝置的唯一識別碼（乙證43第39頁第12至23行，本院卷㈡第414 頁）。五、得心證之理由原告主張其為系爭專利之專利權人，現仍於專利權期間內，詎被告睿點公司未經原告同意或授權，即將系爭產品提供在App Store 及Google Play 等線上平台供大眾下載，系爭產品背後所使用之系爭方法落入系爭專利請求項1 之專利權範圍，業已侵害原告之專利權，則為被告等所否認，並以前詞置辯。是本件經整理並協議簡化爭點後（本院卷㈢第31頁），所應審究者為：㈠請求項解釋：系爭專利請求項1 之「電子發票訊息」、「電子發票資料」應如何解釋？㈡專利侵權部分：系爭產品背後用以與系爭產品相連結之伺服器內所使用方法是否落入系爭專利請求項1 之文義範圍？㈢專利有效性部分：⒈系爭專利說明書是否違反專利法第26條第1 項規定？⒉系爭專利請求項1 是否違反專利法第26條第2 項規定？⒊乙證10、11、21、22、23之組合是否可以證明系爭專利請求項1 不具進步性？⒋乙證10、11、21、35至38之組合是否可以證明系爭專利請求項1 不具進步性？㈣原告依專利法第96條第2 項、第97條第1 項第1 款、公司法第23條第2 項之規定，請求被告等連帶負損害賠償責任，有無理由？若有，其損害賠償金額應如何計算？以若干為適當？茲分述如下：㈠申請專利範圍用語解釋：按發明專利權範圍，以申請專利範圍為準，於解釋申請專利範圍時，並得審酌說明書及圖式，專利法第58條第4 項定有明文。判斷系爭產品是否侵害專利權，首先應依申請專利範圍為準，並得參酌說明書內容解釋請求項中之用語，惟不得將說明書中所載之限制條件讀入申請專利範圍，倘說明書並無定義，則須依通常習慣總括之意義予以解釋。又解釋請求項所使用之證據包括內部證據與外部證據，其內部證據係包括請求項之文字、說明書、圖式及申請歷史檔案資料。準此，申請專利範圍之文字僅記載專利之構成要素，為確定其實質內容，自得參酌說明書或圖式所揭示之目的、作用及效果。本件系爭專利請求項1 之「電子發票訊息」、「電子發票資料」申請專利範圍用語應解釋如下： ⒈「電子發票訊息」部分： ⑴系爭專利說明書第3 頁【先前技術】記載「為響應紙張減量使用的要求，以符節能減碳之環保訴求，政府機關乃大力推行電子發票之開立，以取代行之已久之傳統紙本發票，使能逐步朝向發票無紙化之最終目標，…關鍵乃在於消費者認為電子發票欠缺傳統紙本發票中持有與對獎便利性之雙重障礙。為解決此一問題，中華民國新型專利第M398160 號及第M417618 號等，乃分別提出一種電子發票管理系統，用以將商家所開立之電子發票歸戶，並提供消費者查詢、自動對獎，再選擇性地以電子郵件或簡訊通知消費者等，以解決發票持有與對獎便利性之障礙。惟此一通知方法，或因郵件通知之欠缺通知即時性，或因簡訊通知之成本考量，以致尚難真正解決前述電子發票達到無紙化目標之難題。」（本院卷㈠第88至89頁）。又系爭專利說明書第4 至5 頁【發明內容】記載「本發明之目的是提供一種電子發票訊息傳送方法，其可藉由行動裝置之作業系統業者所提供之推播訊息服務，來將電子發票開立資料或電子發票中獎通知資料，免費且即時地傳送給消費者，一併解決了發票持有與對獎便利性之障礙」、「為達上述及其他目的，本發明提供一種電子發票訊息傳送方法，適用於管理電子發票之伺服主機。此方法在接收到電子發票訊息傳送服務要求時，即依據電子發票訊息傳送服務要求中內含之載具識別碼，來查詢取得與載具識別碼相關連之一行動裝置的行動裝置作業系統類別與其推播訊息記號，之後，再依據查詢取得之行動裝置作業系統類別與推播訊息記號，來將電子發票訊息傳送服務要求中內含之電子發票資料傳送至推播訊息記號所代表之行動裝置上」及「由於本發明所提供之一種電子發票訊息傳送方法，其係藉由行動裝置之作業系統業者所提供之推播訊息服務，來將電子發票開立資料或電子發票中獎通知資料，免費且即時地傳送給消費者。因此，可一併解決前述發票持有與對獎便利性之障礙，達成電子發票真正無紙化之目標」（本院卷㈠第89至90頁）。另系爭專利說明書第8 頁倒數第5 行至第9 頁第17行記載「請參圖4 所示，其係根據本發明較佳實施例之一種電子發票訊息傳送方法流程圖。圖中，當消費者在銷售櫃臺13要求開立電子發票並進行歸戶時（步驟401 ），銷售櫃臺13即將其載具識別碼與電子發票開立資料上傳至電子發票平台（步驟402 ），並由電子發票平台來提出電子發票訊息傳送服務要求。當然，電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求。在步驟403 中，當伺服主機11收到電子發票訊息傳送服務要求時，即進入步驟404 中判斷是否為會員？如否，則進入步驟405 ，以通知註冊加入會員。反之，如已為會員時，則在步驟406 中，依據電子發票訊息傳送服務要求中內含之載具識別碼，來查詢取得與載具識別碼相關連之行動裝置的行動裝置作業系統類別與其推播訊息記號等歸戶資料，之後，再於步驟407 中，判斷行動裝置15之作業系統類別，以分別在步驟408 、409 與410 中，依據所查詢取得之行動裝置作業系統類別與推播訊息記號，來將電子發票訊息傳送服務要求中內含之電子發票資料傳送至推播訊息記號所代表之行動裝置15上」（本院卷㈠第93至94頁）。 ⑵由上開內容，可知系爭專利之「電子發票訊息」傳送方法係藉由行動裝置之作業系統業者所提供之推播訊息服務，來將電子發票資料，推播給消費者之行動裝置，系爭專利之「電子發票訊息」傳送服務要求包含欲推播之電子發票資料及可獲得行動裝置作業系統類別與推播訊息記號之資料。因此，「電子發票訊息」係有關於電子發票資料之推播通知，故系爭專利請求項1 之「電子發票訊息」應解釋為「和電子發票資料相關的推播通知」。 ⒉「電子發票資料」部分 ⑴系爭專利說明書第4 頁倒數第3 行至第5 頁第1 行記載「此電子發票訊息傳送方法之電子發票資料，可以是電子發票開立資料或電子發票中獎通知資料，當然，其亦可以是與此依消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息」（本院卷㈠第89至90頁）。系爭專利說明書第9 頁【實施方式】記載「當然，電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求」（本院卷㈠第94頁）。 ⑵由上開內容及前述㈠⒈⑴之系爭專利說明書【先前技術】、【發明內容】之內容，可知系爭專利之「電子發票資料」可以是電子發票開立資料、電子發票中獎通知資料、電子發票相關之商家訊息或會員服務的通知訊息等。因此，「電子發票資料」係有關於電子發票之相關資料，如電子發票開立資料、電子發票中獎通知資料或與開立之電子發票相關之商家訊息或會員服務的訊息等資料，故系爭專利請求項1 之「電子發票資料」應解釋為「電子發票相關資料，如電子發票開立資料、電子發票中獎通知資料、與開立之電子發票相關之商家訊息或會員服務的訊息等資料」。 ⒊至被告等雖辯稱系爭專利請求項1 並未定義何謂電子發票訊息、電子發票資料，故此之「電子發票」依據系爭專利申請時所適用之100 年5 月12日修正之「統一發票使用辦法」、99年11月15日修正之「電子發票實施作業要點」規定，應解釋為網際網路或其他電子方式開立、傳輸或接收之統一發票、電子發票記載應包括交易日期、品名、數量、單價、金額、銷售額、課稅別、稅額、總計及字軌號碼等語。惟按發明專利權範圍，以申請專利範圍為準，於解釋申請專利範圍時，並得審酌說明書及圖式，專利法第58條第4 項定有明文。因此，判斷系爭產品是否侵害專利權，首先應依申請專利範圍為準，依申請專利範圍解釋原則，申請專利範圍所載技術特徵不明確時，固得參酌說明書與圖式解釋，惟申請專利範圍所載技術特徵明確時，即不得將說明書中所載之限制條件讀入申請專利範圍，倘說明書並無定義，則須依通常習慣總括之意義予以解釋。又解釋申請專利範圍所使用之證據包括內部證據與外部證據，其內部證據係包括請求項之文字、說明書、圖式及申請歷史之檔案資料；而內部證據優先於外部證據，若內部證據足使申請專利範圍清楚明確，則無須考慮外部證據，若外部證據與內部證據對於申請專利範圍之解釋有衝突或不一致者，則優先採用內部證據。而依系爭專利說明書第5 頁第14行至第17行、第4 頁倒數第3 行至第5 頁第1 行、第9 頁之記載，系爭專利請求項1 之「電子發票訊息」、「電子發票資料」應解釋如上，業如前述，是以系爭專利說明書之內部證據已經足以使申請專利範圍清楚明確，尚無須考慮外部證據；況且，系爭專利請求項1 內容為「一種電子發票訊息傳送方法，適用於管理電子發票之一伺服主機，……；接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料；……，來將該電子發票資料傳送至該推播訊息記號所代表之該行動裝置上」（本院卷㈠第96頁），依其記載內容，系爭專利請求項1 所載技術特徵係界定以「電子發票訊息」、「電子發票資料」之技術特徵用語，非僅以「電子發票」為技術特徵用語，尚難以上開「統一發票使用辦法」、「電子發票實施作業要點」相關規定中之「電子發票」作為解釋系爭專利請求項之內容，是被告等上開所辯，尚非可採。㈡專利侵權部分：系爭產品背後用以與系爭產品相連結之伺服器內所使用方法已落入系爭專利請求項1 之文義範圍： ⒈經解析系爭專利請求項1 範圍，其技術特徵可解析為5 個要件，分別為：⑴要件編號1A：「一種電子發票訊息傳送方法，適用於管理電子發票之一伺服主機，包括下列步驟」；⑵要件編號1B：「收集、記錄與一行動裝置相關連之一載具識別碼、一行動裝置作業系統類別與一推播訊息記號」；⑶要件編號1C：「接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」；⑷要件編號1D：「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及」；⑸要件編號1E：「依據該行動裝置作業系統類別與該推播訊息記號，來將該電子發票資料傳送至該推播訊息記號所代表之該行動裝置上」。 ⒉就系爭方法與系爭專利請求項1 之各特徵要件之文義比對：⑴要件編號1A：當電子載具存入手機安裝之系爭產品後，後續若使用者進行消費而有雲端載具發票，系爭產品將會收到「您有新的載具發票進來囉！（共X 張）」之推播通知（即原證5 、原證14之影片），可知系爭產品背後用以與系爭產品相連結之伺服主機，該伺服主機為適用於管理電子發票之伺服主機。因此，系爭方法應為系爭專利請求項1 之要件編號1A「一種電子發票訊息傳送方法，適用於管理電子發票之一伺服主機，包括下列步驟」所文義讀取。 ⑵要件編號1B：使用者於手機上安裝系爭產品後，當開啟系爭產品並連線背後之伺服主機，即會出現「使用者條款與隱私權政策」畫面，告知蒐集資料包括：「機器屬性、LOG 、發票及相關消費資料」等（本院卷㈠第505 頁），當使用者同意隱私權政策後，在【註冊/ 登入】頁面必須申請或輸入【電子載具（手機條碼）】，並輸入【手機號碼】、【驗證碼】，在「會員資料與設定」畫面（本院卷㈠第507 頁），可以查詢到手機號碼、電子載具、電子載具驗證碼已經儲存於系爭產品中，可知系爭產品背後之伺服主機有收集、紀錄載具識別碼（即前述電子載具〈手機條碼〉）、行動裝置作業系統類別（即前述機器屬性）等資訊。再者，系爭產品首頁開啟按右上角管理介面，即進入「進階功能」畫面，可開啟【載具發票推播提醒】功能（本院卷㈠第509 頁），並進一步設定推播是否有聲音、推播之顯示位置等，可知使用者開啟推播通知係讓伺服主機收集、紀錄行動裝置之推播訊息記號。因此，系爭方法為系爭專利請求項1 之要件編號1B「收集、記錄與一行動裝置相關連之一載具識別碼、一行動裝置作業系統類別與一推播訊息記號」所文義讀取。 ⑶要件編號1C： ①有關要件編號1C中所謂「接收」一詞，被告固辯稱以系爭專利說明書第8 頁倒數第5 行至第9 頁第8 行「請參圖4 所示，其係根據本發明較佳實施例之一種電子發票訊息傳送方法流程圖。……銷售櫃台13即將其載具識別碼與電子發票開立資訊上傳至電子發票平台（步驟402 ），並由電子發票平台來提出電子發票訊息傳送服務要求。……在步驟403 中，當伺服主機11收到電子發票訊息傳送服務要求時，即進入步驟404 …」（本院卷㈠第93至94頁）之內容，應將「接收」為伺服主機僅「被動」接收由另一資訊整合平台（即財政部電子發票整合服務平台）主動發送電子發票訊息傳送服務要求至該伺服主機，而非由「伺服主機主動查詢後再接收」獲得相關電子發票資訊等語。惟上開說明書內容已明確記載「圖4 所示，其係根據『本發明較佳實施例』之一種電子發票訊息傳送方法流程圖」，可知該圖式僅為例示之性質，非代表請求項應完全限定於圖式之實施態樣；再者，系爭專利說明書第9 頁第1 至6 行亦記載「當然，電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求」，所述「其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時」，即係伺服主機利用財政部財政資訊中心提供之電子發票應用程式介面（API ），向財政部電子發票平台主動查詢後再接收資料之情境，所述「電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料」，則係財政部電子發票平台主動提供中獎資訊，伺服主機被動接收之情境，故無論是「被動接收」或「主動向另一伺服器查詢後之接收」，均為系爭專利可能之方式。是以，系爭專利請求項1 要件編號1C之「接收」，既未限定僅能從另一資訊整合平台主動發送後之接收，自不應將被動接收之圖4 實施例讀入請求項內，而不當限縮系爭專利請求項1 之範圍，而應解釋為包含：伺服主機「被動接收」由另一伺服器主動發送之資訊之情形，以及伺服主機「主動向另一伺服器查詢後之接收」，亦即伺服主機主動向另一伺服器查詢後，另一伺服器回傳查詢結果給伺服主機，使伺服主機接收之情形，此兩種接收情形均屬於系爭專利請求項1 之要件1C所述「接收」。被告等上開所辯尚非可採。 ②電子發票資料為我國財政部電子發票整合服務平台所管理之專屬資料，且該專屬資料不可能直接從商家端取得，財政部電子發票整合服務平台亦不會主動對第三方主機提出電子發票訊息傳送服務要求等情，為兩造所不爭執（本院卷㈠第76頁、卷㈡第88頁、卷㈢第47頁）；而依原告主張系爭方法之伺服主機係依先前收集、紀錄之手機號碼、載具識別碼、行動裝置機屬性及推播訊息記號，當有新增消費時，即會登入財政部電子發票平台取得與前所收集載具識別碼相關聯之消費紀錄，藉此得知有電子發票訊息傳送服務要求等語（本院卷㈡第89至90頁），亦即財政部電子發票整合服務平台將會回傳電子發票訊息傳送服務要求，而使得伺服主機接收電子發票訊息傳送服務要求。又兩造均自承APP 主動查詢後之接收，財政部電子發票平台有公布應用之API 規格書，所有之訊息介接均應依API 規格書處理（本院卷㈢第334 頁），被告等復確認所使用之API 規格書即為版本1.7 之「電子發票應用API 規格」，並陳稱系爭方法係先以該API 規格書第21頁之載具識別碼向財政部電子發票平台查詢相關發票資訊，知道特定發票後，才會用該API 規格書第16至18頁去查詢發票明細等語（本院卷㈢第335 頁），堪認系爭方法是先以上開API 規格書第21至24頁之「載具發票表頭查詢」功能向財政部電子發票平台查詢載具識別碼所持有之雲端發票，知悉特定發票號碼後，再用該API 規格書第16至18頁之「查詢發票明細」功能內容向財政部電子發票平台查詢該發票號碼之消費明細資料。 ③依據上開API 規格書第21至24頁之規範內容，「載具發票表頭查詢」功能係依載具卡別及載具隱碼（即載具識別碼）查詢載具內所持有之雲端發票，財政部電子發票整合服務平台回傳或發送包含有多筆發票之發票號碼、載具隱碼、發票總金額、對獎期別及開立日期等資料（本院卷㈢第306 至309 頁）。又依據該API 規格書第16至18頁之規範內容，「查詢發票明細」功能係以發票號碼查詢消費明細資料，財政部電子發票整合服務平台回傳包含有發票號碼、對獎期別、開立日期及消費明細等資料（本院卷㈢第301 至303 頁）。由上規範內容，可知在「載具發票表頭查詢」步驟中，財政部電子發票平台所回傳或發送之載具隱碼相當於載具識別碼，所回傳或發送之發票號碼、發票總金額、期別及開立日期等資料相當於電子發票資料。綜上，系爭方法在使用上開「載具發票表頭查詢」步驟時，因財政部電子發票平台回覆或發送包含有發票號碼、載具隱碼、發票總金額、對獎期別及開立日期等資料，使得系爭產品背後之伺服主機「接收財政部電子發票平台所回覆之一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」。是以，系爭方法為系爭專利請求項1 之要件編號1C「接收一電子發票訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」所文義讀取。 ⑷要件編號1D、1E：伺服主機之前已收集、紀錄行動裝置之手機號碼、載具識別碼、行動裝置作業系統類別與推播訊息記號等資料於其資料庫，已如前述，則就所收集之資料間，伺服主機必然得利用收集欄位資料進行查詢，故系爭方法為系爭專利請求項1 之要件1D「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及」所文義讀取。此外，當系爭產品背後用以與系爭產品相連結之伺服主機利用電子發票應用API規格書「載具發票表頭查詢」功能及「查詢發票明細」功能查詢到該發票號碼之消費明細資料後，後續系爭產品將會收到「您有新的載具發票進來囉！（共X 張）」之推播通知，可知伺服主機已依先前所收集、紀錄之行動裝置機器屬性及推播訊息記號將電子發票資料傳送至推播訊息所關聯之消費者的行動裝置上；因此，系爭方法為系爭專利請求項1 之要件編號1E「依據該行動裝置作業系統類別與該推播訊息記號，來將該電子發票資料傳送至該推播訊息記號所代表之該行動裝置上」所文義讀取。 ⒊綜上，系爭產品背後用以與系爭產品相連結之伺服器內所使用方法（系爭方法）已落入系爭專利請求項1 之文義範圍。㈢專利有效性部分 ⒈系爭專利說明書未違反專利法第26條第1項規定 ⑴按說明書應明確且充分揭露，使該發明所屬技術領域中具有通常知識者，能瞭解其內容，並可據以實現，專利法第26條第1 項定有明文。又說明書作為技術文件，應明確且充分揭露申請專利之發明，使公眾能利用該發明，而申請人能據以主張該發明。因此，說明書形式上應敘明發明名稱、技術領域、先前技術、發明內容、圖式簡單說明、實施方式及符號說明等；其內容應明確且充分揭露申請專利之發明，使該發明所屬技術領域中具有通常知識者能瞭解該發明的內容，並可據以實現（即可據以實現要件）。說明書之記載是否已明確且充分揭露，須在說明書、申請專利範圍及圖式三者整體之基礎上，參酌申請時之通常知識予以審究。而說明書應明確且充分揭露，指說明書之記載必須使該所屬技術領域中具有通常知識者能瞭解申請專利之內容，而以其是否可據以實現為判斷之標準。 ⑵被告等雖提出系爭專利說明書第【0024】、【0025】段係記載「銷售櫃臺13即將其載具識別碼與電子發票開立資料上傳至電子發票平台（步驟402 ），並由電子發票平台來提出電子發票訊息傳送服務要求。當然，電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求……」，惟所謂電子發票平台，按申請時之通常知識，係95年12月6 日上線運作之財政部電子發票整合服務平台，然系爭專利說明書前述內容記載不清，不知「電子發票平台」究竟指財政部電子發票整合服務平台或尚有其他第三人之可能；此外，系爭專利請求項1 要件編號1C之「接收」，因依內部證據之系爭專利說明書全文僅有電子發票平台主動提出電子發票訊息傳送服務要求，伺服主機係單純接收，但不知該要求自何發出？包含何種傳送內容？何種傳送動作？所屬技術領域中具有通常知識者無從實施接收步驟；若主動查詢亦包含於該範圍內，則說明書至少應將如何主動查詢、對應伺服器為何、如何連接API 、連接後如何對應取得相應資料及欄位等必要技術特徵予以描述，否則系爭專利說明書內容實無法據以實現等語。惟查： ①由系爭專利說明書第4 至5 頁【發明內容】（本院卷㈠第89至90頁），可知系爭專利所欲解決之問題乃為如何將電子發票資料免費且即時地傳送給消費者；又依系爭專利說明書第8 頁倒數第5 行至第9 頁第6 行揭露「請參圖4 所示，其係根據本發明較佳實施例之一種電子發票訊息傳送方法流程圖。圖中，當消費者在銷售櫃臺13要求開立電子發票並進行歸戶時（步驟401 ），銷售櫃臺13即將其載具識別碼與電子發票開立資料上傳至電子發票平台（步驟402 ），並由電子發票平台來提出電子發票訊息傳送服務要求。當然，電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求」之內容（本院卷㈠第93至94頁），已明確可知電子發票訊息傳送服務要求係由電子發票平台所發出，傳送內容包括但不限於電子發票開立通知、電子發票中獎通知、商家訊息或會員服務通知訊息等之電子發票資料，且傳送動作為電子發票平台透過網際網路將電子發票訊息傳送服務要求至伺服主機上，系爭專利說明書之前述記載已明確且充分揭露該要求自何發出、包含何種傳送內容及何種傳送動作。另依系爭專利說明書第8 頁倒數3 行記載「銷售櫃臺13即將其載具識別碼與電子發票開立資料上傳至電子發票平台（步驟402 ），並由電子發票平台來提出電子發票訊息傳送服務要求」，可知系爭專利界定之電子發票平台必須具有接收銷售櫃台傳送之電子發票開立資料、管理電子發票相關資訊並提出電子發票訊息傳送服務之功能，雖未明確指明電子發票平台名稱，惟目前我國法規規定電子發票資料為我國財政部電子發票整合服務平台所管理之專屬資料，並由財政部電子發票平台提供應用API 規格書予給應用程式開發者介接，所屬技術領域中具有通常知識者在說明書、申請專利範圍及圖式三者整體之基礎上，參酌申請時之通常知識，即能瞭解系爭專利所述具有接收銷售櫃台傳送之電子發票開立資料、管理電子發票相關資訊並提出電子發票訊息傳送服務之功能之電子發票平台，即為財政部電子發票整合服務平台。②由系爭專利說明書第9 頁記載「電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求」（本院卷㈠第94頁），可知系爭專利例示了「電子發票開立資料通知」、「電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料」之單純接收情境，也例示了「其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時」之主動查詢情境；因此，無論是「被動接收」或「主動向另一伺服器查詢後之接收」，均為系爭專利具體例示之情境，難謂系爭專利沒有任何有關伺服主機主動查詢之說明。再者，電子發票資料既為財政部電子發票整合服務平台所管理之專屬資料，財政部電子發票平台公布之電子發票應用API 規格書係作為應用程式開發者之基本工具，則對於該API 規格書記載之如何查詢、對應伺服器為何、如何連接API 、連接後如何對應取得相應資料及欄位等，即為該發明所屬技術領域中具有通常知識者所應具有之通常知識，自無須詳載於說明書中。 ⑶綜上，系爭專利說明書內容可瞭解其內容並據以實現，未違反專利法第26條第1 項規定，被告等上開所辯，尚屬無據。⒉系爭專利請求項未違反專利法第26條第2項規定： ⑴按申請專利範圍應界定申請專利之發明；其得包括一項以上之請求項，各請求項應以明確、簡潔之方式記載，且必須為說明書所支持，專利法第26條第2 項定有明文。又所謂請求項應明確，指每一請求項之記載應明確，且所有請求項整體之記載亦應明確，使該發明所屬技術領域中具有通常知識者，單獨由請求項之記載內容，即可明確瞭解其意義，而對其範圍不會產生疑義，而請求項必須為說明書所支持，係要求每一請求項記載之申請標的必須根據說明書揭露之內容為基礎，且請求項之範圍不得超出說明書揭露之內容。 ⑵被告等雖辯稱系爭專利請求項1 之要件編號1C「一電子發票訊息傳送服務要求」意義及其範圍顯屬有疑，所屬技術領域具有通常知識者無法瞭解其意義，違反請求項應明確並可為說明書支持之記載原則；又請求項1 係由「伺服主機」傳送電子發票資料至行動裝置，然於系爭專利說明書並無相關記載或說明，通篇未解釋如何由伺服主機傳送電子發票資料至行動裝置，反係於系爭專利說明書第【0026】段及圖4 提及電子發票資料乃係由「行動裝置作業系統類別之推播訊息服務主機」執行傳送動作，傳送電子發票資料之主體不同，所使用之傳送技術及方式自當不同，系爭專利請求項1 技術特徵「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號」無法為說明書所支持等語。經查： ①有關系爭專利請求項1 之「電子發票訊息傳送服務要求」之意義及範圍，由上開系爭專利說明書第8 頁倒數第5 行至第9 頁第6 行所揭露之內容，已足知悉電子發票訊息傳送服務要求係由電子發票平台所發出，傳送內容包括但不限於電子發票開立通知、電子發票中獎通知、商家訊息或會員服務通知訊息等之電子發票資料，且傳送動作為電子發票平台透過網際網路將電子發票訊息傳送服務要求至伺服主機上，業如前述，故該發明所屬技術領域中具有通常知識者能明確瞭解系爭專利請求項1 要件編號1C之「一電子發票訊息傳送服務要求」意義及其範圍。 ②經查，有關系爭專利請求項1 之電子發票訊息如何傳送到欲傳送的目標之行動裝置，系爭專利請求項1 已界定「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及依據該行動裝置作業系統類別與該推播訊息記號，來將電子發票資料傳送至該推播訊息記號所代表之該行動裝置上」技術特徵，可知依據該行動裝置作業系統類別與該推播訊息記號，即可將所欲傳送之內容傳送到行動裝置上。此外，系爭專利說明書第9 頁揭露「電子發票訊息傳送服務要求並不限於電子發票開立通知，其亦可在電子發票平台定期自動進行電子發票對獎而確認有電子發票中獎通知資料、或其他與消費行為所開立之電子發票相關之商家訊息或會員服務的通知訊息需傳送時，提出此一電子發票訊息傳送服務要求」、「在步驟403 中，當伺服主機11收到電子發票訊息傳送服務要求時，……，以分別在步驟408 、409 與410 中，依據所查詢取得之行動裝置作業系統類別與推播訊息記號，來將電子發票訊息傳送服務要求中內含之電子發票資料傳送至推播訊息記號所代表之行動裝置15上。」、「行動裝置作業系統類別包含有步驟408 之蘋果公司開發的iOS 、步驟409 之谷歌公司開發的Android 及步驟410 之微軟公司開發的Mango 作業系統。其係分別透過蘋果公司之推播訊息服務主機（Apple Push Notification Service ）、谷歌公司之推播訊息服務主機（Google C2DM ）或微軟公司之推播訊息服務主機（Microsoft Push Notification Service ），來傳送至消費者之行動裝置15上」（本院卷㈠第94頁），可知該電子發票訊息傳送服務要求係由不特定之欲傳送電子發票訊息之主機向伺服主機11提起，伺服主機11接收電子發票訊息傳送服務要求後，依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號，在一較佳實施例中，分別透過蘋果公司、谷歌公司或微軟公司之推播訊息服務主機，將欲傳送的內容傳送到欲傳送的目標之行動裝置15上，前述揭露內容可支持系爭專利請求項1 界定之「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號」技術特徵，且系爭專利請求項1 之記載與說明書並無不一致。⑶綜上，系爭專利請求項1 應屬明確並可為說明書支持，未違反專利法第26條第2 項規定。 ⒊乙證10、11、21至23之組合及乙證10、11、21、35至38之組合均足以證明系爭專利請求項1 不具進步性： ⑴依前述乙證10之技術內容與系爭專利請求項1相較： ①乙證10說明書第7 頁記載「本創作之電子發票管理系統20，包含有一中央單元24，……，該中央單元24包含有一發票總資料庫243 及一發票管理平台241 」（本院卷㈠第169 頁）、第12頁記載「先於發票管理平台中建立對應於該個人識別碼之總發票帳戶，再匯入對應於該個人識別碼之發票資料。而發票管理平台建立該總發票帳戶後，亦可傳送該帳戶之密碼至該用戶裝置，以供用戶管理其總發票帳戶」（本院卷㈠第174 頁），可知乙證10之電子發票管理系統具有中央單元伺服主機提供用戶管理電子發票及對用戶傳送訊息之功能。又由說明書第11至12頁記載「店家平台於建立帳戶後，將該帳戶之密碼傳送至該用戶之用戶裝置」（本院卷㈠第173 至174 頁）、第11頁記載「之後可將發票代碼與消費明細表傳送至該用戶之用戶裝置」（本院卷㈠第173 頁），可知乙證10之電子發票管理系統亦具有店家單元伺服主機提供對用戶傳送電子發票消費明細之功能，相當於系爭專利請求項1 之要件編號1A「一種電子發票訊息傳送方法，適用於管理電子發票之一伺服主機，包括下列步驟：」技術特徵。 ②乙證10說明書第11頁記載「若選擇使用電子發票，則請用戶提供個人識別碼」（本院卷㈠第173 頁）、第12頁記載「個人識別碼可選擇為身分證字號、電話號碼、電子郵件信箱、公司登記之統一編號、特定帳戶等等具有唯一性且可代表該用戶之識別碼。而用戶裝置則可選擇為行動電話、電腦、個人數位助力、筆記型電腦、及多媒體機等可連線至網路或通訊網路，並具有顯示器之裝置」（本院卷㈠第174 頁）、第10頁記載「每張電子發票皆可在發票管理平台241 中以對應於個人識別碼293 之總發票帳戶進行查詢與管理」（本院卷㈠第172 頁）、第12頁記載「發票管理平台建立該總發票帳戶後，亦可傳送該帳戶之密碼至該用戶裝置」（本院卷㈠第174 頁），可知因乙證10之中央單元利用個人識別碼作為用戶之總發票帳戶，且可以對用戶裝置傳送訊息，該個人識別碼對應於系爭專利請求項1 之「與一行動裝置相關連之一載具識別碼」，乙證10前述揭露內容相當於系爭專利請求項1 之要件編號1B前段「收集、記錄與一行動裝置相關連之一載具識別碼」之技術特徵。 ③由上可知，乙證10與系爭專利請求項1 之差異即在於：乙證10僅揭露傳送訊息，未特定以推播傳送訊息，故而未揭露系爭專利請求項1 之要件編號1B後段「收集、記錄…一行動裝置作業系統類別與一推播訊息記號」、要件編號1C「接收一…訊息傳送服務要求，該電子發票訊息傳送服務要求至少包含有該載具識別碼與一電子發票資料」、要件編號1D「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及」及要件編號1E「依據該行動裝置作業系統類別與該推播訊息記號，來將該電子發票資料傳送至該推播訊息記號所代表之該行動裝置上」之技術特徵。 ⑵上開差異部分，再依前述乙證11之技術內容與系爭專利請求項1 相較： ①乙證11說明書第13頁揭露一種「分散式運算之推拉式資訊服務系統10係包括有一資訊服務伺服器20以及至少一客戶端裝置30其遠離於該伺服器20」、「該客戶端裝置30可藉由一通訊媒介50來連接並登入伺服器20以供透過一推送技術或一拉取技術來擷取伺服器20中所儲存的資訊」（本院卷㈠第197 頁），說明書第14頁揭露「該資訊服務伺服器20所提供的資訊係包括至少一第一種與一第二種的資訊。該第一種資訊將會以推送的方式傳送給客戶端裝置，例如廣播」（本院卷㈠第198 頁），說明書第19頁揭露「該即時廣播模組223 可廣播第一種資訊給遠離於該伺服器20的複數個客戶端裝置30」（本院卷㈠第203 頁），可知乙證11之該伺服器可藉由廣播推送的方式提供第一種資訊給客戶端裝置。 ②乙證11說明書第20頁揭露「該客戶資料庫228 儲存有客戶端裝置之客戶資料。這客戶資料至少包括了客戶端裝置30的授權有效性資料」（本院卷㈠第204 頁），說明書第21頁揭露「（A ）授權資料流：由一使用者61藉由該使用者介面33來操作客戶端裝置30並將他/ 她的帳號、密碼、及IMEI硬體機碼（或是例如UID 之另一獨一號碼）經由智慧傳輸模組226 傳給伺服器20之授權帳單模組225 」（本院卷㈠第205 頁），即使用者操作客戶端裝置30將IMEI硬體機碼傳給伺服器20，由上述內容可知，伺服器20之客戶資料庫中收集、記錄授權有效性資料，包括帳號、密碼、IMEI硬體機碼等客戶資料，其中IMEI（International Mobile Equipment Identity 國際移動設備識別碼）硬體機碼即行動裝置身分證，用於在網路中辨識每一部獨立的行動通訊裝置，使得授權資料流可確認客戶端裝置之授權有效性，而進行廣播；又IMEI之序列號共有15位數字，前6 位代表手機類型，從手機類型即直接無歧異得知一行動裝置作業系統類別，是IMEI硬體機碼除對應於系爭專利之推播訊息記號外，亦對應於系爭專利之行動裝置作業系統類別。因此，乙證11揭露伺服器20之客戶資料庫中收集、記錄IMEI硬體機碼（含前6 位手機類型）已揭露系爭專利請求項1 之要件編號1B後段「收集、記錄…一行動裝置作業系統類別與一推播訊息記號」技術特徵。 ③乙證11說明書第21至23頁揭露「（A ）授權資料流：由一使用者61藉由該使用者介面33來操作客戶端裝置30並將他/ 她的帳號、密碼、及IMEI硬體機碼（或是例如UID 之另一獨立號碼）經由智慧傳輸模組226 傳給伺服器20之授權帳單模組225 」（本院卷㈠第205 頁）、「（B ）推送資料流：在客戶端使用者61經由該授權資料流確認其授權有效性後，該客戶端裝置30可以開始執行下列流程。首先，該客戶端裝置30傳送它的個人編輯目錄資訊及存取權給伺服器20的智慧傳輸模組226 。然後，當該智慧傳輸模組226 接收到這些目錄資訊及使用者61之存取權時，其開始過濾由即時資料廣播模組223 根據這目錄資訊與存取權所傳來的資料，然後再將過濾後之資料推送給客戶端裝置30。此推送資料流將於客戶端裝置30關閉連結後結束」（本院卷㈠第207 頁），由上述內容可知，推送資料流係伺服器20接收客戶端裝置30之授權有效性相關資訊（如帳號、IMEI硬體機碼等）後，伺服器20接收來自客戶端裝置30之其個人編輯目錄資訊及存取權。因此，伺服器20所接收之編輯目錄資訊及存取權即為客戶端裝置30請求更新其編輯目錄內容之訊息傳送服務要求，對應於系爭專利之訊息傳送服務要求及訊息資料；又因該訊息傳送服務要求內容係由客戶端裝置30發出且須要伺服器廣播推送資訊回覆，必須包含客戶端裝置之IMEI硬體機碼（載具識別碼）。因此，乙證11揭露伺服器20所接收者即為客戶端裝置30請求更新其編輯目錄內容之訊息傳送服務要求已揭露系爭專利請求項1 之要件編號1C「接收一…訊息傳送服務要求，該…訊息傳送服務要求至少包含有該載具識別碼與一…資料」技術特徵，僅未特定所推送訊息內容為「電子發票資料」及訊息傳送服務要求係針對「電子發票」。 ④乙證11說明書第14頁揭露「該資訊服務伺服器20所提供的資訊係包括至少一第一種與一第二種的資訊。該第一種資訊將會以推送的方式傳送給客戶端裝置，例如廣播」（本院卷㈠第198 頁），說明書第19頁揭露「該即時廣播模組223 可廣播第一種資訊給遠離於該伺服器20的複數個客戶端裝置30」（本院卷㈠第203 頁），說明書第22至23頁揭露「（B ）推送資料流：…當該智慧傳輸模組226 接收到這些目錄資訊及使用者61之存取權時，其開始過濾由即時資料廣播模組223 根據這目錄資訊與存取權所傳來的資料，然後再將過濾後之資料推送給客戶端裝置30」（本院卷㈠第206 至207 頁），由上述內容可知，乙證11揭露伺服器20之即時廣播模組223 透過IMEI硬體機碼（推播訊息記號且其前6 位為行動裝置作業系統類別）及客戶端裝置30請求更新其編輯目錄內容之訊息傳送服務要求，利用一推送技術來將資訊廣播推送給客戶端裝置30，已揭露系爭專利請求項1 之要件編號1E「依據該行動裝置作業系統類別與該推播訊息記號，來將…資料傳送至該推播訊息記號所代表之該行動裝置上」技術特徵，僅未特定所推送訊息內容為「電子發票資料」。 ⑤乙證11雖未特定所推送訊息內容為「電子發票資料」及訊息傳送服務要求係針對「電子發票」，惟乙證10已揭露電子發票管理系統之店家單元伺服主機可傳送電子發票消費明細至用戶裝置，就乙證11揭露客戶端裝置30傳送它的個人編輯目錄與存取權給伺服器20，請求伺服器20就該編輯目錄將過濾後之更新資料推送給客戶端裝置30而言，既然客戶端裝置已經將編輯目錄與存取權交給伺服器，顯然技術上對該編輯目錄傳送之訊息內容為何並無限制，因此上開差異特徵之推送訊息內容或訊息傳送服務要求的編輯目錄為何，均僅係資訊內容選擇之簡單變更，為該發明所屬技術領域中具有通常知識者所能輕易完成者，並未具有無法預期的功效。另乙證10以個人識別碼作為用戶發票歸戶的載具識別碼，並以個人識別碼將發票代碼與消費明細表傳送至該用戶之用戶裝置，可知個人識別碼得為載具識別碼與傳送訊息記號，即載具識別碼與傳送訊息記號之間具有對應關係；又乙證11之IMEI硬體機碼為推播訊息記號，且其前6 位可得到行動裝置作業系統類別，可知推播訊息記號與行動裝置作業系統類別之間具有對應關係，則對於上開差異特徵「依據該載具識別碼查詢取得該行動裝置作業系統類別與該推播訊息記號；以及」之查詢動作，自屬於該發明所屬技術領域中具有通常知識者依其需要為例行工作之簡單變更，並未具有無法預期的功效。 ⑥至原告雖主張乙證11所揭示之拉取式或推送式資訊傳送方法，係推送方式廣播或透過推送技術擷取資料之資訊傳送方式，未使用行動裝置作業系統業者所提供之推播訊息服務來傳送資料，自與系爭專利所使用之行動裝置作業系統業者所提供的推播訊息服務，可以隨時、主動地利用推播訊息服務來傳送資料不同；又所揭示之拉取式或推送式資訊傳送方法，係使用者利用客戶端裝置傳送帳密、IMEI硬體機碼等資訊給伺服器以進行登入與確認授權後，才可以在伺服器與客戶端裝置仍維持連線之情況下拉取或推送資訊，且在推送訊息時，必須以客戶端裝置傳送個人編輯目錄資訊及存取權給伺服器之智慧傳輸模組，嗣後伺服器才會根據這目錄資訊與存取權所傳來資料，將過濾後之資料推送給客戶端裝置等語。惟查，系爭專利請求項1 係限定以「依據該行動裝置作業系統類別與該推播訊息記號」之推播技術來傳送訊息，未限定「使用各行動裝置系統業者所提供之推播服務」之推播技術來傳送訊息，而發明專利範圍以請求項為準，是系爭專利請求項1 之專利權範圍，自應以系爭專利請求項1 所記載之「依據該行動裝置作業系統類別與該推播訊息記號」技術特徵為準，禁止將說明書有揭露但未記載於請求項之內容不當引入請求項，且應以申請專利之發明整體所能獲得之功效來審查進步性，不得用下位概念的發明所獲得之功效來審查進步性，是原告所謂系爭專利因使用之行動裝置作業系統業者所提供的推播訊息服務，而具有隨時、主動地利用推播訊息服務來傳送資料之功效等語，所稱之功效非發明整體均能獲得之功效，其主張自非可採。而乙證11已揭露依據客戶端裝置授予伺服器其目錄資訊之存取權之訊息記號，來讓伺服器推送資料流給客戶端裝置，將資料由伺服器推送給客戶端裝置之推送技術，說明書第14頁更揭露推送訊息之方式，例如廣播，乙證11所揭露之伺服器20之即時廣播模組223 透過IMEI硬體機碼（推播訊息記號且其前6 位為行動裝置作業系統類別）來將資訊廣播推送給客戶端裝置30，已揭露系爭專利請求項1 之要件1E「依據該行動裝置作業系統類別與該推播訊息記號，來將…資料傳送至該推播訊息記號所代表之該行動裝置上」技術特徵，已如前述。另乙證11已揭露依據客戶端裝置授予伺服器其目錄資訊之存取權之訊息記號，來讓伺服器推送資料流給客戶端裝置，將資料由伺服器推送給客戶端裝置之推送技術，說明書第14頁更揭露推送訊息之方式，例如廣播，而廣播亦為一種推播協定，屬於早期使用的HTTP伺服器推播技術，已經具有免費、即時推播訊息來傳送資料之功效，故系爭專利請求項1 之功效已為乙證11所預期。 ⑶綜上，乙證10、11之組合已揭露系爭專利請求項1 所有技術特徵，且乙證11所揭露之伺服器20之即時廣播模組223 透過IMEI硬體機碼（推播訊息記號且其前6 位為行動裝置作業系統類別）來將資訊廣播推送給客戶端裝置30，已經具有利用推播訊息來傳送資料之功效，已足以證明系爭專利請求項1 不具進步性。又乙證10之電子發票管理系統可以將發票代碼或消費明細傳送至用戶裝置（本院卷㈠第168 頁) 、乙證11之分散式運算之推拉式資訊服務系統可以廣播推送資料至用戶裝置（本院卷㈠第191 頁），乙證21至23分別為蘋果公司、Palm公司、谷歌公司公開其推播技術之編程指南或介紹影片，乙證10、11、21至23均屬於資料傳輸之技術領域，具有技術領域之關聯性；乙證10、11、21至23均以資料傳輸處理為目的，具有所欲解決問題之共通性；乙證10、11、21至23利用簡訊、廣播或推播等不同方式將資料傳送給客戶端裝置之功能或作用相同，具有功能或作用之共通性。故該發明所屬技術領域中具有通常知識者，為了將資料即時傳送給客戶端裝置，當有動機組合乙證10、11、21至23之技術內容，且能預期具有免費、即時地傳送資料至用戶之功效，而乙證10、11之組合既足以證明請求項1 不具進步性，則乙證10、11、21至23之組合當然亦足以證明系爭專利請求項1 不具進步性。 ⒋乙證10、11、21、35至38之組合足以證明系爭專利請求項1 不具進步性：乙證10、11之組合已足以證明系爭專利請求項1 不具進步性，業如前述；而乙證35為美國公開第2011/0000000A1號「Managing Notification Messages」發明專利案（本院卷㈡第42至49頁），乙證36為2005年11月24日公開之日本第0000- 000000A 號「購買歷史信息利用方法及其系統和裝置」發明專利案（本院卷㈡第51至63頁），乙證37為99年財政部公告之「實體消費通路開立電子發票試辦作業要點」，涉及雲端資料傳輸之使用（本院卷㈡第65至67頁），乙證38為AmazonSNS 開發者指南介紹如何使用Amazon SNS移動推送通知（本院卷㈡第69至72頁）。乙證10、11可以將資料傳送或廣播推送至用戶裝置，乙證21、38分別為蘋果公司、Amazon公司公開之其推播技術的編程指南，乙證35、36為將資料傳輸通知用戶之專利案，乙證37涉及雲端資料傳輸之使用，乙證10、11、21、35至38均屬於資料傳輸之技術領域，具有技術領域之關聯性；乙證10、11、21、35至38均以資料傳輸處理為目的，具有所欲解決問題之共通性；乙證10、11、21、35至38利用簡訊、廣播或推播等不同方式將資料傳送給客戶端裝置之功能或作用相同，具有功能或作用之共通性。故該發明所屬技術領域中具有通常知識者，為了將資料即時傳送給客戶端裝置，當有動機組合乙證10、11、21、35至38之技術內容，且能預期具有免費、即時地傳送資料至用戶之功效，而乙證10、11之組合既足以證明請求項1 不具進步性，則乙證10、11、21、35至38之組合當然亦足以證明系爭專利請求項1 不具進步性。㈣系爭專利因不具進步性而具有應撤銷之事由，則被告睿點公司所提供系爭產品在App Store 及Google Play 等線上平台供大眾下載即無侵害原告專利權之情事，是本件其餘爭點（被告睿點公司有無故意過失、被告等應否連帶負損害賠償責任、損害賠償金額應如何計算等），即無逐一論駁之必要，附此敘明。六、綜上所述，系爭產品背後用以與系爭產品相連結之伺服器內所使用方法固有落入系爭專利請求項1 之文義範圍，惟乙證10、11、21至23之組合及乙證10、11、21、35至38之組合均足以證明系爭專利不具進步性，系爭專利具有應撤銷之事由，則被告睿點公司提供在App Store 及Google Play 等線上平台供大眾下載之系爭產品或其所使用之系爭方法，自無侵害原告系爭專利之專利權之情事。從而，原告依專利法第96條第2 項、第97條第1 項第1 款及公司法第23條第2 項之規定，請求被告等應連帶給付原告80萬元及法定遲延利息，即為無理由，應予駁回。又原告之訴既經駁回，其假執行之聲請即失其依據，應併予駁回。七、本件事證已臻明確，兩造其餘攻擊防禦方法及所提證據，經本院審酌後，核與判決結果不生影響，爰不另逐一論述，附此敘明。訴訟費用負擔之依據：智慧財產案件審理法第1 條，民事訴訟法第78條。中　　華　　民　　國　　110 　年　　4 　　月　　27　　日智慧財產法院第三庭法官林怡伸以上正本係照原本作成。如對本判決上訴，須於判決送達後20日之不變期間內，向本院提出上訴狀。如委任律師提起上訴者，應一併繳納上訴審裁判費。中　　華　　民　　國　　110　年　　5　　月　　6　　日書記官　鄭楚君附件：109年度民專訴字第5號判決附圖

智慧財產及商業法院109年度民專訴字第5號

關鍵資訊