Патент на изобретение №2311741

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

Настоящее изобретение относится к мобильным телефонным сетям, и в частности к обработке вызовов или других событий или сеансов абонентов в таких сетях. Такие вызовы, события и сеансы могут включать в себя, например, посылку и прием сообщений (SMS, СКС (служба коротких сообщений)), события общих услуг пакетной радиосвязи (GPRS, ОУПРС), сеансы Интернет и Интранет и предоставление мультимедийных услуг. В дальнейшем понятие “вызов” будет использоваться таким образом, что относится к любому или ко всем таким вызовам, событиям или сеансам. Обработка вызова является операцией или операциями, выполняемыми сетью и службами, поддерживаемыми в сети, в ответ на инициализацию вызова пользователем. Обработку вызова можно рассматривать как включающую в себя либо обработку вызова, либо обработку услуги, или и того и другого, причем обработка вызова является операциями, связанными с реализацией вызова в сети, а обработка услуги является операциями, связанными с доставкой услуги как части вызова.

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

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

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

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

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

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

Первый аспект изобретения

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

Затем функция брокера может выполнить любое или все из следующих действий:

1. Она определяет услуги, применяемые к вызову, и/или операции обработки вызова, которые требует вызов.

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

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

4. Она выполняет любые преобразования протокола, необходимые для того, чтобы гарантировать, что каждая платформа, необходимая для обработки вызова, может правильно работать.

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

На практике, по меньшей мере, действия 1 и 2 будут необходимы для любого вызова, и функция брокера должна, по меньшей мере, гарантировать действие 4, чтобы платформы могли правильно обрабатывать вызов. Действия 3 и 5 могут быть необходимы в зависимости от вызова, но не всегда являются существенными.

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

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

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

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

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

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

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

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

Второй аспект изобретения

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

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

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

Следует отметить, что несмотря на то, что этот второй аспект настоящего изобретения разработан для обработки вызовов МС, второй аспект не ограничен обработкой таких вызовов. Принципы второго аспекта, обсужденные выше, могут применяться к другим типам вызовов, таким как обработка сообщений электронной почты, другие текстовые сообщения или сигналы и адреса “всемирной паутины” (WWW). Однако в дальнейшем обсуждении ради простоты терминологии при обсуждении этого второго аспекта ссылка впоследствии будет сделана только на вызовы МС.

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

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

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

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

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

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

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

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

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

фиг. 6 – диаграмма, иллюстрирующая вариант осуществления первого аспекта изобретения;

фиг. 7 – диаграмма, иллюстрирующая дополнительный вариант осуществления второго аспекта изобретения;

фиг. 8 – блок-схема, иллюстрирующая обработку в варианте осуществления фиг. 7.

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

Первый вариант осуществления

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

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

Фиг. 1 идентифицирует пять платформ сетей (или обработки услуг):

PCF, ФУПО 10, являющаяся функцией управления предварительной оплатой.

SLR, РМС 12, являющаяся регистром местонахождения (регистр местонахождения службы), соответствующим регистру, описанному в WO/GB95/02352, который содержит информацию, относящуюся к каждому номеру телефона в соответствующем одном из множества домашних (опорных) регистров местонахождения (HLR, ДРМ) сети, которые не изображены на фиг. 1.

HCF, ФУД 13, являющаяся функцией управления домашним (опорным) регистром местонахождения.

SCF, ФУУ (функция управления услугами) 14, указывающая общую платформу услуг, предназначенную для выполнения других услуг, связанных с вызовом. Каждая из ФУПО 10, РМС 12 и ФУД 13 может рассматриваться как специфический тип ФУУ.

Платформа обработки вызова, изображенная на фиг. 1, включает в себя:

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

SGSN, ОУПО 21, являющийся обслуживающим узлом поддержки GPRS (ОУПРС).

SMS, ЦКС 23, являющийся центром коротких сообщений.

VPS, СОР 24, являющаяся системой обработки речи для приема речевых сообщений.

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

