三星敗訴 判賠蘋果10.5億美元

上週五，蘋果(Apple)在對韓國三星(Samsung)的專利訴訟案中，取得了顯著但並不完全的勝利。蘋果獲得了10.49億美元損害賠償，加上一紙載明三星多次「故意」(willful)侵權的判決書。這個懲罰性賠償的金額，是當前懲罰賠償記錄的三倍之多。

蘋果要求的賠償金額是27.1億美元，該公司還表示，如果發現任何侵權行為，預計至少可獲得5億美元的賠償。

在審判過程中，九人陪審團發現了許多三星手機均違反了蘋果的二項設計和三項實用專利。然而，陪審團也裁定，三星的平板電腦並未侵犯蘋果的 iPad 外觀設計專利。

因此，在這種情況下，蘋果很可能會考慮和其他同樣進行專利訴訟的 Android 智慧手機製造商進行私下談判。

本案將於9月20日宣判，屆時將可確定是否設置禁止在美國銷售被侵權產品的禁止令。這些產品包括12款三星的 Galaxy S 和 S II 等型號的智慧手機。

三星表示將提出上訴，並聲稱該判決將導致“市場上的產品選擇更少、抑制創新，而且可能拉高產品價格。

”這項裁決證實本案中至少有四個蘋果專利遭到侵犯，唯一的例外是 iPad 的外觀設計專利。陪審團還裁定，三星侵犯了原始版iPhone和3GS iPhone的已註冊╱未註冊「外觀和感覺」。不過，陪審團對於蘋果爭論的 iPad 的「外觀和感覺」也遭到侵權一事並不買賬。

蘋果並未侵犯三星所指控的五項實用新型專利，包括兩項三星的3G手機標準專利在內。然而，陪審團也裁決，蘋果未能證實該專利的無效性、或證實三星打破了合作協議，或是證明這家韓國公司的專利及其授權行為違反了反托拉斯法。

蘋果和三星都努力證明對方專利的無效性，他們找來了許多技術方面的專家作證，包括各領域的尖端學者在內。但最終，陪審團認為，所有的專利都是有效的。


原文來自：http://www.eettaiwan.com/

分析稱Google Now性能遠勝蘋果Siri語音助理

7月2日消息，美國科技博客網站Business Insider編輯史蒂夫·科瓦奇(Steve Kovach)周日發表評論文章稱，穀歌Google Now語音數位助理服務性能已遠勝蘋果Siri，且填補了Siri服務此前存在的諸多空白。以下為該文摘要：

在蘋果收購科技創業公司Siri數年之後，大量業界人士認為，此舉為蘋果向穀歌搜索業務發起挑戰而邁出的第一步。這種假設自然有其合理性。

然而在《華爾街日報》旗下博客網站AllThingsD於2010年召開的D8技術大會上，蘋果聯合創始人史蒂夫·約伯斯(Steve Jobs)卻表示，蘋果對於Siri技術的應用與外界想像稍有不同。約伯斯說：“Siri並不是搜索公司，而是人工智慧公司。我們並不希望進軍搜索業務領域，我們不關心這個。其他人(在搜索業務上)做得很好。”

約伯斯上述言論大部分不虛。Siri去年10月被整合到iPhone 4S上面後，該服務更多表現出智慧虛擬助理的特徵，而非一款搜索工具。Siri被設計成一款提醒工具，能夠發送短信並與發出指令等。雖然Siri也部分具有搜索功能，但其搜索結果主要依賴另一家搜索服務商Wolfram Alpha。而Wolfram Alpha又被稱為“知識引擎”，即主要提供事實性資料結果，如“希臘的GPD(國內生產總值)為多少”之類的問題答案，只是此類搜索結果，難以滿足普通公眾的具體需求。

這也就是我對穀歌宣佈推出Google Now感到欣喜的原因所在。Google Now是以搜索業務為中心的語音數位助理，該服務將整合到即將發佈的新款Android 4.1版作業系統當中(開發代碼為“Jelly Bean”)。

