СПОСОБ РАБОТЫ УЗЛА ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ В СООТВЕТСТВИИ С РАСПРЕДЕЛЕННОЙ МНОГОВЫХОДОВОЙ СИСТЕМОЙ ПОИСКОВОГО ВЫЗОВА, СПОСОБ РАБОТЫ РАСПРЕДЕЛЕННОЙ МНОГОВЫХОДОВОЙ СИСТЕМЫ ПОИСКОВОГО ВЫЗОВА Российский патент 2000 года по МПК H04Q7/08 H04B7/00 H04M11/00 G06F15/173 

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

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

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

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

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

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

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

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

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

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

Краткое описание сопроводительных чертежей
Более полное понимание настоящего изобретения можно получить обратившись к подробному описанию и формуле изобретения, рассматривая их с учетом этих сопроводительных чертежей, в которых одинаковые цифровые обозначения относятся к аналогичным позициям на всех чертежах, и
на фиг.1 показан план расположения примерного окружения, в котором может быть осуществлено предпочтительное воплощение этого изобретения;
на фиг. 2 показана блок-схема системы поискового вызова;
на фиг.3-фиг.5 показаны таблицы элементов данных, используемые для системы поискового вызова, показанной на фиг. 2;
на фиг.6-фиг.12 показаны блок-схемы процедур, выполняемых узлами интерфейса пользователя (UIN) системы поискового вызова, показанной на фиг. 2; и
на фиг. 13-фиг. 22 показаны блок-схемы процедур, выполняемых различными узлами в сети системы поискового вызова, показанной на фиг. 2.

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

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

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

Каждый регион 104 содержит любое число систем 102 доставки. Системы 102 доставки собирают и доставляют поисковые вызовы в пределах областей их собственной юрисдикции. Ничто не требует, чтобы системы 102 были совместимы или подобны друг другу. Так, некоторые системы 102 доставки могут использовать традиционные наземные средства ВЧ-передачи, которые направлены на специфические ограниченные географические области. Другие системы 102 доставки могут использовать базирующиеся в космосе (спутниковые) средства 106 ВЧ - связи, которые направляют сообщения в более широкие географические области. Третьи системы доставки могут использовать машины-шлюзы, чтобы передавать вызовы по компьютерным сетям. Каждая из этих и других систем 102 доставки отличается идентификацией единственной системы доставки, в которой находятся единственные адреса доставки.

В соответствии с предпочтительными вариантами реализации настоящего изобретения, распределительная сеть 108, обсуждаемая более подробно ниже, в связи с фиг. 2, работает в пределах окружения 100, принимая и доставляя вызовы соответствующим системам 102 доставки. Системы 102 доставки затем доставляют эти вызовы к блокам абонентов (не показаны), используя их конкретные способы доставки. Система 108 представляет супер-структуру, которая позволяет системам 102 действовать совместно, несмотря на большое разнообразие принципа действия и характеристик систем 102 доставки. Сеть 108 предпочтительно содержит один "оконечный узел поискового вызова" (PTN) 110 для каждого региона 104. Именно узлы PTN 110 доставляют вызовы K заданным системам 102 доставки для последующей доставки их к абонентским блокам. Кроме того, сеть 108 предпочтительно содержит один "узел управления сети" (NMN) 112. Узел NMN 112 собирает статистические данные и рабочие данные состояния о работе сети 108.

На фиг. 2 показана блок-схема окружения 100 и распределительной сети 108 в нем. Вызовы собираются от операторов и от оборудования передачи данных, желающих быть источниками вызовов для узлов интерфейса пользователей (UIN) 202. Окружение 100 может содержать любое число UIN 202, а узлы UIN 202 могут быть распределены по регионам 104 любым удобным способом. Узлы UIN 202 могут контролироваться теми, кто управляет системами 102 доставки, но это не обязательно. Узлы 202 принимают информацию об источнике поискового вызова через каналы 204 источника. Желательно, чтобы каналы 204 были дуплексными каналами, которые могут соединять узел UIN 202 с "коммутируемой сетью электросвязи общего пользования" (PSTN) с локальной или большой площади компьютерной сетью или с любой другой обслуживающей дуплексной системой связи. В этих предпочтительных вариантах реализации изобретения существенный объем интеллекта, необходимого для доставки вызовов, располагается в узлах UIN 202, и процедуры, выполняемые узлами UIN 202, обсуждаются ниже, в связи с фиг. 6 - фиг. 12.

Узлы UIN 202 связаны с сетью 108. Сеть 108 содержит узлы PTN 110, NMN 112, обсуждавшиеся выше, любое число "узлов управления информацией пользователя" (SIM) 206 и сеть связи 208. Узлы NMN 112 и каждый UIN 202, PTN 110 и SIM 206 соединены с сетью 208. Таким образом, через сеть связи 208 каждый UIN 202 может участвовать в передаче данных с любым PTN 110 или SIM 206, а каждый SIM 206 может обеспечить передачу данных с любым другим SIM 206 или PTN 110. Каждый PTN 110 связан с одной или более систем 102 доставки. Системы 102 доставки передают вызовы к любому числу абонентских блоков 210. И наоборот, системам 102 доставки необязательно передавать вызовы к абонентским узлам 210, но они могут представлять собой машину-шлюз для компьютерной сети, например, для такой, которая доставляет страницы в соответствии с методами электронной почты.

Каждому узлу UIN 202 присвоен его собственный узел SIM 206. С точки зрения SIM 206 UIN 202, которому он присвоен, является "противолежащим" ("subtending" UIN). С точки зрения UIN 202, SIM 206, который присвоен этому UIN является "контролирующим" узлом SIM 206. С точки зрения абонента, или оператора, которому посланы эти вызовы, один из узлов SIM 206 считается "собственным" узлом SIM 206. Этот собственный SIM 206 запоминает информацию, описывающую этого абонента и страничное обслуживание, предлагаемое в данный момент для этого абонента. Эта информация записана в собственной базе данных 212 этого собственного узла SIM 206. База данных 214 посторонних абонентов запоминает информацию, касающуюся абонентов, которые не считают этот SIM 206 собственным узлом SIM, но от имени которых, тем не менее, этот SIM используется. Такое использование узла SIM от имени постороннего абонента может облегчить прием вызова противолежащим UIN 202, источником которого является другой оператор. И наоборот, использование SIM по поручению постороннего абонента может осуществляться абонентом, который стремится получить доступ к сети 108 для внесения изменений или запросов относительно его или ее поискового обслуживания.

В соответствии с настоящим изобретением высокоприоритетная передача данных может иметь место между UIN 202 и его управляющим SIM 206. Высокоприоритетная передача этих данных вытекает из необходимости обеспечения быстрых ответов. Как показано более полно ниже, данные передаются между управляющими узлами SIM 206 и UIN 202, когда поисковый вызов генерируется источником, и когда пользователи могут ожидать ответа. Соответственно, специалисты в этой области техники согласятся, что между UIN 202 и SIM 206 желательно было бы иметь выделенную линию 216 или другой канал связи, приспособленный для высокоприоритетных данных сообщений. Линия 216 является частью сети связи 208.

В одном варианте реализации настоящего изобретения, по крайней мере, часть локальных узлов UIN 202 и управляющих SIM 206 конструируют как различные логические объекты общего комплекта компьютерной аппаратной-части. В такой ситуации канал связи 216 реализуется в этом общем комплекте компьютерной аппаратной части с помощью компьютерного программирования.

В предпочтительных вариантах реализации настоящего изобретения каждый из узлов 110, 112, 202 и 206 сети 108 представляет собой компьютер. Другими словами, каждый из этих узлов содержит процессор и память (не показана). Эта память запоминает базы данных 212-214 собственных и посторонних абонентов в SIM 206, так же как и другие таблицы, списки, переменные и команды программирования для каждого из узлов 110, 112, 202 и 206. Желательно, чтобы каждый из этих узлов имел схему синхронизации для получения даты и времени. Предпочтительно, чтобы каждый узел содержал устройства ввода, такие как интерфейсы сети, модемы, клавиатура и т.п., устройства вывода, такие как интерфейсы сети, модемы, видеотерминалы отображения, принтеры и т.п. Кроме того, предпочтительно, чтобы узлы UIN 202 содержали компоненты интерфейса электросвязи, достаточные для работы с интерактивной системой голосового ответа (IVR). Известные версии таких компонентов удобны для использования в настоящем изобретении, и такие компоненты компьютеров хорошо известны специалистам в этой области техники.

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

