網際網路智慧型稅務代理之研究

(1)

I

網際網路智慧型稅務代理之研究

計劃編號：NSC 89-2416-H-004-038

執行期間：88 年 8 月 1 日至 89 年 7 月 31 日

處理方式

□ 可立即對外提供參考

□ 一年後可對外提供參考

□ 二年後可對外提供參考

楊建民

博士

國立政治大學資訊管理研究所

中華民國八十九年十月

(2)

摘要

以現代企業化經營管理之精神，建立以顧客為導向的現代化政府，將民眾視為政府的顧客來服務，是現代國家政府革新的主軸。近年來，資訊科技進展神速，歐美日等先進國家為提高其國際競爭優勢，相繼推動「國家資訊通信基本建設」（National Information Infrastructure），並規劃運用網路構建「電子化政府」，作為提升政府效率及便民服務的重點。納稅是國民應盡的義務，每年二、三月綜合所得稅申報時期，往往成了大多數國民的頭痛時間。有鑑於此，財政部於 1998 年 3 月開始試辦納稅義務人透過網路申報綜合所得稅。然而，網路報稅服務的推展，應不僅止於提供一個新鮮的報稅介面而已；而應針對整個稅務處理，包括課稅（納稅）資料的蒐集、申報、查核、繳納、退補稅等整體之作業流程，從基本上加以重整、改造，以創造一個完善的稅務處理環境，達到真正便民服務的目的。

近年來，智慧型代理者（Intelligent Agent）簡稱為 Agent，引起了許多學者的研究興趣，並廣泛地應用到分散式系統、資訊擷取、電子商務與人工智慧等領域。網際網路全球資訊網（World Wide Web, WWW）的發展，為 Agent 的研究創造了一個有利的發展空間。

(3)

III

都能得以充分發揮。本研究在 Web 的環境下以 JAVA 語言及 IBM 所開發出來的 ASDK（Aglets Software Development Kit）為工具發展智慧型行動稅務代理系統。本系統能主動的為納稅義務人，從網路上蒐集相關的納稅資料；對不同的稅令，做出最佳的節稅回應；同時，納稅人還能在自己的電腦上整理相關資訊，提供納稅人進行帳務處理的工作。期能提昇網路報稅效率及便民服務水準，進而有助於知識經濟時代電子化政府之建構。

(4)

表目錄

表 2-1 現行綜合所得稅申報處理流程之不合理處

………11

(7)

VII

圖目錄

圖 2-1 網路報稅架構圖

………12

圖 3-1 Mobile Agent 的行為模式

………25

圖 4-1 網路上進行電子交易或服務之步驟

………34

圖 4-2 本系統之基本流程

………36

圖 4-3 Aglet 整體架構

………42

圖 4-4 Aglet 的組成元素

………42

圖 4-5 Aglet 的生命週期模式

………44

圖 4-6 Aglet 基本訊息介面

………44

圖 4-7 本研究稅務代理系統架構

………46

圖 5-1 Tahiti

………49

圖 5-2 詢問 JVM 的位置

………50

圖 5-3 選擇安裝路徑

………

51

圖 5-4 伺服端正執行 PokiMon

………52

圖 5-5 輸入帳號及密碼

………52

圖 5-6 確認是否繼續

………

53

圖 5-7 基本資料

………53

圖 5-8 扶養親屬

………54

圖 5-9 所得資料

………54

圖 5-10 自行新增

………55

圖 5-11 列舉扣除

………55

圖 5-12 扣除額

………56

(8)

圖 5-13 大陸地區所得稅扣抵

………56

(9)

(10)

第一章緒論

第一節研究背景與目的

以現代企業化經營管理之精神，建立以顧客為導向的現代化政府，將民眾視為政府的顧客來服務，是現代國家政府革新的主軸。近年來，資訊科技進展神速，歐美日等先進國家為提高其國際競爭優勢，相繼推動「國家資訊通信基本建設」（National Information Infrastructure，NII），並規劃運用網路構建「電子化政府」，作為提升政府效率及便民服務的重點。行政現代化是引領國家在全球競爭力競賽中保持領先的主要動力，政府必須以嶄新的觀念及作法，從管理、制度、科技乃至於行政文化層面，全面推動行政現代化，不斷創新改造，提高行政效率及服務品質，以提高國家競爭力。同時配合國家資訊通信基本建設之推展，建構「電子化政府」，推廣網際網路各項應用，以創造競爭優勢。納稅是國民應盡的義務，每年二、三月綜合所得稅申報時期，往往成了大多數國民的頭痛時間。扣（免）繳憑證的寄送與蒐集，因應稅法修正之節稅策略採用，如何避開擁擠的人潮申報繳納方式，以及往返稽徵機關曠日費時之減省等等，在在都困擾著納稅義務人。稅務單位也往往因而招致民怨，成為眾矢之的。

(11)

2 認無誤後，再經由網際網路線上傳送至國稅局，以完成申報手續。並為簡化申報手續，網路申報者，無需將扣（免）繳憑證寄國稅局。 1999 年 3 月開始正式辦理網路申報繳稅服務，如今已實行了兩年。雖然已有許多民眾曾經利用網路報稅，但這項服務到目前為止還是存在著一些問題與麻煩。況且並非人人都會上網，都曉得申報的手續與流程，何況如今又將整個動作都搬上網，更牽涉到了另一個也是非常重要的問題：安全性。總而言之，現行網路報稅還不是很成熟，勢必有進一步研究的必要。根據周冠中[1998]針對網路上電子報稅服務的調查顯示，目前採用網路報稅的原因，主要是好奇（佔 35％），其次為往返稽徵機關費時，網路報稅程序簡便，以及公務人員態度不好等。因此，網路報稅服務的推展，應不僅止於提供一個新鮮的報稅介面而已；而應針對整個稅務處理，包括課稅（納稅）資料的蒐集、申報、查核、繳納、退補稅等整體之作業流程，從基本上加以重整、改造，以創造一個完善的稅務處理環境，達到真正便民服務的目的。流程再造的概念，不僅可應用於企業當中，也可應用在政府的改造上。Hammer ＆ Champy[1993]首先提出流程再造的觀念，認為組織應從「根本上重新思考，徹底翻新作業流程，以便在成本、品質、服務和速度等重要的關鍵績效上，獲得大幅度的改善」。然而，要能夠拋卻過去的包袱，重新再造流程，而達到徹底改善的目的，必須藉重資訊科技的應用[Talwar, 1993]。由於新一代資訊與通信科技突破性之發展，不僅顛覆了許多傳統的企業流程，更創造出許多新的功能與新的服務。尤其是近年來網際網路電子商務的迅速發展，將政府機構、學校、企業、家庭以及休閒娛樂設施等全部串聯在一

(12)

起，形成一高效能的資訊網路，使得無論政府施政抑或企業經營，都面臨了前所未有的巨大挑戰。

近年來，智慧型代理者（Intelligent Agent，簡稱為 Agent）引起了許多學者的研究興趣，並廣泛地應用到分散式系統、資訊擷取、電子商務與人工智慧等領域。基本上，Agent 是一具有智慧的電腦軟體，可透過感應器（Sensor）認知環境，學習並更新所具備的知識，並藉由作用器（Effector）對環境作出適當的回應；以及能主動的溝通或協助其他的 Agents。

網際網路全球資訊網（World Wide Web，WWW）的發展，為 Agent 的研究創造了一個有利的發展空間。藉由 WWW 跨平台的特性，Agent 的自主移動、溝通、合作等特性，都能得以充分發揮。而做為一個智慧型的稅務代理，必須要能主動的為納稅義務人，從網路上蒐集相關的納稅資料；對不同的稅令，做出最佳的節稅回應；同時能與稽徵機關的核稅代理進行溝通，以完成退補稅的程序；或與其他金融機構的收稅代理，完成繳稅的動作；最後還能整理相關資訊，提供納稅人稅務、帳務處理的相關資訊。綜上所述，本研究主要的目的可以分為以下數端： 1. 以流程再造之觀點，探討在網際網路上綜所稅申報繳稅之流程。 2. 以 WWW 平台為基礎，建構智慧型稅務代理資訊系統架構。 3. 發展綜所稅申報繳稅智慧型代理，並在網際網路上進行模擬測試。

(13)

4

第二節本文結構

