Системы, аппарат и способы создания рекомендаций

Изобретение относится к мобильной операционной среде и, в частности, касается предоставления улучшенных способов создания рекомендаций для пользователей поставщиков услуг для мобильных устройств. Технический результат заключается в обеспечении автоматизированного перекрестного продвижения конкретных услуг из множества неравноправных систем. Способ создания рекомендаций для пользователя мобильного устройства, где мобильное устройство ассоциировано с поставщиком услуг, включает получение запроса на рекомендацию, извлечение данных, ассоциированных с пользователем, и данных о контенте, доступном для мобильного устройства, от поставщика услуг, создание множества рекомендаций на основе анализа извлеченных данных, причем рекомендации создают множеством различных методов рекомендаций, выбор поднабора из созданного множества рекомендаций на основе фильтрующих ограничений. 11 н. и 60 з.п. ф-лы, 25 ил., 2 табл.

 

Притязание на приоритет согласно Своду законов США 35U.S.C.§119

Настоящая заявка на патент испрашивает приоритет по предварительной заявке №60/997570 под заголовком «Recommendation Generation Systems, Apparatus and Methods», поданной 04 октября 2007 года, права на которую принадлежат правопреемнику настоящего изобретения и содержание которой напрямую включено сюда по ссылке.

Область техники, к которой относится изобретение

Настоящее раскрытие изобретения относится к мобильной операционной среде и, в частности, касается предоставления улучшенных способов создания рекомендаций для пользователей поставщиков услуг для мобильных устройств.

Уровень техники

Мобильные операторы или поставщики услуг для мобильных устройств играют важную роль в современной телекоммуникационной индустрии. Изначально указанные мобильные операторы концентрировали свои усилия на создании доходов путем расширения своей абонентской базы. Однако очевидно, что в ряде стран возможности расширения абонентской базы сейчас стали весьма лимитированы, так как рынок практически достиг точки насыщения. В результате мобильные операторы для увеличения своих доходов переключились на предоставление абонентам услуг с добавленной стоимостью.

Одним из средств создания повышенных доходов являются продажи пользователям услуг премиум-класса, таких как мелодии для мобильного телефона, фоновые изображения, игры Java и т.д. Эти услуги могут предоставляться самими мобильными операторами или бизнес-структурами, которые могут действовать в сотрудничестве с мобильными операторами по предоставлению указанных услуг. Услуги могут быть доступны для загрузки в пользовательское мобильное устройство после их оплаты.

Многие преимущества, такие как максимизация потенциальной прибыли с продаж, приходятся на рекомендации и продвижение пользователям контента или услуг, которые пользователям вероятнее всего были бы интересны.

Сущность изобретения

Далее в упрощенном виде представлена сущность одного или более аспектов изобретения, для того чтобы предоставить фундаментальное понимание указанных аспектов. Этот раздел не дает всеобъемлющего представления обо всех предполагаемых аспектах изобретения и не претендует ни на идентификацию ключевых или критических элементов всех аспектов, ни на точное описание объема каких-либо или всех аспектов. Единственным назначением этого раздела является дать в упрощенной форме представление о некоторых концепциях одного или нескольких аспектов в качестве прелюдии к более подробному описанию, представленному ниже.

Для достижения вышеизложенных и связанных целей один или более аспектов содержат описанные здесь признаки, которые детально раскрыты в формуле изобретения. В последующем описании и прилагаемых чертежах подробно изложены некоторые иллюстративные аспекты одного или более аспектов. Однако эти аспекты указывают лишь несколько разных путей возможного использования принципов различных аспектов, и описанные аспекты включают в себя все указанные аспекты и их эквиваленты.

Согласно одному аспекту предоставлен способ создания рекомендаций для пользователя мобильного устройства, ассоциированного с поставщиком услуг. Получают запрос на рекомендацию. От поставщика услуг приобретают данные, ассоциированные с пользователем, и данные о контенте, доступном пользователю. Создают список рекомендаций на основе анализа извлеченных пользовательских данных, причем рекомендации создаются множеством различных методов рекомендации.

Согласно другому аспекту предоставляется компьютерный программный продукт, имеющий считываемый компьютером носитель данных с командами. По меньшей мере одна команда заставляет компьютер получать запрос на рекомендацию. По меньшей мере одна команда заставляет компьютер извлекать данные, ассоциированные с пользователем, и данные о контенте, доступном пользователю, от поставщика услуг. По меньшей мере одна команда заставляет компьютер создавать список рекомендаций на основе анализа извлеченных данных, причем рекомендации создаются множеством различных методов рекомендации.

Согласно дополнительному аспекту предоставлена система для создания рекомендаций для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг. Предоставлены средства для получения запроса на рекомендацию. Предоставлены средства для извлечения данных, ассоциированных с пользователем, и данных о контенте, доступном пользователю, от поставщика услуг. Предоставлены средства для создания списка рекомендаций на основе анализа извлеченных данных, причем рекомендации создаются множеством различных методов рекомендации.

Согласно иному дополнительному аспекту предоставлена система для создания рекомендаций для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг. Модуль профилей сохраняет и обрабатывает данные, ассоциированные с пользователем. Модуль каталога сохраняет и обрабатывает контент, доступный пользователю. Модуль принятия решения, находящийся на связи с модулем профилей и модулем каталога, создает список рекомендаций для пользователя путем анализа данных, извлеченных из модулей профилей и каталога, причем рекомендации создаются множеством индивидуальных модулей-рекомендателей.

Согласно следующему аспекту способ предоставляет создание продвижений для пользователя мобильного устройства. Обращаются к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств. Создают рекомендации для контента, предлагаемые на основе атрибутивных данных, и рекомендации для контента, предлагаемые на основе данных о поведении. Выбирают поднабор рекомендаций путем применения фильтрующего ограничения. Поднабор рекомендаций передают по меньшей мере поднабору из множества мобильных устройств.

Согласно иному аспекту по меньшей мере один процессор создает продвижения для пользователя мобильного устройства. Первый модуль обращается к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств. Второй модуль создает рекомендации для контента, предлагаемые на основе атрибутивных данных, и рекомендации для контента, предлагаемые на основе данных о поведении. Третий модуль выбирает поднабор рекомендаций путем применения фильтрующего ограничения. Четвертый модуль передает поднабор рекомендаций по меньшей мере поднабору из множества мобильных устройств.

Согласно еще одному дополнительному аспекту компьютерный программный продукт создает продвижения для пользователя мобильного устройства. Считываемый компьютером носитель данных содержит команды. Считываемый компьютером носитель данных включает в себя по меньшей мере одну команду, заставляющую компьютер обращаться к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств. Считываемый компьютером носитель данных дополнительно включает в себя по меньшей мере одну команду, заставляющую компьютер создавать рекомендации для контента, предлагаемые на основе атрибутивных данных, и создавать рекомендации для контента, предлагаемые на основе данных о поведении. Кроме того, считываемый компьютером носитель данных включает в себя по меньшей мере одну команду, заставляющую компьютер выбирать поднабор рекомендаций путем применения фильтрующего ограничения. Считываемый компьютером носитель данных, кроме того, включает в себя по меньшей мере одну команду, заставляющую компьютер передавать поднабор рекомендаций по меньшей мере поднабору из множества мобильных устройств.

Согласно еще одному дополнительному аспекту аппарат создает продвижения для пользователя мобильного устройства. Предоставлены средства для обращения к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств. Предоставлены средства для создания рекомендаций для контента, предлагаемых на основе атрибутивных данных, и создания рекомендаций для контента, предлагаемых на основе данных о поведении. Предоставлены средства для выбора поднабора рекомендаций путем применения фильтрующего ограничения. Предоставлены средства для передачи поднабора рекомендаций по меньшей мере поднабору из множества мобильных устройств.

Согласно еще одному аспекту аппарат создает продвижения для пользователя мобильного устройства. Компонента хранения профиля заключает в себе атрибутивные данные и данные о поведении для множества пользователей соответствующего множества мобильных устройств. Система профилей и рекомендаций создает рекомендации для контента, предлагаемые на основе обращения к атрибутивным данным, создает рекомендации для контента, предлагаемые на основе обращения к данным о поведении, и выбирает поднабор рекомендаций путем применения фильтрующего ограничения. модуль сетевой связи передает поднабор рекомендаций по меньшей мере поднабору из множества мобильных устройств.

Краткое описание чертежей

Фиг.1 - блок-схема системы профилирования и рекомендаций в сети мобильной связи согласно одному аспекту;

фиг.2 - временная диаграмма методики профилирования и рекомендаций согласно одному аспекту;

фиг.3 - блок-схема, изображающая примерную систему беспроводной связи, включающую в себя раскрытую здесь систему профилей и рекомендаций согласно одному аспекту;

фиг.4 иллюстрирует блок-схему системы профилей и рекомендаций, где более подробно показаны те компоненты, ассоциированные с мобильным оператором, которые взаимодействуют с системой профилей и рекомендаций, согласно другому аспекту;

фиг.5А - временная диаграмма методики профилирования, которая взаимодействует с внешними сетевыми объектами;

фиг.5В - временная диаграмма методики, иллюстрирующая взаимодействие беспроводного устройства со страницей категорий, созданной системой профилирования и рекомендаций, согласно одному аспекту;

фиг.6 - блок-схема методики для точного целеуказания контента на основе детального понимания привычек и интересов абонентов согласно одному аспекту;

фиг.7 изображает блок-схему основных компонент модуля каталога согласно одному аспекту;

фиг.8 изображает блок-схему основных компонент модуля профилей согласно одному аспекту;

фиг.9 - схема, изображающая четыре фазы процесса создания рекомендаций в модуле принятия решения вместе с блок-схемой методики создания рекомендаций согласно одному аспекту;

фиг.10 иллюстрирует блок-схему методики, суммирующей основные операции для создания рекомендаций согласно еще одному аспекту;

фиг.11 иллюстрирует блок-схему методики субопераций для методики по фиг.10 согласно еще одному аспекту;

фиг.12 иллюстрирует блок-схему методики субопераций, включенных в методику по фиг.11, согласно еще одному аспекту;

фиг.13 изображает блок-схему взаимосвязи между модулями-рекомендателями и контроллером принятия решения согласно одному аспекту;

фиг.14 изображает блок-схему методики обработки в рекомендателях согласно одному аспекту;

фиг.15 изображает примерную схему разных функциональных вызовов в рекомендателе принятия решения согласно другому аспекту;

фиг.16 изображает блок-схему основных компонент модуля принятия решения согласно одному аспекту;

фиг.17 изображает блок-схему основных компонент сетевого рекомендателя согласно одному аспекту;

фиг.18 иллюстрирует блок-схему создания сетевых рекомендаций согласно одному аспекту;

фиг.19 - схема, иллюстрирующая, каким образом модуль принятия решения удовлетворяет требованиям к рабочим характеристикам, используя ряд различных методов, согласно одному аспекту;

фиг.20 изображает блок-схему основных компонент модуля продвижения согласно одному аспекту;

фиг.21 изображает блок-схему методики, выполняемой модулем продвижения, согласно другому аспекту;

фиг.22 - более подробное представление модулей системы профилей и рекомендаций по фиг.4 согласно еще одному аспекту;

фиг.23 иллюстрирует блок-схему вычислительной платформы для выполнения по меньшей мере части методики профилей и рекомендаций согласно одному аспекту; и

фиг.24 иллюстрирует сетевое устройство, имеющее модули для выполнения методики профилей и рекомендаций согласно одному аспекту.

Подробное описание

Ниже подробно описаны разные аспекты изобретения. Очевидно, что описанные здесь принципы могут быть воплощены в широком разнообразии форм и что любая конкретная раскрытая здесь структура или функция является просто представлением. На основе изложенных здесь принципов каждый специалист в данной области техники должен осознавать, что любой раскрытый здесь аспект может быть реализован независимо от других аспектов и что можно разными путями скомбинировать два или более из этих аспектов. Например, аппарат можно реализовать или способ практически воплотить, используя любое количество изложенных здесь аспектов. Вдобавок, можно реализовать аппарат или практически воплотить способ, используя другую структуру или функциональные возможности в дополнение к или вместо одного или нескольких изложенных здесь аспектов. Например, множество описанных здесь способов, устройств, систем и аппаратов описаны в контексте предоставления возможности получения динамичных мобильных доходов в среде мобильной связи. Каждый специалист в данной области техники должен осознавать, что похожие методы можно также применить к другим средам связи.

Используемый в этом изложении термин «контент» используется для описания любого типа приложения, мультимедийного файла, файла изображений, исполняемого файла, программы, web-страницы, скрипта, документа, презентации, сообщения, данных, метаданных либо любого другого типа среды или информации, которую можно воспроизвести, обработать или исполнить на устройстве.

Подразумевается, что используемые в этом изложении термины «компонента», «система», «модуль» и т.п. ссылаются к объекту, имеющему отношение к компьютеру, любым аппаратным средствам, программным средствам, исполняемым программным средствам, программно-аппаратным средствам, межплатформенному программному обеспечению, микрокоду или любой их комбинации. Например, компонентой может быть, но не только: процесс, выполняющийся в процессоре; процессор; объект; исполняемый файл; поток управления; программа или компьютер. Одна или несколько компонент могут находиться в процессе или потоке управления, и компонента может быть локализована на одном компьютере или распределена между двумя или более компьютерами. Также эти компоненты могут исполняться с разных считываемых компьютером сред, имеющих сохраненные на них разные структуры данных. Компоненты могут осуществлять связь друг с другом путем локальных или удаленных процессов, например, в соответствии с сигналом, несущим один или более пакетов данных (например, данные из одной компоненты, взаимодействующие с другой компонентой в локальной системе, распределенной системе или через сеть, такую как Интернет, с другими системами с помощью указанного сигнала). Вдобавок, описанные здесь компоненты систем могут быть перекомпонованы или дополнены дополнительными компонентами, способствующими достижению разных целей, аспектов, преимуществ и т.п., описанных здесь, и они не сводятся к точным конфигурациям, показанным на приведенных чертежах, как должно быть очевидно каждому специалисту в данной области техники.

Вдобавок, разные иллюстративные логические схемы, логические блоки, модули и схемы, описанные в связи с раскрытыми здесь аспектами, могут быть реализованы или выполнены с помощью процессора общего назначения, цифрового процессора сигналов (DSP), специализированной интегральной схемы (ASIC), программируемой вентильной матрицы (FPGA) или иного программируемого логического устройства, дискретного вентиля или транзисторной логики, дискретных аппаратных компонент или любой подходящей их комбинации, разработанной для выполнения описанных здесь функций. Процессор общего назначения может представлять собой микропроцессор, а в альтернативном варианте процессор может представлять собой любой обыкновенный процессор, контроллер, микроконтроллер или конечный автомат. Процессор также можно реализовать в виде комбинации вычислительных устройств, например комбинации процессора DSP и микропроцессора, множества микропроцессоров, одного или более микропроцессоров в сочетании с ядром DSP или любой другой подходящей конфигурации. Вдобавок, по меньшей мере один процессор может содержать один или более модулей, способных выполнять одну или более из описанных здесь операций или действий.

Кроме того, разные аспекты описаны здесь в связи с мобильным устройством. Мобильное устройство также может встречаться под названием: система, абонентский блок, абонентская станция, мобильная станция, мобильный объект, мобильное устройство, сотовое устройство, мультирежимное устройство, удаленная станция, удаленный терминал, терминал доступа, пользовательский терминал, пользовательский агент, пользовательское устройство или пользовательское оборудование или т.п. Абонентская станция может представлять собой сотовый телефон, беспроводный телефон, телефон протокола инициирования сеанса (SIP), станцию беспроводной местной линии (WLL), персональный цифровой помощник (PDA), карманное устройство с возможностями беспроводного соединения или другое обрабатывающее устройство, подсоединенное к беспроводному модему, или похожий механизм, способствующий беспроводной связи с обрабатывающим устройством.

Кроме того, описанные здесь разные аспекты или признаки могут быть реализованы в виде способа, аппарата или изделия с использованием стандартных методов программирования или проектирования. Кроме того, операции или действия способа или алгоритма, описанного в связи с раскрытыми здесь аспектами, могут быть воплощены непосредственно в аппаратном обеспечении, в программном модуле, исполняемом процессором, или в их комбинации. Вдобавок, в некоторых аспектах операции или действия способа или алгоритма могут находиться по меньшей мере в одной любой комбинации или наборе кодов или команд на машиночитаемом носителе или считываемом компьютером носителе, который может являться составной частью компьютерного программного продукта. Кроме того, подразумевается, что используемый здесь термин «изделие» распространяется на компьютерную программу, доступную с любого считываемого компьютером устройства, носителя или среды. Например, считываемая компьютером среда может включать в себя, но не только: магнитные устройства хранения (например, жесткий диск, гибкий диск, магнитные полосы и т.д.), оптические диски (например, компакт-диск (CD), цифровой универсальный диск (DVD) и т.д.), смарт-карты и устройства флэш-памяти (например, карта, стик, флэш-память с ключом и т.д.). Вдобавок, описанная здесь среда хранения разного вида может представлять одно или несколько устройств или другую считываемую машиной среду для хранения информации. Термин «машиночитаемое средство» может включать в себя, но не только, беспроводные каналы или разные другие среды, способные хранить, заключать или переносить команды или данные.

Вдобавок к вышеописанному, термин «примерный» используется здесь в смысле «служащий в качестве примера, случая или иллюстрации». Любой аспект или техническое решение, описанное здесь как «примерное», не обязательно трактовать как предпочтительное или имеющее преимущества перед другими аспектами или разработками. Скорее предполагается, что использование термина «примерный» представляет концепции в конкретном варианте. Кроме того, предполагается, что используемый в этой заявке и прилагаемой формуле изобретения термин «или» означает включающее «или», скорее чем исключающее «или». То есть предполагается, что, если не определено иное или если это не ясно из контекста, то «Х использует А или В» означает любую из естественных включающих перестановок. То есть в этом примере Х мог бы использовать А, Х мог бы использовать В или Х мог бы использовать как А, так и В, и, таким образом, утверждение «Х использует А или В» удовлетворяется для любого из вышеописанных случаев.

Используемые здесь термины «логически выводить» или «логический вывод» относятся в общем случае к процессу рассуждения или умозаключения о состояниях системы, окружения или пользователя исходя из набора наблюдений, зафиксированных через события или данные. Логический вывод можно использовать для идентификации конкретного контекста или действия, либо он может создать, например, распределение вероятностей состояния. Логический вывод может носить вероятностный характер, то есть вычисление распределения вероятностей интересующих состояний на основе учета данных и событий. Логический вывод также может относиться к методам, используемым для создания событий более высокого уровня из набора событий или данных. Такой логический вывод приводит к построению новых событий или действий из набора зарегистрированных событий или сохраненных данных о событиях независимо от того, коррелированны ли эти события в узкой временной области, а также независимо от того, имели ли эти события и данные один или несколько источников событий и данных.

Со ссылкой на фиг.1, настоящие аспекты предоставляют систему 10 профилей и рекомендаций, которая позволяет мобильным операторам 12 сети 14 беспроводной связи и их бизнес-партнерам, изображенным в виде поставщиков 16 контента, активно продвигать потребление контента и услуг в их абонентской базе, изображенной в виде мобильного устройства 18 абонента 20. В одном примере это достигается созданием списка рекомендаций 21, подобранных для частного абонента 20, для доставки на его мобильное устройство 18. Эти рекомендации могут отображаться либо на портале, ассоциированном с мобильным оператором, либо могут быть доставлены на мобильное устройство, например, путем мобильных сообщений.

Согласно одному аспекту сохраненные профильные данные 22 содержат атрибутивные данные 24 или данные 26 о поведении. В соответствии с множеством рекомендателей, изображенных в виде рекомендателя 28 атрибутов и рекомендателя 30 поведения, ассоциируют соответствующие данные 24, 26 с перекрестными ссылками 32 характеризации контента для каталожного индекса 34 контента 36. Предварительные рекомендации от рекомендателей 28, 30 имеют уровень доверия, присвоенный компонентой 38 задания веса доверия. Например, может быть определена слабая или сильная ассоциация. В другом примере атрибут или поведение может быть определено как слабое в результате логического анализа лимитированных появлений или быть определено как сильное через явные взносы или повторяющееся поведение. Затем предварительные взвешенные рекомендации могут быть отсортированы компонентой 40 сортировки.

Перед или после сортировки компонента 42 фильтрации реализует функцию исключения 44 во избежание неподходящей рекомендации. Исключения могут быть в явном виде конкретизированы абонентом 20, как показано по ссылке 46, например запрет некоторых категорий рекомендаций, которые могли бы оказаться нежелательными. Исключения могут задаваться мобильным оператором, как показано по ссылке 48, например, путем задания целей вычислительной платформы, подходящих для контента (например, аудиофайлы, подходящие для мобильного устройства с медиаплеером стандарта MP3). Исключения также можно извлечь из профильных данных 22, изображенных под ссылкой 50, например, путем отслеживания покупок того контента, который, в противном случае, был бы рекомендован снова, или рекомендаций, повторно проигнорированных абонентом 20. Исключения можно также получить у поставщиков 16 контента, которые могут представлять собой мобильный оператор 12, путем предоставления информации 52 о совместимости устройства или программной конфигурации. Тем самым исключаются мобильные устройства 18, которые не смогут успешно использовать рекомендованный контент.

Рекомендации создают путем анализа абонентской информации, доступной мобильному оператору, вместе с предложенными контентом и услугами, с тем чтобы определить тот контент и те услуги, которые, скорее всего, будут представлять наибольший интерес для абонента. В частности, система 10 профилей и рекомендаций также позволяет обеспечить доставку рекомендаций абоненту 20 в те отрезки времени, когда (как было определено ранее) абонент 20 наиболее восприимчив к покупкам, на основе оценки атрибутов или поведения отдельного абонента или абонента, являющегося членом группы. Система профилей и рекомендаций также адаптирована для создания продвижений, когда желательно активно продвигать конкретный контент или услугу в ее абонентскую базу.

На фиг.2 показана методика 50 для профилированных рекомендаций контента, предлагаемого мобильному устройству согласно одному аспекту изобретения. В блоке 52 выполняется каталогизация доступного контента и описываются его характеристики. В блоке 54 поддерживаются пользовательские атрибуты и поведенческие данные. В блоке 56 может быть установлена ассоциация пользователя с атрибутом на основе однорангового (P2P) взаимосвязи с пользователем, для которого был предварительно определен атрибут. Эта непрямая ассоциация может иметь более низкий вес, чем ассоциация, установленная исходя из явно выраженной или прямой информации. В блоке 58 пользователь может быть присоединен к группе, например, на основании регистрации в явном виде, частого подключения портала для группы и т.д. Эта ассоциированная группа может иметь атрибутивные и поведенческие данные, которые затем могут быть использованы для ассоциированного с этой группой пользователя, особенно в случаях, когда получено недостаточно данных, конкретно характеризующих пользователя. В блоке 60 принимается запрос на рекомендации. В блоке 62 по атрибутивным данным создаются запросы на рекомендации для получения позиции для абонентов или абонентов для позиций. В блоке 64 создаются запросы на рекомендации по данным о поведении для получения позиции для абонентов или абонентов для позиции. Эти рекомендации взвешивают путем присваивания каждой из них уровня доверия (блок 66). Взвешенные рекомендации сортируют с тем, чтобы можно было доставить поднабор с максимальным весом (блок 67). Выполняется обращение к исключениям, таким как предыдущая покупка, зафиксированные предыдущие предложения, пользовательские настройки (ограничения), команды оператора, совместимость/конфигурация устройств и т.д. (блок 68). В блоке 70 рекомендации фильтруют путем обращения к используемому исключению. В блоке 72 отфильтрованные и отсортированные рекомендации посылают для представления на мобильном устройстве. В блоке 74 принимают подтверждение о представлении рекомендаций и любом выборе пользователя. С помощью этих данных выполняют обновление отслеживания (блок 76).