На фиг. 3-фиг. 5 показаны позиции данных, включенные в базы данных собственных и посторонних абонентов 212-214. Эти позиции данных, показанные на фиг. 3-фиг.5, относятся к абоненту (т.е. к лицу, которому эти вызовы посылаются) и к его или к ее оборудованию, такому как абонентский блок 210. В общем базы данных 212-214 содержат информацию для многих абонентов, а информация каждого абонента включена в его или в ее собственную запись 300 абонента. Так как собственная база данных 212 предпочтительно содержит более обширный набор позиций данных, чем база данных 214 посторонних абонентов, фиг.3 - фиг.5 представлены с точки зрения базы данных 212. Специалисты в этой области техники согласятся, что с небольшими исключениями, которые обсуждаются ниже, большая часть данных, показанных на фиг.3 - фиг.5, применима к "профилю абонента", так же как и к базе данных 214 посторонних абонентов.

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

Позиции этих данных обслуживания показаны в связи с таблицей 400 данных обслуживания абонента (см. фиг. 4). Таблица 400 данных обслуживания абонента связана с записью 300 абонента через ссылку 302, записанную в записи 300 абонента. Настоящее изобретение позволяет абонентам и источникам поисковых вызовов модифицировать это обслуживание, когда необходимо, чтобы лучше удовлетворить потребности абонентов или источников поисковых вызовов. Например, это обслуживание содержит список систем 402 доставки. Системы 402 доставки идентифицируют узлы PTN 110 и системы 102 доставки, к которым должны направляться поисковые вызовы. В таблицу 400 могут быть включены множественные системы 402, чтобы поисковые вызовы могли доставляться с помощью множественных систем. В таблице 400 не должны перечисляться все системы 102, существующие в окружении 100. Скорее, в таблице 400 может содержаться только предполагаемый по умолчанию поднабор всех систем 102 доставки. Затем абонент может динамически активировать и деактивировать системы 402 доставки по мере появления необходимости у абонента.

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

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

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

На фиг. 6 - фиг.12 показаны блок-схемы процедур, выполняемых узлом UIN 202 в соответствии с концепцией настоящего изобретения. Настоящее изобретение предполагает, что каждый UIN 202 в окружении 100 будет выполнять существенно одни и те же процедуры. Так, процедуры, показанные на фиг. 6 -фиг. 12, применимы к любому и ко всем узлам UIN 202. Более того, известная интерактивная система голосовой реакции (IVR) может быть использована для управления процедурами на фиг.6 - фиг.12. Специалисты в этой области техники согласятся, что IVR системы часто используются для сбора информации от вызывающих абонентов по телефонным линиям.

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

На фиг. 6 показана блок-схема процедуры 600. "Старт", которую выполняет UIN 202, когда приходит запрос на приведение в действие источника поискового вызова в задаче 602. Этот запрос принимается по каналу 204. Он может иметь форму телефонного вызова или сообщения, принятого от компьютерной сети. Он может быть принят от лица, использующего "двухтональные мультичастоты" (DTMF) или другое современное телефонное оборудование. Он может быть принят от компьютера, возможно, управляемого человеком, использующим известную технику передачи данных через МОДЕМ. Независимо от вида источника и формы этот запрос информирует UIN 202 о том, что у распределительной сети 108 запрашивается обслуживание.

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

Если задача 604 решит, что идентификация источника запроса требуется, тогда выполняется процедура 700 "Санкционирование источника" для проверки этого вызывавшего абонента. На фиг. 7 показана блок-схема процедуры 700. Со ссылкой на фиг, 7 опросная задача 702 определяет, разрешен ли и доступен ли ID источника сети PSTN. ID источника PSTN относится к источнику этого вызова и этот ID может быть доступным из PSTN как характеристика PSTN.

Если ID источника PSTN разрешен и доступен, опросная задача 704 определяет, является ли этот ID источника действительным для санкционированного источника. Эта действительность определяется из списка (не показан) санкционированных идентификаторов ID источников, который предпочтительно хранится в памяти UIN 202. Если указанный вызывающий абонент ID источника включен в этот список, то этот вызывающий абонент считается санкционированным, и программное управление выходит из процедуры 700 и возвращается к процедуре 600.

С другой стороны, если указанный вызывающим абонентом ID источника не действителен, то опросная задача 706 определяет, действительно ли этот ID был получен от PSTN, или действительно ли был превышен предел попыток. Если этот ID был получен от PSTN или был превышен предел попыток, то этому источнику не предоставляется никаких других возможностей получить обслуживание от UIN 202, и программное управление выходит из процедуры 700 и переходит к процедуре 614 "Выход", обсуждающейся ниже. Эти пределы попыток для получения доступа к обслуживанию, обеспечиваемому UIN 202, улучшают защиту и делают минимальными перегрузки на телефонных линиях, создаваемые несанкционированными абонентами.

Если задача 706 определит, что разрешена другая попытка ввести действительный ID источника, программное управление передается к задаче 708. Кроме того, если задача 702, обсуждавшаяся выше, определит, что указанный PSTN ID источника не разрешен, или разрешен, но в настоящее время не доступен, программное управление также переходит к задаче 708.

UIN 202 собирает данные от источника вызова в задаче 708. В частности, задача 708 собирает ID источника этого вызова. Специалисты в этой области техники согласятся, что сбор данных от источника вызова в задаче 708 или в любой другой задаче, обсуждаемой ниже, может заключать в себе несколько известных процессов. Например, этому вызывающему абоненту может быть сделана подсказка с помощью сообщения или записи, информирующей вызывающего о том, какая информация требуется. UIN 202 может принимать такие поставляемые вызывающим абонентом данные в форме тонов DTMF или данных AS СII и хранить такие данные в буфере, даже если такие данные поступят раньше, чем кончится подсказка. Желательно, чтобы UIN 202 мог ожидать в течение заданного периода времени, пока не поступит ответ вызывающего абонента на эту подсказку. После принятия узлом UIN 202 ответа от вызывающего абонента UIN 202 может проверить этот ответ на действительность в такой степени, насколько это возможно. Если вызывающий абонент не успевает дать ответ в течение заданного периода времени или обнаружен недействительный ответ, подсказка может быть повторена, чтобы дать вызывающему абоненту еще один шанс послать действительные данные. Если вызывающий абонент снова не сможет выдать действительные данные, этот вызов может быть освобожден предпочтительно через подпрограмму 614 "Выход", обсуждаемую ниже. После задачи 708 программное управление переходя к задаче 704, обсуждавшейся выше, для проверки собранных данных на действительность.

Как показано на фиг. 6, после того как вызывающий абонент будет идентифицирован с помощью процедуры 700 санкционирования, если необходимо, или после задачи 604, если санкционирования не требуется, выполняется задача 606. В задаче 606 UIN 202 собирает информацию об оконечном адресе от вызывающего абонента. Этот конечный адрес соответствует, или предпочтительно, является значением идентификации (ID) конкретного абонента в распределительной сети 108. Никакого соответствия один-к-одному между идентификаторами ID и абонентами не предполагается. Соответственно, ID некоторых абонентов может относиться ко всем членам определенной группы абонентов, а некоторые абоненты могут идентифицироваться путем использования любого из нескольких различных ID абонентов.

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

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

После того как вызывающий абонент укажет, в каком обслуживании он или она заинтересованы, UIN 202 выполняет задачу 610, запрос к распределительной сети 108, чтобы она обеспечила информацию о профиле идентифицированного абонента. Этот запрос выполняется путем постановки в очередь к контролирующему SIM 206 команды "Получить профиль" (Get Profile). Эта команда "Получить профиль" содержит ID этого абонента. Кроме того, команда Get Profile уточняет, должна ли запись 400 абонента быть заблокирована в собственной базе данных 212 этого абонента, или же к UIN 202 должен быть возвращен номер последовательности вместе с профилем этого абонента.