本節大致描述本研究的章節架構。第一章為緒論，包含了研究背景、研究目的，以及本報告之結構。第二章為網際網路線上報稅現況之探討，我們將探討電子化政府、稅務處理與流程再造、申報處理流程之現況以及缺失，最後再說明目前網路線上報稅之架構及流程。第三章網為際網路智慧型代理系統。在本章中我們將廣泛地探討網際網路智慧型代理系統，並在第二節中進一步探討行動代理；然後在第三節中，討論用 JAVA 語言開發代理系統及其優缺點。第四章研究設計與方法，主要將針對綜合所得稅申報流程探討 Agent-based 系統之架構，並導出本研究之稅務資料蒐尋代理、節稅代理以及帳務代理。然後在第二節中探討本研究所使用之工具 ASDK（Aglets Software Development Kit）。最後，再發展出本研究之架構與各種稅務代理。

第五章系統與實例說明，解釋本研究代理系統的安裝及操作步驟，並提醒使用者應該注意的地方。

第六章結論與建議，則針對線上報稅提出整體性的建議，以及未來研究方向，俾使後續研究者能有一個完整的參考與指引。

(14)

第二章網際網路線上報稅現況之探討

第一節　電子化政府

關於電子化政府之相關文獻，大部分集中於探討政府政策法令執行與業者之間的關係，政府本身的行政成效評估，以及資訊公開與安全等相關問題的探討。在探討此問題之前，我們必須先了解電子化政府的涵義。行政院研考會 [1997] 提出之「電子化政府」（ Electronic Government）係指政府機關運用資訊與通信科技，並透過不同資訊服務設施（包括電話、網際網路、共用資訊服務站等），在企業及民眾方便的時間與地點，提供各種自動化服務之總體概念。因此，「電子化政府」最重要的內涵及精髓是建構一個「虛擬機關」（Virtual Agencies），使得民眾及各界可以很快速地取用整合性的資訊及服務，而不是要經過層層關卡審核的作業方式。亦即在資訊科技的協助下，電子化政府能依據各界的需求、使用的形式、要求服務的時間及地點，提供各種不同的服務。葉俊榮[1997]舉出電子化政府的具體推動項目包括： 1. 建置跨機關服務資訊系統，配合公文電子交換之推廣，藉連線交換資訊，避免重覆輸入資料，提高行政處理效率。

(15)

6 3. 針對民眾多元化的需求，透過網際網路及共用資訊服務站等，提供民眾資訊、通信及線上申辦等互動式的服務。 4. 建置電子商務的環境，推動電子報稅、電子簽審、電子支付、電子採購等應用，並由政府機關提供企業界，諸如國際貿易等電子資料庫的應用，尤其是對中小企業提供各種電子化服務，以提高其競爭力。 5. 充實網際網路上的資訊資源，建置人口、土地等十八項公用資料庫，建立取用公用資料庫之各類電子閘門，透過網際網路以線上方式對外提供資訊服務。 6. 逐步減少書證的使用，改由政府機關從網路上查驗，以減少民眾往返不同機關間申辦各種書證，以發揮電子化政府的功效；整合建立連線申報環境，運用檔案傳輸、電子文件交換等技術規劃以電子化表格及文件辦理申報，並配合身分證換發為磁卡作業，研究建立線上身份核對作業模式。 7. 推動「課股有信箱、訊息瞬間通」計畫，普及電子郵遞的運用。

(16)

第二節　稅務處理與流程再造

財政部賦稅改革委員會（賦改會）於 1989 年提出綜所稅作業流程之檢討與改進。其改革的方式已開始著重媒體申報來提高作業效率，並注意到如何協助納稅人稅額核算與扣繳調整；以及減少退稅案件，改善退稅流程等問題。楊建民及劉美鳳[1990]運用專家系統模式，發展出一綜合所得稅申報諮詢專家系統，以幫助納稅義務人熟習申報程序，並合法的應用節稅技巧，達到減省稅負之目的。該系統係以 Prolog 語言發展，採逆向推理（Backward Reasoning）方式進行推論，並可在一般個人電腦或區域網路上執行。楊建民[1991]研究利用人工智慧語言，將營利事業所得稅申報相關之租稅、法令淬取出來並建構成專家系統，以輔助企業進行妥適之租稅規劃。本研究提出一套有系統的方法，將繁複的租稅法令判例，以及租稅專家的知識、經驗予以型式化、結構化，有助於租稅專家系統知識庫之建立。楊建民、林妙雀及林震岩[1991]針對傳統以稅目分立所發展之系統，造成稅務資料產生重覆衝突，資料蒐集不易，以及無法充份加以利用於查核、勾稽等問題，提出整體稅務資訊系統架構。整合所得稅、財產稅和交易稅之課稅資料以掌握稅源；並利用發票、扣繳、財產交易及捐贈等子系統，為歸戶、勾稽、查核等之經緯；以提昇稅務資訊應用層次，並突破當前稅務處理之困境。

(17)

8 之力量，從頭開始設計新的流程，一切重新開始。 Harrison ＆ Pratt[1993]則強調資訊科技在流程再造上的重要性，透過資訊與通信技術的發展，來改變許多傳統上認為不可能的事，因此必需應用資訊科技才能來達成流程改造的理想。胡志榮[1995]運用再造工程的概念，提出綜所稅稽徵制度免申報的改造構想。稽徵單位可由納稅義務人的扣（免）繳資料，及相關資料，即可核算納稅義務人應繳之稅額。劉玉玲[1998]提出綜所稅「免申報電子納稅」。亦即由稅務單位根據課稅資料，直接核算出應納稅額，供納稅義務人參考。然而，本方式改變了綜所稅由納稅人申報，稽徵機關核定之基本精神。

(18)

第三節綜合所得稅之申報處理流程現況

我國現行綜合所得稅申報處理流程，起於納稅義務人與扣繳單位對於結算申報書與扣（免）繳憑單的申報，終於年度所得資料核定統計。流程內容包括以下兩個重要部份：一、所得資料蒐集所得資料蒐集是針對綜合所得稅的所得資料進行蒐集，就蒐集方式而言可分為三種：第一種為納稅義務人結算申報書中的所得資料，其來源為根據扣繳單位所寄發之扣（免）繳憑單及其他列舉所得證明文件而得；第二種由扣繳單位扣繳所得申報取得；第三種資料來源則為非扣繳所得資料的蒐集。扣（免）繳所得資料的蒐集主要是針對採就源扣繳方式的納稅義務人所得資料而言，這類的所得來源穩定，蒐集方便，如薪資所得、利息所得等，資料的蒐集來源可由： 1. 納稅義務人的結算申報書申報及其所附扣（免）繳憑單； 2. 扣繳單位扣（免）繳所得申報。非扣繳所得資料指依所得稅法規定在給付時毋須扣繳所得稅，或無法扣繳以及有先行查核必要者之各類所得，由稽徵機關依規定調查蒐集核定其所得額。非扣繳所得資料的蒐集就不如扣（免）繳所得資料方便，因其資料的發生較不固定，也沒有統一的憑證，如執行業務所得、租賃權利金、自立耕作所得、財產交易所得等，其資料的蒐集要依賴相關政府單位所得資料的通報及稽徵機關本身的

(19)

10 各類資料蒐集後，稽徵機關要先就地進行資料先期的審查與整理，如檢查納稅義務人的申報書內容與所附憑證是否相符，書面資料的分冊編號與裝訂等，以便將整理好的資料送交財稅資料中心進行資料的縮影登錄。二、所得資料建檔依據所得稅法規定，各項所得資料需予保存，為改進資料保存方式，方便查詢調閱，現行採縮影方式將各項所得資料縮影存證。原始資料建檔採就地處理及集中處理並行原則，以收各種資料間相互勾稽與制衡的效果，主要資料建檔的工作由財稅資料中心負責，資料建檔主要目的在運用電腦將龐大複雜的課稅資料建檔，以提供後續所得歸戶、交查核定、發單作業使用，需建檔的資料包括各類所得資料及結算申報書。胡志榮[1995]將現行綜合所得稅申報處理流程不合理之處整理如表 2-1 所示：

(20)

表 2-1 現行綜合所得稅申報處理流程之不合理處現行流程之不合理處 [1] 綜合所得稅申報與核定結構的不合理 [2] 作業處理時間太長整體流程分析 [3] 資料成長快速，稽徵機關現有人力已不勝負荷 [4] 納稅義務人未收到扣（免）繳憑單，以致漏報所得 [5] 納稅單位需花費人力時間更正扣（免）繳資料、結算申報書之錯誤 [6] 未申報案件的開徵遠落後於收件年度 [7] 納稅義務人習慣於結算申報截止前數日才申報，使得稽徵機關的作業負荷明顯不均 [8] 扣（免）繳資料重複建檔 [9] 一般性扣（免）繳憑單、結算書數量龐大，人工作業負荷程度過高，且作業時間過長 [10] 所得核稅時間太晚 [11] 先申請了退稅，但經核定後又變成補稅之類案件階段流程分析 [12] 民眾查詢相關資料，稽徵機關限於資料有限無法立即答詢