過去數天中，我一直在試用運行Jelly Bean的Galaxy Nexus手機和Nexus 7平板電腦。在試用過程中我發現，Google Now的性能表現無疑比Siri更為突出。Google Now填補了Siri服務留下的所有空白，且整體表現也優於Siri。Google Now的表現，其實正是搜索業務如何應用於移動設備上的典型例子。

試舉數例：

上周我在三藩市市報導穀歌的2012年度I/O開發者大會，並在該市採訪了其他數家科技公司。上週五我有一個會議。在會議開始之前45分鐘，Google Now給我發出提醒，並表示我必須趕快出發，否則可能會遲到。Google Now甚至將堵車因素也考慮在內。真不錯。

另一個晚上，我與數名從事新聞行業的老校友聚會。我們當時談論起吉姆·羅梅奈斯科(Jim Romenesko，注：美國科技博客作者)。我的一位朋友當時表示，也不知道羅梅奈斯科現在多大年紀了。於是我將這個問題交給了Google Now，而不到一秒鐘內，Google Now就給出了答案。

我是紐約大都會棒球隊(Mets)的“粉絲”，因此我在穀歌搜索進行的絕大部分體育搜索，多與該球隊的比賽得分有關。Google Now自然也瞭解我的這種習慣，因此會自動向我發送最新賽事的得分情況。我已不再需要向Google Now發出搜索請求。

上週五我乘坐紅眼航班回紐約。在登機前，我與數位朋友一起三藩市Mission區附近聚會。依據我的搜索歷史，Google Now已經知道我的航班號，並向我提供登機入口及航班可能晚點等資訊。

另一方面，Google Now的處理速度很快。數天前我曾同穀歌Android產品主管雨果·巴拉(Hugo Barra)進行過交談。巴拉告訴我，Google Now團隊曾花費數月時間，使Google Now的回應時間縮短數秒鐘。與Siri相比，Google Now提供的資訊不僅相關性更高，且幾乎是瞬間返回答案。就Siri處理速度而言，通常情況下使用者在提出問題後，往往要等上數秒鐘才會得到答案。

Google Now就是我需要的虛擬助理服務。我不想捲入究竟哪款智慧手機性能更好的爭論，我需要得到滿足我個人需求的答案，而Google Now就能做到這一點。有時我甚至不必提問，Google Now就知道我內心所想，真是令人難以置信。

雖然Google Now性能不錯，但Android作業系統碎片化的問題，卻將使得Google Now的推廣事宜面臨著挑戰。穀歌上一個Android版本Ice Cream Sandwich於7個月之前推出，而目前在所有Android設備上的份額僅占7%，即絕大部分Android設備目前仍在運行2010年晚些時候發佈的Gingerbread。

按照這種發展速度，至少還需花上一年時間，絕大部分Android設備使用者才能用上Google Now服務。與此同時，蘋果每個季度會出售大量具有Siri功能的iPhone 4S。即使Siri性能不及Google Now，但大量公眾卻會逐步接觸並熟悉Siri，從而使蘋果在語音助理服務上比穀歌佔據更多市場優勢。

今後Siri的搜索功能肯定會有所加強，我對此深信不疑。只是絕大部分人沒有意識到的是，目前Google Now在性能上已完全擊敗Siri。

IDC：蘋果推出mini iPad市場控制力會更強

根据市场调研公司IDC公布的2012年平板电脑销售预测，苹果将继续保持并扩大其市场领先地位。IDC通过数据追踪认为，今年苹果有望挽回2011年被Android阵营抢走的市场份额，市场占有率将在62%，iPad销售量约6980万台。2012年，平板电脑销售总额将达到1.074亿台，2011年为6960万台，2010年仅为1940万台。

IDC移動設備部門調研主任Tom Mainelli表示，“對iPad的商用需求正大幅增加。因為iPad的價格逐步走低，微軟大舉研發Win8系統，人們對蘋果熱情不減，消費群體對平板電腦仍然感興趣。”