Обслуживающий узел 26, являющийся элементом (устройством и/или функцией) управления подвижной службой, функцией деталей обслуживания и специализированной функцией ресурса.

Сервер 27 WAP (протокол мобильной интерактивной связи с Интернет), являющийся Web-сервером, который может обслуживать Web-страницы в формате, который может быть доставлен в мобильный телефон.

В соответствии с первым аспектом настоящего изобретения, все эти платформы связаны с помощью функции 30 брокера, которая управляет активностью платформ с 10 по 14 и с 20 по 27, в зависимости от обработки вызова или услуг. Функция брокера связана с функциями сети с 10 по 14 и с платформами обработки вызова с 20 по 27, а также с базой данных 31. Эта база данных может быть распределенной базой данных, которая описана в W099/35867.

Далее фиг. 2 иллюстрирует основные операции, выполняемые функцией 30 брокера фиг. 1. Когда вызов включает в себя одну из платформ с 10 по 14 и/или с 20 по 27, функция 30 брокера устанавливает операцию 40 посредничества, которая взаимодействует с платформами, в которых принят вызов, а также может взаимодействовать с другими платформами, в зависимости от характера вызова.

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

В зависимости от характера услуги или услуг, требуемых вызовом, которые идентифицированы с помощью операции 41, функция 30 брокера затем должна установить, может ли платформа, которая приняла вызов, обработать вызов, и какая услуга или услуги затребованы этим вызовом. Следовательно, она выполняет операцию функциональной возможности, которая связывается с функцией коммутации услуг (SSF, ФКУ) подходящей платформы с 20 по 27, для определения функциональных возможностей этой ФКУ. Если платформа с 20 по 27 не может обеспечить подходящие операции, функция 30 брокера затем может установить линии связи с другими платформами, которые могут выполнить эти услуги, и может работать таким образом, чтобы завершить эти функции других платформ. Функция коммутации услуг (ФКУ) является функцией, которая принимает указания из платформы обработки вызова, какие точки в вызове (PIC, ТВВ) достигнуты. Затем ФКУ запрашивает инструкции из функции управления услугами (ФУУ). ФУУ реализует логическую функцию услуг и дает ФКУ инструкции для продолжения, отклонения и/или выполнения других операций, таких как модифицирование инструкции вызова, сообщения ячейки ветви и измерение моментов времени вызовов. ФКУ воспринимает эти инструкции и выполняет этапы посредством заданного конечного автомата, соответствующим образом передавая инструкции и информацию обратно в программное обеспечение обработки вызовов и ФУУ. ФКУ находится в физическом узле, называемом пунктом коммутации услуг (SSP, ПКУ), а ФУУ находится в физическом узле, называемом пунктом управления услугами (SCP, ПУУ).

Следовательно, если вызов требует множество услуг, тогда функция 30 брокера должна выполнить операцию 43 корреляции для коррелирования информации, требуемой любой из платформ с 10 по 14 и с 20 по 27, чтобы обеспечить соответствующие операции (обработку вызова, обработку услуги). Обычно корреляция будет включать в себя множество платформ, и функция брокера получает из базы данных 31 одно множество данных для вызова, которое может быть использовано функцией 30 брокера и соответствующими платформами с 10 по 14 и с 20 по 27 для выполнения необходимых операций. Следовательно, функция брокера может выполнять корреляцию для согласования функциональных возможностей, обычно включающую в себя платформы с 20 по 27, и корреляцию множества услуг, обычно включающую в себя платформы с 10 по 14. Когда такие платформы включены, функция 30 брокера должна выполнить операцию 44 установления последовательности, которая определяет последовательность, в которой должны быть обеспечены множество операций, и следовательно, последовательность, в которой платформы с 10 по 14 и с 20 по 27 должны обеспечить эти операции. Эта операция 44 установления последовательности также может требоваться, даже когда не требуется множество платформ, и следовательно, операцию 43 корреляции не выполняют, когда множество услуг должны быть предоставлены в одной платформе.