Обратимся теперь к фиг.3, где согласно одному аспекту изобретения представлена блок-схема, показывающая примерную систему 100 беспроводной связи, включающую в себя систему 101 профилей и рекомендаций. Система 100 беспроводной связи может включать в себя одно или более беспроводных устройств 102, которые осуществляют связь через беспроводную сеть 103 с контроллером 104 базовой станции (BSC). Беспроводными устройствами 102 могут быть устройства любого подходящего типа, включая, например, карманный персональный компьютер (PC), PDA или мобильный телефон. В свою очередь, контроллер 104 базовой станции осуществляет связь с инфраструктурой связи мобильного оператора, такой как, например, беспроводной шлюз, изображенный в виде шлюза 105 протокола беспроводных приложений (WAP), центр 106 коммутации мультимедийных сообщений (MMSC) и центр 107 коммутации коротких сообщений (SMSC). Системы мобильного оператора также включают в себя сервер 108, сконфигурированный для работы в качестве портала.

В одном случае система 101 профилей и рекомендаций согласно настоящему изобретению имеет линию связи с инфраструктурой связи мобильного оператора. В одном примере система профилей и рекомендаций включает в себя мобильного оператора и ассоциированных с ним бизнес-партнеров для активного продвижения потребления услуг путем обеспечения унифицированного подхода и продвинутого профилирования своей абонентской базы, а также интеллектуальных рекомендаций, как более подробно объясняется ниже.

На фиг.4 согласно одному аспекту показана примерная блок-схема сети 200 профилей и рекомендаций, иллюстрирующая взаимодействия между некоторыми компонентами, ассоциированными с мобильным оператором 202, и системой 101 профилей и рекомендаций согласно настоящему изобретению. Эти системы могут быть непосредственно интегрированы в инфраструктуру 206 связи мобильного оператора, или в альтернативном варианте, могут являться частью системы бизнес партнера, ассоциированного с мобильным оператором. Инфраструктура 206 может включать в себя компоненту 208 информации об услугах и контенте, источник 210 информации о профиле абонента и приложение 212 для рекомендаций, используемое администратором 213. Система 101 профилей и рекомендаций взаимодействует с системой 214 доставки контента, которая может содержать шлюз 105 протокола WAP, центр 107 службы коротких сообщений (SMSC) и центр 106 службы мультимедийных сообщений (MMSC), который, в свою очередь, может осуществлять связь с беспроводными устройствами 102. Система 214 доставки контента обеспечивает функцию доставки контента через соединение с такими сетевыми системами, как шлюзы 105 протокола WAP, центры SMSC 107 и центры MMSC 106. Это позволяет системе 101 профилей и рекомендаций доставлять и принимать мобильный контент или услугу любого типа для пользователей или абонентов 222 беспроводных устройств 102, находящихся на связи с системой 214 доставки контента. Эту функцию можно реализовать там, где система 101 профилей и рекомендаций используется для доставки информации по продвижению контента и услуг (например, через сообщения SMS, MMS, WAP Push и т.д.) и где система 101 профилей и рекомендаций отвечает за доставку контента (например, полифонической мелодии для мобильного телефона, фонового изображения, игр и т.д.).

Компонента 208 информации об услугах и контенте может содержать внешние платформы, такие как служба услуг с добавленной стоимостью (VAS) или портал 226, с которым система 101 профилей и рекомендаций может осуществлять связь. В одном примере интеграция с платформами 226 услуг VAS может облегчить создание полного каталога контента, доступного мобильному абоненту 222 одного или нескольких беспроводных устройств 102. Это позволяет системе 101 профилей и рекомендаций обеспечить более эффективную розничную продажу имеющегося контента или услуг с помощью мобильного оператора или его партнера. Интеграция с порталом 226 позволяет обеспечить доставку целевых продвижений тем пользователям или абонентам 222, которые используют портал 226, и позволяет обеспечить фиксацию информационной компоненты 228 об их поведении для последующего обращения за справками к источнику 210 информации о профиле абонента. В одном случае информация 228 о профиле абонента включает в себя одно или более из следующих данных вызова: пол, дата рождения, прошлые покупки, проявления заинтересованности или незаинтересованности, манера тратить деньги, тип мобильного устройства, текущее географическое положение, частота звонков или другие метаданные.

На фиг.4 приведены дополнительные подробности основных иллюстративных компонент системы 101 профилей и рекомендаций согласно одному аспекту изобретения. Они включают в себя модуль 230 каталога, модуль 232 профилей, модуль 234 принятия решения и модуль 236 продвижений. Каждый из этих модулей более подробно описывается ниже. Модуль каталога 230 позволяет системе 101 профилей и рекомендаций использовать его в качестве центрального каталога для большого объема контента или услуг. Таким образом, другим системам (например, портал и т.д.) может быть представлена более подробная картина доступного контента/услуг, что позволяет обеспечить более качественное управление процессом розничной продажи контента.

Согласно одному примеру каталог 238 оператора, поддерживаемый мобильным оператором в централизованном месте, может включать в себя полный каталог услуг передачи данных, речи и иных услуг, предоставляемых оператором. В одном случае модуль 230 каталога может поддерживать коды и структуры 240 идентификаторов продуктов, которые определены в центральном каталоге 238 мобильного оператора.

Как показано на фиг.5А, при использовании методика 300 для создания профилей и рекомендаций в одном примере взаимодействует с внешними сетевыми объектами, показанными в виде источника 302 информации о профиле абонента. В свою очередь, информация о профиле абонента связана с существующей биллинговой системой 304 мобильного оператора и системой 306 управления взаимосвязью с потребителем (CRM). Система 308 профилей и рекомендаций выполняет интеграцию биллинговых операций, отвечая за доставку контента пользователю или беспроводному устройству 312 абонента.

Согласно другому аспекту, показанному на фиг.5В, методика 358 показывает, как беспроводное устройство 360 обращается к беспроводному шлюзу 362 для приема рекомендаций на странице категорий, созданной системой 304 профилей и рекомендаций. Как показано под ссылкой 366, беспроводное устройство 360 делает запрос на просмотр страницы категорий от беспроводного шлюза 362, который, в свою очередь, направляет запрос на рекомендации в систему 364 профилей и рекомендаций, как показано под ссылкой 368. Рекомендации создаются и возвращаются на беспроводной шлюз 362, как показано под ссылкой 370, который, в свою очередь, отображает эти рекомендации на странице категорий в беспроводном устройстве 360, как показано под ссылкой 372. Когда пользователь выберет на странице категорий рекомендованную позицию, этот выбор передается на беспроводной шлюз 362, как показано под ссылкой 374. Беспроводной шлюз 362 обеспечивает обратную связь по просмотровым действиям, как показано под ссылкой 376, в систему 364 профилей и рекомендаций. Пользователь беспроводного устройства 360 может выдать запрос на дополнительный просмотр страницы категорий, как показано под ссылкой 378, который передается на беспроводной шлюз 362. Как показано под ссылкой 380, беспроводный шлюз 362 запрашивает рекомендации, чтобы заполнить страницу категорий, а система 364, в свою очередь, как показано под ссылкой 382, отвечает новыми рекомендациями для страницы категорий, которые отражают последние просмотровые действия, такие как аннулирование уже приобретенной позиции или позиции, предложенной больше заданного числа раз, либо добавление позиции, относящейся к выбранной рекомендованной позиции.

Вновь обратимся к фиг.5А, где система 308 профилей и рекомендаций может поддерживать диапазон биллинговых сценариев в виде интерфейса прикладного программирования (API) к биллинговым системам 304, специализированным для конкретных потребителей. Беспроводное устройство 312 передает в биллинговую систему 304 запрос на информацию в реальном времени, как показано под ссылкой 320, что позволяет выполнять запросы баланса в реальном времени, фиксировать случаи покупок, например подписку на новый контент с уведомлением, а также используемые балансы (например, для первых трех месяцев по новому контракту абонент может загрузить на месяц две игры бесплатно и т.д.). Таким образом, биллинговая система 304 передает на беспроводное устройство 312 подтверждение информации или транзакции, как показано под ссылкой 324. Режим реального времени указанного интерфейса API, реализуемый системой 308 профилей и рекомендаций, обеспечивает эффективное управление балансами абонентов и минимизацию потерь доходов.

Согласно одному примеру, как показано в блоке 328, система 308 профилей и рекомендаций может использовать тарифные коды при создании записей данных вызовов (CDR) для биллинговых функций, которые передаются в биллинговую систему 304, как показано под ссылкой 330. Эти коды задаются пользователем и могут быть ассоциированы со всем контентом, поступающим от источника контента. Согласно одному аспекту этот интерфейс может также поддерживать множество выходов форматов CDR. Вдобавок к базовой информации о тарифных кодах он может также включать в себя описания реального контента, которые могут быть включены в счет абонента. Он может также управлять биллинговыми ярлыками для информации, имеющей нулевой или специальный рейтинг. Согласно одной реализации, как показано в блоке 332, система 308 профилей и рекомендаций также может обрабатывать данные об оплате, чтобы помочь мобильному оператору установить различие между ценами за актуальный контент в зависимости от полосы пропускания, используемой для доставки контента, которые передаются в биллинговую систему 304, как показано под ссылкой 334. Также можно дифференцировать оптовую и розничную цену для сообщения о том, сколько мобильный оператор должен поставщику контента.

Система 308 профилей и рекомендаций, кроме того, способна дать возможность множеству агентов подавать данные либо в модуль 232 профилей (фиг.4), либо в модуль 230 каталога (фиг.4). Например, можно сконфигурировать один агент 336 для приема атрибутивной информации о пользователе или абоненте, как показано под ссылкой 338, из системы CRM 306 и другой агент 340 для приема предыстории покупок пользователя или абонента, как показано под ссылкой 342, от биллинговой системы 304.

Приложение 212 для рекомендаций обеспечивает средство, с помощью которого система 308 профилей и рекомендаций может взаимодействовать с внешним приложением, через которое может осуществляться администрирование всех аспектов системы 308 профилей и рекомендаций, таких как, например, управление продвижениями, каталогом и контентом. Согласно одному аспекту это может быть пользовательский интерфейс на основе web-сети (не показан), доступный для администраторов, которыми могут быть служащие мобильного оператора или ассоциированные бизнес-партнеры, например партнеры по контенту. Многие функции этого приложения 344 для рекомендаций будут понятны из приведенного ниже описания со ссылками на различные модули системы 308 профилей и рекомендаций.

Как показано под ссылкой 346, копия контентного каталога с управлением версий может экспортироваться в место 348 расположения центрального каталога. Согласно одному аспекту система 308 профилей и рекомендаций, поддерживающая данные о контенте в центральном каталоге продуктов в блоке 350, позволяет системе 308 профилей и рекомендаций экспортировать формат XML модуля 230 каталога в место 348 расположения центрального каталога, как показано под ссылкой 352. Таким путем согласно одному примеру все детали заранее сохраняются, и ни одна из позиций согласно переиндексации контента не может пропасть.

Обратимся к фиг.6, где согласно одному варианту реализации методика 400 для профилирования пользователей и абонентов реализуется посредством детального изучения привычек и интересов абонентов (выясняемых через модуль 232 профилей (фиг.4) и подробный каталог контента). Построение такого подробного каталога контента становится возможным посредством определения метаданных. В одном примере модуль 230 каталога (фиг.4) способен создавать единый вид всего контента или услуг, доступных через мобильных операторов и ассоциированных бизнес-партнеров (блок 402). Вдобавок, модуль 230 каталога может идентифицировать контент или услуги, поддерживаемые каждым устройством (блок 404). Модуль 230 каталога может дополнительно идентифицировать взаимосвязь между контентом и услугами (блок 406). Вдобавок модуль каталога может ассоциировать абонентские сегменты с каждым контентом или услугой (блок 408). Модуль каталога 230, кроме того, может скомбинировать подробную целевую информацию (блок 410) о том, к каким абонентским сегментам применим каждый контент или услуга, о взаимосвязях между контентом или услугами и о том, какие устройства поддерживают контент или услугу, а также информацию об их использовании.

Согласно одному примеру модуль 230 каталога обеспечивает базовый набор определений метаданных (блок 412) и задает дополнительный неограниченный диапазон метаданных для каждого отдельного фрагмента контента или услуги (блок 414). Чем больше диапазон элементов метаданных, определенных для позиций контента или услуг, тем больше имеется опций с точки зрения группирования контента или услуг (в ресурсные группы) и для отображения контента или услуг пользователям или абонентам с различными интересами. Согласно одному примеру, не являющемуся ограничением, эти метаданные могут, среди прочего, задавать объем данных, информацию о ценах (розничных и расчетных), контент для взрослых, метки продвижения, местоположение контента (хранящегося на месте или удаленного) и т.д.

Модуль 230 каталога можно реализовать в ситуациях, когда имеются сохраненные метаданные о контенте или услугах или когда он дополнительно сохраняет некоторый или весь контент или саму услугу (например, мелодии для сотового телефона, фоновые изображения и т.д.). В последнем случае можно также развернуть модуль контента, способный осуществлять управление и доставку локально сохраненного контента (блок 416). В одной примерной конфигурации, где сам контент не сохраняется, модуль 230 контента может поддерживать одну или несколько ссылок на то место, где можно обнаружить контент (блок 418). В любом случае своевременно предоставленная и точная совокупность метаданных контента позволяет эффективно функционировать модулям системы 101 профилей и рекомендаций (фиг.4).

На фиг.7 показана блок-схема основных компонент модуля 230 каталога согласно одному аспекту изобретения. Эти компоненты содержат модуль 501 группирования контента, модуль 502 поиска, модуль 503 управления контентом, модуль 504 базы данных контента и модуль 505 поглощения контента. Функциональные возможности каждого из этих модулей более подробно объясняются ниже.

Согласно одному аспекту модуль 501 группирования контента может обеспечить группирование ресурсов для портала. Группирование ресурсов позволяет создавать страницы, привязанные к теме контента, пользовательскому или абонентскому тарифу и возможностям мобильного устройства. Модуль 230 каталога может автоматически консолидировать весь контент или услуги от множества источников (например, фильм как одну ресурсную группу и т.д.). В другом примере может иметь место ресурсная группа для поп-артисток, которым подходит мелодия Бритни Спирс для сотового телефона. Также может быть ресурсная группа для Бритни Спирс, которой подходит та же мелодия, хотя эта же мелодия также может подходить к ресурсной группе для мелодий из десятки самых популярных. Создание ресурсных групп основано на группировании вокруг метаданных и в диапазоне ресурсных групп, которым подходит часть контента. Согласно одному аспекту создание ресурсных групп для некоторой позиции контента с помощью модуля 501 группирования контента может быть ограничено количеством меток метаданных, определенных для этой позиции контента.

Согласно одному аспекту модуль 502 поиска обеспечивает встроенный механизм поиска, который выполняет функцию поиска контента на основе ключевых слов. Действие этого механизма основано на построении индекса поиска исходя их метаданных контента. Можно сконфигурировать точные поля метаданных, на которых может выполняться поиск. Например, модуль 502 поиска обеспечивает поиск с использованием общих полей поиска, таких как «артист» и «название», а также других полей, таких как «стоимость». Индекс поиска обновляется с конфигурируемыми периодами исходя из каталожных данных.

Согласно одному аспекту мобильное устройство способно выполнять абстрактное отображение между категорией контента и устройствами, поддерживающими этот контент. Например, функцию устройства под именем «MMS 30K» можно использовать для отслеживания устройств, которые поддерживают MMS-сообщения в пределах 30 кбайт. В одном варианте реализации система 101 профилей и рекомендаций может отслеживать те устройства 102, которые поддерживают эту функцию, и позиции контента, для которых требуется эта функция. Затем можно запросить модуль 230 каталога с помощью модуля 502 поиска на предмет контента, который поддерживается конкретным устройством. В одном случае это может быть обеспечено порталом. Таким путем пользователям и абонентам не предлагается контент, который несовместим с их мобильными устройствами. Вдобавок, также может быть предусмотрена функция устройства под именем «MMS 100K». В одном случае, где устройство может иметь обе функции, приоритет может быть отдан наиболее подходящей функции, в данном случае это версия 100К. Согласно одному аспекту информация о контенте приобретается с помощью модуля 505 поглощения контента. При извлечении информации для конкретного пользователя или абонента система 101 профилей и рекомендаций передаст контент, наиболее подходящий для устройства этого пользователя или абонента.

При разворачивании модуля 232 профилей система 101 профилей и рекомендаций может следить за тем, какой контент является наиболее популярным в рамках определенных категорий. Затем эта информация сообщается на портал для создания таких категорий, как «10 самых популярных игр» или «10 самых популярных игр класса «Аркада». Если информация о привычках из модуля 232 профилей недоступна, то тогда модуль 230 каталога может иметь рейтинг популярности контента, заданный в явном виде, который можно получить от внешней системы, имеющей такую информацию, или он может быть установлен вручную администратором 213. В одном случае контенты для модуля 230 каталога сохраняются в модуле 504 базы данных контента. Они могут распространяться благодаря связи между модулем 230 каталога и услугами и блоком 208 информации о контенте (например, портал и т.д.) для извлечения доступного контента или услуг. Приложение 212 для рекомендаций позволяет администратору 213 в виде авторизованных пользователей (например, поставщики контента) управлять метаданными, ассоциированными с контентом, которые поставщик контента добавляет в модуль 230 каталога путем установления связи с модулем 503 управления контентом. Согласно одному примеру также предусмотрен интерфейс XML API, который позволяет выполнять массовую загрузку обновлений контента. Через эти интерфейсы администратор 213 может сформировать информацию о контенте, например, о том, где хранится контент (например, на месте или удаленно и т.д.), о том, какую цену запрашивает поставщик контента за данный контент, и т.д. Согласно одному примеру поставщик контента также может создать базовые продвижения, которые позволят поставщику контента определить варианты возможного предоставления скидки на контент или услугу для мобильного оператора, пользователей или абонентов. Кроме того, указанный интерфейс может собирать статистику в реальном времени об использовании контента и статусе доставки контента, а также активности абонентов.

При загрузке каталожных данных в модуль 504 базы данных контента в одном примере можно задать каталожную зону. Если такая зона задана, то ее (их) можно затем использовать для разбивки каталожных данных на различные участки. В одном примере каталожную зону можно использовать для разбивки позиций контента на различные области, так чтобы рекомендации предоставлялись для конкретной подсекции контента. Например, все источники музыкального контента могут быть сведены в каталожную зону «Музыка», а все источники игрового контента могут быть сведены в каталожную зону «Игры». При запросе рекомендации может быть определена конкретная каталожная зона с тем, чтобы передать рекомендованные позиции только из этой каталожной зоны (то есть получить только музыкальные рекомендации путем задания каталожной зоны «Музыка» или получить только рекомендации по играм путем задания каталожной зоны «Игры»). В одном примере, когда каталожная зона не задана, рекомендации поступают из всех каталожных зон (например, в данном случае «Игры» и «Музыка»).

Вновь обратимся к фиг.4, где модуль 232 профилей обеспечивает активный механизм для профилирования онлайнового поведения абонентов или пользователей, сегментацию, выявляет интересы, наиболее вероятный характер трат, особенности устройства, дни рождения, юбилеи, периоды наиболее интенсивного использования и т.д., что позволяет обеспечить взаимную однозначность продвижений и услуг. Модуль 232 профилей обеспечивает данные, необходимые модулю 234 принятия решения для выдачи интеллектуальных рекомендаций. В одном случае, чем разнообразнее данные, заключенные в модуле 232 профилей, и чем они более релевантные, тем выше качество рекомендаций.

На фиг.8 представлена блок-схема основных компонент модуля 232 профилей согласно другому аспекту, содержащая модуль 601 базы данных профилей, модуль 602 управления профилями, модуль 603 группирования профилей и модуль 604 поглощения профилей. Функциональные возможности каждого из этих модулей более подробно описаны ниже.

Согласно одному примеру модуль 232 профилей по умолчанию может включать в себя метаданные, необходимые для фиксирования множества наиболее общих подробностей о пользователе или абоненте с точки зрения действительных атрибутов абонента (например, предоплата и оплата по факту), и информацию о предыстории покупок. Модуль 232 профилей может дополнительно обеспечить возможность легкого расширения стандартной модели данных профиля абонента для удовлетворения конкретных требований.

Обратимся к фиг.4 и 8, где в одном примере с помощью приложения 212 для рекомендаций, находящегося на связи с модулем 602 управления профилем, администратор 213 может определить поля новых метаданных, соответствующий тип данных, имеют ли поля новых метаданных свободную форму, или они взяты из фиксированного списка, и являются ли поля новых метаданных обязательными. Затем новые метаданные можно использовать тем же способом, что и стандартные метаданные в таких областях, как профильные группы, принятие решения, импорт и экспорт профильных данных. Таким образом, администратор 213 может подогнать профильную информацию, чтобы лучше адаптировать ее к желаемому способу использования администратором 213 системы и процесса импортирования/экспортирования профильных данных из внешних систем, имеющих уже существующие метаданные.

Обратимся к фиг.8, где модуль 603 группирования профилей дополнительно обеспечивает функциональные возможности для создания и управления профильными группами на основе информации, сохраненной в модуле 601 базы данных профиля. В одном примере в этих группах содержатся пользователи или абоненты с общими атрибутами или поведением при покупках. В одном примере такие группы могут создаваться с использованием одного или нескольких из следующих механизмов: (А) Импортирование списков пользователей или абонентов из источника информации о профилях абонентов, такого как система CRM. Это может быть процесс импорта файлов, выполняемый вручную или автоматически через соединительный модуль; (В) Категоризация пользователей или абонентов по конкретному фрагменту (фрагментам) профильных метаданных (например, все мужчины, абоненты с предоплатой и т.д.); (С) Анализ использования системы в прошлом (например, абоненты, закупившие или не закупившие конкретный фрагмент или категорию контента, и т.д.); и (D) Категоризация абонентов по типам имеющихся у них устройств (например, устройства с функцией MMS и т.д.). Согласно одному примеру группы могут быть заданы статическим образом на конкретный период времени (например, пользователи или абоненты, закупившие игру на декабрь 2004 года и т.д.) или могут быть динамическими (например, пользователи или абоненты, не закупившие мелодию для мобильного телефона за последний месяц и т.д.).