(21)

12

第四節　網路線上報稅架構及流程

網路線上報稅可配合行政院電子化政府施政目標，達成縮短作業流程，減少資料處理人力，擴增民眾接觸政府之管道，並能提昇便民服務之水平。網路報稅架構如圖 2-1 所示：圖 2-1 網路報稅架構圖納稅義務報稅流程: 1. 納稅義務人透過網際網路，進入承包廠商 Web 主機隻網路報稅首頁，下載並執行報稅軟體。 2. 納稅義務人可於承包廠商報稅資料庫中查詢稽徵機關所提供之相關資料。納稅義務人填寫或修改報稅資料，經過報稅軟體執行前端審核之動作後，在將資料傳送給承包廠商上報稅共用中心之報稅主機。 3. 承包廠商在伺服器端作一初步線上審核動作，若審核無誤，則將報稅資寫入資料庫中。若審核時發現問題，則回傳錯誤訊息即向

(22)

說明給納稅義務人，要求納稅義務修改申報資料後重新傳送。 4. 承包廠商回傳給納稅義務人網路申報成功之訊息（含對該訊息之數位簽章）以及案件序號，納稅義務人可依據回傳訊息驗證承包廠商數位簽章之合法性，並可隨時利用此一序號到報稅主機資料庫中查詢自己的申報狀態。 5. 納稅義務人將配合網路申報之必要附件寄送所屬稽徵機關。 6. 承包廠商定時以批次作業方式將最新申報版本之報稅資料送至財稅資料中心轉送各地稽徵機關。 7. 若納稅義務人網路申報無誤，已收到申報成功訊息，在申報期限截止前，仍可透過網路更正申報資料。承包廠商需將更正資料傳送至財稅資料中心轉送各地稽徵機關，申報資料內以申報時間來區分申報版本。 8. 財稅資料中心及各地稽徵機關進行各稅目後續相關作業。在目前的網路報稅架構下，納稅義務人的相關稅務資料，包括課稅資料與納稅資料，都會暴露在第三者（承包商）的系統中，在安全及隱私上造成了極大的漏洞。本研究將從 Agent 技術來克服上述的問題。

(23)

14

第三章網際網路智慧型代理系統

第一節代理者（Agent）系統

Smith[1994]認為 Agent 通常是比一般程式要精緻得多的電腦程式，並以所具備的知識引導本身的行為。 Wooldridge 和 Jennings[1994]則以描述 Agent 特性的方式來定義 Agents，並提出 Agents 應具有下列四種特質： 1. 自發性（Autonomy）：Agents 無需透過人為的介入，即可自行運作，並控制其自發行為及其內部狀態。社會性（Social Ability）： Agents 透過特定語言，可與人類或其他 Agents 溝通。 2. 回應性（Reactivity）：Agents 能夠認知其所處在之環境，並可對環境的改變予以回應。 3. 主動性（Pro-activeness）：Agents 能主動表現出目標導向（Goal-direction）的行為。 Agents 能對外在環境做出適當的回應。通常 Agents 的資訊處理流程，包括兩個步驟。首先，由外在的環境讀取信息（Messages），然後更新內部狀態（ State ），包括信念（ Belief ）與承諾（Commitment）；然後，再執行目前之承諾，而予所在之環境適當的回應。

許多學者在 Web 的環境下發展 Agent-based 的系統[Davies， 1995]。Web 的環境能讓 Agents 相關的特性如移動、溝通和合作等，得以充份的發揮。Lingnau[1995]，在 Web 環境下，Agents 間利用

(24)

HTTP 作為傳輸協定，提出之 Agent-based 的系統架構，將系統分為 Agent、Agent Server、Runtime Environment 以及 Client 四大部份。茲分述如下：

1. Agent：為系統運作的主體，包括程式（Code）、狀態（State）以及特質（Attributes）三部份。

2. Agent Server：主要的任務在於管理 Agent 產生、移動、溝通、與結果等，以及負責 Agent Servers 間之運作與控制。

3. Runtime Environment 主要負責 Agents 所在主機間之溝通與資源之分配。

4. Client 則係直接面對使用者的介面部分。

Agents 技術的應用層面甚廣，工業應用如程序控制（Process Control），彈性製造系統（Flexible Manufacturing Systems），以及航管（Air Traffic Control）系統等[Jennings ＆ Wooldridge， 1995]。在商業上應用尤其廣泛，例如 Maes[1994]用於資訊蒐尋與篩選（Information Gathering and Filtering），Jennings[1996] 用於企業程序管理（Business Process Management），以及 Chaves

＆ Maes[1996]用於電子商務等等。Agents 技術亦應用於醫療方面，如 Hayes-Roth[1989]的病患監看（Patient Monitoring）， Huang[1996]之醫療照護（Health care）。此外亦用於休閒娛樂方面，如 Wavish[1996]於電腦遊戲（Games），Hayes-Roth[1995]於互動式影劇等等。

(25)

16

第二節行動代理者（Mobile Agent）

自從 1992 年全球資訊網瀏覽器（Web Browser）開發成功之後，網際網路（Internet）即迅速地成為新世紀的寵兒，過去使用區域網路為溝通媒介的企業或組織相繼改用網際網路為連繫管道，分散式的資料處理蔚為風氣。目前絕大部分的分散式系統皆以主從架構（Client／Server）為主，在網路上呼叫、執行遠端的程序或物件。然而此種連接方式必須在 Client 端與 Server 端之間的相連持續的情形下方能運作，而且常常需要在彼此之間傳遞大量的資料，在今日網路的硬體建設趕不上資料量大幅成長的大環境現實之下，不但網路斷線的情形屢見不鮮，嚴重的網路塞車問題也妨礙了巨量資料的傳輸。此外，近幾年各行各業漸次體會到結盟或上中下游整合的必要性，不同企業或組織間資訊系統的整合變成一件事關重大，卻又難以下手的龐大工程。然而什麼方法可以解決上述的問題呢？有一個新的網路運作的範型（Paradigm）正逐漸成熟之中，那就是所謂的行動代理（Mobile Agent）技術。它的出現，意謂著一種新的網路運作模式的誕生。

3.2.1 行動程式碼（Code Mobility）

行動程式碼（Code Mobility）可以非正式的定義為「動態改變程式碼和其所執行地點之間的關係」。換句話說，程式碼所執行的地點是可以動態改變的。這樣子的定義聽起來很容易讓人聯想到在分散式系統中所討論的「行程遷移」（Process Migration）。

(26)

在分散式系統的研究課題中，所謂的行程遷移（ Process Migration），也就是執行中行程的遷移行為。這種行為允許作業系統中的一個行程（Process）從原先執行的機器，遷移到另外一台機器去，並且若無其事的繼續執行。要實踐這種行為，可以想見需要處理十分複雜的問題。因為必須將整個的執行環境像是開啟檔案的所有 handle、環境變數等等的轉移，而且遷移到另一機器之後，必須能夠正確的繼續執行，就像什麼事都沒有發生過一樣。行程遷移的目的大抵上多是為了：1.負載平衡（Load Balancing）； 2.遷移到更適合（或說程式更喜愛的）的軟硬體。行程在多台機器之間遷移可以讓多台機器之間的負載儘量的平均，使資源的使用可以更加的均衡，平均的效能也應該可以提高。至於遷移的策略以及演算的方法，目前已有為數不少的論文在討論這個問題。因為軟硬體偏好的遷移行為則有可能發生在像是一個分散式的系統中，並不是每台機器都裝有某一硬體或軟體，但是這個系統希望程式在任一台機器開始執行之後，透過行程遷移到提供執行所需資源（軟體或硬體）的機器之上，讓程式感覺不到這背後的一切，就像是一開始執行的機器就擁有這些資源一樣。大多數的行程遷移的機制都希望提供一個透明化的環境，也就是不希望，也儘量不允許程式設計者接觸、控制到行程遷移的行為。程式設計者無法知道，也無法分辨執行中的行程是否經歷過遷移。

(27)

18

物件遷移（Object Migration）與行程遷移相似。這種機制是在不同的 Data Space 當中搬移 Data Object。它和行程遷移一樣，都是定位於應用在一些鬆散連結（Loosely-coupled）、小範圍的分散式系統。