Теперь будут описаны три примера работы сети или функций, проиллюстрированных на фиг. 1, со ссылкой на фиг. 3 по фиг. 5. На этих фигурах номера в кружках указывают стадии в обработке вызова.

Пример 1 первого варианта осуществления

В этом примере предполагается, что вызов требует множество услуг.

Входящий вызов принимают в ПКУ 40 платформы, в котором вызов принят, и это запускает сигнал в функцию 30 брокера, и функция 30 брокера может осуществить доступ к базе данных 31, чтобы установить выполняемые операции. Этот сигнал запуска содержит данные, указывающие операции, выполняемые в ответ на вызов. В примере фиг. 3 предполагается, что операции требуют доступа к ПУУ 41, 42. Однако перед передачей сигналов в эти ПУУ 41, 42 функция 30 брокера передает сигналы в базу данных 31, чтобы собрать данные, необходимые для всех услуг, которые должны быть выполнены платформами обработки вызова и/или услуги. Затем функция 30 брокера последовательно опрашивает ПУУ 41, 42, чтобы запустить каждый из этих ПУУ 41, 42 для генерирования соответствующей информации, которая объединяется с помощью функции 30 брокера, а затем ответ передают в ПУУ 40 для обеспечения возможности продолжения вызова.

В некоторых случаях действия, выполняемые соответствующими ПУУ 41, 42, будут независимыми. Следовательно, например, один из ПУУ 41, 42 может просто преобразовывать номер вызова в другой номер, и в таких случаях функция 30 брокера может просто собирать множество таких операций. Однако в некоторых случаях может требоваться, чтобы один из ПУУ 41, 42 был занят на протяжении всего вызова. Например, если один из ПУУ связан с ФУУ 14, занятой в вызове предварительной оплаты, тогда может требоваться, чтобы функция 30 брокера создавала агрегированный результат для ПКУ 40.

Пример 2 первого варианта осуществления

Фиг. 4 изображает пример, в котором ПКУ, который сначала принимает вызов, не может выполнить все необходимые операции.

Следовательно, если вызов принимают в первом ПУУ 50 платформы, который не имеет достаточных функциональных возможностей, чтобы выполнить необходимые операции, ПКУ 50 передает сигнал в функцию 30 брокера. Как в примере 1, функция 30 брокера осуществляет доступ в базу данных 31, чтобы получить все данные, необходимые для обработки вызова, а затем назначает временную идентификацию корреляции вызову, эту идентификацию корреляции передают обратно в ПКУ 50. Эта идентификация корреляции заставляет ПКУ 50 передать вызов во второй ПКУ 51 платформы, который может обеспечить операции, требуемые вызовом, а прием вызова с помощью ПКУ 51 генерирует сигнал запуска в функцию 30 брокера, которая осуществляет доступ к подходящему ПУУ 52, чтобы получить соответствующую ответную информацию, которую передают в ПКУ 51, который затем может дать возможность вызову продолжаться в платформе, которая его обрабатывает.

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

Заметим, что в примере 2 допускается, что вызов требует доступа только к одному ПУУ 52. В некоторых случаях будет необходимо опрашивать множество ПУУ, как в примере 1, и такой опрос может происходить таким же образом, как в примере 1, когда вызов передан в ПКУ 2, хотя, заметим, что в это время функция 30 брокера уже осуществит доступ к базе данных 31.

Пример 3 первого варианта осуществления