Вновь обратимся к фиг.4, где в одном примере профильные группы могут оказаться полезными в следующих случаях: (А) Онлайновые продвижения, где модуль 236 продвижения может использовать профильные группы для определения того, какие абоненты заинтересуются конкретным баннером, и определения того, когда абонент посещает портал. Например, может быть создана абонентская группа, которая заключает в себе всех абонентов, имеющих SMS-предупреждение и мобильное устройство 102 с функцией MMS. Это можно использовать для предложения этим пользователям или абонентам 222 услуг MMS-предупреждений в следующий раз, когда пользователь или абонент 222 посетит портал 226; (В) Исходящие продвижения, где модуль 236 стимуляции может использовать профильные группы для определения тех пользователей или абонентов 222, которым следует послать исходящее продвижение посредством сообщений SMS, MMS, WAP-Push и т.д. Например, может быть создана абонентская группа, заключающая в себе всех пользователей или абонентов 222, которые приобрели услугу «FIFA 2004». Это можно использовать для активизации исходящего продвижения для услуги «FIFA 2005»; (С) Детали профильных групп могут быть экспортированы во внешнюю систему для обновления централизованной системы (например, источник 210 профильной информации абонента, такой как CRM или хранилище данных и т.д.), и содействия таким образом процессу поддержания консолидированной абонентской базы данных (не показана); и (D) Профильные группы можно использовать при проведении кампаний по продвижению для групп по интересам, где пользователи или абоненты 222 могут согласиться принимать информацию, касающуюся новых продвижений или услуг. В одном примере модуль 236 продвижения способен автоматически управлять возможностью согласия или отказа пользователя или абонента получать указанную информацию.

В одном примере также можно непрерывно подсчитывать количество контактов на одного абонента и поддерживать предпочтительный способ контакта с пользователем или абонентом. Согласно одному примеру необходимость в этом может возникнуть по регулятивным причинам или согласно стратегии мобильного оператора, реализуемой при контактах с пользователем. Это может быть использовано для того, чтобы пользователи или абоненты с широким кругом интересов были ограждены от информации, касающейся продвижения тех или иных услуг, на конкретных временных отрезках. Запись предпочтительного способа контактов с абонентом может гарантировать предоставление указанной информации пользователю или абоненту таким образом, чтобы вызвать его позитивный отклик с максимальной вероятностью.

Согласно одному аспекту одной из функций модуля 232 профилей является эффективное хранение атрибутов пользователей или абонентов, а также предыстории их покупок в модуле 601 базы данных профилей для последующего извлечения с помощью модуля 604 поглощения профиля, когда это необходимо. В одном случае механизм сохранения сконфигурирован таким образом, что он способен сохранять большие объемы данных таким путем, который обеспечивает высокоэффективные обновления и доступ к данным. Согласно одному аспекту можно использовать реляционную базу данных Oracle для хранения всех данных платформы, включая профильные данные. В другом случае специализированный, но при этом облегченный уровень доступа к данным, использующий присущую подключаемость интерфейсов API Oracle (например, подключаемость баз данных Java (JDBC), интерфейса вызовов Oracle (OCI) и т.д.), подсоединяется к базе данных эффективным способом. В одном случае также можно использовать такие методы, как выполнение операций через множество соединений баз данных, использование заранее подготовленных операторов структурированного языка очередей (SQL), и интеллектуальное кэширование данных. Уровень доступа к данным может инкапсулировать в себе конкретные механизмы хранения из других частей платформы, обеспечивая очищенный уровень, на котором строятся функциональные возможности профиля.

Вдобавок, в одном примере для функции модуля 232 профилей для расширения метаданных может потребоваться, чтобы модуль 601 базы данных профилей был способен управлять определениями метаданных и их ассоциированными значениями. Эта возможность может быть обеспечена посредством библиотеки меток метаданных, которая позволяет определить атрибуты новых метаданных любым системным объектом. В одном примере это используется совместно модулем 232 профилей и модулем 230 каталога.

Согласно одному аспекту профильные данные могут появляться либо из внешних систем (например, блок источника информации и профиля абонента), либо из информации, созданной системой 101 профилей и рекомендаций. Данные от внешних систем могут подаваться в модуль 601 базы данных профилей через соединительный модуль (на фиг.4 не показан). Согласно одному аспекту эти данные могут относиться к пользовательским или абонентским атрибутам и могут включать в себя информацию об их использовании, если это имело место.

В одном варианте реализации степень независимого распространения профильной информации системой 101 профилей и рекомендаций может зависеть от развернутых в системе модулей и способа их использования. Например, если для доставки некоторого контента или услуг используется контентный модуль, то тогда информация об использовании этих услуг может автоматически записываться в модуле 601 базы данных профилей. Если система 101 профилей и рекомендаций (фиг.4) интегрирована с компонентой 208 информации об услугах и контенте (например, портал 226 и т.д.) таким образом, что блок информации об услугах и контенте сообщает системе 101 профилей и рекомендаций о покупках пользователей или абонентов, то такая информация также может быть записана. В одном примере при загрузке профильных данных в модуль 601 базы данных профилей возможна привязка этих данных к профильной зоне. Согласно одному примеру, если задана профильная зона (зоны), то ее можно затем использовать для сегментации данных пользовательской или абонентской транзакции на различные части. В одном случае профильную зону можно использовать для разделения абонентских транзакций на отдельные части, с тем чтобы рекомендации давались с использованием данных из определенной части. Например, если в систему были загружены данные транзакции от двух операторов (например, оператор мобильной виртуальной сети (MVNO)), то тогда транзакциям от каждого оператора могут быть заданы разные значения профильной зоны.

Обратимся к фиг.9, где согласно одному аспекту изобретения показана методика 700 создания рекомендаций, которая имеет автономную фазу I, выполняющую предварительную подготовку (блок 702), включая создание агрегатных данных. Последующие три процесса в реальном времени включают в себя фазу II, которая выполняет индивидуальный выбор (блок 704). Фаза III выполняет взвешивание (блок 706) для маркетинга на основе глубокого понимания потребностей пользователя. Фаза IV выполняет фильтрацию (блок 708) для представления на основе определенных правил.

Вновь обратимся к фиг.4 и 8, где во время обработки на фазе I «Подготовка» модуль 234 принятия решения создает данные отдельно для каждой профильной зоны, а также зону по умолчанию, в которой комбинируются все данные. При запросе рекомендаций требуемая профильная зона может быть выбрана на пользовательском интерфейсе (UI) или задана в вызове API. Если при запросе рекомендации модулем 604 поглощения профиля профильная зона не задана, то тогда можно использовать данные из зоны по умолчанию.

Модуль 234 принятия решения используют для рекомендации наилучшего предложения пользователям или абонентам. Согласно одному варианту реализации последнее отличается от модуля 236 продвижения, где механизм выбора наилучшего предложения администратора 213 использует фиксированное количество предварительно определенных продвижений и несколько заранее определенных профильных групп. Согласно одному примеру при использовании модуля 234 принятия решения можно автоматически создать наиболее подходящее предложение без использования ручной конфигурации.

Вновь обратимся к фиг.4, где путем использованию модуля 234 принятия решения и унифицированного вида имеющегося контента и услуг может быть достигнуто высококачественное соответствие наиболее подходящего контента или услуги с отдельным пользователем или абонентом с учетом таких факторов, как используемое беспроводное устройство 102; демографические характеристики абонентов или пользователей; предшествующее поведение при покупках; каким образом предшествующее поведение пользователя или абонента при покупках связано с привычками других аналогичных абонентов совершать покупки, доступные средства и т.д. Такой уникальный и широкий диапазон критериев при принятии решения гарантирует, что пользователю или абоненту 222 будет предложен и представлен контент, подходящий именно для него.

Модуль 234 принятия решения для создания рекомендаций, кроме того, использует информацию о продукте, имеющуюся в модуле 230 каталога, вместе с информацией об абоненте, имеющейся в модуле 232 профилей. Согласно одному аспекту, чем больше будет информации, доступной этим модулям, тем лучше будут рекомендации, которые сможет предложить модуль 234 принятия решения.

Согласно одному аспекту модуль 234 принятия решения использует фактически всю информацию, собранную модулем 230 каталога и модулем 232 профилей, для своевременного представления соответствующего контента или услуг, интересующих пользователей или абонентов 222, а также для соответствующих продвижений. Таким образом, модуль 234 принятия решения несет в себе возможности самообучения, которые позволяют мобильным операторам, по существу, автоматически обеспечить максимум продаж каждый раз, когда пользователь или абонент 222 использует контент или услуги мобильного оператора.

Согласно одному или нескольким аспектам, не являющимся ограничениями, модуль 234 принятия решений используется в следующих случаях: (А) Выбор наилучшего варианта продвижения (определенного модулем 236 продвижения) для абонента, когда абонент обращается к порталу, и запрашивается система 101 профилей и рекомендаций на предмет предложения наиболее подходящего варианта продвижения; (В) Выбор контента или услуги (хранящихся в модуле 230 каталога) для пользователя или абонента вместо фрагмента контента, выбираемого путем продвижения, созданного в явном виде. Последнее исключает требование к администратору 213 создавать продвижения в явном виде при наличии подробного каталога; (С) Выбор оптимальных пользователей или абонентов, на которых нацелено продвижение. Последнее выполняется при выборе целевого списка пользователей или абонентов для исходящего продвижения. В одном примере модуль 234 принятия решения может идентифицировать тех пользователей или абонентов, которые по определению модуля 234 принятия решения позитивно откликнутся на продвижение с минимальной степенью достоверности; (D) Выбор наилучшего предложения, которое делается группе пользователей или абонентов, причем предлагаемый контент или услугу выбирают из модуля 230 каталога, а не из конкретного варианта продвижения. В одном случае, начиная с идентифицированной группы пользователей или абонентов 222, модуль 234 принятия решения идентифицирует оптимальную позицию контента или оптимальную услугу, предлагаемую каждому пользователю или абоненту 222, из модуля 230 каталога, выбирая те позиции контента, вероятность вызывания позитивного отклика, на которые превышает заданный минимум; (Е) Перекрестная продажа контента или услуги на основе уже купленных позиций. Модуль 234 принятия решения может использовать информацию о последней покупке абонента для идентификации другой позиции контента или услуги, которую также следует рекомендовать пользователю или абоненту 222. Затем этот контент или услугу можно рекомендовать пользователю или абоненту 222 на портале или посредством автоматически исходящего продвижения сразу после совершения покупки.

Вновь обратимся к фиг.9, где представлена схема, изображающая четыре фазы методики 700 создания рекомендаций в модуле принятия решения согласно одному аспекту изобретения. Этими четырьмя фазами являются: фаза I - подготовка (702), фаза II - выбор (704), фаза III - взвешивание (706) и фаза IV - фильтрация (708).

Во время фазы I (участок 702 подготовки в методике 700) проверяют данные (блок 710), аккумулированные в системе 101 профилей и рекомендаций, а также у ассоциированных бизнес-партнеров, а затем вычисляют (блок 712) общие поведенческие тренды, ассоциации и шаблоны. В одном примере в методике 702 подготовки на фазе I выполняют аккумулирование данных на агрегатном уровне в отличие от индивидуального уровня (блок 714). Методика 702 подготовки на фазе I может выполняться периодически в автономном/фоновом процессе (блок 716). Частота выполнения фазы I 702 может зависеть от частоты обновления данных. Так как каждый рекомендатель (алгоритм) принятия решения имеет свою собственную подготовительную фазу, рекомендатели принятия решения могут быть настроены на работу с частотами, подходящими каждому рекомендателю. Дополнительная информация, относящаяся к каждому рекомендателю принятия решений, представлена ниже в связи с фиг.13-16. Согласно одному иллюстративному примеру вывод информации осуществляется в их собственные базы данных (блок 718). Согласно другому примеру данные могут аккумулироваться в модулях 232 профилей и 230 каталога соответственно, из которых также приобретались входные данные. Специалистам в данной области техники должно быть ясно, что согласно другому аспекту могут аккумулироваться данные из любого другого подходящего источника.

На интервале 704 выбора на фазе II в методике 700 модуль 234 принятия решения может обратиться к конкретной информации о конкретном человеке (например, демографические характеристики, прошлые покупки, предпочтения и т.д.) (блок 720), а алгоритмы рекомендаций модуля принятия решений выбирают рекомендации (блок 722) для отдельного пользователя или абонента. В одном случае модуль 234 принятия решения может создать большой (подробный) список рекомендаций, упорядоченный по уровню доверия (блок 724).

В ходе выполнения методики 706 взвешивания на фазе III модуль 234 принятия решения может предоставить администратору 213, поставщику контента или мобильному оператору возможность задать позиции, которые должны быть приоритетными/неприоритетными с точки зрения вероятности их рекомендации пользователю или абоненту (блок 728). В одном примерном случае использования может оказаться желательным продвигать некоторый контент и услугу в конкретные дни (например, Рождество) или продвигать определенных знаменитых артистов (блок 730). Во время фазы III (706) для переупорядочивания списка рекомендаций абоненту перед переходом к следующей фазе используют информацию о взвешивании (блок 732).

Во время выполнения фазы IV - фильтрации (708) модуль 234 принятия решения берет список рекомендаций, созданный на фазе II, и может выполнить фильтрацию на основе последних покупок и совместимости устройства (блок 733), и конкретизирует результат, привязывая его к определенному контексту в вызывающем приложении (блок 734). Например, может оказаться желательным передать только рекомендации по конкретному артисту, типу контента, жанру или стоимости (блок 736). Также можно отфильтровать позиции, уже рекомендованные пользователю или абоненту определенное число раз (блок 738). Согласно одному примеру вызывающее приложение задает критерии фильтрации, как часть вызова API (блок 740), который показан на схеме до блока 734. Также можно задать такие системные критерии фильтрации, как максимально допустимое количество рекомендаций любой позиции любому отдельному пользователю (блок 741), изображенный вслед за блоком 738, после чего следует обновление отслеживания рекомендаций для будущих подсчетов количества предложений одной рекомендации абоненту (блок 742).

Согласно одному аспекту, когда фаза I (702) не работает на уровне отдельного абонента, фазы II (704), III (706) и IV (708) работают на уровне отдельного абонента, причем фазы II (704), III (706) и IV (708) используют данные отдельного абонента для создания адресных рекомендаций. То есть используют сохраненные профильные данные, содержащие профильные данные 750 отдельного пользователя или абонента, атрибуты 754 пользователя или абонента (например, пол, сегмент и т.д.) и информацию 756 о предыстории пользователя или абонента (например, покупки и т.д.), как показано на фиг.8. Профильные данные 750 также могут содержать входные данные/обратную связь 758 от пользователя/абонента. Вдобавок, модуль 234 принятия решения может использовать определенную информацию, специфичную для данного абонента, что показано в виде фильтров 760 предпочтений для автоматической фильтрации результатов. Согласно одному примеру примерными фильтрами 760 являются: (А) Тип и модель 762 мобильного устройства абонента, - когда указанная информация задана, модуль принятия решения обеспечивает рекомендацию только того контента или услуги, которая может быть реализована на устройстве абонента; (В) Блокирование прошлых покупок (764) - модуль 234 принятия решения обеспечивает, чтобы абоненту не была рекомендована позиция, которую он уже купил; (С) Обратная связь с негативной оценкой в прошлом (766) - модуль 234 принятия решения обеспечивает, чтобы абоненту не была рекомендована позиция, которой он уже дал в прошлом негативную оценку; (D) Регламентированный контент 768 - позиции могут быть отмечены как регламентированные, означая, что указанные позиции не следует рекомендовать, пока абонент явным образом не решит получить указанный контент (например, контент для совершеннолетних и т.д.). Следует сказать, что модуль 234 принятия решения при создании рекомендации может использовать информацию в реальном времени. Например, если пользователь или абонент покупает или просматривает какую-то позицию на портале, это может немедленно повлиять на рекомендации, представляемые этому пользователю или абоненту. В указанном примере такие события в реальном времени могут быть представлены в систему 101 профилей и рекомендаций через соответствующий вызов API, а не через интерфейс API модуля 232 профилей. В альтернативном варианте профильный интерфейс API можно использовать только для посылки информации о покупках.

На фиг.10 показана методика 800, которая суммирует основные операции в процессе создания рекомендаций согласно одному аспекту изобретения. В блоке 802 внешнее (вызывающее) приложение запрашивает рекомендацию для абонента из системы профилей и рекомендаций, что может повлечь за собой передачу контекста или других параметров. В блоке 804 приобретаются данные, аккумулированные во время фазы подготовки (описанной ранее в связи с фиг.9), ассоциированные с конкретным абонентом. В блоке 806 модуль принятия решения создает множество рекомендаций для абонента на основе извлеченных данных. В блоке 808 уточняются рекомендации, созданные в блоке 806, для получения окончательного списка рекомендаций для абонента. В блоке 810 этот окончательный список рекомендаций возвращают во внешнее приложение. В одном случае внешнее приложение может затем послать созданные рекомендации пользователю или абоненту либо в онлайновом режиме через портал, либо в исходящем режиме посредством сообщения SMS, MMS, WAP Push или с помощью любого подходящего механизма на мобильное устройство пользователя или абонента.

Обратимся к фиг.11, где согласно одному примеру показана блок-схема, включающая в себя дополнительные субоперации в операциях с 804 по 808 блок-схемы на фиг.10. В блоке 902 приобретаются данные из модуля данных, ассоциированного с пользователем или абонентом, где модуль данных построен по результатам периодического контроля сохраненных данных, относящихся к пользователю или абоненту. В блоке 904 осуществляется ввод этих данных во множество алгоритмов рекомендаций, каждый из которых вычисляет в реальном времени рекомендации для абонента. Результирующие рекомендации комбинируются для формирования подробного списка рекомендаций. В блоке 906 подробный список рекомендаций упорядочивается по уровню доверия. В блоке 908 список рекомендаций переупорядочивается на основе правил взвешивания. В блоке 910 выполняется дополнительная обработка переупорядоченного списка для создания окончательного списка рекомендаций.

На фиг.12 показана блок-схема субопераций, включенных в операцию 910 по фиг.11, согласно одному варианту реализации. В блоке 1002 список взвешенных рекомендаций фильтруется для создания списка, который больше привязан к контексту внешнего приложения, запросившего рекомендации (как пояснялось ранее при описании фазы IV). В блоке 1004 рекомендации, относящиеся к контенту или услуге, купленной пользователем или абонентом ранее, удаляются из отфильтрованного списка. В блоке 1006 также удаляются рекомендации, несовместимые с мобильным устройством пользователя или абонента. В результате остается окончательный список для конкретного пользователя или абонента. Следует заметить, что порядок операций 1002, 1004 и 1006 на фиг.12 может быть изменен. Как было показано и описано ранее, фильтрация может дополнительно охватывать регламентированный контент и позиции, уже рекомендованные недопустимо много раз.

Как упоминалось ранее, согласно одному примеру, модуль 234 принятия решения может использовать комбинацию различных алгоритмов для создания, по существу, наилучших рекомендаций из всех возможных. Использование множества алгоритмов позволяет модулю 234 принятия решения использовать практически наиболее оптимальные способы с точки зрения качества и объема доступных данных. Действуя таким образом, модуль 234 принятия решения может создать подходящую рекомендацию почти в любом сценарии.

В одном примере управление алгоритмами, используемыми для создания рекомендаций, осуществляется контроллером принятия решения (также называемым здесь «рекомендателем принятия решения»). Например, в одном варианте реализации контроллер принятия решения может быть сконфигурирован для использования пяти различных алгоритмов для создания рекомендаций. Действуя таким образом, контроллер принятия решения вызывает соответствующие стандартные подпрограммы в заданном порядке, а затем сортирует созданные рекомендации.

Согласно одному примеру контроллер принятия решения может быть сконфигурирован так, чтобы возвращать рекомендации с некоторыми временными ограничениями. Например, возможно потребуется, чтобы контроллер принятия решений создал рекомендации для конкретного пользователя или абонента в течение 50 миллисекунд. В одном случае возможна конфигурация контроллера принятия решения, обеспечивающая прекращение процесса создания рекомендаций, если создание рекомендации занимает больше 50 миллисекунд в данном примере. Будут передаваться рекомендации, созданные в рамках разрешенного временного интервала.

Согласно одному примеру на фиг.13 показана блок-схема взаимосвязи между модулями 1104, 1106, 1108, 1110 и 1112 ассоциирования (алгоритм правил ассоциирования), сравнения (алгоритм подобия), группирования (алгоритм профилирования), отслеживания (алгоритм для популярного контента) и сетевого (алгоритм формирования социальной сети), которые вместе обозначены как «модули-рекомендатели 1114», и контроллером 1116 принятия решения согласно одному аспекту изобретения. Как можно видеть из иллюстративного примера, показанного на фиг.13, каждый из модулей-рекомендателей 1104, 1106, 1108, 1110 и 1112 ассоциирования, сравнения, группирования, отслеживания и сетевой в качестве входных данных берет извлеченные абонентские данные и обрабатывает эти данные для создания списка рекомендаций 1118. Затем каждый список вводится в контроллер 1116 принятия решения, который обрабатывает результаты, чтобы вывести окончательный список рекомендаций 1120.

В одном примере модули-рекомендатели 1114 могут выполнять некоторую предварительную обработку 1122 данных. Затем предварительно обработанные данные могут быть использованы во время создания рекомендаций. Эта стадия предварительной обработки может быть сконфигурирована для работы каждый день на конкретных временных интервалах, для непрерывной работы, для автономной работы и т.д. В одном случае на этой стадии предварительной обработки осуществляется очистка, обработка и структуризация данных в формате, в котором они могут быстро и точно использоваться на интервале восстановления отдельной рекомендации.

В одном случае модули-рекомендатели 1114 могут быть сконфигурированы для предоставления уровня 1124 доверия решения (например, с 1 по 5), указывающего, насколько велик уровень доверия каждого из модулей-рекомендателей 1114 в рекомендованной позиции. В одном примере позиции рекомендация, предоставленная с уровнем «5», считается очень хорошей рекомендаций, в то время как рекомендация с уровнем доверия «1» считается плохой рекомендацией. Согласно одному варианту реализации каждый из модулей-рекомендателей 1114 может быть сконфигурирован с дополнительным внутренним баллом/значением доверия. Для каждой рекомендации модуль-рекомендатель 1114 может использовать этот внутренний балл/значение доверия для создания нормализованного уровня доверия решения. Контроллер 116 принятия решения может использовать уровень доверия, переданный каждым модулем-рекомендателем 114 для сортировки соответствующих рекомендаций путем использования компоненты 1126 взвешивания, компоненты 1128 фильтрации и компоненты 1130 сортировки.

Согласно одному примеру рекомендатели 1104, 1106, 1108, 1110 и 1112 ассоциирования, сравнения, группирования, отслеживания и сетевой могут обеспечить функциональные возможности А, В и С, как представлено ниже.

Обратимся к фиг.14, где показана методика 1140 обработки, выполняемой рекомендателем, которая поддерживает принятие решения путем обеспечения функциональных возможностей А, В и С. Функциональные возможности А относятся к нахождению позиций для абонента, которые в блоке 1141 определены как применимые. В одном примере каждый из модулей-рекомендателей 1114 сконфигурирован с функцией, которая предоставляет список рекомендованных конкретному абоненту позиций, что показано в виде приема запроса на рекомендации (блок 1142). Вызов функции может охватывать несколько параметров, включая, «без ограничений», минимальный уровень доверия, количество рекомендаций и т.д., что показано в блоке 1144 как прием параметров рекомендаций. Затем результаты могут быть упорядочены согласно уровню доверия (блок 1146). В одном случае рекомендованные позиции сконфигурированы в виде, совместимом с мобильным устройством отдельного абонента (если была обеспечена информация, касающаяся этого мобильного устройства), причем рекомендованные позиции не будут включать в себя позицию, которая уже были закуплена данным абонентом (блок 1148).

