Мы больше не будем использовать Windows

Цитируем Financial Times:

Google is phasing out the internal use of Microsoft’s ubiquitous Windows operating system because of security concerns, according to several Google employees.

The directive to move to other operating systems began in earnest in January, after Google’s Chinese operations were hacked, and could effectively end the use of Windows at Google, which employs more than 10,000 workers internationally.

“We’re not doing any more Windows. It is a security effort,” said one Google employee.

Все логично, Microsoft конкурент Google, будут платить меньше лицензий. После случая в Китае, они поставили под сомнение безопасность Windows. Хотя, как говорится «палка двух концов», пользователи могут уйти и на Mac OS, и вообще Google Chrome OS не может быть предназначен для развития самих компьютеров, т.к. продукты Гугл — это веб-приложения.

Корпорация Google отметила тридцатилетие видеоигры Pac-Man, заменив на нее собственный логотип. Таким образом, все посетители сайта Google.com могли сыграть в Pac-Man на выходных 22 и 23 мая.

В Google были так ошеломлены успехом Pac-Man’а на своей главной странице, что решили сделать доступной игру всегда — по адресу google.com/pacman.

Игра Pac-Man была выпущена японской компанией Namco Bandai 22 мая 1980 года. Смысл игры заключается в поедании главным героем по имени Pac-Man точек, разбросанных по лабиринту. Этому мешают четыре монстра по имени Blinky, Pinky, Inky и Clyde.

Несколько лет назад я прикинул, что было бы клёво создать… фотомозаику. Такую реальную. Т. е. вместо одного большого-пребольшого постера, где малые фотки, размером с почтовую марку играют роль «плиток», вместе создающих одно большое полотно постера, сделать большую картину из реальных фоток высокого разрешения, размером 4?6.

В задаче этой было несколько моментов, которые меня озадачивали и тем привлекали (ну, задача-то была сложная, как ни крути!). Во-первых, для того, чтобы иметь достаточно «плиток», чтобы общий рисунок, сделанный из них, был чёток, сама мозаика должна быть не просто большой, а преогромной. Посему потребовалась стена, а не просто поверхность. Во-вторых, для того, чтобы зритель смог оценить как общую мозаику, так и каждую «плитку» отдельно, на всё это надо смотреть с приличного расстояния (чтобы «плитки» давали общий цветовой фон, сливались т. с.), чтобы затем можно было подойти ближе и убедиться, что каждое фото есть отдельное фото. Посему гигант должен был занимать всю стену внутри помещения или целый блок где-нибудь снаружи. И в-третьих, при осмотре малых фотографий следовало бы убедиться в том, что и сами по себе они представляют чёткие, красивые, сюжетные и самостоятельные произведения. Поэтому я знал, что взять и скачать из сети самых разных фоток не получится. Мне надо было получить оригиналы файлов, с высоким разрешением, которые можно распечатать, в общем напрямую от фотографов.
Вечером в четверг, после многих месяцев подготовки и планирования, с помощью десятка друзей и последователей гугла, всё «сложилось» наконец. Мы использовали 884 отдельных фотографий размера 4?6 с изображением людей, мест и всякой всячины со всей Британии (причём все фотки были сделаны гугломанами!), и вот результат – в лондонском офисе гугла мы создали логотип гугла на стене размером примерно 10?20 футов.

И, скажу я вам, этот опыт был нечто. Если смотреть на мозаику с расстояния 100 футов, глаз точно выцепляет гугловское лого, а, если затем идти по направлению к мозаике, то постепенно проступают детали уже отдельных фотографий. И это очень круто! Для тех, кто не живёт в Лондоне, вот вам попытка воссоздать то, что мы испытали, с помощью всё тех же фоток, приближений и увеличений (нижняя правая “G” и нижняя левая красной “o”), ну и отдельные снимки отдельных фото.

(Это нижняя правая большого G и нижняя левая красная o.)

(Это Грег Блок сфоткал, не я.)

Весь процесс сделан ещё и на видео, чтобы было ясно, как это всё реально делалось. (Камера щёлкала и делала снимок каждые 7 секунд, поэтому 5 с половиной часов сжаты в фильм на час двадцать.). Смотреть это видео лучше в высоком разрешении HD (на самом видео можно переключиться на другой код), на большом экране вы увидите даже мелкие фотографии.