Третий пример связан со случаем, когда обработка вызова включает в себя разные протоколы. Ссылаясь на фиг. 5, вызов принимают в ПКУ 60, который генерирует сигнал в функцию 30 брокера, указывающий необходимые услуги. В этом примере предполагается, что ПКУ 60 и, следовательно, сигналы, которые он создает, работают в первом протоколе А. Функция 30 брокера может осуществлять доступ к базе данных 31, как прежде, чтобы получить данные для обработки вызова, если сигнал запуска из сети сам не содержит достаточно информации, и опрашивает подходящий ПУУ 61, чтобы получить информацию для обработки вызова. Если ПУУ 61 и, следовательно, сигналы, которые он должен принимать и передавать, работают в соответствии со вторым протоколом В, тогда функция 30 брокера осуществляет посредничество между этими разными протоколами, как проиллюстрировано на фиг. 5. Если функция 30 брокера собрала всю информацию, чтобы обработать вызов, из базы данных 31 и ПУУ 61, она передает ответ в ПКУ 60 в протоколе А, подходящем для этого ПКУ 60.

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

Второй вариант осуществления

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

Ссылаясь на фиг. 6, вызов, являющийся мультимедийным сообщением (МС), создан, например, в аппарате 100 мобильного телефона абонента, из которого сообщение (мультимедийную информацию) передают в центр 110 обслуживания мультимедийных сообщений (MMSC, ЦОМС). Инициирующий аппарат 100 посылает вызов МС через ОУПРС 140 и шлюз 118 WAP в ЦОМС 110. ЦОМС действует как временное хранилище для вызова ЦОМС и для этой цели может иметь хранилище 112 сообщений, связанное с ним.

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

Фиг. 6 иллюстрирует вариант осуществления, в котором вызов МС предназначен для адресата в самой инициирующей сети. Следовательно, когда брокер 114 услуг определил обработку, необходимую для вызова, обработку вызова возвращают в ЦОМС 110. В частности, ЦОМС может послать сообщение WAP в прокси-шлюз 115 принудительной рассылки, который передает его в SMSC, ЦСКС (центр службы коротких сообщений) 116 и в соответствующий аппарат 117, который может отобразить сообщение вызова МС. Это проиллюстрировано с помощью стрелок 5 и 6 на фиг. 6. Прокси-шлюз 115 принудительной рассылки действует таким образом, чтобы форматировать и передавать сигналы, исходящие из ЦОМС 110, для дальнейшей доставки в структуру службы коротких сообщений (СКС), образующую ЦСКС 116 для обеспечения возможности осуществления соответствующей передачи.

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

Как проиллюстрировано на фиг. 1, брокер услуг может быть соединен с устройством 120 функции данных услуг (SDF, ФДУ), как проиллюстрировано более подробно в заявке PCT WO 99/35867, и устройством 121 регистра (устройством РМС), как проиллюстрировано более подробно в заявке PCT WO 96/11557. Таким образом, устройство 120 ФДУ может запоминать данные абонента МС, которые будут требоваться ЦОМС 110. При выполнении своих функций устройство 114 брокера услуг, следовательно, может получать информацию из устройства 120 ФДУ для определения, как должен быть обработан вызов. Подобным образом устройство 114 брокера услуг может извлекать соответствующую информацию из устройства 121 РМС для получения номера MSISDN, ЦСИУПС (цифровая сеть с интегрированными услугами подвижной станции) инициирующей стороны (отправителя) и стороны адресата.

Тогда имеются две возможности. Первая состоит в том, что инициирующий аппарат 100 имеет устройства оплаты отправления, причем поставщик услуг (провайдер) сети работает в ЦОМС 110. В этом случае подходящие устройства выписывания счетов могут быть помещены в устройство, состоящее из последовательности элементов. Однако, если инициирующий аппарат 100 работает в устройстве предварительной оплаты, тогда должна быть сделана проверка, имеется ли соответствующий кредит, перед тем как будет передан вызов МС. Для этой цели устройство 110 брокера услуг может послать сигнал в функцию управления предварительной оплаты (ФУПО) 12, причем этот сигнал указывает сторону отправителя и указание типа и объема сообщения вызова МС. Функция 122 управления предварительной оплатой затем может послать соответствующие сигналы в операции выписывания счетов сети, схематически проиллюстрированные в 123. Эти операции выписывания счетов включают в себя устройство 124 системы посредничества сети (NMS, СПС), которое генерирует сигналы для обеспечения возможности выполнения функций 125, 126 оценки и выписывания счетов. Фиг. 6 также иллюстрирует, что устройство 124 СПС принимает сигналы запуска из самого ЦОМС 110.