Как показано на фиг.15, примерная блок-схема для этой функции 1200 персональных рекомендаций в контроллере 1116 принятия решения может включать в себя интерфейс API 1202 портала, вызывающий администратор 1204 доступа для принятия решения (DAM) с вызовом getRecommendations и задающий пользователя или абонента, максимальное количество рекомендаций, минимальный уровень доверия, каталожную и профильную зоны, мобильное устройство, фильтр включения атрибутов пользователя и т.д. Затем администратор DAM 1204 может вызвать контроллер 1116 принятия решения, проводящий идентификацию пользователя/абонента, количество рекомендаций, минимальный уровень доверия, каталожную и профильную зоны, мобильное устройство, фильтр включения атрибутов пользователя и т.д. Контроллер 1116 принятия решения запрашивает у каждого из модулей-рекомендателей 1114 информацию об абоненте, количество рекомендаций и минимальный уровень доверия. После этого каждый модуль-рекомендатель 1114 добавляет свои рекомендации в список рекомендованных позиций, если эти рекомендации уже не включены в список и определены с уровнем доверия, превышающем минимальный. Затем контроллер 1116 принятия решения сортирует указанный список и фильтрует его согласно каталожной зоне, регламентированному контенту, устройству и фильтру включения атрибутов пользователя и т.д. В одном случае в администратор DAM 1204 возвращается только запрошенное «количество рекомендаций». После этого DAM 1204 может, например, преобразовать все позиции контента в списке в формат xml и вернуть их вызывающей стороне.

Вновь обратимся к фиг.14, где методика 1140, кроме того, поддерживает функциональные возможности В, относящиеся к нахождению абонентов для некоторой позиции (наиболее подходящие абоненты, которым рекомендуется данная позиция), как определяется в блоке 1149. Каждый модуль-рекомендатель 1114 сконфигурирован с функцией, которая возвращает список пользователей или абонентов, которым следует рекомендовать данную позицию (блок 1150). В одном примере вызов охватывает несколько параметров, например минимальный уровень доверия (блок 1152) и т.д. Результаты упорядочиваются согласно уровню доверия (блок 1154). Таким образом, рекомендованных абонентов фильтруют в зависимости от совместимости их устройства (блок 1156).

В одном примере, показанном на фиг.15, блок-схема для этих функциональных возможностей в контроллере 1116 принятия решения включает в себя графический пользовательский интерфейс (GUI) 1206, вызывающий контроллер 1116 принятия решения, который использует вызов getSubscribersForItem и задает позицию, максимальное количество абонентов, минимальный уровень доверия, каталожную и профильную зоны и т.д. Контроллер 1116 принятия решения запрашивает у каждого модуля-рекомендателя 1114 количество пользователей или абонентов, позицию, минимальный уровень доверия, каталожную зону и профильную зону. Каждый модуль-рекомендатель 1114 за исключением рекомендателя 1110 отслеживания может добавить рекомендованных абонентов в список рекомендованных абонентов, если данного абонента еще нет в списке. После вызова всех модулей-рекомендателей 1114 список сортируют, и в интерфейс GUI 1206 возвращают только запрошенное «количество абонентов».

Вновь обратимся к фиг.14, где методика 1140 дополнительно обеспечивает функциональные возможности С, относящиеся к прошлой покупке, как показано в блоке 1157. Каждый модуль-рекомендатель 1114 может быть сконфигурирован для включения в себя функции, которая предоставляет рекомендованные позиции, относящиеся к контенту или услуге, для абонента на основе предшествующей позиции, по которой абонент совершил покупку (блок 1158). В одном иллюстративном варианте реализации рекомендацией по прошлой покупке является рекомендация на основе позиции, по которой только что совершена покупка, например предложение аксессуаров или расходных материалов, обычно покупаемых вместе. Вызов может охватывать несколько параметров, включая позицию, минимальный уровень доверия, количество рекомендаций и т.д. (блок 1160). Результаты могут быть упорядочены согласно уровню доверия (блок 1162). Рекомендованные позиции будут совместимы с мобильным устройством конкретного пользователя (если таковое имеется) и покупка не состоится, если она уже была сделана этим абонентом ранее (блок 1164).

Согласно одному примеру блок-схема для этой функции, как показано на фиг.15, в контроллере 1116 принятия решения может включать в себя вызов интерфейсом API 1202 портала администратора DAM 1204 с getPostPurchaseRecommendations и задание уже закупленных позиций, пользователя или абонента, максимального количества рекомендаций, минимального уровня доверия, каталожной и профильной зон, мобильного устройства, фильтра включения атрибутов пользователя и т.д. Администратор DAM 1204 запрашивает у контроллера 1116 принятия решения такие параметры, как закупленная позиция, абонент, количество рекомендаций, минимальный уровень доверия, каталожная и профильная зоны, мобильное устройство, фильтр включения атрибутов пользователя и т.д. Контроллер 1116 принятия решения запрашивает у каждого модуля-рекомендателя 1114 данные о уже закупленных позициях, абоненте, количестве рекомендаций и минимальном уровне доверия и т.д.

Каждый из модулей-рекомендателей 1134 добавляет свои рекомендации в список рекомендованных позиций, если данная рекомендация еще не содержится в списке, и превышен минимальный уровень доверия. Затем контроллер 1116 принятия решения сортирует этот список и фильтрует его согласно каталожной зоне, регламентированному контенту, устройству и фильтру включения атрибутов пользователя, и в администратор DAM 1204 возвращается только запрошенное «количество рекомендаций». После этого администратор DAM 1204 может, например, преобразовать все позиции контента в списке в формат xml и вернуть их вызывающей стороне.

Согласно одному примеру интерфейс API 1202 портала является механизмом, с помощью которого внешние системы могут приобретать результаты из модуля 234 принятия решения. В одном варианте реализации API 1202 портала имеет три основные цели: (А) Извлечение рекомендации (рекомендаций) для абонента; (В) Извлечение продвижения (продвижений) для абонента; и (С) Извлечение информации о популярном контенте. Аналогичным образом профильный API может иметь четвертую цель (D) - подача конкретной информации (например, о покупках) в реальном времени в систему 101 профилей и рекомендаций.

Также, как показано на фиг.15, за рекомендателем 1104 ассоциирования следует аксессор 1208 ассоциирования позиций. За рекомендателем 1106 сравнения/подобия следует аксессор 1210 сравнения. За рекомендателем 1108 группирования следует аксессор 1212 предыстории групповых покупок и аксессор членства в группе (не показан). За рекомендателем 1110 отслеживания следует аксессор 1214 отслеживания. За сетевым рекомендателем 1112 следует аксессор 1216 предыстории сети абонента.

Как показано в иллюстративном примере на фиг.13, примерная система 101 профилей и рекомендаций может включать в себя рекомендатель 1104 ассоциирования, рекомендатель 1106 сравнения, рекомендатель 1108 группирования, рекомендатель 1110 отслеживания и сетевой рекомендатель 1112.

На фиг.16 показана более подробная блок-схема модуля 234 принятия решения, которая включает в себя основные параметры, ассоциированные с процессом обработки в модулях-рекомендателях 1114, причем модуль 234 содержит рекомендатель 1104 ассоциирования, рекомендатель 1106 сравнения/подобия, рекомендатель 1108 группирования, сетевой рекомендатель 1112 и рекомендатель 1110 отслеживания. Назначение каждого рекомендателя описано ниже.

Рекомендатель 1104 ассоциирования (правил ассоциирования) - согласно одному примеру рекомендатель 1104 ассоциирования использует продвинутые методы на основе правил ассоциирования для выполнения анализа корзины по данным прошлых транзакций. Для извлечения моделей поведения из данных предыстории покупок используют метод извлечения данных на основе правила ассоциирования. В примере с корзиной покупок в супермаркете извлечение данных на основе правил ассоциирования раскрывает взаимосвязи между всеми позициями продаж в супермаркете путем анализа комбинаций позиций, появляющихся в корзинах с покупками, например «множество людей, которые купили и хлеб и молоко». Правило ассоциирования может точно зафиксировать эту взаимосвязь в виде математической вероятности. Владелец супермаркета может затем изучить все вероятности для всех такого рода пар продуктов и заполнить полки, размещая рядом друг с другом те позиции, которые, скорее всего, покупают вместе. При реализации этой идеи используют данные прошлых транзакций для воздействия на поведение покупателей в будущем.

Например, для любого набора контента, услуг или продуктов (например, загружаемые компьютерные продукты, мелодии для мобильного телефона и т.д.), если предусмотрена база данных транзакций (например, «корзины покупок» в примере с супермаркетом), то можно вывести правила ассоциирования между позициями. Правила ассоциирования позволяют обеспечить разумные рекомендации по контенту, услугам или продуктам для пользователей, абонентов, потребителей в будущем на основе продуктов, которые уже закупили пользователи, абоненты или потребители. Кроме того, в одном примере правила ассоциирования позволяют найти более сложные модели, чем просто взаимосвязи между парами позиций, таких как «покупка хлеба с высокой вероятностью влечет за собой покупку молока». В частности, в одном примере правила ассоциирования могут сопрягать вместе наборы позиций. Набором позиций может быть группа из одной или нескольких позиций. Например, если А и В - два любых (не связанных) набора позиций, то вопрос может быть сформулирован так: «какова вероятность присутствия В в транзакции, если А уже присутствует»; последнее устанавливает правило ассоциирования, которое можно записать как «А⇒В». Рекомендатель 1104 ассоциирования, входящий в модуль 234 принятия решения, может обеспечить создание многоуровневых ассоциаций, например «АВ⇒С, АВС⇒D» до максимального уровня 5 «ABCD⇒Е» (то есть, если кто-то покупает позиции А, В, С и D, какова вероятность того, что тот же человек купит позицию Е).

В одном примере может быть установлена стандартная конфигурация для трех позиций, то есть, если кто-то купил позиции А, В, какова вероятность, что он купит позицию С. Для большинства приложений такая размерность может оказаться достаточной.

Согласно одному варианту реализации для измерения мощности правила ассоциирования можно определить два показателя, как показано ниже в таблице 1.

Таблица 1
Примерные показатели правил ассоциирования
Поддержка (А⇒В)=P(A U B)=	Количество транзакций, заключающих в себе А и В
Общее количество транзакций
Уровень доверия (А⇒В)=P(B|А)=	Количество транзакций, заключающих в себе А и В
Количество транзакций, заключающих в себе А

В одном примере по умолчанию рекомендатель 1104 ассоциирования в модуле 234 принятия решения вычисляет общее количество транзакций (корзин) в виде количества уникальных абонентов, купивших два или более позиций. Это значение является конфигурируемым.

В одном примере показатели, указанные в таблице 1, умножают на 100 для выражения их в процентах. Поддержка показывает, как часто наборы позиций появляются вместе в транзакциях в общей базе данных, а показатели доверия показывают, как часто В появляется в транзакциях, заключающих в себе А. Правило ассоциирования численно оценивается его мощностью в обоих показателях.

Вычисление всех возможных правил ассоциирования между всеми возможными наборами позиций может оказаться с точки зрения объема вычислений весьма трудоемкой задачей. В одном случае для преодоления указанных ограничений внимание сосредотачивается на так называемых «частых наборах позиций», причем алгоритм ассоциирования может обеспечить хорошо оптимизированный способ вычисления правил ассоциирования. Согласно одной реализации алгоритм ассоциирования может использовать транзакции из таблицы базы данных SubscriberHistory транзакций для создания ассоциаций между позициями. В одном случае для создания ассоциаций могут быть использованы только транзакции типа «Купить». В указанном примере при создании рекомендации могут быть использованы действия типа «Купить».

В одном примере могут быть использованы действия типа: BUY (Купить), LIKE (Нравится), DISLIKE (Не нравится), SUB (Подписаться), UNSUB (Не подписаться) и NOT-PURCHASED (Не куплено). При использовании действий указанных типов при создании рекомендаций можно использовать примерные стандартные веса, показанные в таблице 2.

Таблица 2
Примерные стандартные веса для ассоциирования
Тип транзакции	Вес
BUY	100
LIKE	20
DISLIKE	-20
SUB	10
UNSUB	-10
NOT_PURCHASED	0

Например, транзакцию «BUY» можно считать более релевантной, чем транзакцию LIKE. Однако необходимо заметить, что указанные стандартные значения весов можно изменить.

При создании рекомендации модуль 234 принятия решения может просмотреть прошлые транзакции 1304 абонента, которые были извлечены через профильный интерфейс API/компоненту 1305 поглощения данных и агрегировать веса для каждой позиции. Затем эту информацию можно использовать для поиска всех релевантных комбинаций правил ассоциирования. Далее полученные результаты могут быть взвешены и отсортированы соответствующим образом.

Примерный поток функциональных вызовов в рекомендателе 1104 ассоциирования для нахождения позиций для абонента включает в себя функцию AssociateRecommender (рекомендатель ассоциирования) модуля 1104 ассоциирования, получающую позиции, по которым абонент сделал покупки, и формирующий наборы позиций из комбинаций в модуле 1306 ассоциирования контента. После этого AssociateRecommender ищет ассоциации с минимальной поддержкой и уровнем доверия для каждого набора позиций, задавая количество рекомендуемых ассоциаций, которые каждый набор позиций должен предоставить. AssociateRecommender формирует запрос и получает ассоциации между позициями из хранилища ассоциаций между позициями (например, Таблица DB и т.д.), проверяя, превышают ли показатели поддержки ассоциирования и доверия минимальный порог. После этого создается несколько рекомендаций, упорядоченных согласно общему уровню доверия.

В одном примере AssociateRecommender может получить результаты из таблицы ассоциаций между позициями для каждого набора позиций. Затем AssociateRecommender может проверить, были ли уже куплены эти позиции указанным абонентом, путем использования процесса 1311 фильтрации, который может также оценить совместимость устройства и выполнить фильтрацию метаданных, обращаясь к информации 1313 в устройстве. Далее AssociateRecommender может добавить позиции в список и использовать уровень доверия с применением процесса 1307 взвешивания согласно правилам 1309 взвешивания. Затем рекомендации отправляют в рекомендатель принятия решений.

В примерном потоке функциональных вызовов в рекомендателе 1104 ассоциирования для получения абонентов, которым будет рекомендована позиция, AssociateRecommender рекомендателя 1104 ассоциирования использует позицию, минимальный уровень доверия, каталожную и профильную зоны и количество абонентов, которое следует предложить. Затем AssociateRecommender запрашивает хранилище ассоциаций между позициями (например, таблицу базы данных и т.д.) на предмет целевой позиции, количества абонентов, которым надо отправить рекомендации, а также минимальный уровень доверия, проводя поиск по всем пользователям или абонентам, которые уже сделали покупки по позициям в ассоциациях, заключающих в себе целевую позицию, но не сделали покупку по данный позиции, гарантируя, кроме того, наличие у пользователей или абонентов мобильного устройства, способного поддерживать данную позицию.

Примерный поток функциональных вызовов в рекомендателе 1104 ассоциирования для прошлой покупки включает в себя функцию AssociateRecommender рекомендателя 1104 ассоциирования, использующую конкретную позицию для создания набора позиций, заключающего в себе целевую позицию. Затем AssociateRecommender запрашивает в хранилище ассоциаций между позициями (например, таблицу базы данных и т.д.) минимальный уровень доверия и поддержку для каждого набора позиций, задавая количество отправляемых рекомендаций (например, с использованием конфигурируемого свойства и т.д.). Затем предоставляют набор рекомендаций, упорядоченных согласно общему уровню доверия. AssociateRecommender проверяет, делались ли пользователем или абонентом покупки по данным позициям, добавляет позиции в список, выполняет взвешивание, проверяет совместимость устройства, а затем отправляет результаты в рекомендатель 234 принятия решения.

Рекомендатель 1106 сравнения - в одном примере рекомендатель 1106 сравнения предназначен для вычисления взаимосвязи между различными контентными позициями на основе контентных метаданных 1327, причем рекомендатель 1106 получает входные данные из каталожного интерфейса API 1329, который осуществляет поглощение интерфейсных данных. Согласно одному примеру рекомендатель 1106 сравнения может помочь в решении проблемы «холодной» загрузки для новой позиции (то есть новой позиции, у мобильного оператора или ассоциированной с ним бизнес-системы, которая еще никем не была куплена). В одном случае рекомендатель 1104 ассоциирования может оказаться неспособным обнаружить какие-либо корреляции для новой позиции, так как ни один абонент не сделал покупку по этой позиции, и эта позиция отсутствует во всех предысториях покупок абонентов.

В указанной ситуации рекомендатель 1106 сравнения может найти позиции, подобные этой конкретной позиции, а затем найти для указанных позиций тех абонентов, которым их можно было бы рекомендовать. В одном случае рекомендатель 1106 сравнения сравнивает позиции, используя такие метаданные, как артист, название, имя источника, заключающего в себе контент, и издателя, для формирования наборов 1310 сходных контентов. Специалистам в данной области техники следует иметь в виду, что можно также сконфигурировать любые потребительские атрибуты, используемые для сравнения. В одном примере это достигается в процессе создания потребительских атрибутов контента.

При сравнении метаданных рекомендатель 1106 сравнения в одном примере может использовать вес фрагмента метаданных для определения важности этого фрагмента метаданных при сравнении атрибутов. Вес может принимать значение, например, от 1 до 5, где 1 - самое низкое значение, а 5 - самое высокое значение. Например, в качестве потребительского атрибута может быть названа «Категория цены», которая может иметь вес, равный 1, в то время как «Жанр» может иметь значение, равное 5, указывающее, что сходство жанров двух позиций более важно, чем сходство их цен.

В одном примере рекомендатель 1106 сравнения может иметь два механизма, с помощью которых он может сравнивать значения метаданных. Первый механизм может использовать прямое сравнение независимых цепочек. Второй механизм может использовать метод сопоставления нечетких цепочек. Второй механизм подходит при сравнении значений, которые представляют одно и то же или сходное значение, например «FIFA 2004» или «FIFA 2005». В одном примере также предусмотрен режим, позволяющий сравнивать цепочки, состоящие из субцепочек, разделенных запятыми.

Согласно одному примерному аспекту основные операции в процессе обработки функциональных вызовов в алгоритме 1106 сравнения для рекомендации позиций абоненту включают в себя функцию SimilarityRecommender рекомендателя 1106 сравнения, получающую данные о позициях, которые купил абонент. Затем SimilarityRecommender запрашивает в хранилище сходства позиций (например, таблица базы данных) минимальный уровень доверия для каждой купленной позиции, определяя количество сходных позиций, где каждая купленная позиция должна предоставляться с использованием конфигурируемого свойства. После этого предоставляют сходные позиции, упорядоченные по показателю сходства. В одном примере SimilarityRecommender получает сходные позиции для каждой купленной пользователем позиции и проверяет, не куплены ли они данным абонентом. Затем SimilarityRecommender добавляет эти позиции в список и прилагает каждой уровень доверия. Затем эти рекомендации отправляют в рекомендатель 234 принятия решения.

Согласно одному примерному аспекту в основе основных операций в процессе функциональных вызовов в алгоритме 1106 сравнения для рекомендации абонентам позиции лежит функция SimilarityRecommender рекомендателя 1106 сравнения, через которую проходит данная позиция, и задание максимального количества абонентов, задаваемого как конфигурируемое свойство.

После этого SimilarityRecommender осуществляет поиск для сходных позиций и находит абонентов, которые не делали покупку по целевой позиции, но делали покупки по одной или нескольким сходным позициям. После этого SimilarityRecommender добавляет этих пользователей в список, сортируя его по оценке доверия и приписывая каждому уровень доверия. Затем «количество абонентов» отправляют в рекомендатель 234 принятия решения.

Рекомендатель 1108 группирования - в одном примере рекомендатель 1108 группирования реализован для вычисления наиболее популярных позиций, закупленных определенными абонентскими группами (то есть по поведению 1324 абонентской группы). Согласно одному аспекту этот рекомендатель 1108 особенно полезен для решения проблемы «холодной» загрузки абонентов, когда имеется недостаточно или не имеется вообще какой-либо информации о предыстории (покупки, любимые позиции, нелюбимые позиции и т.д.) для конкретного пользователя. Однако даже в такой ситуации могут быть доступны полезные абонентские метаданные или демографическая информация, на основе которых могут быть выполнены рекомендации. Например, если известно, что конкретным абонентом является мужчина - бизнес-клиент, использующий способ оплаты по факту, эту информацию можно использовать для рекомендации контента или услуг, которые нравятся другим абонентам, со сходными демографическими характеристиками. При создании рекомендаций для пользователя или абонента рекомендатель 1108 группирования сначала определяет пользовательские или абонентские группы, к которым принадлежит пользователь или абонент (то есть членство 1316 в профильной группе), а затем приобретает наиболее популярные контентные позиции для этих групп. Группирование может поддерживаться процессом 1318 создания профильной группы, который поддерживает абонентские атрибуты и транзакции 1304 особенно для новых членов без записи отслеживания, а также поддержки членов 1316 профильной группы. Указанные позиции затем фильтруют (например, позиции, уже купленные пользователем или абонентом, удаляют и т.д.), сортируют согласно уровню доверия и отправляют. В другом примере при рекомендации абонентов для позиции рекомендатель 1108 группирования может определить, в каких абонентских группах популярен конкретный контент, и выявляет членов этих групп 1316. Затем члены этих групп фильтруют, сортируют согласно уровню доверия и отправляют.

Согласно одному примеру в основе основных операций в последовательности обработки функциональных вызовов в рекомендателе 1108 группирования для рекомендации позиций абоненту может лежать рекомендатель 1108 группирования, получающий позиции, которые купил абонент, и получающий группы, членом 1316 которых является данный абонент. Затем GroupRecommender 1108 приобретает из хранилища (таблица базы данных и т.д.) используемую в качестве опции профильную зону и задает количество позиций, которое следует отправить (используя конфигурируемое свойство), то есть наиболее покупаемые позиции для каждой группы. После этого отправляют количество позиций, упорядоченных согласно частоте их покупки. GroupRecommender проверяет, не куплены ли они уже пользователем, добавляет эти позиции в список и прилагает оценку доверия. Затем эти рекомендации сортируют и отправляют в рекомендатель 234 принятия решения.

Согласно одному примерному аспекту в основе основных операций в последовательности обработки функциональных вызовов в рекомендателе 1108 группирования для абонентов для рекомендации позиций абоненту может лежать рекомендатель 1108 группирования, обращающийся к хранилищу данных (например, таблица базы данных и т.д.) за данной позицией с целью получения всех групп, в которых эта позиция была продана заданное число раз. Для каждой группы рекомендатель группирования получает пользователей или абонентов, которые не купили эту позицию, но имеют устройство, поддерживающее эту позицию. GroupRecommender 1108 может добавить этих абонентов в список абонентов, если превышен минимальный уровень доверия, и проверяет, разрешен ли регламентированный контент для каждого абонента.