Хочу поблагодарить всех, кто присылал мне фотографии, тратил своё время и мозговые клетки (я, кстати, вовсе не ожидал, что из всего этого унылого бетонного единообразия да с помощью даже десятка постеров что-то выйдет похожее!), чтобы данный проект получился. Отдельное спасибо Аде Ошини, Ане Хэррис, Бет Фостер, Кристоферу Аллену, Дэну Кроу, Дону Дрессеру, Гэбриэль Хьюг, Грегу Блоку, Джонатану Баркеру, Кайли Мэдисон, Людвику Гродски, Маартену Вильке, Ною Сэмуэльсу, Ною Вульфу, Райану Либенбергу, Ронни Боади, Саре Хантре и Симону Биркенхэду за предоставление в общей сложности порядка 4000 фотографий, а также Ане Хэррис, Аннабель Такер, Бет Фостер, Кэтлин Пантос, Гэвину Барнарду, Грегу Блоку, Джонатану Баркеру, Кайяль Патель, Марко Дуартэ, Майку Смиту, Робу Гейтсу, Симону Биркенхэду и Тому Эйлсу, всем, кто момогал мне в расклейке стены. И, разумеется, спасибо тебе Келли за терпение и поддержку в течение тех 40 или 50 часов, что всё это заняло!

1. ВВЕДЕНИЕ
GOOG-411 [1] является сервисом по поиску бизнес-объектов при помощи голоса. Пользователям предлагается назвать город и штат, а затем название конкретного бизнес-объекта или бизнес-категории (например, «компьютерные магазины»). Система распознавания речи преобразует голосовой пользовательский запрос в запрос, который подается в интернет-систему по поиску бизнес-объектов, Google Maps [2]. Google Maps возвращает отсортированный список предприятий. В зависимости от того, насколько точно это соответствует запросу пользователя, выдается от одного до восьми результатов запроса с помощью синтез речи (TTS). Пользователи могут выбрать определенный результат, соединиться по телефону с бизнесом-объектом или запросить SMS с информацией и картой. GOOG-411 в настоящее время работает только с английским языком и охватывает десятки тысяч городов по всей территории Соединенных Штатов.

Концепция голосового справочного сервиса 411 исследовалась в течение довольно многих лет (см. например, [3, 4, 5]), и было реализована в различных сервисах, включая 555 Tell [6], Live Search 411 [7] и Free 411 [8] в США. Как нам кажется, GOOG-411 был одной из первых реализованных служб 411, которая включала полный поиск по бизнес-объектам и категориям, и при обработке трудных запросов не происходило переключения на операторов. Наше основное допущение при таком выборе было в том, что, реализуя итерационный подход в обработке данных и соответствующих показателей, система будет автоматически улучшаться с течением времени. Наличие возможности переключения на оператора изменяет способ взаимодействия пользователя с системой. Чтобы избежать этого и сосредоточиться на конечном решении, мы решили не использовать операторов с самого начала. После краткого обзора системной архитектуры мы опишем процесс подготовки данных и измерения, которые мы проводим для улучшения GOOG-411. Затем мы более внимательно сосредоточимся на двух ключевых компонентах, акустических и языковых моделях, и завершим наше рассмотрение обзором высокоуровневых характеристик (UI) и их совершенствованием с течением времени.

2. СИСТЕМНАЯ АРХИТЕКТУРА
На рисунке 1 показаны основные компоненты системы GOOG-411. Они включают в себя телефонную сеть, сервер приложений, который запускает голосовые приложения, TTS-сервер, сервер распознавания с акустическими, языковыми и фонетическим моделями (AM, LM, PM), сервис Google Maps для выполнения бизнес-запросов, и SMS-канал для передачи информации мобильным пользователям. Каждый из этих компонентов содержит свою собственную резервную копию и возможность балансировки нагрузки, потому что эта диалоговая система, многие из процессов которой асинхронны, в целом является достаточно сложным структурным образованием. Мы используем инфраструктуру Google (machine grid, GFS [9], Bigtable [10]) для резервирования, автоматического распределения; а также реализацию процессов несколькими сетями (multi-homed implementation) в целях обеспечения надежности и масштабируемости сервиса. Текущие показатели используются для контроля за системой, и в реальном масштабе времени вновь поступающие данные позволяют нам контролировать их качество.

Рис. 1. Блок-схема GOOG-411