ЦОМС 110 может содержать устройство интерфейса базы данных абонента (не изображено на фиг. 6), которое передает запросы, сгенерированные с помощью ЦОМС 110, в устройство 114 брокера услуг через промежуточный интерфейс 131. Таким образом, устройство 114 брокера услуг может управлять дальнейшей обработкой вызова с помощью ЦОМС 110.

Теперь заявитель предполагает, что вызов МС сгенерирован с помощью аппарата 100 на фиг. 6, но аппарат 117, являясь терминалом адресата, не поддерживает мультимедийные функции. В этом случае ЦОМС 110 направляет вызов в шлюз 141 используемого аппарата, который запоминает вызов МС. Кроме того, он генерирует сообщение в виде СКС в ЦСКС 116, где оно может быть передано в аппарат 117 для передачи сигнала пользователю этого аппарата 117 о том, что мультимедийное сообщение запомнено. Следовательно, сигналы в аппарат 117 могут быть стандартными сообщениями. Пользователь, например, аппарата 117 затем может использовать подходящий компьютер 144 для соединения через интерсеть 115 со шлюзом 141 используемого аппарата, чтобы дать возможность считать мультимедийное сообщение. Следовательно, шлюз 141 используемого аппарата может содержать web-серверы для обеспечения соответствующего доступа. Кроме того, возможна посылка мультимедийного сообщения в адрес электронной почты. Это выполняют с помощью агента 146 передачи почты, который принимает вызов из ЦОМС 110 и преобразует его в сообщение электронной почты, которое посылают через интерсеть 145 в подходящие компьютеры 144, 147.

Возможны многие модификации этого варианта осуществления. Например, фиг. 6 предполагает, что инициирующий аппарат 100 и аппарат адресата 117 являются потребителями одной и той же сети и оба находятся в своей собственной сети. Однако возможно, что они являются потребителями разных сетей, в этом случае вызов должен быть передан из ЦОМС 110 инициирующей сети в эквивалентный ЦОМС сети адресата. Тогда особенно важно действие брокера 114 услуг.

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

Может быть, что сеть, которой принадлежит номер адресата, не имеет соглашения взаимного соединения с оператором ЦОМС 110, в этом случае брокер 114 услуг может решить послать сообщение в шлюз 141 используемого аппарата.

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

Когда выполняют роуминг аппарата 117 адресата из его собственной сети, ЦОМС пошлет сообщение (например, сообщение СКС) в аппарат 117 адресата, чтобы сообщить пользователю о контактировании с ЦОМС 110 собственной сети для приема сообщения МС из собственной сети.

Когда выполняют роуминг инициирующего аппарата 110 из его собственной сети, сообщение МС направляют в ЦОМС 110 собственной сети, который затем обрабатывает его способами, описанными со ссылкой на фиг. 6. Такие операции являются надежными в несобственной сети (в которую осуществлен роуминг), поддерживающей соответствующие сетевые функциональные возможности, чтобы дать возможность посылать и принимать сообщения МС.

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

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

Третий вариант осуществления

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

Во втором аспекте изобретения вызов преобразуют в заданный общий протокол, сигналы запуска событий создают в этом общем протоколе, эти сигналы запуска событий используют для инициализации обработки вызова. Для того чтобы выполнить это, вызов МС преобразуют в стандартный протокол, такой как простой протокол пересылки электронной почты (SMTP, ПППЭП) и передают прокси-агенту 113 ПППЭП. Этот прокси-агент 113 ПППЭП запускает обработку вызова.

