美國聯邦通訊傳播委員會(Federal Communications Commission, FCC )主席Julius Genachowski表示,美國政府正努力規劃商業用途頻譜(spectrum)供給量,以滿足通訊科技服務發展需求。惟諸多產業專家預測無線通訊服務運用導致頻寬需求快速增加,無線通訊擁塞情況恐將嚴重惡化。
儘管FCC已藉頻譜拍賣釋出不少頻譜,且2009年6月全美廣電數位化後(DSO),一定要件開放業者毋須取得頻譜執照便可使用所謂的「閒置頻譜」(interleaved/white space),但是頻譜匱乏的問題仍無法解決。
對此,FCC允諾將會弭平頻譜供給需求間的落差,並且列為FCC的首要任務之一。未來FCC將透過非商用頻譜重分配與鼓勵發展更有效率使用頻譜之科技,以期解決頻譜不足的窘境。
產業界與公眾安全通訊相關組織呼籲FCC應提供更多頻譜供無線通訊服務使用。不過FCC亦要求資通訊產業於研發行動寬頻新產品時,須設想頻譜供給不足,研發更有效率使用頻率的通訊技術。產官學三者間,必須相互配合與協調(尤其是業者間的「不歧視原則」),方能有效解決網路通訊擁塞及頻譜匱乏問題。
歐盟於2015年5月9日在拉脫維亞的里加舉辦了為期一週之「eHealth Week」研討會,包含由歐盟輪值理事會主辦之高階eHealth會議,以及由歐洲HIMSS (Healthcare Information and Management Systems Society)主辦之「WoHIT (World of Health IT Conference & Exhibition)」兩大活動,而2015歐洲mHealth高峰會為其中備受矚目的重要主題活動。該高峰會以推動歐洲mHealth進程之執行為領導思考核心,相關利害關係者(包括公部門、ICT產業、健康保健專業學者)於5月12日以mHealth綠皮書公眾諮詢結果為基礎,針對歐盟目前執行中以及未來可能採取之政策為討論,主要議題包括:1.所蒐集資料之隱私與安全保護。2.生活康樂型apps產品之安全性與品質管控。3.網路經營者對於mHealth市場之進入障礙。 針對資料之隱私與安全保護議題,公眾諮詢結果顯示,關鍵問題在於mHealth apps蒐集使用者資料是否有足夠的隱私與安全保障措施?與會者並認為此問題在資料的第三人再利用情形尤為重要。對此歐盟執委會表示將展開就mHealth apps訂定以產業為主導、範圍涵蓋資料隱私與安全性之行為守則,以建立使用者對mHealth apps之信任感,並提升app開發者對歐盟資料保護法規之遵法意識。 針對生活康樂型apps(包括健康照護相關app)產品之安全性與品質管控議題,透過與會者現場意見調查顯示,認為健康照護相關apps之安全性、品質與可靠性由於欠缺臨床佐證,導致就apps的目的與功效會有錯誤的宣示。值得注意的是,制定法規控管並非多數意見,大多數與會者認為以訂定指引或標準的方式,作為生活與康樂型apps的安全性與品質之依循方針較為妥適。對此歐盟執委會表示會持續跟進此議題並與相關利害關係者討論下一步之行動。 針對網路經營者進入歐盟mHealth市場議題,與會者認為網路經營者將面臨複雜的進入障礙,諸如歐盟相關法規架構的不清與零散、mHealth方案與設備的互通性與開放標準的欠缺等。歐盟執委會明確表示,支持網路經營者進入mHealth市場,目前歐盟正在進行的「Startup Europe」等相關倡議措施,即是以強化網路及資通訊業者商業環境為目的,提供網路經營者法規諮詢、投資媒合、商業模式育成等協助,以降低網路經營者所面對之市場進入門檻並有機會展現其新創能量。
歐盟執委會同意德國全面開放寬頻市場在歐盟公布電子通訊網路的規範架構後,德國電信主管機關聯邦網路局Bundesnetzagentur(BNetzA)於2005 年10月11日提出寬頻接取批發市場的規劃草案,提案內容包含顯著市場力量(SMP)及寬頻網路市場的定義,不過卻將超高速網路接取(very high-speed internet access)排除在寬頻接取市場的定義之外,由於此將涉及德國在流量接取(bitstream)及寬頻接取市場的有效競爭,以及有可能影響具有顯著市場力量的德國電信公司(Deutsche Telekom)與後進電信業者建置VDSL基礎設施或提供寬頻多媒體服務的意願。因此此項草案在送交資訊社會媒體執委會後,引發了諸多爭論。多數委員認為如未將VDSL列入寬頻接取批發市場的定義中,將會導致其他業者無法以同一立足點與德國電信競爭。在BnetzA將VDSL列入市場定義,並允以流量作為批售基礎而重提規劃案後,歐盟執委會於2005年12月23日通過決議,同意德國的電信主管機關聯邦網路局Bundesnetzagentur(BNetzA)全面開放含VDSL在內的高速寬頻網路市場。
開放原始碼撤出蘋果Safari?兩年前蘋果選擇開放原始碼成像引擎( rendering engine ) KHTML 做為 Safari 瀏覽器的基礎;兩年後,蘋果則打算以自己的程式碼取代該引擎,藉以解決相容性的問題。 KHTML 成像引擎──也是其瀏覽器的核心,考慮在其架構上放棄 KHTML 的程式庫( code base ),或者所謂的「樹狀圖」( tree ),改用蘋果自己的版本,也就是所謂的 WebCore (網頁核心)。 KHTML 原本是為了要在 KDE ( K Desktop Environment )上執行而撰寫的──這是 Linux 和 Unix 作業系統的介面。 Safari 並不是蘋果唯一以開放原始碼為基礎的軟體,其麥金塔( Macintosh )作業系統就是以達爾文( Darwin )開放原始碼計畫為基礎。 企業在某些方面受到限制,而開放原始碼社群以不受限制為傲。蘋果自己內部有些問題搞不定,以致銜接不上 KDE 開發 KHTML 的模式,導致 KHTML 與 Safari 逐漸產生分歧,後來情況則越來越嚴重。