Этот профиль абонента представляет поднабор позиций данных, показанных на фиг. 4 и фиг. 5, которые необходимы для приема и маршрутизации поискового вызова и для обеспечения возможности абоненту изменять текущее, активированное для него или нее обслуживание. В частности, со ссылкой на фиг. 3, это обслуживание включает элемент 306 данных ID абонента, коды 308 и 310 защиты поискового вызова и абонента, соответственно, и данные 312 суммарного профиля абонента. В отношении таблицы 400, которая связана с записью абонента 300 через ссылку 302, она содержит определение обслуживания абонента наряду с указанием о том, является ли это обслуживание активным или нет, и коды игнорирования защиты, ассоциированные с этим обслуживанием. Запись 300 этого абонента блокируется, если вызывающий абонент задал обслуживание обновления профиля абонента выше в задаче 608, и возвращается номер последовательности с профилем абонента, если абонент задал связанное с поисковым вызовом обслуживание выше, в задаче 608. Запись 300 блокируется соответствующей манипуляцией элементом 314 данных блокировки в собственной базе данных этого абонента. Номер последовательности получается от элемента данных 316 из записи 300. Как только команда поставлена на очередь, она передается к соответствующему узлу SIM 206 в "Фоновой" процедуре 1200, обсуждающейся ниже. Конечно, если вызывающий абонент запросил выход из UIN 202 выше, в задаче 608, задача 610 может быть опущена.

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

Флаг текущего профиля означает, что данные профиля абонента были заказаны узлом UIN 202, но еще не поступили в этот UIN 202. Как указано подробнее ниже, эти данные профиля могут храниться в контролируемом SIM 206, либо в базе данных 212 собственных, либо в базе данных 214 посторонних абонентов. Профиль абонента может быть получен из контролирующего SIM 206 в большинстве ситуаций. Следовательно, профиль абонента подается к UIN 202 быстро, через каналы связи 212. С другой стороны, контролирующему узлу SIM 206 изредка может потребоваться "заказать" профиль абонента из SIM 206 собственных абонентов.

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

После того как задача 610 закажет профиль абонента, переключательная задача 612 переключит программное управление на процедуру или программу для обработки затребованной опции. Если вызывающий абонент захочет обновить профиль абонента, выполняется процедура 800 обслуживания абонента, обсуждаемая ниже в связи с фиг. 8. Если пользователь предпочтет принять обслуживание поискового вызова, выполняется процедура 1000 обслуживания источника, обсуждаемая ниже в связи с фиг. 10. Если пользователь предпочтет выйти из UIN 202, выполняется программа 614 выхода.

Программа 614 выхода может быть введена из переключательной задачи 612 или из множества других задач, некоторые из которых обсуждались выше. В программе 614 задача 616 ставит на очередь команду "сеанс связи осуществлен" (Session Done) к собственному SIM 206 этого последнего абонента, идентифицированного выше в задаче 606. Определение этого собственного SIM 206 может быть успешно выполнено путем оценки ID этого абонента. Предпочтительно присваивать идентификаторы абонентам так, чтобы конкретное поле ID абонента (например, 4-10 биты) идентифицировало собственный SIM этого абонента. Однако задача 616 опускается, если только она не является необходимой. Задача становится необходимой, если был заблокирован профиль абонента. Как показано подробнее ниже, отправка команды Session Done к собственному SIM 206 позволяет этому собственному SIM 206 разблокировать запись 300 его абонента.

После задачи 616 задача 618 проигрывает или другим способом отправляет соответствующее сообщение в канал 204. Это сообщение информирует вызывающего абонента о том, почему его сеанс (Session) завершается. Это соответствующее сообщение выбирается в ответ на задачу, выполнявшуюся до того, как программное управление было передано программе 614 "Выход". После задачи 618 задача 620 освобождает этот вызов, и процедура 600 останавливается. Эта линия или канал 204 теперь могут использоваться другим вызывающим абонентом.

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

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

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

На фиг. 9 показана блок-схема процедуры 900 "защита". Процедура 900 собирает данные кода защиты от вызывающего абонента. Процедура 900 используется для сбора кода 308 защиты абонента, обсуждавшегося выше, а также кода 310 защиты поискового вызова, и кодов игнорирования защиты поискового вызова (см. фиг. 4), обсуждающиеся ниже. Задача 902 собирает специфицированный код защиты от вызывающего абонента. Когда процедура 900 вызывается из процедуры 800, этот специфицированный код является кодом 308 защиты абонента. После задачи 902 задача 904 устанавливает специфицированный флаг, чтобы индицировать текущее состояние и сбрасывает этот специфицированный флаг текущего состояния, чтобы индицировать неудавшуюся защиту.

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

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

После того как данные обслуживания будут собраны в задаче 802, опросная задача 804 определят, не запросил ли вызывающий абонент выхода из процедуры 800. Если вызывающий абонент не запрашивал выхода из процедуры 800, задача 800 анализирует формат и содержание ответа вызывающего абонента, собранного в задаче 802. Если окажется, что этот ответ вызывающего абонента не действителен, опросная задача 808 возвратит программное управление обратно к задаче 802, чтобы этот вызывающий абонент мог снова попытаться предоставить действительные данные. Конечно, специалисты в этой области техники понимают, что можно ввести дополнительные задачи, определяющие, было ли превышено число попыток или превзойден предел времени до передачи программного управления обратно к задаче 802 и перехода программного управления к программе 614 "Выход", например, если такое число или предел были превышены. Если задача 808 определяет, что данные, предоставленные вызывающим абонентом, оказались действительными, задача 810 собирает подтверждение от вызывающего абонента. Предпочтительно, чтобы задача 810 подсказывала вызывающему абоненту с помощью эхо-сигнала этого ответа на запрос обслуживания, сделанный в задаче 802, чтобы вызывающий абонент мог прекратить этот запрос, если это обслуживание является не тем, что он или она ожидают. Если этот запрос обслуживания не подтверждается, опросная задача 812 направляет программное управление обратно к задаче 802, чтобы вызывающий абонент мог представить данные альтернативного обслуживания. Конечно, специалисты в этой области техники понимают, что можно ввести дополнительные задачи, определяющие, было ли превышено число попыток или превзойден предел времени до передачи программного управления обратно к задаче 802, и перехода программного управления к программе 614 "Выход", например, если такие числа или пределы были превышены.

Если вызывающий абонент подтвердит эти данные обслуживания в задачах 810-812, или если он запросит выхода в задаче 804, программное управление передается к задаче 814, в которой вызывающего абонента спрашивают, не желает ли он сделать другие изменения в записи этого абонента. Если вызывающий абонент обозначит желание сделать дополнительные изменения, программное управление опять передается к задаче 802. Если вызывающий абонент укажет, что больше изменений не требуется, тогда программное управление переходит к опросной задаче 816.

В этой точке UIN 202 завершил столько обработки, сколько было возможно, без обращения к профилю абонента, запрошенному выше, в задаче 610. Соответственно, задача 816 оценивает флаг текущего профиля для ID этого абонента, чтобы определить, не был ли уже принят этот профиль абонента. Если этот профиль не был принят, опросная задача 818 проверяет таймер, определяя, следует ли ожидать дальше приема этого профиля абонента или отвергнуть попытки предоставления обслуживания для текущего идентифицированного абонента. До тех пор, пока заданная длительность, начиная с момента постановки сигнала Get Profile в очередь, не истекла, программное управление возвращается обратно к задаче 816. В течение времени, пока происходит зацикливание на задачах 816-818, UIN 202 может проиграть запись или сообщение к этому вызывающему абоненту, в котором рекомендуется, чтобы он воздержался от приема профиля абонента. Когда эта заданная длительность истечет, программное управление возвратится обратно к программе 614 "Выход".