В этом варианте осуществления прокси-агент 113 ПППЭП соединен с брокером 144 услуг, который выполняет функцию брокера первого аспекта изобретения, обсужденного выше со ссылкой на фиг. 1 по фиг. 5 и фиг. 6. Брокер услуг 114 определяет обработку, необходимую для всех, на основании сигнала запуска из прокси-агента 113 ПППЭП. Так как прокси агент 113 ПППЭП работает в известном не патентованном протоколе, относительно просто разработать его таким образом, чтобы генерировать такие сигналы запуска, независимо от протокола ЦОМС 110.

Прокси-агент 113 ПППЭП извлекает из данных в сообщении информацию, которая идентифицирует размер сообщения, а также может извлечь из данных в сообщении информацию, которая идентифицирует класс или тип среды передачи данных, содержащийся в сообщении. Затем соответствующий сигнал посылают в устройство 114 брокера услуг. Кроме того, прокси-агент 113 ПППЭП посылает ответ в ЦОМС 110 через интерфейс ММ4, чтобы преобразовать адреса отправителя и получателя, как проинструктировано устройством 114 брокера услуг (заметим, что сообщение может быть послано обратно в тот же самый ЦОМС 110 (закольцовывание), в другой ЦОМС в той же сети или в другой ЦОМС в другой сети.

Следовательно, в описанном выше варианте осуществления сигналы запуска событий генерируют в прокси-агенте 113 ПППЭП в протоколе, таком как ПППЭП, который не является тем же самым, что и протокол, в котором вызов МС первоначально создают и принимают с помощью ЦОМС 110.

Прокси-агент 113 ПППЭП может быть стандартным сервером электронной почты, который сконфигурирован таким образом, чтобы временно запоминать сообщения МС для генерирования сигналов запуска. Эти сигналы запуска могут быть в виде расширенного запроса облегченного протокола доступа к каталогам (LDAP, ОПДК), который содержит соответствующую информацию, такую как источник и назначение вызова, тип сообщения, размер сообщения и т.д. Эту информацию передают брокеру 114 услуг, который затем определяет, как должен быть обработан вызов.

На фиг. 7 интерфейс 131 соединен с ЦОМС 110 через устройство 130 базы данных абонента, которое, как упомянуто со ссылкой на фиг. 6, передает запросы, сгенерированные с помощью ЦОМС 110 в устройство 114 брокера услуг через интерфейс 131.

Фиг. 7 также иллюстрирует ситуацию, когда вызов МС посылают адресату другой сети из сети ЦОМС 110. В этом случае прокси-агент 113 ПППЭП передает вызов в формате ПППЭП в ЦОМС 150 другого оператора, где он может быть обработан точно тем же способом, как описано выше. Следовательно, вызов МС передают из ЦОМС 110 через прокси-агента 113 ПППЭП в ЦОМС 150 в протоколе, который отличается от протокола либо вызова, поступающего в ЦОМС 110, либо вызова посылаемого из ЦОМС 150. При работе в общем протоколе, таким образом, сигналы запуска событий, сгенерированные с помощью прокси-агента 113 ПППЭП, могут быть надежно созданы, независимо от протоколов, которыми оперируют в разных сетях. Даже было бы возможно, чтобы ЦОМС 150 управлял тот же самый оператор, что и ЦОМС 110, причем этот оператор имеет множество ЦОМС.

Теперь будет описан поток сигналов в вариантах осуществления фиг. 7 со ссылкой на фиг. 8. На фиг. 8 номера с 1 по 9 иллюстрируют стадии передачи сигналов. Заметим, что существуют альтернативы на этапах 7а, 7b и 7с. Следовательно, сигналы инициируют в клиенте 200 МС, который будет программным обеспечением в аппарате 100, и передают через шлюз 201 в ЦОМС 202. ЦОМС 202 передает сигнал агенту 203 передачи, соответствующему агенту 113 передачи, который опрашивает брокера 204 услуг на этапе 4. Этот брокер 204 услуг сам может опрашивать РМС 205, соответствующий устройству 121 РМС на фиг. 7, или ФУПО 206, соответствующую функции 122 управления предварительной оплатой. Если брокер услуг определит, что вызов не может быть послан, сообщение 7с отказа может быть запущено в инициирующую сторону 200. Альтернативно, если брокер 204 услуг определит, что вызов может быть обработан, сигнал передают агенту 203 передачи, который может передать вызов в ЦОМС 207 той же сети ЦОМС 202 (на самом деле они могут быть одним и тем же ЦОМС) на этапе 7а или в ЦОМС 208 другой сети на этапе 7b. Затем ЦОМС 207 передает вызов через этот ЦОМС 209 в соответствующий ЦОМС 116 на этапе 8, а на этапе 9 передает вызов адресату 210.

Формула изобретения

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

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

3. Способ по п.1 или 2, отличающийся тем, что упомянутая функция выполняет дополнительный этап, на котором (f) преобразуют протокол вызова, события или сеанса или упомянутой платформы таким образом, что упомянутый один протокол является обрабатываемым с помощью упомянутой платформы.

4. Способ функционирования мобильной телефонной сети, причем сеть имеет множество платформ, предназначенных для обработки вызова, события или сеанса, сгенерированного в, по меньшей мере, один мобильный телефон или для, по меньшей мере, одного мобильного телефона упомянутой сети, и функцию, которая взаимодействует с упомянутым множеством платформ для определения упомянутой обработки, причем упомянутая функция хранит данные, необходимые для выполнения упомянутых услуг и/или операций обработки вызова, заключающийся в том, что a) определяют в упомянутой функции услуги и/или операции обработки вызова, которые должны быть применены к вызову, событию или сеансу, b) определяют в упомянутой функции, может ли первая платформа из упомянутых платформ выполнить упомянутые услуги и/или операции обработки вызова, c) если упомянутая функция определяет, что упомянутая первая платформа из упомянутых платформ может выполнить, по меньшей мере, некоторые из упомянутых услуг или операций обработки вызова, заставляют упомянутую первую платформу из упомянутых платформ обрабатывать вызов, событие или сеанс с использованием упомянутых данных, d) определяют в упомянутой функции другую из упомянутых платформ, которая может выполнить другие из упомянутых услуг или операций обработки вызова, e) передают вызов, событие или сеанс в упомянутую другую платформу, и f) выполняют упомянутые другие из упомянутых услуг или операций обработки вызова в упомянутой другой платформе с использованием упомянутых данных.

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

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

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

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