На фиг.17 показана блок-схема основных компонент сетевого рекомендателя 1112 согласно одному аспекту. Он включает в себя модуль 1402 записи данных вызова, модуль 1404 формирователя сети, модуль 1406 сетевой очистки, модуль 1408 взвешивания, модуль 1410 идентификаторов взаимосвязей абонентов и модуль 1412 NetworkRecommender. Эти модули более подробно описаны ниже. В одном примере сетевой рекомендатель 1112 использует данные 1320 одноранговой (P2P) связи (например, вызов, данные SMS и т.д.), используемые в процессе 1321 обработки сетевым формирователем для создания P2P (одноранговых) сетей 1322. Эти сети 1322 можно затем использовать для создания рекомендаций для пользователя на основе поведения членов их локальной сети 1322. В одном примере сетевой рекомендатель 1112 использует записи данных вызова (CDR) на основе используемости мобильного устройства (разговоры, сообщения SMS, MMS, 3G и т.д.) для построения сети ссылок между парами пользователей, осуществляющих связь с использованием соответствующих мобильных устройств. Затем эту социальную сеть 1322 можно использовать для рекомендации позиций людям (или наоборот) путем опроса сетевых ссылок отдельных пользователей для изучения покупательского поведения этих людей в их локальной сети.

Вновь обратимся к фиг.17, где согласно одному аспекту сетевой рекомендатель 1112 состоит по меньшей мере из трех модулей, а именно: формирователя 1404 сети, блока 1406 сетевой очистки и алгоритмов 1412 NetworkRecommender.

Обратимся к фиг.18, где представлена методика 1420 сетевых рекомендаций согласно одному аспекту. В одном примере сетевой формирователь 1404 берет в качестве входных данных список записей CDR из модуля 1402 записи данных вызова, где CDR представляет собой просто строку данных, фиксирующих связь между двумя мобильными устройствами (блок 1422). Примером записи CDR может быть «CALLER_NUMBER, RECEIVER_NUMBER, CALL_TYPE, CALL_ TIME, CALL_DURATION, CALL_COST». Может быть сконфигурирована утилита для настройки одного или нескольких «фильтров» для входящих записей CDR. Согласно одному аспекту фильтром является список правил, которым должны удовлетворять записи CDR. В одном примере фильтр проверяет следующее: (А) Номера вызывающей стороны и приемника имеют специальные префиксы и минимальную/максимальную длину (блок 1424); (В) Вызов относится к конкретному типу (речь, SMS, MMS, видео и т.д.) (блок 1426); (С) Для речевых вызовов задана минимальная/максимальная длительность (блок 1428); (D) Запись CDR оказывается между заданной календарными датами начала/окончания (блок 1430); и (Е) Время CDR лежит между заданными часами времени суток (блок 1432). Также фильтрации подвергается день недели записи CDR (блок 1433).

Каждый набор указанных фильтров может определять отдельную сеть. Например, одна такая сеть может фиксировать записи CDR, представляющие сеансы связи от 8 утра до 6 вечера, с понедельника до пятницы, то есть бизнес-сеть. Другой сетью, фиксирующей записи CDR с 6 часов вечера пятницы до 2 часов понедельника, будет социальная сеть.

В одном примере любые записи данных, прошедшие через указанные фильтры, посылают в таблицу «Сводка сети», где в одном случае ссылки P2P сохраняются в виде единой строки и собираются вместе (блок 1434). То есть, если запись от вызывающей стороны А на приемник В является входящей, то проверяется указанная таблица на предмет существования строки для А к В. Если строка уже существует, то она обновляется с помощью информации в новой записи CDR. В противном случае, эта запись CDR вставляется в виде новой строки. Таким образом, каждая строка окончательной таблицы «Сводка сети» представляет общую активность передачи данных между двумя людьми.

Согласно одному примеру каждая из этих сетей конфигурируется как направленная (блок 1436), что означает, что ссылка «A→В» отличается от ссылки «B→А». По существу, если существуют записи CDR для передач от А к В и от В к А, то каждая будет иметь отличную от другой строку в таблице «Сводка сети». В одном примере могут быть построены фильтры, сконфигурированные в файле XML, который может называться, например «RAWRECORD FILTERS.xml.».

В одном случае таблица «Сводка сети» будет заключать в себе некоторый шум, например, такие автоматические поставляемые услуги, как расписания поездов, погода, чрезвычайные происшествия, такси и т.д. Указанные данные бесполезны с точки зрения рекомендаций, и поэтому сетевой рекомендатель 1112 рассчитан на то, что он будет удалять такие данные из таблицы «Сводка сети», используя модуль 1406 очистки (блок 1438). Согласно одному аспекту для каждой сети, созданной модулем 1404 формирователя сети, может быть создан отдельный фильтр, который будет очищать только эту сеть. Фильтр может задать, например, максимальное/минимальное количество исходящих передач, которое разрешено иметь вызывающей стороне (блок 1440). Таким образом, вызывающие абоненты, нарушающие эти пороговые значения, удаляются из сводки сети.

В одном примере сразу после очистки таблицы «Сводка сети» конфигурируется сетевой рекомендатель 1112 для присваивания веса (или мощности) каждой взаимосвязи (то есть строке в таблице) с помощью модуля 1408 взвешивания (блок 1442). Это делается с тем, чтобы можно было ранжировать ссылки отдельных абонентов с целью идентификации их «лучших» друзей (то есть объектов с самыми большими весами) (блок 1444). В одном примере эти фильтры могут быть построены и сконфигурированы в виде файла XML, такого как, например, «NetworkSummaryTableCleaner.xml.»

Сразу после построения и очистки таблицы «Сводка сети» можно использовать сетевой рекомендатель 1112 для нахождения позиций, рекомендуемых абоненту, или нахождения тех абонентов, которым можно было бы предложить эту позицию (блок 1446). В одном примере для данного абонента идентифицируют «соседей» этого абонента (люди, непосредственно с ним сопряженные), затем соседей этих соседей и т.д. (здесь это называется «степени разобщения» или просто степени), что выполняется модулем 1410 идентификации взаимосвязей абонентов (блок 1448). Таким образом, человек, которого с другим человеком разделяют две степени, относится к человеку, сопряженному с кем-то, кто, в свою очередь, сопряжен с ним (то есть приятель приятеля). В одном случае рекомендации для данного абонента формируют на основе наиболее популярных позиций среди этих людей.

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

Согласно одному примеру сетевой рекомендатель 1112 можно использовать для рекомендации позиций абоненту, который имеет предысторию покупок. В указанном сценарии предысторию покупок абонента можно использовать для создания рекомендаций абоненту и исключения уже купленных позиций (блок 1452).

Согласно одному примерному аспекту сводка основных операций в процессе обработки функциональных вызовов в сетевом рекомендателе 1112 включает в себя контроллер 1116 принятия решения, получающий позиции, которые купил абонент, и подачу их в NetworkRecommender 1412 сетевого рекомендателя 1112. В одном примере NetworkRecommender 1412 с учетом прохождения порога решает, сколько степеней разобщения использовать при поиске в локальной сети абонента.

В одном примере NetworkRecommender 1412 выполняет поиск в локальной сети абонента для позиций, купленных членами этой локальной сети в рамках заданных степеней разобщения, и следует только по ссылкам P2P с весом, превышающим заданный порог, и опрашивает только те члены, которые делали заданное или конфигурируемое минимальное количество покупок. Затем NetworkRecommender 1412 проверяет, не была ли уже куплена каждая позиция целевым абонентом, добавляет эти позиции в список и использует уровень доверия применительно к каждой позиции. Затем рекомендации отправляют в контроллер 1116 принятия решения.

Согласно другому примерному аспекту сводка основных операций в процессе обработки функциональных вызовов в сетевом рекомендателе 1112 с целью обнаружения абонентов, которым рекомендуется данная позиция, включает в себя использование данной позиции и нахождение людей, которые уже ее купили. Затем целями для данной позиции становятся соседи каждого из этих людей. Заметим, что можно задать, чтобы рассматривались только те соседи, которые имеют вес, превышающий определенный порог, а также соседи с количеством степеней разобщения, не превышающим заданное число. В каждой локальной сети могут быть идентифицированы люди, не покупавшие данную позицию, и те из них, количество покупок у которых превышает минимальный конфигурируемый уровень, добавляются в качестве целей для рекомендации.

Вернемся к фиг.16, где представлен рекомендатель 1110 отслеживания. В одном примере рекомендатель 1110 отслеживания можно использовать для непрерывного контроля и записи чаще всего используемого контента или услуг, то есть обеспечить отслеживание 1330 общего тренда. Затем эту информацию используют для возврата рекомендации на основе наиболее популярных позиций. В одном примере рекомендатель 1110 отслеживания можно использовать для направления популярных позиций абоненту. В одном примере результаты, полученные от рекомендателя 1110 отслеживания, можно использовать тогда, когда другой алгоритм неспособен обеспечить более адресную рекомендацию (например, ситуация «холодной» загрузки абонента)». Кроме того, рекомендатель 1110 отслеживания можно использовать для просмотра наиболее популярного контента в каталоге в течение заданного периода времени. Примером рекомендации такого типа может быть отображение «горячего» списка пользователям портала. В одном примере рекомендатель 1110 отслеживания использует таблицу TrackContentItem, которая строится по данным транзакций в таблице SubscriberHistory. В одном случае перед созданием таблицы TrackContentItem можно задать период времени для поиска транзакций предыстории.

Согласно одному примерному аспекту сводка основных операций в последовательности обработки функциональных вызовов в рекомендателе 1110 отслеживания для рекомендации позиций абонентов включает в себя получение функцией TrackRecommender наиболее популярных позиций, поддерживаемых устройством абонента, но не купленных ранее этим абонентом. Затем TrackRecommender использует профильную зону и задает количество позиций, которое следует направить, используя конфигурируемое свойство, формирует запрос и получает позиции из таблицы TrackContentItem, отправляя заданное количество позиций, упорядоченных согласно отсчету каждой позиции. После этого TrackRecommender проверяет RestrictedContent, контент, не купленный абонентом или пользователем, добавляет эти позиции в список и прилагает уровень доверия. Затем эти рекомендации отправляют в контроллер 1116 принятия решения.

Согласно еще одному примерному аспекту система 101 рекомендаций согласно настоящему изобретению может использовать рекомендатель бестселлеров.

Однако согласно одному аспекту рекомендатель бестселлеров отделен от рекомендателей 1114 и может представлять собой автономный модуль. В одном примере это отражается на кодовом уровне, определяющем рекомендатель бестселлеров вне архитектуры рекомендателей принятия решений. Хотя согласно одному аспекту при поиске позиций для абонента или позиций для другой позиции обращаются к рекомендателям 1114, рекомендатель бестселлеров покупок может рассматриваться дополнительно как средство сбора статистических данных.

Рекомендатель бестселлеров в одном простом примере позволяет пользователю просмотреть наиболее популярный контент из таблицы транзакций в предыстории абонента, согласно действиям пользователя (BUY/LIKE/DISLIKE/VIEWED и т.д.) и временному периоду (конфигурируемый набор временных интервалов в прошлом, например последний час, последние 12 часов, последний день, последняя неделя и т.д.). Согласно одному необязательному аспекту пропускание абонента через рекомендатель бестселлеров может иметь два дополнительных эффекта по возвращаемым позициям: (А) Позиции, по которым абонентом уже сделаны покупки, оказываются скрытыми; или (В) Регламентированные позиции скрывают от абонента, если это целесообразно.

В одном примере, когда абонент функционально подходит, рекомендатель бестселлеров может работать практически также, как рекомендатель 1110 отслеживания. В одном примере рекомендатель бестселлеров может искать действия, отличные от покупок. Вдобавок, по аналогии с рекомендателем 1110 отслеживания, данные рекомендателя бестселлеров могут храниться в таблице TrackContentItem рядом с данными рекомендателя отслеживания и использовать тот же формат. В одном примере настройка создания данных бестселлеров может состоять в добавлении единственного свойства, содержащего список доступных временных периодов, разделенных запятыми. Например, свойство «1H, 7H, 1D, 7D, 999D» указывает пять различных временных периодов (1 час, 7 часов, 1 день, 7 дней, 999 дней), в течение которых рекомендатель бестселлеров сможет осуществлять своевременный поиск. Фаза подготовки разбивает таблицу данных транзакции в предыстории абонента на временные периоды, заданные в вышеуказанном свойстве, и сохраняет эту информацию в таблице TrackContentItem рядом с данными рекомендателя отслеживания. Если временной период, заданный отслеживанием, является периодом, заданным рекомендателем бестселлеров, то создание данных для этого периода может быть только однократным.

Согласно одному примеру рекомендатель бестселлеров может быть доступнее только в виде вызова интерфейса API «GetTopContentByTimeAndAction». Согласно одному аспекту могут быть обязательными параметры простого протокола доступа к объектам (SOAP), такие как действие (BUY/VIEWED/LIKE и т.д.) или список действий, разделенных запятой, и временной период (например, 12H или 7D и т.д.).

Очевидно, что параметры, выданные для вызова решения, обеспечивают механизм создания рекомендаций. В них скомбинированы бизнес-правила с входными данными и выходными данными от рекомендателей принятия решения для создания окончательной рекомендации, которая будет выдана абоненту. Эти параметры, кроме того, квалифицируют выходные данные от рекомендателей принятия решения.

В одном примере задание параметров обеспечивается через предоставленные параметры вызова API. Вдобавок также могут быть заданы глобальные системные параметры по умолчанию. Согласно одному аспекту параметры API модуля принятия решения можно использовать для обеспечения следующих возможностей: (А) Выбор рекомендателя; (В) Правила, используемые для точного выбора того, какое решение о конфигурациях рекомендателя (рекомендателей) будет использовано для выполнения рекомендаций; (С) Входные критерии; (D) В качестве параметров для модуля принятия решения принимаются критерии фильтрации абонентов и контента. Затем их используют при оценке имеющихся профильных и каталожных данных; (Е) Запрос результатов; и (F) Оценивают выходные данные из модуля принятия решения, чтобы определить, оказалась ли найденная рекомендация хорошей. Модуль 234 принятия решения вернет значение степени достоверности для каждой рекомендации, которую предложил модуль 234 принятия решения, в качестве уровня доверия. Данное правило может задать приемлемую минимальную степень достоверности, которая, если ее не поддержать, может привести к попытке использования другого рекомендателя.

Например, согласно одному аспекту выполняется вызов решения, запрашивающий возврат рекомендации абоненту из имеющегося контента в модуле каталога. Модуль принятия решения может выдать рекомендацию с низкой степенью достоверности. В этой ситуации рекомендация может быть проигнорирована, и по умолчанию переходят к конкретной (фиксированной) позиции контента, которую хочет продвинуть администратор 213.

Другой пример относится к случаю, когда позиция контента необходима для перекрестной продажи. Модуль 234 принятия решения может рекомендовать контент или услугу, которая возможно не покажется наиболее очевидной или общепринятой при выборе. Последнее можно использовать, чтобы избежать рекомендаций, не представляющих большую ценность для абонента (например, рекомендация последнего хита конкретного артиста, когда абонент только что купил его последний выпуск).

Согласно одному примеру фильтрацию абонентов можно использовать для того, чтобы дать возможность администратору 213 определять абонентов, которым могут быть выданы рекомендации конкретного типа. Это используют при создании рекомендации для конкретного абонента (например, онлайновая рекомендация, показанная на портале, и т.д.). Например, может быть создано правило принятия решения, которое ограничивает представление рекомендаций абонентам с устройством или атрибутом конкретного типа (например, оплата по факту, абонент, склонный транжирить деньги, и т.д.).

В другом примере фильтрацию абонентов можно использовать для предварительного выбора поднабора абонентов, для которых необходимо создать рекомендации. Это используют при создании исходящего продвижения на основе данного правила. Например, администратор 213 может задать критерии фильтрации абонентов через пользовательский интерфейс приложения 212 для рекомендаций, что позволяет выбрать атрибуты из списка и выполнить простую логическую обработку (например, устройство MMS и оплата по факту, предоплата или оплата по молодежному тарифу и т.д.).

Что касается фильтрации контента, она позволяет уточнить типы рекомендуемого контента. Например, администратор 213 может создать правило, которое будет рекомендовать только позицию контента MMS. Таким образом, в одном примере интерфейсы API, ассоциированные с извлечением рекомендаций, также имеют возможность задать определенные критерии, касающиеся типа рекомендации, которую следует выдать (например, жанр музыкальной дорожки и т.д.). Хотя при этом открываются большие возможности управления для вызывающего приложения, это означает, что возможно потребуется перекодировка приложения, сделавшего вызов API, в связи с изменениями навыков пользователя. Во избежание этого, система 101 профилей и рекомендаций может обеспечить соответствующие профили. Профили рекомендаций могут быть созданы через пользовательский интерфейс блока 212 приложения для рекомендаций (показан на фиг.4), причем они позволяют администратору 213 задавать значения для всех параметров вызова API. Затем вызывающее приложение обращается к профилю рекомендаций вместо того, чтобы задать значения для отдельных параметров. Затем модуль 234 принятия решений берет значения параметров из указанного профиля. Таким образом, профили для рекомендаций позволяют администратору 213 изменить навыки пользователя без необходимости перестройки системы кодирования.

Согласно одному примеру может оказаться важным быстродействие, с которым может работать модуль 234 принятия решения. Критерии быстродействия могут измеряться десятками или сотнями миллисекунд, что соответствует обслуживанию нескольких сот запросов в секунду. В одном примере факторами, которые могут влиять на эффективность системы, могут быть количество используемых рекомендателей и объем просматриваемых данных.

Согласно одному аспекту на фиг.19 представлена схема, иллюстрирующая, каким образом модуль 234 принятия решения удовлетворяет этим требованиям эффективности с помощью Web-контейнера 1502. В одном примере для удовлетворения требований эффективности можно использовать несколько различных методов, таких как кэширование в подсистеме 1504 кэш-памяти и обращение к базе данных 1508. Модуль 234 принятия решения согласно одному аспекту может для повышения эффективности использовать интеллектуальное кэширование данных, к которым часто обращаются. Можно обеспечить управление объемом и временем существования элементов кэшированных данных для согласования с имеющимся объемом данных и доступными аппаратными ресурсами. Согласно другому аспекту, если кэширование не предусмотрено, то модуль 234 принятия решения может использовать тонко настроенный язык SQL и технологию JDBC, например, для извлечения данных. Все объекты SQL и базы данных рассчитаны на обеспечение максимальной эффективности и масштабируемости.

Механизм кэширования в модуле 234 принятия решения может использовать несколько различных устройств 1512 кэш-памяти для хранения различных типов данных с частым доступом. Чаще всего используют устройства кэш-памяти, которые хранят информацию о предыстории абонента, данные о позиции, включая потребительские атрибуты, и данные, созданные с помощью различных алгоритмов на фазе I (например, данные об ассоциации между позициями, сравнения по сходству, сети и т.д.).

Для загрузки абстрактных данных из других компонент модуля 234 принятия решения используют уровень 1518 доступа к данным. При поступлении запроса на какой-то фрагмент данных, уровень 1518 доступа к данным сначала проверяет подсистему кэширования на предмет того, загружены ли уже эти данные. Если эти данные уже загружены, то они выдаются. Если данные не были загружены, уровень 1518 доступа к данным загружает эти данные из базы данных и вводит их в кэш-память перед их выдачей. Подсистема 1504 кэширования управляет удалением старых или не используемых данных. В одном примере подсистема 1504 кэширования для определения того, что следует удалить, использует как время последнего доступа к данным, так и общий размер кэш-памяти.

В одном примере в модуле 234 принятия решения учитывается время, необходимое для подготовки данных на фазе А, как было показано ранее в связи с фиг.9. Хотя этот процесс не оказывает аналогичного влияния на навыки пользователя, следует заметить, что для этого не потребуется недопустимо больших аппаратных ресурсов и что этот процесс может быть завершен в разумный период времени. В одном случае, когда это возможно, выполняется пошаговый анализ на фазе I, как показано под ссылкой 1522 (то есть обработка новых данных и комбинирование этих новых данных с существующими результатами).

Обратимся к фиг.20, где согласно одному примеру показаны основные компоненты модуля 236 продвижения. Как описано выше в связи с фиг.4, в одном примере модуль 236 продвижения предоставляет возможность создания связанных исходящих продвижений и поддержки создания на Web-портале динамических контентных страниц, с тем чтобы увеличить пользовательское потребление и объем заказов. Модуль 236 продвижения содержит модуль 1602 управления продвижением, модуль 1604 обратной связи продвижения, модуль 1606 образования продвижения, модуль 1608 извлечения продвижения и модуль 1610 доставки продвижения. Функциональные возможности каждого из этих модулей более подробно объяснены ниже.

Обратимся к фиг.4 и 20, где в одном примере при продвижении позиций администратор 213 создает ряд кампаний вокруг конкретных позиций. Например, может быть создано продвижение для некоторых позиций, которые бизнес пытается предложить покупателям. Это может быть сделано администратором 213 через приложение 212 для рекомендаций (фиг.4), находящееся на связи с модулем 1606 образования продвижения и модулем 1602 управления продвижением, автоматически или так, как объяснено ниже.

В одном примере система 101 профилей и рекомендаций может определить наиболее релевантные продвижения для отдельного абонента и наиболее подходящее время для их доставки. Выполняя продвижения в интерактивном режиме, мобильный оператор может максимизировать вероятность покупки данной позиции абонентами. Например, если мобильный оператор хочет сформировать секцию «Звездные войны» на своем портале, то система 101 профилей и рекомендаций может сгруппировать весь указанный контент и услуги (например, мелодии для сотового телефона, экранные заставки, рабочие столы, анонсы, обзоры кинофильмов, игры, услуги по продаже билетов и т.д.) на одной странице или секции портала без ручных операций. Необходимо заметить, что в указанном примере отображаются только тот контент и услуги, которые применимы к абоненту или пользователю и соответствуют возможностям их мобильных устройств.

Кроме того, согласно одному примеру определяется профиль онлайнового поведения пользователей или абонентов с формированием обзора их покупательских привычек, а также оценкой успешности продвижений и сделанных им предложений. Затем всю эту информацию можно использовать для определения наилучшего способа и наилучшего времени дня/недели для продвижения нового предложения. Таким путем продвижение некоторой позиции предлагается пользователю или абоненту тогда, когда имеется максимальная вероятность успеха, и через тот канал, через который абонент скорее всего отреагирует. Например, если абонент посылает пять (5) или более одноранговых сообщений между 5.30 и 6.30 часами утра на неделе, это поведение можно идентифицировать и использовать как окно для продвижения позиции этому абоненту. По всей вероятности, время, когда абонент едет домой с работы на поезде или автобусе и может использовать это время для общения с друзьями и организации вечерних развлечений, является самым удобным временем для продвижения им той или иной позиции.

Модуль 236 продвижения, кроме того, может создавать целевые продвижения через множество каналов путем обеспечения интеллектуальных автоматизированных средств стимулирования использования контентных услуг как через онлайновый, так и исходящий механизмы. Продвижения доставляются через модуль 1610 доставки продвижения. В одном примере онлайновый механизм продвижения используется для абонентов, которые посещают проводной или беспроводный портал мобильного оператора. При исходящем продвижении продвижение посылают пользователям или абонентам с помощью таких средств, как SMS, MMS, WAP Push.