Когда профиль абонента уже получен, фоновая программа 1200, обсуждаемая ниже, соответственно, регулирует этот флаг текущего профиля, а также устанавливает или сбрасывает флаг защиты абонента для указания того, является или нет код защиты, установленный абонентом выше, в задаче 902, действительным. В предпочтительном осуществлении этот код является действительным, если он согласуется с кодом 308 защиты абонента этого профиля абонента. Если задача 816 определит, что профиль был принят, а установленный абонентом код защиты недействителен, программное управление возвращается обратно, к программе 614 "Выход". Никаких изменений в ранее идентифицированном профиле абонента не разрешается.

С другой стороны, если задача 816 определит, что профиль абонента принят, и что вызывающий абонент установил действительный код защиты, задача 820 проиграет для вызывающего абонента соответствующее сообщение о приеме, а задача 802 поставит в очередь к распределительной сети 108 команду "обновления абонента" (Subscriber-Update). В частности, эта команда Subscriber-Update посылается из UIN 202 к ее контролирующему SIM 206. Из контролирующего SIM 206 она может быть передана к собственному SIM 206. Эта команда Subscriber- Update идентифицирует абонента, к которому эта команда относится, и позицию или позиции данных, которые обновляются, и новые значения или состояния, которые должны ассоциироваться с этими позициями. После задачи 802 программное управление выходит из процедуры 800 и возвращается к задаче 606, чтобы UIN 202 мог выполнять обслуживание других абонентов.

На фиг. 10 показана блок-схема процедуры обслуживание источника 1000. Процедура 1000 вводится из задачи 612, обсуждавшейся выше, когда вызывающий абонент описывает характеристики связанного поисковым вызовом обслуживания. Процедура 1000 выполняется после того, как вызывающий абонент идентифицирует абонента, для которого необходимо это, связанное с поисковым вызовом обслуживание. В опросной задаче 1002 процедура 1000 определит, требуется ли код защиты поискового вызова до того, как UIN 202 сможет приступить к обслуживанию поискового вызова. Это определение может осуществляться в соответствии с рабочими правилами конкретного UIN 202, выполняющего задачу 1002. Все узлы UIN 202 не должны принимать одинаковое решение в задаче 1002. Если защита затребована, выполняется процедура защиты 900, обсуждавшаяся выше. В этой ситуации процедура 900 собирает код защиты поискового вызова от вызывающего абонента и устанавливает флаги так, что никакого обслуживания поискового вызова не будет предоставлено до тех пор, пока Фоновая процедура 1200 не определит, что установленный вызывающим абонентом код поискового вызова согласуется с кодом защиты поискового вызова 310 из профиля этого абонента.

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

После задачи 1004 UIN 202 завершает столько обработки, сколько возможно, без обращений к профилю абонента, затребованному выше, в задаче 610. Соответственно, задача 1006 оценивает флаг задержки профиля для ID этого абонента, чтобы определить, не был ли уже принят профиль этого абонента. Если этот профиль не был принят, опросная задача 1008 решает, надо ли ожидать дальше приема профиля этого абонента, или отвергнуть попытки обеспечения обслуживания для текущего, идентифицированного абонента. До тех пор, пока заданная длительность, от момента постановки на очередь команды Get-Profile, еще не истекла, программное управление передается обратно, к задаче 1006. Во время зацикливания на задачах 1006-1008 UIN 202 может проигрывать запись или сообщение к вызывающему абоненту, рекомендующее ему воздержаться от приема профиля абонента. Если эта заданная длительность истечет раньше, чем будет принят профиль этого абонента, программное управление перейдет к программе 614 "Выход".

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

Никакое связанное с поисковым вызовом обслуживание этого идентифицированного абонента не разрешается.

С другой стороны, если задача 1006 решит, что профиль абонента уже прибыл, и что обеспечиваемый вызывающим абонентом код защиты поискового вызова, если он имеется, согласуется с кодом защиты поискового вызова 310 профиля абонента, опросная задача 1010 определит, запрашивал ли этот вызывающий абонент исследование поискового вызова. Более того, если такое обслуживание запрашивалось, задача 1010 проверяет профиль этого абонента, чтобы проконтролировать, что были активированы характеристики запрошенного исследования для этого абонента. Если такое обслуживание было запрошено, но не активировалось, то желательно, чтобы программное управление можно было направить (не показано) обратно к задаче 1004, позволяя вызывающему абоненту запросить другое обслуживание.

Если было запрошено и активировано обслуживание исследования поискового вызова, задача 1012 ставит соответствующую команду Запроса к собственному SIM 206 этого абонента. После задачи 1012 опросная задача 1014 определяет, был ли получен ответ на эту команду Запроса. Если задача 1014 определит, что никакого ответа на эту команду запроса еще не было получено, опросная команда 1016 решает, надо ли дальше ожидать приема ответа от собственного SIM 206 этого абонента, или отвергнуть попытку исполнить запрос этого абонента. До тех пор, пока заданная длительность с момента постановки на очередь этой команды запроса еще не истекла, программное управление возвращается обратно к задаче 1014. Во время зацикливания по задачам 1014-1016 UIN 202 может проигрывать запись или сообщение к вызывающему абоненту, рекомендующее ему воздержаться от приема результатов этого запроса. Если эта заданная длительность истечет до получения ответа на эту команду Запроса, программное управление переходит к программе выход 614.

Когда задача 1014 определит, что в UIN 202 получен ответ на эту команду Запроса, задача 1018 выдаст этот ответ вызывающему абоненту. На запрос состояния, предварительно записанное сообщение может информировать вызывающего абонента о текущем состоянии идентифицированного поискового вызова. На запрос поискового вызова, сообщение этого идентифицированного поискового вызова может выдать дату и время вызывающему абоненту. После задачи 1018 программное управление выходит из процедуры 1000 и возвращается к задаче 606, чтобы позволить вызывающему абоненту запросить обслуживание для другого абонента.

Возвращаясь к задаче 1010 процедуры 1000, когда было определено, что вызывающий абонент запрашивал размещение поискового вызова, программное управление переходит к процедуре источника 1100. На фиг. 11 представлена блок-схема процедуры 1100. После ввода процедуры 1100, задача 1102 собирает подтверждение о поисковом вызове, доставка которого была запрошена вызывающим абонентом. Желательно, чтобы 1102 могла подтверждать эхо-сигналом любое сообщение, которое должно быть доставлено этим поисковым вызовом. Задача 1102 может дополнительно информировать вызывающего абонента об активных в настоящее время системах доставки и о других опциях обслуживания, которые осуществляют доставку этого поискового вызова. Например, вызывающий абонент может информироваться о том, где находится поисковый вызов, который должен доставляться, или о том, будет ли наложен запрет на этот поисковый вызов, для доставки его позднее этому абоненту. Вызывающий абонент может подтвердить параметры поискового вызова и доставки, отвергнуть этот поисковый вызов (не показано), или послать запрос об игнорировании некоторого специфицированного параметра доставки, такого как система доставки.

После того, как данные подтверждения будут собраны в задаче 1102, опросная задача 1104 определит, запрашивал ли вызывающий абонент игнорирование параметра доставки. Такое игнорирование параметров доставки может повлиять на расчетные счета абонента и на правдоподобие успешно доставленных поисковых вызовов. Соответственно, вызывающий абонент должен соблюдать меры безопасности, чтобы такое игнорирование было принято узлом UIN 202 и распределительной сетью 108. Если запрошено игнорирование параметра, процедура 1100 выполняет процедуру защиты 900 в отношении этого специфического обслуживания (см. фиг. 5), которую запрашивал вызывающий абонент. Процедура 900 потребует от вызывающего абонента представить код игнорирования, который должен быть согласован с соответствующим кодом игнорирования, записанным в профиле этого абонента, прежде чем это игнорирование будет разрешено.

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

После процедуры 900 задача 1106 собирает любые данные, которые соответствуют этому запрошенному игнорированию. Например, если вызывающий абонент запрашивает доставку поискового вызова по адресу, отличающемуся от того, что указан в профиле абонента, тогда задача 1106 собирает данные этого, отличающегося адреса. После задачи 1106, или если никакого игнорирования не запрошено, программное управление переходит к опросной задаче 1108. Когда исполняется задача 1108, профиль абонента уже получен, так как выход из задачи 1006 (см. фиг. 10) был задержан до момента получения профиля абонента. Тем не менее, в задаче 1108 программное управление ожидает, пока не будет разрешено любое игнорирование защиты. Так как вопрос о действительности игнорирования защиты решается в фоновом режиме работы, он может быть не решен ко времени, когда выполняется задача 1108. Соответственно, когда вопрос об игнорировании защиты задерживается, программное управление возвращается обратно, к задаче 1108. Если вопрос о действительности кода игнорирования защиты был решен, и этот код был сочтен недействительным, программное управление выходит из процедуры 900 и переходит к программе выход 614.