　　Mainelli表示，“iPad銷售增長幾乎沒有放緩的跡象，Retina顯示幕和4G網路對很多果粉具有誘惑性。而低價銷售iPad 2的方法也非常明智。”

　　Mainelli同時表示，如果蘋果推出7英寸的低價iPad，那麼對市場的控制力會更強。目前有坊間傳聞蘋果將會在今年秋天推出這樣一款設備。

轉自: 

http://www.cnbeta.com/articles/192508.htm

為什麼使用者不喜歡 Facebook 的 iOS app？(轉)

Facebook 創辦人與執行長 Mark Zuckerberg 最近喜事連連，除了上週五自己創辦的公司公開上市，他自己也在隔天與女友結婚。不過也許是因為要公開上市，最近市場冒出許多質疑 Facebook 的聲音，例如美國通用汽車（GM）認為在 Facebook 投放廣告不划算、分析師認為 Faecbook 執行長「不夠成熟」（例如在路演期間穿的是招牌連帽外套而非西裝）、Facebook 的市值被高估等等，其中跟使用者最為相關的，就是 Facebook 搞不定行動裝置。
目前 Facebook 有半數的使用者透過行動裝置（iOS、Android app 或行動版網頁等等）使用這個全世界最大的社交平台，可是他們的 app 在行動裝置上的兩大平台 iOS 與 Android 最近飽受批評，而這些批評不外乎是速度太慢、bug 太多⋯ 舉例來說，也許有讀者看過 Facebook 的 iOS app 出現類似以下的畫面：

Facebook App 評價下滑

最新一版的 Facebook iOS app 在 App Store 上評價只有兩顆星（但是過去的總體評價是四顆星），而給予評價的 23303 名使用者當中有 12809 人打了一顆星。通常一個 app 有超過半數使用者在五星評等中只給出一顆星的評價，說明這個 app 必定很有問題。

來源：App Store

來源：App Store

請注意截圖中，每則給予一顆星的評論都獲得九成以上的認同。
無獨有偶，最近 Android 的使用者對 Facebook app 也很有意見：

來源：Google Play

一開始 Facebook 的 iOS app 不是長這樣

其實一開始 Facebook 的 iOS app 不是現在這樣，最初它是由 Firefox 瀏覽器的共同創造者 Joe Hewitt（他另一個有名的作品是 Firefox 的附加元件「Firebug」，目前有超過三百萬人（註 1）天天使用）所開發出來的，用了一部分他自己的開源碼專案「Three20 project」（註 2），堪稱當時 iOS app 的範本，許多有名的 app 也是參考他的設計（例如 LinkedIn）。但是在 Joe Hewitt 離開 Facebook 後，接手的團隊重寫了 Facebook app。
幾天前 mobtest 在他們的部落格上發表了一篇文章〈Here’s why the Facebook iOS app is so bad (UIWebViews and no Nitro)〉（註 3），說明為什麼 Facebook 的 iOS app 會這麼糟糕。
他們列舉出幾個 Facebook iOS app 的問題：

1. app 的速度太慢
2. 不一致的訊息
   有時候代表「通知」的圖示告訴你有新的通知（例如妳的留言有人按讚），但其實沒有。
3. app 甚至比行動版網頁還慢
   大家都在用速度越來越快的 iOS 原生 app 時，Facebook app 竟然比行動版網頁還慢，而後者提供了幾乎與前者一模一樣的功能。
4. 一大堆 bug
   超慢的顯示、照片上傳會失敗、文字框會消失、缺乏分享功能⋯

問題：HTML、UIWebView、沒有 Nitro JavaScript 引擎

HTML
超文件標示語言（英文：HyperText Markup Language，HTML）是為「網頁創建和其它可在網頁瀏覽器中看到的信息」設計的一種標示語言。（參考來源：維基百科）
UIWebView
You use the UIWebView class to embed web content in your application.
您可用 UIWebView 這個類別（class）將 web 內容嵌入到您的 app。 （參考來源：Apple iOS Developer Library）
Nitro JavaScript 引擎
JavaScrip t 引擎是一個專門處理 JavaScript 腳本的軟體程序，一般會附帶在網頁瀏覽器之中。而 Nitro JavaScript 引擎是 Apple  為旗下的瀏覽器 Safari 開發出來的 JavaScrip t引擎。（參考來源：維基百科）