В одном примере онлайновые продвижения реализуются путем обмена данными между модулем 1608 извлечения продвижения и компонентой 208 информации об услугах о контенте, которая в одном примере содержит портал 226. В одном примере подобная интеграция выполняется через интерфейс портала для программирования приложений, интерфейс API на базе SOAP, который дает возможность порталу приобретать информацию из модуля 1608 извлечения продвижения (например, наилучшие продвижения для конкретного абонента и т.д.) и выдачи информации об использовании (например, «абонент проявил интерес к позиции при ее продвижении» и т.д.) через модуль 1604 обратной связи продвижения. Работая вместе с порталом, модуль 236 продвижения может отслеживать, какие абоненты посетили портал, какие продвижения были замечены и кто в результате «кликнул» по рекламной ссылке. Примером этого является ситуация, когда портал запрашивает подробности наиболее интересной рекламы для конкретного пользователя через модуль 1608 извлечения продвижения. Модуль 236 продвижения выдаст подробности рекламы (включая текст, изображение, ссылки и т.д.). Затем портал представит эту рекламу на сайте в подходящем месте.

Вдобавок к предоставлению портальным интерфейсом API информации на портал, портал также может передать информацию обратно в модуль 236 продвижения с помощью модуля 1604 обратной связи профиля. Это позволяет модулю 236 продвижения больше узнать о поведении абонентов, а значит, работать более эффективно. Примеры этого включают в себя сообщение о том, что абонент посетил портал, а также о продвижениях, которые в результате привели к покупке, а также продвижениях, которые не увенчались покупками. Поскольку модуль 236 продвижения обладает этой информацией, он может представить отчеты об эффективности кампании.

Согласно одному аспекту модуль 236 продвижения может выполнить онлайновые продвижения различных типов, каждое из которых обеспечивает различные пути представления целевых продвижений для абонентов, когда те перемещаются по порталу. Далее следуют примеры онлайновых продвижений.

Банерная реклама. Это целевая реклама, которую размещают на портале, где ее пользователь или абонент может просмотреть и выбрать то, что его интересует. После выбора, сделанного абонентом, ему показывают детали продвижения, на основании которых абонент может перейти к покупке, если пожелает. В одном примере банерная реклама является графической. Банерная реклама также может быть задана в области отображения, которая позволяет показать продвижения позиций в подходящих частях портала (например, демонстрация продвижения мелодии для телефона в разделе мелодий для телефона, а не в разделе финансовых новостей, и т.д.).

Постпродажная реклама. Эта реклама демонстрируется абонентам после покупки. Контент, относящийся к перекрестной продаже, может быть сконфигурирован администратором 212 системы профилей и рекомендаций или может быть создан автоматически модулем 234 принятия решения.

Комплекты. Отдельные фрагменты контента или услуг могут быть сгруппированы вместе и предложены абонентам для покупки со скидкой. Информация о комплектах сортируется в модуле 236 продвижения, откуда портал может ее извлечь. Когда абонент покупает комплект, портал контролирует его исполнение вместе с системой профилей и рекомендаций. В одном примере модуль 236 продвижения фиксирует покупки комплектов для будущего использования.

Целевые ссылки в меню. Эти ссылки помещают в структуру меню портала, причем они нацелены на привлечение абонентов к зонам портала, где им может быть предложен подходящий контент или услуги. Размещение этих ссылок в связи с другими статическими или персонализированными ссылками контролируется системой управления порталом.

Исходящие продвижения основаны на исходящих широковещательных рассылках и нескольких механизмах входящей связи, к которым относится следующее.

Широковещательные рассылки. Широковещательные рассылки для групп абонентов могут быть созданы модулем 1602 управления продвижением. Широковещательным сообщением может быть SMS, MMS или WAP push-сообщение, которое может оказаться полезным при продвижении нового контента и услуг.

Кампании на основе SMS. В одном примере при использовании SMS модуль 236 продвижения обеспечивает автоматическое управление информацией о контенте/сессии абонента. Администратор 213 через связь с модулем 1602 управления продвижением может создать текстовое сообщение, которое абоненты должны развить в ходе обсуждения (поддержка повторяющихся выражений для обеспечения более сильного соответствия). Для фиксации неправильных сообщений и возврата консультативного сообщения, восприимчивого к контексту, могут быть добавлены стандартные операторы-ловушки.

Кампании на основе сообщений WAP. При использовании канала WAP администратор 213 может задавать отдельные страницы, которые будут отображаться на мобильном устройстве. Эти страницы могут включать в себя текст, изображения, поля записей данных (введенные данные хранятся в виде переменных), ссылки на внешние страницы WAP и т.д.

В одном примере широковещательные рассылки могут доставляться модулем 1610 доставки продвижения в виде сообщений WAP Push, которые, при их активизации абонентами, будут приводить их к онлайновой версии продвижения позиции. Это обеспечивается следующими тремя путями: (А) Ссылка, заключающаяся в сообщении WAP Push, указывает на другую систему (например, портал и т.д.), где доступна информация о продвижении. Это может оказаться идеальным механизмом для информирования абонентов о новой услуге на портале; (В) Записывают подробности о действиях отреагировавших абонентов, которые затем переправляют в другую систему (например, портал и т.д.). Это может быть полезным, когда необходимо отслеживание реакций абонентов в реальном времени. Затем модуль 236 продвижения обеспечивает онлайновые отчеты в реальном времени, которые показывают общее количество респондентов; и (С) Ссылка указывает на страницу, заключающую в себе подробности продвижения. В одном примере администратор 213 может создать страницу продвижения через редактор типа «Что увидишь, то и получишь» (WYSIWYG), осуществляющий связь с модулем 1606 образования продвижения. Модуль 236 продвижения может воспроизвести информацию о продвижении, включая изображения, на языке гипертекстовой разметки (HTML), языке беспроводной разметки (WML), расширенном языке гипертекстовой разметки (XHTML) мобильного устройства. Абонент может просматривать информацию о продвижении непосредственно из модуля 236 продвижения, причем в нее могут быть включены изображения и ссылки на внешние порталы. Это техническое решение можно использовать, когда для передачи продвижения (например, в виде рекламного листка и т.д.) и обеспечения ссылки вперед на более детальную информацию или диалог при покупке можно использовать единую WAP панель. Эта опция позволяет быстро создавать продвижение без необходимости обновления портала мобильного оператора.

В одном примере часть исходящих продвижений необходима для обеспечения механизма входящей связи для абонентов, реагирующих на продвижение позиции. Модуль 236 продвижения обеспечивает следующие механизмы.

Группы по интересам. Абоненты могут зарегистрировать свои интересы в конкретном продвижении или теме, прореагировав (например, через SMS и т.д.) простым ключевым словом. Модуль 236 продвижения может автоматически следить за тем, к каким позициям абоненты проявили интерес, и сохранить эту информацию для использования в будущем. Это может обеспечить идеальный подход к формированию механизмов маркетинга на основе абонентов, таких как группы лояльности или общины.

Интерактивная кампания. Модуль 236 продвижения способен поддерживать создание более сложных кампаний и интерактивных услуг с помощью модуля 1606 образования продвижения посредством использования своего приложения, поддерживающее сценарии диалогов (CSA). Приложение CSA обеспечивает графический способ создания указанных сценариев диалога путем предоставления администраторам возможности перетаскивать компоненты или названные операторы по экрану CSA и сопряжения их вместе для создания различных вариантов развития диалогов, которым могут следовать абоненты, принимающие участие в кампании.

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

В одном примере исходящие продвижения могут выполняться через источник 210 информации о профиле абонента, который содержит, например, внешний CRM или системы автоматизации маркетинга, такие как Epiphany of Infor Global Solutions GMbH, Alpharetta, GA, Unica Corporation of Waltham, MA или Chordiant Software, Inc. of Cupertino, CA. Такая интеграция может просто представлять собой создание широковещательных рассылок или может доходить до создания разрекламированных интерактивных кампаний, результаты которых поступают обратно в CRM или маркетинговую систему. В одном примере эта интеграция обеспечивается через группу продвижения и интерфейс API управления широковещательными рассылками.

Модуль 236 продвижения также позволяет обеспечить целевые продвижения путем создания профильных групп. Эти списки либо могут импортироваться системой профилей и рекомендаций, либо создаваться ей с использованием накопленной информации о привычках абонентов.

Модуль 236 продвижения может быть развернут сам по себе или вместе с другими модулями системы профилей и рекомендаций, включая модуль 232 профилей, модуль 230 каталога и модуль 234 принятия решения. При автономном разворачивании модуль 236 продвижения предоставляет администраторам возможность быстрого создания и выполнения целевых продвижений к заданным абонентам с помощью модуля 1606 образования продвижения. При использовании вместе с модулем 232 профилей, модулем 230 каталога и модулем 234 принятия решения, модуль 236 продвижения имеет возможность обеспечить более адресные автоматизированные и усложненные продвижения, которые станут более успешными. Это возможно потому, что при использовании, в сочетании с другими модулями системы профилей и рекомендаций, модуль 236 продвижения может повысить качество решения, обеспечив более качественный выбор при продвижении позиций для онлайновых абонентов. При использовании модуля 234 принятия решения применяют правила и алгоритмы, которые эффективно используют информацию в профильном модуле 232 профилей и модуле 230 каталога для направления наилучшего (из всех возможных) варианта продвижения целевым абонентам. Предложенные исходящие продвижения также вычисляются автоматически и представляются пользователю. Модуль 234 принятия решения может взять созданные продвижения и определить, каким абонентам их следует направить в исходящем режиме. Автоматическое создание продвижения также можно обеспечить, исходя из информации, хранящейся в модуле 230 каталога. В одном примере (без других компонент системы профилей и рекомендаций) администратору 213 необходимо вручную идентифицировать контент/услуги, которые требуется продвигать. Однако при использовании модуля 234 принятия решения этот модуль может автоматически создать рекомендации (например, постпродажа, исходящие широковещательные рассылки и т.д.), исходя непосредственно из информации, сохраненной в каталожном и профильном модулях 232 профилей и 230 каталога соответственно.

Продвижение может часто включать в себя цену со скидкой для рассматриваемого контента или услуги. Модуль 236 продвижения позволяет администраторам предварительно оценить контент путем обеспечения указанной информации о скидке для ее использования во время продвижения позиции. В зависимости от того, насколько достигнута биллинговая интеграция, эта информация о продвигаемом тарифе либо может направляться в биллинговую систему непосредственно из модуля 236 продвижения, либо поступать на портал для биллинговых операций. Модуль 236 продвижения также предоставляет администраторам функции управления на основе Web, которые путем взаимодействия с модулем 1602 управления продвижением могут обеспечить возможность эффективного управления множеством одновременных широковещательных рассылок и могут без труда обеспечить доставку многих миллионов сообщений в день. Эти функции могут включать в себя: (А) Процесс авторизации с учетом особенностей потребителей на основе конкретных деталей широковещательных рассылок, таких как объем, дросселирование, время и т.д.; (В) Периоды ограничения широковещательных рассылок (например, с 9 ч утра до 5 ч вечера с понедельника по пятницу), с игнорированием администратора, если это необходимо; (С) Дросселирование созданного сообщения согласно сетевым нормам; (D) Ежедневный и еженедельный просмотр выполнения или будущих широковещательных рассылок; (Е) Ограничение количества сообщений, которое посылается в один день - это может быть требованием, инициируемым сетью; (F) Отчет и контроль в реальном времени по длительным широковещательным рассылкам. В отчетах показывают процент завершенных широковещательных рассылок и расчетное время окончания. Администраторы имеют возможность без труда прервать, возобновить и прекратить широковещательную рассылку; и (G) Повторение широковещательных рассылок ежедневно, еженедельно и ежемесячно.

Следует заметить, что из-за высокой степени автоматизации, обеспечиваемой модулем 236 продвижения, можно выполнить значительно меньше продвижений (более целенаправленных продвижений), в противоположность меньшему количеству объемных универсальных продвижений. Кроме того, модуль 236 продвижения позволяет согласовать количество широковещательных рассылок применительно к конкретному абоненту. Например, можно контролировать количество широковещательных рассылок, которое абонент должен получить в течение определенного периода, время дня, когда абоненты должны получать широковещательные рассылки, и предпочтительный для абонентов механизм связи (например, SMS, MMS и т.д.).

В одном примере модуль 236 продвижения также может создавать и доставлять уникальные купоны как часть широковещательной рассылки или следящего канала. Их можно использовать для получения определенных выгод, таких как скидки, кредиты, подарки или товары и т.д.

Согласно одному аспекту в тексте широковещательной рассылки также могут быть использованы переменные для приспособления контента к абоненту. Эти переменные представляют собой значения, привязанные к абоненту, которые могут быть настроены администратором 213, внешними системами или самими абонентами. Например, в широковещательную рассылку можно включить имя или баланс абонента. Переменные можно также использовать для реализации точек лояльности, где абонент формирует точки реагирования на кампании. Значения переменных могут быть доступны внешней системе через интерфейс XML API.

В одном примере модуль 236 продвижения также может обеспечить в реальном времени отчеты об успешных (или неудачных) продвижениях. Он может предоставить статистику о количестве абонентов, которые ознакомились, проявили интерес, отреагировали или отвергли конкретное продвижение. Возможность получить эти результаты в реальном времени означает, что события, которые регулярно происходят, могут быть немедленно модифицированы для обеспечения их эффективности в будущем, успешные события могут быть повторены, а события, не принесшие успех, могут быть опущены.

Согласно одному аспекту доступ к продвижениям может быть осуществлен через интерфейс API портала таким же образом, как и доступ к рекомендациям. API портала предоставляет несколько интерфейсов API для запроса продвижения и передачи обратно событий, инициируемых пользователем в связи с продвижением (например, посредством щелчка мышью), в систему профилей и рекомендаций. В другом примере доступ к продвижениям может быть получен через связь между пользовательским интерфейсом блока 212 приложения для рекомендаций и модулем 1602 управления продвижением для создания исходящего продвижения через сообщения SMS, MMS, WAP Push и т.д. В этом случае модуль 1610 доставки продвижения можно использовать для реальной доставки информации по исходящему продвижению или просто для создания списка телефонных номеров целевых абонентов. При создании списка целевых абонентов можно задать как количество абонентов, так и требуемый минимальный уровень доверия. Это означает возможность выполнения таких действий, как создание первых 100000 абонентов, которые должны стать целями конкретной позиции, с определенной минимальной степенью достоверности.

Согласно одному варианту реализации создание продвижения с помощью модуля 1606 образования продвижения может включать в себя три этапа: первый этап (общие детали), второй этап (целевые абоненты) и третий этап (доставка).

На первом этапе администратор 213 выдает некоторые общие детали, касающиеся продвижения, включая: (А) Имя и описание; (В) Тип продвижения (например, банерная реклама, линия связи WAP, комплект, перекрестная покупка и т.д.); (С) Вес - Вес продвижения используют при выборе наилучшего продвижения для абонента при существовании более одного возможного продвижения. Например, если существуют два продвижения, задающие одинаковые профильные группы, то для определения правильного продвижения для абонента в этой группе можно использовать вес; (D) Предлагаемая позиция. Это может быть конкретный фрагмент контента из модуля 230 каталога (например, игра Pac Man Java и т.д.) или категория контента, выбранная из модуля 230 каталога (например, полифонические роковые мелодии по телефону и т.д.); (Е) Ссылка на позицию контента, принадлежащего внешней системе (например, бизнес-рубрики); (F) Сфера - Сфера продвижения идентифицирует область, для которой данное продвижение окажется подходящим, например может быть создано продвижение с областью мелодий для телефона, указывающей, что это продвижение следует показывать в части портала, относящейся к мелодиям для телефона.

На втором этапе запрашивается администратор 213 на предмет задания механизма идентификации целевых абонентов для данного продвижения. Целевая группа определяет абонентов, которым могут быть представлены продвижения. Имеются три иллюстративные опции:

Опция А. Глобальная - Продвижения, имеющие глобальную цель, могут быть показаны любому абоненту пока абоненты не ознакомились с этим продвижением определенное количество раз или не совершили покупку по продвигаемой позиции. Глобальные продвижения могут иметь меньший вес, чем более нацеленные продвижения;

Опция В. Профильная группа (группы) - Администратор 213 также может задать одну или несколько профильных групп, которым может быть доступно продвижение. Эти группы могут представлять собой списки телефонных номеров абонентов, импортированные в модуль 232 профилей, или могут быть созданы модулем 232 профилей на основе записанных действий или атрибутов абонента; и

Опция С. Решение. При использовании модуля 234 принятия решения для определения того, следует ли показывать конкретное продвижение данному абоненту, модуль 234 принятия решения сначала определяет расширенный список рекомендаций для этого человека, а затем сравнивает этот список с позициями, заключенными в данном продвижении. Если какая-либо позиция в данном продвижении имеется в списке рекомендаций пользователя, и абонент не сделал покупку по какой-либо продвигаемой позиции, то тогда это продвижение годится для демонстрации абоненту. При выборе такого механизма нацеливания можно выбрать минимальный уровень доверия, который должно иметь решение для данного продвижения, чтобы оно годилось для отображения абоненту.

На третьем этапе администратор 213 определяет дополнительные материалы, которые будут использованы для представления продвижения абоненту. Они могут быть разделены на онлайновые и исходящие. При онлайновом варианте администратору 213 предлагается обеспечить текст или графику на основе Web и WAP, которые будут отображаться на портале. В одном примере задаются сводные и подробные дополнительные материалы. Сначала абонентам показывается сводная информация, а подробная информация показывается, как только абонент запросит дополнительную информацию о продвижении. Дополнительные материалы этого типа делают доступными на портале через интерфейс API портала. При использовании исходящих дополнительных материалов администратор 213 конфигурируется для их подачи через другой исходящий механизм, который абоненты хотят использовать. Администратор 213 может задать контент SMS, MMS, WAP Push и т.д. Затем эта информация будет использована модулем 1610 доставки продвижения при выполнении исходящего продвижения.

На фиг.21 показана блок-схема примерной последовательности 1700 обработки в модуле 236 продвижения. На шаге 1702 приобретается имеющийся список продвижений, созданный администратором. На шаге 1704 создаются рекомендации для абонента. На шаге 1706 продвижения сравнивают с рекомендациями для абонента, например, путем проверки на совпадение. На шаге 1708 определяют продвижения, которые есть в списке рекомендаций, но соответствующие позиции не были куплены абонентом (в одном примере предыдущая обработка может сделать эту проверку излишней). На шаге 1710 этот список продвижений подается во внешнее приложение. Затем внешнее приложение может пропустить эти продвижения для доставки абоненту в онлайновом режиме через Web-портал или в исходящем режиме через сообщение SMS, MMS, WAP Push и т.д. на мобильное устройство абонента.

Вдобавок к вышеупомянутым модулям системы профилей и рекомендаций в сети 1800 профилей и рекомендаций модуль 1801 профилей и рекомендаций в одном примере может включать в себя дополнительные модули. На фиг.22 детализируются вышеупомянутые компоненты по фиг.4 системы профилей и рекомендаций вместе с контентным модулем 1804 и соединительным модулем 1802 согласно одному аспекту изобретения.

Контентный модуль 1804 обеспечивает возможность управления и доставки контента для широкого диапазона контента или услуг. Соединительный модуль 1802 обеспечивает доставку сообщений SMS, MMS, WAP и загружаемого контента. Согласно одному примеру при этом поддерживаются все стандартные отраслевые сетевые протоколы подключаемости и доставки. Контентный модуль 1804 может интегрироваться с источником 210 информации о профиле абонента, такой как биллинговая система, для начисления платы за контент или услуги. Вдобавок, контентный модуль 1804 может быть интегрирован с системами предоплаты и оплаты по факту через множество различных протоколов. Контентный модуль 1804 может также быть интегрирован с блоком 208 информации об услугах и контенте для демонстрации имеющегося контента или услуг на Web- или WAP-порталах (например, название, артист, анонсы и т.д.) и инициирования доставки контента или услуг.

В одном примере контентный модуль 1804 предоставляет возможность локального хранения, управления и доставки контента любого типа. Надежное хранение и управление контентом и информацией может быть обеспечено, например, через Web-интерфейс, причем информация и контент могут доставляться через серверы операторского класса для загрузки предупреждений и контента по требованию.

Система профилей и рекомендаций может дополнительно поддерживать множество различных механизмов для автоматического приема и сбора контента от внешних источников. Может быть сконфигурирована платформа для получения контента в виде HTTP/XML или FTP (протокол пересылки файлов)/XML от внешних источников и обеспечения инфраструктуры для реализации конкретных механизмов поставщика контента для интеграции контента. Согласно одному аспекту система профилей и рекомендаций может также активно приобретать контент из внешних источников, таких как RSS (расширенная сводка сайта). В одном примере поставщики контента могут использовать интерфейс API представления контента в системе профилей и рекомендаций для управления контентом с использованием определенного формата XML через HTTP.

Кроме того, может быть сконфигурирован контентный модуль 1804 для обеспечения активного или не активного обновления, в зависимости от типа проверки контента, который может потребоваться. Администратор 213 может обеспечить тот тип авторизации, который требуется для каждого типа контента. В одном примере надежный контент может проверяться автоматически, в то время как для контента других типов может потребоваться разрешение от администратора 213 или контентного администратора мобильного оператора.

Кроме того, контентный модуль 1804 может поддерживать создание и управление предупредительными сообщениями на основе подписки, а также доставку SMS, MMS или других типов контента. Абоненты могут создать расписание персонализированных предупредительных сообщений, привязанных к их интересам, с возможностью определения таких параметров, как носитель (например, SMS или MMS и т.д.), время доставки, язык, часовой пояс и т.д. Модуль предупредительных сообщений контентного модуля 1804 имеет возможность удовлетворять требованиям мобильных операторов, обеспечивая своевременную доставку контента или услуг.

Согласно одному варианту модуль загрузки контента обеспечивает сервер загрузки для всех загружаемых типов контента, включая, но не только, Java, мелодии для сотового телефона, экранные заставки и т.д. В одном примере модуль загрузки контента обеспечивает следующие функции: (А) Доставка приложений Java (например, игры и т.д.), архива Java (JAR) или формата разработки приложений (JAD) (двухэтапная загрузка); (В) Каждой загрузке может быть присвоен уникальный указатель URL, и она может иметь свой собственный символический идентификатор (ID); (С) Перезапись файла JAD для задания динамических координат загрузки JAR; (D) Повторная загрузка может быть разрешена в течение конфигурируемого периода времени или ограничена числом попыток; (E) Для загрузки контента может быть использовано управление цифровыми правами (DRM); (F) Загрузка может быть инициирована через сообщение WAP Push или непосредственно из портала WAP; и (G) Интерфейс CSR для просмотра действий пользователя основан на номере мобильного абонента цифровой сети с интеграцией служб (MSISDN) с возможностью повторения загрузки при необходимости.