9. Способ функционирования мобильной телефонной сети, причем сеть имеет множество платформ, предназначенных для обработки вызова, события или сеанса, сгенерированного в, по меньшей мере, один мобильный телефон или для, по меньшей мере, одного мобильного телефона упомянутой сети, и функцию, которая взаимодействует с упомянутым множеством платформ для определения упомянутой обработки, заключающийся в том, что a) принимают вызов, событие или сеанс в первой платформе из упомянутых платформ, b) определяют в упомянутой функции услуги и/или операции обработки вызова, которые должны быть применены к вызову, событию или сеансу,c) собирают в упомянутой функции данные, необходимые для выполнения упомянутых услуг и/или операций обработки вызова, d) определяют, может ли упомянутая первая платформа выполнить упомянутые услуги и/или операции обработки вызова, и когда результат определения оказывается отрицательным, e) передают упомянутый вызов в другую платформу из упомянутых платформ, которая может выполнить упомянутые услуги и/или операции обработки вызова, и f) передают упомянутые данные из упомянутой функции в упомянутую другую платформу из упомянутых платформ, вследствие чего упомянутая другая платформа из упомянутых платформ выполняет упомянутые услуги и/или операции обработки вызова с использованием упомянутых данных.

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

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

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

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

14. Способ по любому из пп.1, 4 или 9, отличающийся тем, что вызов, событие или сеанс являются мультимедийным сообщением.