一般所謂的行動程式碼系統（Mobile Code Systems）則企圖應用在大範圍的環境中，它有幾個性質： 1. 行動程式碼可應用在網際網路上。 2. 程式設計包含執行地點之資訊（Location Aware）：在行動程式碼系統中，不隱藏程式執行地點的相關資訊，反而在許多的應用中，程式執行地點成了該應用的重要資訊。 3. 程式的移動是受程式設計者的控制的：不過這並不意謂著程式設計者可以控制，及必須控制所有遷移細節性的過程以及行為。程式設計者的責任應該是規範程式碼移動的策略以及規則。

4. 程式的移動不全然只為了負載平衡：Mobile Code Systems 還有其它的目的。像是客製化服務（Service Customization）、程式功能自動執行（Dynamic Execution of Application Functionality）、自發性（Autonomy）、容錯能力（Fault Tolerance）以及支援離線運作（Support for Disconnected Operations）。

行動程式碼的技術可以應用在網際網路上，表示它具有很好的延展性（Scalability），並不需要特別刻意的設計，便渾然天成。而「因地制宜」（Location Aware）的性質，則有別於許多分散式系統的架構。前面談到行程遷移時，有提到大多數行程遷移的機制都希望提供一個透明化的環境，將程式設計者隔絕於這些行為之外。程

(28)

式設計者在設計程式時，並不會去、也不需要去考慮到程式遷移的行為，而將這些行為的觸發以及執行的工作交付底層的系統。任何程式，不需特別的設計，便能享受到行程遷移所帶來的利益。就像一些分散式物件的系統，希望本地端執行的程式能夠使用遠端的物件，就像使用本地端的物件一樣。提供一層透明化的界面來達到這樣的效果是很美的一件事情，美在程式設計者不需在乎分散式系統中，實際上不同節點之間地點資訊的差異。整個分散式系統就像是個處理能力更快、擁有資源更多的一個單一系統。但是，行動程式碼系統卻有著截然不同的系統觀。對行動程式碼系統來說，執行地點的認知是相當清楚，而且是必須的。譬如我們可以設計一個具有行動程式碼性質的程式，它的任務是搜集 WWW 上關於運動娛樂的文章。對它來說，移動到了那個 WWW 伺服器應該是十分明確並且十分重要的訊息，而且還可以輕易的達到整個網際網路的層級。程式設計者不必身陷於程式碼移動的實作細節當中。程式碼的移動，整個系統應該提供一層程式界面，而程式設計者之任務在於提出移動的策略以及規則。如何移動，應是視應用而定，並且將會深深的影響程式所表現出來的效能當中。程式的移動除了負載平衡之外，還可以帶來更多額外的好處。例如： 1. 客製化服務（Service Customization）：在網路管理研究領域中，有人提出“Management by Delegation”的概念，也就是指派式的管

(29)

20 轉。傳統的 Client／Server 式的網路管理架構，網路管理的應用程式透過網路管理的通訊協定要求網路設備之上的 Agent 提供服務。在這種架構之下，網路管理應用程式是 Client，而網路設備上的 Agent 程式則是 Server。Agent 程式提供一組事先定義好的服務，像是提供各種網路設備的狀態、回報網路設備所發生的特殊事件（例如網路斷掉）等等。但是無論如何，所能提供的服務終究必須經過事先的定義，而很難動態的改變。而訂製的服務就像是在網路設備上提供執行程式的環境，網路管理應用程式需要什麼樣的服務，就自己將程式碼送到網路設備上執行，這樣一來，網路設備只需內含一個執行程式碼的核心，便可以迎合各種應用程式的需求，不需要事先定義自己所提供的服務，而且應用程式所需的服務可以動態的改變。

2. 程式功能自動執行（ Dynamic Execution of Application Functionality）：這一點，可以從上述的 Management by Delegation 的例子中明白。 3. 自發性（Autonomy）：每個會移動的程式碼都可以視為一個具有自主能力的個體。就這點來說，就有極大的思考空間。因為這種具有自主能力，可以移動的程式個體，就像是具有生命般的可在網路上遊走。賦予它的智慧愈高，也許就能產生愈大的效益。縱使是具自主能力的個體有其獨立性，但是也提供了不同的個體之間的合作可能性。透過不同個體之間的彼此合作，也能發揮神奇的功用。一隻螞蟻的力量微不足道，但數量極多的萬蟻雄兵卻能扛起一頭巨象，合作之用大矣。

(30)

Disconnected Operations）：這兩種性質有些相關。有些行動程式碼系統是針對頻寬不足甚至是通訊環境不穩定的網路（像是無線通訊網路）而發展的。當程式碼移動到某一節點，該節點對外的連線卻斷了之後，程式仍可繼續存活，待該節點重新恢復連線之後，再進行移動的動作。這樣的性質可以讓行動碼的應用程式容許網路某些節點發生斷線事故，卻仍然可維持程式的正常運行。相似地，這個性質也讓 Mobile Code 的應用程式可以達到 Disconnected Operation。舉例來說，使用者利用一 Notebook 加上無線通訊設備連上網路，他需要執行一個程式，必須花費一段為時不短的時間和使用者進行互動，完成之後，將結果送回網路之上。則當程式碼進入使用者的 Notebook 之後，便可離線，待互動行為完成後，才重新連線回到網路之上。對於節省連線的費用，或是容許不穩定的網路環境，都提供了解決之道。而了達到行動碼的目的，有一些系統或是架構被實作出來，這些系統可稱為 Mobile Code Technologies 。我們可以發現， Code Mobility 的核心意念十分的簡單，也就是「程式碼所執行的地點是可以動態改變的」。而在這個意念之下，分別出現了四種 Design Paradigm，分別是： 1.Client ／ Server （ CS ）； 2.Remote Evaluation （REV）；3.Code On Demand（COD）；4.Mobile Agent（MA）。他們並且強調所謂的 Design Paradigm 不必然的對映某些特定的 Mobile Code Technologies，而一個 Mobile Code Technology 事實上也不全然的只能實作特定一 Design Paradigm 。以下僅對本系統所使用的技術－Mobile Agent 來作介紹。

(31)

22 一個所謂的 Mobile Agent 擁有知識，也擁有資源，但是卻缺乏了位置因素，也就是缺乏不可移動的資源，而這些資源只有在一些特定的地點才有，所以 Mobile Agent 必需具備遷移的能力，移動本身的程式碼（如何完成工作）以及可移動的資源。Code On Demand 和 Mobile Agent 都可以算是具備實質上的程式碼移動行為，它們之間最大的差異應該是：在 Code On Demand 的架構之下，程式碼通常只移動一次，將程式碼送給程式碼的需求者之後，程式碼就不在移動了，算是定居下來。但是 Mobile Agent 卻是天生漂泊不定的浪子性格，通常為了達成一項工作，必須遊走數個特定地點。需要特別注意的是 Mobile Agent 不僅遷移程式碼，更包括了自身的狀態。一個特定的應用，不見得和某一特定的 Design Paradigm 牢牢地綁在一起。我們可能可以利用多種 Design Paradigm 都足以完成一個特定的應用，但各種不同的 Design Paradigm 在優劣上卻可能有高下之分。如何為自己要解決的問題尋求一個較佳的 Design Paradigm 一個應用 Mobile Code 技術上的核心課題，這將有賴於設計者對於問題本質的洞悉以及各技術應用的評估。評估的項目自然因人而異，諸如：對網路流量所造成的影響，執行效率，容錯能力，擴充性（Extensibility），延展性（Scalability）等等。

3.2.3 行動代理者的定義

要瞭解什麼是 Mobile Agent，首先得知道 Agent 的定義。Agent 和一般程式有何不同？這問題在學者間已持續辯論了好幾年，基本上我們可以把它下個較寬鬆的定義為：「由人類指定工作內容與作業限制，代替人類進行所指定工作的軟體程式」。Agent 依照其環境的本質可分為三種[Clements ＆ Papaioannou＆Edwards，1997]：

(32)

1. 目的導向型（Goal Oriented）：Agents 的行為並非只是單純地對環境的刺激產生反應而已，尚有其本身的任務與目的。

2. 溝通型（Communicative）：可和其他 Agents 互相溝通的 Agents。

3. 移動型（ Mobile ）：可以從一台主機移動到另一台主機上的 Agents。

而 Mobile Agent 其實便是一種具有移動能力的 Agent 物件或程式。

更詳細一點來說，Mobile Agent 可以如下解釋：

Mobile Agent ＝ Mobile Code ＋ Agent