3. ПРОЦЕСС ПОДГОТОВКИ ДАННЫХ И ИЗМЕРЕНИЯ
Важным аспектом нашей системы является оптимизация данных. С этой целью мы создали обширную систему подготовки данных. Все входящие звонки анализируются для определения жизнеспособности системы (проверка на сбои компонентов и т.д.) и отслеживается их качество (например, того, какая часть звонков достигла конечной точки в диалоге). Эти данные затем сохраняются, расшифровываются и используются для дальнейшего анализа, а также для перегруппировки основных компонентов системы. Затем эти данные обновляются в функционирующей системе. В течении всего времени новые данные используются для тестирования, остальные данные сгруппированы для тренировочных сетов. Данный тестовый подход позволяет нам контролировать пользовательский интерфейс и изменения инфраструктуры, отслеживать меняющиеся модели использования, и избегать использования устаревших тестовых установок.

Для оценки точности распознавания нашим основным показателем являются кривые оперативного приема (receiving-operating curves, ROC), которые показывают соотношение правильно распознанных (correct-accept, CA) и ложно распознанных (false-accept, FA) сигналов. Они оцениваются на уровне предложения в семантической интерпретации результатов распознавания; например, распознавание «гм, итальянский ресторан» вместо «Итальянский ресторан» считается корректным распознаванием (при условии, что коэффициент уверенности превосходит некоторый предопределенный порог, иначе гипотеза была бы исключена).

На системном уровне мы измеряем показатель успешных соединений (transfer rate), т.е. долю звонков, при которых пользователи соединяются с предприятиями или получают SMS с деталями результата запроса. Несколько упрощая, можно сказать, что этот показатель является в первом приближении верным показателем удовлетворения пользователей. Как показано в главе 6, он отражает изменения пользовательского интерфейса, улучшение инфраструктуры и возрастающей точности.

Наконец, на уровне продукта мы отслеживаем изменение трафика, что является еще одним свидетельством успешности работы этого сервиса. В следующих двух разделах мы рассмотрим более подробно наши эксперименты в области акустики и языкового моделирования. При представлении результатов здесь и в главе 6 мы сознательно избегаем показателей абсолютных значений, указывая вместо них лишь относительные. Отчасти из-за конкурентных причин, отчасти потому, что абсолютные цифры легко становятся ошибочными вне контекста. Например, абсолютные числа зависят от того, сохраняем мы или устраняем из тестовых сетов предложения, которые содержат непонятную речь или молчание, и насколько они часты. Они также зависят от того, включен ли в подсчет итоговый (back-end) поиск. Показатель успешных соединений (transfer rate) зависит от того, включаем ли мы в статистику звонки, когда пользователь повесил трубку прежде, чем что-либо сказать. Мы надеемся, что относительные показатели тем не менее окажутся информативными для научного сообщества.
Эксперименты, описанные ниже, отражают показатели нашего существующего сервиса, которым интересующиеся читатели могут воспользоваться по телефону 1-800-GOOG-411 (1-800-466-4411). В общем, служба получила позитивные отзывы пользователей, демонстрируя высокую точность распознавания речи (уровень точности распознавания в диапазоне 50-80%), что делает ее полезной для пользователей и сопоставимой с коммерческими системами.

4. АКУСТИЧЕСКИЕ МОДЕЛИ
Система распознавания речи – это стандартный recognizer, работающий на большом словаре, с PLP и LDA свойствами, на основе GMM triphone HMMs, моделями деревьев, STC [11] и на основе FST-поиска [12]. Чтобы натренировать систему необходимо совершит максимально возможную оптимизацию, осуществляемую во фреймворке mapreduce [13], что позволяет нам получать готовые модели в течение нескольких часов, даже при наличии больших объемов данных, в настоящее время на нескольких сотнях машин. Акустические модели, сравниваемые в данном разделе, не зависят от пола, одноцикличны и тренированы исключительно на образцах речи сервиса GOOG-411.

Рис. 2. Показатель эффективности в зависимости от количества тренировочных акустических данных.

Рисунок 2 показывает относительную эффективность ряда моделей, тренируемых на увеличивающемся объеме данных. Тест состоит приблизительно из 20,000 недавно собранных высказываний, в ответ на вопрос «Скажите называние компании или категорию?» («What business name or category?»), охватывающих более, чем 3,000 городов. Структура акустических и языковых моделей постоянно проходят через ряд экспериментов. Тренировочные сеты сгруппированы так, чтобы мы могли представить результаты всех тренировочных материалов, которые собрали в первом полугодии, в первом квартале, в первом месяце и т.д. Наиболее обширные тренировочные сеты содержат выборку из тысяч часов речи.