15. Мобильная телефонная сеть, имеющая платформу, предназначенную для обработки вызова, события или сеанса, сгенерированного в, по меньшей мере, один мобильный телефон или для, по меньшей мере, одного мобильного телефона упомянутой сети, и функцию, которая взаимодействует с упомянутой платформой для определения упомянутой обработки, причем упомянутая платформа может выполнить множество операций обработки вызова, а упомянутая функция выполняет следующие этапы, на которых a) определяют операции обработки вызова, которые должны быть применены к вызову, событию или сеансу, b) определяют, может ли упомянутая платформа выполнить упомянутые операции обработки вызова, требуемые вызовом, событием или сеансом, c) если упомянутая платформа может выполнить, по меньшей мере, некоторые из упомянутых операций обработки вызова, требуемых вызовом, событием или сеансом, определяют в упомянутой функции данные, требуемые для выполнения упомянутых, по меньшей мере, некоторых из упомянутых операций обработки вызова, и определяют последовательность этапов для упомянутых, по меньшей мере, некоторых из упомянутых операций обработки вызова, чтобы обеспечить обработку упомянутой платформой вызова, события или сеанса, и d) заставляют упомянутую платформу обрабатывать вызов, событие или сеанс путем выполнения упомянутой операции обработки вызова в упомянутом последовательном порядке и с использованием упомянутых данных.

16. Мобильная телефонная сеть, имеющая множество платформ, предназначенных для обработки вызова, события или сеанса, сгенерированного в, по меньшей мере, один мобильный телефон или для, по меньшей мере, одного мобильного телефона упомянутой сети, и функцию, которая взаимодействует с упомянутым множеством платформ для определения упомянутой обработки, причем упомянутая функция хранит данные, необходимые для выполнения упомянутых услуг и/или операций обработки вызова, а сеть способна выполнять следующие этапы, на которых a) определяют в упомянутой функции услуги и/или операции обработки вызова, которые должны быть применены к вызову, событию или сеансу, b) определяют в упомянутой функции, может ли первая платформа из упомянутых платформ выполнить упомянутые услуги и/или операции обработки вызова, c) если упомянутая функция определяет, что упомянутая первая платформа из упомянутых платформ может выполнить, по меньшей мере, некоторые из упомянутых услуг или операций обработки вызова, заставляют упомянутую первую платформу из упомянутых платформ обрабатывать вызов, событие или сеанс с использованием упомянутых данных, d) определяют в упомянутой функции другую из упомянутых платформ, которая может выполнить другие из упомянутых услуг или операций обработки вызова, e) передают вызов, событие или сеанс в упомянутую другую платформу, и f) выполняют упомянутые другие из упомянутых услуг или операций обработки вызова в упомянутой другой платформе с использованием упомянутых данных.

17. Мобильная телефонная сеть, имеющая множество платформ, предназначенных для обработки вызова, события или сеанса, сгенерированного в, по меньшей мере, один мобильный телефон или для, по меньшей мере, одного мобильного телефона упомянутой сети, и функцию, которая взаимодействует с упомянутым множеством платформ для определения упомянутой обработки, причем сеть способна выполнять следующие этапы, на которых a) принимают вызов, событие или сеанс в первой платформе из упомянутых платформ, b) определяют в упомянутой функции услуги и/или операции обработки вызова, которые должны быть применены к вызову, событию или сеансу, c) собирают в упомянутой функции данные, необходимые для выполнения упомянутых услуг и/или операций обработки вызова, d) определяют, может ли упомянутая первая платформа выполнить упомянутые услуги и/или операции обработки вызова, и когда результат определения оказывается отрицательным, e) передают вызов, событие или сеанс в другую платформу из упомянутых платформ, которая может выполнить упомянутые услуги и/или операции обработки вызова, и f) передают упомянутые данные из упомянутой функции в упомянутую другую платформу из упомянутых платформ, вследствие чего упомянутая другая платформа из упомянутых платформ выполняет упомянутые услуги и/или операции обработки вызова с использованием упомянутых данных.

РИСУНКИ