Agent： 代理者程式，通常能接受使用者的命令，根據命令去執行大量的工作; 或者其本身具有 Autonomous（自發性），透過程式的人工智慧（AI）或決策樹在執行時期（Runtime）自行判斷應執行的程序。 Mobile Code： 行動碼是一種能讓執行中的程式由其所處的執行空間中遷移至另一執行空間中執行（行程遷移技術），一般實際上多運用於產生能在執行時期遊走於網際網路中的程式。

JAVA Mobile Agent 技術並非 JAVA 的標準套件，而是由一些團體自行開發的，但是基本上這是一個以遠端方法呼叫（ Remote Method Invocation，RMI）為基礎的系統，當 RMI 的技術，搭配上物件串列化的機制，Mobile Agent 的系統就逐漸被展現出來。

(33)

24

Mobile Agent 當然不可能任意的遊走於何一台主機中，所有要支援 Mobile Agent 的主機上皆必需先建構出一個 Mobile Agent Runtime Environment（通常是利用執行一個 JAVA Application 來產生），當基礎的環境建置好了之後，系統中運行的 Agent 即能執各類動作，而各 Runtime Environment 間利用物件序列化（Serialization）來達成程式碼實體（Code Instance）的遷移，利用類似 RMI 的機制來形成遠端參考（Remote Reference）以利實現遠端控制。

在元件化的設計理念之下，DCOM／COBRA／JAVA RMI 等架構，皆實現了讓一程式的各元件能夠分散在數個系統中運行，讓程式的各個元件能在其最適當的主機中執行，而 Mobile Agent System 進一步的擴展此一概念，讓程式中的各元件不再被限制在一固定的主機之中，換句話說 DCOM／COBRA／RMI 的系統架構是一種靜態架構，而 Mobile Agent System 則是一種能在執行時期作適時決策或轉變的動態架構，在此一特性下，系統將更容易實現負載平衡及容錯等機制。以下是對 Mobile Agent 更嚴謹的定義： Mobile Agent 並不侷限於只能在開始執行的系統上動作，最主要的特性就是它可以經由網路將其本身轉移到另一個不同的系統上去繼續動作。這種移動的能力使得 Mobile Agent 能夠與目的地系統上的物件相互溝通，然後在相同的主機上使用這些物件，或是作為網路上的遠端物件[Lange ＆ Oshima，1998]。由上述定義可知，Mobile Agent 的運用前提是網路環境，它可以在四通八達的網路空間中漫游，移動到存放有 Mobile Agent 所需要之資料的主機上，就近進行處理的工作。工作告一段落之後，Mobile

(34)

Agent 帶著其程式碼與已處理過的資料移動到下一台主機上，如此持續到所有工作完成，回到其原來出發的機器為止。圖 3-1 大略描述了 Mobile Agent 的行為模式：圖 3-1 Mobile Agent 的行為模式

3.2.4 行動代理的效益與實務應用上的考量

運用行動代理相對於傳統主從架構有以下優點： 5. 減少網路負載：分散式系統十分倚賴通訊媒介來交換訊息，尤其是使用到安全協定時，造成龐大的網路流量。Mobile Agent 不需要與目標機器持續連線，它允許使用者將指令包裝起來送到彼方的電腦，然後在彼端當場進行交談的動作。Mobile Agent 亦可在遠端主機上就近處理其上存放的大量資料，不像傳統模式須將大筆資料經由網路傳輸到本地端方能進行處理，無形中省去了大量交通量。此外 Mobile Agent 只在移動時才會使用網路傳送資料，而且傳送的只有運算完成的資料及自己本身的程式，消耗頻寬較少。 6. 可克服網路延遲問題：在以網路控制大批需要即時反應的系統之時，例如工廠的眾多機械臂，常會造成網路的遲延。Mobile Agent 為此問題提出了解套的方法，因為它可以從中央主機派送到各機器上，在各機本端直接執行控制指令。 7. 將通訊協定封裝起來：分散式系統的主機需要對外送的資料加上協定用的資料，而在接收資料時則將包含的協定資料解譯。當協

(35)

26 新，很容易會造成延遲現象。Mobile Agent 則可跑到遠端主機，依據其使用的協定建立所謂的「通道」（Channel）。 8. 允許非同步及自主的執行方式：我們可把工作塞進 Agent 內，將 Agent 傳送到各處，在各處自主、非同步地執行。這時我們可先離線，過了一段時間之後再來回收 Agent。 9. 可動態地調適環境：Mobile Agent 具備感測週遭環境進而自行調整的能力。多個 Mobile Agents 可在網路各處維持其最佳的組態，並共同解決特的問題。 10. 天生就具備異質性：網路運算基本上就涵括了各種異質的軟硬體，而 Mobile Agent 一般都和硬體和網路傳輸層是無關的，只與其執行環境有關，故而能夠使系統天衣無縫地整合在一起。 11. 強固且有容錯能力：Mobile Agent 可動態反應環境和事件的能力使得它可輕易建立強固且容錯的分散式系統。當某台主機要關機時會通知正在執行的 Agents，此時 Agents 就會收工並前往其他主機繼續未完的任務。

12. 擴充性：Mobile Agent 容許 Server 和 Client 之間彈性地調整或擴充功能。我們可以動態地注入一個 Agent 程式到 Client 或 Server 端，以彈性地增加其功能。

目前 Mobile Agent 在實務上的應用所面臨的兩大挑戰：可攜性（Portability）與安全性（Security）。由於 Mobile Agent 需在各種異質的網路協定中穿梭，所以最好是以可攜性高的程式語言來撰寫，方能輕易地在 Internet 上暢行無阻；在安全性方面，Mobile Agent 所引起的安全性議題和 Applet 類似，例如惡意的 Agent 可能會趁機竊取

(36)

主機內的重要資料，或是病毒偽裝成 Agent 的模樣，藉機大肆傳染。故針對 Mobile Agent 必須設置安全政策，以防止可能造成的傷害。

3.2.5 行動代理的代表性系統

這裡我們將介紹幾種代表性的 Mobile Agent系統[Klusch，1999]，並比較它們之間的異同。 1. 多語言（Multiple-Language）系統：即能支援由多種不同語言撰寫的 Agents 程式，在同一系統內執行。

1.1. Ara Ara 支援以 Tcl、C／C++及 JAVA 語言所撰寫的 Agents 程

式。Ara 提供一個 go 指令，能夠自動捕捉（Capture）一個 Agent 的完整狀態資訊，並傳送給目標機器，並且從原本 go 時的中斷 點開始在那裏執行。另外 Ara 也允許 Agents 自行在執行時的任 何時間點上檢查（Checkpoint）其內部狀態。與其他多語言系統 不同的是，Ara 為多緒的（Multi-Threaded），Agent Server 及所有語言直譯（Agent 的執行）都在單一一個 Unix 行程內執行，如此雖然較為複雜，但卻大大增進了系統的執行績效。

1.2. D’Agents 也稱為 Agent Tcl，支援以 Tcl、JAVA 及 Scheme 語言， 及靜態（不會移動）的以 C／C++

所寫的 Agents 程式。與 Ara 同樣 提供 go 指令，可捕捉及回復某個移動中 Agent 的完整狀態。不同 於 Ara 的是，只有 D’Agent Server 是多緒的，每個 Agent 都是在不同的行程所執行。現今 D’Agent 常被應用於資訊取得（Information

(37)

28 等語言。不同於 Ara 及 DAgent，Tacoma 沒有自動捕捉狀態的能 力。取而代之的，Tacoma 會在 Agent 要移動時，先產生一個文件 夾，將所有程式碼及狀態資訊包裝進去，然後將此文件夾傳送出 去，目標機器則先啟始其必要的執行環境，再從接收到的文件夾內讀取程式進入點狀態資訊，以開始程式的執行。如此雖增加程式設計師的負擔，卻可快速整合新的語言進入 Tacoma 系統。 2. JAVA 語言系統：幾乎所有純 JAVA 語言的系統都是多緒的，因此都有不錯的執行績效優勢。大部分 JAVA 式的 Mobile Agent 系統都只移動程式碼與所需資料，但不會轉移執行緒的狀態。

2.1. Aglets 由於 Aglets 是本系統的開發工具，因此後面將有詳細的介

紹。

2.2. Concordia 如同其他許多 JAVA 式的 Mobile Agent系統，Concordia

也不具備轉移執行緒的功能。Concordia 主要是針對安全及移動性兩議題所設計的 Mobile Agent 系統。

2.3. Jumping Beans 要載放（host）Mobile Agents 的機器必須執行一

個 Jumping Beans Agency，而 Agency 則可結合多個 Jumping Beans

Domain。每個 Domain 都有一個中央伺服器，負責鑑定 Agencies