Если вопрос об игнорировании защиты был решен и этот код был сочтен действительным, процедура 1100 выполняет задачу 1110. Задача 1110 ставит этот поисковый вызов в очередь на передачу к одному или более узлов PTN 110, команда Page Hold не активна. Этот поисковый вызов содержит номер последовательности поискового вызова, полученный из профиля абонента, адрес PTN 110 любой системы 102 доставки, через которую должен направляться этот поисковый вызов, ID этого абонента и любое сообщение, передаваемое этим поисковым вызовом. Определение того факта, является ли обслуживание "удержание вызова" (Page Hold) активным, производится путем проверки профиля этого абонента. Определение узла (узлов) PTN, к которому должны посылаться эти поисковые вызовы, также осуществляется путем проверки профиля абонента. В частности, активированные системы доставки профиля этого абонента должны использоваться для доставки этого поискового вызова. Задача 1110 может проконсультироваться с таблицей в памяти UIN 202, чтобы перевести эти адреса в адреса узлов PTN 110, которые используются для маршрутизации поисковых вызовов.

После задачи 1110 задача 1112 ставит этот поисковый вызов в очередь для доставки к собственному SIM 206 этого абонента. Этот собственный SIM 206 идентифицируется путем оценки ID этого абонента. Когда этот поисковый вызов направляется к собственному SIM 206 абонента, он содержит значение последовательности, полученное из профиля абонента, адрес этого собственного SIM 206, ID абонента и любое сообщение, передаваемое этим поисковым вызовом. Последний дополнительно информирует собственный SIM 206 о том, что этот поисковый вызов был принят сетью 108, а также об идентификации этого узла (узлов) PTN и идентификации адреса (адресов) системы (систем) доставки и адреса (адресов) доставки, к которым этот поисковый вызов был послан.

После задачи 1112 задача 1114 определяет, активировано ли обслуживание подтверждения состояния путем проверки профиля этого абонента. Если это обслуживание активировано, то вызывающему абоненту представляется значение последовательности. В процессе работы задач 1010-1018 вызывающий абонент может вызвать любой UIN 202 в окружении 100, а позднее запросить состояние этого поискового вызова. Вызывающий абонент должен представить значение этой последовательности, чтобы распределительная сеть 108 могла идентифицировать поисковый вызов, состояние которого запрашивается. После задачи 1114 программное управление выходит из процедуры 1100 и возвращается к задаче 606, чтобы позволить вызывающему абоненту запросить дополнительное обслуживание, относящееся к другому абоненту.

На фиг. 12 показана блок-схема фоновой процедуры 1200. UIN 202 выполняет процедуру 1200 в фоновом режиме. Другими словами, процедура 1200 непрерывно действует, даже если выполняются другие задачи, не относящиеся к процедуре 1200, в общем, в одном и том же временном кадре. Процедура 1200 выполняет задачу 1202 обработки очереди на выходе и задачу 1204, обработки очереди на вход. Другими словами, команды, установленные в очередь для передачи к другим узлам по коммуникационной сети 208, пересылаются в свое время в результате работы задачи 1202, а данные сообщений, принятых от других узлов сети связи 208, получаются благодаря действию задачи 1204.

Специалисты в этой области техники согласятся, что отправка любой команда любым объектом в окружении 100, будь то UIN 202 или другое устройство, может включать в себя ожидание приема сообщения соответствующего подтверждения. Если в течение заданного периода времени подтверждения не получено, то это сообщение может быть повторено. Подобно этому, прием любого сообщения может включать передачу соответствующего сообщения подтверждения в ответ на это принятое сообщение. Такие детали, понятные специалистам в этой области техники, включены в объем задач 1202-1204, и далее здесь не обсуждаются.

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

Задача 1208 определяет, установлен ли флаг защиты текущего состояния абонента. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код защиты абонента. Если этот флаг установлен, то программное управление переходит к процедуре оценки 1210. Если нет, то задача 1212 определяет, установлен ли флаг текущего поискового вызова. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код защиты поискового вызова. Если этот флаг установлен, то программное управление переходит к процедуре оценки 1210.

Если нет, то опросная задача 1214, определяет, установлен ли флаг игнорирования текущего состояния. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код игнорирования защиты. Если этот флаг установлен, то программное управление переходит к процедуре оценки 1210. Если нет, задача 1216 сбрасывает этот флаг текущего профиля для профиля рассматриваемого вызывающего абонента, и программное управление переходит обратно к задаче 1202.

Процедура оценки 1210 определяет, является ли указанный код защиты, введенный вызывающим абонентом, действительным. В частности, опросная задача 1218 сравнивает этот введенный вызывающим абонентом код защиты, с соответствующими кодами защиты, включенными в профиль этого вызывающего абонента (см. фиг. 3-5). Если этот, введенный вызывающим абонентом, код и коды профиля абонента согласованы или каким-то образом соответствуют друг другу, тогда этот введенный вызывающим абонентом код, считается действительным и задача 1220 устанавливает этот специфицированный флаг защиты для индикации действительного кода защиты. Если этот, введенный вызывающим абонентом код и коды профиля абонента не соответствуют друг другу, то этот введенный вызывающим абонентом код считается недействительным. Задача 1222 сбрасывает этот специфицированный флаг защиты, если необходимо, чтобы индицировать недействительный код защиты. После задач 1220 или 1222 задача 1224 сбрасывает этот специфицированный флаг защиты текущего состояния для индикации того, что эта специфицированная функция защиты теперь решена. Контроль над этими флагами текущего состояния и защиты осуществляется, как описано выше, в связи с задачами 816, 1006 и 1108. После задачи 1224 программное управление переходит к задачам 1212, 1214 иди 1216, как указано на фиг. 12. На графиках фиг. 13-22 показаны блок-схемы процедур, выполняемых узлами распределительной сети 108. Как указывалось выше, основной объем интеллекта, связанный с маршрутизацией поисковых вызовов и обеспечением программного обслуживания абонента и источника вызова настоящего изобретения сосредоточен в узлах UIN 202. Так, процедуры, выполняемые узлами распределительной сети 108, обычно обеспечивают вышеописанные процедуры, выполняемые узлами UIN 202. Специалисты в этой области техники согласятся, что в предпочтительных вариантах реализации настоящего изобретения процедуры, показанные на фиг. 13-22, осуществляются компьютеризованным оборудованием под управлением компьютерных программ, записанных в памяти этого оборудования. Более того, специалисты в этой области техники знают, что эти процедуры предпочтительно являются повторно используемыми.

На фиг. 13 показана команда Get Profile процедуры 1300, выполняемая SIM 206, действующим в качестве контролирующего узла SIM для UIN 202. В частности, процедура 1300 выполняется, когда SIM 206 принимает команду Get Profile от UIN 202 в задаче 610, описанной выше. Команда содержит ID абонента и предписывает, либо заблокировать запись 300 этого абонента в собственной базе данных 212 абонента, либо возвратить номер последовательности в UIN 202, пославший эту команду Get Profile, как обсуждалось выше, в связи с задачей 610.

Процедура 1300 выполняет опросную задачу 1302 определения того факта, действительно ли ID абонента, переданный командой Get Profile, представляет ID локального абонента. Другими словами, задача 1302 определяет, считает ли абонент, профиль которого запрашивается, что SIM 206 является его или ее собственным узлом SIM. Это определение может быть сделано путем оценки ID абонента, в котором указан собственный SIM 206 этого абонента. Если задача 1302 определяет, что SIM 206, выполняющий процедуру 1300, является собственным SIM 206, то задача 1304 просматривает абонентскую запись 300 этого идентифицированного абонента в его собственной базе данных 212 и отсылает профиль этого абонента обратно, к локальному UIN 202, в соответствии с параметрами команды Get Profile. Задача 1304 также блокирует профиль этого абонента или включает номер последовательности в профиль этого абонента, отправляемый обратно, к локальному UIN 202. После задачи 1304 программное управление выходит из процедуры 1300.