Facebook iOS app 是從 facebook.com 下載 REST（XML 格式而非 JSON）與 HTML。HTML 負責使用者的 timeline、個人資訊及社團的 timeline。我們可以發現有時候 Facebook app 在下載 HTML 和圖片/樣式（stylesheets）/JavaScript。為了在 app 裡顯示 HTML，開發者就用了 iOS 瀏覽器 Safari 裡的一個物件（component）「UIWebView」，它雖然方便，卻也很危險。HTML 檔案不小（15kb），包括了圖片、樣式和 JavaScript 的連結。由於 UIWebView 無法讓開發者對內容做有效的快取，每一次 Facebook 都會重新下載整個 Timeline 的 HTML 檔案，而 UIWebView 的效能又比不上行動版的 Safari，不但缺乏 Nitro JavaScript 引擎，也有安全上的疑慮。
mobtest 的作者特地用自己的 iPhone 4（搭載 iOS 5.1.1）執行 SunSpider JavaScript Benchmark，結果在行動版 Safari 的效能是 iOS 原生 app 裡 UIWebView 的三倍快，也難怪使用者會覺得慢。而且為了 UIWebView 跟原生 app 之間的溝通，必須靠 JavaScript bridge，這東西很棘手，不但慢而且還不安全。

對於相同資訊的呼叫無法同步

前面提到資訊不一致的問題，是因為 REST 呼叫完成後，會回傳 XML 資料，先確認「通知」的數量（https://api.facebook.com/restserver.php），然後再透過一個獨立的呼叫擷取通知的 內容（https://api-read.facebook.com/restserver.php）。由於 Facebook 會回傳不一致的訊息，導致使用者遭遇通知數與實際內容不相符。

那為什麼 Facebook 不乾脆全面使用原生 app 的技術就好？

1. 因為 HTML 比 Objective-C 更容易調整內容的呈現方式，後者在處理一些狀況時候很麻煩，例如文繞圖的樣式。
2. 使用 HTML 跨平台容易許多。iOS、Android、BlackBerry、Windows Phone 使用技術都不同，造成開發者極大的困擾。要在不同的平台中分享內容及功能，靠 HTML 容易的多。
3. HTML 更符合 Facebook 的連續佈署程序。Apple 的審核時間太長，不符合 Facebook 佈署程式碼的流程（每次都要送審的話那還得了）。
4. 世界上還有許多不是 iPhone/Android 的功能手機（feature phone）。一些比較沒那麼富裕、先進的地區（例如非洲），很多人都是透過功能手機來使用 Facebook。
5. 全世界只有一個 Facebook。當你我的朋友都在用 Facebook 的時候，就算它的 app 再糟糕，我們也只好繼續忍耐。

至於 Facebook app 到底有多困擾使用者，我們可以參考一下 Facebook 產品總監（Director of Product）、Firefox 瀏覽器的共同創造者 Blake Ross 在 Facebook 公開上市前夕發出的一個訊息（註 4），他說明天 Facebook 要公開上市，問使用者們今天晚上 Facebook 是不是該做點什麼、各位使用者們希望加入什麼功能（或是修好哪些問題），結果就有人回應：

“Fix the Android app. It is ridiculously slow.”
“A mobile app that works.”
“Fix the iPhone app.”
“Please fix the mobile app.”

（大家可以去 Blake Ross 的訊息網頁，在大家的留言中搜尋「app」XD）


註 1：Firebug :: 統計資訊顯示板 :: Firefox 的附加元件
註 2：Three20
註 3：Here’s why the Facebook iOS app is so bad (UIWebViews and no Nitro)
註 4：Blake Ross 的 Facebook 牆上照片

轉自: http://www.inside.com.tw/2012/05/21/why-isfacebook-app-so-slow