能否進入這個 Domain。Mobile Agents 從一個 Agency 移動到另一個 Agency，而 Agents 也可送訊息給其他 Agents；兩種機制都是經由中央伺服器所達成，因此中央伺服器就成為最重要的管理員角色，好壞成敗都由它負責。

(38)

3.1. Messenger 可說是較輕盈的 Mobile Agent 系統，因為它主要適用 可移動的程式碼來建構彈性的分散式系統，而非單只是 Mobile Agent 系統。Messenger 系統的電腦上執行一個 MOS（Messenger Operating System），提供收送 Messenger 物件程式的服務，而 Messenger 物件則以其專屬的 MO 語言所寫成。一此許多可移動的 Messenger，就能夠提供許多不同的服務。

3.2. Telescrip Telescrip 之所以著名乃因其為第一個商用的 Mobile Agent 系統，因此也影響了許多後來的 Mobile Agent 系統。Telescrip 系統在每一個網路上的站台都會跑一個伺服器，而此伺服器則主 要負責維護許多的虛擬場所（Virtual Places）。每一個進入機器執行的 Agent 都會指定其欲進入的場所，而這些場所則負責檢驗 Agents 的合法性，然後授與適當的權限以利其工作。Telescrip 的 Agents 是以一種類似於 JAVA 及 C++的命令式物件導向語言所寫成，然後編譯成 Bytecode 交由每台伺服器的虛擬機器去執行。 Agents 是以如同於 Ara和 D’Agent 的 go 指令來令其移動，各 Agents 之間不論是否位於相同的場所內，都可以互相交換和傳遞物件，甚至呼叫彼此的方法。雖然 Telescrip 具備安全、容錯及效率等優點，但由於 JAVA 的快速竄起，現今市場上 Telescrip 系統卻已不多見了。

(39)

30

第三節 JAVA 語言與代理者系統

JAVA 語言自從 1995 年現身以來，不但快速竄紅，亦已逐漸成為網路應用程式開發的主流。有關 JAVA 一般的介紹及討論可見諸相關文獻。在本節中我們將針對 JAVA 程式語言的特性以及 Agent 的需求，探討其運用於代理者系統開發的適用性。同時將探討 JAVA 語言在代理者系統開發上的優點與缺點。

3.3.1 開發 JAVA-based 行動代理的優點

1. 平台獨立性 JAVA 是設計用於異質環境下運作的語言。為了使 JAVA 程式能在網路上的任何地方執行，JAVA 編譯器所產生出來的是與架構中立（Architecture-Neutral）的 Bytecode，而非不可移植的原生碼（Native Code）。要在某種特定的機器上執行 Bytecode，則需此特定機器的 JRE（JAVA Runtime Environment）來直譯。但 JAVA 原始程式本身及函式庫都是與平台獨立的，因此有利於我們在撰寫 Mobile Agents 程式時，不需知道目的機器的平台為何，便可將此同樣的程式移動到那目的機器上。 2. 安全性 JAVA 的安全架構非常良好，其中的安全管理者（ Security Manager）部份會去檢查所有潛在的不安全動作，如檔案存取及網路連線等，以決定是否某程式有被允許來做這些動作。整體而言，JAVA 安全架構使得某主機若要載放（Host）外來未取得信任的 Agent 可被合理接受，因為它不會也不能破壞此主機，或者存取私密資訊。

(40)

JAVA 的類別載入（Classloading）機制允許虛擬機器在執行時期進行類別載入和定義的工作，這使得各個 Agents 都能有其受保護的命名空間（Namespace），可以安全獨立的執行。

4. 多緒程式設計

Agents 的必要條件之一便是「自主的」（Autonomous），也就是說某 Agent 的執行不受同樣空間中的其他 Agent 所影響；而允許 Agent 在其自己的執行緒內執行，便是達成自製的重要方法之一。JAVA 易於多緒設計，並支援同步機制，使得 Agents 彼此更方便進行互動。

5. 物件序列化（Serialization）

Mobile Agent 的一項特性便是能夠對物件進行「序列化」（Serialize）及「反序列化」（Deserialize），而 JAVA 的內建序列化機制便能做到此點。它不但能夠（反）序列化某物件，更能處理此物件所有參考到的其他物件，以一併進行（反）序列化程序。 6. 自尋（Reflection） JAVA 能夠在載入類別時自動發現其所有的屬性、方法及建構子，此即所謂的「自尋」程序。這使得 Agents 對自己及其他 Agents 都更為了解，也更易於程式撰寫。

3.3.2 JAVA-based 行動代理的限制

1. 資源控制不適當 JAVA 語言系統未提供控制資源消耗的機制，並且對資源的取用

(41)

32 一些視窗，則當此 Agent 被移除或分派至他處時，這些配置的資源並未獲得釋放，因為 JAVA 並沒有方法將這些資源繫結到另外的物件上。 2. 物件參考（References）欠缺保護 JAVA 中某個物件的 public 方法可以被其他任何參考到此物件的物件所取用。正因為沒有對參考行為加以保護，所以某些物件可能比其他物件更能存取較為廣泛的眾多 public 方法；對 Agent 而言則沒辦法直接去監督及控制到底是哪些 Agents 在取用其方法。不過這有一個解決辦法，就是在呼叫者及被呼叫者之間插入一個 Proxy 物件，如此既能做到參考的保護，又能達到位置透明化（Location Transparency）的目的，亦即其他物件不需知道某物件的實際位置，就可透過此物件所屬的 Proxy，來存取此物件。 3. 不支援執行狀態的保存與復原目前 JAVA 還不能夠擷取一個物件所有的執行狀態。如程式計數器（Program Counter）及堆疊內容等狀態資訊，對 JAVA 來說一直都是不變的禁區。因此若 Mobile Agent 程式要能適當地在遠端主機上繼續執行下去，就必須依賴其本身的內部變數值及外部事件來導引它。製作一種嵌入式自動機制（Embedded Automaton）來追蹤記錄 Agents 的移動路線，則可以達成使程式適當地終止及回復執行。在本章中，我們探討了網際網路中智慧型行動代理的意義與特性，以及行動代理的效益與限制，讓我們充分了解到解決網際網路上複雜應用的一個範型。在下一章中，我們將針對網路報稅發展本研究之智慧型行動代理系統。

(42)

第四章稅務代理系統之發展

本研究是探討在 Web 環境下，發展網路上綜合所得稅 Agent-based 之稅務代理系統。在本章的第一節中，我們首先探討 Agent-based 稅務代理系統之架構以及綜所稅申報流程。

本研究稅務代理系統以 JAVA語言及 IBM所開發的 ASDK（Aglets Software Development Kit）工具為主來開發，在前一章中已對 JAVA 語言在代理人系統特性上的優點與缺點做了一番探討。因此在本章第二節中，我們將針對本系統的發展工具－Aglet 之特性、架構與環境作進一步的探討，並說明選擇 ASDK 來發展本研究系統的原因。然後於第三節中提出本研究稅務代理系統之架構，並解釋各模組的功能及彼此之間的交互作用方式。

第一節 Agent-Based 系統架構及綜所稅申報流程

4.1.1 Agent-Based 稅務代理系統架構

在 Agent-based 的架構裡，Web 提供一個環境，讓納稅義務人與稅捐稽徵機構，在網際網路上進行申報、繳納等交易活動，Agent 便要負起納稅人與稅捐單位間的溝通、交易之責任。我們根據 Kalakota ＆ Winston[1996]所提出在網路上進行電子交易或服

(43)

34 消費者行為納稅行為所需之Agent 蒐集商品資訊蒐集納稅資訊 Search Agent Negotiation Agent Order Agent Payment Agent Account Agent 節稅 / 核稅申報繳稅稅務處理帳務處理付費下單比價/ 議價圖 4-1 網路上進行電子交易或服務之步驟在本研究中，我們將網路申報繳納所需之 Agents 整合為三種。其中智慧型資料蒐尋代理（即 Search Agent），負責課稅（納稅）資料之蒐集彙整；智慧型節稅代理（包括 Negotiation Agent 與 Order Agent），負責節稅、申報以及稅捐稽徵機關之溝通與交涉；智慧型稅務代理（包括 Payment Agent 與 Account Agent）主要負責稅款之繳納，以及後續之退補稅與帳務處理等工作。相關之功能分述如下：一. 智慧型資料蒐尋代理系統的設計目標是希望能使廣大的納稅人藉著智慧型代理，達到「報稅不求人」的境界，當然，在網際網路的首頁上，要以現今的技術要求達到如一般應用程式般的親和力，但是本系統秉持著以納稅人眼光為出發點，希望能適用所有沒有電腦背景及專業稅務法規常識的民眾，都能輕鬆上網報稅。因此資料蒐尋代理應具備以下幾種功能：