Если задача 1302 определяет, что абонент, профиль которого запрашивается, не является локальным абонентом, то опросная задача 1306 определяет, не зарегистрирован ли в настоящее время этот абонент, в качестве постороннего абонента SIM 206, выполняющего процедуру 1300. Абонент считается посторонним абонентом, если он имеет запись постороннего абонента для этого идентифицированного абонента в его собственной базе данных 214 посторонних абонентов. Если он или она не зарегистрированы как посторонние абоненты, то задача 1308 форматирует и отправляет команду "запроса профиля" (Profile-Request) к собственному SIM этого абонента. Если он или она зарегистрированы в качестве постороннего абонента, задача 1310 форматирует и отправляет команду "обновления профиля" (Profile-Update) к собственному SIM 206. После задач 1308 и 1310 эта команда будет отправлена к собственному SIM 206 этого абонента, а программное управление выйдет из процедуры 1300.

Команда Profile-Request идентифицирует контролирующий SIM 206, запрашивающий этот профиль и ID абонента, для которого делается этот запрос. Команда Profile-Update идентифицирует контролирующий SIM 206, запросивший обновление этого профиля, ID абонента, для которого делается запрос и суммирующий элемент данных. Обе эти команды Profile-Request и Profile-Update устанавливают, надо ли заблокировать запись 300 этого абонента в собственном SIM 206 или возвратить номер последовательности. Команда Profile-Request запрашивает SIM 206, чтобы он выдал полный профиль абонента, который является поднабором полной записи 300 абонента. Номер 316 последовательности включается в профиль этого абонента, если команда Profile-Request требует, чтобы он был включен. Этот профиль абонента может потребовать передачи относительно большого объема данных. С другой стороны, команда Profile-Update запрашивает собственный SIM 206, чтобы он проверил, действителен ли все еще профиль абонента, хранящийся в настоящее время в контролирующем SIM 206 базы данных посторонних абонентов.

Чтобы определить, действителен ли этот профиль, некоторый вид суммирующих данных посылается к этому собственному SIM 206. Этими суммирующими данными может быть контрольная сумма этого профиля абонента, исключая любые номера 316 последовательности. Или в качестве альтернативы, это может быть другой тип кода обнаружения ошибки, такой как контроль циклическим избыточным кодом. В другом варианте реализации изобретения эти суммирующие данные формируют дату или дату и штамп времени, который указывает последнее время, когда этот профиль абонента обновлялся. Если собственный SIM 206 определяет, путем оценки этих суммарных данных, что профиль абонента, хранящийся в собственном SIM 206 этого абонента, не изменился по сравнению с профилем абонента, хранящимся в базе данных 214 посторонних абонентов контролирующего SIM 216, тогда сети связи 208 не нужно передавать профиль этого абонента обратно, к этому контролирующему SIM 206, и ресурсы сети не занимаются.

На фиг. 14 показана блок-схема команды "ответного сообщения о профиле" (Profile-Response) процедуры 1400. Процедура 1400 выполняется контролирующим SIM 206, когда он принимает ответ от собственного SIM 206 на команды, посланные выше в связи с задачами 1308 или 1310. Задача 1402 определяет, является ли ответное сообщение, принятое SIM 206, ответом верификации или профилем абонента. Ответ верификации есть короткая коммуникация, которая информирует контролирующий SIM 206, что специфицированная запись абонента в его базе данных 214 посторонних абонентов содержит текущий профиль абонента. Этот ответ верификации предпочтительно содержит ID абонента для идентификации этого абонента, о котором был сделан запрос, и обсуждавшийся выше номер 316 последовательности. Этот профиль последовательности может сохраняться в профиле абонента в базе данных 214 посторонних абонентов. Если обнаружен этот запрос верификации, выполняется задача 1404, отправка профиля абонента из базы данных 214 посторонних абонентов к локальному UIN 202. Если этот запрос верификации в задаче 1402 не обнаружен, выполняется задача 1406 сохранения профиля абонента в базе данных 214 посторонних абонентов этого SIM. После задачи 1406 выполняется задача 1404 отправки профиля этого абонента к локальному UIN 202. После задачи 1404 программное управление выходит из процедуры 1400.

На фиг. 15 показана команда "обновления абонента" (Subscriber-Update) процедуры 1500. Процедура 1500 выполняется контролирующим SIM 206, когда он принимает команду Subscriber- Update от UIN 202. Команда Subscriber-Update идентифицирует абонента, к которому относится эта команда, и передает позицию или позиции данных, которые обновляются, и новые значения или состояния, которые должны ассоциироваться с этими позициями. Эта команда Subscriber-Update передается UIN 202 во время задачи 822.

Процедура 1500 выполняет опросную задачу 1502 определения того факта, является ли этот идентифицированный абонент локальным абонентом. Если этот абонент - локальный, задача 1504 обновляет позиции соответствующих данных в собственной базе данных 212 и осуществляет рециркуляцию элемента 312 суммарных данных для того, чтобы отразить этот обновленный профиль данных. Кроме того, задача 1504 разблокирует запись 300 этого абонента путем изменения позиции 314 данных о ней. После задачи 1504 программное управление выходит из процедуры 1500. Если задача 1502 определяет, что этот абонент не является локальным абонентом, она посылает команду Subscriber-Update к собственному SIM 206 абонента в задаче 1506. Кроме того, она обновляет соответствующие позиции данных, включая элемент 312 суммарных данных в ее базе данных 214 посторонних абонентов в задаче 1508. Когда собственный SIM 206 примет эту команду, он будет выполнять свою собственную версию процедуры 1500. После задачи 1506-1508 программное управление переходит к процедуре 1500.

На фиг. 16 показана блок-схема команды "запроса профиля" (Profile-Request) процедуры 1600. Процедура 1600 выполняется собственным SIM 206, когда он принимает команду Profile-Request от любого контролирующего SIM 206, входящего в окружение 100. Команда Profile-Request идентифицирует абонента, к которому эта команда прикладывается, она определяет, надо ли заблокировать профиль этого абонента, или возвратить номер последовательности, и идентифицирует контролирующий SIM, которому должен быть послан ответ на эту команду. Эта команда Profile- Request передается управляющим SIM 206 во время задачи 1308, обсуждавшейся выше.

Процедура 1600 выполняет задачу 1602 получения профиля абонента от собственной базы данных 212. Как указывалось выше, профиль абонента предпочтительно является поднабором всех позиций данных, хранящихся в записи 300 абонента. После задачи 1602, задача 1604 проверяет позицию 314 данных с целью определить, не заблокирована ли запись этого абонента. Если в текущий момент запись 300 заблокирована, задача 1604 ожидает момента, когда запись 300 будет разблокирована (не показано).

Поисковые вызовы снабжены номерами 316 последовательности, как обсуждено выше, чтобы их можно было индивидуально идентифицировать после приема их распределительной сетью 108. Номера 316 последовательности контролируются в собственных узлах SIM, исключающих возможность дублирования этих номеров последовательности. Если команда Profile-Request инструктирует собственный SIM 206 включить номер 316 последовательности, задача 1604 включает номер 316 последовательности в профиль абонента. Затем задача 1604 посылает этот профиль к запросившему SIM 206 в форме команды Profile-Response, обсуждавшейся выше, в связи с фиг. 14. Задача 1604 может также сделать приращение или по-другому изменить номер последовательности позиции 316 данных, так чтобы новый номер последовательности стал сразу же доступен. От контролирующего SIM 206, принявшего профиль, этот профиль направляется к UIN 202, как обсуждалось выше, в связи с процедурой 1400.