Может быть сконфигурирован модуль для использования, по существу, всех возможных стандартов и методов для обеспечения успешной загрузки и точного биллинга загруженного контента. Он может включать в себя интерфейс API извещения о загрузке, который позволяет серверу загрузки извещать внешнюю систему о прохождении различных этапов загрузки. Эти извещения можно использовать для прекращения загрузки в любой момент или создания биллинговых событий.

Согласно одному примеру соединительный модуль 1802 может быть сконфигурирован с функцией управления цифровыми правами (DRM), которая дает возможность применения прямой блокировки DRM версии 1 Открытого сообщества производителей средств мобильной связи (OMA), комбинированной доставки и раздельной доставки для избирательного контента, как это определено администратором платформы или поставщиками контента.

Согласно одному аспекту соединительный модуль 1802 включает в себя механизм транскодирования, который может быть сконфигурирован для поддержки транскодирования между множеством различных форматов контента и кодеков. Вдобавок, механизм транскодирования может быть сконфигурирован для обеспечения собственной профильной базы данных устройства, которая тестируется и настраивается специально для доставки мультимедийного контента.

Согласно одному аспекту соединительный модуль 1802 может выполнять обработку по следующим трем сценариям доставки контента:

Сценарий 1. Информация по требованию. В этом сценарии запросы на услуги или контент обрабатываются путем отображения запросов на услуги или контент на соответствующий источник контента, извлечения текущего контента или услуги из этого источника и направления ее абоненту;

Сценарий 2. Запланированная доставка. Запланированная доставка может быть основана либо на фиксированном расписании доставки, заданном системным администратором 213, либо на расписании, заданном абонентом. В этом случае извлечение контента или услуг и доставка их абонентам выполняется в моменты времени, заданные в указанных расписаниях; и

Сценарий 3. Незапланированная доставка. Доставка незапланированного контента или услуг может инициироваться либо вручную, либо автоматически в результате внешнего события. В этом случае контент или услуга направляется абонентам из источника контента или услуг.

Контентный модуль 1804 может быть интегрирован с существующим порталом через предусмотренный интерфейс API портала или в случаях, когда существующая витрина заменена, контентный модуль 1804 может установить витрину, удовлетворяющую требованиям мобильного оператора. Контентный модуль, кроме того, обеспечивает витрину креативного типа, которая позволяет мобильным операторам торговать контентом или услугами через множество витрин и множество каналов доставки. Такая предлагаемая по умолчанию витрина может быть модернизирована таким образом, чтобы удовлетворять функциональным возможностям и брендовым требованиям конкретного мобильного оператора.

В одном примере, поскольку витрина была предварительно интегрирована с остальной частью системы профилей и рекомендаций, она может наилучшим образом использовать все системные функции. Согласно одному аспекту витрина может позволить мобильному оператору: (А) Предлагать абонентам обширный набор услуг; (В) Продвигать новые услуги; (С) Формировать предложения по комплектованию контента; (D) Предоставить абонентам дружественный интерфейс для покупок и подписки на услуги по предоставлению контента; (Е) Отображать версии витрины, привязанные к конкретному сегменту рынка; и (F) Создавать списки первых десяток для продвижения новых/популярных услуг.

Вдобавок, витрина может помочь абоненту: (А) Просматривать весь полный диапазон предлагаемых контентных услуг (либо все услуги, либо услуги, доступные в этом сегменте рынка); (В) Покупать контентные услуги (например, игры, мелодии для телефона и т.д.); (С) Подписываться на контентные услуги (например, предупредительные сообщения и т.д.); (D) Управлять своими подписками на контентные услуги; и (Е) Составлять свое собственное расписание доставки контента.

В ситуации, когда контент или услуга должны продаваться по разным каналам, система профилей и рекомендаций может быть сконфигурирована с множеством витрин. Например, мобильный оператор может продвигать свой контент или услуги через множество брендов или оптовых торговых посредников. В одном примере для каждого канала может поддерживаться специально заказанная витрина.

Контентный модуль 1804, кроме того, может быть сконфигурирован для обеспечения защищенного, надежного и проверенного механизма сохранения и управления контентом. В одном случае безопасность обеспечивается через протокол защиты информации (SSL) и аутентификацию имени/пароля пользователя. Согласно одному примеру доступ к контенту может быть ограничен, так что ограничивается доступ поставщиков контента к своему собственному контенту. Просмотр и авторизация контента может выполняться либо администратором 213 платформы, либо внешними владельцами контента.

Согласно одному аспекту для обеспечения возможности доставки контента того типа, который предложен поставщиками, в оптимальном формате, соответствующем возможностям пользовательского или абонентского устройства, можно использовать интеллектуальный выбор контента. Путем отображения возможностей устройств на устройства и отдельные позиции контента или услуги система профилей и рекомендаций может определить, какую услугу или какой фрагмент контента необходимо доставить. В случае если устройство имеет несколько функциональных возможностей, система профилей и рекомендаций может использовать систему взвешивания для определения наиболее подходящего контента для доставки.

Вновь обратимся к фиг.22, где в одном примере данные для модулей 230 каталога и 232 профилей соответственно могут импортироваться из систем (например, биллинговая система, CRM, платформы услуг с добавленной стоимостью (VAS) (например, платформа предупредительных сообщений и т.д.) и т.д.) через соединительный модуль 1802. Согласно одном аспекту соединительный модуль 1802 обеспечивает упрощение и автоматизацию импорта и экспорта информации для модуля 232 профилей и модуля 230 каталога в и из системы профилей и рекомендаций.

Обратимся к фиг.23, где примерная среда 1900 для реализации различных аспектов заявленного предмета изобретения включает в себя компьютер 1912. Компьютер 1912 включает в себя блок 1914 обработки, системную память 1916 и системную шину 1918. Системная шина 1918 сцепляет системные компоненты, включая, но не только, системную память 1916 с блоком 1914 обработки. Блоком 1914 обработки может быть любой из имеющихся различных процессоров. В качестве блока 1914 обработки также можно использовать сдвоенные микропроцессоры и другие микропроцессорные архитектуры.

Системная шина 1918 может представлять собой любую шинную структуру (структуры) нескольких типов, включая шину памяти или контроллер памяти, периферийную шину или внешнюю шину, и/или локальную шину, использующую любой вариант из доступных шинных архитектур, включая, но не только: шину с архитектурой промышленного стандарта (ISA); шину с микроканальной архитектурой (MCA); шину с расширенной архитектурой ISA (EISA); шину с архитектурой для электроники интеллектуальных устройств (IDE); локальную шину VESA Ассоциации по стандартам видеооборудования (VLB); шину для межсоединений периферийных компонент (PCI); шину CardBus; универсальную последовательную шину (USB); шину для порта ускоренной графики (AGP); шину Международной ассоциации производителей плат памяти для персональных компьютеров (PCMCIA); шину FireWire (IEEE 1394) и шину для интерфейса малых компьютерных систем (SCSI).

Системная память 1916 включает в себя энергозависимую память 1920 и энергонезависимую память 1922. Базовая система ввода/вывода (BIOS), заключающая в себе базовые стандартные программы для пересылки информации между элементами в компьютере 1912, например, во время запуска, хранится в энергонезависимой памяти 1922. Как пример, но не как ограничение, энергонезависимая память 1922 может включать в себя память только для считывания (ПЗУ) (ROM), программируемое ПЗУ (ППЗУ) (PROM), электрически программируемое ПЗУ (ЭППЗУ) (EPROM), электрически стираемое ППЗУ (ЭСПЗУ) (EEPROM) или флэш-память. Энергозависимая память 1920 включает в себя оперативное запоминающее устройство (ОЗУ) (RAM), которое действует как внешняя кэш-память. В качестве иллюстрации, но не как ограничение, ОЗУ может быть представлено в различных видах, таких как статическое ОЗУ (SRAM), динамическое ОЗУ (DRAM), синхронное динамическое ОЗУ (SDRAM), запоминающее устройство SDRAM c удвоенной скоростью передачи данных (DDR SDRAM), усовершенствованное запоминающее устройство SDRAM (ESDRAM), запоминающее устройство Synchlink DRAM (SLDRAM), и шину прямого резидентного доступа Rambus RAM (RDRAM), шину прямого резидентного доступа Rambus DRAM (DRDRAM) и шину Rumbus DRAM (RDRAM).

Компьютер 1912 также включает в себя съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители данных. На фиг.23 показано, например, дисковое запоминающее устройство 1924. Дисковое запоминающее устройство 1924 включает в себя, но не только, такие устройства, как накопитель на магнитном диске, накопитель на гибком диске, накопитель на ленте, накопитель Jaz, накопитель Zip, накопитель LS-100, карту флэш-памяти или карту памяти цифрового фотоаппарата. Вдобавок, запоминающее устройство 1924 на дисках может включать в себя носитель данных, существующий отдельно или в комбинации с другими носителями данных, включая, но не только: накопитель на оптическом диске, например, ПЗУ на компакт-диске (CD-ROM), накопитель на компакт-диске с однократной записью (накопитель CD-R), накопитель на перезаписываемом компакт-диске (накопитель CD-RW Drive) или накопитель на цифровом универсальном компакт-диске (DVD-ROM). Для облегчения подсоединения дисковых запоминающих устройств 1924 к системной шине 1918 обычно используют съемный или несъемный интерфейс, такой как интерфейс 1926.

Следует принять во внимание, что фиг.23 дает представление о программном обеспечении, которое действует в качестве посредника между пользователями и базовыми компьютерными ресурсами, описанными в подходящей операционной среде 1900. Указанное программное обеспечение включает в себя операционную систему 1928. Операционная система 1928, которая может храниться в дисковом запоминающем устройстве 1924, осуществляет управление и распределение ресурсов компьютерной системы 1912. Системные приложения 1930 пользуются возможностями управления ресурсами операционной системой 1928 через программные модули 1932 и программные данные 1934, хранящиеся в системной памяти 1916 или в дисковом запоминающем устройстве 1924. Следует принять во внимание, что рассматриваемое изобретение можно реализовать с помощью различных операционных систем или их комбинаций.

Пользователь вводит команды или информацию в компьютер 1912 через устройство (устройства) 1936 ввода. Устройства ввода 1936 включают в себя, но не только: указательное устройство, например мышь, шаровой манипулятор, перо, сенсорную панель, клавиатуру, микрофон, джойстик, игровую панель, спутниковую тарелку, сканер, карту селектора телевизионных каналов, цифровую камеру, цифровую видеокамеру, Web-камеру и т.п. Эти и другие устройства ввода подсоединены к блоку 1914 обработки через системную шину 1918 с использованием интерфейсного порта (портов) 1938. Интерфейсный порт (порты) 1938 включает в себя, например: последовательный порт, параллельный порт, игровой порт и универсальную последовательную шину (USB). Устройство (устройства) 1940 вывода используют некоторые из тех же портов, что и устройство (устройства) 1936 ввода. Так, например, порт USB можно использовать для обеспечения ввода в компьютер 1912 и вывода информации из компьютера 1912 на устройство 1940 вывода. Выходной адаптер 1942 предусмотрен для того, чтобы показать, что среди других устройств 1940 вывода имеется ряд устройств, таких как мониторы, динамики и принтеры, для которых требуются специальные адаптеры. Выходные адаптеры 1942 включают в себя, в качестве примера, но не как ограничение, видео- и звуковые карты, которые обеспечивают средства соединения между устройством 1940 вывода и системной шиной 1918. Следует заметить, что другие устройства и/или системы, состоящие из таких устройств, обеспечивают как функцию ввода, так и функцию вывода, как, например, удаленный компьютер (компьютеры) 1944.

Компьютер 1912 может работать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, такими как удаленный компьютер (компьютеры) 1944. Удаленный компьютер (компьютеры) 1944 может представлять собой персональный компьютер, сервер, маршрутизатор, сетевой персональный компьютер, рабочую станцию, бытовой прибор на микропроцессорной основе, равноправное устройство или другой известный сетевой узел и т.п., причем такой удаленный компьютер, как правило, включает в себя большинство или все элементы, описанные применительно к компьютеру 1912. Для краткости показано, что удаленный компьютер (компьютеры) 1944 имеет только запоминающее устройство 1946. Удаленный компьютер (компьютеры) 1944 логически соединен с компьютером 1912 через сетевой интерфейс 1948, а затем физически подсоединен через коммуникационное соединение 1950. Сетевой интерфейс 1948 охватывает проводные и/или беспроводные сети связи, такие как локальные сети (LAN) и глобальные сети (WAN). Технологии LAN включают в себя интерфейс для передачи распределенных данных по волоконно-оптическим каналам (FDDI), проводной интерфейс для передачи распределенных данных (CDDI), сеть Ethernet, сеть Token Ring (маркерное кольцо) и т.п. Технологии WAN включают в себя, но не только: двухточечные линии связи, сети с коммутацией каналов, такие как цифровая сеть с комплексными услугами (ISDN) и их вариации, сети с коммутацией пакетов и цифровые абонентские линии (DSL).

Коммуникационное соединение (соединения) 1950 относится к аппаратным/программным средствам, используемым для подсоединения сетевого интерфейса 1948 к шине 1918. Хотя коммуникационное соединение 1950 показано для ясности внутри компьютера 1912, оно также может быть внешним по отношению к компьютеру 1912. Аппаратные/программные средства, необходимые для подсоединения к сетевому интерфейсу 1948, включают в себя, только как пример, такие средства внутренней и внешней связи, как модемы, включая модемы стандартного телефонного качества; кабельные модемы и модемы DSL; адаптеры ISDN и карты Ethernet.

На фиг.24 сетевое устройство 2400 заключает в себе считываемый компьютером носитель 2402 данных, заключающий в себе средство, которое заставляет один или несколько процессоров 2404 выполнять описанные здесь методики для профилирования и рекомендации контента пользователям беспроводных устройств. Такое средство может представлять собой наборы модулей программных кодов, программно-аппаратных и аппаратных модулей или их комбинацию. Сетевой коммуникационный модуль 2406 обеспечивает передачу рекомендаций на беспроводные устройства, который в иллюстративном варианте реализации имеет связь с мобильным оператором (на фиг.24 не показан). Согласно иллюстративному аспекту модуль 2408 обращается к атрибутивным данным и поведенческим данным для множества пользователей соответствующего множества мобильных устройств. Модуль 2410 создает рекомендации для предлагаемого контента на основе атрибутивных данных, а также создает рекомендации для предлагаемого контента на основе поведенческих данных. Модуль 2412 выбирает поднабор рекомендаций путем применения фильтрующего ограничения. Модуль 2414 передает этот поднабор рекомендаций по меньшей мере на один поднабор из множества мобильных устройств.

В одном случае модули 232 профилей и 230 каталога соответственно могут обеспечить интерфейсы API на основе протоколов HTTP/XML для пересылки данных. Эти интерфейсы API (вместе с UI на основе Web) могут удовлетворять требованиям по обмену данных для развернутой системы (например, система, развернутая на ранних этапах и т.д.). В одном случае также могут поддерживаться обмены данными, требующие более сложной интеграции. В одном примере соединительные модули 1802 обеспечивают обработку для обменов данными посредством использования агентов для обмена данными, способных обеспечить механизмы для импорта и экспорта контента в разных форматах с использованием множества различных механизмов транспортировки. Соединительный модуль 1802 может также поддерживать внешние системы, имеющие свое собственное средство представления данных. Например, указанная внешняя система может иметь специальные требования/возможности, касающиеся того, каким образом внешние системы могут распределять или получать данные. Вдобавок, внешние системы могут использовать различные механизмы транспортировки для онлайновой или автономной (пакетной) транспортировки. Например, для онлайновых механизмов могут быть использованы Протокол гипертекстовой пересылки (HTTP), простой протокол доступа к объектам (SOAP), архитектура извлечения контента (COBRA), инициирование удаленного способа (RMI) и т.д., в то время как для механизмов автономной транспортировки могут использоваться протокол FTP и очереди сообщений. Транспортные уровни соединительного уровня 1802 поддерживают множество конфигурируемых транспортировок.

В одном примере уровень транспортировки отвечает за следующее: (А) Извлечение данных посредством подходящего протокола. Это может включать в себя извлечение файла через протокол FTP и его открытие или получение кодированных данных XML через протокол HTTP; (B) Потоковая передача данных в сконфигурированные кодеры. Можно одновременно переслать данные на множество экземпляров кодера для повышения эффективности; (С) Архивирование данных. Необязательное хранение обработанных данных для обращения к ним в будущем; и (D) Каждый блок транспортировки ассоциируют с кодером, с помощью которого можно создать один или несколько экземпляров для обработки полученных данных. Для каждой точки интеграции может быть сконфигурировано множество блоков транспортировки.

В одном примере соединительный модуль 1802 может использовать кодеры для трансляции данных из формата внешней системы, в формат, воспринимаемый модулей 232 профилей или модулем 230 каталога, и наоборот. Кодерам известен формат данных для конкретной реализации, и они знают, как выполнить трансляцию из этого формата в формат, требуемый системой профилей и рекомендаций. В одном примере основными задачами кодеров могут быть: (А) Прием входных данных от транспортного агента; (В) Проверка принятых данных и создание отчетов исключений, когда это необходимо. Отчеты исключений заключают в себе записи из неправильно сформатированных или некомплектных данных; (С) Согласно одному аспекту возможны трудности при приеме данных, не заключающих в себе необязательные или нежелательные данные. В последнем сценарии для определения элементов данных, подлежащих отбрасыванию, используют фильтры кодеров; (D) Вставка, обновление или удаление данных из модулей 232 профилей и 230 каталога соответственно; и (Е) Обеспечение подробной регистрации действий при кодировании. В одном примере в процессе кодирования кодеры имеют полный доступ к данным уже заключенных в модулях 232 профилей и 230 каталога соответственно. Это позволяет кодерам проверить существующие данные перед импортированием новой позиции.

Согласно одному аспекту система профилей и рекомендаций обеспечивает определенные стандартные кодеры для общих форматов данных. Можно без труда разработать новые кодеры, реализующие новый или заказной формат данных. В одном примере кодеры могут быть записаны на языке Java. Это также позволяет потребителям или интеграторам написать новые кодеры с использованием надежного высокоэффективного стандартного языка, которым они хорошо владеют.

В одном примере портальный интерфейс API системы профилей и рекомендаций представляет собой систему на основе стандарта SOAP, которая предоставляет Web-сайтам поставщиков контента, Web-порталам или другим системам конечного пользователя доступ к профильной и каталожной информации системы профилей и рекомендаций. В одном примере портальный интерфейс API можно использовать для следующих задач: (А) Обеспечение целевых продвижений (например, банерная реклама и т.д.), определенных модулем 236 продвижения; (В) Распределение контента, доступного через портал, на основе информации, хранящейся в модуле 230 каталога (например, экранные заставки, мелодии для телефона и т.д.); (С) Обеспечение функциональных возможностей поиска в метаданных, хранящихся в модуле 230 каталога; (D) Обеспечение заказной информации на основе информации, хранящейся в модуле 232 профилей; и (Е) Обновление системы профилей и рекомендаций событиями, появившимися на портале (например, посещение портала абонентом, щелчок мышью по рекламе, покупка позиции контента и т.д.).

Очевидно, что некоторые варианты реализации настоящего изобретения будут применять его главным образом для центрального каталога, в сочетании с возможностью интеграции продвижений и портала. В этом сценарии упор может быть сделан на поддержании модуля 230 каталога путем его обеспечения полной и своевременной информацией, касающейся контента и услуг. Модули 236 и 234 продвижения и принятия решения соответственно могут быть использованы для увеличения поглощения насколько это возможно. В этом сценарии можно расширить портальную интеграцию, начиная с нормальных аспектов продвижения (банерная реклама и т.д.), до вариантов, где портал получает частично или полностью всю известную информацию об имеющемся контенте или услугах из модуля 230 каталога. Другой вариант реализации изобретения может быть сфокусирован на использовании настоящего описания для функции продвижения и доставки. Выбранное решение будет зависеть от требований потребителей и может со временем эволюционизировать.

Согласно одному или нескольким аспектам система профилей и рекомендаций по настоящему изобретению может быть развернута в общей базовой архитектуре, которая обеспечивает рабочие характеристики операторского класса, надежность и масштабируемость. Такая архитектура может также обеспечить согласованную точку интеграции для сетевой инфраструктуры доставки, CRM, биллинговой системы и других систем BSS. Вдобавок, указанная общая архитектура может поддерживать множество решений, сформированных исходя из различных функций с высоким уровнем модульности и конфигурируемости.

Согласно одному примеру система профилей и рекомендаций может быть развернута с использованием различных аппаратных средств, включая, но не только, аппаратные средства, работающие с операционными системами Solaris, HP-UX, Linux и Windows. Согласно одному аспекту система профилей и рекомендаций может быть разделена на три уровня, каждый из которых может быть развернут на общих или отдельных аппаратных средствах в зависимости от стандартов мобильного оператора и требований к рабочим характеристикам. В одном примере для хранения данных и управления хранением данных может быть использована база данных Oracle.

Согласно одному примеру архитектура системы профилей и рекомендаций может обеспечить очень высокий уровень эффективности, необходимый крупным мобильным операторам. Модуль 234 принятия решений обеспечивает создание большого объема рекомендаций в реальном времени исходя из расширенной базы данных профильной и каталожной информации. Модуль 236 продвижения может обеспечить крупномасштабные продвижения в онлайновом и исходящем режимах, а контентный модуль 1804 может обеспечить управление и доставку больших объемов контента.

В одном примере система профилей и рекомендаций может дополнительно обеспечить избыточное развертывание с гарантией отсутствия отказов. Таким путем может быть обеспечена высокая доступность всех прибыльных услуг. Система 101 профилей и рекомендаций также может обеспечить надежность и доступность операторского класса посредством использования: (А) Конфигурации с горячим резервом, где функция каждой программной компоненты может быть передана на резервный сервер; (В) Использования серверов с встроенными избыточными аппаратными компонентами; (С) Загрузки компенсаторов во всех интерфейсных точках; (D) Технологии базы данных Oracle 9i, обеспечивающей высокую производительность и доступность базы данных; и (Е) Непрерывного контроля и выдачи предупредительных сообщений по упрощенному протоколу простого сетевого управления (SNMP) и предупредительных сообщений по упрощенному протоколу электронной почты (SMTP), позволяющих обеспечить интеграцию с существующими платформами сетевого управления.

Система профилей и рекомендаций, кроме того, может обеспечить эффективные опции масштабируемости, удовлетворяющие текущим и прогнозируемым требованиям потребителя к эффективности при экономически эффективном и гибком использовании ресурсов обработки. В одном или нескольких примерах все компоненты архитектуры могут быть распараллелены и рассчитаны на максимальное использование множества CPU серверов. В зависимости от имеющихся ресурсов система согласно одному аспекту может быть сконфигурирована таким образом, что будет обеспечено полное управление указанными обрабатывающими элементами в виде потоков и соединений с базой данных. Вдобавок к обеспечению масштабируемости в хосте система профилей и рекомендаций может быть масштабирована применительно к нескольким узлам, причем добавление новых узлов обеспечивает практически пропорциональное повышение эффективности системы.

Вдобавок, согласно одному или нескольким аспектам система профилей и рекомендаций может обеспечить множество различных интерфейсов API, которые позволяют системе легко интегрироваться с другими приложениями. В одном примере, не являющемся ограничением, указанные интерфейсы API включают в себя протоколы XML/SOAP, RMI, JDBC и т.д. Также может быть обеспечено множество точек интеграции, которые позволяют вводить в последовательности операций обработки, выполняемой различными модулями, новую или существующую бизнес-логику.