(44)

1. 本 Agent 首先從主機系統中，取得去年申報民眾的基本資料（包括納稅人､配偶､扶養親屬等戶籍資料）轉入資料庫伺服器，同時也將所有的申報資料（包括︰各項扣繳、非扣繳所得與稽徵機關能掌握的捐贈等），並帶至客戶端。 2. 前面步驟輸入的資料，在後面步驟中若有需要則成為選單以供選擇。如納稅人、配偶及所有扶養親屬姓名，在步驟三、四輸入所得及列舉細項時，即成為選單，只需選擇而不需再一次輸入。每一步驟的切換，皆依照填寫申報書之正常操作程序，一步一步導引，也可以作跳躍式選擇，使生手熟手皆能操作自如。三. 智慧型節稅代理 Agent 系統已內藏各項稅務法規知識，納稅人僅須依各項單據鍵入所得類別及金額，可不依順序也毋需分類，系統自動整理分類、加總，並依法規計算免稅額、扣除額……等，同時為納稅人選擇最佳且最正確的方式。（以未開辦線上報稅前國稅局為例，1995 年度單單因為選擇計稅方式錯誤的報稅戶有 41 萬 5000 多戶，一共多繳了 26 億 7000 多萬的稅額；此數據尚未包括因計算錯誤或填寫錯誤的納稅人。）所以，此節稅代理應包含以下功能： 1. 提供給納稅人便捷的報稅諮詢服務； 2. 協助納稅人正確報稅及有效應用節稅技巧； 3. 藉著 Agent 的執行，使用者能在最短的時間內學習到完整之報稅程序及專家之節稅策略和技巧。

(45)

36 三. 智慧型帳務代理稅務代理負責申報繳納完後可提供納稅人申報書列印及帳務處理，納稅人已不需赴稽徵單位索取申報書且不需填寫，系統可工整列印詳細資料，供納稅人參考驗證。此外，系統利用網際網路 HTML 之超連結特性，提供了三種線上查詢功能： 1. 操作說明：每一步驟皆有圖文並茂之解說。 2. 法規說明：提供民眾對各項法規之說明。 3. 金融機構代號查詢：當納稅人要利用金融機構來代扣（繳）稅款，需知道該金融機構的代號，然而往往存摺上的資訊卻不足，因此系統也提供了一小型資料庫於各中繼站以供線上直接查詢。

4.1.2 綜所稅申報流程

本系統之流程是以綜合所得稅網路申報為依據，模擬實際申報流程，以問答的方式要求使用者輸入資料，再將得到的資料存入資料庫，並根據這些資料，隨時提供建議給使用者，並且幫助其節稅及免除煩複的計算過程。本系統之基本流程如圖 4-2 所示：

(46)

基本資料輸入各項所得處理各項扣除額處理綜合所得淨額計算稅額計算圖 4-2 本系統之基本流程 1. 基本資料輸入系統要求使用者輸入婚姻狀況、姓名、年齡、性別、職業別及扶養親屬人數等基本資料。根據使用者所輸入資料，系統將做如下之推論： 若　　婚姻狀況為已婚 　且　一年內婚姻狀況有變動 　且　夫妻兩人一年之所得皆大於三萬元 則　　建議夫妻分開報稅，可節省稅支 若　　婚姻狀況為已婚 　且　一年內婚姻狀況無變動 或　　婚姻狀況為已婚 　且　一年內婚姻狀況有變動 　且　夫妻兩人一年之所得有一方小於三萬元 則　　建議夫妻合併報稅，可節省稅支。 　　　同時提醒納稅人正常狀況下之申報人為夫方。

(47)

38 每項所得輸入皆有說明畫面，供使用者參考。同時，輸入之所得額，除了薪資所得因牽涉到薪資特別扣除額之計算，必須個別輸入外，其餘各項所得則只須輪入納稅人及其共同申報人之該項總額即可。當各項所得皆輸入完畢時，系統將自動將該九項所得及其扣繳稅額加總顯示於畫面上。 3. 各項扣除額處理：扣除額共有四項： 4. 標準扣除額或列舉扣除額納稅人得自由選擇採標準扣除額或列舉扣除額。其中標準扣除額由本系統計算出來，而列舉扣除額則由使用者輸入。然後，由本系統對兩者加以比較，採金額較大者做為此項扣除額。 5. 薪資所得特別扣除額依照個人薪資所得系統規定比例，由系統自動計算出。 6. 財產交易損失扣除額由使用者輸入其總額。 7. 儲蓄投資持別扣除額由使用者輸入，其總額以不超過三十六萬元為限。各項扣額輸入完畢後，由本系統自動加總並將結果顯示於畫面上。 8. 綜合所得淨額計算

(48)

如果納稅人之綜合所得總額超過了 73 萬元，則本系統將會建議納稅人，如困其有合於獎勵規定之利息所得，則採分離課稅將會更為有利。綜合所得淨額將由系統依使用者前面所輸入之資料而自動計算出其淨額，其計算公式如下： 綜合所得淨額＝ 綜合所得總額－分離課稅總額－免稅額－扶養親屬寬減額－扣 除額 9. 稅額的計算首先系統必須計算出納稅人之初步應納稅額。而採分離課稅者，本系統也將為其計算出分離課稅所得應納稅額。計算方式如下 綜合所得應納稅額＝綜合所得淨額＊稅率－累進差額 分離課稅應納稅額＝分離課稅總額＊25％ 最後，即為最終稅額之計算步驟： 最終稅額＝ 綜合所得應納稅額－投資抵減稅額－出售自用住宅抵減稅額＋ 選擇分離課稅應納稅額－扣繳稅額－額繳稅額

(49)

40

第二節 Aglet

4.2.1 Aglet 的特性與目的

Aglet 是由 IBM 東京研究實驗室所開發的獨立式 Mobile Agent （Stand-alone Mobile Agent）物件程式，完全是以 JAVA 語言來製作，最主要的目的便是能夠使程式碼、執行狀態及結果在 Internet 上多台主機間傳遞移動。也就是說，原來正在某個主機上執行 Aglet，可以立即中斷執行，然後將其自己分派到網路上另一台遠端主機上，再接著於那台主機上執行。而在移動的過程中，其原始程式及相關資料都不會漏失，以確保移動後仍能正確被執行。但是 Aglet 並不會在移動時捕捉執行緒的狀態，因為這會牽涉到更動標準的 JAVA 虛擬機器（JAVA Virtual Machine，JVM）；也就是說，捕捉執行緒意味著系統只能應用於某種特定的虛擬機器，這不但會使市場接受度降低，亦與 JAVA 本身的初衷相違背。因此 Aglet 是採欲如同 Tacoma 式的「已知進入點」（Known Entry Point）模式，以在移動後能重新開始執行[Klusch，1999]。

Aglet 支援自動執行（ Autonomous Execution ）及動態繞徑（Dynamic Routing）的概念，我們可以將 Aglet 視為 JAVA Applets 及 Servlets 的延伸，因為基本上 Aglet 便具有它們的特性。Aglets 乃是載放於 Aglet 伺服器上，就如同 JAVA Applets 是由 Web 伺服器所載放一樣。Aglet 伺服器提供 Aglets 執行的環境，而 JVM 及 Aglet Security Manager 則提供必要的安全和保護機制，使其能安全的收送及執行 Aglets。

(50)

輕量物件轉移（Lightweight Object Migration）、支援「永續生存」（Built with Persistent Support），以及事件驅動（Event-Driven）[Xu ＆ Tao， 1997]。另外，透過Aglet Proxy，可以達成位置透明化的目的。[Oshima ＆ Karjoth ＆ Ono，1998]

Aglet 系統的目的如下：[1]

1. 提供一個簡單且綜合的模型以供製作撰寫 Mobile Agents，開發者不需更改任何 JAVA VM（VM，虛擬機器）及原生碼（Native Code）。

2. 提供動態且強大的溝通方式，使 Agents 能夠與其他不論是否為已知的 Agents 彼此地相互溝通。 3. 設計一個可再利用與可延伸的架構。 4. 設計一個與現有 Web／JAVA 技術完全相容的架構。 5. 提供一個既簡易又充分的安全機制，使得使用者可以充分信任 Mobile Agents。

順帶一提，Aglet 這個字原來是由 Agent 及 Applet、兩個字所合 成，顧名思義，代表 Aglet 具有「輕量級代理者」（Lightweight Agent）的涵意。