После задачи 1604 выполняется задача 1606 определения, инструктировала ли команда Profile-Request собственный SIM 206 заблокировать запись 300 этого абонента. Если такой запрос был сделан, задача 1606 установит элемент 314 данных записи 300 абонента с целью указании того, что запись 300 этого абонента теперь заблокирована. Кроме того, может быть установлен таймер, чтобы эта запись 300 абонента автоматически разблокировалась по истечении определенного интервала времени. За счет этого исключается возможность в случае сбоя в работе UIN 202 создавать помехи для способности других UIN 202 использовать распределительную сеть 108. До тех пор, пока запись 300 остается заблокированной, поисковые вызовы не могут быть размещены. Как указывалось выше, запись 300 остается заблокированной все время, пока производится обновление профиля абонента. Благодаря этому предотвращается размещение поисковых вызовов в соответствии с устаревшей записью абонента. После подачи 1606 программное управление выходит из процедуры 1600.

На фиг. 17 показана блок-схема команды Profile-Update процедуры 1700. Процедура 1700 выполняется собственным SIM 206, когда он принимает команду Profile-Update от любого контролирующего SIM 206 в окружении 100. Команда Profile-Update идентифицирует абонента, к которому относится эта команда, идентифицирует управляющий SIM 206, к которому должен посылаться ответ на эту команду, инструктирует собственный SIM 206, чтобы он либо заблокировал запись 300 этого, абонента, либо включил номер 316 последовательности в возвращаемый ответ и включает суммирующие данные. Команда Profile-Update передается контролирующим SIM 206 во время задачи 1316, обсуждавшейся выше.

Процедура 1700 выполняет задачу 1702 ожидания события, когда запись 300 этого идентифицированного абонента будет разблокирована. Задача 1702 может определить, заблокирована ли запись 300 в результате оценки позиции 314 данных в записи 300 этого абонента. Более часто записи 300 абонента в задаче 1702 разблокированы и существенных потерь времени не имеет места. Однако, если во время, когда осуществляется обновление абонента, принимается команда Profile-Update, программное управление не выйдет из задачи 1702 до тех пор, пока эта запись не будет разблокирована. Эта запись может разблокироваться, как указано выше, в связи с задачей 1504.

После задачи 1702 опросная задача 1704 определяет, соответствуют ли, или другим образом согласуются ли суммарные данные, принятые с этой командой Profile-Update, с суммарными данными 312, включенными в запись 300 этого абонента в собственной базе данных 212 для этого идентифицированного абонента. Если эти суммарные данные соответствуют, задача 1706 форматирует и отправляет команду Profile-Response верификации обратно, запросившему SIM 206. Эта команда Profile-Response содержит ID этого абонента. Она также содержит номер последовательности из позиции 316 данных, если была проинструктирована командой Profile-Update, чтобы сделать это. Принимающий SIM 206 обрабатывает эту команду Profile-Update в процедуре 140, обсуждавшейся выше.

Если задача 1704 определяет, что суммарные данные не соответствуют, задача 1708 форматирует и отправляет этот полный профиль абонента, который является поднабором записи 300, к затребованному в команде Profile-Response SIM 206. Эта команда Profile-Response также содержит номер последовательности из позиции 316 данных, если была инструкция сделать это в команде Profile-Update. После задачи 1706 или 1708 выполняется задача 1710 определения, инструктировала ли команда Profile-Request собственный SIM 206 заблокировать запись 300 этого абонента. Если такой запрос был, задача 1710 установит элемент 314 данных записи 300 абонента для указания того, что запись 300 этого абонента теперь заблокирована. После задачи 1710 программное управление выходит из процедуры 1700.

На фиг. 18 показана блок-схема команды Session-Done процедуры 1800. Процедура 1800 выполняется собственным SIM 206, когда он принимает команду Session-Done от любого UIN 202 в окружении 100. Эта команда идентифицирует абонента, к которому подается эта команда, и означает, что этим абонентом не было принято никаких изменений. Команда Session-Done передается узлом UIN 202 во время задачи 616, обсуждавшейся выше. Процедура 1800 выполняет задачу 1802 разблокирования записи 300 идентифицированного абонента путем изменения позиции 314 данных в ней. Это разблокирование позволяет в будущем использовать запись 300. После задачи 1802 программное управление выходит из процедуры 1800.

На фиг. 19 показана блок-схема команды "поисковый вызов" (Page) процедуры 1900. Процедура 1900 выполняется собственным SIM 206, когда он принимает команду Page от любого UIN 202 в окружении 100. Эта команда идентифицирует абонента, к которому эта команда прикладывается, идентифицирует номер последовательности, ассоциированный с этой страницей, и в случае необходимости может содержать сообщение. Команда Page передается UIN 202 как результат задачи 1112, обсуждавшейся выше. Процедура 1900 выполняет задачу 1902 сохранения любого сообщения, ассоциированного с этим поисковым вызовом, в соответствующей ячейке памяти собственной базы данных 212, и устанавливает канал 320 записи 300 абонента для идентификации таблицы 500 активности, которая используется для хранения данных этого поискового вызова. Кроме того, состояние этого поискового вызова может обновляться в таблице 500, отражающей факт приема этого поискового вызова собственным SIM 206. После задачи 1902 программное управление выходит из процедуры 1900.

На фиг. 20 показана блок-схема команды Inquiry процедуры 2000. Процедура 2000 выполняется собственным SIM 206, когда он примет команду Inquiry от любого UIN 202 в окружении 100. Команда Inquiry идентифицирует абонента, к которому относится эта команда, UIN 202, к которому должен быть послан ответ, и номер последовательности, который идентифицирует отдельный поисковый вызов. Эта команда Inquiry передается UIN 202 как результат задачи 1012, описанной выше. Процедура 2000 выполняет задачу 2002 просмотра поискового вызова, указанного в таблице 500 активности абонента. Затем задача 2004 отправляет состояние или поисковый вызов, ассоциированные с этим номером последовательности, в зависимости от типа команды запроса, обратно, к запросившему UIN 202. После задачи 2004 программное управление выходит из процедуры 2000.

На фиг. 21 показана блок-схема команды "обновление, состояния" Status-Update процедуры 2100. Процедура 2100 выполняется собственным SIM 206, когда он примет команду Status-Update от любого узла в окружении 100, и в частности, от PTN 110. Команда Status-Update содержит информацию, которая позволяет проследить ход процесса доставки поискового вызова. Соответственно, PTN 110 может отправить одну команду Status-Update, когда он примет поисковый вызов от UIN 202, другую, когда он передаст этот поисковый вызов к указанной системе 102 доставки, и еще одну, когда указанная система 102 доставки проинформирует, что она доставила этот поисковый вызов. Команда Status-Update содержит данные, идентифицирующие абонента; которому адресована эта команда, номер последовательности поискового вызова, к которому относится эта информация обновления, и данные, идентифицирующие текущее состояние этого поискового вызова. Процедура 2100 выполняет задачу 2102 просмотра этого указанного поискового вызова в таблице 500 активности абонента. Кроме того, задача 2102 модифицирует эти данные состояния, ассоциированные с указанным поисковым вызовом, в соответствии с данными, переданными командой Status-Update. После задачи 2102 программное управление выходит из процедуры 2100.

На фиг. 22 показана блок-схема процедуры 2200 PTN 2- "поисковый вызов принят" (Page-Receved). Процедура 2200 выполняется узлом PTN 110, когда он примет поисковый вызов от UIN 202 для доставки через одну из его подсистем, если таковая имеется. Процедура 2200 выполняется в ответ на команду, посланную UIN 202 в соответствии с исполнением задачи 1110, обсуждавшейся выше. Задача 2202 форматирует этот поисковый вызов и ставит его в очередь для доставки с помощью системы 102 доставки, указанной в этом поисковом вызове. Этот поисковый вызов не должен доставляться немедленно. Скорее, узлы PTN могут собирать поисковые вызовы для доставки к нижестоящим системам 102 доставки эффективным образом. После задачи 2202, задача 2204 может форматировать и отправлять команду Status-Update к собственному SIM 206 этого поискового вызова. Ничто не требует от PTN 110 немедленной отправки команды Status-Update. Фактически, PTN 110 предпочтительно ожидает получения подтверждения от системы доставки 102, прежде чем снять с очереди поисковый вызов и отправить команду Status-Update к собственному. SIM 206. После задачи 2204 программное управление выходит из процедуры 2200.

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

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

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