Интересно отметить, что качество распознавания не увеличивается резко с количеством тренировочных данных (8% корректных распознаваний [CA] на 10% ложных распознаваний [FA] при коэффициенте роста тренировочных данных 64). Одной из причин может быть то, что тренировочные данные качественно подготовлены для тренировочных сетов как фонетически, так и акустически (одни и те же пользователи своими запросами могут участвовать как в тренировке системы, так и в ее тестировании, конечно разными звонками, но, вероятно, на одном и том же устройстве, а иногда и совершая один и тот же запрос). Другая причина может просто состоять в том, что мы еще недостаточно изучили этот факт.

5. ЯЗЫКОВЫЕ МОДЕЛИ
Языковые модели – это комбинация n-грамных статистических лингвистических моделей (SLM) и внеконтекстных (context-free) грамматик. Они обучаются на трех источниках данных, что облегчает оптимизацию ROC’ов при обработке наборов данных.

Итак, во-первых, мы имеем данные по бизнес-объектам и местоположению: они обеспечивают необходимое покрытие покрытие, но официальные наименования компаний не всегда совпадают с теми, какими их именуют люди, например, «Google» вм. «Google Inc.» или «Starbucks» вм. «Starbucks coffee».

Во-вторых, мы имеет логи web-запросов к сервису Google Maps: это обширный корпус печатных запросов, которые лучше всего подходят для сервиса GOOG-411 (пользователи уже научились тому, что можно вводить «Google» или «Starbucks» для получения нужных ответов). Данные о запросах используются для определения вероятности LM, однако их приоритетность на Google Maps и GOOG-411 не всегда совпадают: например, «real estate» [«недвижимость»] является частым web-запросом, но редким голосовым запросом.

В-третьих, мы имеем речевую базу: транскрибированная речь, собранная благодаря обращениям в службу GOOG-411, оказывается наиболее подходящим видом данных. Во всех приведенных ниже экспериментах языковые модели сокращены, дабы приблизиться к распознаванию в реальном времени и ограничить время ожидания всей системы.

Рис. 3. Показатели эффективности в зависимости от типа данных LM.

Рисунок 3 показывает эффективность работы системы в зависимости от типа данных LM. В настоящее время данные web-журнала демонстрируют, что наилучшими языковыми моделями являются те, которые построены на речевой базе, в процентном соотношении 6% корректных распознаваний на 10% неверных распознаваний между 2-мя LM. Показатели по данным бизнес-объектов гораздо хуже. Объединение 3-х источников данных (combo) дает дополнительно 5% корректных распознаваний (поверх web LM).

Рис. 4. Показатели эффективности LM, построенные на речевых данных, как функция суммы LM тренировочных данных.

Рисунок 4 показывает эффективность LM по бизнес-объектам, полученную только на речевых данных, как функцию от объема речевых данных. Здесь снова показатели тренировочных данных отличаются на 2 пункта. Так как соответствующие ROC’и расположены примерно одинаково, по логу тренировочных данных мы можем заключить, что точность LM растет линейно. По этому показателю вклад речевых данных будет соответствовать вкладу (текущих) web-запросов, только когда мы соберем в 4 раза больше речевых данных (даже при том, что это все еще будет на порядок меньше, чем объем web-данных).

Рис. 5. Показатели эффективности, как функция от типа и количества LM тренировочных данных.

Рисунок 5 показывает эффективность работы диалога «askCityState», в зависимости от типа (web, речь, комбинированный) и размера речевой LM тренировочных данных. Будучи простой задачей, askCityState возрастает менее линейно. Здесь речевые данные выступают так же, как web-данные, которые были значительно обработаны, чтобы отделить города и штаты от запросов, со множеством показателей (полные уличные адреса и т.д.). Без такой обработки web-данные показали очень большое отклонение показателей. Сочетание речевых и (обработанных) web-данных обеспечивает наилучшее качество распознавания. Базы данных по объектам и местоположению не представили каких-либо дополнительных преимуществ.

6. ОБЩИЕ НАПРАВЛЕНИЯ УСОВЕРШЕНСТВОВАНИЯ
Данный раздел дает общий взгляд на эволюцию GOOG-411 во времени. Многие факторы влияют на структуру использования данной услуги, это и изменение статистических моделей, изменения пользовательского интерфейса, изменения внутренней структуры сервиса, исправление ошибок, а также внешние события, такие как праздники, например.