4.2.2 Aglet 的架構

Aglet 物件本身的架構主要可分成 Aglet 核心與 Aglet 代理者（Proxy）兩個不同的部份[Clements ＆ Papaioannou ＆ Edwards， 1997]。Aglet 核心是最主要的部份，包含了 Aglet 內部所有的方法、

(51)

42 防止任何外部物件直接存取私有的變數與方法，也可以隱藏某個 Aglet 的真實位置，避免其他惡意的 Aglet 程式得知而進行侵入或破壞。Aglet 的整體架構如圖 4-3：圖 4-3 Aglet 整體架構

4.2.3 Aglet 的環境

從整體的環境架構來看，Aglet 系統主要可以是為由四大部分所組成，如圖 4-4 所示[Xu ＆ Tao，1997]：圖 4-4 Aglet 的組成元素 1. Viewer 作為使用者與Aglet之間溝通的介面，使用者可以經由 Viewer來操縱Aglet，如產生、儲存及分派等動作。例如Tahiti，即是一個GUI Aglet Viewer，具有視覺化的管理介面，讓使用者更方便管理Aglets。

(52)

執行的許多方法函式，所有的Aglets都一定要在既有的（一個或多個）Context下才能動作。

3. Security Manager 負責保護主機及Aglets不受惡意的個體或行為 所破壞。 Aglet系統中的 Security Manager主要是以 JAVA本身的 Security架構為基礎，再加上一些限制而成。基本上是以各個Aglet 的工作權限為依據，來判定其所具有的資源存取能力。

4. ATP（Agent Transfer Protocol）是一個簡單的以HTTP為基礎的應 用層（Application Level）通訊協定，它使得我們不需顧慮Aglets 是否被派送到不同的Agent系統就可以傳送Aglets（也就是Agent-System-Independent）[Lange ＆ Oshima，1998]。

4.2.4 Aglet 的生命週期與彼此的溝通

一般的 Aglets 在其生命週期中主要會發生以下四類的事件： 1. 產生（Creation）：創造（Create）及複製（Clone）。 2. 移除（Disposal）：移除（Dispose） 3. 移動（Mobility）：分派（Dispatch）及召回（Retract）。 4. 儲存（Storage）：暫停（Deactivate）及喚醒（Activate）。圖 4-5 即為典型的 Aglet 生命週期模式：

(53)

44 圖 4-5 Aglet 的生命週期模式 Aglet 的另一個重要特性便是彼此之間可以互相溝通。Aglets 不需要知道對方式誰，長什麼樣，便可以彼此交換訊息；而這些訊息乃是物件式的，也就是幾乎可以由任何類別的物件所組成，當然包含使用者自訂的類別。訊息並非由 Aglets 所直接接收，而是先經由 Proxy 所「代收」，帶查驗是否「送對人」及是否「合法」；另外也提供位置透明化的傳送介面，因此不論收受訊息的對象是本地或遠端，其傳送的方式都是一樣的。Aglet 的基本訊息介面如圖 4-6 所示：圖 4-6 Aglet 基本訊息介面

4.2.5 Aglet API 舉例

使用者可依需要改寫（Override）以下的各個方法，帶事件發生時，系統便會呼叫相對應的方法加以處理。表 4-1 檢列了幾個最基

(54)

本的處理方法：

表 4-1 基本的 Aglet 動作處理方法

事件 當事件發生時系統呼叫 當事件結束時系統呼叫

產生 Creation onCreation（）複製 Cloning onCloning（） onClone（）分派 Dispatching onDispatching（） onArrival（）召回 Retraction onReverting（） onArrival（）移除 Disposal onDisposing（）

暫停 Deactivation onDeactivating（）

喚醒 Activation onActivation（）傳送訊息 Messaging handleMessage（）

(55)

46

第三節本研究稅務代理系統架構

本研究系統的架構牽涉到三個個體，包括伺服端（Server）、報稅人的客戶端（Client），以及國稅局網站。整個報稅的工作流程從報稅人（使用者）登入系統的 Server 開始，共可分為六個步驟（參考圖 4-7）：圖 4-7 本研究稅務代理系統架構使用者先登錄為本系統網站的會員，取得一個 ID 及密碼，然後進行下列步驟： 1. 使用者登入本系統的網站，從 Server 上下載回來 Cabinet 檔案，內含環境設定程式及 Kangaroo Agent 程式。 2. 使用者利用 Kangaroo 登入系統 Server，Server 在檢查使用者登入無誤後，則會詢問使用者想要進行的動作，以決定派遣哪一種 PokiMon 回來給使用者。

3. 若使用者要進行報稅，則 Kangaroo 便將 PokiMon 從 Server 上帶回到 Client 端，以開始報稅。 Server （存有客戶端所需的所有 Aglets） Client （必須先登入 Server） 國稅局 （網站存有客戶的稅務資料） 1 2 3 4 6 5

(56)

4. 在報稅過程中， PokiMon 會啟動 Beelet 程式，並依據使用者的個人資料，登入國稅局的網站。Beelet 負責在國稅局網站收集客戶的稅務資料，如扣繳憑單等。 5. Beelet 會取回使用者的個人稅務資料，將其拆解並分析整理，然後填入報稅表格中適當的欄位；而此稅表其餘的相關資訊則由使用者自行填入。整個流程其間不需經過系統 Server，因為客戶稅務資料是屬於相當個人性私密資料，若能減少在網路上的傳輸時間與路徑，就能降低被截取或竄改的風險，而安全性亦隨之提升。

6. PokiMon 將整個填好的稅表傳給 Client 端的 Kangaroo，若使用者有需要，則 Kangaroo 負責將結果存檔於 Client 端上。

整個系統主要包含了三個 Mobile Agents（Aglets），即 Kangaroo、 PokiMon 與 Beelet。Kangaroo 是附帶於可供下載的包裝程式 Cabinet 之中，以備使用者下載回 Client 端自動安裝執行。而 PokiMon 內則包含了到國稅局網站報稅的程式。所有程式均以 JAVA 語言寫成，因此可以緊密的整合在一起。以下說明本系統中最重要三個代理者程式的功能。

1. Kangaroo：為一 Aglet 程式，包於 Cabinet 下載檔案之中。當使用 者利用 Cabinet 將環境安裝設定起來之後，便會自動執行 Kangaroo，然後負責登入本系統網站。登入成功後再依據使用者的需要，將 PokiMon 程式帶回到 Client 端。最後可將 PokiMon 傳回的結果表單加以存檔，以供日後使用。在本研究中 Kangaroo 即為第一節中所稱之帳務代理，能存取客戶端的檔案，並列印出各

(57)

48

型報稅程式，能針對納稅義務人的狀況，提供最有利之報稅策略，並能進行各種試算，期能為納稅人合法節稅。在本研究中 PokiMon 即為第一節中所提之智慧型節稅代理。

3. Beelet：為一 Aglet 程式，包含在實際負責報稅動作的 PokiMon 程 式中。Beelet 會從 Client端依據使用者個人資料，登入國稅局網站，然後將國稅局網站中有關此客戶的帳戶資料，如扣繳憑單等，自動拆解及分析，並填入報稅表單。此表單中沒有出現於國稅局網站中用戶資料內的其他欄位，則由使用者自行填入。然後將結果及相關資訊與程式碼，一併傳回給在 Client端上等候的 Kangaroo，其間並不經過系統 Server，亦即不會將這些物件暫存於 Server上。在本研究中，Beelet 程式即為第一節中所稱之資料蒐尋代理。

(58)

第五章系統與實例說明

第一節系統環境與安裝

5.1.1 系統環境

由於本系統主要架構是以 ASDK 所開發，因此必須先行說明此套開發工具及其所提供的 Mobile Agent 環境。ASDK 主要包含了 Aglet API、說明文件、範例 Aglets，以及 Tahiti Aglet Server。Tahiti 是一個 JAVA Application，提供一個 GUI 的介面，方便讓使用者接收、管理，或者傳送 Aglets 到網路上其他有執行 Tahiti 的電腦上。因此 Tahiti 可以說是 Aglets 的執行環境，一定要先執行起來，才可以載放 Aglets，也才能讓 Aglets 移動於網路上各主機之間，故 Tahiti 亦是一個 Aglet Server。圖 5-1 便是 Tahiti 的執行畫面：

圖 5-1 Tahiti

由於 Tahiti 也是一種 JAVA 應用程式（Application），因此需要直譯程式才能啟動它。而且在安裝 ASDK 時，也必須先指定 JDK 的路

網際網路智慧型稅務代理之研究