1. Способ работы узла интерфейса пользователя в соответствии с распределенной многовыходовой системой поискового вызова для маршрутизации поисковых вызовов в подходящие независимые подсистемы поискового вызова для доставки поисковых вызовов, отличающийся тем, что принимают от вызывающего абонента в упомянутом узле интерфейса пользователя сообщения с инициирующими данными, имеющее значение идентификатора (ИД) и адрес доставки, причем значение ИД идентифицирует одну сеть распределения поискового вызова из множества независимых сетей распределения поискового вызова, а адрес доставки соответствует абонентскому идентификатору (ИД), идентифицирующему абонента, которому должен быть послан поисковый вызов, запрашивают через сеть связи профиль абонента из узла управления абонентской информацией упомянутой одной сети распределения поискового вызова на основании абонентского ИД, причем профиль абонента определяет перечень активизированных независимых систем доставки поискового вызова для доставки поискового вызова, при этом, по меньшей мере, одна из упомянутых активизированных независимых систем доставки поискового вызова определена абонентом в профиле абонента, получают в узле интерфейса пользователя сообщение поискового вызова от вызывающего абонента, принимают в узле интерфейса пользователя из узла управления абонентской информацией упомянутый профиль абонента и определяют оконечный узел поискового вызова, связанный с активизированными системами доставки, в которые должен быть послан поисковый вызов, маршрутизируют через сеть связи упомянутый поисковый вызов, включающий сообщение поискового вызова, из узла интерфейса пользователя в упомянутый оконечный узел поискового вызова, при этом оконечный узел поискового вызова формирует поисковый вызов для доставки через каждую из активизированных систем доставки из упомянутого перечня и посылает сформатированный поисковый вызов в каждую из активизированных систем доставки для потенциального приема упомянутым абонентом. 2. Способ по п.1, отличающийся тем, что дополнительно посылают в узел управления абонентской информацией команду на обновление состояния, идентифицирующую текущее состояние поискового вызова как посланного в упомянутые активизированные системы доставки, после запроса профиля абонента принимают код защиты поискового вызова от вызывающего абонента, если код защиты поискового вызова совпадает с кодом защиты в профиле абонента, определяют оконечный узел поискового вызова, а если код защиты поискового вызова не совпадает с кодом защиты в профиле абонента, прекращают сообщение с инициирующими данными. 3. Способ по п.2, отличающийся тем, что дополнительно принимают в узле интерфейса пользователя сообщение от абонента, запрашивающее внесение изменения в профиль абонента, чтобы заменить указанную, по меньшей мере, одну активизированную систему доставки на другую активизированную систему доставки и с указанием уникального идентификатора системы доставки для этой другой активизированной системы доставки, посылают через сеть связи из узла интерфейса пользователя в узел управления абонентской информацией команду на обновление, дающую указание узлу управления абонентской информацией изменить профиль абонента в соответствии с упомянутым изменением. 4. Способ по п.3, отличающийся тем, что при запросе профиля абонента обрабатывают абонентский ИД в узле управления абонентской информацией, чтобы определить собственный узел базы данных упомянутого абонента в том случае, если узел управления абонентской информацией не является собственным узлом базы данных для этого абонента, при этом собственным узлом базы данных является другой узел управления абонентской информацией, имеющий хранящийся в нем текущий адрес доставки для данного абонента, который соответствует перечню активизированных систем доставки. 5. Способ по п.4, отличающийся тем, что при приеме профиля абонента принимают профиль абонента, задающий перечень активизированных систем доставки, включающий в себя базирующуюся в космосе (спутниковую) систему доставки и наземную систему доставки, и при определении оконечного узла поискового вызова идентифицируют оконечный узел поискового вызова для спутниковой системы доставки и оконечный узел поискового вызова для наземной системы доставки, причем в первом оконечном узле поискового вызова формируют поисковый вызов для базирующейся в космосе (спутниковой) системы доставки, а во втором оконечном узле поискового вызова форматируют упомянутый поисковый вызов для наземной системы доставки. 6. Способ по п. 4, отличающийся тем, что при приеме профиля абонента принимают профиль абонента, задающий перечень активизированных систем доставки, включающий в себя спутниковую систему доставки и наземную систему доставки, и при идентификации оконечного узла поискового вызова идентифицируют оконечный узел поискового вызова для спутниковой системы доставки и наземной системы доставки, причем в оконечном узле поискового вызова форматируют упомянутый поисковый вызов для спутниковой системы доставки и наземной системы доставки. 7. Способ по п.5, отличающийся тем, что при получении кода защиты поискового вызова прекращают сообщение с инициирующими данными, если код защиты поискового вызова не совпадает с кодом защиты поискового вызова в профиле абонента. 8. Способ по п.7, отличающийся тем, что дополнительно получают последовательный номер поискового вызова из профиля абонента и посылают в ответ на него подтверждающее значение в узел управления абонентской информацией. 9. Способ по п.8, отличающийся тем, что при посылке поискового вызова дополнительно включают последовательный номер поискового вызова в сообщение поискового вызова. 10. Способ по п.9, отличающийся тем, что дополнительно принимают значение ИД по каналу подтверждения и обрабатывают это принятое через канал подтверждения значение ИД для определения адреса упомянутого узла управления абонентской информацией. 11. Способ работы распределенной многовыходовой системы поискового вызова, выполненной с возможностью приема поисковых вызовов от множества узлов интерфейсов пользователей и доставки упомянутых поисковых вызовов множеству независимых систем доставки поисковых вызовов, отличающийся тем, что получают через сеть связи от узла интерфейса пользователя запрос на профиль абонента, имеющий значение идентификатора (ИД), идентифицирующее одну сеть распределения поисковых вызовов из множества независимых сетей распределения поисковых вызовов, причем запрос на профиль абонента также включает в себя абонентский ИД, идентифицирующий абонента, которому должен быть послан поисковый вызов, анализируют профиль абонента для идентификации перечня активизированных систем доставки, принимают через сеть связи от узла интерфейса пользователя упомянутый поисковый вызов для маршрутизации в оконечный узел поискового вызова, причем оконечный узел поискового вызова определяют в узле интерфейса пользователя в ответ на прием перечня активизированных систем доставки, маршрутизируют упомянутый поисковый вызов в упомянутый оконечный узел поискового вызова, в котором форматируют поисковый вызов для доставки через каждую активизированную систему доставки и доставляют сформатированный поисковый вызов в каждую из активизированных систем доставки для потенциального приема абонентом. 12. Способ по п.11, отличающийся тем, что узел управления абонентской информацией содержит упомянутый уникальный идентификатор системы доставки для каждой системы доставки, при этом дополнительно посылают уникальный идентификатор системы доставки для каждой активизированной системы доставки. 13. Способ по п.12, отличающийся тем, что в оконечном узле поискового вызова форматируют упомянутый поисковый вызов для доставки базирующейся в космосе (спутниковой) системе доставки поисковых вызовов и форматируют поисковый вызов для доставки в наземной системе доставки поисковых вызовов. 14. Способ по п.13, отличающийся тем, что дополнительно получают в узле управления абонентской информацией последовательное значение поискового вызова, соответствующее упомянутому поисковому вызову, и принимают команду на обновление состояния от оконечного узла поискового вызова в собственном узле базы данных, причем командой на обновление состояния дают указание узлу управления абонентской информацией зарегистрировать состояние доставленного поискового вызова вместе с упомянутым последовательным значением поискового вызова. 15. Способ по п. 14, отличающийся тем, что дополнительно запоминают последовательное значение поискового вызова в связи с каждой из активизированных систем доставки поисковых вызовов в узле управления абонентской информацией, возвращают последовательный номер поискового вызова из узла управления абонентской информацией в узел интерфейса пользователя, принимают в узле управления абонентской информацией команду на обновление состояния, информирующую узел управления абонентской информацией о том, что упомянутый поисковый вызов был принят оконечным узлом поискового вызова для доставки в, по меньшей мере, одной из активизированных независимых систем доставки поисковых вызовов, и изменяют в узле управления абонентской информацией данные состояния, связанные с этим поисковым вызовом, в ответ на команду на принятие.