Рис. 6. Показатели эффективности за все время.

Рисунок 6 показывает функцию распознавания во времени. Каждый ROC собирался на различных тестовых сетах (см. концепцию тестирования, описанную в разделе 3). Эти числа показывают, что при норме в 10% корректных распознаваний за прошлые 7 месяцев мы улучшили ее примерно на 25%.

Рис. 7. Дневной трафик как временная функция

Рис. 8. Показатель успешных соединений в зависимости от времени.

Рисунки 7 и 8 показывают число входящих вызовов в день, а также ежедневный показатель успешных соединений в течение одного года. Здесь отражены несколько интересных моментов. Точки A и B на графике показывают рост трафика в момент увеличения нашей рекламной кампании. Точка C – временный перерыв в работе системы. Точка Е на обоих графиках отмечает официальный старт сервиса GOOG-411 большим увеличением объема трафика, а также большое падение показателя успешных соединений: пользователи экспериментируют с системой и не стремятся дозвониться до компаний. Точке D соответствует спокойный период до официального запуска: мы остановили рекламу сервиса (снижение показателей звонков), поэтому абонентами были в основном пользователи, которые по назначению обращались в данную службу (пик показателя успешных соединений).

Точка F на графике успешных соединений отмечает начало эксперимента с пользовательским интерфейсом, где мы сократили результаты выдачи пользователям. Это провоцирует людей дозваниваться до компаний чаще. Точка G отмечает распространение сервиса на все штаты Америки. Точка H показывает интересную ошибку, когда части звонивших были предоставлены неверные результаты значительного числа запросов. Это отразилось падением показателя успешных соединений. Точки J и K показывают сбои инфраструктуры телефонии, с чем также связано падение показателя успешных соединений. Точка I это 4 июля [День независимости], день, когда пользователи, вероятно, были более заинтересованы в соединении с бизнес-объектами для совершения покупок.
Мы могли бы проанализировать кривые более подробно. Но очевидно, что ни трафик, ни показатели соединений не расскажут нам все о пользователях, несмотря на то, что они отражают удивительно широкий аспект событий и оказываются весьма полезными для контроля за работой и развитием системы. Существует немало помех в кривых, которые являются результатом целого ряда трудно определяемых факторов. Это осложняет on-line эксперименты. Конечно возможно небольшое изменение пользовательского интерфейса, однако не ясно его воздействие на показатель успешных соединений, хотя, бесспорно, оно появится в конечном итоге. Для этого мы должны рассчитывать на нахождение более дробных показателей, и в конечном итоге поверить, что мы все делаем к лучшему, так же, как мы верим, когда оптимизируем модели распознавания.

7. ЗАКЛЮЧЕНИЕ
Итак, мы применили итерационный подход для создания, применения и развития довольно сложной системы, основанной на голосовых запросах. Мы показали как, фокусируясь на данных, измерениях, а также постоянном совершенствовании системы, мы можем быстро улучшить низкоуровневые показатели, такие как точность распознавания речи так же, как высокоуровневые характеристики, связанные с пользователями. Вообще, мы нашли, что наличие доступа ко всему стеку продукта с возможностью гибко изменять его по желанию, а также наличие устойчивого потока увеличивающихся данных являются ключевыми факторами в нашей способности последовательно улучшать обслуживание в течение долгого времени.

8. ССЫЛКИ

[1] «GOOG-411″ http://www.google.com/goog411.

[2] «Google Maps» http://maps.google.com.

[3] L. Boves et al., «ASR for automatic directory assistance: The SMADA project» in Proc. ASR, 2000, pp. 249–254.

[4] N. Gupta et al., «The AT&T spoken language understanding system» in IEEE Trans. ASLP, 2006, pp. 213–222.

[5] D. Yu et al., «Automated directory assistance — from theory to practice» Proc. Interspeech, 2007.

[6] «555 Tell» http://www.tellme.com/products/TellmeByVoice.

[7] «Live search 411″ http://www.livesearch411.com.

[8] «Free 411″ http://www.free411.com.

[9] S. Ghemawat et al., «The google file system» in Proc. SIGOPS, 2003, pp. 20–43.

[10] F. Chang et al., «Bigtable: A distributed storage system for structured data» in Proc. OSDI, 2006, pp. 205–218.

