臺灣高等法院民事判決109年度重上字第581號上 訴 人 宏達國際電子股份有限公司法定代理人 王雪紅訴訟代理人 朱瑞陽律師複代 理人 陳興蓉律師訴訟代理人 蔡文玲律師複代 理人 黃郁喬律師訴訟代理人 楊采文律師被上 訴人 台灣國際商業機器股份有限公司法定代理人 高璐華訴訟代理人 張炳煌律師
朱日銓律師上列當事人間請求給付契約價款事件，上訴人對於中華民國109年6月10日臺灣臺北地方法院105年度重訴字第1225號第一審判決提起上訴，本院於110年8月24日言詞辯論終結，判決如下：
主 文原判決附表1之「工作說明書第1號修正書」下之「第2-2期」之「准許利息起算日」變更為「104年10月14日」。
原判決除前項減縮部分外，關於命上訴人給付超過本判決附表所示本息部分，及該部分假執行之宣告，暨命上訴人負擔訴訟費用之裁判，均廢棄。
前項廢棄部分，被上訴人在第一審之訴及其假執行之聲請均駁回。
其餘上訴駁回。
第一審訴訟費用關於廢棄部分，及第二審訴訟費用，均由被上訴人負擔仟分之肆，餘由上訴人負擔。
事實及理由被上訴人在原審起訴主張：兩造就「HTC Customer Centric T
ransformation Project【中譯：（下同）上訴人以客為尊轉型專案】」（下稱系爭專案），於民國（下同）103年2月14日以「Composite Signature Agreement（通用簽署契約）」方式，簽訂「MASTER SERVICES AGREEMENT（服務主約）」（下稱主約），約定由伊提供主約之「APPENDIX A、STATEMENT OF
WORK（附錄Ａ：工作說明書）」記載之各項服務，及簽訂「S-upplement License for Programs（授權程式商品採購附約）」，約定由伊代被上訴人外購系爭專案使用之授權軟體、1年期之SoftLayer雲端服務，嗣兩造於103年9月間簽訂「Ame-ndm
ent to Appendix A: Statement of Work of the Master Services Agreement for HTC Customer Centric Transform-ati
on Project（工作說明書之修訂協議書）」（下稱修訂書），合意變更工作說明書第1.8條約款內容，再於103年12月間簽訂「Addendum to Appendix A: Statement of Work of
the Master Services Agreement for HTC Customer CentricTransformation Project（工作說明書之增補協議書）」（下稱修訂書，並與以上各契約書合稱系爭契約)，約定追加「Community（論壇）」相關服務。伊於104年1月16日以前陸續履行系爭契約所定義務，且修訂書均明定上訴人之付款義務不得被撤銷或終止、以任何方式扣除或抵銷，上訴人亦不得僅因不滿意某些項目之履行，免除全部付款義務，惟伊陸續開立總額新臺幣（下未標明幣別者，均指新臺幣）135,805,946元之統一發票（如附表所示，下稱發票）請求上訴人付款，上訴人僅支付工作說明書第1期款及修訂書第2-1期款，伊多次催告未果，爰依系爭契約及民法第233條第1項、第203條規定請求給付價款本息；倘若上訴人合法解除系爭契約，則備位依民法第259條第3、6款及民法第179條、第181條規定，請求上訴人償還相當於伊已提供服務與軟、硬體契約價款之價額（原審卷2第299頁反面）等語。聲明求為判決：㈠上訴人應給付被上訴人如附表「聲明請求」欄所示本息；㈡願供現金或匯豐（臺灣）商業銀行無記名可轉讓定期存單為擔保，請准許宣告假執行。
上訴人以：被上訴人未踐行系爭主約第10.1條及工作說明書之
附錄A-2約定之爭議處理機制，其起訴無權利保護必要；被上訴人未依約完成部分工作，且所完成之工作有未達約定標準情形，經伊催告修補未果者，爰依民法第227條第1項適用第254條、第494條第1項、第502條第2項等規定，解除系爭契約；如認伊無解約權，則類推適用民法第572條規定，或依民法第493條第1項、第494條第1項及第359條規定，請求酌減價款；因主要社群媒體大幅變動，被上訴人縱使補正提出合於約定之規格與指定社群平台介接，對伊已無實益，爰依民法第232條規定，拒絕其補正給付，被上訴人並應賠償相當於伊已付價款之損害；於被上訴人完成瑕疵修補、依工作說明書第l.3.5.6條完成備份之系統資料，及在伊之雲端平台重建系爭專案系統，以該系統資料為基礎完成原審卷2第268至271頁附表所列工作，經伊驗收前，拒絕給付價款；若認被上訴人於103年10月1日完成建置階段工作，其就修訂書之第2-2期款之請求權於105年9月30日時效完成，本件起訴狀於105年11月3日送達予伊，伊自得拒絕給付；依主約第3.1條約定，被上訴人縱得依修訂書請求價款，依民法第548條第1項或承攬工作完成須經驗收等規定，遲延利息應自起訴狀送達翌日起算等語置辯。答辯聲明求為判決：㈠被上訴人之訴及其假執行之聲請均駁回；㈡如受不利判決，願提供兆豐國際商業銀行無記名可轉讓定期存單供擔保，請准宣告免為假執行。
原審判命上訴人應給付被上訴人如附表「原判決命給付」欄所
示本息，並為附條件之准、免假執行之宣告，另駁回被上訴人其餘之訴及假執行聲請。被上訴人對於敗訴部分未聲明不服，且於第二審減縮附表所示修訂書之第2-2期款之利息起算日為104年10月14日（見本院卷1第413頁），各該部分均不在本件裁判範圍內，下不贅述。上訴人對於敗訴部分提起上訴，聲明求為判決：㈠原判決不利上訴人之部分廢棄；㈡上開廢棄部分，被上訴人於第一審之訴及其假執行之聲請均駁回（被上訴人就此部分請求之備位之訴隨同移審，附此敘明）。被上訴人則答辯聲明：上訴駁回。兩造不爭執之事實：
㈠兩造就系爭專案，於103年2月14日以通用簽署契約方式，簽訂
主約及授權程式商品採購附約。兩造嗣於103年9月間簽訂修訂書，合意變更工作說明書第1.8條「Charges（價款）」約款內容。上訴人已支付修訂書關於「Payment Items（付款項目）」中之「Item #1（第1期）」、「Key Deliverables: S-ig
ned Contract and Deliver IBM Licensed Program per S-UPPLEMENT NO.:14031SB1S（主要交付項目：完成簽署之契約，並交付附約編號14031SB1S所定IBM授權程式）」價款，及 「I
tem #2（第2期）」中依「IPP Payment Schedule（被上訴人提出之付款計劃所定付款時程）」約定之第2-1期價款。兩造再於103年12月間簽訂修訂書，約定追加論壇相關服務。但被上訴人開立如附表「統一發票號碼」欄所示統一發票（下稱發票）請款未果後，上訴人迄未支付附表「原判決命給付」欄之價款本息。（見原審卷1第9至19、31至80、127、
128、131至134、139至177頁；原審卷4第272、273、301頁）㈡系爭契約之中譯以原審卷4第185至309頁為準。
㈢兩造間之授權程式商品採購附約，係上訴人委任被上訴人向授
權商購買程式商品使用授權，及向SoftLayer購買1年期之雲端服務後，轉售予上訴人之契約。被上訴人業已履行委任事務，依主約第6節「 Representations, Warranties and Covenan-
ts.（聲明、保證及承諾）」下之第6.3條約定：「ExclusiveWarranties. Except as otherwise set forth in this Sec-tion 6 or an applicable SOW, neither party makes anywarranties, express or implied, with respect to the S-ervices, Deliverables or any obligations under this A-greement, and both parties expressly disclaim the war-ranties of merchantability and fitness for a particul-
ar purpose. The Services provided by IBM under this A-greement or an applicable SOW do not create any impli-
ed representations, warranties or commitments on enti-tlement of any software license, either IBM LicensedPrograms or Non-IBM Programs. All the representations,
warranties, and commitments on entitlement of any sof-tware license, either IBM Licensed Programs or Non-IB
M Programs, will be set forth in the respective licens
e agreement. (專屬保證：除第6節或所適用之工作說明書另有規定外，兩造就服務、交付項目或本合約項下義務，均不提供任何明示或默示保證，且兩造明示否認提供適售性及符合特定效用之保證。由被上訴人依本合約或所適用工作說明書之規定提供之服務，就軟體授權之授與，無論IBM授權程式或非IBM授權程式，均未創設任何默示聲明、保證或承諾。軟體授權之授與，無論IBM授權程式或非IBM授權程式，其一切聲明、保證及承諾，於個別授權合約定之。）」（原審卷1第15頁；卷4第194頁），及工作說明書第1節「Statement of Work（工作說明）」約定：「Licensed Programs, including IBM SMA, I-
BM Campaign, Cognos Bl, Infosphere DataStage, WebSpher
e Application Server, and DB2 in this transaction arepurchased by HTC as part of Charge payable under sect-
ion 1.8, which are governed under separate license ag-reement (e.g. IPAA, IPLA and their applicable LicenseInformation for IBM Licensed Programs) between HTC and
their licensor, sample of which agreements as shown i
n the SOW Attachment I as listed below.【所謂授權程式，包括本交易中之IBM、SMA、IBM Campaign、Cognos BI、Info-sphere DataStage、WebSphere Application Server及DB2，係上訴人以第1.8條下應支付價款之一部分所購買取得授權之程式，此等程式受上訴人與其授權商之間所立個別授權合約（例如：IPAA、IPLA及其所適用之IBM授權手冊授權資訊）之拘束，該等合約之範例詳本工作說明書附件一所示。】、「T-
he Cloud Service (SoftLyer) in this transaction, incl-uding the services as described in this SOW, such assection 1.1 .7, 1.2.7, 1.3.3.6, 1.3.4.6, 1.3.5.6, and
1.3.6.6 is provided and governed under separate servi-
ce agreement between HTC and SoftLayer, sample of whi-
ch agreements as shown in the SOW Attachment Ⅱ as li-s
ted below.【本交易中之SoftLyer雲端服務，包括本工作說明書所述各項服務（例如：第1.1.7、1.2.7、1.3.3.6、1.3.4.6、1.3.5.6、1.3.6.6條），依上訴人與SoftLayer所立個别服務合約之規定提供並受其拘束，該等合約之範例詳本工作說明書附件Ⅱ所示】」、「For the purpose of this SOW the following shall apply:…2. The terms and conditions in the
Agreement and SOW shall not apply to the Licensed Programs except for the payment terms set forth in Se-cti
on 1.8 of the SOW. 3. The parties acknowledge that alllicense fees or service fee payable pursuant to t-heLicensed Programs or Cloud Service is incorporated int
o Charges payable by HTC to IBM pursuant to Section 1,8, upon receipt of HTC payment, IBM shall be responsib
le for payment to the licensor for Licensed Program an
d Cloud Service.（基於本工作說明書之目的，應適用下列規定：…⒉主約及本工作說明書之條款不適用於授權程式，但本工作說明書第1.8條所訂付款條款不在此限。⒊兩造承認授權程式或雲端服務所規定之一切應支付授權費用或服務費，均納併於第1.8條所規定之上訴人應支付被上訴人之價款中，被上訴人於收到上訴人支付之款項時，應負責將款項支付予授權程式及雲端服務之授權商。）」、第1.4節「HTC Responsibi-lities（上訴人之義務）」約定：「IBM's performance ispredicated and conditional upon the following respons-ibilities being fulfilled by HTC（被上訴人之履行義務，以上訴人是否履行下列義務為前提）」、第1.4.2.2條約定：
「Provide all Information and materials reasonably re-quired to enable IBM to provide the Services. IBM will
not be liable for any loss, damage or deficiencies in
the Services arising from inaccurate, incomplete, ill-egal, or otherwise defective data supplied by HTC orthird parties.（上訴人應提供合理情形下所需之一切資訊與著作物，以使被上訴人得以提供服務。因上訴人或第三人所提供之資料有不準確、不完整、不合法或具有瑕疵等情形，而肇生「服務」中之滅失、損害或短缺者，被上訴人概不負責。）」、第1.4.2.3條約定：「Ensure HTC has appropria-te agreements In place with third parties to enable I-BM toperform the Services under this SOW, where HTC
is using or providing IBM with third party APIs, data,information, support or materials for a project inclu-ding but not limited to, where HTC is employing other
suppliers whose work may affect IBM's ability to prov-ide the Services. Unless specifically agreed to other-wise in writing, HTC will be responsible for the mana-gement of the third parties and the quality of theirinput and work. Except to the extent IBM specificallyagrees otherwise in this SOW, HTC is solely responsib-
le for any third party hardware, software or communic-ations equipment used in connection with the Services(Collectively referred as "Required Resource"). If HTC
fails to obtain the necessary Required Resource whichhinder provision of service, IBM may suspend to provi-de the service being affected, otherwise both parties
agree to descope the affected service through PCR.【確保上訴人已與第三人簽訂適當之合約，以使被上訴人得以進行本工作說明書項下之服務，在此等服務中，上訴人針對專案而使用該等第三人之API、資料、資訊、支援或著作物，或將其提供予被上訴人，包括且不限於下列事項：上訴人聘僱其他供應商，且該等供應商可能影響被上訴人提供服務之能力者。除非兩造另有書面同意，否則上訴人對於第三人之管理及其投入與工作之品質，應負其責任。除非被上訴人特別於本工作說明書中同意，否則上訴人對於與服務搭配使用之第三人軟硬體或通訊設備（合稱所需資源），應負完全責任。上訴人未能取得前述必要之所需資源，致使服務供應受阻者，被上訴人得暫停提供受影響之服務，或者兩造同意透過PCR程序將該受影響之服務從專案範圍中去除。」（原審卷1第32、62頁反面、第33頁；卷4第210、211、265頁）。另修訂書約定：「The Cha-rges include IBM Licensed Programs per SUPPLEMENT NO.:
14031SB1S and 1 Year SUSE Linux Enterprise Server Sub-scription described in Appendix E Non-IBM Software Li-cense on Softlayer.（價款包括附約編號：14031SB1S所定I-BM授權程式之價款及附錄E所示Softlayer之非IBM軟體授權所載明之1年SUSEL Linux企業伺服器訂用之費用。）」（原審卷1第127頁；原審卷4第299頁）。是被上訴人代購之授權程式商品及雲端服務，關於該商品及服務之契約關係存在於上訴人與授權人之間，僅相關價款計入系爭契約約定價款，由被上訴人收取並代付予授權商，被上訴人不負授權商責任（原審卷1第235頁反面；本院卷1第290頁）。
關於上訴人抗辯：被上訴人未踐行系爭契約所定爭議解決程序，逕行起訴，欠缺權利保護必要乙節，得心證之理由：
㈠按民法第98條規定，解釋契約，固須探求當事人立約時之真意
，不能拘泥於契約之文字，但契約文字業已表示當事人真意，無須別事探求者，即不得反捨契約文字而更為曲解。㈡兩造於主約第10節約定：「Dispute Resolution. All dispu-t
es or claims arising under this Agreement ("Dispute-s") will be resolved as set forth in this Section 10.【爭議之解決：本合約所生一切紛爭或請求（爭議），悉依本節規定解決】」，其下第10.1條約定：「Informal Resoluti-on. In the event of a Dispute, both parties agree toresolve the dispute in accordance with the EscalationProcess set forth in the SOW. If conflict remains unr-esolved after Escalation Process in SOW has been appl-ied, either Party may terminate the SOW and this Agre-ement by 7 calendar days notice in writrng to the oth-
er party, in which case, Company shall be entitled toreceive payment for the charge which is due under app-licable SOW or separate agreement and not yet paid byHTC; and subject to negotiation at good faith by bothparties, HTC will pay for 1) the undisputed charges f-
or Services Company provides up to the date of termin-ation. 2) all Deliverables Company has prepared throu-
gh termination, whether or not completed (except forsuch Deliverables delivered fails to meet Acceptance
and Completion Criteria set forth in the SOW) which is
not yet billed. To the extent the applicable cloud service agreement permits, HTC may request refund of ch-arge for undue Cloud Service. Company will provide de-liverables created before termination but not yet del-ivered to HTC upon receipt of the above payment. For
the avoidance of doubt, this Section 10.1 does not pr-ejudice either party's right to claim damages under S-ections 7 and 11.【循簡易程序解決：發生爭議時，兩造同意依工作說明書中之「爭議解決機制」解決之。若爭議衝突依工作說明書中之「爭議解決機制」處理後仍未獲解決者，任一造於7個日曆日前以書面通知他造後得終止工作說明書及本合約。有前述終止之情事者，對於適用之工作說明書或個別合約所規定已到期但未由上訴人支付之費用，被上訴人有權收受之，且由兩造本誠信原則協調後，上訴人應支付下列費用：⒈至終止日前，被上訴人所提供並無爭議之服務費用；⒉無論是否完工，被上訴人於終止前已作成但尚未開立發票之一切交付項目（但已交付未符合本工作說明書所定驗收與完工標準之交付項目者，不在此限）。在所適用之雲端服務合約許可範圍内，上訴人得就未到期雲端服務，要求退還價金。前述於服務終止前作成但尚未收到款項之交付項目，應於上訴人付清款項後提供予上訴人。為免除疑義，特此指明，第10.1條不損及第7節與第11節所規定任一造之損害求償權。】」（原審卷1第17頁；原審卷4第197頁）。次按工作說明書附錄A-2「Escalati-on
Procedure（爭議解決機制）」約定：「The following p-rocedure will be followed if resolution is required to a
conflict arising during the performance of this SOW.
1.When a conflict arises between HTC and IBM, the Pro-ject team member(s) will first strive to work out theproblem internally. 2.Level 1: If the Project team can
not resolve the conflict within two (2) working days,
the HTC Project Manager and IBM Project Manager willmeet to resolve the issue. 3.Level 2: If the conflict
is not resolved within three (3) working days after b-eing escalated to Level 1, the Steering Committee will
meet to resolve the issue. 4.If the conflict is resol-ved by either Level 1 or Level 2 intervention, the re-solution will be addressed in accordance with the Pro-ject Change Control Procedure set forth in Appendix A-l. 5.If the conflict remains unresolved after Level 2
intervention, then either party may terminate this SO
W pursuant to the Agreement. 6.During any conflict reso-lution, IBM agrees to provide Services relating to it-ems not in dispute, to the extent practicable pendin
gresolution of the conflict. HTC agrees to pay undispu-
ted invoices per this SOW and the Agreement.（本工作說明書執行期間所生衝突如需解決者，應遵循下列程序為之：⒈兩造間肇生衝突時，應先由本專案小組成員於內部盡力尋求問題解決之道。⒉層級1：本專案小組未能於2個營業日內解決該衝突者，由兩造專案經理會面解決之。⒊層級2：呈報至專案經理後3個營業日內未能解決該衝突者，由指導委員會委員會面解決之。⒋該衝突因層級1或層級2之介入而解決者，依工作說明書附錄A-1所定「專案變更控制程序」處理該解決方案。⒌層級2之介入仍未能解決該衝突者，一方得依本約規定終止本工作説明書。⒍於衝突解決進行期間，被上訴人同意繼續提供不屬於爭議範圍内、並完全不受爭議所影響的服務項目；上訴人同意依工作説明書及本約之規定支付無爭議項目發票款項。）」（原審卷1第68頁；原審卷4第276頁）；附錄A-1「P-rojectChange Control Procedure（專案變更控制程序）」約定：
「During the contract period, a Project ChangeRequest (PCR) will be the vehicle for requesting chan-
ges. Since the PCR may materially impact on the price
and schedule of the project and other contract terms
and conditions, it shall be discussed and reviewed by
the Project Managers (PM) of both parties, and will beperformed only after the consent of both parties. Unt-il a change is agreed in writing, both parties will c-ontinue to act In accordance with the latest agreed v-ersion of the SOW.（專案變更控制程序：於履行本合約期間，本程序係要求變更之工具。專案變更對於專案之價格與時程及其他契約條款有重大影響，應由兩造之專案經理商討審查，經兩造同意後始得為之。未經兩造書面表示同意變更前，兩造仍應繼續遵循所同意之最新版工作說明書之規定。）」（原審卷1第67頁；原審卷4第274頁）。上開契約文義明示「爭議解決機制」係處理系爭專案執行期間發生之爭端；負責處理層級由下而上之順序為⒈專案小組成員、⒉專案經理、⒊指導委員會，於「爭議解決機制」進行期間，兩造應繼續履行與爭端無關之契約義務，如於層級⒈或⒉已解決爭端者，即進入「專案變更控制程序」，若至層級⒉仍無法解決爭端者，兩造均得提前終止契約，足見「爭議解決機制」處理之爭端，係兩造對於工作說明書所定工作內容之衝突問題，至於被上訴人就其主張已執行完成之系爭專案所定工作，請求上訴人對待給付價款之爭訟，不屬於「爭議解決機制」處理之範疇。
㈢綜上，被上訴人提起本件訴訟，無主約第10節之適用。上訴人
抗辯被上訴人未先循上開「爭議解決機制」解決爭端，逕行起訴，欠缺權利保護必要云云，乃曲解契約文字明示之意思，洵非可採。
系爭契約（除授權程式商品採購附約部分外，下同）之定性部分，得心證之理由：
㈠按民法第490條第1項規定，稱承攬者，謂當事人約定，一方為
他方完成一定之工作，他方俟工作完成，給付報酬之契約。此與委任契約之受任人，於受委託事務處理完畢，不論有無結果，均得請求報酬之情形不同。㈡兩造於主約第2節「Engagement.（約定）」下之第2.1條約定：
「Services. Company will perform the Services acc-ordi
ng to the terms and conditions set forth in thisAgreement and the applicable SOW.（服務：被上訴人應依主約及所適用之工作說明書所訂條款執行服務）」，第4節「Payment.（付款）」下之第4.1條約定：「Fees. Subject toCompany's duly performance of the Services, HTC will
pay Company as set forth in the SOW.（費用：於被上訴人依約執行服務之前提下，上訴人應依工作說明書規定將服務款項支付被上訴人）」（原審卷1第11、13頁；原審卷4第187、190頁）。契約文義明示被上訴人完成工作說明書所定之「服務」一部或全部時，上訴人應給付對應之價款。
㈢工作說明書第1.5節「Deliverables（交付項目）」下之第1.5.
2條「Application Implementation（應用程式施行）」表列被上訴人應於⒈「Define（需求確認）」、⒉「Design（設計）」、⒊「Build（建置)」、⒋「Test（測試）」、⒌「D-eploy,Post Live support, Reporting（部署、使用後支援及報告）」等「Phase（階段）」，分別交付之細項（即完成之工作或服務）所屬「Solution（解決方案）」、名稱、「Format（格式）」、「Type（類型）」（原審卷1第63至65；原審卷4第266至270頁）。修訂書約定「付款項目」分為前開之㈠所示第1期；「Item #2（第2期）」、「主要交付項目」:
「 Completion deliverables of Build Phase in sec-tion
1.5.2（完成交付第1.5.2節中建置階段之項目）」；「Item #3（第3期）」、「主要交付項目」:「Completion del-iverables of Test Phase in section 1.5.2（完成交付第1.
5.2節中測試階段之項目）」；「Item #4（第4期）」、「主要交付項目」:「Completion deliverables of Deploy Phase
in section 1.5.2（完成交付第1.5.2節中部署階段之項目）」；「Item #5（第5期）」、「主要交付項目」:「Comp-leti
on Go live Support and deliverables of Project A-cceptance Report in Section 1.5.1（完成交付第1.5.1節中之上線支援及專案接受報告之項目）」，上訴人之「Payment Schedule（付款時程）」則按各該付款項目完成時或加計特定月份數後分期支付（原審卷1第127、128頁；原審卷4第299至301頁）。修訂書就「Projec Deliverables（專案交付項目）」表列被上訴人應於⒈「設計/建置)」、⒉「測試」、⒊「Technical Support （技術支援）」、⒋「部署」等階段，分別交付之「Task（作業）」、名稱、「格式」、「類型」，上訴人則應按「Milestone 1（里程碑1） 」、「主要交付項目」:「sign off of this Addendum（本協議書簽署日）」；「Milestone 2（里程碑2）」、「主要交付項目」:「Comple-tion of
Design and Build（完成設計與建置）」；「Miles-tone 3（里程碑3）」、「主要交付項目」:「測試」；「Mil-estone
4（里程碑4）」、「主要交付項目」:「Completion
of Technical Support（完成技術支援）」；「Milestone 5（里程碑5）」、「主要交付項目」:「部署」，或加計特定月份後分期支付價款（原審卷1第132、133頁；原審卷4第305至308頁）。契約文字再次表明被上訴人應為上訴人完成一定之工作，上訴人俟一部或全部工作完成（即達成一定結果），始給付對應之報酬。
㈣系爭主約第2.5條約定：「Repotrs and Meetings. Company
shall organize progress meetings to monitor the perfo-rmance of the Services; these meetings will be held w-eekly or a frequency to be agreed upon between the Pa-rties as agreed in the SOW. Such meetings may also beconvened on such any other occasion during the perfor-mance of the Services as deemed necessary by one of t-
he parties. Company shall also provide reports as req-uired by HTC specified in the SOW.（報告與會議：被上訴人應安排進度會議，監督「服務」執行狀況；該等會議應每週召開一次，或依兩造於工作說明書中所合意之召開頻率為之。一造認為有必要召開前項會議者，亦得於執行「服務」之期間隨時召開。被上訴人亦應依上訴人於工作說明書載明之要求提供報告。）」（原審卷1第11頁反面；原審卷4第187、188頁），目的係監督被上訴人應交付項目之完成內容及進度。工作說明書第1.1.1.1條係約定「Social Listening（社群聆聽）」細項之工作內容（原審卷1第34頁；原審卷4第213、214頁）；第1.1.2.1條係約定「Community business design（論壇業務設計）」工作內容（原審卷1第38頁；原審卷4第220頁）；第1.1.7條係約定「 Cloud Infrastructure Implemen-tation an
d Support Services（雲端基礎架構施行與支援服務）」工作內容（原審卷1第44頁；原審卷4第231、232頁），及第1.3.1.3條約定：「Ongoing Project Management（專案管理）」約定：「IBM will provide ongoing project mana-gement for
the IBM responsibilities in this SOW. This activity i
s to provide technical direction and control of IBM project personnel and to provide a framework f-or projec
t planning, communications, reporting, proce-dural andcontractual activity. This activity is comp-osed of t
he following tasks: 1.Review the SOW and the contractu
al responsibilities of both parties with the HTC Proje
ct Manager. 2.Maintain project communication-s through
the HTC Project Manager. 3.Coordinate the e-stablishm
ent of the project environment. 4.Establishdocumentation and procedural standards for deliverable
Materials. 5.Prepare and maintain the IBM Project Pla
n which lists the activities, tasks, assignments, miles-tones and estimates for performance of this SOW. 6.Re-view project tasks, schedules, and resources and mak
e changes or additions, as appropriate. Measure and eva-luate progress against the IBM Project Plan with the
HTC Project Manager.（被上訴人將就本工作說明書中之被上訴人義務提供專案管理。本活動之目的在於提供專案人員之技術指示與控制，並提供專案規劃、協商、提報、程序活動及約定活動等架構。本活動包含下列作業：⒈協同上訴人專案經理審查本工作說明書及兩造之約定義務。⒉持續透過上訴人專案經理進行專案協商。⒊協調專案環境之建置。⒋訂定應交付著作物之說明文件與程序之標準。⒌準備及維持「IBM專案計劃」，並於計劃中載明執行本工作說明書之活動、作業、指派、里程碑及評估。⒍審查專案作業、時程及資源，並視適用情況予以變更或增補。協同上訴人專案經理針對「IBM專案計劃」衡量及評估進度。）（原審卷1第49頁；原審卷4第240頁），係規範被上訴人之工作管理及配合上訴人進行工作審查、進度評估等義務，均以達成之㈣所示工作成果為目的。
㈤綜上，系爭契約應定性為承攬契約，上訴人抗辯系爭契約為委
任與承攬混合契約，且應適用委任相關規定云云，不足憑採。被上訴人主張其依約完成工作說明書第1.5.2條，如原審卷3第1
03至112頁（下同）所示編號1.1、1.2、1.5至1.9、2.2至2.
28、3.1、3.4至3.9、3.11至3.20、4.7等交付項目【內載交付項目日及提交「Service Completion Confirmation Form（服務完成確認單）日期】，經上訴人簽署服務完成確認單等語，有上訴人提出之完工確認單紀錄（內載交付項目日、提交服務完成確認單日期及被上訴人簽署該確認單日）、服務完成確認單影本（原審卷1第270至340頁）可稽，復為上訴人所不爭執（本院卷1第326、448頁），堪予信實。
按民事訴訟法第270條之1第1項第3款、第3項規定，當事人就其
主張之爭點，經受命法官整理並協議簡化爭點者，應受其拘束。但經兩造同意變更，或因不可歸責於當事人之事由或依其他情形協議顯失公平者，不在此限。查受命法官於109年11月19日準備程序，就被上訴人主張其已依約完成編號1.1至3.20等交付項目乙節，請上訴人確認有爭執部分，上訴人表明僅爭執編號1.3、1.4、2.1、3.2、3.3，其餘不爭執（本院卷1第
325、326頁），經受命法官諭知日後不得再行爭執，是兩造已就被上訴人是否依約完成編號1.1至3.20等交付項目之爭點，經受命法官整理並協議簡化爭點以編號1.3、1.4、2.1、3.2、
3.3為限，上訴人應受該協議之拘束。上訴人嗣後就編號3.10交付項目追復爭執（本院卷1第329頁），為被上訴人不同意，上訴人亦未提出任何不可歸責於己之事由或該協議顯失公平之主張，爰不准上訴人再為爭執。關於被上訴人是否依約完成編號1.3交付項目之爭點，得心證之理由如下：
㈠按民事訴訟法第282條規定，法院得依已明瞭之事實，推定應證
事實之真偽。查工作說明書第1.5.2條所定工作階段，區分為⒈需求確認、⒉設計、⒊建置、⒋測試、⒌部署、⒍上線後支援，而階段⒈⒉完成，始有可能進行階段⒊以後工作。前開之㈢所示修訂書明定以上開階段⒊至⒍各別完成日決定第2至5期之「付款項目」及「付款時程」。又兩造於修訂書約定第2期價款之付款里程碑為被上訴人完成「建置」階段之交付項目，兩造並表明沒有針對「付款時程」所定第2-1、2-2期款分別約定付款里程碑（本院卷1第291頁）。且被上訴人主張：伊於103年10月1日開立第2-1期發票請款，經上訴人於103年12月10日給付等語，為上訴人是認。據此應得推定被上訴人已完成階段⒈至⒊交付項目，自包括完成編號1.3之交付項目（即「需求確認」階段下之「Social Marketing（社群行銷）」下之「HTC Resource
Recommendation Document（上訴人資源建議文件）」交付項目）（原審卷1第63頁反面；原審卷4第267頁），上訴人否認之，應提出足以推翻該已推定事實之反證。
㈡工作說明書第1.5.2條載明編號1.3之類型為「Document（文件
）」。依工作說明書第1.6節「Completion Criteria（完成標準）」約定「Each deliverable material must apply wi-th
the following different acceptance criteria.（各應交付著作物均各依下列不同完成標準）」，其下第2條「文件」約定：「The Documents will be reviewed and accept-ed i
n accordance with the following procedure. a.One copy
of the Deliverable will be submitted to the HTCProject Manager. It is the HTC Project Manager's resp-onsibility to make and distribute additional copies to
any other reviewers; b. Within five working days of r-eceipt, the HTC Project Manager will provide the IBMProject Manager a written list of revision request, a-
nd IBM wi11 respond within five working days. The IBMProject Manager will consider HTC's request for revis-ions, If any. Those HTC revisions agreed by IBM will
be made and the Deliverable will be resubmitted to the
HTC Project Manager. If IBM receives no response from
the HTC Project Manager within five working days, the
n the Deliverable will be final and a basis to continu
e. (「文件」之審查與接受，應依下列程序為之。a：應提交一份「交付項目」予上訴人專案經理。上訴人專案經理應自行負責製作及分送額外複本予任何其他審查人員。b：上訴人專案經理應於收受前項文件後5個工作日内，以書面列出修訂要求交付被上訴人專案經理，被上訴人專案經理應於5個工作日內回應該要求。被上訴人專案經理應考量上訴人之修訂要求（若有）。經被上訴人同意上訴人修訂，應予以修訂，並且應重新提交「交付項目」予上訴人專案經理。被上訴人於5個工作日内未收到上訴人專案經理所為任何回應者，該「交付項目」即為最終「交付項目」，且為繼續執行之基礎。）」（原審卷1第65頁；卷4第270、271頁）。查被上訴人主張：伊於103年4月18日交付編號1.3文件予上訴人等語，業據提出被上訴人提交上訴人簽署之服務完成確認單影本（原審卷2第70頁）為證，並有上訴人提出103年4月24日系爭專案會議紀錄影本，就「Social Marketing Milestone（社群行銷里程碑）」，作成「Social Marketing KPI, Use Case document, and resour-ce
plan…were all delivered.（社群行銷績效指標、使用案例文件及資源計劃已全部交付)」結論（本院卷1第341、423頁），可資佐證，堪予信實。上訴人復未提出任何證據證明其於收受編號1.3文件後5個工作日内（即103年4月25日前），曾以書面提出修訂要求，依上開約定，於103年4月26日視為被上訴人完成編號1.3交付項目，並作為系爭專案繼續執行之基礎。㈢上訴人抗辯：被上訴人專案經理李珉玲（MingLing Lee）於
103年8月24日寄送主旨為「（Build Phase Acceptance Foll-
ow Up Meeting（建置階段驗收後續待辦會議）」之電子郵件（下稱電郵），表示：「1.SM KPI and SMA Analysis: Migh-
t need to defer to next phase for confirmation (Kevin& Clare) 2.Resource Plan for both SM and Community, a-
nd CRM Integration specification: will be defered(誤載為deferred) to Deploy phase for confirmation.（⒈社群行銷績效指標與社群媒體分析報告：可能需要推遲到下一階段進行確認 (Kevin & Clare）；⒉社群行銷與論壇資源計劃，以及CRM整合規格：將推遲到佈署階段進行確認）」，所謂社群行銷資源計劃即編號1.3文件等語，業據提出該電郵影本（原審卷5第29頁；本院卷1第428、447頁）為證，經被上訴人自認（本院卷1第357頁），堪予信實。惟該電郵主旨表明針對「建置階段驗收」事宜，內文之前言記載「The following a-re the
current staus updates based on last Mondays Ac-ceptan
ce meeting.（以下是根據上週一之驗收會議，更新目前狀態）」、文末記載「We need your strong support for this billing milestone so that we can keep our team r-esourc
es for continuous developments/enhancements goi-ng forward.（我們需要各位大力支持此付款里程碑，以便能不斷投入我們的團隊資源以進行開發/強化）」，顯見兩造係就被上訴人已交付項目，討論是否達到修訂書所示第2期付款里程碑，當時尚未有定論，被上訴人亦無同意改變之㈡所示於103年4月16日視為被上訴人完成編號1.3交付項目之意思，且依前開之㈠，上訴人事後應已確認達到該付款里程碑，始於103年12月10日支付第2-1期價款。是上訴人執該電郵，抗辯兩造就社群行銷績效指標及編號1.3交付項目無法於建置階段完成確認已有共識云云，為不可採。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準云云，為被上訴人否認。查前開之㈡所示約款明定「文件」完成標準，並未包括上訴人簽署服務完成確認單乙項。且按工作說明書第
1.6節前言約定：「Any conflict arising from this Deliv-erable Materials Acceptance Procedure will be address-
ed as pecified in the Escalation Procedure set forth
in Appendix A.（交付著作物接受程序所生一切衝突，依附錄A所定「爭議解決機制」之規定處理）」（原審卷1第65頁；原審卷4第270頁）。而依之㈡所示「爭議解決機制」，上訴人如主張「文件」完成標準應增加上訴人簽署服務完成確認單乙項，經兩造系爭專案相關人員作成解決方案者，即進入工作說明書附錄A-1所定「專案變更控制程序」，但上訴人未提出證據證明兩造踐行上開程序後，以書面將上訴人簽署服務完成確認單乙項納入「文件」完成標準，自不生變更原約定完成標準之效力。準此，被上訴人提出服務完成確認單，請求上訴人簽署，目的頂多作為「交付項目」已完成之證明文件，難認以上訴人簽署為完成「交付項目」之條件，則上訴人以其專案人員未簽署之㈡所示服務完成確認單，抗辯被上訴人未完成編號1.3交付項目，亦不足採。
㈤上訴人抗辯：被上訴人應將文件「交付項目」之定稿版本提交
予伊之專案經理劉冠廷（Kurt Liu），始符合工作說明書第1.6節之2之ａ（見之㈡）約定之交付方式云云。惟查，工作說明書第1.5.2條明定編號1.3「交付項目」之格式為「Power P-oi
nt or Word」（原審卷1第63頁反面），均為電子檔，非紙本文件。工作說明書第1.6節之2之ａ係約定上訴人專案經理應自行負責製作及分送複本予其他審查人員，並未約定被上訴人除交付電子檔外，應另交付紙本文件予上訴人專案經理。又被上訴人主張：伊將編號1.3文件電子檔儲存至上訴人指定之資料庫「team room」以為交付等語，有之㈡所示服務完成確認單影本為證，並有上訴人提出其資訊長Albert Wang（王文泰）於103年2月26日發予被上訴人專案經理李珉玲，副知兩造專案人員之電郵影本，表示「All project document/delive-rables, please store into project sharepoint.（所有專案文件及交付項目，請存檔到專案共享資料庫）」（原審卷2第272頁），可資佐證，上訴人亦自認「team room」為其之電子檔雲端儲存空間（本院卷1第366頁）。且上訴人不爭執被上訴人已完成，格式分別為Word、Power Point、Excel、PDF等電子檔，類型為文件之「交付項目」，交付方式均是將電子檔儲存至「team room」 ，有上訴人提出之完工確認單紀錄、服務完成確認單影本（見原審卷1第270至312、314至325頁）可稽。
再斟酌上訴人在原審抗辯：被上訴人應將工作内容上傳至指定空間，不能以電郵寄送文件「交付項目」云云，於第二審抗辯：被上訴人應將定稿版本提交伊之專案經理劉冠廷，「t-eamroom」僅係兩造就專案溝通之備份存放空間云云，前後不一。
本院認為被上訴人之主張為真正，上訴人之抗辯則不足採信。
㈥綜上事證，堪認被上訴人已依約完成編號1.3交付項目，上訴
人雖否認該事實，但就其抗辯均未提出相當反證以實其說，不足以撼動本院認定之結果。
關於被上訴人是否依約完成編號1.4交付項目之爭點，得心證之
理由如下：㈠引用之㈠論述，推定被上訴人已完成階段⒈至⒊交付項目，自包
括完成編號1.4交付項目，即需求確認階段中關於「社群行銷」之8小時SMA（指工作說明書第1.3.3.6條下之「Softwa-re Installation Services（軟體安裝服務）下之「IBM Soc-ialMedia Analytics（社群媒體分析）」授權程式商品之「Product Trafning with Training Materials【產品訓練（含訓練教材）】」（原審卷1第56、63頁反面；原審卷4第254、267頁），上訴人否認之，應提出足以推翻該已推定事實之反證。
㈡工作說明書第1.5.2條載明編號1.4之類型為「Training（教育
訓練）」。依工作說明書第1.2節「Key Assumption（主要假設）」下之第1.2.0條「General Assumption（一般假設）」第3項約定：「All training courses will be hosted in H-
TC Office, except those agreed by both HTC and IBM th-rough Appendix A-l. No attendance limit for each cour-se, HTC will be responsible for the reproduce of trai-ning material base on the number of its attendees.（一切訓練課程均應於上訴人辦公大樓舉辦，但兩造於附錄A-1中所合意之課程不在此限。各課程上課人數不拘，上訴人應依上課人數負責重製訓練教材）」；第1.6節「完成標準」下之第3條「教育訓練」約定：「Training: Training material acc-eptance will follow the document acceptance process a-bove. The training material may use standard productdocumentation. These components of training materialwould be excluded from revision or acceptance. When t-
he training material is accepted, IBM has completed t-
he training courses, and provided the sign-off report
of HTC attendees to HTC Project Manager after all thetraining classes are finished, then the Training will
be deemed accepted.（教育訓練：教育訓練教材之接受，應遵循前揭「文件」接受處理程序。教育訓練教材得使用標準產品說明文件。此等教育訓練教材文件不包含在修訂或驗收項目内。當教育訓練教材已被接受、被上訴人完成教育訓練課程，且於教育訓練課程結束後將參與該等課程之上訴人人員簽字認可之報告交付上訴人專案經理後，全部教育訓練即視為完成。）」（原審卷1第46、65頁反面；原審卷4第235、271頁）。查上訴人主張：伊於103年5月9日9:30至18:00，計8.5小時，進行編號1.4教育訓練，到場之上訴人人員包括上訴人之專案經理劉冠廷及「Community BU Leader（論壇事業單位負責人）」Adam Chen（陳家馴）等人均已簽認等語，業據提出簽到單影本（原審卷2第77頁）為證，依上開約定，編號1.4教育訓練即視為全部完成。至於上訴人抗辯簽到單記載之課程時間應扣除上訴人表定午休時間1小時，故被上訴人僅提供7.5小時教育訓練云云，未舉證以實其說，且即令屬實，仍無礙依兩造約定，視為此交付項目全部完成之效力。上訴人又抗辯：該簽到單上註明為「PartⅠ」課程，顯見還有後續課程，故編號1.4交付項目尚未完成云云，然查，依工作說明書第1.5.2條，教育訓練類型之交付項目共6項（原審卷1第63至65頁），由上開註記無法推論係表示編號1.4交付項目之第1場教育訓練，且上訴人至少已提供7.5小時教育訓練，兩造顯無可能僅為0.5小時教育訓練排定第2場課程，是此抗辯委無可取。㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號1.4交付項目乙
節屬實，上訴人所為抗辯則均不可採。關於被上訴人是否依約完成編號2.1交付項目之爭點，得心證之理由如下：
㈠引用之㈠論述，推定被上訴人已完成階段⒈至⒊交付項目，自包
括完成編號2.1交付項目，即設計階段中關於「社群行銷」之細項「Sodal Listening Business Requirement Docu-ment (
SMA Report)【社群聆聽商業需求文件（社群媒體分析報告）】」（原審卷1第63頁反面；原審卷4第267頁），上訴人否認之，應提出足以推翻該已推定事實之反證。
㈡工作說明書第1.5.2條載明編號2.1之類型為「文件」，依前開
之㈡，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年7月3日交付編號3.3文件，於103年7月9日提交之服務完成確認單記載「Note: The UseCase Documents includes D+8W deliverable SMA Report.（註記：本行銷案例文件包括專案啟動日加8週時應交付項目社群媒體分析報告）」，經上訴人之「Social Marketing BULeader（社群行銷單位負責人 」Tingwei Chang（張庭瑋）、專案經理劉冠廷等人分別於103年5月8、9日簽署服務完成確認單等語，有上訴人提出之服務完成確認單影本（原審卷1第275頁）為證，堪予信實。上訴人復未提出任何證據證明其於收受編號2.1文件後5個工作日内（即103年3月27日前），曾以書面提出修訂要求，依上開約定，於103年3月28日視為被上訴人完成編號2.1交付項目，並作為系爭專案繼續執行之基礎。
㈢上訴人抗辯：被上訴人應交付編號2.1文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云。惟查，工作說明書第1.5.2條明定編號2.1交付項目之格式為「Power Point or Word」（原審卷1第63頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號2.1文件電子檔儲存至「team room」以為交付等語，有之㈡所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈣綜上事證，堪認被上訴人主張其已依約完成編號2.1交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號3.2交付項目之爭點，得心證之理由如下：
㈠引用之㈠論述，推定被上訴人已完成階段⒈至⒊交付項目，自包
括完成編號3.2之交付項目，即建置階段中關於「社群行銷」之細項「Analysis Report (分析報告)」（原審卷1第64頁；原審卷4第268頁），上訴人否認之，應提出足以推翻該已推定事實之反證。
㈡工作說明書第1.5.2條載明編號3.2之類型為「文件」，依之㈡，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
查被上訴人主張：伊於103年8月27日交付編號3.2文件等語，業據提出被上訴人於同日提交予上訴人之服務完成確認單影本（原審卷2第73頁）為證，並有上訴人提出103年8月28日專案會議紀錄影本所示結論內容，於「社群行銷」下第3點記載「S
MA Analysis report review was completed on 8/27with Tingwei and Roxanne.【張庭瑋及陳潤德已於8月27日審核（被上訴人主張譯文）或檢視（上訴人主張譯文）社群媒體分析報告」（原審卷5第31頁；本院卷1第437頁），可資佐證，復為上訴人是認（本院卷1第360頁），堪予信實。則上訴人如未提出證據證明其於收受編號3.2文件後5個工作日内（即103年9月3日前），曾以書面提出修訂要求，依上開約定，於103年9月4日視為被上訴人完成編號3.2交付項目，並作為系爭專案繼續執行之基礎。
㈢上訴人抗辯：上開103年8月28日專案會議紀錄所示結論內容，
於「社群行銷」下第1點記載「IBM team will fetch 500 da-
ta from each SC/TC model to re-test them.（被上訴人團隊將從簡體與繁體中文模型各擷取500筆資料，重新測試）」，且被上訴人之人員Clare Hsiao於同日以電郵寄編號3.2文件
5.5版給張庭瑋及陳潤德，同時表示「follow up act-ions asfollowing（後續待辦事項如下）」：「⒈Clare wi-ll provi
de Facebook Fanpage Chinese Coverage.⒉Clarewill provide sites by "Global, EMEA, NAM, APAC, China,
Taiwan" for TingWei to double check with regional own-er. ⒊TingWei will collect regional sites to IBM forsetting up media set.（⒈Claire將提供臉書粉絲頁中文範圍。⒉Claire將依據全球、EMEA、NAM、APAC、中國及台灣提供站點，以供張庭瑋再次與區域所有人確認。⒊張庭瑋將蒐集區域站點資料予被上訴人以建立媒體組合）」，足見被上訴人交付編號3.2文件後，伊曾於5個工作日內表示意見並拒絕接受該文件云云，以之㈡所示會議紀錄及於本院提出之電郵影本（原審卷5第31頁；本院卷1第379、381、437頁）為證。惟依前開之㈢，社群媒體分析程式乃由上訴人向IBM購買之授權程式商品，關於社群媒體分析程式使用所生問題，係依上訴人與IBM間訂立之授權合約解決，並非被上訴人之責任。再依工作說明書第
1.1.1節「社群行銷」下之第1.1.1.1條「SocialListening（社群聆聽）」約定：「IBM will build up SMA,
and will provide the training to HTC to use and maint-
ain this system afterward in accordance to this SOW.（被上訴人將建置社群媒體分析程式，並對上訴人提供訓練，使其後續得以依照本工作說明書之規定使用及維護本系統）」（原審卷1第34頁；原審卷4第213頁），是被上訴人負責在上訴人之系統中安裝、建置社群媒體分析授權程式商品，及訓練上訴人之人員使用該程式，至於上訴人使用該程式之效果如何，非被上訴人應負責或擔保。又被上訴人主張：編號3.2文件係紀錄於103年5月11日起至7月16日止期間使用社群媒體分析程式分析所得資料等語，為上訴人所不爭執，則前開會議紀錄及電郵內容，係針對分析結果討論後續測試作業，及說明103年8月28日以後預定進行之工作內容，顯非由上訴人專案經理依工作說明書第1.6節之第2條b項約定，以書面列出編號3.2文件之修訂要求，上訴人所辯為不可採。上訴人既未提出其他證據證明其於收受編號3.2文件後5個工作日内曾依約以書面提出修訂要求，應視為此交付項目於103年9月4日完成。
㈣上訴人抗辯：Clare Hsiao於103年11月18日以電郵寄送編號
3.2文件給伊之人員Debby Chen，足見被上訴人於103年8月27日交付編號3.2文件後，伊曾於5個工作日內表示意見並拒絕接受該文件云云，提出電郵影本（原審卷5第167頁）為證。惟被上訴人主張：因Debby Chen於103年11月間向Clare Hsiao索取編號3.2文件，Clare Hsiao乃以檔名「SMA—Analysis_Report_0828v5.5_Final.ppt」（其中「0828」指103年8月28日，「Final」指「最終交付項目」）寄送伊於103年8月27日交付之編號3.2文件5.5版予Debby Chen等語，核與該電郵內容及此一交付項目依約視為於103年9月4日完成乙節相符，是上訴人之抗辯委無可取。
㈤上訴人抗辯：被上訴人專案人員Claire Hsiao於103年10月14日
請伊之專案人員提出「 On-going job export slow. Expo-rt
takes 2 days to finish, and documents lost duringexport.」之PMR以利IBM協助調查，Anda Chen並於103年10月17日向張庭瑋解釋PMR內容為「被上訴人導入社群媒體分析程式過程中有諸多需要修正的錯誤，最主要是整合社群媒體分析程式與第三方資料供應商，致原訂上線時程自6月15日延至9月30日，故請求社群媒體分析程式產品團隊支援」，嗣IBM於103年12月6日回覆其中有6筆PRM是「HTC doesn't agree to clo-
se these PMRs as no place for them to track the status
of ERs, although no any actions on these PMRs. We nee
d to work together to get those sorted next week.（上訴人不同意結案這些PMR ，因為無位置可以追蹤這些ERs的狀態，儘管在這些PMR上沒有任何動作。我們必須合作才能在下週處理。）」，足見伊於103年12月6日前曾告知被上訴人社群媒體分析程式之PMR清單仍有部分無法結案，即不接受被上訴人交付之編號3.2文件云云，提出電郵影本（原審卷5第33、17
1、177頁）為證【參見被上訴人提出之中譯文（本院卷1第567頁）】。惟上訴人未依工作說明書第1.6節之第2條b項約款提出修訂要求，編號3.2交付項目已視為完成。又上訴人使用社群媒體分析程式所生問題，係依上訴人與IBM間訂立之授權合約解決，並非被上訴人之責任。且被上訴人主張：伊之專案經理李珉玲於103年10月17日電郵表示「As discussed in the
PMO meeting, I can not answer your #1& #2 questions
for the product team. I have copied Jessica Ti who is
the SW product sales focal point.（如同我在專案經理會議中所述，我無法代替產品部門回答您的問題1、2，並於此電郵副知軟體產品銷售部門聯絡人Jessica Ti）」，上訴人乃依其與IBM間之授權合約，向IBM在中國之「IBM Business Anal-ytics Client Center→Find information and support for y
our products」(下稱IBM國際客服中心）提出「Service Re-quest（簡稱SR，即服務需求）」，經該中心建立「PMR」（即Problem Management Report）編號，嗣由該中心之客服與支援經理韓津（Jin Han）以上開103年12月6日電郵回覆處理結果予上訴人，而其表示尚有13個「open PMRs（開啟處理中的PMR）」，不包括103年10月17日電郵中所列5個PMR（編號49362,999,858、49374,999,858、05421,999,858、05425,999,858、05426,999,858），可見IBM業已處理結案等語，與上開電郵內容（原審卷5第171頁；本院卷1第567至569頁）相符，是上訴人此部分抗辯亦不可採。
㈥上訴人抗辯：被上訴人應交付編號3.2文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號3.2交付項目之格式為「Power Point or Word」（原審卷1第64頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號
3.2文件電子檔儲存至「team room」以為交付等語，有之㈡所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈦上訴人抗辯：被上訴人專案經理李珉玲於103年8月24日寄送之電郵表示社群媒體分析報告推遲確認云云，提出該電郵影本（原審卷5第29頁；本院卷1第428、447頁）為證，然引用之㈢理由，應認上訴人所辯亦不可採。
㈧上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，伊之專案人員均未簽署之㈡所示服務完成確認單，應認被上訴人未完成編號3.2交付項目云云，然引用之㈣理由，此部分抗辯亦不足採。
㈨綜上事證，堪認被上訴人主張其已依約完成編號3.2交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號3.3交付項目之爭點，得心證之理由如下：
㈠引用之㈠論述，推定被上訴人已完成階段⒈至⒊交付項目，自包
括完成編號3.3交付項目，即建置階段中關於「社群行銷」之細項「CDM data model (CDM資料模型)」（原審卷1第64頁；原審卷4第268頁），上訴人否認之，應提出足以推翻該已推定事實之反證。
㈡工作說明書第1.5.2條載明編號3.3之類型為「文件」，依之㈡，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
查被上訴人主張：伊於103年7月3日交付編號3.3文件等語，有上訴人提出被上訴人於103年7月9日提交予上訴人之服務完成確認單影本（原審卷4第451頁），內載交付「HTC_CCT_BD_SCV_UT_Unit Test Report_V2 1 Word File」，並註明「This deliverable includes CDM data model（此檔案包括C-DM資料模型）」可憑，且上訴人之「SCV IT Leader（單一客戶視圖資訊長）」王文泰及專案經理劉冠廷業於其上簽認，堪予信實。則上訴人如未提出證據證明其於收受編號3.3文件後5個工作日内（即103年7月10日前），曾以書面提出修訂要求，依上開約定，於103年7月11日視為被上訴人完成編號3.3交付項目，並作為系爭專案繼續執行之基礎。
㈢上訴人抗辯：之㈤所示Claire Hsiao、Anda Chen及IBM之電郵
內容，足證伊於103年12月6日前表明拒絕接受被上訴人交付之編號3.3文件云云。惟上訴人未依工作說明書第1.6節之第2條b項約款提出修訂要求，編號3.3交付項目已視為完成。且引用之㈤論述，堪認上訴人此部分抗辯為不可採。
㈣上訴人抗辯：被上訴人應交付編號3.3文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號3.3交付項目之格式為「Power Point or Word」（原審卷1第64頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號
3.3文件電子檔儲存至「team room」以為交付等語，有之㈡所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈤綜上事證，堪認被上訴人主張其已依約完成編號3.3交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.1交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.1係「測試」階段下之「社群
行銷」下之細項「HTC Analysis Model (Model 1 & Model 2）of each language」【各語言之分析模型（模型1與模型2）】，類型為「文件」，依之㈡，兩造約定完成標準按工作說明書第1.6節及其下第2條定之。查被上訴人主張：兩造於103年12月4日專案會議就社群行銷作成「•SMA system is d-own on12/3 due to storage adjustment for better perf-ormance. IBM team will identify the root cause, and t-hen explain to HTC team in detail for 12/4 further ac-tion. (Done)• To collect a complete set of data forDecember, IBM team highly suggested HTC team to activ-
ate SMA model 1 from 12/5. The system was formally ac-tivated on Friday, 12/5. SMA model 2 plans to go live
on 12/19; and SMMS follows to go live no later than J-
an 9, 2015.【1.為提升效能，社群媒體分析程式（SMA，下同）在12月3日因調整儲存系統而停機。被上訴人團隊將判定根本原因，然後向上訴人團隊詳細解釋12月4日的下一步措施（已完成）。⒉為收集完整的12月數據，被上訴人團隊強烈建議上訴人團隊從12月5日起啟用社群媒體分析程式的模型1。該系統已於12月5日星期五正式啟用。社群媒體分析程式的模型2預計在12月19日上線，緊接著社群媒體管理系統（SMMS，下同）預針將於104年1月9日以前上線。】」結論，伊嗣於103年12月5日交付編號4.1文件，其後兩造於103年12月11日專案會議就「社群行銷」作成「Successfully activated SMA Model 1 o
n 12/05. Also done Model 2 environment installation an
d now is being monitored.（已在12月5日成功地啟動社群媒體分析程式模型1，模型2之環境已安裝完成，現正監視中）」結論等語，有被上訴人提出之會議紀錄、編號4.1文件列印工作表等影本（原審卷2第352頁；本院卷2第27至113、115頁），及上訴人提出被上訴人於103年12月19日提交予上訴人之服務完成確認單、會議紀錄、電郵等影本（本院卷1第481、501頁）【參見被上訴人提出之中譯文（本院卷1第535、567至569頁）】可稽，並為上訴人所不爭執，堪予信實。則上訴人如未提出證據證明其於收受編號4.1文件後5個工作日内（即103年12月12日前），曾以書面提出修訂要求，依上開約定，於103年12月13日視為被上訴人完成編號4.1交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.1文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.1交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.1文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之人員簽署，可見此項目未完成云云，然引用九之㈣理由，此抗辯為不可採。
㈣上訴人抗辯：依之㈠所示103年12月4日會議紀錄，及被上訴人
專案人員於103年12月6日以電郵表示社群媒體分析程式共有13個未結案的PMR，其中有文字片段開頭複製標題兩次；分析使用者介面觀感的重點強調不正確；URL文字不應該是觀感用詞；在報告使用者介面中執行相同的篩選時，出現不一致的結果，及欠缺依據篩選概念演進的主題等問題，可知被上訴人於103年12月5日交付編號4.1文件，需要上線運作、蒐集完整資料並釐清社群媒體分析程式根本問題後才達到完成標準云云，提出會議紀錄、電郵等影本（本院卷1第481、501頁）為證【參見被上訴人提出之中譯文（本院卷1第535、567至569頁）】。
惟依之㈤，社群媒體分析程式乃上訴人向IBM購買之授權程式商品，上開電郵係上訴人與IBM國際客服中心間就社群媒體分析程式使用問題之支援服務往來郵件，並非被上訴人之人員所發，顯非之㈡所指書面修訂要求。且觀諸上開之㈠所示編號4.1文件列印工作表，乃以文字表達之字詞、概念、主題等清單，上開電郵所示問題則係上訴人使用社群媒體分析程式過濾各該文字而產生之問題，上訴人並未具體指明其中何者與編號4.1設定之模型有關，即使有關，惟依工作說明書第1.5.2條約定：「Ownership： the definition of owne-rship specification of "HTC Deliverable Ⅰ", "HTC Del-iverab Ⅱ", "blank" are subject to MSA Section 5.（「HTC交付項目I」、「HTC交付項目Ⅱ」、「空白」等項目之所有權歸屬，依主約第5節之規定）」（原審卷1第63頁反面；原審卷4第267頁），再依系爭主約第5.1.1條約定：「HTC will o-wn exclusively a
ll right, title, and interest, in and to all items of
the "HTC Deliverable I" as specified
in the SOW, in which the intellectual property rights
are newly conceived, made, discovered, written, or cr-eated by Company personnel alone, jointly with HTC orjointly with third parties and delivered under this A-greement, whether completed or works-in-progress, andCompany agrees to assign such intellectual property r-ights to HTC.（本工作說明書明訂之「HTC交付項目I」，其中單獨由被上訴人人員，或由其聯合上訴人，或聯合第三人創新構想、製作、發現、撰寫或創設智慧財產權，且依本合約規定交付之一切項目，不問成品或半成品，其一切權利、所有權及利益均為上訴人獨有，且被上訴人同意將該等智慧財產權讓與上訴人。）」（原審卷1第13頁；原審卷4第190、191頁），而工作說明書第1.5.2條載明編號4.1權屬為「交付項目Ⅱ」（原審卷1第64頁反面），是上訴人於被上訴人完成編號4.1交付項目後，非不得自行在該電子檔修改相關文字設定，故上訴人執此抗辯被上訴人未完成編號4.1交付項目，委無可取。
㈤按工作說明書第1.1「Project Scope（專案範圍）」下之第1.1
.1.1條「社群聆聽」約定：「Social Listening, using IBMSocial Media Analytics Vl.2.0 for HTC (here and aftercalled SMA) platform, will scrape the social layer for
relevant comments. Specific data analysis rules and t-axonomy will be defined and used to identify user pre-ference and unmet needs from the unstructured data.
HTC will then be able to generate standard reports da-ily, weekly or monthly by management request, and und-erstand at both an aggregated and individual level wh-
at is being said, by whom and the level of sentiment.Additionally, an "alert mechanism” will be built totrigger HTC's timely reaction when the Social Media A-nalytics system capture sensitive buzz that may impact
HTC business.…IBM will configure SMA base upon HTC'srequirement listed as 3 stages described below. If any
requirement is not able to be fulfilled by standard f-unctions, HTC will follow PCR to apply the change req-uest. For reference purpose； the service scope of th-is section is described as follows:…Social Media Ana-lytics will be divided into three stages as listed be-
low: 1.Fetch and Store. 2.Analyze. 3.Present and DeepDive.【「社群聆聽」採用IBM Social Media Analytics for
HTC 1.2.0版（下稱SMA）平台，將貼近地蒐集社群層中相關之評論。將定義特定的資料分析規則及分類架構，並利用此等規則及分類架構，從非結構化資料中識別使用者喜好設定及未符合之需求。上訴人得以依管理要求，每日、每週或每月產生標準報告，並從集體及個別之層次瞭解發言内容、發言人及觀感層次…被上訴人將依照以下所述3階段所示上訴人需求配置SM-A。如有任何需求未能由標準功能而履行，上訴人應遵循PCR提出變更要求。…社群媒體分析系統分為下列3個階段：1.提取及儲存。2.分析。3.呈現及深入探討。】」、「Stage 1: Fe-tc
h and Store: The service scope of this stage is def-in
ed as following, • Language: - English, Simplified Chinese, Traditional Chinese. (Note; System Capability wi
ll be 7 languages: English, German, Spanish, French, Dutch, Traditional Chinese, Simplified Chinese.) • D-at
a Source Scope: - BoardRead-er, GNIP, and Klout. • Business Topic Scope: - Model 1 〈Trend Model〉: HTCMobile device relevant topics, Including Brand Image,customer experience, competitor's analysis. - Model 2〈Responding Target Model〉: HTC Social Media Monitor-in
g Model. The results of this model will be stored in Customer Data Mart 〈COM hereafter〉 and provided for campaign management tool 〈IBM Campaign〉 use. - Each Model
consists of 3 above languages. The Simplified C-hines
e analytics under model 1 and 2 are similar those forTraditional Chinese, except some linguistic adjus-tmen
t due to culture or language difference.【第1階段：提取及儲存：本階段服務範圍確認如下：•語言：英文、簡體中文、繁體中文（附註：系統功能提供7種語言的能力：英文、德文、西班牙文、法文、荷蘭文、繁體中文、簡體中文。）‧資料來源範圍：BoardReader、GNIP及Klout。•商業主題範圍：模型1（趨勢模型）：「HTC行動裝置」相關主題，包括品牌形象、客戶體驗、競爭者分析。模型2（回應目標模型）：上訴人社群媒體監視模型。此模型之結果將儲存於「客戶資料集區」（下稱CDM），並供行銷活動管理工具（IBM Ca-mpaign）使用。各模型均包含至少3種語言。模型1及模型2中之簡體中文分析，除因文化或表達方式之差異所致用字遣詞上之若干調整外，大致與繁體中文分析類似。】」、「Stage 2:…IBM wil
l set up the configuration of SMA as followi-ng to customize HTC analysis model: 1.Types and Conce-pt: A concept is a topic that is relevant for a speci-fic use c
ase. A type is a group of concepts that belo-ng togeth
er. IBM Social Media Analytics uses types and concepts
to create and analyze. IBM will assist HTC to definetypes and concepts by defining key words in SMA to analyze the documents. 2.Hotwords: Hotwords are te-rms of
interest that act as filters to help HTC narrow HTC'sdata result set. IBM will assist HTC to definepatterns of words, referred to as include terms and e-xclude terms, that are included or excluded while sea-rching for relevant snippets. 3.Sentiments: IBM Social
Media Analytics combines linguistic rules with the li-sts of positive, negative, and blocking sentiment ter-ms to determine positive or negative sentiment. IBM w-ould assist HTC to define sentiment terms and blocker
s in SMA to better analyze sentiment results.（被上訴人將依下列方式設定社群媒體分析程式之配置，以客製上訴人分析模型：…⒈類型與概念：概念係指有關特定使用案例之主題。類型則為一起歸於同一整體之概念。社群媒體分析程式利用類型與概念來進行建立與分析。被上訴人將協助上訴人定義社群媒體分析程式中之關鍵字，以分析文件。⒉熱門字詞：熱門字詞係指作為過濾器之屬意用詞，用以協助上訴人縮小其資料結果集之範圍。被上訴人將協助上訴人定義在搜尋相關文字片段時所包含或排除之字詞型樣。⒊觀感：社群媒體分析程式將語言規則與正面、負面及封鎖等觀感用詞之清單結合在一起，以判斷正面或負面觀感。被上訴人將協助上訴人定義社群媒體分析程式中之觀感用詞及封鎖器，以優化分析觀感結果）（原審卷1第34頁反面、第35頁；卷4第213至215頁）。查被上訴人以開發之編號4.1分析模型使用社群媒體分析程式測試後，於103年5月29日寄送103年5月26日至29日分析測試結果予上訴人，表示英文模型之觀感正確率在56%-67%區間；上訴人之專案人員陳潤德於103年5月30日發電郵予被上訴人之專案人員表示：「SMA is THE most important element in this e-ntireproject as everything derives from it. From the attach
ed report, you can see that after having been "tuned" for 3weeks, its sentiment accuracy is still 57%. This is NOT acceptable and greatly damaging our fai-
th in IBM, who we believed should be one of the bestproblem solvers out there.（社群媒體分析是整個專案最重要的要素，因為所有事情都是由該要素所衍生。依據附件報告，您可以看到經過三週調整以後，觀感分析正確率仍為57%，這是無法接受並嚴重影響我們對於被上訴人作為最佳解決方案提供者之一的信賴。）」；被上訴人之製造業事業群副總經理Ginnie Hsu（此有上訴人提出被上訴人之人員Eric Wang於104年2月5日以電郵提供系爭專案結案後之額外支援選項產品說明，有副知Ginnie Hsu可知，本院卷2第209至220頁）於103年6月28日發電郵予上訴人之負責人甲○○，表示：「We are so
rry for SMA product bugs which impacts CCT projectperformance and schedule. IBM top management team arewell aware and has engaged to solve…Enhancements will
be added to SMA but it takes time; SMA Lab will provi-
de a plan after detailed assessment but it won't be "immediate".（我們對於社群媒體分析程式之問題致影響本專案執行情形與期程感到抱歉，IBM高階管理團隊已充分知悉並將解決此問題…社群媒體分析程式將進行產品提升但此需要時間，社群媒體分析程式實驗室將在詳細評估後提供計劃，但這無法立即完成。）」，係針對社群媒體分析程式之產品本身之設計及功能，影響系爭專案成果表現，表達歉意，及表示產品團隊將研究加強程式功能；陳潤德於103年7月1日發電郵予被上訴人之專案人員，表示一再要求被上訴人就英文模型之觀感正確率提出「Deatailed improvement plans（詳細改善計畫）」，但被上訴人未提出；被上訴人之專案人員於103年8月12日寄送1,617則簡體中文觀感分析測試結果，其中1,136則與觀感有關，經模型分析測試正確率為69%，至於350則未能正確分析之原因，其中201則係觀感用詞未正確定義，其餘尚待調查；被上訴人之專案人員於103年9月4日以電郵寄送1,649則英文觀感分析測試結果，其中799則與觀感有關，經模型分析測試正確率為66%（即799-274=525則），該274則未能正確分析之原因，其中100則係觀感用詞未正確定義，其餘尚待調查；被上訴人之專案人員於103年9月9日以電郵寄送同年8月1至30日就共計500則簡體中文觀感分析測試結果，其中398則與觀感有關，經模型分析測試正確率為64%；張庭瑋於103年9月10日以電郵回覆：「The sentiment accuracy goes down from p-revious testing (69%→64%), although relevancy goes up (70%→80%). 60~percent accuracy (for both Simplified & Traditional Chinese) is NOT acceptable and far from w-ha
t Product team claimed. Please come up a plan to en-ha
nce.【觀感分析正確率從先前測試結果下滑（從69%到64%），儘管關聯性有提升（從70%到80%），但60%左右的正確率（對於簡體與繁體中文而言）是無法接受的，且遠遠未達產品團隊所宣稱的。請提供方案以提升之）】」，有上訴人提出之電郵影本（原審卷1第372至376頁；原審卷2第256、252頁；本院卷1第469、477頁。參見被上訴人提出之中譯文，本院卷1第543、533頁）可稽，則被上訴人以客製之分析模型，使用社群媒體分析程式進行觀感分析之正確率，不能排除係受社群媒體分析程式本身規格、功能影響所致。且依之㈠，經過多次分析測試後，被上訴人於103年12月5日交付編號4.1文件最終版，上訴人既未提出證據證明其於收受該文件後5個工作日内曾以書面提出修訂要求，仍視為被上訴人於103年12月13日完成此交付項目。
㈥按工作說明書第1.2.1.1條「社群聆聽之假設」第5項約定：「M
aximum of 3 alert mechanism rules will be created
and designed in SMA, Alert mechanism will define alerttrigger points, alert frequency, and alert delivery m-ethods (E-mail/Report or Dash board).【社群媒體分析程式中至多可建立及設計3項警示機制規則。警示機制將確立警示觸發點、警示頻率及警示遞送方法（電子郵件/報告或儀表板）】」（原審卷1第47頁；原審卷4第236、237頁）。上訴人抗辯：被上訴人交付編號1.1之「Social Marketing KPI doc-ument（社群行銷關鍵績效指標文件）」中之「Objectives a-
nd Strategic KPI: Listening and Profiling（目標及策略性關鍵績效指標：聆聽和側寫）」記載103年目標，就社群媒體分析報告滿意度1-5，可達到4，就警示機制正確率達到75%等語，固提出該文件影本（本院卷2第161、247頁）為證。然查，該文件開頭即說明其「Purpose（目的）」為「This doc-ument defines the "what, why, & who" of social market-
ing KPIs.（本文檔定義了社群行銷關鍵績效指標之內容、原因及對象」、「The "where, when, & how" of KPIs in this
document are for discussion purposes only to be final-ized based on campaign design and rollout plans durin
g custom report design & enablement.（本文中之社群行銷開始的「地點、時間及方式」僅供參考。將會在制定過程中，根據活動設計和推出之計畫進行最終確定。）」（本院卷2第150、244頁），是前開目標及策略性關鍵績效指標並非兩造約定之完成標準，上訴人執以抗辯被上訴人未完成編號4.1交付項目，顯然無稽。
㈦上訴人抗辯：被上訴人之網站廣告：「社群媒體分析是一種功
能強大的工具，它可以揭露散佈在無數線上資源的客戶觀感…IBM的社群媒體分析解決方案可協助組織掌控這方面的資料，從而提高客戶滿意度、識別模式與趨勢，以及制定與行銷活動相關的智慧決策。IBM社群媒體分析解決方案可協助貴公司：⑴從社群媒體擷取客戶資料，以瞭解態度、意見、趨勢並且管理線上聲譽；⑵預測客戶行為，然後藉由建議最佳的下一個行動來提高客戶滿意度；⑶建立能夠讓社群媒體參與者產生共鳴的客製化行銷活動與促銷；⑷識別特定社群網路管道中的主要影響力」、「IBM Social Media Analytics可協助企業瞭解社群媒體對他們產品、服務、市場、行銷活動、員工及合作夥伴的影響，並且依分析結果採取行動。本產品可分析數十億的社群媒體評論，並透過可配置的圖表與儀表板提供自訂結果」；被上訴人於102年發表關於IBM社群媒體分析程式產品介紹，表示「
IBM Social Media Analytics能協助企業使用社群媒體洞悉消費者意見，及識別消費者對產品與品牌的喜好等相關趨勢。IB
M Social Media Analytics是一種分析應用程式，具有無與倫比的可擴充性，能協助您了解消費者對貴公司的所見所聞，以及他們對貴公司的意見批評。其可協助您回答以下問題：•消費者對我們最新的廣告行銷活動反應如何？他們的回饋是正面還是負面？」、「研究自然語言處理有20年以上經驗的IBM，支援多語言感受分析（multi-lingual sentiment an-alysis)，能測量跨多重社群媒體管道所進行大量對話之語氣和意圖。所謂感受，是指特定消費者評論是正面、負面、中性還是矛盾。這些感受詞彙會與已加入管理入口（administrat-ion portal）的特定感受及阻礙詞彙（blocker terms）比較，因此甚至連流行用語也可以納入分析。」，固提出廣告截圖影本（原審卷2第250、251頁；本院卷2第139至146頁）為證。惟查，系爭契約未將上述廣告內容納為「完成標準」，且社群媒體分析程式乃上訴人購買之IBM授權程式商品，依之㈢，被上訴人未為任何聲明、保證或承諾，上訴人主張該商品應具備廣告所示品質或功效乙節，係上訴人與授權廠商間簽訂之授權合約之問題，是上訴人執此抗辯被上訴人未完成編號
4.1交付項目，亦無可憑採。㈧綜上事證，堪認被上訴人主張其已依約完成編號4.1交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.2交付項目之爭點，得心證之理由如下：
工作說明書第1.5.2條載明編號4.2係「測試」階段下之「社群行銷」下之細項「SMA Application & Report Training with
Training Materials【社群媒體分析應用程式與報告訓練（含訓練教材）】，類型為「訓練」（原審卷1第64頁反面；原審卷4第269頁），依之㈡，兩造約定完成標準按工作說明書第
1.6節第3條決之。查上訴人主張：伊於103年9月9日13:00至18:00；103年9月12日13:00至18:00；103年9月15日13:00至18:
00；103年9月16日14:00至17:00，及103年9月17日14:00至18:
00，進行編號4.2教育訓練，到場之上訴人人員均已簽認等語，業據提出上訴人不爭執真正之簽到單影本（原審卷2第78至82頁）為證。且依論述，上訴人於103年12月間在社群媒體分析程式啟用編號4.1模型，屢經測試，於103年12月5日交付該模型最終版，並於103年12月13日視為完成此交付項目，據此堪推定上訴人之專案人員在此之前業已接受編號4.2教育訓練。上訴人復未具體抗辯編號4.2教育訓練有何未完成情事，則依上開約定，視為編號4.2教育訓練全部完成。
關於被上訴人是否依約完成編號4.3交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.3係「測試」階段下之「論壇
」下之細項「HTC Integration Test Report（整合測試報告）」，類型為「文件」（原審卷1第64頁反面；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年9月22日交付編號4.3文件等語，業據提出被上訴人於103年9月25日提交予上訴人之服務完成確認單影本（原審卷2第74頁）為證，且上訴人之「Community IT Leader」王文泰已於其上簽認（原審卷1第271頁），上訴人亦不爭執交付之事實（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.3文件後5個工作日内（即103年9月29日前），曾以書面提出修訂要求，依上開約定，於103年9月30日視為被上訴人完成編號4.3交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.3文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.3交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.3文件電子檔儲存至「team room」以為交付等語，有之㈠服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣上訴人抗辯：工作說明書第1.1.2節「論壇」下之第1.1.2.2條
約定：「In this diagram, HTC community has interactio-
ns with four systems: HTC account, digital analyticstool, and Single Customer View (SCV). HTC account and
HTC comtnunity: The user repository will be integratedwith HTC account. HTC account will enable HTC custome-rs to login HTC web sites using HTC account and ident-ities from social networks. Site Catalyst and HTC com-munity: Member activities in community will be recor-ded by the Site Catalyst. The tool analyzes user acti-vities and come out individual user preferences. Sing-le Customer View (SCV) : The membership attributes su-ch as hierarchy status, member social profile, and de-gree of influence will be the input information from
HTC community to SCV. This will enable SCV tobuild in-dividual user information and deliver accurate market-
ing messages.（上訴人論壇與4個系統進行互動：上訴人帳戶、數位分析工具及單一客戶視圖。⒈上訴人帳戶及論壇：使用者儲存庫將與上訴人帳戶整合。上訴人帳戶可讓上訴人客戶使用社群網路所提供之上訴人帳戶與ID，登入上訴人網站。⒉SiteCatalyst與上訴人論壇：SiteCatalyst會記錄論壇中之成員活動。此工具會分析使用者活動，並產生個別使用者喜好設定。3.單一客戶視圖：成員資格屬性（例如：階層狀態、成員社群資訊及影響程度）係從上訴人論壇輸入至單一客戶視圖之資訊。此資訊可讓單一客戶視圖建置個別使用者資訊及遞送精準行銷訊息。）」（原審卷1第38頁反面；原審卷4第221頁），故被上訴人需將論壇資料匯入單一客戶視圖，始能完成編號第
4.3之系統整合測試報告云云。惟查，上開約款係說明上訴人之「論壇」與何種應用程式互動及其產生之效果，無從憑以認定上訴人執行編號4.3工作之際，上訴人之「論壇」與約定應用程式處於不能互動狀態。又依工作說明書第1.3.5節「測試」約定：「The Test Phase is to validate the res-ults o
f the Build Phase in which the unit test will be performed for each track. System level tests verify p-roper
execution of the entire application componentsincluding Interfaces with other applications. Both fu-nctional and structural types of tests are performed
to verify that the system is functionally and operati-onally sound.（測試階段之目的，在於驗證建置階段之結果，會針對每項追蹤作業進行單元測試。系統層次測試可驗證全部應用程式元件能否正常執行，包括用以與其他應用程式互通之介面。會同時執行功能與結構類型之測試藉以驗證系統之功能與運作是否正常。）」（原審卷1第59頁；原審卷4第259頁），被上訴人進行「論壇」系統整合測試之前，必然已與上述4種系統處於互動狀態，且上訴人收受編號4.3文件後5個工作日內，從未以「論壇」尚未與上述4種系統完成互動，無從測試驗證其功能與運作是否正常為由，主張編號4.3文件不符合整合測試需求。是上訴人此一抗辯洵無可取。
㈤綜上事證，堪認被上訴人主張其已依約完成編號4.3交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.4交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.4係「測試」階段下之「論壇
」下之細項「HTC Performance Test Report（效能測試報告）」，類型為「文件」（原審卷1第64頁反面；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年7月14日交付編號4.4文件，嗣於104年1月15日系爭專案第46週會上之簡報第19頁「測試階段進度表」載明「論壇」測試階段活動於103年7月21日結束等語，業據被上訴人提出週會簡報影本（原審卷2第25、189頁）為證，並有上訴人提出被上訴人於103年9月29日提交予上訴人之服務完成確認單影本（原審卷1第323頁）可資佐證，且上訴人之「Community IT Leader」王文泰業於該確認單上簽認（原審卷1第271頁），上訴人亦不爭執交付之事實（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.4文件後5個工作日内（即103年7月21日前），曾以書面提出修訂要求，依上開約定，於103年7月22日視為被上訴人完成編號4.4交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.4文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.4交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.4文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.4交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.5交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.5係「測試」階段下之「SCV,
Integration & Architecture（單一客戶視圖、整合與架構）」下之細項「Integration Test Report （整合測試報告）」，類型為「文件」（原審卷1第64頁反面；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年7月18日交付編號4.5文件，於103年9月25日提交服務完成確認單，經上訴人之員工Jun chi（黃俊旗）代理上訴人之「Social Marke-ting ITLeader」王文泰簽認等語，業據提出服務完成確認單影本（原審卷4第481頁）為證，上訴人亦自認簽署人有權代理（本院卷2第227、228頁），堪予信實。則上訴人如未提出證據證明其於收受編號4.5文件後5個工作日内（即103年7月25日前），曾以書面提出修訂要求，依上開約定，於103年7月26日視為被上訴人完成編號4.5交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.5文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.5交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.5文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.5交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.8交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.8係「測試」階段下之「單一
客戶視圖」下之細項「Cutover plan（快速轉換計劃）」，類型為「文件」（原審卷1第64頁反面；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年9月16日交付編號4.8文件等語，有上訴人提出被上訴人於103年12月16日提交服務完成確認單（內載「Note: The above file includes both
SCV and Integration related Cutover plans（註記：上開檔案包括單一客戶視圖及與整合相關之快速轉換計畫）」影本（原審卷1第329頁）為證，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.8文件後5個工作日内（即103年9月23日前），曾以書面提出修訂要求，依上開約定，於103年9月24日視為被上訴人完成編號4.8交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.8文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.8交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.8文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.8交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.9交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.9係「測試」階段下之「單一
客戶視圖」下之細項「Data Model（資料模型）」，類型為「文件」（原審卷1第64頁反面；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年9月16日交付編號4.9文件等語，有上訴人提出被上訴人於103年12月16日提交之服務完成確認單影本（原審卷1第324頁）為證，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.9文件後5個工作日内（即103年9月23日前），曾以書面提出修訂要求，依上開約定，於103年9月24日視為被上訴人完成編號4.9交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.9文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.9交付項目之格式為「PDF」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.9文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.9交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.12交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.12係「測試」階段下之「整合
與架構」下之細項「Cutover plan（快速轉換計劃）」，類型為「文件」（原審卷1第65頁；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年9月16日交付編號4.12文件，嗣於103年12月16日提交予上訴人之服務完成確認單註記如之㈠所示內容等語，有上訴人提出該服務完成確認單影本（原審卷1第329頁）可稽，堪予信實。上訴人既未提出證據證明其於收受編號4.12文件後5個工作日内（即103年9月23日前），曾以書面提出修訂要求，依上開約定，於103年9月24日視為被上訴人完成編號4.12交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.12文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.12交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.12文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.12交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.13交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.13係「測試」階段下之「整合
與架構」下之細項「Support ticket & log summary （支援問題單與日誌摘要）」，類型為「文件」（原審卷1第65頁；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年8月18日交付編號4.13文件，嗣於103年10月23日提交服務完成確認單，經上訴人之「IT Leader」王文泰簽認等語，有上訴人提出該服務完成確認單影本（原審卷1第332頁）可稽，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.13文件後5個工作日内（即103年8月25日前），曾以書面提出修訂要求，依上開約定，於103年8月26日視為被上訴人完成編號4.13交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.13文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.13交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.13文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.13交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.14交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.14係「測試」階段下之「CRM
Integration（CRM整合）」下之細項「 Modifications to c-allcenter key（電話客服中心關鍵使用者操作手冊修改）」，類型為「文件」（原審卷1第65頁；原審卷4第269頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年11月25日交付編號4.14文件，及提交服務完成確認單，經上訴人之「CRM Integratio
n BU Leader」Nels Nelson及「CRM Integration IT Leader」王文泰簽認等語，有上訴人提出該服務完成確認單影本（原審卷1第331頁）可稽，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.14文件後5個工作日内（即103年12月2日前），曾以書面提出修訂要求，依上開約定，於103年12月3日視為被上訴人完成編號4.14交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.14文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.14交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.14文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.14交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.15交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.15係「測試」階段下之「So-f
tLayer」下之細項「Backup and Restore Drill Plan（備 份及還原服務計劃）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年12月26日交付編號4.15文件，及提交服務完成確認單，經上訴人之「System Infrastructure Leader」Jeff Lin簽認等語，有上訴人提出該服務完成確認單影本（原審卷1第330頁）可稽，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.15文件後5個工作日内（即104年1月6日前），曾以書面提出修訂要求，依上開約定，於104年1月7日視為被上訴人完成編號4.15交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.15文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.15交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.15文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.15交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.16交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.16係「測試」階段下之「So-f
tLayer」下之細項「Backup and Restore Drill report（備份及還原服務報告）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年12月26日交付編號4.16文件，及提交服務完成確認單，經上訴人之「System Infrastructure Leader」Jeff Lin簽認等語，有上訴人提出該服務完成確認單影本（原審卷1第330頁）可稽，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號4.16文件後5個工作日内（即104年1月6日前），曾以書面提出修訂要求，依上開約定，於104年1月7日視為被上訴人完成編號4.16交付項目，並作為系爭專案繼續執行之基礎。
㈡上訴人抗辯：被上訴人應交付編號4.16文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.16交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.16文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.16交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.17交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號4.17係「測試」階段下之「Ov-e
rall SIT（整體系統整合測試）」下之細項「SIT(即System Integration Test)test report（系統整合測試報告）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。查被上訴人主張：伊於103年7月18日交付編號4.17文件，於103年9月25日提交服務完成確認單，經上訴人之專案人員黃俊旗代理上訴人之「Social Marketing IT Leader」王文泰簽認等語，業據提出服務完成確認單影本（原審卷4第481頁）為證，上訴人亦自認簽署人有權代理（本院卷2第227、228頁），堪予信實。則上訴人既未提出證據證明其於收受編號4.17文件後5個工作日内（即103年7月25日前），曾以書面提出修訂要求，依上開約定，於103年7月26日視為被上訴人完成編號4.17交付項目，並作為系爭專案繼續執行之基礎。㈡上訴人抗辯：被上訴人應交付編號4.17文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號4.17交付項目之格式為「Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號4.17文件電子檔儲存至「team room」以為交付等語，有之㈠所示服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈠所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣上訴人抗辯：依之㈠，被上訴人於103年9月22日交付編號4.3「
論壇整合測試報告」，不可能於103年7月18日交付編號4.17「整體系統整合測試報告」云云。惟查，測試報告係於測試結束後製作，是被上訴人完成「論壇整合測試」、「整體系統整合測試」後，始會製作交付編號4.3、4.17報告，換言之，無從以交付各該報告期日，推定執行整合測試之先後順序。又按工作說明書第1.1.8.2條「Entry and Exit Criteria（開始測試與結束測試之準則）」，就「系統整合測試」部分約定開始測試準則為：「•A complete list of all code promotedf
rom the unit test environment has been delivered to t
he test team, as well as all release notes.•All cri-ti
cal unit testing activities for the promoted code h-av
e been completed and signed off by the developmentteam lead.•System test environment in place and oper-ational.（⒈從單元測試環境中晉級之一切程式碼之完整清單，連同版本注意事項，均已交付予測試小組。⒉晉級程式碼之一切重要單元測試活動均已完成，並由開發小組負責人簽字認可。⒊系統測試環境已經備妥，並可運作。）」結束測試準則為：「•All critical system tests have been complet-ed successfully.•Non-critical, open defects have beendocumented in the test tracking database with a plan
for resolution.•All test documentation relating to t-e
st execution and approval has been assembled and all t
est results have been filed in accordance with estab-lished procedures.•A final system test report has be-en
completed for all test focus areas and sign-off by th
e test team has been obtained.（⒈一切重要系統測試均已順利完成。⒉已在測試追蹤資料庫中記載非重大開放式瑕疵，並載明解決計劃。⒊一切有關測試之執行與核准之測試說明文件均已彙整，且一切測試結果已依既定程序歸檔備查。⒋一切測試焦點區域之最終系統測試報告均已完成，且業經測試小組簽字認可。）」（原審卷1第45頁；原審卷4第233、234頁），足見「論壇整合測試」完成後，被上訴人始能進行「整體系統整合測試」，至於測試報告交付日期則係決定交付項目完成之標準，與測試結束時序無涉，是上訴人所辯委無可取。
㈤上訴人抗辯：工作說明書第1.1.3.1條「SCV Data Model（單一
客戶視圖資料模型）」約定：「SCV Data Model is used
to consolidate customer data from different operatingsystems. The Data Model stores the most current custo-
mer information and the original data from differentoperating systems.（單一客戶視圖資料模型係用於合併來自不同作業系統之客戶資料。資料模型儲存來自不同作業系統之最新客戶資料與原始資料。）」；第1.1.3.2條「 Customer D
ata Synchronization Mechanism（客戶資料同步化機制）」約定：「Through the Customer Data Synchronization Mec-hanism, the customer data of the defined systems will
be extracted, transformed and loaded to the SCV datab-
ase of SCV Data Model. The Customer Data Synchronizat-
ion Mechanism Implementation Scope are: 1.Customer Da-
ta synchronization Source System Scope are the same asData Model source system scope. 2.Establish the nearreal-time (1 hour) data synchronization mechanism (ca-ptured in files) to capture the transaction data of c-ustomer information from HTC Account, HTC Community a-
nd China WCS of htc.com. 3. Establish the daily batchdata synchronization mechanism to retrieve daily cust-omer change data (captured in files) from CDM. 4.Build
near real-time (1 hour) data synchronization mechanis
m to retrieve customer change data (captured In files)from either Smart Client/E2E or Sugar CRM customer pr-ofile. 5.Build near real-time (1 hour) data synchroni-zation mechanism to retrieve customer change data (Ca-ptured in Staging DB) from Social Profile Provider.【客戶資料同步化機制：通過「客戶資料同步化機制」，可將已定義系統之客戶資料擷取、轉換並載入單一客戶視圖資料模型之單一客戶視圖資料庫。以下為客戶資料同步化機制施行範圍：⒈客戶資料同步化來源系統範圍同於資料模型來源系統範圍。⒉建立近乎即時（1小時）資料同步化機制（於檔案中擷取），從htc.com之上訴人帳戶、上訴人論壇及中國WCS擷取客戶資料之交易資料。⒊建立每日批次資料同步化機制，從CDM （即Customer Data Mart，客戶資料集區）擷取每日客戶變更資料（於檔案中擷取）。⒋建置近乎即時（1小時）資料同步化機制，從智慧型用戶端/E2E或Sugar CRM客戶人員資訊擷取客戶變更資料（於檔案中擷取）。⒌建置近乎即時（1小時）資料同步化機制，從社群側寫提供人擷取客戶變更資料（於S-taging DB中擷取）】」（原審卷1第41頁反面；原審卷4第227頁），但伊之專案人員Martin Chen（陳冠文）於103年10月24日請求被上訴人解決論壇使用者資料拋回單一客戶視圖資料庫時遺失之問題，經被上訴人之專案人員Kevin Lai（賴啟民）於103年11月13日提出調查結果，再於103年11月24日撰寫程式碼解決該問題，嗣陳冠文於103年12月4日請求被上訴人解決使用者無法連線至各自的社群個人檔案時，伊未能收到反應之問題，被上訴人之專案人員僅回覆提供社群側寫服務予伊之授權商Janrain表示「系統不支援回呼訊息」，未提出任何解決意見，顯見被上訴人開發之論壇系統與單一客戶視圖系統間未能確實執行資料同步機制云云，提出電郵影本（本院卷2第293至300頁。
參見被上訴人提出之中譯文，本院卷2第411至423頁）為證。
然查，上述問題在整體系統整合測試完成，被上訴人於103年7月26日完成編號4.17「整體系統整合測試報告」交付項目，且上訴人於其商業用途作業環境中執行論壇與單一客戶視圖系統時發生，應不影響被上訴人完成編號4.17交付項目之事實。況且被上訴人業已解決論壇使用者資料拋回單一客戶視圖資料庫時遺失之問題。至於使用者無法連線至個人社群檔案時，上訴人未能收到反饋之問題，被上訴人業已表明係因上訴人所使用Janrain之授權程式商品不支援回呼訊息所致，依之㈢說明，屬於上訴人與Janrain間之授權合約問題，被上訴人本無解決該問題之義務，自不得據以否定被上訴人完成編號4.17交付項目之事實。㈥綜上事證，堪認被上訴人主張其已依約完成編號4.17交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號4.10交付項目之爭點，得心證
之理由如下：㈠工作說明書第1.5.2條載明編號4.10係「測試」階段下之「單一
客戶視圖」下之細項「ETL（即「Extract→Transform→Lo-ad」，指將數位資料從來源端，經過「抽取」、「轉置」、「載入」至目的端之過程，下同）job（ETL工作）」，格式為「DataStage」，類型為「Application (with source code)【應用程式（含原始碼）】」（原審卷1第64頁反面；原審卷4第269頁）。兩造於工作說明書第1.6節及其下第1條，就應用程式之完成標準約定：「The Application will be deemedaccepted when either one of the following two conditi-
ons (a,b) is met. a.Go-Live Procedures is completed if:ⅰ.There is/are no severity level 1 defect(s) outsta-nding (Please refer to 1.1.8.3 Defect Severity Level).
As for those defects marked as severity level 2 or 3problems, if any, IBM would fix during the Go-Live su-pport period;ⅱ.HTC and IBM has approved the Go-LiveProcedures before IBM proceeds fulfilling the tasks; ⅲ.Complete to deploy application codes to the design-at
ed production environment; ⅳ.Complete to conduct t-heverification test defined in the Go-Live Procedures, and ⅴ.IBM Project Manager initiates an application u
ser acceptance test confirmation meeting with HTC. A-l
l application problems happened on the production en-vironment, if any, must be submitted and received by
IBM within five working days after the application us-
er acceptance test confirmation meeting held. IBM Pro-ject Manager would initiate a defect confirmation mee-ting and confirm the follow-up plan and action(s) with
HTC Project Manager. b.When Application is running onHTC's business use production environment.【符合下列二項條件（a、b）之一者，即視為「應用程式」已被接受。a.下列情形全數完成者，即完成上線程序：⒈無未解決之嚴重性層次1瑕疵（請參閱1.1.8.3「瑕疵嚴重性層次」）。瑕疵嚴重性層次如有標示為嚴重性層次2或3等問題之瑕疵者，被上訴人於「上線」支援期間修正之；⒉兩造於被上訴人執行作業前已核准「上線」程序；⒊已完成將應用程式之程式碼部署至指定正式作業環境之作業；⒋已完成「上線」程序中所規定之驗證程序；及⒌被上訴人專案經理開始與上訴人進行應用程式使用者驗收測試確認會議。發生於正式作業環境之所有應用程式問題，均應由被上訴人於應用程式使用者驗收測試確認會議召開後5日內提交及收受之。被上訴人專案經理應開始與上訴人專案經理進行瑕疵確認會議，並確認繼續追蹤之計劃與行動。b.「應用程式」已在上訴人商業用途作業環境中執行。）」（原審卷1第65頁正反面；原審卷4第270、271頁）。
㈡被上訴人主張：伊於103年9月16日交付編號4.10應用程式（含
原始碼）等語，提出被上訴人之專案人員Chiwen Chang於103年12月26日回覆上訴人之專案人員陳冠文所詢關於編號4.10原始碼儲存位置及輸出路徑之電子郵件影本（原審卷2第109頁）為證，並有上訴人提出被上訴人於103年12月16日提交之服務完成確認單影本（原審卷1第325頁）可稽，復為上訴人自認（原審卷1第272頁），堪予信實。㈢按工作說明書第1.1.8.3條「Defect Severity Level（瑕疵嚴
重性層次）」約定：「1-Critical（層次1：重度）」為「Cr-itical and high severity defects include defects thatprevent the system from going live and there are no a-cceptable workaround.（重大之高度嚴重性瑕疵，包括致使系統無法運作，且無可接受之暫行解決方法。）」，且「HTCshall confirm and inform IBM in writing each defect s-everity level assigned based on the above "Defect Sev-erity Level" table.（上訴人應以書面確認及通知被上訴人依前項「瑕疵嚴重性層次」表指定之各瑕疵嚴重性層次）」（原審卷1第45頁反面；原審卷4第234、235頁）。上訴人未抗辯曾就收受編號4.10交付項目後，以書面確認及通知被上訴人存在層次1瑕疵，堪認並無之㈠所示a之1情形。㈣依之㈠，編號4.5「單一客戶視圖、整合與架構」下之細項「整
合測試報告」於103年7月26日完成；依之㈠，編號4.8「單一客戶視圖」下之細項「快速轉換計劃」於103年9月24日完成，及依之㈠，編號4.9「單一客戶視圖」下之細項「資料模型」於103年9月24日完成，而進行各該工作項目須以「單一客戶視圖」已在被上訴人之系統上線為前提。再依論述，被上訴人進行「論壇」與包括「單一客戶視圖」在內之系統之整合測試後，於103年9月22日交付編號4.3「論壇整合測試報告」；被上訴人提出104年1月15日第46週會上之系爭專案進度簡報影本第19、20頁之測試階段進度表及「Deploy Phase Pr-ogress（部署階段進度）」表分別記載「單一客戶視圖」於103年8月29日、103年9月16日活動結束（原審卷2第25、189頁正反面）；被上訴人主張：上訴人於104年5月12日於發給伊之電郵之附表第9項表示「論壇」於103年7月22日上線，「Soci-
al Profiling SCV（社群側寫之單一客戶視圖）」、「SocialResponding Unica（社群回應之Unica，即「IBM Campaign」授權程式商品）均於103年9月16日上線等語，有上訴人提出該電郵影本（原審卷1第361至363頁）可憑。此外，依之㈤，論壇及單一客戶視圖系統至遲於103年10月間已在上訴人之商業用途作業環境中執行。據上，堪認被上訴人交付之編號4.10工作項目，已符合之㈠所示a之2至5，及b條件，則依之㈠約定，視為上訴人已接受。
㈤上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，前項服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用前開之㈣理由，此抗辯為不可採。㈥綜上事證，堪認被上訴人主張其已依約完成編號4.10交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號4.11交付項目之爭點，得心證
之理由如下：㈠工作說明書第1.5.2條載明編號4.11係「測試」階段下之「單一
客戶視圖」下之細項「Information Service source code（資訊服務原始碼）」，類型為「Application (with source
code)【應用程式（含原始碼）】」（原審卷1第64頁反面；原審卷4第269頁）。兩造約定完成標準依之㈠所示工作說明書第1.6節及其下第1條決之。
㈡被上訴人主張：伊於103年9月16日交付編號4.11應用程式（含
原始碼）等語，有上訴人提出被上訴人於103年12月16日提交之服務完成確認單影本（原審卷1第326頁）可稽，復為上訴人自認（原審卷1第272頁），堪予信實。依工作說明書第1.1.8.3條約定（見之㈢），上訴人未抗辯其收受編號4.11交付項目後，曾以書面確認及通知被上訴人存在層次1瑕疵，堪認並無之㈠所示a之1情形。再引用之㈣理由，堪認已符合之㈠所示a之2至5及b條件。則依之㈠約定，即視為編號4.11「應用程式」已為上訴人接受。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號4.11交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號4.6交付項目之爭點，得心證之
理由如下：㈠工作說明書第1.5.2條載明編號4.6係「測試」階段下之「Int-e
gration & Architecture（整合與架構）」下之細項「Cast I
ron deployable project files（Cast Iron可部署專案檔）」，類型為「Application (with source code)【應用程式（含原始碼）】」（原審卷1第64頁反面；原審卷4第269頁）。
兩造約定完成標準依之㈠所示工作說明書第1.6節及其下第1條決之。
㈡被上訴人主張：伊於103年10月17日交付編號4.6工作項目，於1
03年10月23日提交服務完成確認單，經上訴人之「IT Leade-r」王文泰等人簽認等語，有上訴人提出之服務完成確認單影本（原審卷1第333頁）為證，並為上訴人自認（原審卷1第272頁），堪予信實。依工作說明書第1.1.8.3條約定（見之㈢），上訴人未抗辯其於收受編號4.11交付項目後，曾以書面確認及通知被上訴人存在層次1瑕疵，堪認並無之㈠所示a之1情形。
㈢系爭工作說明書第1.1.4條「整合與架構」約定：「In this
Project, several nodes over the different clouds areinvolved to integrate using IBM Cast Iron, which wasobtained by HTC in CRM project. There are several cha-llenges for the intercloud integration, and Cast Iron
is applied to solve these challenges: 1. Cloud to Clo-
ud message transformation: The Integration Appliancecombines data integration, transformation, routing, m-onitoring, and management capabilities in a single pr-oduct. During run time, the Cast Iron shares data andprocessing among databases, enterprise applications,legacy systems, and business applications. According
to the message specifications defined by integrated n-odes as well as the business requirements defined by
IBM delivery team, IBM designer designs the message transformation flow.（本專案包含數個位於不同雲端之節點，此等節點必須使用IBM Cast Iron予以整合，LBM Cast Iron係由上訴人於CRM專案中取得。雲端間之整合有若干難題尚未克服，Cast Iron可用於解決該等難題：⒈雲端對雲端訊息轉換：
此「整合軟體驅動裝置」將資料整合、轉換、遞送、監視及管理等功能結合在單一產品中。在執行期間，Cast Iron會在資料庫、企業應用程式、舊式系統及商業應用程式之間共用資料與處理程序。被上訴人設計人員係依整合節點所確認之訊息規格及被上訴人專案小組所確認之業務需求，設計訊息轉換流程。」（原審卷1第42頁反面；原審卷4第229頁）。查依論述，被上訴人於103年12月13日完成編號4.1「社群行銷」下之「各語言之分析模型（模型1與模型2）」交付項目；依論述，上訴人之「論壇」與4個應用系統互動，被上訴人已於103年9月30日完成編號4.3「論壇整合測試報告」交付項目及於103年7月22日完成編號4.4「論壇效能測試報告」交付項目；依論述，被上訴人於103年7月26日完成編號4.5「單一客戶視圖、整合與架構」下之細項「整合測試報告」交付項目；依論述，被上訴人於103年9月24日完成「整合與架構」下之編號4.12「快速轉換計劃」交付項目、於103年8月26日完成編號4.13「支援問題單與日誌摘要」交付項目、於103年12月3日完成編號4.14「電話客服中心關鍵使用者操作手冊修改」交付項目；依論述，被上訴人於103年7月26日完成「整體系統整合測試報告」交付項目，及依之㈤，論壇及單一客戶視圖系統至遲於103年10月間已在上訴人之商業用途作業環境中執行。C
ast Iron功能既係整合系爭專案所建置之各系統間之雲端對雲端訊息轉換，是各系統之單元及整體整合測試必須利用Cast Iron始能進行，被上訴人再根據測試結果完成上開各交付項目，自得推定被上訴人於103年10月17日交付編號4.6【應用程式（含原始碼）】時已具備之㈠所示a之2至5條件，則依之㈠約定，視為上訴人已接受。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號4.6交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號5.1交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.1係「Deploy, Post Live S-u
pport, Reporting（部署、使用後支援、報告）」階段下之「社群行銷」下之細項「 Pilot Test Plan for Social Res-ponding Campaign（執行「社群回應」行銷活動小規模試驗測試計劃）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡被上訴人主張：伊於103年10月8日以電郵交付「Unica UAT（即
User Acceptance Test，使用者驗收測試，見原審卷1第45頁反面；原審卷4第234頁）Cases」文件電子檔等語，業據提出電郵影本（原審卷2第83、84頁）為證。依工作說明書第1.3.2.1條，「社群回應」係使用「IBM Campaign」授權程式商品（原審卷1第49頁反面；原審卷4第241頁），此商品別稱「Unica」，為兩造不爭執之事實，是上開文件係使用「Unic-a」執行「社群回應」使用者驗收測試之案例。而依工作說明書第
1.1.8.2條關於「使用者驗收測試」準則約定「開始測試準則」為：「•System/Performance testing of the candi-datecode has been completed and signed off.• No sev-erity
1 defects exist.•Acceptance test environment is in pla
ce and operational.•Acceptance test plan for t-he effo
rt is complete and ready to execute.（⒈候選程式碼之系統/效能測試已完成，且業經簽字認可。⒉無嚴重性1之瑕疵。⒊驗收測試環境已經備妥，並可運作。⒋成果之驗收測試計劃已完成，且已準備開始執行。）」，「結束測試準則」為：「•A
ll acceptance tests have been completedsuccessfully.• Non-critical, open defects have beendocumented in the test tracking database with the app-ropriate resolution plan.•All documentation relating t
o test execution and approval has been assembled and a
ll test results have been filed in accordance with e-stablished procedures.•A final acceptance test report h
as been completed for all test focus areas and sign-
off by the test team has been obtained.（⒈一切驗收測試均已順利完成。⒉在測試追蹤的資料庫中，所有問題皆需載明適當的解決方案，沒有重大的瑕疵。⒊ 一切有關測試之執行與核准之說明文件均已彙整，且一切測試結果已依既定程序歸檔備查。⒋一切測試焦點區域之最後驗收測試報告均已完成，且業經測試小組簽字。）」（原審卷1第45頁反面；原審卷4第234頁），是被上訴人完成編號5.1交付項目，才能開始「使用者驗收測試」。又被上訴人主張：上訴人於104年5月12日所發電郵附表清單第9點表明社群回應「Unica」於103年9月16日執行完畢（參見工程說明書第1.7條「Estimated Schedu-le（預估排程）」約定：「The Services in this SOW areestimated to be performed in a period of up to 6 mont-
hs from the Project kick-off date which agreed by bothparties.（本工作說明書中之「服務」預計於兩造合意之專案啟動日起算6個月內執行完畢）」等語，提出電郵為證（原審卷1第361頁），亦可推論被上訴人早已完成「社群回應」之「使用者驗收測試」。則上訴人既未提出證據證明其於收受編號5.1文件後5個工作日内（即103年10月16日前），曾以書面提出修訂要求，依上開約定，於103年10月17日視為被上訴人完成編號5.1交付項目。
㈢上訴人抗辯：被上訴人應交付編號5.1文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.1交付項目之格式為「Power Point or Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號
5.1文件電子檔儲存至上訴人之「Redmine」資料庫等語，為上訴人所不爭執，此部分抗辯自不足採信。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提出編號5.1服務完成確認單，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.1交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.2、5.4交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.2、5.4均係「部署、使用後支
援、報告」階段下之「社群行銷」下之細項「Testing res-ul
t summary reports（IBM Campaign and SMMS）【測試結果摘要報告(IBM Campaign 及社群媒體管理系統）】」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡按工作說明書第1.1.1.3條「社群媒體管理系統」約定：「So-c
ial Media Management System will be customized by IB-M. The scope of SMMS includes 3 categories:(ⅰ) Social Responding:1.SMMS will be integrated with IBM Campaig-n. IBM campaign would send the to-be responded posts
and articles to the social responding platform whereassigned community managers can respond and escalate
the case to CRM for call agents to follow up. 2.For t-
he 5 social media (Facebook, Twitter, Sina Weibo, Goo-gle+, and YouTube) with integration API supported, cr-eate Unified Ul where community manager can respond to
the author, including replying the comment and sendin
g private messages. For the social media without integr-ation API provided, the agent will respond in the soc-ial channel page. In either case the status and users' responses will be tracked. 3.Create the flexibility
to respond social message by multi-agent login with diff-erent social accounts. 4.Provide the capability to
re-ply multiple messages at one batch for same questi
ons.
5. Provide the capability to follow up on replied pos-tings or messages by url link. 6.Pass manual respondi-
ng status back to IBM Campaign for Social RespondingManagement Report. 7.Provide the capability to performcase escalation or case reassigning to other members/teams.…(ⅱ) Content Management:1.Provide the capabil-
ity to upload and manage media contents for social re-sponding and publishing, including text, images and v-ideo clips (uploaded files with the limitation of 500G
for storing contents). 2.Content could be stored by c-ategory (Concept, Hot words, Sentiment) 3.Content upl-oad/download authorization by user role. Upload/downl-
oad record will be kept. (ⅲ) Owned channel Publishing:1.Provide the capability to publish social contents
in owned social media pages (Facebook, Twitter, SinaWeibo, Google+, and YouTube). 2.Provide the capability
to assign a page or group of pages to a specific pers-on or team to manage, publish to and moderate. 3.Incl-ude permissions and approval workflow functionalities
as a part of the publishing capability. 4.Develop sch-eduling abilities in Calendar view for posting manage-ment. 5.Under the condition that the API is available
from Facebook, Twitter, Youtube, Sina Weibo and Googl
e Plus. Display a performance report (KPI customized re-port) for the published contents at the HTC owned Facebook, Twitter, Youtube, Sina Weibo and Google Plus pa-ges. 6.Display a summary report (customized report)
on performance tracking (tracked by SiteCatalyst) of t
he HTClinks posted on Facebook, Twitter, Youtube, SinaW-eibo and Google Plus. 7.Under the condition that th
e
API is available from Facebook. The SMMS platform wou-
ld provide the function to publish contents onto HTC'sowned Facebook page, targeting audiences by gender, g-eographic location, age, language, marital status, ho-bbies, and educational level.（社群媒體管理系統將由被上訴人予以客製化，其範圍包括3個種類：⒈社群回應：⑴社群媒體管理系統將與IBM Campaign整合。IBM Campaign會將待回應貼文與文章傳送至社群回應平台，在此平台中，指定社群管理者可回應案例，並將其呈報至CRM，以供呼叫客服人員執行後續作業。⑵針對内含獲得支援之整合API之5個社群媒體（Facebook、Twitter、新浪微博、Google+及YouTube)，建立統一使用者介面，供社群管理者用以回應作者，包括回覆評論及傳送私人訊息。針對未提供整合API之社群媒體，前揭客服人員將於社群頻道網頁上回應。不論係為何種情形，均會追蹤狀態及使用者之回應。⑶藉由利用不同社群帳戶進行多重客服人員登入，建立回應社群訊息之彈性作法。⑷針對相同問題，提供於同一批次回覆多重訊息之功能。⑸依照URL鏈結，提供對已回覆之貼文或訊息採取後續動作之功能。⑹將手動回應狀態回傳至IBM Campaign供社群回應管理報告使用。⑺提供執行案例呈報或將案例重新指派予其他成員/團隊之功能。⒉内容管理：⑴提供上傳及管理社群回應與公佈媒體內容之功能，包括文字、影像及視訊短片等内容（上傳檔案之儲存內容以500 G為上限）。⑵儲存內容時，可依種類（概念、熱門字詞、觀感）區分。⑶依使用者角色賦予內容上傳/下載授權。上傳/下載記錄將予以保存。⒊自有頻道之發佈：⑴提供在自有社群媒體網頁（Facebook、Twitter、新浪微博、Google+及YouTub-e）中發佈社群內容之功能。⑵提供將單一網頁或一組網頁指定予特定人員或團隊，由其負責管理、發佈及控管之功能。⑶在發佈功能中納入權限與核准工作流程功能。⑷在「行事曆」視圖中開發貼文管理排程能力。⑸在由Facebook、Twitter、Youtube、新浪微博及Google Plus提供API之前提下，在上訴人所擁有之Facebook、Twitter、Youtube、新浪微博及Googl-
e Plus網頁上，顯示已發佈內容之效能報告（KPI客製化報告）。⑹顯示上訴人在Facebook、Twitter、Youtube、新浪微博及Google Plus上所張貼上訴人鏈結之效能追蹤摘要報告（客製化報告），該追蹤作業由SiteCatalyst執行。⑺在由F-acebook提供API之前提下，社群媒體管理系統平台可提供將內容發佈至上訴人所擁有Facebook網頁之功能，藉以依照性別、地理位置、年齡、語言、婚姻狀態、嗜好及教育程度，尋找目標受眾。」（原審卷1第36頁反面、第37頁；原審卷4第218、219頁），是編號5.2、5.4係指被上訴人客製之「社群媒體管理系統」與IBM Campaign整合執行上開「社群回應」作業之測試結果摘要報告。
㈢被上訴人主張：伊之專案人員Eric Wang於103年9月25日先以電
郵寄送編號5.2、5.4文件電子檔予上訴人之專案人員Elaine及黃俊旗，同日再以電郵寄送更新版予Elaine及黃俊旗，並將電子檔儲存於上訴人之「Redmine」資料庫中，嗣上訴人之專案人員張凡齊於104年1月14日發電郵予伊之專案人員Eric Wa-ng及Robin Chen（陳林裕）表示：「I've verified and clo-se
all the issues on Redmine, except this one below,it's the "Datetime" issue on Publishing List View. Pl-ease have a look.（我已經驗證並結束所有記載在Redmine上的問題，除了以下這個公佈清單視圖上「日時」問題，請查看一下）」，陳林裕於104年1月15日以電郵回覆張凡齊：「It'sfixed, please verify again and close it if no other p-roblem.（該問題已解決，請再次確認，如無問題則結案）」，張凡齊於同日發電郵予兩造專案團隊表示：「Hi al-l, Tha
nks to Robin, all resolved issues are closed no-w!（謝謝林裕，現在所有問題皆已解決結案）」等語，提出上訴人不爭執真正之電郵影本（原審卷2第46至48、85、203頁）為證。
且依之㈡所示工作說明書第1.1.8.2條所定「使用者驗收測試」準則，須於應用之程式碼完成系統、效能測試，驗收測試環境已經備妥並可運作（即已部署在上訴人商業用途作業環境），始能開始執行「使用者驗收測試」，再於完成驗收測試、彙整有關測試之執行與核准說明文件、測試結果已歸檔備查，且最後驗收測試報告已完成始告結束，被上訴人既於103年10月8日交付「社群回應」之「使用者驗收測試」文件，上訴人亦於104年5月12日所發之電郵自承「社群回應」已於103年9月16日執行完畢，足資佐證被上訴人確已完成編號5.2、5.4交付項目。則上訴人如未提出證據證明其於收受編號5.2、5.4文件後5個工作日内（即103年10月2日前），曾以書面提出修訂要求，依上開約定，於103年10月3日視為被上訴人完成編號5.2、5.4交付項目。
㈣張凡齊於104年1月14日請求被上訴人處理編號5.2、5.4文件中
之「日時」問題，及上訴人陳稱：103年10月9日週會紀錄記載「For SMMS, 3 issues left to be resolved before UAT（社群媒體管理系統進行「使用者驗收測試」前，仍有3個問題等待解決）」，及103年10月26日週會紀錄記載「Fixed all S
MMS enhancement function, new bugs found during re- t
est are in progress（解決所有社群媒體管理系統優化功能，重新測試過程中發現的新漏洞仍在處理）」等語，固為被上訴人所不爭執，然各該問題均係在工作說明書第1.6節下之第2條所示提出修訂要求期限以後提出，亦非由上訴人之專案經理提出，且依上訴人提出103年12月4日專案會議紀錄記載「Theprogress of SMMS bug fix goes well, will review the ne
w items with HTC team on 12/5 afternoon.（社群媒體管理系統程式偵錯進展順利，將於12月5日下午與上訴人團隊一起檢視新的項目）」（原審卷2第324頁；本院卷1第535頁）及103年12月25日專案會議紀錄記載「All SMMS PCR ite-ms are completed; the last in-progress bug is new Cam-paign Trending which needs to be tested.」（原審卷2第325頁），可見上訴人自103年10月9日起請求被上訴人處理有關社群媒體管理系統之問題，均屬於使用後支援部分，不影響依約視為被上訴人於103年10月3日完成編號5.2、5.4交付項目之事實。
㈤上訴人抗辯：被上訴人應交付編號5.2、5.4文件之定稿版本予
伊之專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.2、
5.4交付項目之格式為「Power Point or Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號5.2、5.4文件電子檔儲存至上訴人之「Redmi-ne」資料庫等語，為上訴人所不爭執，此部分抗辯自不足採信。㈥上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提出編號5.2、5.4服務完成確認單，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈦綜上事證，堪認被上訴人主張其已依約完成編號5.2、5.4交付
項目乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.3交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.3係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「Go-Live Plans (CDM)【上線計畫（客戶資料集區）】」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。㈡被上訴人主張：伊之專案人員Eric Wang於104年1月14日發電郵
予上訴人之專案人員陳冠文表示：「As you know, the CDM D
B replicated data to SCV. The attached file describes
the details of the replication setting. Please have alook.（如同您所知，客戶資料集區資料庫的資料會複製至單一客戶視圖資料庫。附件檔案敘述該複製設定的細節，請看一下）」，是伊於103年9月16日一併交付編號4.8（見）及編號
5.3文件，嗣103年12月16日提交之同一服務完成確認單載明編號5.3文件電子檔名「HTC_CCT_DP_SCV_Go Live Readiness Checklist_V2_00000000」等語，業據提出服務完成確認單、電郵及附檔等影本（原審卷1第329頁；原審卷2第87至108頁；本院卷3第15至31頁）為證，再依之㈣，上訴人自承單一客戶視圖於103年9月16日上線，堪信被上訴人之主張真正。上訴人既未提出證據證明其於收受編號5.3文件後5個工作日内（即103年9月23日前），曾以書面提出修訂要求，依上開約定，於103年9月24日視為被上訴人完成編號5.3交付項目，並作為系爭專案繼續執行之基礎。上訴人雖抗辯：工作說明書第1.1.1.2條「社群側寫」下之「Task 2: Build Up Customer Data M-art（作業2：建置「客戶資料集區」）」約定：「CustomerData Mart (CDM) is an integrated data repository formarketing purpose. CDM will consolidate data from fol-lowing source systems will gather various data of ind-ividual level from these accesses as follows: 1.Social
profile data (SCV). 2.Digital Insight data (Provided
by HTC from SiteCatalyst). 3.Social listening data (SMA). 4.Forum data (HTC Community). 5.CRM data (SmartClient/E2E or SugarCRM). 6.HTC China e-commerce site.
7.HTC Elevate. 8.SMMS 9.IBM Campaign（「客戶資料集區」為一種以行銷為目的之整合型資料儲藏庫，可合併自下列來源系統之資料，並從下列存取作業蒐集個別層次之各種資料：⒈社群資訊資料（單一客戶視圖）⒉數位洞察資料（由上訴人從SiteCatalyst提供）⒊社群聆聽資料（社群媒體分析程式) ⒋討論區資料（上訴人之論壇）⒌CRM資料（智慧型用戶端/E2E或SugarCRM) ⒍上訴人在中國之電子商務網站⒎HTC Elevate⒏社群媒體管理系統⒐IBM Campaign）」，是社群資訊資料僅為客戶資料集區之資料來源之一，客戶資料集區收納資料遠超過社群資訊資料，故編號4.8文件不能涵蓋編號5.3「客戶資料集區」上線計畫云云，惟查，編號5.3係「社群行銷」系統中之「社群側寫」單元關於建置「客戶資料集區」之作業範圍，而該「客戶資料集區」屬於執行工作說明書第1.1.3.2條所指「單一客戶視圖」之客戶資料同步化機制之範疇（見之㈤），是被上訴人主張編號4.8包括編號5.3之計劃在內，並非無據，上訴人所辯洵非可採。
㈢上訴人抗辯：被上訴人應交付編號5.3文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.3交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人主張：伊將編號5.3文件電子檔儲存至「team room」以為交付等語，有之㈡服務完成確認單影本為證，上訴人之抗辯自不足採信。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.3交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號5.5交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.5係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「Go-Live Plans (IBMCampaign and SMMS)【上線計畫（IBM Campaign及社群媒體管理系統）】」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡被上訴人主張：伊於103年9月16日交付編號5.5關於IBM Camp-a
ign之文件，嗣伊於103年12月16日提交之服務完成確認單所載文件電子檔名「HTC_CCT_DP_SCV_Go Live Readiness Checklist_V2_00000000」包含該文件內容等語，業據提出服務完成確認單及該電子檔列印本等影本（原審卷1第329頁；本院卷3第15至31頁）為證，再依之㈣，上訴人自承社群回應之Uni-ca（即IBM Campaign）於103年9月16日上線，堪信被上訴人之主張真正。上訴人既未提出證據證明其於收受編號5.5關於IBM Campaign文件後5個工作日内（即103年9月23日前），曾以書面提出修訂要求，依上開約定，於103年9月24日視為被上訴人完成編號5.5此部分交付項目，並作為系爭專案繼續執行之基礎。
㈢被上訴人主張：伊將編號5.5關於社群媒體管理系統上線計畫儲
存在上訴人之「Redmine」資料庫中，嗣於103年12月18日第43週會、103年12月25日第44週會、104年1月18日第45週會，及104年1月15日第46週會提出簡報（內載「Model 1 Activat-ion
Checklist」、「Model 2 Activation Checklist」，即為社群媒體分析程式及社群媒體管理系統之「go-live readi-ness
checklist（上線就緒核對清單）」，伊之專案經理李珉玲於104年1月19日發電郵予兩造專案人員，檢附兩造專案經理室於104年1月間之會議紀錄，記載就「社群行銷」之總結包括「Th
e SMA & SMMS Go Live readiness check were all com-pleted, and both SMA & SMMS systems were in the produ-ctio
n environment already on Jan. 23, 2015.」，是伊於103年12月18日以前已交付上開文件等語，業據提出電子檔列印本、簡報等影本（本院卷3第33至85頁；原審卷2第17至26、183頁；原審卷1第223頁）為證。再依之㈡所示「使用者驗收測試準則」，「社群媒體管理系統」須先上線運作，始能進行「使用者驗收測試」，而依論述，「社群媒體管理系統」已經「使用者驗收測試」，被上訴人於103年9月25日交付編號5.
2、5.4「測試結果摘要報告」，足可推定被上訴人於進行「使用者驗收測試」前已交付編號5.5文件，是被上訴人之主張非不可信。上訴人雖抗辯：伊之專案人員張庭瑋收到李珉玲之電郵，即於104年1月19日以電郵回覆：「You meeting not-es d
o not reflect the current project status and thecomment from last PMO meeting. 1.IBM and HTC didn't do
any "go-live readiness check”for SMA and SMMS system
in the past few weeks. Not sure why you said "The SMA& SMMS Go Live readiness check were all complete-d.”（您的會議紀錄並未反映目前專案狀態與專案辦公室先前會議上的意見：⑴過去幾週以來，兩造並未針對社群媒體分析程式及社群媒體管理系統進行任何上線整備確認，因此無法理解您所謂「社群媒體分析程式及社群媒體管理系統上線整備確認均已完成」所指為何）」等語，並提出電郵影本（原審卷2第164、
160、161頁）為證，但張庭瑋之說法與前開週會簡報內容不符，且被上訴人陳稱：李珉玲於當日以電郵回覆張庭瑋，並檢附104年1月15日週會簡報，表示：「We have beendoing Go Live readiness for SMA and SMMS since 2014/11/27 which was the dat CRM in tegration completed UAT.
Pls refer to everyweek's PMO chart.（我們從103年11月27日完成CRM整合之使用者測試以來，就一直在為社群媒體分析程式及社群媒體管理系統之上線作準備，請參考專案辦公室每週專案會議紀錄表）」等語，提出電郵影本（原審卷2第220頁）為憑，上訴人則未抗辯張庭瑋此後有提出異議，是張庭瑋之電郵不足以否定兩造業已確認社群媒體管理系統上線整備之事實。從而，被上訴人主張以103年12月18日為交付編號5.5文件日期，應可憑採。上訴人既未提出證據證明其於收受編號5.5關於社群媒體管理系統上線計畫後5個工作日内（即103年12月25日前），曾以書面提出修訂要求，依上開約定，於103年12月26日視為被上訴人完成編號5.5此部分交付項目，並作為系爭專案繼續執行之基礎。
㈣上訴人抗辯：被上訴人應交付編號5.5文件之定稿版本予伊之專
案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.5交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人將編號5.5文件電子檔儲存至上訴人之「Redmine」資料庫，合於兩造約定，上訴人之抗辯不足採信。
㈤上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈥綜上事證，堪認被上訴人主張其已依約完成編號5.5交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.6交付項目之爭點，得心證之
理由如下：㈠工作說明書第1.5.2條載明編號5.6係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「ETL Job source code（ETL工作原始碼）」，格式為「DataStage」，類型為「應用程式（含原始碼）」（原審卷1第65頁；原審卷4第270頁）。
兩造約定完成標準依之㈠所示工作說明書第1.6節及其下第1條決之。
㈡被上訴人主張：編號5.6與編號4.10相同，伊於103年9月16日儲
存於「team room」，並於103年12月16日提交之服務完成確認單記載路徑位址為「HTC_ETC—1219」（原審卷4第491頁）等語，業據提出服務完成確認單影本，及被上訴人專案人員Chiwen Chang於103年12月26日回覆上訴人之專案人員陳冠文所詢關於該原始碼儲存位置及輸出路徑之電郵影本（原審卷1第325頁；原審卷2第109至110頁）為證。又引用之㈢、㈣論述，堪認被上訴人交付之編號5.6應用程式（含原始碼）已具備之㈠所示a、b條件，則依工作說明書第1.6節及其下第1條約定，視為上訴人已接受。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號5.6交付項目乙
節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.7交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.7係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「SMMS source code（社群媒體管理系統原始碼）」，格式為「a portable medi-a（可攜式媒體）」，類型為「原始碼」（原審卷1第65頁；原審卷4第270頁）。兩造約定完成標準依之㈠所示工作說明書第
1.6節及其下第1條決之。㈡被上訴人主張：伊於104年1月6日交付編號5.7原始碼，並於
104年1月13日提交之服務完成確認單記載儲存位置與連結等語，有上訴人提出之服務完成確認單影本（原審卷1第327頁）可稽，並為上訴人自認（原審卷1第272頁），堪予信實。
㈢查103年12月4日專案會議紀錄就「社群行銷」結論記載：「R-e
test BR data after BR's feedback that their fix is r-e
ady. Still failed to timely retrieve Sina & Facebook data; Google+ was 7hrs delayed to retrieve data; Inst-agram is under testing. BR request to have the actual usage amount of Sina data. IBM team will estimate it
and provide. Both HTC and IBM will work together to c-ontinuously talk to BR for fixing the data readinessissue asap.（在BR回饋修正作業已就緒後，重新測試BR數據。目前仍無法及時提取新浪與Facebook的數據；Google+延遲7小時後才取得數據，Instagram則在測試中，BR要求取得新浪數據的實際使用量，被上訴人團隊會將估算並提供。兩造將會合作持續跟BR進行溝通，以盡快解決數據就緒問題。）」，後附「Follow-up items（待辦事項）」表就「BR data read-in
ess confirmation（BR資料就緒確認）」事項記載由上訴人之專案人員張庭瑋、Debby Chen負責(原審卷2第324頁。見被上訴人提出之中譯文，本院卷1第535、537頁）。嗣上訴人之專案人員張庭瑋於103年12月5日發電郵予被上訴人之專案經理李珉玲表示：「BoardReader Facebook post missing issue is
still open. Although IBM reported 90% coverage onThursday by retesting 10 posts, at the same day, we f-ound 100% data lost. According to the latest PMR comm-unication, SMA and BoardRead still didn't have conclu-sion of the fix plan.【Facebook貼文遺失問題仍未解決：
儘管被上訴人於本週四（即103年12月4日）回報經過重新測試10則貼文已涵蓋90%等語，但根據上訴人同天測試結果發現資料遺失為100%。根據最後PMR Communication，社群媒體分析程式與Broadreader仍未能完成修補】」（原審卷2第160、164頁）。李珉玲於同日以電郵回覆：「According to our unde-rstanding, 2 cases were tested last Thursday by HTC.
I am not sure when the test were done, but both case-s's rootcause were found. One case was feedback to BR d
ue to language setting, and BR would it asap. Pls refe
r to the e-mail Clare sent you and project team arou-n
d noon today for the other case in Green as follows.（據了解，上訴人上周四測試了2個案例，我不確定何時完成測試，但已找出2個案例之根本原因，一個是由於語言設定問題且已回報予BoardReader，而BoardReader將會盡快處理。另一狀況請參考Clare在今天中午寄給您與專案團隊之電子郵件，如下綠色文字。）」，而所引用之「綠色文字」為：「T-he reason for both the documents not being seen in SMA is
the delay between a documented being inserted andsearchable from the index. Based on Boardreaders expl-anation there is a delay, between a document being In-serted (which SMA is looking for in an ongoing job) a-
nd the time it can be searched for. When the iteratio-
ns were executed both documents were already insertedinto the index, but not searchable at that time. Addi-tionally Document#1, which had been inserted on Janu-
ary 8th, might have been searchable at an even laterpoint due to latency because of a fix being applied f-
or HTC at that exact time. Boardreader is still confi-rming that internally.【在社群媒體分析程式中沒有看到貼文的原因是插入貼文後到可以從索引中搜尋之間有時間落差。根據BoardReader的說明，在插入貼文（社群媒體分析程式正在運作時要搜尋的貼文）和該貼文可以被搜尋到的時間之間存在時間落差。當重覆執行時，雖然兩則貼文皆已插入到索引中，但尚非當時可搜尋到的貼文。此外，1月8日插入的文件1可能由於時間落差而在稍後的時間内可以被搜尋到，因為在那時有為上訴人做修正。Boardreader仍在内部確認中。】」（原審卷2第220頁正反面）。其後於103年12月25日專案會議紀錄記載：「For the SMA Go Live readiness check, only oneissue (BR data readiness) remains. Both HTC and I-BM would work together to follow up the issue statuswith BR; Currently BR is working on exposing daily re-porting of content collection counts to HTC. Delay intimely data retrieve will be improved wait until theprocess is fully implemented. Due to no commercial se-rvice agreement between BR and FB, no guarantee of the
data coverage for FB is given. IBM team proposes to f-ocus on the data on HTC FB fan page instead of uncoun-table personal FB pages. IBM Eric will confirm the fe-asibility of this idea and have farther discussion wi-th HTC Kurt.（關於社群媒體分析程式上線準備確認項目，僅剩BR問題仍存在。兩造應共同追蹤BR此議題狀態。目前BR正在努力完成内容蒐集數向上訴人每日通報，即時資料提取的遲延情形將在此作業完全實施後改善，鑒於BR與Facebook間並無商業服務條款，無法保證Facebook資料涵蓋範圍，被上訴人建議重點放在上訴人之Facebook官方粉絲頁而非難以計數的個人F-acebook專頁，被上訴人之人員Eric會再跟上訴人溝通此構想的可行性。）」，後附「待辦事項」表就「Hold a meeting
to clarify BR data readiness status with BR（與BR召開會議以釐清BR數據就緒狀態）」亦係由上訴人之專案人員張庭瑋、Debby Chen負責（原審卷2第325頁）。上訴人復不爭執B-oardReader係其購買之授權程式商品，並非系爭專案約定由被上訴人客製化之應用程式，且上訴人就上述問題係尋求授權商解決，顯與被上訴人交付之編號5.7「原始碼」無關，則依之㈢論述，因BoardReader使用上之限制所生上述問題，不得認為係被上訴人交付之編號5.7「原始碼」存在工作證明書第1.1.8.3條所指層次1瑕疵。上訴人又未抗辯曾就編號5.7交付項目，以書面確認及通知被上訴人存在層次1瑕疵，堪認並無之㈠所示a之1情形。又依之㈢，於104年1月兩造之專案經理室會議中確認社群媒體管理系統上線整備就緒，堪認符合之㈠所示a之2至5條件，則依工作說明書第1.6節及其下第1條約定，視為上訴人已接受。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤上訴人抗辯：被上訴人未先依工作說明書第1.3.5.7條及附錄F
，提出執行安全檢測之報告，即交付編號5.7程式碼，違反約定交付步驟云云。然查，工作說明書第1.3.5.7條係「測試」階段下之「系統整體整合測試」規範（見原審卷1第60頁反面；原審卷4第262頁），與編號5.7交付項目無涉。且工作說明書第1.3.5.7條約定：「IBM will perform the following activities and detail tasks: Security Test…Perform s-ecurity test as Appendix F.（被上訴人將執行下列活動與詳細作業：安全測試…依照附錄F進行安全測試）」，而附錄F係規範「Security Test Items（安全測試項目）」（原審卷1第78頁正反面；原審卷4第296、297頁），其中無隻字片語表示被上訴人應交付「安全測試報告」，工作說明書第1.5.2條亦未將「安全測試報告」列入交付項目，是上訴人所辯委無可取。
㈥綜上事證，堪認被上訴人主張其已依約完成編號5.7交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號5.8交付項目之爭點，得心證之
理由如下：㈠工作說明書第1.5.2條載明編號5.8係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「IBM Campaign Train-
ing with Training Materials【IBM Campaign訓練（含訓練教材）】」計16小時（原審卷1第65頁；原審卷4第270頁），兩造約定執行方式依工作說明書第1.2.0條第3項，完成標準依工作說明書第1.6節下之第3條決之（見之㈡）。
㈡上訴人主張：伊於103年7月25日14:00至16:00、103年8月11日1
4:00至16:00、103年8月20日10:00至12:00、103年8月29日17:00至19:00、103年9月9日10:00至12:00、103年9月26日10:00至12:00，執行編號5.8教育訓練共計16小時，到場之上訴人專案人員張庭瑋等人均已簽認等語，業據提出上訴人不爭執真正之簽到單影本（原審卷2第111至116頁）為證，依上開約定，編號5.8教育訓練即視為全部完成。
㈢上訴人抗辯：被上訴人未交付訓練教材云云。然查，工作說明
書第1.2.0條第3項明定上訴人負責重製訓練教材，且IBM Cam-paign為授權程式商品，被上訴人主張其使用該商品之標準產品說明文件作為教育訓練教材乙節，為上訴人所不爭執，則依工作說明書第1.6節下之第3條約定，該教材不包含在修訂或驗收項目内，故上訴人所辯為不可採。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用前開之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.8交付項目乙
節屬實，上訴人所為抗辯則均不可採。關於被上訴人是否依約完成編號5.10交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.10係「部署、使用後支援、報
告」 階段下之「論壇」下之細項「System Operation Man-ual（系統操作手冊）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。㈡被上訴人主張：伊於103年9月18日交付編號5.10文件，嗣於
103年9月25日提交服務完成確認單，經上訴人之「Community
IT Leader」王文泰簽署等語，業據提出上訴人不爭執真正之服務完成確認單影本（原審卷2第76頁）為證，堪予信實。上訴人既未提出證據證明其於收受編號5.10文件後5個工作日内（即103年9月25日前），曾以書面提出修訂要求，依上開約定，於103年9月26日視為被上訴人完成編號5.10交付項目，並作為系爭專案繼續執行之基礎。㈢上訴人抗辯：被上訴人應交付編號5.10文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.10交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人將編號
5.10文件電子檔儲存至上訴人之「Team room」資料庫，有之㈡所示服務完成確認單可稽，合於兩造約定，上訴人之抗辯不足採信。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，之㈡所示服務完成確認單未經伊之專案經理劉冠廷簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.10交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號5.11交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.11係「部署、使用後支援、報
告」 階段下之「論壇」下之細項「Roll Out Plan（大規模部署計劃）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡被上訴人主張：伊於103年8月27日交付編號5.11文件，及提交
服務完成確認單，經上訴人之「Community IT Leader」王文泰及專案經理劉冠廷簽署等語，業據提出上訴人不爭執真正之服務完成確認單影本（原審卷4第507頁）為證，並為上訴人自認（原審卷1第272頁），堪予信實。上訴人既未提出證據證明其於收受編號5.11文件後5個工作日内（即103年9月3日前），曾以書面提出修訂要求，依上開約定，於103年9月4日視為被上訴人完成編號5.11交付項目，並作為系爭專案繼續執行之基礎。㈢上訴人抗辯：被上訴人應交付編號5.11文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.11交付項目之格式為「Power Point or Word」（原審卷1第64頁反面），為電子檔，非紙本文件。引用之㈤理由，被上訴人將編號
5.11文件電子檔儲存至上訴人之「Team room」資料庫，有之㈡所示服務完成確認單可稽，合於兩造約定，上訴人之抗辯不足採信。
㈣綜上事證，堪認被上訴人主張其已依約完成編號5.11交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.13交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.13係「部署、使用後支援、報
告」 階段下之「論壇」下之細項「HTC Community Platfo-rm
Customization Specification and coding（上訴人之論壇平台客製化規格與編碼）」，格式為「可攜式媒體」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡被上訴人主張：伊將編號5.13電子檔儲存於上訴人之作業環境
硬體設備，嗣被上訴人之論壇於103年7月22日上線使用等語，經上訴人自認「論壇」於103年7月22日對外開放使用（本院卷2第228頁）。又被上訴人提出上訴人不爭執真正之104年1月8日週會紀錄，記載兩造專案經理室結論為「We will go live
on Jan 16, 2015 with one month post live support. Wewill hold the last PMO meeting on Jan 15, 2015.（我們將於104年1月16日上線及開始上線後1個月技術支援。最後一次專案經理室會議將於104年1月15日召開）」（本院卷3第199至201頁），及被上訴人之專案經理李珉玲於104年1月19日寄予兩造專案團隊人員之電郵，表示「We finally moved all
the systems into production last Friday, Jan.16, 2015.
We will continue the one month support this week（我們終於在上星期五，104年1月16日將所有系統上線至正式作業環境，將從本週進行一個月之支援服務）」，於檢附之當月兩造專案經理室之會議紀錄亦記載「As of Jan. 16, 2015, all
the CCT systems were moved into production environmen-
t. IBM team have completed all the deliverables, andwill continue the one month support.」（原審卷1第223頁正反面）。此外，上訴人提出張庭瑋於104年1月19日發予李珉玲之電郵（見之㈢），雖爭執兩造尚未就社群媒體分析程式及社群媒體管理系統確認上線整備清單，但未爭執被上訴人未交付編號5.13文件（原審卷2第164頁），可資證明，堪認被上訴人至遲於103年7月22日交付編號5.13文件，則上訴人如未提出證據證明其於收受編號5.13文件後5個工作日内（即103年7月29日前），曾以書面提出修訂要求，依上開約定，於103年7月30日視為被上訴人完成編號5.13交付項目，並作為系爭專案繼續執行之基礎。㈢上訴人抗辯：被上訴人應交付編號5.13文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.13交付項目之格式為電子檔，非紙本文件。引用之㈤理由，被上訴人將編號5.13文件電子檔儲存至上訴人之資料庫，合於兩造約定，上訴人之抗辯不足採信。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交編號5.13之服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。
㈤上訴人之員工林家豐於103年10月22日發電郵予王文泰，副知劉
冠廷，表示「目前Community論壇目前無法提供服務…今天原預計更版，但在上程式前(18:30)，發現論壇首頁及討論區本文無法連至DB…目前懷疑CLUSTER有問題」，劉冠廷於當日發電郵予林家豐、王文泰，副知被上訴人之專案經理李珉玲及員工Ja
cky Lu、Jason Chen（陳俊全）等人，表示「This is secondtime that the community crashed in a short tim-e.（這是論壇在短時間内第2次當機）」。嗣陳俊全於同日發電郵予劉冠廷、王文泰及被上訴人之製造業事業群副總經理G-innieHsu等人，表示：「the issue is very probably onMySQL cluster. Please have DBA team support Jeff and
try recover the service back first, even we need to t-emporally disable cluste.（這個問題很可能在於MySQL叢集。請讓DBA團隊支援Jeff，即使需要暫時停用叢集，也必須設法先恢復服務）」。Ginnie Hsu亦於同日發電郵予劉冠廷、王文泰等人，表示：「Team is working on the problem and w
ill set it as first priolity to solve.（小組正在硏究此問題，且將會優先處理此問題）」（本院卷2第289至291、403至405頁）。當時已是103年7月22日「論壇」對外開放使用之後3個月，不影響編號5.13交付項目於103年7月30日完成之事實。
㈥綜上事證，堪認被上訴人主張其已依約完成編號5.13交付項目乙節屬實，上訴人所為抗辯則無可憑採。
關於被上訴人是否依約完成編號5.14交付項目之爭點，得心證
之理由如下：㈠工作說明書第1.5.2條載明編號5.14係「部署、使用後支援、報
告」 階段下之「論壇」下之細項「HTC Community Custom-iz
ed Platform Runtime（上訴人之論壇客製化平台執行時期）」，格式為「可攜式媒體」，類型為「應用程式（含原始碼）」（原審卷1第65頁；原審卷4第270頁），兩造約定完成標準依之㈠所示工作說明書第1.6節及其下第1條決之。
㈡被上訴人主張：伊將編號5.14應用程式部署在上訴人之作業環
境硬體設備，上訴人之論壇嗣於103年7月22日對外開放使用（即在上訴人之商業用途作業環境中執行）等語，引用之㈡之理由，堪認被上訴人確已交付編號5.14「應用程式（含原始碼）」，且至遲於103年7月22日達到工作說明書第1.6節下之第1條所示b完成標準，視為上訴人接受。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。
㈣按工作說明書第1.1節「Project Scope（專案範圍）」下之第1
.1.2條「論壇」約定：「In this stream IBM will provideservice in designing, developing, and deploying four
HTC communities in US, India, Taiwan and China in thr-
ee languages (English, traditional Chinese and simpli-fied Chinese). The shared community platform aims tocover user groups of general user and developers.【在本串流中，上訴人位於美國、印度、台灣及中國之四個論壇，將由被上訴人以三種語言（英文、繁體中文及簡體中文）提供設計、開發及部署之服務。共用論壇平臺之目標，期能涵蓋一般使用者與開發人員之使用者群組】（原審卷1第33頁反面、第37頁；原審卷4第212、219頁）；第1.3節「IBM Responsib-ilities（被上訴人義務）下之第1.3.3.2條「論壇」約定：「
IBM will perform the following activities and detail tasks:…On the basis of client's requirements, to des-ig
n the configuration specification of Discuz! to meet those requirements.…Design the customization program specification to fulfill those requirements could not be
configure in Discuz!.（被上訴人將執行下列活動與詳細作業：…依照客戶需求，設計Discuz!配置規格，以符合該等需求…設計客製化程式規格，以實現無法在Discuz!中配置之該等需求）」，其下另明定「Completion Criteria: When H-TC accepts the Deliverables in accordance to section 1.5.2 Design Phase of this SOW, this section will bedeemed completed.（完成標準：於上訴人依本工作說明書第1.5.2之規定就「設計階段」之「交付項目」予以接受時，本節即視為完成。）」（原審卷1第48、52頁；原審卷4第239、
245、246頁）。查上訴人自認Discu!授權程式商品係其原使用之商品，並非被上訴人推薦（本院卷2第334頁）。且上訴人對於被上訴人已依約完成工作說明書第1.5.2所示設計階段中之「Community - Business Design（論壇商業設計」、「Comm-unity - IT Implementation（論壇IT施行）」，即編號2.6至
2.12交付項目（原審卷1第63頁反面；原審卷4第267、268頁）均不爭執，依約視為被上訴人完成前揭應負責執行之活動與作業。準此，上訴人嗣後抗辯：後台英文介面有30%沒辦法用英文顯示，而是中文顯示等語，固提出上訴人於104年5月12日發予被上訴人之信函影本，主張：「Community is not provid-
ed as global template (per the project scope, Communi-
ty is to be delivered to cover 3 languages: simplifiedChinese, traditional Chinese and English).【所提供之論壇並非全球性範本（根據專案範圍，論壇要涵蓋三種語言：簡體中文、繁體中文及英文）】」，及檢附「What IBM has de-livered (which was not met the requirement)（被上訴人所交付項目不符需求）」清單，就「論壇」具體指摘「Discu-z, IBM suggested platform, is not fully capable of se-rving as a global template. 30% of backend does noth-ave English user interface.（被上訴人建議使用的Discuz平台不能完全作為全球性範本使用，30%的後端無英文使用者介面。）」（原審卷1第361頁正反面。參見被上訴人提出之中譯文，本院卷2第321、322頁），暨提出後台使用者畫面截圖影本（原審卷2第248、249頁）為證，然該後台使用者介面之語言顯示情形，屬於被上訴人執行前揭「論壇」設計階段之成果，依約既視為被上訴人已履行該階段義務，上訴人不得執此主張被上訴人未完成編號5.14交付項目。
㈤上訴人於本院抗辯：被上訴人未交付美國、中國及印度論壇，
且僅交付繁體中文版本；臺灣之論壇網站前端及後端使用者均無法使用英文介面操作，而係中英混雜，且繁體中文網頁不能選取轉換為英文頁面，致前端英文介面版本從未上線云云（本院卷2第478頁）。然查，上訴人原抗辯：「論壇」僅有之㈣所示104年5月12日信函所指後端英文使用者介面有30%未顯示英文的問題，並不是被上訴人沒有交付三種語言的操作介面等語（本院卷2第332、333頁），顯自認被上訴人已交付英文、繁體中文及簡體中文之論壇平台使用者介面，且前端使用者使用英文介面操作並無問題。又依工作說明書第1.1節（見之㈣），被上訴人係開發三種語言之介面，交付上訴人使用於上訴人位於美國、印度、臺灣及中國之論壇，並非由被上訴人為上訴人建置美國、印度、臺灣及中國論壇系統，況且被上訴人主張：上訴人於104年4月30日發行之103年年報，於第36頁載明：
「社群策略…去年起（指103年）我們在台灣大陸地區設立了HTC線上論壇，隨後亦將之推展至印度與美國等關鍵重要市場…去年一整年HTC的Facebook與Twitter的回應高達3億6仟9佰萬筆，較2013年成長了126%」等語，提出上訴人不爭執之年報影本（原審卷3第86頁）為證。上訴人亦自認其委託訴外廠商，於系爭契約成立前建置「美國論壇」（本院卷3第151、152頁)、於104年間建置「大陸論壇」（本院卷3第153、154頁)，自102年起至105年止則均無「印度論壇」上線紀錄等情(本院卷3第157至160頁）。是上訴人抗辯被上訴人依約應交付、卻未交付美國、中國及印度論壇云云，顯不足採。至於繁體中文網頁不能選取轉換為英文頁面，屬於被上訴人執行之㈣「論壇」設計階段之成果，依約既視為被上訴人已履行該階段義務，上訴人自不得執此主張被上訴人未完成編號5.14交付項目。
㈥綜上事證，堪認被上訴人主張其已依約完成編號5.14交付項目
乙節屬實，上訴人所為抗辯則無可憑採。關於被上訴人是否依約完成編號5.9交付項目之爭點，得心證之
理由如下：㈠工作說明書第1.5.2條載明編號5.9係「部署、使用後支援、報
告」 階段下之「社群行銷」下之細項「SMMS AdministratorTraining with Training Materials【社群媒體管理系統管理者訓練（含訓練教材）】」計8小時（原審卷1第65頁；原審卷4第270頁），兩造約定執行方式依工作說明書第1.2.0條第3項，完成標準依工作說明書第1.6節下之第3條決之（見之㈡）。
㈡被上訴人主張：伊於103年10月7日15:00至18:00、103年10月
13日14:00至17:00、103年10月17日10:00至11:30、103年10月22日10:00至12:30、103年10月23日10:30至12:30、103年10月24日10:00起，執行編號5.9教育訓練共計逾12小時，到場之上訴人專案人員均已簽認等語，業據提出上訴人不爭執真正之簽到單影本（原審卷2第117至122頁）為證，依上開約定，編號5.9教育訓練即視為全部完成。
㈢上訴人抗辯：被上訴人未交付訓練教材云云。然查，工作說明
書第1.2.0條第3項明定上訴人負責重製訓練教材。且被上訴人於103年4月29日交付編號2.2「Social Responding BusinessRequirement Document for SMMS（社群媒體管理系統適用之社群回應商業需求文件）」、於103年7月14日交付編號3.5「SMMS Specifications（社群媒體管理系統規格）」等文件（原審卷1第63頁反面、第64頁；原審卷4第267、268頁），並依工作說明書第1.6節及其下第2條約定，視為完成各該交付項目，為兩造不爭執之事實。另依論述，被上訴人於103年9月24日完成編號5.5「IBM Campaign及社群媒體管理系統上線計劃」交付項目，及依論述，被上訴人於104年1月6日交付編號5.7「社群媒體管理系統原始碼」，符合之㈠所示a條件，視為上訴人已接受。再觀之㈡所示工作說明書第1.1.1.3條約定社群媒體管理系統之範圍及功能，與其互動之單元、系統有關之交付項目（編號2.1、2.3至2.15、2.2至2.28、3.1至3.4、3.7至
3.20、4.3至4.5、4.9至4.13、4.17、5.1至5.4、5.8、5.10、
5.11、5.13、5.14），已於執行編號5.9交付項目前陸續完成。此外，上訴人於104年5月12日發予被上訴人之電郵中表列之履約爭議，並未爭執此工作項目之訓練教材未達完成標準（原審卷1第367頁反面）。綜上事證，堪認被上訴人執行編號5.9教育訓練所使用之教材合於工作說明書第1.6節下之第2條完成標準，上訴人之抗辯洵非可取。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.9交付項目乙
節屬實，上訴人所為抗辯則均不可採。關於被上訴人是否依約完成編號5.12交付項目之爭點，得心證
之理由如下：㈠工作說明書第1.5.2條載明編號5.12係「部署、使用後支援、報
告」 階段下之「論壇」下之細項「 System operation tr-aining with Training Materials【系統操作訓練（含訓練教材）】」計4小時（原審卷1第65頁；原審卷4第270頁），兩造約定執行方式依工作說明書第1.2.0條第3項，完成標準依工作說明書第1.6節下之第3條決之（見之㈡）。
㈡被上訴人主張：伊於103年7月11日14:30至15:00、18:00至19:0
0，及103年7月15日15:00起，執行編號5.12之教育訓練，到場之上訴人專案人員均已簽認等語，業據提出上訴人不爭執真正之簽到單影本（原審卷2第123至124頁）為證，堪以信實。上訴人雖以103年7月15日簽到單未記載結束時間，否認被上訴人提供合計4小時之教育訓練，然依工作說明書第1.6節下之第3條約定，參與該課程之上訴人人員既已簽字認可，應推定課程時數已達4小時，且之㈣所示上訴人於104年5月12日發予被上訴人之電郵中表列之履約爭議，並未爭執此工作項目時數不足（原審卷1第367頁反面），是上訴人空言否認，尚不足採。準此，依上開約定，編號5.12教育訓練即視為全部完成。
㈢上訴人抗辯：被上訴人未交付訓練教材云云。然查，被上訴人
主張：教材為所示編號5.10文件等語，為上訴人所不爭執，且依工作說明書第1.2.0條第3項約定，上訴人負責重製訓練教材。是上訴人之抗辯洵非可取。
㈣上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈤綜上事證，堪認被上訴人主張其已依約完成編號5.12交付項目乙節屬實，上訴人所為抗辯則均不可採。
關於被上訴人是否依約完成編號5.15交付項目之爭點，得心證
之理由如下：㈠工作說明書第1.5.2條載明編號5.15係「部署、使用後支援、報
告」 階段下之「整合與架構」下之細項「Cast Iron Trai-ni
ng with Training Materials【Cast Iron訓練（含訓練教材）】」計2小時（原審卷1第65頁；原審卷4第270頁），兩造約定執行方式依工作說明書第1.2.0條第3項，完成標準依工作說明書第1.6節下之第3條決之（見之㈡）。
㈡上訴人主張：伊於103年8月11日13:30至15:15執行編號5.15教
育訓練逾2小時，到場之上訴人專案人員均已簽認等語，業據提出上訴人不爭執真正之簽到單影本（原審卷2第125頁）為證，依上開約定，編號5.15教育訓練即視為全部完成。
㈢上訴人抗辯：系爭專案執行期間，兩造合意以伊簽署服務完成
確認單，作為被上訴人完成「交付項目」之標準，被上訴人未提交服務完成確認單予伊之專案人員簽署，可見此項目未完成云云，然引用之㈣理由，此抗辯為不可採。㈣綜上事證，堪認被上訴人主張其已依約完成編號5.15交付項目
乙節屬實，上訴人所為抗辯則均不可採。關於被上訴人是否依約完成編號5.16交付項目之爭點，得心證之理由如下：
㈠工作說明書第1.5.2條載明編號5.16係「部署、使用後支援、報
告」階段下之「Cloud Infrastructure（雲端基礎架構）」下之細項「Monthly managed service report（每月受管理服務報告）」，類型為「文件」（原審卷1第65頁；原審卷4第270頁），依之㈡說明，兩造約定完成標準按工作說明書第1.6節及其下第2條決之。
㈡按工作說明書第1.1.7條「Cloud Infrastructure Implement-a
tion and Support Services（雲端基礎架構施行與支援服務）」約定：「This part describes the services and ap-plications infrastructure deployed on SoftLayer. Thesupported applications categorize into below types:…Infrastructure Operation Services - IBM will provideInfrastructure Operation Services in managing serverenvironment with following tasks:- Server networkingimplementation - Batch process+ result check - Backup
and restore task and result check - Monthly report -Change management operation support - Remote 24 hourduty center monitoring service - Ticket opening and
tracking（基礎架構作業服務：被上訴人將於利用下列作業管理伺服器環境時提供「基礎架構作業服務」：⒈伺服器網路功能施行⒉批次程序及結果檢查⒊備份與還原作業及結果檢查⒋每月報告⒌變更管理運作支援⒍遠端24小時值勤中心監視服務⒎問題單之開啟及追蹤）」，及依「AppendixE（附錄E）」，上訴人係向SUSE Linux購買1年之SoftLayer雲端服務。（原審卷1第44頁、第77頁反面；原審卷4第231、232、295頁）。查被上訴人主張：伊按月以電郵寄送前一月份之編號5.16文件予上訴人等語，業據提出電郵22件（顯示103年11月25日寄103年10月報告；103年12月9日寄103年11月份報告；104年1月10至16日陸續寄103年12月份報告；104年2月10日寄104年1月份報告；104年3月17至20日陸續寄104年2月份報告；104年4月14日寄104年3月份報告）影本（原審卷2第126至147頁）為證，為上訴人所不爭執，堪予信實。又按工作說明書第1.3.6.7條「
Go Live Support and Post Live Support（上線支援與上線後支援）」約定：「IBM will support the System Go Liveactivities and provide one month Post Live support.（被上訴人將支援系統上線活動，並提供一個月上線後之支援）」，其「完成標準」為「When one month Post Live is completed this section will be deemed completed.（上線後一個月，本節即視為完成）」（原審卷1第62頁；原審卷4第265頁），查依之㈡所示被上訴人之專案經理李珉玲之電郵及兩造專案經理室之會議紀錄結論，確認系爭專案之所有系統已於104年1月16日之前陸續上線至上訴人之正式作業環境，被上訴人並開始提供一個月之上線後支援服務，則自上線翌日起算一個月，至104年2月16日視為被上訴人完成「上線支援及上線後支援」。上訴人復未提出證據證明其於104年4月14日最後一次收受編號5.16文件後5個工作日内（即104年4月21日之前）曾以書面提出修訂要求，依工作說明書第1.6節下之第2條約定，於104年4月22日視為被上訴人完成編號5.11交付項目。
㈢上訴人抗辯：被上訴人應交付編號5.16文件之定稿版本予伊之
專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，工作說明書第1.5.2條明定編號5.16交付項目之格式為「Power Point or Word」（原審卷1第65頁），為電子檔，非紙本文件。引用之㈤理由，被上訴人交付電子檔，合於兩造約定，上訴人之抗辯不足採信。
㈣綜上事證，堪認被上訴人主張其已依約完成編號5.16交付項目乙節屬實，上訴人所為抗辯則無可憑採。
按工作說明書第1.8「價款」下之「Invoice Schedule（發票時
程）」約定：「Payment is due upon receipt of invoic-e.
All payments are payable within 45 days from recei-vi
ng IBM invoice ("the Payable Date"). In case that
IBM invoice is incorrect, IBM shall reissue the invoi-
ce and the Payable Date shall be extended accordingly.（價款支付義務於收到發票時到期。一切款項均應於上訴人收到被上訴人發票之日後45日內支付。被上訴人發票如有訛誤者，被上訴人應重新開立發票，付款日順延。）」（原審卷1第66頁正反面；原審卷4第272頁）。次按修訂書就之㈢所示第2至5期「付款項目」約定「發票時程」適用「IBM Payme-nt Plan（被上訴人付款計劃，簡稱IPP），而於IPP下約定：「6. I
BM will issue invoices to bil1 HTC in accordance withfollowing IPP Payment Schedule and HTC shall make thepayments before each Payment Due Date as stated b-elow.（⒍被上訴人將依下列IPP付款時程開立發票向上訴人收款，上訴人應於下表所示各「付款到期日」前付款）」、「7.IBM
may invoice HTC in New Taiwan Dollar (NTD) for ea-ch Payment item with the Exchange Rates of the New Ta-iwan
Dollar Against the U.S.Dollar (Interbank Spot Ma-rketClosing Rates) as published by the Central Bank
of the Republic of China on the first payment scheduledate (D2, D3, D4, D5) for all payment schedules (2-1 &2-2, 3-1 & 3-2, 4-1 & 4-2, 5-1 & 5-2) of each Paymentitem (#2, #3, #4, #5) respectively (for example: OneMilestone amount is USD1000 and the exchange rate is
30.8 in the milestone completion date. The Payment am-ount for this milestone will be NTD30,800 and IBM willissue two invoices with amount NTD23,100 and NTD7,700
for first and 2nd payment base on the structure in IP-P) and HTC agrees to pay each payment by New Taiwan D-ollar (NTD).【被上訴人得分別於各期「付款項目」（第2期、第3期、第4期、第5期）一切付款時程（2-1及2-2、3-1及3-
2、4-1及4-2、5-1及5-2）之第一個付款時程日期（D2、D3、D4、D5）依中華民國中央銀行公告之「新臺幣對美元銀行間成交之收盤匯率」，就各該「付款項目」，以新臺幣向上訴人開立發票（例如：某項付款時程金額為美金1,000元，付款時程完成日之匯率為30.8，則此付款時程之「付款」金額應為新臺幣30,800元，被上訴人將依IPP中之分期付款約定，就第一小期付款與第二小期付款開立二張發票，金額各為新臺幣23,100元及新臺幣7,700元，上訴人同意以新臺幣支付各該款項。】」，「IPP付款時程」表則載明：⒈第2期「付款項目」中之第2-2期款（含5%營業稅，下同）為美金382,500元，「B-illing Date（發票開立日）」為「Completion deliverables
of Build Phase in section 1.5.2（完成交付工作說明書第
1.5.2條中建置階段之項目）」+6個月，「Payment Due Date（付款到期日）」為「完成交付工作說明書第1.5.2條中建置階段之項目」+9個月。⒉第3期「付款項目」中之第3-1期款為美金860,625元，「發票開立日」為「Completion deliverab-
les of Test Phase in section 1.5.2（完成交付工作說明書第1.5.2條中測試階段之項目）」，「付款到期日」為「完成交付工作說明書第1.5.2條中測試階段之項目」+3個月；第3-2期款為美金286,875元，「發票開立日」為「完成交付工作說明書第1.5.2條中測試階段之項目」+6個月，「付款到期日」為「完成交付工作說明書第1.5.2條中測試階段之項目」+9個月。⒊第4期「付款項目」中之第4-1期款為美金1,147,500元，「發票開立日」為「Completion deliverables of Depl-oy Phase in section 1.5.2（完成交付工作說明書第1.5.2條中部署階段之項目）」，「付款到期日」為「完成交付工作說明書第1.5.2條中部署階段之項目」+3個月；第4-2期款為美金382,500元，「發票開立日」為「完成交付工作說明書第1.5.2條中部署階段之項目」+6個月，「付款到期日」為「完成交付工作說明書第1.5.2條中部署階段之項目」+9個月。⒋第5期「付款項目」中之第5-1期款為美金860,625元，「發票開立日」為「Completion Go Live Support and deliverables of Project
Acceptance Report in section 1.5.1（完成交付工作說明書第1.5.1條中之「上線支援」及「專案驗收報告」）」，「付款到期日」為「完成交付工作說明書第1.5.1條中之『上線支援』及『專案驗收報告』」+3個月；第5-2期款為美金286,875元，「發票開立日」為「完成交付工作說明書第1.5.1條中之『上線支援』及『專案驗收報告』」+6個月，「付款到期日」為「完成交付工作說明書第1.5.1條中之『上線支援』及『專案驗收報告』」+9個月（原審卷1第127頁反面、第128頁；原審卷4第300、301頁）。修訂書另約定：「Except as otherwise stated i
n this Amendment No.1,
the terms and conditions of the SOW and Agreement rem-ainin full force and effect. This Amendment No.1 prev-ails and controls with respect to any inconsistency b-etween the terms and conditions of this Amendment No.1
and those of the SOW or Agreement.（除非修訂書另有其他約定外，工作說明書及主約條款繼續有效。修訂書之條款與工作說明書或主約之條款如有牴觸者，修訂書之條款優先。）」（原審卷1第128頁反面；原審卷4第301頁），再斟酌修訂書並無如同前揭工作說明書第1.8節下之「發票時程」關於上訴人付款期限以被上訴人開立發票日起算，且會因被上訴人重新開立發票而順延之約定，而係明定上訴人之付款期限以被上訴人完成特定階段項目，非以被上訴人開立發票為起算條件，自應優先適用修訂書，解為被上訴人完成特定階段之交付項目，起算上訴人之付款期限，且該期限不因被上訴人提出發票之日期而受影響。
按民法第229條第1項規定，給付有確定期限者，債務人自期限
屆滿時起，負遲延責任；第233條第1項規定，遲延之債務，以支付金錢為標的者，債權人得請求依法定利率計算之遲延利息。但約定利率較高者，仍從其約定利率。依論述，被上訴人於103年9月3日以前陸續完成「建置」階段全部交付項目，則修訂書所示第2-1期款之付款期限為103年12月3日，第2-2期款美金382,500元之付款期限為104年6月3日，再按103年12月3日中央銀行公告之「新臺幣對美元銀行間成交之收盤匯率」31.167元折算第2-2期款為11,921,378元（元以下四捨五入，下同）。被上訴人主張：伊已開立如附表所示修訂書第2-2期發票請款等語，為上訴人所不爭執，則被上訴人請求上訴人給付該期款11,484,563元，及自104年10月14日起至清償日止按年息5%計算之利息，為有理由。又按民法第128條前段規定，消滅時效，自請求權可行使時起算；第127條第7款規定，承攬人之報酬請求權，因2年間不行使而消滅。被上訴人於104年6月3日得請求上訴人給付第2-2期款，該請求權之2年時效於106年6月3日完成，被上訴人於105年10月24日提起本件訴訟，其行使請求權未罹於時效，上訴人為時效抗辯，顯然無據。依至論述，被上訴人於104年1月7日以前陸續完成「測試」
階段全部交付項目，則修訂書所示第3-1期款美金860,625元之付款期限為104年4月7日，第3-2期款美金286,875元之付款期限為104年10月7日，再按104年4月7日中央銀行公告之「新臺幣對美元銀行間成交之收盤匯率」31.152元折算第3-1期款為26,810,190元，第3-2期款為8,936,730元。被上訴人主張：伊已開立如附表所示修訂書第3-1、3-2期發票請款等語，提出信函、回執、銷貨明細表、發票等影本（原審卷1第148至150、153至156頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第3-1期款26,792,977元，及自104年4月17日起至清償日止按年息5%計算之利息，為有理由；請求上訴人給付第3-2期款8,936,730元，及自104年10月17日起至清償日止按年息5%計算之利息，為有理由，逾此所為請求，為無理由。
按工作說明書第1.5.2條編號5.1至5.16工作項目雖置於「部署
、使用後支援、報告」階段，但依第1.3.6節「部署」下之第1.3.6.1「社群行銷」約定，係於完成編號5.1至5.7交付項目時視為「社群行銷」部署階段全部完成；依第1.3.6.2、1.3.6.3條之「論壇」及「單一客戶視圖」約定，係於完成編號5.10至
5.14交付項目時視為「論壇」及「單一客戶視圖」之部署階段全部完成；依第1.3.6.4條「整合與架構」，及第1.3.6.5條「CRM整合」約定：「•Conduct one operation train-ing curriculum for call center key users who are pred-efined mutually by IBM and HTC. •Conduct one operati-on traini
ng curriculum for marketing key users who are predefin
ed mutually by IBM and HTC.•Deploy CRM integ-ration services (defined in section 1.1.5) to product-ion environment. •Confirm production application cut-over.（⒈針對兩造預先確認之電話客服中心關鍵使用者，開辦操作訓練系列課程。⒉針對兩造預先確認之行銷關鍵使用者，開辦操作訓練系列課程。⒊將CRM整合服務（規定於第1.1.5條）部署至正式作業環境。⒋確認正式作業應用程式快速轉換。）」，於完成編號5.8、5.9、5.12、5.15交付項目時視為部署階段全部完成；依第1.3.6.6條之「Cloud Infrastruc-ture Implementat
ion and Support Services（雲端基礎架構施行及支援服務）」約定「General support at Infrastruc-ture level as pe
r tasks list in 1.3.4.6 Cloud Infrast-ructure Implementation and Support Services.（基礎架構層次之一般支援，如第1.3.4.6條「雲端基礎架構施行與支援服務」中作業清單所示。）」，而第1.3.4.6條約定作業包括「24-HR remote monitor server and storage system, net-work connection status（24小時遠端監視伺服器與儲存體系統、網路連線狀態）」及「Infrastructure Administration Services（基礎架構管理服務）」等作業，應於完成編號5.16交付項目時視為部署階段全部完成（原審卷1第58至59、61至62頁；原審卷4第257至259、262至265頁）。查依至論述，被上訴人於104年4月22日以前陸續完成編號5.1至5.16交付項目，「部署」階段即告全部完成，則修訂書所示第4-1期款美金1,147,500元之付款期限為104年7月22日，第4-2期款美金382,500元之付款期限為105年1月22日，再按104年7月22日中央銀行公告之「新臺幣對美元銀行間成交之收盤匯率」
31.352元折算第4-1期款為35,976,420元，第4-2期款為11,992,140元。被上訴人主張：伊已開立如附表所示修訂書第4-1、4-2期發票請款等語，提出信函、回執、銷貨明細表、發票等影本（原審卷1第148至149、151、153、154、157至159頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第4-1期款35,723,970元，及自104年7月23日起至清償日止按年息5%計算之利息；請求上訴人給付第4-2期款11,992,140元，及自105年1月23日起至清償日止按年息5%計算之利息，均為有理由，逾此所為請求，為無理由。按工作說明書第1.3.6.7條「Go Live Support and Post Live
Support（上線支援與上線後支援）」約定：「IBM will sup-port the System Go Live activities and provide one mo-
nth Post Live support.（被上訴人將支援系統上線活動，並提供一個月上線後之支援）」，其「完成標準」為「When one
month Post Live is completed this section will be dee-med completed.（上線後一個月，本節即視為完成）」（原審卷1第62頁；原審卷4第265頁）。查依之㈡論述，被上訴人於104年2月16日視為被上訴人完成「上線支援及上線後支援」。再按工作說明書第1.6節下之第4條「Project Complet-ion（專案完成）」約定：「This Project will be deemed
as completed when whichever occurs first: ⑴ all theDeliverables set forth in Section 1.5 are accepted by
HTC through the above completion criteria; ⑵ complete
of Project go-live support and there is no severity l-evel 1 defect(s) outstanding solely caused by IBM.【有下列情形者（以發生在先者為準），本專案即視為完成：⑴上訴人依前揭完成標準接受第1.5節所定一切交付項目者；⑵完成專案上線支援，且無單由被上訴人一方所致未解決之嚴重性層次1瑕疵者。】」（原審卷1第65頁反面、第66頁；原審卷4第271頁），被上訴人既於104年4月22日以前陸續完成工作說明書第1.5節所定一切交付項目，系爭專案即視為完成，自得推定修訂書所定第5期付款期日起算之「完成交付工作說明書第1.
5.1條中之上線支援及專案驗收報告」條件於104年4月22日成就，準此，第5-1期款美金860,625元之付款期限為104年7月22日，第5-2期款美金286,875元之付款期限為105年1月22日，再按104年7月22日中央銀行公告之「新臺幣對美元銀行間成交之收盤匯率」31.352元折算第5-1期款為26,982,315元，第5-2期款為8,994,105元。被上訴人主張：伊已開立如附表所示修訂書第5-1、5-2期發票請款等語，提出信函、回執、銷貨明細表、發票等影本（原審卷1第160至161、151、
153、154、157至159頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第5-1期款26,792,977元，及自104年12月1日起至清償日止按年息5%計算之利息，為有理由。被上訴人請求上訴人給付第5-2期款8,994,105元，及自105年6月1日起至清償日止按年息5%計算之利息，為有理由。
按修訂書約定：「In addition to the project scope in se
ction 1.1 of the SOW, IBM agrees to undertake the f-ollowing scope of work:…IBM will develop the Communi-tyAPIs. The API list is as below.（除工作說明書第1.1節約定之專案範圍外，被上訴人同意新增下列工作範圍：被上訴人將開發「論壇API」；「Assumptions…1.APP developme-nt is
HTC's responsibility, but API's development isIBM's responsibility to make sure API is workable for
APP development purpose. 2.China community data migra-tion task is HTC's responsibility.（專案假設：…⒈APP開發由上訴人負責，API開發則由被上訴人負責以確認API適用於APP開發用途。⒉中國論壇資料移轉作業由上訴人負責。）」，「專案交付項目」之階段及交付項目區分為：⒈「設計∕建置」階段，交付項目為「論壇API」作業下之⑴「System Requirement Document（系統需求文件）」及⑵「Sy-s
tem Design Document（系統設計文件）」。⒉「測試」階段，交付項目為「論壇API」作業下之「Test Report（測試報告）」。⒊「Technical Support（技術支援）」階段，交付項目為「Support and Monitor System（支援及監督系統）」作業下之「 Service Log Document（服務紀錄文件）」。⒋「部署」階段，交付項目為⑴「論壇API」作業下之「HTC Co-mmunity A
PI - coding（論壇API編碼）」、⑵「Consultingservice to China（中國諮詢服務）」作業下之「Meeting m-inutes（會議紀錄）」、⑶「Functional Enhancement（功能升級）」作業下之①「Functional Enhancement source code（功能升級原始碼）」、②「Service confirmation sign-off（服務確認登出）」。「交付項目完成標準」約定：「Pr-ojecl Deliverables listed above shall only be deemedcompleted upon acceptance by HTC in accordance with t-
he acceptance criteria in Section 1.6 of the SOW.（上述交付項目於上訴人依照工作說明書第1.6節完成標準接受時視為完成）」，「付款里程碑」則區分為⒈ 「sign off ofthis Addendum（修訂書簽署日）」、⒉完成階段1交付項目、⒊完成階段2交付項目、⒋完成階段3交付項目、⒌完成階段4交付項目（原審卷1第131、132頁；原審卷4第303至305頁）。查：
㈠上開階段1之交付項目⑴、⑵；階段2、3交付項目，及階段4之交
付項目⑵、⑶之②，「類型」均為「文件」，格式均為「P-owerPoint or Word」，兩造約定完成標準按工作說明書第1.6節及其下第2條決之（見之㈡說明）。階段4之交付項目⑴及⑶之①交付項目，「格式」均為「可攜式媒體」，「類型」均為「應用程式（含原始碼）」，兩造約定完成標準依之㈠所示工作說明書第1.6節及其下第1條決之。
㈡被上訴人主張：伊交付階段1之交付項目⑴、⑵之電子檔予上訴人
後，於104年1月15日提交服務完成確認單，經上訴人之「IT Leader」王文泰及「Business Leader」Adam Chen（陳家馴）簽署等語，業據提出上訴人不爭執真正之服務完成確認單影本（原審卷1第228頁）為證，堪予信實。上訴人既未提出證據證明其於收受各該文件後5個工作日内（即104年1月22日前），曾以書面提出修訂要求，依上開約定，至遲於104年1月23日視為被上訴人完成各該交付項目。㈢被上訴人主張：伊交付階段2之交付項目電子檔予上訴人後，於
104年3月6日提交服務完成確認單，經上訴人之「IT Leader」王文泰及「Business Leader」陳家馴簽署等語，業據提出上訴人不爭執真正之服務完成確認單影本（原審卷1第228頁反面）為證，堪予信實。上訴人既未提出證據證明其於收受各該文件後5個工作日内（即104年3月13日前），曾以書面提出修訂要求，依上開約定，至遲於104年3月14日視為被上訴人完成各該交付項目。
㈣被上訴人主張：伊交付階段3之交付項目電子檔予上訴人後，於
104年3月23日提交服務完成確認單，經上訴人之「IT Lead-er」王文泰及「Business Leader」陳家馴簽署等語，業據提出上訴人不爭執真正之服務完成確認單影本（原審卷1第229頁反面）為證，堪予信實。上訴人既未提出證據證明其於收受各該文件後5個工作日内（即104年3月30日前），曾以書面提出修訂要求，依上開約定，至遲於104年3月31日視為被上訴人完成各該交付項目。
㈤被上訴人主張：伊於104年3月23日前完成第4階段交付項目，但
提交服務完成確認單後，上訴人遲不簽認，伊之專案人員盧司堃（Steve Lu）於104年4月30日發電郵予陳家馴，表示：「As
discussed one month ago, the Community PCR Phase 4 ha
s been completed. Need your kindly help to sign o-ff t
he acceptance. The last milestone is phase 5 and Ialsoneed your advise to let me know anything else th-at w
e have not completed.（如同我們1個月前的討論，修訂書的第4階段已經完成，麻煩您簽署該階段確認單。最後一期付款里程碑是第5期，我也需要您讓我知道我們還有什麼事還沒完成）」等語，業據提出上訴人不爭執真正之電郵影本（原審卷1第237頁）為證，堪予信實。上訴人既未提出證據證明其於收受階段4之交付項目⑵及⑶之②文件後5個工作日内（即104年3月30日前），曾以書面提出修訂要求，依上開約定，至遲於104年3月31日視為被上訴人完成各該交付項目。又上訴人之論壇於103年7月22日在上訴人之商業用途作業環境中執行，引用之㈡之理由，堪認被上訴人交付階段4之交付項目⑴及⑶之①交付項目，至遲於103年7月22日達到工作說明書第1.6節下之第1條所示b完成標準，視為已為上訴人接受。
㈥上訴人抗辯：被上訴人應交付階段1之交付項目⑴、⑵；階段2、3
交付項目，及階段4之交付項目⑵、⑶之②等文件之定稿版本予伊之專案經理劉冠廷，始符合工作說明書第1.6節之2之ａ約定之交付方式云云，惟查，各該交付項目之格式均為電子檔，非紙本文件，引用之㈤理由，被上訴人交付電子檔予上訴人，並無不合，上訴人之抗辯不足採信。㈦上訴人抗辯：系爭專案執行期間，兩造合意以伊之專案經理劉
冠廷簽署服務完成確認單，作為被上訴人完成「交付項目」之標準，被上訴人提交之服務完成確認單未經伊之專案經理劉冠廷簽署，或未提出服務完成確認單予伊之專案人員簽署，可見修訂書之交付項目均未完成云云，然引用之㈣理由，此抗辯為不可採。
五十一：按修訂書之「付款計劃（IPP）」約定：「2.HTC agrees to
pay the amounts due with respect to the Services in a-ccordance with the IPP as set out in below IPP PaymentSchedule.…6.IBM will issue invoices to bill HTC in a-ccordance with following IPP Payment Schedule and HTCshall make the payments before each Payment Due Date
as stated below.（⒉上訴人同意依照下述IPP付款時程約定之IPP，就「服務」支付到期應付金額）。…⒍被上訴人將依下列IPP付款時程開立發票向上訴人收款，上訴人應於下表所示各「付款到期日」前付款）」。「IPP付款時程」表則約定：「Payment Schedule #1（第1期程）」之第1期款（含5%營業稅，下同）為784,350元，「發票開立日」為「sign off date of th
is Addendum（兩造簽署修訂書之日）」，「付款到期日」為「兩造簽署修訂書之日」+3個月；第2期款為261,450元，「發票開立日」為「兩造簽署修訂書之日」+6個月，「付款到期日」為「兩造簽署修訂書之日」+9個月。「Payment Schedule #2（第2期程）」之第1期款為1,176,525元，「發票開立日」為「完成階段1之日」，「付款到期日」為「完成階段1之日」+3個月；第2期款為392,175元，「發票開立日」為「完成階段1之日」+6個月，「付款到期日」為「完成階段1之日」+9個月。「Payment Schedule #3（第3期程）」之第1期款為784,350元，「發票開立日」為「完成階段2之日」，「付款到期日」為「完成階段2之日」+3個月；第2期款為261,450元，「發票開立日」為「完成階段2之日」+6個月，「付款到期日」為「完成階段2之日」+9個月。「Payment Schedule #4（第4期程）」之第1期款為588,257元，「發票開立日」為「完成階段3之日」，「付款到期日」為「完成階段3之日」+3個月；第2期款為196,093元，「發票開立日」為「完成階段3之日」+6個月，「付款到期日」為「完成階段3之日」+9個月。「Payment Schedule #5（第5期程）」之第1期款為588,257元，「發票開立日」為「完成階段4之日」，「付款到期日」為「完成階段4之日」+3個月；第2期款為196,093元，「發票開立日」為「完成階段4之日」+6個月，「付款到期日」為「完成階段4之日」+9個月。另約定：「Except as ot-herwise stated in this Amendment, the terms and condi-ti
ons of the SOW and Master Services Agreement remai-ni
n in full force and effect. This Amendment prevails an
d controls with respect to any inconsistency between t
he terms and conditions of this Amendment and those
of the SOW.（除非修訂書另有其他約定外，工作說明書及主約條款繼續有效。修訂書之條款與工作說明書之條款如有不一致者，修訂書之條款優先。）」（原審卷1第133、134頁；原審卷4第307、308頁）。再斟酌修訂書並無如同工作說明書第1.8節下之「發票時程」關於上訴人付款期限自被上訴人開立發票日起算，且被上訴人重新開立發票者，付款期限隨之順延之約定（見），而係明定上訴人之付款期限以兩造簽署修訂書或被上訴人完成特定階段項目起算，非以被上訴人開立發票為起算條件，自應優先適用修訂書，解為於兩造簽署修訂書或被上訴人完成特定階段項目時，起算上訴人之付款期限，且該期限不因被上訴人提出發票之日期或尚未開立發票而受影響。查：
㈠第1期程之第1期款784,350元之「付款到期日」為「兩造簽署修
訂書之日」+3個月，第2期款261,450元之「付款到期日」為「兩造簽署修訂書之日」+9個月。上訴人簽署修訂書時 未記載簽署日期（原審卷1第134頁），被上訴人主張以其於103年12月16日收到上訴人簽回之修訂書為兩造簽署之日等語，有被上訴人在其留存之修訂書上所蓋「Date received by
IBM: DEC 00 0000（被上訴人收受日期103年12月16日）」印文（原審卷1第131頁）為憑，並為上訴人所不爭執，堪予信實，準此，第1期款付款期限為104年3月16日，第2期款之付款期限為104年9月16日。又被上訴人主張：伊已開立附表所示修訂書之第1-1、1-2期發票請款等語，提出銷貨明細表、發票等影本（原審卷1第163至166頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第1期款784,350元，及自104年3月17日起至清償日止按年息5%計算之利息；請求上訴人給付第2期款261,450元，及自104年9月17日起至清償日止按年息5%計算之利息，為有理由。㈡第2期程之第1期款1,176,525元之「付款到期日」為「完成階段
1之日」+3個月，第2期款392,175元之「付款到期日」為「完成階段1之日」+9個月。依之㈡，被上訴人於104年1月23日完成階段1交付項目，是第1期款付款期限為104年4月23日，第2期款之付款期限為104年10月23日。又被上訴人主張：伊已開立附表所示修訂書之第2-1、2-2期發票請款等語，提出銷貨明細表、發票等影本（原審卷1第167至170頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第1期款1,176,525元，及自104年4月29日起至清償日止按年息5%計算之利息；請求上訴人給付第2期款392,175元，及自104年10月29日起至清償日止按年息5%計算之利息，為有理由。㈢第3期程之第1期款784,350元之「付款到期日」為「完成階段2
之日」+3個月，第2期款261,450元之「付款到期日」為「完成階段2之日」+9個月。依之㈢，被上訴人於104年3月14日完成階段2交付項目，是第1期款付款期限為104年6月14日，第2期款之付款期限為104年12月14日。又被上訴人主張：伊已開立如附表所示修訂書之第3-1、3-2期發票請款等語，提出銷貨明細表、發票等影本（原審卷1第171至174頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第1期款784,350元，及自104年6月18日起至清償日止按年息5%計算之利息；請求上訴人給付第2期款261,450元，及自104年12月18日起至清償日止按年息5%計算之利息，為有理由。
㈣第4期程之第1期款588,257元之「付款到期日」為「完成階段3
之日」+3個月，第2期款196,093元之「付款到期日」為「完成階段3之日」+9個月。依之㈣，被上訴人於104年3月31日完成階段3交付項目，是第1期款付款期限為104年6月30日，第2期款之付款期限為104年12月31日。又被上訴人主張：伊已開立如附表所示修訂書之第4-1、4-2期發票請款等語，提出銷貨明細表、發票等影本（原審卷1第175至177頁）為證，上訴人亦不爭執，則被上訴人請求上訴人給付第1期款588,257元，及自104年9月11日起至清償日止按年息5%計算之利息；請求上訴人給付第2期款196,093元，及自105年3月11日起至清償日止按年息5%計算之利息，為有理由。㈤第5期程之第1期款588,257元之「付款到期日」為「完成階段4
之日」+3個月，第2期款196,093元之「付款到期日」為「完成階段4之日」+9個月。依之㈤，被上訴人於104年3月31日完成階段4交付項目，是第1期款付款期限為104年6月30日，第2期款之付款期限為104年12月31日。則被上訴人請求上訴人給付第1期款588,257元，及自104年10月15日起至清償日止按年息5%計算之利息；請求上訴人給付第2期款196,093元，及自105年4月15日起至清償日止按年息5%計算之利息，為有理由。
五十二：關於上訴人抗辯：被上訴人交付之「論壇」介面有之㈣㈤所示瑕疵，被上訴人交付之社群媒體管理系統有無法與Facebook及Google+進行接觸點整合及建立單一使用者介面之瑕疵，爰依民法第227條第1項適用第254條、第494條第1項、第502條第2項等規定，以106年5月1日答辯狀之送達（於106年5月2日送達被上訴人）解除系爭契約（原審卷1第232、247、252頁；卷2第264頁；卷3第91頁反面）；依民法第502條第2項規定，以答辯㈤狀之送達（於106年7月26日送達被上訴人）及於108年12月11日解除系爭契約（原審卷4第514頁）；伊之專案經理劉冠廷於104年3月10日以電郵請求減除社群行銷分析與社群行銷管理系統的費用（原審卷4第509頁；本院卷2第132頁），伊再類推適用民法第572條規定，請求酌減價金（原審卷5第67、68頁）；於被上訴人完成瑕疵修補，且在伊之雲端平台重建系統，進而以該系統資料為基礎履行原審卷2第268至271頁及原審卷4第320至323頁附表所列工作，經伊驗收確認前，依民法第264條規定行使同時履行抗辯權，拒絕給付價金（原審卷1第253頁；原審卷2第268頁；原審卷4第320至323頁）等語，得心證之理由如下：
㈠依論斷，上訴人指摘被上訴人交付之「論壇」客製化程式或介
面存在瑕疵乙節，均不可採。㈡上訴人抗辯：依工作說明書第1.1.1.3條，被上訴人應依據各該
社群媒體「當下適用」或「已釋出將適用」之API規格，進行接觸點整合及建立單一使用者介面，Facebook於103年4月30日發佈介接規範第2版（資料來源為https://developers.facebo
ok.com/docs/apps/changeloa）（原審卷1第246頁），介接規範第1版使用期限則至104年4月30日，然被上訴人交付之社群媒體管理系統規格係使用第1版介接規範，致該系統自104年4月30日起無法蒐集Facebook使用者資料，伊於104年5月12日發函要求被上訴人於10日內就「SMA/SMMS does not capture/display all comments on our Facebook/Google+ own chan-nels, so own channel moderation is impossible.（社群媒體分析程式及社群媒體管理系統無法抓到顯示在上訴人之Fac-ebook/Google+自有頻道上之所有評論，致使上訴人無法達成主持本身的社群媒體粉絲頁。）」、「SMMS can not send p-rivate messages to Facebook…users.（社群媒體管理系統無法傳送私人訊息給Facebook…的使用者）」（原審卷1第361頁；本院卷2第321、322頁）提出解決方案，再於104年10月14日函催被上訴人於10日内提出解決方案，被上訴人迄未提出等語。
㈢按工作說明書第1.1.1.3條（見之㈡）明定被上訴人係針對内含
獲得支援之整合API（應用程式開發介面）之5個社群媒體（包括Facebook、Google在內)建立統一使用者介面，供社群管理者用以回應作者；在上述社群媒體提供API之前提下，有在上訴人於上述社群媒體之網頁上顯示發佈內容之效能，及在Facebook提供API之前提下，社群媒體管理系統平台可提供將內容發佈至上訴人在Facebook之網頁之功能。第1.4.2.3條（見之㈢）亦約定上訴人負責取得第三人之API予被上訴人執行系爭專案工作項目，如上訴人未取得，致阻礙被上訴人執行工作者，被上訴人得停止提供該部分服務，或者由兩造透過工作說明書附錄A之「專案變更要求程序」合意刪除該部分工作。是各該社群媒體釋出API，被上訴人始能開發與該社群媒體程式介接之外部程式。
㈣被上訴人之專案人員Kate Lin（林欣儀）於103年5月31日發電
郵予張庭瑋，表示「Google+ only provides "reads" permi-ssion to public and in order to "writes" (such as com-ment, create a new post to Google+ pages), we need tohave access to Google+ Pages API, which can only be a-ccessed by company which are whitelisted by Googlc+.【Google Plus只向公眾提供"閱覽"權限，為了能夠"寫"（例如評論、創造新貼文到Google Plus粉絲頁），我們需要取得授權得以存取Google Plus粉絲頁之應用程式開發介面。該應用程式開發介面只能由被Google Plus列入白名單之被授權公司來存取。】」，張庭瑋於同日以電郵回覆：「 Do you know t
he name of those APIs or do you have the url link to t
he page where we can apply the access right?（請問您知道那些應用程式開發介面的名稱，或是您有我們可以申請授權之網頁連結嗎？）」，林欣儀即於103年6月2日以電郵發送申請網址予張庭瑋，但嗣後未收到該應用程式開發介面。被上訴人之專案經理李珉玲乃於103年7月3日發電郵予張庭瑋、上訴人之專案經理劉冠廷，表示：「For the purpose of deve-loping the application (social media management syste-m)
for HTC (or developing any applications for otherclients that requires IBM to deliver source codes), it
is recommended that HTC signs the NDA with google+ toobtain the APIs required for building/using the appli-cation. According to the NDA, if IBM signs the NDA wi-th Google+ and obtains the APIs on its own, IBM will
not be able to deliver the application it develops for
HTC to HTC. On the other hand, if HTC obtains the API
s itself, IBM will use the APIs to build the applicati
on on behalf of HTC, as the Google NDA allows HTC (i.e.
the confidential information recipient) to share ifor-mation with its third party contractor(s).【為了替上訴人（或為需要被上訴人交付原始碼之其他客戶開發任何應用程式）開發應用程式，建議由上訴人與Google Plus簽署保密協議以取得建置∕使用應用程式所需要之應用程式開發介面。根據該保密協議，假如是由被上訴人與Google Plus簽署協議而自行取得應用程式開發介面，被上訴人不能將為上訴人開發之應用程式交付予上訴人。另一方面，假如是由上訴人自行取得應用程式開發介面，被上訴人是代理上訴人使用應用程式開發介面以建置應用程式，因為Google Plus之保密協議允許上訴人（即機密資訊收受者）與第三方承包商共享機密資訊。】」，同日系爭專案會議紀錄亦記載結論：「Due to the ownersh
ip issue, IBM legal is afraid that Google+ API application could not be submitted from IBM side. HTC applied, and then delegate the authorization to IBM w-ill be
a better solution.」，但上訴人始終未取得Google+之應用程式開發介面等情，有被上訴人提出上訴人不爭執真正之電郵影本（原審卷2第13、14、176、177頁），及上訴人提出之會議紀錄影本（原審卷2第244頁）可稽。至於上訴人抗辯其嗣後有取得應用程式開發介面，提供被上訴人使用云云，未舉證以實其說，難以採信。從而，被上訴人交付之社群媒體管理系統不具備提供抓到顯示在上訴人之Google+自有頻道上之所有評論之功能，係因上訴人未盡提供該社群媒體API之協力義務，並非被上訴人給付不完全或有瑕疵。
㈤被上訴人主張：Facebook未提供公用API，伊無從開發在Face-b
ook網站上寄發私訊予貼文者之應用程式，且伊於103年7月14日交付工作說明書第1.5.2條所示「建置」階段之編號3.5「S-
MMS Specifications（社群媒體管理系統規格）」文件（檔號HTC_CCT_DS_SM_SRD_SMMS_Speicifcation.doc，於第2.3.9節「SMMS_UC09_SendPrivateMessage」有所說明，經王文泰、張庭瑋、劉冠廷於服務完成確認單簽認，依約視為於103年7月21日完成此交付項目等語，有上訴人提出之服務完成確認單影本（原審卷1第308頁）可稽，亦為上訴人自認（原審卷1第271頁）且不爭執。從而，被上訴人交付之社群媒體管理系統不具備抓到顯示在上訴人之Facebook自有頻道上之所有評論，及傳送私人訊息給Facebook使用者之功能，係因上訴人未盡提供該社群媒體API之協力義務，亦非被上訴人給付不完全或有瑕疵。
㈥綜上，上訴人抗辯被上訴人交付之「論壇」客製化程式或介面
及社群媒體管理系統存在上述工作瑕疵云云，為不可採，上訴人執此主張解除系爭契約、減少價金、酌減價金，均不合法。又上訴人未提供Facebook、Google+之API，致被上訴人開發之社群媒體管理系統無法與各該社群媒體程式介接，兩造並未透過工作說明書附錄A之「專案變更要求程序」合意刪除該部分工作，且被上訴人交付社群媒體管理系統相關工作項目，均依約視為完成，則上訴人事後為同時履行抗辯，拒絕給付價金，亦不合法。
五十三：關於上訴人抗辯：被上訴人交付之社群媒體分析模型不符約定品質與規格，經伊之專案經理劉冠廷於104年3月10日以電郵請求減除社群行銷分析與社群行銷管理系統的費用（原審卷4第509頁；本院卷2第132頁），伊再依民法第493條第1項、第494條第1項，或依民法第359條規定，請求減少價金（本院卷2第2
33、234頁），或類推適用民法第572條規定，請求酌減價金（原審卷5第67、68頁），又於被上訴人修補瑕疵，達到具備一般業界之觀感分析正確率，經伊驗收前，依民法第264條規定行使同時履行抗辯權，拒絕給付價金（原審卷1第253頁；原審卷2第268頁；原審卷4第320至323頁）等語，得心證之理由如下：
㈠上訴人抗辯：伊委託國立臺灣師範大學圖書資訊學研究所曾元
顯教授針對被上訴人於103年5月29日交付之Testing Plan(0529)，及於103年9月4日交付之EN006_TestingRu7sult_0903等文件，出具「HTC導入IBM方案之分析報告」（下稱系爭分析報告），認為有重大瑕疵：⒈被上訴人未建立測試資料集，以作為驗證模型調校優化之基礎，所用以測試社群媒體分析程式之模型資料筆數遠低於業界一般測試資料集筆數，故在模型設計與測試方法規劃上未盡善良管理人注意義務。⒉被上訴人所採用計算正確率之方式，僅考量社群媒體分析程式判讀結果與人工判斷一致性之比例，未能將貼文類型分布不平均的問題納入考量，導致評估社群媒體分析程式有相當程度的誤導。⒊被上訴人以正確率作為社群媒體分析程式成效之判斷標準，不符合專業作法且有誤導之嫌，無法真實反映社群媒體分析程式判讀分析之實際成效。⒋以102年舉辦之推文情感分析國際評比所使用之成效數值F檢視社群媒體分析程式成效數值為0.4034，而參賽之34隊的F值超過0.4043，最高達0.6902，其中一非學術機構團隊之成效為0.6486，故社群媒體分析程式成效數值未達當時一般專業水準。⒌社群媒體分析程式根據top、high q-uality等情感詞彙對整句做判斷，沒有進一步瞭解各該情感詞彙在修飾什麼，所以無法為正確分析等語，提出系爭分析報告影本及光碟（原審卷4第111至157頁）為證。㈡社群媒體分析程式係上訴人向訴外人IBM Singapore Pte.Ltd.
購買之授權程式商品，依之㈢，被上訴人未就使用該商品所得出之觀感分析正確率負任何保證或擔保責任。工作說明書所附「SUPPLEMENT LICENSE FOR PROGRAMS（程式授權書）」於附註「Remark（附註）」第4條亦約明：「The Products inc-lu
ded in this Supplement are subject to and governed
by the terms and conditions of IBM International Prog-
ram License Agreement（本附件所包含之程式商品應適用「IBM國際程式授權合約」) ，有上訴人提出該附件影本（原審卷2第31頁）可稽。而「IBM國際程式授權合約」第8.1條「有限保證」約定：「IBM保證當本『程式』使用於特定運作環境時，符合其規格。本『程式』之規格及特定運作環境資訊，可於本『程式』檢附說明文件（如Readme檔）或於IBM公佈之其他資訊（如通知函）中找到。…IBM不保證本程式之運作不會中斷或全無錯誤，亦不保證程式之一切缺陷均可改正。使用本『程式』所生之結果，由被授權人自行負責。 」（原審卷2第36頁反面）。被上訴人就曾元顯教授所指摘第4、5點關於社群媒體分析程式本身設定之分析方法及使用之效果，不負進行改善之義務。且依之㈣至㈦，被上訴人係客製分析模型，協助上訴人定義社群媒體分析程式中的觀感用詞及封鎖器，以優化分析觀感結果，但未擔保或保證觀感分析正確率多寡，上訴人收受編號4.1文件最終版，未於約定期限內以書面提出修訂要求，視為被上訴人於103年12月13日完成此交付項目，之後上訴人得自行修改、精進分析用詞設定，以改善分析觀感之正確率，是曾元顯教授所指摘第1至3點關於社群媒體分析程式之分析模型問題，不得認為係被上訴人所完成與社群媒體分析程式相關之交付項目存在之瑕疵。㈢按兩造於修訂書約定：「The payment obligations of co-mp
leted milestone under this IPP are not cancellable an
d may not be terminated. Payment shall be made with-
out deduction or setoff of any kind. Unsatisfactory i-
tem performance for any reason shall not excuse HTC f-
rom it's obligations to make full payments under thisSection 1.8.(本IPP所定按完成之里程碑所生之付款義務不得被撤銷或終止，亦不得以任何方式扣除或抵銷付款。若僅因不滿意某些項目之履行，不論原因為何，上訴人均不得免除依本第1.8節所定全部付款義務。）」（原審卷1第127頁反面；原審卷4第300頁），於修訂書約定：「The payment obligat-i
ons of completed milestone under this Addendum are n-o
t cancellable and may not be terminated. Payment sha-l
l be made without deduction or setoff of any kind. U-nsatisfactory item performance for any reason shall n-o
t excuse HTC from it's obligations to make full paym-e
nts under this IPP.(本修訂書所定按完成之里程碑所生之付款義務不得被撤銷或終止，亦不得以任何方式扣除或抵銷付款。上訴人不得以其不滿意某些項目之履行為理由，拒絕依I-PP約定支付全部款項。）」（原審卷1第133頁；原審卷4第307頁）。是上訴人依約不得以其不滿意社群媒體分析程式所分析觀感正確率結果，請求減少價金或拒絕支付。
㈣綜上，上訴人抗辯被上訴人交付之社群媒體分析系統存在觀感
分析正確率過低之瑕疵云云，為不可採，則上訴人執此主張解除減少價金、酌減價金或拒絕給付價金，均不合法。
五十四：綜上所述，被上訴人依系爭契約及民法第233條第1項、第203條規定，請求上訴人給付附表所示本息部分，洵屬有據，應予准許；逾此部分之請求（除減縮及確定部分外），為無理由，應予駁回（被上訴人先位之訴一部有理由，即無庸就備位之訴為論斷、裁判，附此敘明）。從而原審就超過上開應予准許部分，為上訴人敗訴之判決，自有未洽，上訴意旨指摘原判決此部分不當，求予廢棄改判，為有理由，爰由本院廢棄改判如
主文第3項所示。至於上開應准許部分，原審為上訴人敗訴之判決，並無不合。上訴人仍執陳詞，指摘原判決此部分不當，求予廢棄改判，為無理由，應駁回其上訴。又依前開所示減縮部分，諭知如主文第1項所示。
五十五：本件事證已臻明確，兩造其餘之攻擊或防禦方法及所用之證據，經本院斟酌後，認為均不足以影響本判決之結果，爰不逐一論列，併此敘明。
五十六：據上論結，本件上訴為一部有理由、一部無理由，依民事訴訟法第450條、第449條第1項、第79條，判決如主文。中 華 民 國 110 年 11 月 23 日
民事第二十一庭
審判長法 官 翁昭蓉
法 官 鍾素鳳法 官 羅惠雯正本係照原本作成。
被上訴人不得上訴。
上訴人如不服本判決，應於收受送達後20日內向本院提出上訴書狀，其未表明上訴理由者，應於提出上訴後20日內向本院補提理由書狀（均須按他造當事人之人數附繕本）上訴時應提出委任律師或具有律師資格之人之委任狀；委任有律師資格者，另應附具律師資格證書及釋明委任人與受任人有民事訴訟法第466 條之1第1項但書或第2項所定關係之釋明文書影本。如委任律師提起上訴者，應一併繳納上訴審裁判費。
中 華 民 國 110 年 11 月 23 日
書記官 張淑芬