Кроме того, согласно одному примеру система профилей и рекомендаций может обеспечить интуитивное администрирование на основе Web и обеспечение всех аспектов функционирования платформы и системной поточной обработки. Система, кроме того, может обеспечить базовое администрирование платформы, а также интерфейсы для администрирования каждого из модулей.

Вдобавок, система профилей и рекомендаций может обеспечить интеграцию по протоколу SNMP с системами управления, такими как HP Openview. Система может также обеспечить подробные регистрационные файлы для всех системных компонент, причем уровень регистрации можно конфигурировать для каждой компоненты. Согласно одному или нескольким аспектам уровень регистрации можно изменять в реальном времени.

Кроме того, система профилей и рекомендаций может поддерживать множество различных сетевых протоколов подключаемости (например, протокол одноранговых коротких сообщений (SMPP), распределение компьютерных интерфейсов по сообщениям (CIMD), универсальный компьютерный протокол (UCP), EAIF, MM7, MM1, протокол аутентификации по паролю (PAP) и беспроводной протокол (OTA). В одном примере платформа может одновременно быть соединена с неограниченным количеством точек сетевой доставки и выполнять сложную маршрутизацию контента.

Следует заметить, что система профилей и рекомендаций может быть сконфигурирована для поддержки доставки контента или услуги пользователям или абонентам не только одного, но и нескольких мобильных операторов или мобильного оператора с несколькими дочерними компаниями.

Вдобавок, система профилей и рекомендаций может обеспечить сетевое управление с помощью управления полосой частот с использованием пиковых объемов выходных данных поставщика контента и управление безопасностью путем поддержки управления доступом на всех внешних интерфейсах посредством использования SSL, VPN, проверки адресов источников и проверки паролей пользователей, когда это соответствует рассматриваемому протоколу.

Система профилей и рекомендаций может быть дополнительно использована для регулирования частоты поступления сообщений в систему из приложений и центров передачи сообщений. Вдобавок, она может быть использована для предоставления трафику конкретного приложения заданного приоритета.

Кроме того, согласно одному или нескольким аспектам система профилей и рекомендаций может обеспечить функцию создания отчетов, которая отвечает за фиксацию соответствующих системных данных для создания отчета или запросов на услуги для потребителей. Система может фиксировать, по существу, все детали трафика, необходимые для создания полного аудиторского следа. Множество различных отчетов может быть доступно через административный Web-сайт. Согласно одному аспекту типы доступных отчетов могут зависеть от принятого решения по разворачиванию системы. В одном примере по умолчанию различные компоненты могут сопровождаться множеством наиболее часто используемых встроенных отчетов различного вида. Однако система профилей и рекомендаций может создать дополнительные отчеты, удовлетворяющие требованиям конкретного потребителя. В одном примере может быть использовано встроенное средство создания отчетов. При таком подходе можно создать отчет, необходимый потребителю, с помощью усовершенствованного средства GUI и получить отчет, легко доступный с web-сайта профилей и рекомендаций. Из этого Web-сайта можно просмотреть сводную информацию (в текстовом или графическом виде) и загрузить подробную информацию в формате CSV. В одном примере создание отчетов может включать в себя инструментальную панель управления, которая включает в себя статистические данные интерфейса на основе Web об использовании всех услуг и продвижений, а также возможность выдачи предупредительных сообщений в случае возникновения предварительно установленных условий.

Создание отчетов может включать в себя также инструментальную панель, работающую в реальном времени, которая может обеспечить такую информацию, как текущее техническое состояние всех серверов, текущее состояние всех активных серверов, информация об изменении количества транзакций для каждой услуги, информация об изменении объема транзакций у поставщика контента, первые 10 текущих рекомендаций согласно типу абонента, реакция на каждую рекомендацию и т.д.

Согласно одному или нескольким аспектам система профилей и рекомендаций по настоящему изобретению может помочь мобильным операторам, отличающимся сложным сочетанием предоставляемых услуг и многообразной абонентской базы, активно продвигать потребление контента или услуг путем обеспечения унифицированного просмотра, усовершенствованного профилирования и разумных рекомендаций. Эти возможности могут помочь мобильным операторам преодолеть текущее ограничение при активной розничной продаже своего контента или услуг через канал мобильной связи (например, каким образом обеспечить перекрестное продвижение контентных услуг из множества неравноправных систем; каким образом организовать продажу услуг отдельным абонентам на основе их демографических характеристик, доступных средств и привычек; каким образом улучшить опыт пользователя путем сопоставления услуг, доступных устройству и абоненту, без потери возможности продажи; каким образом автоматизировать узконаправленные продвижения и т.д.).

Система профилей и рекомендаций по настоящему изобретению может преодолеть все вышеуказанные проблемы путем обеспечения сквозной среды розничной торговли для мобильных операторов, причем эта система, например: (А) Максимизирует возможности продаж, доступных мобильному оператору; (В) Автоматизирует продвижение контента и услуг с минимальными расходами на персонал; (С) Максимизирует существующие инвестиции в современные платформы мобильных операторов, предоставляющие контент и данные; усиливает все взаимосвязи, которые мобильный оператор имеет с поставщиками контента; (D) Повышает удержание и притягивает абонента; (Е) Увеличивает средний доход на одного пользователя (ARPU) благодаря активному стимулированию более высоких норм прибыли (например, по меньшей мере в 3 раза); и (F) Уменьшает сложность.

Специалистам в данной области техники очевидны видоизменения, модификации и другие варианты реализации того, что здесь было описано, не выходящие за рамки существа и объема формулы изобретения. Соответственно, изобретение определяется не предшествующим иллюстративным описанием, а существом и объемом нижеследующей формулы изобретения.

1. Способ создания рекомендаций для пользователя мобильного устройства, где мобильное устройство ассоциировано с поставщиком услуг, способ содержит этапы, на которых:
получают запрос на рекомендацию;
извлекают данные, ассоциированные с пользователем, и данные о контенте, доступном для мобильного устройства, от поставщика услуг;
создают множество рекомендаций на основе анализа извлеченных данных, причем рекомендации создают множеством различных методов рекомендаций; и
выбирают поднабор из созданного множества рекомендаций на основе фильтрующих ограничений.

2. Способ по п.1, дополнительно содержащий доставку созданных рекомендаций на пользовательский интерфейс, доступный пользователю.

3. Способ по п.2, в котором доставка выбранного поднабора рекомендаций дополнительно содержит доставку выбранного поднабора рекомендаций на портал, ассоциированный с поставщиком услуг.

4. Способ по п.3, дополнительно содержащий этапы, на которых:
обнаруживают взаимодействие пользователя с выбранной частью портала;
определяют фильтрующие ограничения как ассоциированные с аспектом выбранной части со множеством рекомендаций; и
избирательно отображают поднабор рекомендаций в ответ на обращение пользователя к различным частям портала.

5. Способ по п.2, в котором доставка созданных рекомендаций на пользовательский интерфейс, доступный пользователю, дополнительно содержит доставку рекомендаций на мобильное устройство.

6. Способ по п.5, в котором доставка на мобильное устройство осуществляется через толкающее сообщение протокола беспроводных приложений (WAP) на портал, ассоциированный с поставщиком услуг.

7. Способ по п.5, в котором доставка на мобильное устройство осуществляется через сообщение службы коротких сообщений (SMS).

8. Способ по п.5, в котором доставка на мобильное устройство осуществляется через сообщение службы мультимедийных сообщений (MMS), отображаемое на мобильном устройстве.

9. Способ по п.1, в котором создание множества рекомендаций дополнительно содержит этапы, на которых:
предоставляют извлеченные данные для каждого из различных методов рекомендаций для создания рекомендаций, каждую рекомендацию создают с ассоциированным с ней уровнем доверия; и
комбинируют рекомендации из каждого метода рекомендаций в порядке уровня доверия.

10. Способ по п.9, дополнительно содержащий этапы, на которых:
переупорядочивают рекомендации на основе взвешиваний, определенных пользователем; и
фильтруют переупорядоченные рекомендации.

11. Способ по п.10, дополнительно содержащий этапы, на которых:
принимают запрос на рекомендации, заключающий в себе конкретное ограничение; и
фильтруют переупорядоченные рекомендации путем фильтрации согласно конкретному ограничению.

12. Способ по п.10, в котором фильтрация переупорядоченных рекомендаций дополнительно содержит удаление рекомендации, которой ранее воспользовался пользователь, или уже представленной пользователю определенное количество раз.

13. Способ по п.10, в котором фильтрация переупорядоченных рекомендаций дополнительно содержит удаление рекомендации, несовместимой с мобильным устройством.

14. Способ по п.9, дополнительно содержащий нормализацию доверительных уровней, полученных от различных методов рекомендаций.

15. Способ по п.1, в котором множество методов рекомендаций выбирают из группы, состоящей из рекомендателя ассоциирования, рекомендателя сравнения, рекомендателя группирования, рекомендателя отслеживания или сетевого рекомендателя.

16. Способ по п.15, в котором сетевой рекомендатель дополнительно содержит:
выбор множества людей из списка пользователей в локальной сети целевого пользователя, причем это множество людей находится в рамках конкретного количества степеней разобщения;
определение популярного контента, которым ранее воспользовалось выбранное множество людей; и
создание рекомендаций на основе определенного поставщика услуг и популярного контента.

17. Способ по п.16, в котором выбор множества людей дополнительно содержит идентификацию пользователей из локальной сети целевого пользователя, которые ассоциированы с высокими значениями взвешивания.

18. Способ по п.17, в котором значения взвешивания присваивают путем:
извлечения данных межперсональной мобильной связи для пользователя от поставщика услуг;
фильтрации данных межперсональной связи для удаления нежелательных данных связи и
присвоения значения взвешивания каждому из отфильтрованных межперсональных сводных сеансов связи, причем присвоенное значение пропорционально величине и типу активности межперсональной связи.

19. Способ по п.18, в котором фильтрация данных межперсональной связи дополнительно содержит:
удаление данных связи от нежелательных источников.

20. Способ по п.19, в котором нежелательные источники идентифицируют по соответствующим уникальным телефонным номерам.

21. Способ по п.18, в котором фильтрация межперсональной связи дополнительно содержит удаление данных связи, нежелательных с точки зрения типа или длительности связи.

22. Способ по п.18, в котором фильтрация дополнительно содержит удаление данных сеансов связи, нежелательных с точки зрения времени суток или дня связи.

23. Способ по п.18, в котором данные межперсональной мобильной связи дополнительно содержат одно или более из: голосовые вызовы, сообщения службы коротких сообщений (SMS), сообщения службы мультимедийных сообщений (MMS) или способ мобильной связи.

24. Способ по п.15, в котором рекомендатель ассоциирования дополнительно содержит:
формирование правил ассоциирования из данных о поведении пользователя, извлеченных от поставщика услуг; и
создание рекомендаций на основе сформированных правил ассоциирования.

25. Способ по п.15, в котором рекомендатель сравнения дополнительно содержит:
формирование ссылок между похожими контентными данными, доступными пользователю, с применением контентных метаданных; и
создание рекомендаций на основе сформированных ссылок.

26. Способ по п.15, в котором рекомендатель отслеживания содержит:
определение истории активности пользователей для того, чтобы сформировать ранжирование всех контентных данных, причем контентные данные ранжируют по популярности; и
создание рекомендаций на основе ранжирования.

27. Способ по п.26, в котором активность пользователей содержит покупки контента, рейтинги или другие проявления интереса пользователя за конфигурируемый период времени.

28. Способ по п.1, в котором данные, ассоциированные с пользователем, содержат выбор одного или более из: данные вызова, день рождения, пол, предшествующие покупки, проявления интереса, проявления отсутствия интереса, образец трат, тип мобильного устройства, текущее географическое месторасположение, частота вызовов или другие пользовательские метаданные.

29. Способ по п.28, дополнительно содержащий поддержание ассоциированных с пользователем данных вплоть до даты создания рекомендации.

30. Способ по п.1, в котором запрос на рекомендацию получают из портала, ассоциированного с поставщиком услуг.

31. Способ по п.1, в котором рекомендации создают в реальном времени с тем, чтобы не приуменьшать опыт пользователя.

32. Способ по п.1, в котором рекомендации создают за период времени, меньший 200 мс.

33. Способ создания продвижений для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг, способ содержит этапы, на которых:
извлекают список продвижений от поставщика услуг;
извлекают данные, ассоциированные с пользователем, и данные о контенте, доступном пользователю, от поставщика услуг;
создают список рекомендаций для пользователя путем анализа извлеченных данных, причем рекомендации создают посредством множества индивидуальных методов рекомендаций; и
выбирают для доставки поднабор извлеченных продвижений, поднабор извлеченных продвижений включает в себя продвижения, которые подобны рекомендациям в списке рекомендаций и которыми пользователь уже не воспользовался.

34. Считываемый компьютером носитель данных, содержащий
по меньшей мере одну команду, заставляющую компьютер получать запрос на рекомендацию;
по меньшей мере одну команду, заставляющую компьютер извлекать данные, ассоциированные с пользователем, и данные о контенте, доступном пользователю, от поставщика услуг;
по меньшей мере одну команду, заставляющую компьютер создавать список рекомендаций на основе анализа извлеченных данных, причем рекомендации создают посредством множества различных методов рекомендаций.

35. Система для создания рекомендаций для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг, причем система содержит:
средство для получения запроса на рекомендацию;
средство для извлечения данных, ассоциированных с пользователем, и данных о контенте, доступном пользователю, от поставщика услуг;
средство для создания списка рекомендаций на основе анализа извлеченных данных, причем рекомендации создают посредством множества различных методов рекомендаций.

36. Система для создания рекомендаций для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг, система содержит:
модуль профилей для сохранения и обработки данных, ассоциированных с пользователем;
модуль каталога для сохранения и обработки контента, доступного пользователю;
модуль принятия решения, находящийся на связи с модулем профилей и модулем каталога, модуль принятия решения используют для создания списка рекомендаций для пользователя путем анализа данных, извлеченных из модулей профилей и каталога, причем рекомендации создаются множеством индивидуальных модулей-рекомендателей.

37. Система по п.36, в которой модуль принятия решения включает в себя рекомендатель ассоциирования, рекомендатель сравнения, рекомендатель группирования, рекомендатель отслеживания и сетевой рекомендатель.

38. Система по п.37, в которой сетевой рекомендатель содержит: модуль записи данных вызова, модуль формирователя сети, модуль очистки сети, модуль взвешивания, модуль идентификатора взаимосвязи и модуль сетевого рекомендателя.

39. Система по п.36, в которой модуль профилей содержит: модуль базы данных профилей, модуль управления профилями, модуль группирования профилей и модуль поглощения профилей.

40. Система по п.36, в которой модуль каталога содержит: модуль группирования контента, модуль поиска, модуль управления контентом, модуль базы данных контента и модуль поглощения контента.

41. Система для создания рекомендаций для пользователя мобильного устройства, пользователь ассоциирован с поставщиком услуг, система содержит:
модуль профилей для сохранения и обработки данных, ассоциированных с пользователем;
модуль каталога для сохранения и обработки контента, доступного пользователю:
модуль принятия решения, находящийся на связи с модулем профилей и модулем каталога, модуль принятия решения используют для создания списка рекомендаций для пользователя путем анализа данных, извлеченных из модулей профилей и каталога, причем рекомендации создаются множеством индивидуальных модулей-рекомендателей, и
модуль продвижения для сравнения рекомендаций с базой данных продвижений поставщика услуг и для создания списка продвижений на основе сравнения.

42. Система по п.41, в которой модуль продвижения дополнительно содержит: модуль управления продвижением, модуль обратной связи продвижения, модуль образования продвижения, модуль извлечения продвижения и модуль доставки продвижения.

43. Способ для создания рекомендаций для пользователя мобильного устройства, содержащий:
обращение к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств;
создание рекомендаций для контента, предлагаемых на основе атрибутивных данных, и создание рекомендаций для контента, предлагаемых на основе данных о поведении;
выбор поднабора рекомендаций путем применения фильтрующего ограничения; и
передачу поднабора рекомендаций по меньшей мере поднабору из множества мобильных устройств.

44. Способ по п.43, дополнительно содержащий прием запроса на рекомендуемых пользователей для выбранной позиции контента.

45. Способ по п.43, дополнительно содержащий применение фильтрующего ограничения путем обращения к исключающему ограничению.

46. Способ по п.45, дополнительно содержащий обращение к исключающему ограничению путем
отслеживания количества предложений выбранной позиции контента выбранному пользователю; и
исключение дополнительных предложений выбранной позиции контента выбранному пользователю при достижении порога.

47. Способ по п.45, дополнительно содержащий обращение к исключающему ограничению путем приема запрета категорий для выбранного пользователя.

48. Способ по п.45, дополнительно содержащий обращение к исключающему ограничению путем определения того, что выбранная позиция контента ранее была выбрана и принята выбранным мобильным устройством выбранного пользователя.

49. Способ по п.48, дополнительно содержащий идентификацию позиции контента для рекомендации, которая ассоциирована с ранее выбранной позицией контента.

50. Способ по п.45, дополнительно содержащий обращение к исключающему ограничению путем определения совместимости выбранного беспроводного устройства с выбранной позицией контента.

51. Способ по п.43, дополнительно содержащий выбор поднабора рекомендаций путем применения фильтрующего ограничения путем определения уровня доверия множества рекомендаций выбранных позиций контента и применения весового коэффициента согласно уровню доверия.

52. Способ по п.51, дополнительно содержащий сортировку множества рекомендаций согласно уровню доверия.

53. Способ по п.43, дополнительно содержащий немедленное обновление данных о поведении для выбранного пользователя беспроводного устройства на основе взаимодействия пользователя с представленными предложениями по рекомендациям.

54. Способ по п.43, дополнительно содержащий ассоциирование выбранного пользователя беспроводного устройства с группой пользователей и выбор рекомендаций на основе групповой ассоциации.

55. Способ по п.54, дополнительно содержащий обращение к атрибутивным данным и данным о поведении, состоящим из данных вызова, дня рождения, пола, предшествующих покупок, проявлений интереса, проявлений отсутствия интереса, образца трат, типа мобильного устройства, текущего географического месторасположения, частоты вызовов или других пользовательских метаданных.

56. По меньшей мере один процессор для создания рекомендаций для пользователя мобильного устройства, содержащий:
первый модуль для обращения к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств;
второй модуль для создания рекомендаций для контента, предлагаемых на основе атрибутивных данных, и создания рекомендаций для контента, предлагаемых на основе данных о поведении;
третий модуль для выбора поднабора рекомендаций путем применения фильтрующего ограничения; и
четвертый модуль для передачи поднабора рекомендаций по меньшей мере поднабору из множества мобильных устройств.

57. Считываемый компьютером носитель данных, содержащий сохраненные на нем команды, которые при исполнении создают рекомендации для пользователя мобильного устройства, команды содержат:
по меньшей мере одну команду, заставляющую компьютер обращаться к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств;
по меньшей мере одну команду, заставляющую компьютер создавать рекомендации для контента, предлагаемые на основе атрибутивных данных, и создавать рекомендации для контента, предлагаемые на основе данных о поведении;
по меньшей мере одну команду, заставляющую компьютер выбирать поднабор рекомендаций путем применения фильтрующего ограничения; и
по меньшей мере одну команду, заставляющую компьютер передавать поднабор рекомендаций по меньшей мере поднабору из множества мобильных устройств.

58. Аппарат для создания рекомендаций для пользователя мобильного устройства, содержащий:
средство для обращения к атрибутивным данным и данным о поведении для множества пользователей соответствующего множества мобильных устройств;
средство для создания рекомендаций для контента, предлагаемых на основе атрибутивных данных, и создания рекомендаций для контента, предлагаемых на основе данных о поведении;
средство для выбора поднабора рекомендаций путем применения фильтрующего ограничения; и
средство для передачи поднабора рекомендаций по меньшей мере поднабору из множества мобильных устройств.

59. Аппарат для создания рекомендаций для пользователя мобильного устройства, содержащий:
компоненту сохранения профиля, заключающую в себе атрибутивные данные и данные о поведении для множества пользователей соответствующего множества мобильных устройств;
систему профилей и рекомендаций для создания рекомендаций для контента, предлагаемых на основе атрибутивных данных, для создания рекомендаций для контента, предлагаемых на основе данных о поведении, и для выбора поднабора рекомендаций путем применения фильтрующего ограничения; и
модуль сетевой связи для передачи поднабора рекомендаций по меньшей мере поднабору из множества мобильных устройств.

60. Аппарат по п.59, дополнительно содержащий модуль сетевой связи для приема запроса на рекомендуемых пользователей для выбранной позиции контента.

61. Аппарат по п.60, дополнительно содержащий систему профилей и рекомендаций для применения фильтрующего ограничения путем обращения к исключающему ограничению.

62. Аппарат по п.61, дополнительно содержащий систему профилей и рекомендаций для обращения к исключающему ограничению путем
отслеживания количества предложений выбранной позиции контента выбранному пользователю; и
исключение дополнительных предложений выбранной позиции контента выбранному пользователю при достижении порога.

63. Аппарат по п.61, дополнительно содержащий систему профилей и рекомендаций для обращения к исключающему ограничению путем приема запрета категорий для выбранного пользователя.

64. Аппарат по п.61, дополнительно содержащий систему профилей и рекомендаций для обращения к исключающему ограничению путем определения того, что выбранная позиция контента ранее была выбрана и принята выбранным мобильным устройством выбранного пользователя.

65. Аппарат по п.64, дополнительно содержащий систему профилей и рекомендаций для идентификации позиции контента для рекомендации, которая ассоциирована с ранее выбранной позицией контента.

66. Аппарат по п.61, дополнительно содержащий систему профилей и рекомендаций для обращения к исключающему ограничению путем определения совместимости выбранного беспроводного устройства с выбранной позицией контента.

67. Аппарат по п.59, дополнительно содержащий систему профилей и рекомендаций для выбора поднабора рекомендаций путем применения фильтрующего ограничения путем определения уровня доверия множества рекомендаций выбранных позиций контента и применения весового коэффициента согласно уровню доверия.

68. Аппарат по п.67, дополнительно содержащий систему профилей и рекомендаций для сортировки множества рекомендаций согласно весовому коэффициенту.

69. Аппарат по п.59, дополнительно содержащий систему профилей и рекомендаций для немедленного обновления данных о поведении для выбранного пользователя беспроводного устройства на основе взаимодействия пользователя с представленными предложениями по рекомендациям.

70. Аппарат по п.59, дополнительно содержащий систему профилей и рекомендаций для ассоциирования выбранного пользователя беспроводного устройства с группой пользователей и выбора рекомендаций на основе групповой ассоциации.

71. Аппарат по п.59, дополнительно содержащий систему профилей и рекомендаций для обращения к атрибутивным данным и данным о поведении, состоящим из данных вызова, дня рождения, пола, предшествующих покупок, проявлений интереса, проявлений отсутствия интереса, образца трат, типа мобильного устройства, текущего географического месторасположения, частоты вызовов или других пользовательских метаданных.