[11] M.J.F. Gales «Semi-tied covariance matrices for hidden markov models» Proc. IEEE Trans. SAP, May 2000.

[12] «OpenFst Library» http://www.openfst.org.

[13] J. Dean et al., «Mapreduce: Simplified data processing on large clusters,» in Proc. OSDI, 2004, pp. 137–150.

via habrahabr.ru

• @Last Software, Inc.
• Android, Inc.
• Applied Semantics, Inc.
• Marc Broadcasting, Inc.
• Ganji Inc.
• Google International LLC
• Google LLC
• Google Payment Corp.
• Ignite Logic, Inc.
• JASS Inc.
• JG Productions Inc.
• JotSpot Inc.
• Kaltix Corporation
• Liquid Acquisition Corp. 2
• Neotonic Software Corporation
• Nevengineering, Inc.
• Orkut.com, LLC
• Picasa LLC
• PiFidelity Holding Corporation
• PiFidelity LLC
• Scott Concepts, LLC
• Scott Studios, LLC
• SkillSet LLC
• The Salinger Group LLC
• Transformic, Inc.
• Upstartle, LLC
• Urchin Software Corporation
• Where2 LLC
• YouTube, LLC
• ZipDash, Inc.
• Aegino Limited
• @Last Software, Ltd.
• At Last Software GmbH
• allPAY GmbH
• bruNET GmbH
• bruNET Holding AG
• bruNET Schweiz GmbH
• Endoxon Ltd.
• Endoxon (India) Private Ltd.
• Endoxon Prepress AG
• Endoxon (Deutchland) GmbH
• Google (Hong Kong) Limited
• Google Advertising and Marketing Limited
• Google Akwan Internet Ltda.
• Google Argentina S.R.L.
• Google Australia Pty Ltd.
• Google Belgium NV
• Google Bermuda Limited
• Google Bermuda Unlimited
• Google Brasil Internet Ltda.
• Google Canada Corporation
• Google Chile Limitada
• Google Czech Republic s.r.o.
• Google Denmark ApS
• Google Finland OY
• Google France SarL
• Google Information Technology Services Limited Liability Company
• Google Germany GmbH
• Google India Private Limited
• Google International Gmb
• Google Ireland Holdings
• Google Ireland Limited
• Google Israel Ltd
• Google Italy s.r.l
• Google Japan Inc.
• Google Korea, LLC.
• Google Limited Liability Company — Google OOO
• Google Mexico S. de R.L. de C.V.
• Google Netherlands B.V.
• Google Netherlands Holdings B.V.
• Google New Zealand Ltd.
• Google Norway AS
• Google Payment Ltd.
• Google Payment Hong Kong Limited
• Google Payment Singapore Pte. Ltd.
• Google Poland Sp. z o.o.
• Google Singapore Pte. Ltd.
• Google South Africa (Proprietary) Limited
• Google Spain, S.L.
• Google Sweden AB
• Google Switzerland GmbH
• Google UK Limited
• Neven Vision KK
• Neven Vision Germany GmbH
• Leonberger Holdings B.V.
• Reqwireless Inc.
• Skydocks GmbH

Официальный источник: http://www.sec.gov/Archives/edgar/data/1288776/000119312507044494/dex2101.htm

Некоторые факты:

* Google стал больше платить по программе AdSense: $916миллионов в 4м квартале против $825 миллионов в 3м квартале.

* Увеличились платежи data-центрам и платежным системам: $307 миллионов

* Google тратит много денег на IT: $367 миллионов, потраченных на IT инфраструктуру, сервера и сетевое оборудование.

* Больше половины расходов идут на бухгалтерию и внутренние услуги.

* Увеличение расходов на исследования и разработку: $1.28 миллиарда в 4ом квартале, что на $777 миллионов больше в год назад.

Официально Eric Schmidt заявил:
«У Google был квартал с нормальным ростом доходов, которые получены от самих продуктов Гугла, так и от сетевого маркетинга. Мы продолжаем вкладывать деньги в наши инфраструктуры и в людей. Сильные качества нашей бизнес модели, дают нам возможность инвестировать в наш бизнес, позволяя управлять и увеличивать рынок, а так же держать лидерство на нем.

Финансовый отчет выглядел примерно так:
Доход: $2.25 миллиарда за квартал
Увеличение на 79% по сравнению с 1м кварталом 2005 года и на 17% по сравнению с 4м кварталом 2005 года.