Спосіб роботи вузла інтерфейсу користувача і спосіб роботи розподіленої багатовихідної системи пошукового виклику

1 Способ работы узла интерфейса пользователя в соответствии с распределенной многовы-ходовой системой поискового вызова, отличающийся тем, что принимают от вызывающего абонента в упомянутом узле интерфейса пользователя сообщение с инициирующими данными, имеющими значение идентификатора (ИД) и адрес доставки, причем значение ИД идентифицирует одн у сеть распределения поискового вызова из множества независимых сетей распределения поискового вызова, а адрес доставки соответствуе т абонентскому ИД, идентифицирующему абонента, которому должен быть послан поисковый вызов, запрашивают через сеть связи профиль абонента из узла управления абонентской информацией упомянутой одной сети распределения поискового вызова на основании абонентского ИД, причем профиль абонента определяет перечень активизированных независимых систем доставки поискового вызова для доставки поискового вызова, при этом, по меньшей мере, одну из упомянутых активизированных независимых систем доставки поисковых вызовов определяют абонентом в профиле абонента, получают в узле интерфейса пользователя сообщение поискового вызова от вызывающего абонента, принимают в узле интерфейса пользователя из узла управления абонентской информацией упомянутый профиль абонента и определяют оконечный узел поискового вызова, связанный с активизированными системами доставки, в которые должен быть послан данный поисковый вызов, маршрутизируют через сеть связи упомянутый поисковый вызов включающий сообщение поискового вызова, из узла интерфейса пользователя в упомянутый оконечный узел поиско во го вызо ва , в ко тором оконечным узлом поискового вызова форматируют поисковый вызов для доставки через каждую из активизированных систем доставки из упомянутого перечня, и посылают сформатированный поисковый вызов в каждую из активизированных систем доставки для потенциального приема упомянутым абонентом 2 Способ по п 1, отличающийся тем, что допол нительно посылают в узел управления абонентс кой ин формацией команду на обно вление сос тояния, идентифицирующую текущее состояние поискового вызова как посланного в упомянутые активизированные системы доставки, после зап роса профиля абонента принимают код защиты поискового вызова о т вызы вающе го абонен та, если код защиты поискового вызова совпадает с кодом защиты в профиле абонента, определяют оконечный узел поиско вого вызова , а е сли код защиты поискового вызова не совпадает с кодом защиты в профиле абонента, прекращают сооб щение с инициирующими данными 3 Спосо б по п 2, о тли ча ющийся тем , что до полнительно принимают в узле интерфейса пользователя сообщение от абонента, запраши вающее внесение изменения в профиль абонен та, чтобы заменить указанную, по меньшей мере, одну активизированную систему доставки на дру гую активизированную систему доставки, и с ука занием уникального идентификатора системы доставки для этой др угой активизированной сис темы доставки, и посылают через се ть связи из узла интер фейса пользователя в узел управле ния абонен тской ин формацией команду на об новление, дающую указание узлу управления абонентской информацией изменить профиль абонента в соответствии с упомянутым измене нием 4 Способ по п 3 , отл ичающийся тем, что при запросе профиля абонента обраба тывают або нентский ИД в узле управления абонентской ин формацией, чтобы определить собственный узел базы данных упомянутого абонента в том случае, если узел управления абонентской информацией не я вляе тся со бственным узлом базы данны х для этого абонента, при этом собственным узлом базы данны х я вляется др угой узел упра вления абонентской информацией, имеющей хранящий ся в нем тек ущи й а дрес доста вки для данно го см О о о со ю см со 32539 абонента, который соответствует перечню активизированных систем доставки. 5 Способ по п 4, отли чающий ся тем , что при приеме профиля абонента принимают профиль абонента, задающий перечень активизированных систем доставки, включающий в себя базирующуюся в космосе (спутниковую) систему доставки и наземную систему доставки, и при определении оконечного узла поискового вызова идентифицир уют оконечный узел поискового вызова для спутниковой системы доставки и оконечный узел поискового вызова для наземной системы доставки, причем в первом оконечном узле поискового вызова форматир уют поисковый вызов для базирующейся в космосе(спутниковой)системы доставки, а во втором оконечном узле поискового вызова форматируют упомянутый поисковый вызов для наземной системы доставки. 6. Спо со б по п 4 , о тли ча ющийся тем, что при приеме профиля абонента принимают профиль абонента, задающий перечень активизированных систем доставки, включающий в себя сп утнико вую систему доставки и наземную систему дос та вки , и пр и и ден ти фикации оконе чно го узла поискового вызова идентифицир уют оконечный узел поискового вызова для сп утниковой систе мы доставки и наземной системы доставки, при чем в оконечном узле поискового вызова форма тируют упомянутый поисковый вызов для спутни ковой системы до ставки и наземной системы доставки. 7. Способ по п . 5, о тлича ющий ся тем , что при получении кода защиты поискового вызова прек ращают сообщение с инициирующими данными, если код за щи ты поисково го вызо ва не со впа дает с кодом за щи ты поисково го вызова в про филе абонента. 8. Способ по п . 1, о тличающий ся тем , что до полнительно получают последовательный номер поискового вызова из профиля абонента и посы лают в ответ на него подтверждающее значение в узел управления абонентской информацией. 9. Способ по п . 8, о тлича ющий ся тем , что при посылке поискового вызова дополнительно вклю чают последовательный номер поискового вызо ва в сообщение поискового вызова. 10 Способ по п. 9, отлича ющийся тем, что до полнительно принимают значение ИД по каналу подтверждения и обрабатывают это принятое через канал подтверждения значение ИД для определения адреса упомянутого узла управления абонентской информацией 11. Способ работы распределенной многовыхо-довой системы поискового вызова, выполненной с возможностью приема поисковых вызовов от множества узлов интерфейсов пользователей и доставки упомянуты х поисковых вызовов множеству независимых систем доставки поисковых вызовов, отли чающийся тем, что получа ют через сеть связи от узла интерфейса пользователя запрос на профиль абонента, имеющий значение идентификатора (ИД), идентифицирующее одну сеть распределения поисковых вызовов из множества независимых сетей распределения поисковых вызовов, причем запрос на профиль або нента также включает в себя абонентский ИД, идентифицирующий абонента, которому должен быть послан поисковый вызов; анализируют профиль абонента для идентификации перечня активизированных систем доставки, принимают через сеть связи от узла интерфейса пользователя упомянутый поисковый вызов для маршрутизации в оконечный узел поискового вызова, причем оконечный узел поискового вызова определяют в узле интерфейса пользователям ответ на прием перечня активизированных систем доставки; маршрутизируют упомянутый поисковый вызов в упомянутый оконечный узел поискового вызова, в котором форматируют поисковый вызов для доставки через каждую активизированную систему доставки и доставляют сформатированный поисковый вызов в каждую из активизированных систем доставки для потенциального приема абонентом 12. Способ по п. 11 , о тли ча ющий ся тем , что узел управления абонентской информацией содержит упомянутый уникальный идентификатор системы доставки для каждой системы доставки, при этом дополнительно посылают уникальный идентификатор системы доставки для каждой активизированной системы доставки 13 Способ по п 12, отлича ющийся тем, что 8 оконечном узле поискового вызова форматируют упомянутый поисковый вызов для доставки базирующейся в космосе в (спутниковой) системе доставки поисковых вызовов и форматируют поисковый вызов для доставки в наземной системе доставки поисковых вызовов 14. Способ по п 13 , о тли чающийся тем, что до полнительно получают в уз ле упра вления або нентской информацией^последовательное значе-. ние поискового вызова, соответствующее упомя нутому поисковому вызову, и принимают команду на о бно влени е со стояния о т оконе чно го узла поискового вызова в собственном узле базы дан ных, причем командой на обновление состояния дают указание узлу управления абонентской ин формацией зарегистрировать состояние достав ленного поискового вызова вместе с упомянутым последовательным значением поискового вызо ва. 15. Способ по п. 14, отли чающийся тем, что до полнительно запоминают последовательное зна чение поискового вызова в связи с каждой из ак тивизированных систем доставки поисковых вы зовов в узле управления абонентской информа цией, возвращают последовательный номер поискового вызова из узла управления абонентс кой информацией в узел интер фейса пользова теля, принимают в узле управления абонентской информацией команду на обновление состояния, информирующую узел управления абонентской информацией о том, что упомянутый поисковый вызов был принят оконечным узлом поискового вызова для доставки в, по меньшей мере, одной из активизированных независимых систем дос тавки поисковых вызовов, и изменяют в узле уп равления абонентской информацией данные сос тояния, связанные с этим поисковым вызовом, в ответ на команду на принятие. 32539 Настоящее изобретение в общем относится к коммуникационным системам (системам связи) Более конкретно, настоящее изобретение относится к системам поискового вызова, которые обеспечивают операции множественной доставки поисковых вызовов Поисковый вызов относится к обслуживанию симплексных сообщений Иными словами, симплексные вызовы, здесь и далее именуемые поисковыми вызовами, направляются точно определенными абонентам такого обслуживания Когда абонентский блок, такой как пейджер, принимает поисковый вызовов, абонент предупреждается об этом Эти поисковые вызовы могут содержать сообщения или они могут просто передавать тот факт, что этот абонент подвергается поисковому вызову Вообще говоря, это обслуживание считается симплексным обслуживанием, так как сообщение передается только в одном направлении, от источника поискового вызова к абоненту В настоящее время используются многие системы поискового вызова При типовом обслуживании поискового вызова используются ВЧсвязь для доставки вызовов к пейджерам (устройствам поискового вызова) Следовательно, пейджеры не должны быть привязаны к конкретному месту и их можно переносить вместе с абонентом Поскольку пейджеры только принимают сообщения, им не требуются передатчики или возможности для передачи сигналов В результате, пейджеры обычно являются небольшими, с низким потреблением, малого веса, портативным и недорогими блоками Известные системы поискового вызова испытывают проблему, связанную с ограничением радиуса действия Система поискового вызова работает только, когда ее лейджеры находятся в пределах области, которая может быть достижима для передатчиков этой системы Если абоненты движутся за пределами этой области, их пейджеры не могут принять вызовы Другим аспектом этой проблемы является ограничение емкости пейджинговой сети Когда область покрытия увеличивается для лучшего обслуживания нужд абонентов, количество устройств поискового вызова также увеличивается При возрастании количества устройств поискового вызова число сообщений данных возрастает Так, по мере возрастания области покрытия может быть достигнута точка уменьшения возвратов Число сообщений данных может стать столь большим, что возникнут недопустимые задержки в доставке вызовов Более того, со временные системы поискового вызова обычно доставляют вызовы только тем пейджерам, которые специально спроектированы, чтобы быть совместимыми с параметрами систем поискового вызова ВЧ-связи Так, экономия веса в результате объединения емкостей независимых систем поискового вызова трудно достижима Соответственно, существуе т необходимость в суперструктуре, которая принимает поисковые вызовы от источников поисковых вызовов и затем отправляет эти вызовы соответствующим независимым подсистемам поискового вызова для доставки этих вызовов Таким образом, это преимущество настоящего изобретения, что предлагается улучшенная система и способ доставки поисковых вызовов. Другим преимуществом настоящего изобретения является то, что обеспечиваются множественные операции доставки поисковых вызовов Другое преимущество заключается в том, что настоящее изобретение формирует распределенную сеть, в которой обрабатывающие мощности сконцентрированы в множестве узлов интерфейсов пользователей Еще одно преимущество состоит в том, что настоящее изобретение обеспечивает систему, которая независимо от действий, которые отдельные устройства, связанные с этой системой, могут предпринять, остается функционирующей для остальных устройств Вышеназванные и другие преимущества настоящего изобретения достигаются в одной форме, способом действия узла интерфейса пользователя в соответствии с распределенной многовыходовой системой поискового вызова Этот способ требует получения сообщения с инициирующими данными, имеющего значение идентификатора (ID) Это значение ID идентифицируе т абонента, которому должен быть послан поисковый вызов В узел базы данных отправляется команда Эта команда приказывает узлу базы данных возвратить данные текущего адреса доставки Эти возвращенные данные конкретного текущего адреса доставки ассоциированы с этим значением ID Эти данные текущего адреса доставки принимаются и вызов посылается к одному из множества узлов, сконфигурированных для приема вызовов Этот один узел, к которому посылается вызов, идентифицир уется в ответ на эти данные адреса доставки Вышеназванные и другие преимущества настоящего изобретения достигаются в др угой форме способом работы распределенной многовыходовой системы поискового вызова Этот способ предусматривает получение команды запроса профиля пользователя (subscriber profile) от узла интер фейса пользователя Эта команда запроса профиля пользователя имеет значение (ID) идентификации, и это значение ID идентифицирует абонента, к которому должен быть послан вызов Это значение обрабатывается с целью получения адреса собственного узла базы данных. Этот собственный узел базы данных имеет записанный в памяти текущий адрес доставки Команда запроса профиля приказывает собственному узлу базы данных возвратить данные текущего адреса доставки, ассоциированные с этим значением (ID) Данные этого текущего адреса доставки затем посылаются из собственного узла базы данных к узлу интерфейса пользователя Более полное понимание настоящего изобретения можно получить обратившись к подробному описанию и формуле изобретения, рассматривая их с учетом эти х сопроводительных чертежей, в которых одинаковые цифровые обозначения относятся к аналогичным позициям на всех чертежах, где на фиг 1 показан план расположения примерного окружения, в котором может быть осуществлено предпочтительное воплощение этого изобретения, на фиг. 2 показана блок 32539 схема системы поискового вызова ; на фи гЗфиг.5 показаны таблицы элементов данных, используемые для системы поискового вызова, показанной на фиг.2; на фиг.6-фиг.12 показаны блок-схемы процедур, выполняемых узлами интерфейса пользователя (UIN) системы поискового вызо ва , показанной на фи г. 2 ; на фи г 13фиг.22 показаны блок-схемы процедур, выполняемых различными узлами в сети системы поискового вызова, показанной на фиг. 2. Описание, приведенное ниже, и эти сопроводительные чертежи связаны друг с другом при помощи цифровых обозначений для ссылок Эти цифровые обозначения для ссылок выбраны с таким расчетом, чтобы отражать тот номер чертежа, на котором указанные позиции являются самыми наглядными. В частности, три старши х разряда всех трехразрядных обозначений для ссылок и два старших разряда всех четырехразрядных обозначений для ссылок равны номеру чертежа, на котором можно видеть эту адресуемую позицию На фиг. 1 показан план расположения примерного окружения 1, в котором может быть использован этот предпочтительный вариант реализации настоящего изобретения. При работе настоящего изобретения вызовы могут передаваться к большому количеству систем доставки 2, которые существуют вн утри окружения 1. В настоящем описании термины "поисковый вызов" или "поисковые вызовы" относятся к любой симплексной системе связи, независимо от того, доставляется ли она по каналам ВЧ или другим способом Они могут, а могут и нет, содержать сообщения для приемников информации В целях настоящего изобретения поисковые вызовы включают сообщения, передаваемые известными системами поискового вызова, а также электронную почту и другие сообщения, передаваемые в компьютерных сетях и по другим каналам связи. Как показано на фиг. 1, окружение 1 распределяет юрисдикции для доставки вызовов по множеству географических регионов 3. На фиг. 1 показана Северная Америка, поделенная на три региона 3. Точное число и расположение регионов 3 выбирается в некоторой степени произвольно и не является ограничением в настоящем изобретении. Более того, ничто не мешает поделить весь земной шар или меньшие географические области на регионы 3. Каждый регион 3 содержит любое число систем 2 доставки. Системы 2 доставки собирают и доставляют поисковые вызовы в пределах областей их собственной юрисдикции. Ничто не требует, чтобы системы 2 были совместимы или подобны друг другу. Так, некоторые системы 2 доставки могут использовать традиционные наземные средства ВЧ-передачи, которые направлены на специфические ограниченные географические области. Другие системы 2 доставки могут использовать базирующиеся в космосе (спутниковые) средства 4 ВЧ-связи, которые направляют сообщения в более широкие географические области. Третьи системы доставки могут использовать машины-шлюзы, чтобы передавать вызовы по компьютерным сетям. Каждая из этих и других систем 2 доста вки отличается иденти фикацией единственной системы доставки, в которой находятся единственные адреса доставки. В соответствии с предпочтительными вариантами реализации настоящего изобретения, распределительная сеть 5, обсуждаемая более подробно ниже, в связи с фиг. 2, работает в пределах окружения 1, принимая и доставляя вызовы соответствующим системам 2 доставки. Системы 2 доставки затем доставляют эти вызовы к блокам абонентов (не показаны), используя их конкретные способы доставки. Система 5 представляет супер-структуру, которая позволяет системам 2 действовать совместно, несмотря на большое разнообразие принципа действия и характеристик систем 2 доставки. Сеть 5 предпочтительно содержит один "оконечный узел поискового вызова" (PTN) 6 для каждого региона 3. Именно узлы PTN 6 доставляют вызовы к заданным системам 2 доставки для последующей доставки их к абонентским блокам. Кроме того, сеть 5 предпочтительно содержит один "узел управления сети" (NMN) 7. Узел NMN 7 собирает статистические данные и рабочие данные состояния о работе сети 5. На фиг. 2 показана блок-схема окружения 1 и распределительной сети 5 в нем Вызовы соби раются от операторов и от оборудования переда чи данных, желающих быть источниками вызовов для узлов интерфейса пользователей (UIN) 8. Окружение 1 может содержать любое число UIN 8, а узлы UIN 8 могут быть распределены по ре гионам 3 любым удобным способом. Узлы UIN 8 могут контролироваться теми, кто управляет сис темами 2 доставки, но это не обязательно. Узлы 8 принимают информацию об источнике поиско вого вызова через каналы 9 источника. Жела тельно, чтобы каналы 9 были дуплексными кана лами, которые могут соединять узел UIN 8 с "ком мутируемой сетью электросвязи общего пользо вания" (PSTN) с локальной или большой площа ди компьютерной сетью или с любой другой обс луживающей дуплексной системой связи. В этих предпочтительных вариантах реализации изоб ретения существенный объем интеллекта, необ ходимого для доставки вызовов, располагается в узлах UIN 8, и процедуры, выполняемые узлами U IN 8 , обсуж да ются ниже , в связи с фи г.6 фиг. 12. • > Узлы UIN 8 связаны с сетью 5. Сеть 5 содержит узлы PTN 6 , N MN 7, обсуждавшиеся выше, любое число "узлов управления информацией пользователя" (SIM) 10 и сеть связи 11. Узлы NMN 7 и каждый UIN 8, PTN 6 и SIM 10 соединены с сетью 11. Таким образом, через сеть связи 11 каждый UIN 8 может участвовать в передаче данных с любым PTN 6 или SIM 10, а каждый S1M 10 может обеспечить передачу данных с любым другим SIM 10 или PTN 6 . Каждый PTN 6 связан с одной или более систем 2 доставки. Системы 2 доставки передают вызовы к любому числу абонентских блоков 12. И наоборот, системам 2 доставки необязательно передавать вызовы к абонентским узлам 12, но они могут представлять собой машину-шлюз для компьютерной сети, например, для такой, которая доставляет страницы в соответствии с методами электронной почты. 32539 Каждому узлу UIN 8 присвоен его собственный узел SIM 10 С то чки зрения SIM 10 UIN 8, которому он присвоен/ является "противолежащим" ("subtending" U IN) С то чки зрения UIN 8, SIM 10, который присвоен этому UIN, является "контролирующим" узлом SIM 10 С точки зрения абонента, или оператора, которому посланы эти вызовы, один из узлов SIM 10 считается "собственным" узлом SIM 10 Этот собственный SIM 10 запоминает информацию, описывающую этого абонента и страничное обслуживание, предлагаемое в данный момент для этого абонента Эта информация записана в собственной базе данных 13 этого собственного узла SIM 10 База данных 14 посторонних абонентов запоминает информацию, касающуюся абонентов, которые не считают этот SIM 10 собственным узлом SIM, но от имени которых, тем не менее, этот SIM используется Такое использование узла SIM от имени постороннего абонента может облегчить прием вызова противолежащим UIN 8, источником которого является другой оператор И наоборот, использование SIM по поручению постороннего абонента может осуществляться абонентом, который стремится получить доступ к сети 5 для внесения изменений или запросов относительно его или ее поискового обслуживания В соответствии с настоящим изобретением высокоприоритетная передача данных может иметь место между UIN 8 и его упра вляющим SIM 10 Высокоприоритетная передача этих данных вытекает из необходимости обеспечения быстрых ответов Как показано более полно ниже, данные передаются между управляющими узлами SIM 10 и UIN 8, когда поисковый вызов генерируется источником и когда пользователи могут ожидать ответа Соответственно, специалисты в этой области техники согласятся, что между UIN 8 и SIM 10 желательно было бы иметь выделенную линию 15 или другой канал связи, приспособленный для высокоприоритетных данных сообщений Линия 15 является частью сети связи 11 В одном варианте реализации настоящего изобретения, по крайней мере, часть локальных узлов UIN 8 и управляющих SIM 10 конструируют как различные логические объекты общего комплекта компьютерной аппаратной части В такой ситуации канал связи 15 реализуется в этом общем комплекте компьютерной аппаратной части с помощью компьютерного программирования В предпочтительных вариантах реализации настоящего изобретения каждый из узлов 6, 7, 8 и 10 сети 5 представляет собой компьютер Другими словами, каждый из этих узлов содержит процессор и память (не показана) Эта память запоминает базы данных 13-14 собственных и посторонни х абонентов в SIM 10 , так же как и другие таблица, списки, переменные и команды программирования для каждого из узлов 6, 7, 8 и 10 Желательно, чтобы каждый из этих узлов имел схему синхронизации для получения даты и времени Предпочтительно, чтобы каждый узел содержал устройства ввода, такие как интерфейсы сети, модемы, клавиатура и т п , устройства вывода, такие как интерфейсы сети, модемы, видеотерминалы отображения, принте ры и т п Кроме того, предпочтительно, чтобы узлы UIN 8 содержали компоненты интерфейса электросвязи, достаточные для работы с интерактивной системой голосового ответа (IVR) Известные версии таких компонентов удобны для использования в настоящем изобретении, и такие компоненты компьютеров хорошо известны специалистам в этой области техники Системы 2 доставки дополнительно представляют компьютеризованное оборудование Однако системы 2 могут кроме этого содержать компоненты, которые позволяют системам 2 соответствовать конкретным схемам ВЧ-связи Системы 2 доставки, через которые поисковые вызовы могут посылаться к абонентских блокам 12, и абонентские блоки 12, приспособленные для приема поисковых вызовов, хорошо известны специалистам в этой области техники На фиг 3-фи г 5 показаны позиции данных, включенные в базы данных собственных и посторонних абонентов 13-14 Эти позиции данных, показанные на фиг 3-фиг 5, относятся к абоненту ( т е к лицу, которому эти вызовы посылаются) и к его или к ее оборудованию, такому как абонентский блок 12 В общем базы данных 13-14 содержат информацию для многих абонентов, а информация каждого. абонента включена в его или в ее собственн ую запись 16 абонента Так как собственная база данных 13 предпочтительно содержит более обширный набор позиций данных, чем база данных 14 посторонних абонентов, фиг 3-фиг 5 представлены с точки зрения базы данных 13 Специалисты в этой области техники согласятся, что с небольшими исключениями, которые обсуждаются ниже, большая часть данных, показанных на фиг 3-фиг 5, применима к "профилю абонента", так же как и к базе данных 14 посторонних абонентов В общем, запись 16 абонента содержит позиции данных идентифицирующи х этого абонента, и обслуживание или возможности, предлагаемые сетью 5 этому абоненту Желательно, чтобы собственная база данных 13 могла бы содержать платежные данные, данные статистического использования сети, данные регистрации и имя абонента, адрес, кредит и другие идентифицирующие данные и т п , но эти позиции данных не обязательно должны быть отражены в базах данных 14 посторонних абонентов, или в профилях абонентов, и больше здесь не обсуждаются Позиции этих данных обслуживания показаны в связи с таблицей 17 данных обслуживания абонента (см фиг 4) Таблица 17 данных обслуживания абонента связана с записью 16 абонента через ссылку 18, записанную в записи 16 абонента Настоящее изобретение позволяет абонентам и источникам поисковых вызовов модифицировать это обслуживание, когда необходимо, чтобы лучше удо влетворить потребности абонентов или источников поисковых вызовов Например, это обслуживание содержит список систем 19 доставки Системы 19 доставки идентифицир уют узлы PTN 6 и системы 2 доставки, к которым должны направляться поисковые вызовы В таблицу 17 могут быть включены множественные системы 19, чтобы поисковые вызо 32539 вы могли доставляться с помощью множественных систем В таблице 17 не должны перечисляться все системы 2, существующие в окружении 1. Скорее, в таблице 17 может содержаться только предполагаемый по умолчанию поднабор всех систем 2 доставки. Затем абонент может динамически активировать и деактивировать системы 19 доставки по мере появления необходимости у абонента Например, абонент, который совершает путешествие, может деактивировать одну систем у 2 доставки и активировать другую систему 2, чтобы поисковые вызовы следовали за ним илиза ней до его или её места назначения И наоборот, абонент может активировать множественные системы доставки, если ожидается, что его или её местонахождение будет изменяться в широких пределах. Может оказаться желательным, чтобы оплата базировалась на использовании сети, так что абонент будет заинтересован задействовать не больше активных систем, чем необходимо для удовлетворения его или её требований. Bqnee того, в пределах параметров, перечисленных в таблице 17, источник вызова может игнорировать специфицированную абонентом систему доставки.если приложен соответствующий код игнорирования защиты, чтобы передать поисковый вызов через альтернативную систему 2 доставки. Соответственно, настоящее изобретение может обеспечить поисковый вызов в пределах исключительно большой области, но ни одной системе доставки не требуется емкости, достаточной для размещения всей полной большой области. Скорее эта область поделена между системами доставки 2 и абонент может "программировать" распределительную сеть 5, чтобы определить те системы 2, которые лучше удовлетворяют нуждам абонента Другие виды обслуживания, предоставляемого распределительной сетью 5, включают, но не ограничиваются, наложение запрета на подлежащие доставке абоненту поисковые вызовы, повторную посылку поисковых вызовов, доставляемых абоненту, архивное хранение поисковых вызовов и разрешение источнику поискового вызова проверять состояние вызова после того, как вызов будет размещен. Эти виды обслуживания и другие позиции данных, показанные на фиг.Зфиг 5, будут подробно обсуждаться ниже. На фиг.6-фиг.12 показаны блок-схемы процедур, выполняемых узлом U1N 8 в соответствии с концепцией настоящего изобретения. Настоящее изобретение предполагает, что каждый UIN 8 в окружении 1 будет выполнять существенно одни и те же процедуры. Так, процедуры, показанные на фиг. 6 -фиг. 12, применимы к любому и ко всем узлам UIN 8. Более того, известная интерактивная система голосовой реакции (IVR) может быть использована для управления процедурами на фиг 6-фиг 12. Специалисты в этой области техники согласятся, что IVR-системы часто используются для сбора информации от вызывающих абонентов по телефонным линиям. Основной объем интеллекта, связанного с маршрутизацией поисковых вызовов и обеспечением программированного обслуживания або нента и источника вызова настоящего изобретения, включен в узлы 8. Так, настоящее изобретение является распределенной системой. Так как настоящее изобретение является распределенной системой, надежность повышается по сравнению с централизованной системой. Более того, стоимости обслуживания равномерно распределены по всей системе, и не сконцентрированы в централизованном оборудовании. Специалисты в этой области те хники согласятся, что в предпочтительных вариантах воплощения настоящего изобретения процедуры, показанные на фиг.6фиг 12, осуществляются компьютеризованным оборудованием под управлением компьютерных программ, записанных в памяти этого оборудования. Более того, специалисты в этой области техники признают, что эти процедуры предпочтительно являются повторно используемыми Следовательно, те процедуры, которые являются множественными, могут продолжать действовать в любое заданное время относительно размещенного одного или более поискового вызова. На фиг 6 показана блок-схема процедуры 20 "Старт", которую выполняет UIN 8, когда приходит запрос на приведение в действие источника поискового вызова в задаче 21. Этот запрос принимается по каналу 9 Он может иметь форму телефонного вызова или сообщения, принятого от компьютерной сети. Он может быть принят от лица, использующего "двухтональные мультичастоты" (DTMF) или другое современное телефонное оборудование Он может быть принят от компьютера, возможно, управляемого человеком, использующим известную технику передачи данных через МОДЕМ. Независимо от вида источника и формы это т запрос информируе т U IN 8 о том, что у распределительной сети 5 запрашивается обслуживание. Когда задача 21 получает запрос, поисковая задача 22 определяет, потребовал ли запросивший вызывающий абонент идентифицировать его или её для проверки, прежде чем можно будет использовать обслуживание узла UIN 8 для доступа .к распределительной сети 5. Такое определение основано на правилах, согласно которым работает UIN 8, и такие правила могут устанавливаться в соответствии с нуждами контролирующего UIN 8. Не все узлы UIN 8 должны принимать одинаковые решения в задаче 22. Если задача 22 решит, что идентификация источника запроса требуется, тогда выполняется процедура 23 "Санкционирование источника" для проверки этого вызывавшего абонента На фиг. 7 показана блок-схема процедуры 23. Со ссылкой на фиг. 7 опросная задача 24 определяет, разрешен ли и доступен ли ID источника сети PSTN. ID источника PSTN относится к источнику этого вызова и этот ID может быть доступным из PSTN как характеристика PSTN. Если ID источника PSTN разрешен и доступен, опросная задача 25 определяет, является ли этот ID источника действительным для санкционированного источника. Эта действительность определяется из списка (не показан) санкционированных идентификаторов ID источников, который предпочтительно хранится в памяти UIN 8. Если указанный вызывающий абонент ID ис 32539 точника включен в этот описок, то этот вызываю* щий абонент считается санкционированным, и программное управление выходит из процедуры 23 и возвращается к процедуре 20. С другой стороны, если указанный вызывающим абонентом ID исто чника не действи телен, то опросная задача 2&определяе т, действительно ли это т ID был получен от PSTN , или действи тельно ли был превы шен предел попыток . Если это т ID бы л п олучен о т PSTN и ли был превы шен предел попыток, то этом у и сточник у не предоставляется никаких др уги х возможносте й получи ть обслужи вание о т U IN 8, и программное управление вы ходи т из процедуры 23 и пер е ходит к проце дуре 2 7 "Выход", обсуждающейся ниже Эти пределы попыток для получения доступа к обслуживанию, обеспечиваемому U IN 8, улучша ют за щи ту и делают минимальными перегрузки на телефонных линия х, созда ваемые несанкционированными абонентами. Если задача 26 определит, что разрешена другая попытка ввести действительный ID источника, программное управление передается к задаче 28. Кроме того, если задача 24, обсуждавшаяся выше, определит, что указанный PSTN ID источника не разрешен, или разрешен, но в настоящее время не доступен, программное управление также переходит к задаче 28. UIN 8 собирает данные от источника вызова в задаче 28. В частности, задача 28 собирает ID источника этого вызова Специалисты в этой области техники согласятся, что сбор данных от источника вызова в задаче 28 или в любой другой задаче, обсуждаемой ниже, может заключать в себе несколько известных процессов. Например, этому вызывающему абоненту может быть сделана подсказка с помощью сообщения или записи, информирующей вызывающего о том, какая информация требуется. UIN 8 может принимать такие поставляемые вызывающим абонентом данные в форме тонов DTMF или данных AS СИ и хранить такие данные в буфере, даже если такие данные поступят раньше, чем кончится подсказка. Желательно, чтобы UIN 8 мог ожидать в течение заданного периода времени, пока не поступит ответ вызывающего абонента на эту подсказку. После принятия узлом UIN 8 ответа от вызывающего абонента UIN 8 может проверить этот ответ на действительность в такой степени, насколько это возможно. Если вызывающий абонент не успевает дать ответ в течение заданного периода времени или обнаружен недействительный ответ, подсказка может быть повторена, чтобы дать вызывающему абоненту е ще один шанс послать действительные данные Если вызывающий абонент снова не сможет выдать действительные данные, этот вызов может быть осво- , божден предпочтительно через подпрограмму 27 "Выход", обсуждаемую ниже После задачи 28 программное управление переходит к задаче 25, обсуждавшейся выше, для проверки собранных данных на действительность. Как показано на фиг.6, после того, как вызывающий абонент будет идентифицирован с помощью процедуры 23 санкционирования, если необходимо, или после задачи 22, если санкцио нирования не требуется, выпопняется задача 29. В задаче 29 UIN 8 собирает информацию об оконечном адресе от вызывающего абонента Этот оконечный адрес соответствует, или предпочтительно, является значением идентификации (ID) конкретного абонента в г аспределительной сети 5. Никакого соответствия один-к-одному между идентификаторами ID и абонентами не предполагается. Соответственно, ID некоторых абонентов может относиться ко всем членам определенной группы абонентов, а некоторые абоненты могут идентифицироваться путем использования любого из нескольких различных ID абонентов. После того, как сбор данных ID закончен, задача 30 собирает данные операции обслуживания от вызывающего абонента. Одна операция обслуживания в задаче 30 о тносится к поисковым вызовам. При этом обслуживании поисковые вызовы могут быть произведены абонентом. В дополнение к этому может быть проверено состояние ранее 'размещенного или произведенного поисковоговызова, и последние могут быть повторно выполнены для предоставления абоненту. Другая операция обслуживания в задаче 30 позволяет абоненту модифицировать или обновлять его или её профиль абонента. Кроме того, задача 30 обеспечивает возможность вызывающему абоненту, выйти из UIN 8 в этой точке. В альтернативном варианте реализации этого изобретения UIN 8 обеспечивает два отдельных порта доступа. Эти порты доступа могут соответствовать, например, двум различным телефонным номерам. Один порт доступа может использоваться исключительно для обслуживания абонента, а другой - исключительно для обслуживания источника. В этом варианте реализации задаче 30 не нужно собирать данные операции обслуживания от вызывающего абонента, потому что желаемая операция обслуживания может быть выведена из идентичности порта доступа, использованного этим вызывающим абонентом. После того, как вызывающий абонент укажет, в каком обслуживании он или она заинтересованы, UIN 8 выполняет задачу 31, запрос к распределительной сети 5, чтобы она обеспечила информацию о профиле идентифицированного абонента. Этот запрос выполняется путем постановки в очередь к контролирующему SIM 10 команды "Получить профиль" (Get Profile). Эта команда "Получить профиль" содержит ID этого абонента Кроме того, команда Get Profile уточняет, должна ли запись 17 абонента быть заблокирована в собственной базе данных 13 этого абонента, или же к UIN 8 должен быть возвращен номер последовательности вместе с профилем этого абонента. Этот профиль абонента представляет поднабор позиций данных, показанных на фиг. 4 и фиг.5, которые необходимы для приема и маршрутизации поискового вызова и для обеспечения возможности абоненту изменять текущее, активированное для него или неё обслуживание В частности, со ссылкой на фиг. 3, это обслуживание включает элемент 32 данных ID абонента, коды 33 и 34 защиты поискового вызова и абонента, соответственно, и данные 35 суммарного профиля абонента. В отношении таблицы 17, ко 32539 торая связана с записью а бонента 16 через ссылку 18, она содержит определение обслуживания абонента наряду с указанием о том, является ли это обслуживание активным или нет, и коды игнорирования защиты, ассоциированные с этим обслуживанием Запись 16 этого абонента блокируется, если вызывающий абонент задал обслуживание обновления профиля абонента выше в задаче 30, и возвращается номер последовательности с профилем абонента, если абонент задал связанное с поисковым вызовом обслуживание выше, в задаче 30. Запись 16 блокируется соответствующей манипуляцией элементом 36 данных блокировки в собственной базе данных этого абонента. Номер последовательности получается от элемента данных 37 из записи 16. Как только команда поставлена на очередь, она передается к соответствующему узлу SIM 10 в "Фоновой" процедуре 38, обсуждающейся ниже. Конечно, если вызывающий абонент запросил выход из UIN 8 выше , в задаче 30, задача 31 может быть опущена. Как показано на фиг. 6, задача 31 дополнительно устанавливает флаг текущего профиля и все флаги защиты для индикации состояния успешной защиты. Эти флаги защиты обсуждаются ниже. Установка этих флаго в в состояние успешной защиты не предполагает, что в результа те автоматически получится успешная защита. Скорее, она устанавливает инициализированное состояние, из которого начинаются процедуры, описанные ниже Флаг тек ущего профиля обозначает, что данные профиля абонента были заказаны узлом UIN 8, но еще не поступили в этот UIN 8. Как указано подробнее ниже, эти данные профиля могут храниться в контролируемом SIM 10, либо в базе данных 13 собственных, либо в базе данных 14 посторонних абонентов. Профиль абонента может быть получен из контролирующего SIM 10 в большинстве ситуаций. Следовательно, профиль абонента подается к UIN 8 быстро, через каналы связи 13. С другой стороны, контролирующему узлу SIM 10 изредка может потребоваться "заказать" профиль абонента из SIM 10 собственных абонентов. Задержка в получении профиля абонента в UIV 8 изменяется в зависимости от того, где в настоя щее время это т про филь а бонен та находится, и от нагрузки сообщения данных в сети связи 11. U1N 8 продолжает обрабатывать столько вызовов, сколько возможно, пока распределительная сеть 5 пытается подать этот профиль абонента в U IN 8. Это создает удобства для вызывающего абонента, поскольку сводится к минимуму время, которое ему требуе тся на ожидание. Кроме того, минимизируется среднее время каждого вызова UIN 8 и обеспечивается более высокая пропускная способность вызовов при заданном уровне возможностей приема вызовов. После того как задача 31 закажет профиль абонента, переключательная задача 39 переключит программное управление на процедуру или программу для обработки затребованной операции. Если вызывающий абонент захочет обновить профиль абонента, выполняется процедура 40 обслуживания абонента, обсуждаемая ниже в связи с фиг.8. Если пользователь предпочтет принять обслуживание поискового вызова, выполняется процедура 41 обслуживания источника, обсуждаемая ниже в связи с фиг. 10. Если пользователь предпочтет выйти из UIN 8, выполняется программа 27 выхода. Программа 27 выхода может быть введена из переключательной задачи 39 или из множества други х задач, некоторые из которых обсуждались выше. В программе 27 задача 42 ставит на очередь команду "сеанс связи осуществлен" (Session Done) к собственному SIM 10 этого последнего абонента, идентифицированного выше в задаче 29 Определение этого собственного SIM 10 может быть успешно выполнено путем оценки ID этого абонента. Предпочтительно присваивать идентификаторы абонентам так, чтобы конкретное поле ID абонента (например, 4-10 биты) идентифицировало собственный SIM этого абонента Однако задача 42 опускается, если только она не является необходимой. Задача становится необходимой, если был заблокирован профиль абонента Как показано подробнее ниже, отправка команды Session Done к собственному SIM 10 позволяет этому собственному SIM 10 разблокировать запись 16 его абонента. После задачи 42 задача 43 проигрывает или другим способом отправляет соответствующее сообщение в канал 9. Это сообщение информирует вызывающего абонента о том, почему его сеанс (Session) завершается. Это соответствующее сообщение выбирается в ответ на задачу, выполнявшуюся до того, как программное управление было передано программе 43 "Выход". После задачи 43 задача 45 освобождает этот вызов, и процедура 20 останавливается Эта линия или канал 9 теперь могут использоваться другим вызывающим абонентом. На фиг. 8 показана блок-схема процедуры 40 "Обслуживание абонента". Процедура 40 позволяет абоненту исследовать и изменять обслуживание, которое активировано в настоящее время для него или для неё, включая и описание систем доставки. В этом предпочтительном варианте реализации это обслуживание может оказывать прямое влияние на расчетные счета этого абонента. Соответственно, принимаются меры безопасности, направленные на то, чтобы только этот абонент мог делать такие изменения. После ввода процедуры 40 программное управление переходит к процедуре 46 защиты для обеспечения защиты этого абонента. Вообще говоря, вызывающий абонент вынужден ввести код 33 защиты абонента прежде, чем сможет начаться процедура 40 На фиг. 9 показана блок-схема процедуры 46 "Защита". Процедура 46 собирает данные кода защиты от вызывающего абонента. Процедура 46 используется для сбора кода 33 защи ты абонента, обсуждавшегося вы ше, а также кода 34 защиты поискового вызова, и кодов игнорирования защиты поискового вызова (см. фиг, 4), обсуждающиеся ниже. Задача 47 собирает специфицированный код защиты от вызывающего абонента. Когда процедура 46 вызывается из проце 32539 дуры 40, этот специфицированный код является кодом 33 защиты абонента После задачи 47 задача 48 устана вли вае т специфициро ванный флаг, чтобы индицировать текущее, состояние и сбрасывает этот специфицированный флаг текущего состояния, чтобы индицировать неудавшуюся защиту Как указывалось выше, профиль абонента может быть принят, а может быть и не принят в то время, когда исполняется процедура 46 Соответственно, никакого определения в отношении того, что касается действительности или санкционирования этого специфицированного вызывающим абонентом кода защиты в процедуре 46 не производится Скорее, фоновая процедура 38, обсуждаемая ниже, разрешает эту проблему защиты должным образом Как показано на фиг 8, после процедуры 46 задача 49 собирает данные обслуживания от этого вызывающего абонента Задача 49 подсказывает вызывающему абоненту о видах обслуживания, на которое делаются запросы Вызывающий абонент идентифицирует эти виды обслуживания для узла UIN 8, а также значения или состояния, которые должны прилагаться к этому обслуживанию В качестве нелимитирующи х примеров вызывающий абонент может запросить, чтобы на поисковые вызовы для не го или для нее был наложен запрет, или вызывающий абонент может запросить активацию или деактивацию систем доставки, используемых при доставке поисковых вызовов После того как данные обслуживания будут собраны в задаче 49, опросная задача 50 определит, не запросил ли вызывающий абонентвыхода из процедуры 40 Если вызывающий абонент не запрашивал выхода из процедуры 40, задача 51 анализирует формат и содержание ответа вызывающего абонента, собранного в задаче 49 Если окажется, что этот ответ вызывающего абонента не действителен, опросная задача 52 возвратит программное управление обратно к задаче 49, чтобы этот вызывающий абонент мог снова попытаться предоставить действительные данные Конечно, специалисты в этой области техники понимают, что можно ввести дополни тельные задачи, определяющие, было ли np«=>Rbiшено число попыток или превзойден предел вре мени до передачи программного управления ібратно к задаче 49 и перехода программн >ru управления к программе 44 "Выход", например, fu ли такое число или предел были превышены Если задача 52 определяет, что данные, предоставленные вызывающим абонентом, оказались действительными, задача 53 собирает подтверждение от вызывающего абонента Предпочтительно, чтобы задача 53 подсказывала вызывающему абоненту с помощью эхо-сигнала этого ответа на запрос обслуживания, сделанный в задаче 49, чтобы вызывающий абонент мог прекратить этот запрос, если это обслуживание является не тем, что он или она ожидают Если этот запрос обслуживания не подтверждается, опросная задача 54 направляет программное управление обратно к задаче 49, чтобы вызывающий абонент мог представить данные альтернативного обслуживания Конечно, специалисты в этой области техники понимают, что можно ввести дополнительные задачи, определяющие, было ли превышено число попыток или превзойден предел времени до передачи программного управления обратно к задаче 49, и перехода программного управления к программе 44 "Выход", например, если такие числа или пределы были превышены Если вызывающий абонент подтвердит эти данные обслуживания в задачах 53-54, или если он запросит выхода в задаче 50, программное управление передается к задаче 55, в которой вызывающего абонента спрашивают, не желает ли он сделать другие изменения в записи этого абонента Если вызывающий абонент обозначит желание сделать дополнительные изменения, программное управление опять передается к задаче 49 Если вызывающий абонент укажет, что больше изменений не требуется, іогда программное управление переходит к опросной задаче 56 В этой точке UIN 8 завершил столько обработки, сколько было РОЗМОЖНО, без обращения к профилю абонента, запрошенному выше, в задаче 3 1 Соо тве тственно , за да ча 5 6 оцени вае т флаг текущего профиля для ID этого абонента, чтобы определить, не был ли уже принят этот профиль абонента Если этот профиль не был принят, опросная задача 57 проверяет таймер, определяя, следует ли ожидать дальше приема этого профиля абонента или отвергнуть попытки предоставления обслуживания для текущего идентифицированного абонента До тех пор, пока заданная длительность, начиная с момента пос тановки сигнала Get Profile в очередь, не истек ла, программное управление возвращается обратно к задаче 56 В течение времени, пока происходит зацикливание на задачах 56-57, UIN 8 может проиграть запись или сообщение к этому вызывающему абоненту, в котором рекомендуется, чтобы он воздержался от приема профиля абонента Когда эта заданная длительность истечет, программное управление возвратится обратно к программе 44 "Выход" Когда профиль абонента уже получен, Фоновая программа 38, обсуждаемая ниже, соответственно, регулируе т этот флаг текущего профиля, а также устанавли вает или сбрасывает флаг защиты абонента для указания того, является или нет код защиты, установленный абонентом выше, в задаче 47, действительным В предпочтительном осуществлении этот код является действительным, если он согласуется с кодом 33 защиты абонента этого профиля абонента Если задача 56 определит, что профиль был принят, а установленный абонентом код защиты недействителен, программное управление возвращается обратно, к программе 27 "Выход". Никаких изменений в ранее идентифицированном профиле абонента не разрешается С другой стороны, если задача 56 определит, что профиль абонента принят, и что вызывающий абонент установил действительный код защиты, задача 58 проиграет для вызывающего абонента соответствующее сообщение о приеме, а задача 49 поставит в очередь к распределительной сети 5 команду "обновления абонента" (Subscriber-Update) В частности, эта команда 9 32539 Subscriber-Update посылается из UIN 8 к ее контролирующему SIM 10. Из контролирующего SIM 10 она может быть передана к собственному SIM 10. Эта команда Subscriber-Update идентифицирует абонента, к которому эта команда относится, и позицию или позиции данных, которые обновляются, и новые значения или состояния, которые должны ассоциироваться с этими позициями. После задачи 49 программное управление выходит из процедуры 40 и возвращается к задаче 29, чтобы UIN 8 мог выполнять обслуживание других абонентов. На фиг. 10 показана блок-схема процедуры обслуживание источника 41. Процедура 41 вводится из задачи 39, обсуждавшейся выше, когда вызывающий абонент описывает характеристики связанного поисковым вызовом обслуживания. Процедура 41 выполняется после того, как вызывающий абонент идентифицирует абонента, для которого необходимо это, связанное с поисковым вызовом, обслуживание. В опросной задаче 59 процедура 41 определит, требуется ли код защиты поискового вызова до того, как UIN 8 сможет приступить к обслуживанию поискового вызова. Это определение может осуществляться в соответствии с рабочими правилами конкретного UIN 8, выполняющего задачу 59. Все узлы UIN 8 не должны принимать одинаковое решение в задаче 59. Если защита затребована, выполняется процедура защиты 46, обсуждавшаяся выше. В этой ситуации процедура 46 собирает код защиты поискового вызова от вызывающего абонента и устанавливает флаги так, что никакого обслуживания поискового вызова не будет предоставлено до тех пор, пока Фоновая процедура 38 не определит, что установленный вызывающим абонентом код поискового вызова согласуется с кодом защиты поискового вызова 34 из профиля этого абонента. После процедуры 23, или когда защита поискового вызова не затребована узлом UIN 8, задача 60 собирает данные обслуживания поискового вызова от вызывающего абонента. В частности, задача 60 делает подсказки вызывающему абоненту с помощью различных типов связанного с поисковым вызовом обслуживания, обеспечиваемого UIN 8. Такое обслуживание включает размещение поисковых вызовов у идентифицированного абонента, запрос состояния ранее размещенного поискового вызова и повторный поисковый вызов ранее размещенных вызовов у идентифицированного абонента. Затем вызывающий абонент реагирует, идентифицир уя один из типов такого обслуживания. Кроме того, задача 60 соответственно подсказывает и собирает данные, относящиеся к специфическому типу затребованного обслуживания. Например, если затребовано размещение поискового вызова, задача 60 может собирать сообщение, такое как номер телефона обратного вызова, набор алфавитно-цифровы х знаков для включения в этот поисковый вызов. Когда запрашивается состояние или повторный вызов, номер последовательности, который идентифицирует конкретный поисковый вызов, ранее размещенный у идентифицированного абонента, собирается задачей 60. После задачи 60 UIN 8 завершает столько обработки, сколько возможно, без обращений к профилю абонента, затребованному выше, в задаче 31 Соответственно, задача 61 оценивает флаг задержки профиля для ID этого абонента, чтобы определить, не был ли уже принят профиль этого абонента Если этот профиль не был принят, опросная задача 62 решает, надо ли ожидать дальше приема профиля этого абонента, или отвергнуть попытки обеспечения обслуживания для текущего, идентифицированного абонента До те х пор, пока заданная длительность от момента постановки на очередь команды Get-Profile, е ще не истекла, программное управление передается обратно, к задаче 61 Во время зацикливания на задачах 61-62 UIN 8 может проигрывать запись или сообщение к вызывающему абоненту, рекомендующее ему воздержаться от приема профиля абонента Если эта заданная длительность истечет раньше, чем будет принят профиль этого абонента, программное управление перейдет к программе выход 27. Если профиль этого абонента принят, фоновая процедура 38, обсужденная ниже, соответственно регулирует флаг текущего профиля и устанавливает или сбрасывает флаг защи ты поискового вызова для указания о том, является или нет код защиты, который может установить вызывающий абонент выше, в задаче 47, действительным Если задача 61 определит, что этот профиль был принят, а устанавливаемый вызывающим абонентом код защиты поискового вызова недействителен, программное управление переходит к программе 44 "Выход" Никакое, связанное с поисковым вызовом обслуживание этого идентифицированного абонента, не разрешается. С другой стороны, если задача 61 решит, что профиль абонента уже прибыл, и что обеспечиваемый вызывающим абонентом код защиты поискового вызова, если он имеется, согласуется с кодом защиты поискового вызова 34 профиля абонента, опросная задача 63 определит, запрашивал ли этот вызывающий абонент исследование поискового вызова Более того, если такое обслуживание запрашивалось, задача 63 проверяет профиль этого абонента, чтобы проконтролировать, что были активированы характеристики запрошенного исследования для этого абонента. Если такое обслуживание было запрошено, но не активировалось, то желательно, чтобы программное управление можно было направить (не показано) обратно к задаче 60, позволяя вызывающему абоненту запросить другое обслуживание. Если было запрошено и активировано обслуживание исследования поискового вызова, задача 64 ставит соответствующую команду Запроса к собственному SIM 10 это го абонента. После задачи 64 опросная задача 65 олределяет, был ли получен ответ на эту команду Запроса. Если задача 65 определит, что никакого ответа на эту команду запроса еще не было получено, опросная команда 66 решает, надо ли дальше ожидать приема ответа от собственного SIM 10 этого абонента, или отвергнуть попытку исполнить запрос этого абонента. До те х пор, пока заданная дли 10 32539 тепьность с момента постановки на очередь этой команды запроса еще не истекла, программное управление возвращается обратно, к задаче 65 Во время зацикливания по задачам 65-66 UIN 8 может проигрывать запись или сообщение к вызывающему абоненту, рекомендующее ему воздержаться от приема результатов этого запроса Если эта заданная длительность истечет до получения ответа на эту команду Запроса, программное управление переходит к программе выход 44 Когда задача 65 определит, что в U1N 8 получен ответ на эту команду Запроса, задача 67 выдаст этот ответ вызывающему абоненту На запрос состояния, предварительно записанное сообщение может информировать вызывающего абонента о текущем состоянии идентифицированного поискового вызова На запрос поискового вызова, сообщение этого идентифицированного поискового вызова может выдать дату и время вызывающему абоненту После задачи 67 программное управление выходит из процедуры 41 и возвращается к задаче 29, чтобы позволить вызывающему абоненту запросить обслуживание для другого абонента Возвращаясь к задаче 63 процедуры 41, когда было определено, что вызывающий абонент запрашивал размещение поискового вызова, программное управление переходит к процедуре источника На фиг 11 представлена блоксхема процедуры 68 После ввода процедуры 68, задача 69 собирает подтверждение о поисковом вызове, доставка которого была запрошена вызы ва ющим а боне н том Же ла те льно , чтобы задача 69 могла подтверждать эхо-сигналом любое сообщение, которое должно быть доставлено этим поисковым вызовом Задача 69 может дополнительно информировать вызывающего абонента об активных в настоящее время системах доставки и о других операциях обслуживания, которые осуществляют доставку этого поискового вызова Например, вызывающий абонент может информироваться о том где находится поисковый вызов, который должен доставляться, или о том, будет ли наложен запрет на этот поисковый вызов для доставки его позднее этому абоненту Вызывающий абонент может подтвердить параметры поискового вызова и доставки, отвергнуть этот поисковый вызов (не показано), или послать запрос об игнорировании некоторого специфицированного параметра доставки, такого как система доставки После того, как данные подтверждения будут собраны в задаче 69, опросная задача 70 определит, запрашивал ли вызывающий абонент игнорирования параметра доставки Такое игнорирование параметров доставки может повлиять на расчетные счета абонента и на правдоподобие успешно доставленных поисковых вызовов Соответственно, вызывающий абонент должен соблюдать меры безопасности, чтобы такое игнорирование было принято узлом UIN 8 и распределительной сетью 5 Если запрошено игнорирование параметра, процедура 1100 выполняет процедуру защиты 46 в отношении этого специфического обслуживания (см фиг 5), которую запрашивал вызывающий абонент Процедура 46 потребует от вызывающе го абонента представить код игнорирования, который должен быть согласован с соответствующим кодом игнорирования, записанным в профиле этого абонента, прежде чем это игнорирование будет разрешено Специалисты в этой области те хники согласятся, что тем, кто выбирает коды абонента, поисковый вызов и коды игнорирования зашиты, должен быть именно этот абонент Соответственно, широкой публике не известны такие коды, и посторонний человек не может помешать работе абонента распределительной сети 5 С другой стороны, когда абонент желает, чтобы определенные люди, такие как секретари, супруги и т п могли оказывать влияние на выбранные оператором действиясети 5, это т оператор может установить коды защиты, которые позволяют этим людям оказывать такое влияние Конечно, ничто не мешает абоненту установить все коды защиты на одинаковое или разные значения После процедуры 46 задача 71 собирает любые данные, которые соответствуют этому запрошенному игнорированию Например, если вызывающий абонент запрашивает доставку поискового вызова по адресу, отличающемуся от того, что указан в профиле абонента, тогда задача 71 собирает данные этого, отличающегося адреса После задачи 71, или если никакого игнорирования не запрошено, программное управление переходит к опросной задаче 72 Когда исполняется задача 72, профиль абонента уже получен, так как выход из задачи 71 (см фиг 10) был задержан до момента получения профиля абонента Тем не менее, в задаче 72 программное управление ожидает, пока не будет разрешено любое игнорирование защиты Так как вопрос о действительности игнорирования защиты решае тся в фоновом режиме работы, он может быть не решен ко времени, когда выполняется задача 72 Соответственно, когда вопрос об игнорировании защиты задерживается, программное управление возвращается обратно, к задаче 72 Если вопрос о действительности кода игнорирования защиты был решен, и этот код был сочтен недействительным, программное управление выходит из процедуры 46 и переходит к программе Выход 44 Если вопрос об игнорировании защиты был решен и этот код был сочтен действительным, процедура 68 выполняет задачу 73 Задача 73 ставит этот поисковый вызов в очередь на передачу к одному или более узлов PTN 6, команда Page Hold не активна Этот поисковый вызов содержит номер последовательности поискового вызова, полученный из профиля абонента, адрес PTN 6 любой системы 2 доставки, через которую должен направляться этот поисковый вызов, ID этого абонента и любое сообщение, передаваемое этим поисковым вызовом Определение того факта, является ли обслуживание удержание "вызова" (Page Hold) активным, производится путем проверки профиля этого абонента Определение узла (узлов) PTN к которому должны посылаться эти поисковые вызовы, также осуществляется путем проверки профиля абонента В частности, активированные системы доставки профиля этого абонента должны использоваться 11 32539 для доставки этого поискового вызова. Задача 73 может проконсультироваться с таблицей в памяти UIN 8 , чтобы перевести эти адреса в адреса узлов PTN б, которые используются для маршрутизации поисковых вызовов. После задачи 73 задача 74 ставит этот поисковый вызов в очередь для доставки к собственному SIM 10 этого абонента. Этот собственный SIM 10 идентифицируе тся путем оценки ID этого абонента. Когда этот поисковый вызов направляется к собственному SIM 10 абонента, он содержит значение последовательности, полученное из профиля абонента, адрес этого собственного SIM 10, ID абонента и любое сообщение, передаваемое этим поисковым вызовом Последний дополнительно информирует собственный SIM 10 о том, что этот поисковый вызов был принят сетью 5, а также об идентификации этого узла (узлов) PTN и идентификации адреса (адресов) системы (систем) доставки и адреса (адресов) доставки, к которым этот поисковый вызов был послан. После задачи 74 задача 75 определяет, активировано пи обслуживание подтверждения состояния путем проверки профиля этого абонента. Если это обслуживание активировано, то вызывающему абоненту представляется значение последовательности. В процессе работы задач 63-67 вызывающий абонент может вызвать любой U1N 8 в окружении 1, а позднее запросить состояние этого поискового вызова. Вызывающий абонент должен представить значение этой последовательности, чтобы распределительная сеть 5 могла идентифицировать поисковый вызов, состояние которого запрашивается. После задачи 75 программное управление выходит из процедуры 68 и возвращается к задаче 29, чтобы позволить вызывающему абоненту запросить дополнительное обслуживание, относящееся к другому абоненту. На фиг. 12 показана блок-схема фоновой процедуры 38. UIN 8 выполняет процедуру 38 в фоновом режиме. Другими словами, процедура 38 непрерывно действуе т, даже если выполняются другие, задачи, не относящиеся к процедуре 38, в общем, в одном и том же временном кадре. Процедура 38 выполняет задачу 76 обработки очереди на выходе и задачу 77 обработки очереди на вход. Др угими словами, команды, установленные в очередь для передачи к др угим узлам по сети связи 11, пере сылаются в свое время в рез ульта те рабо ты задачи 76, а данные сообщений, принятых от др уги х узлов сети связи 11, получаются благодаря действию задачи 11. Специалисты в этой области техники согласятся, что отправка любой команды любым объектом в окружении 1, будь то UIN 8 или др угое устройство, может включать в себя ожидание приема сообщения соответствующего подтверждения. Если в течение заданного периода времени подтверждения не получено, то это сообщение может бы ть по вторено . По добно этом у, прием любого сообщения может включать передачу соответствующе го сообщения подтверждения в ответ на это принятое сообщение. Такие детали, понятные специалистам в этой области техники, включены в объем задач 76-77, и далее здесь не обсуждаются. После задач 76-77 опросная задача 78 определяет, установлен ли любой профиль или флаги текущего состояния в том, что относится к любому, ранее принятому в задаче 77 профилю. Если ни одного такого флага не установлено, программное управление возвращается обратно к задаче 76 для продолжения обработки входной и выходной очередей. Если флаг текущего состояния установлен, что является нормальной ситуацией непосредственно после того, как принят профиль абонента, программное управление переходит к опросной задаче 79. Задача 79 определяет, установлен ли флаг защиты текущего состояния абонента. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код защиты абонента. Если этот флаг установлен, то программное управление переходит к процедуре оценки 80 Если нет, то задача 81 определяет, установлен ли флаг текущего поискового вызова. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код защиты поискового вызова. Если это т флаг установлен, то программное управление переходит к процедуре оценки 80. Если нет, то опросная задача 82 определяет, установлен ли флаг игнорирования текуще го состояния. Этот флаг устанавливается всякий раз, когда вызывающий абонент ввел код игнорирования защиты. Если это т флаг установлен, то программное управление переходит к процедуре оценки 80. Если нет, задача 83 сбрасывает этот флаг текущего профиля для про филя рассматриваемого вызывающего абонента, и программное управление переходит обратно к задаче 76. Процедура оценки 80 определяет, является ли указанный код защиты, введенный вызывающим абонентом, действительным. В частности, опросная задача 84 сравнивает этот, введенный вызывающим абонентом код защиты, с соответствующими кодами защиты, включенными в про фи ль это го вызы вающе го а боне н та (см . фи г. 3-5 ) . Если это т, введенный вызывающим абонентом, код и коды профиля абонента со гласованы или каким-то образом соотве тствуют друг др угу, тогда этот вве денный вызывающим абонентом код, счи тае тся действите льным и задача 85 устана вливае т это т специ фицированный флаг за щи ты для индикации действительного кода за щи ты . Если это т, введенный вызы вающим а бонен том код и коды про филя абонента не соотве тствуют др уг др угу, то это т вве денный вызы вающим абонентом код считае тся недей стви те льным. За дача 86 сбра сывае т этот спец и фициро ванный фла г защи ты , если необ хо димо, чтобы индициро ва ть недействи тельный код за щи ты . После задач 85 или 86 задача 87 сбрасывает это т специ фициро ванный фла г за щи ты тек уще го состоя ния для индикации то го , что эта специфициро ванная функция защиты теперь решена. Контроль над этими фла гами тек уще го состояния и защи ты осуществляе тся, как описано вы ше , в связи с задачами 56; 61 и 62. После задачи 87 программное управление переходи т к задачам 81, 82 или 63 , как указано на фиг. 12 . 12 32539 На графиках фиг. 13-22 показаны блок-схе* мы процедур, выполняемых узлами распределительной сети 5. Как указывалось выше, основной, объем интеллекта, связанный с маршрутизацией поисковых вызовов и обеспечением программного обслуживания абонента и источника вызова настоящего изобретения, сосредоточен в узлах UIN 8. Так, процедуры, выполняемые узлами распределительной сети 5, обычно обеспечивают вышеописанные процедуры, выполняемые узлами UIN 8. Специалисты в этой области техники согласятся, что в предпочтительных вариантах реализации настоящего изобретения процедуры, показанные на фиг. 13-22, осуществляются компьютеризованным оборудованием под управлением компьютерных программ, записанных в памяти этого оборудования. Более того, специалисты в этой области техники знают, что эти процедуры предпочтительно являются повторно используемыми. На фиг. 13 показана команда Get Profile процедуры 88, выполняемая SIM 10. действующим в качестве контролирующего узла SIM для UIN 8 В частности, процедура 88 выполняется, когда SIM 10 принимает команду Get Profile от UIN 8 в задаче 31, описанной выше. Команда содержит ID абонента и предписывает, либо заблокировать запись 16 этого абонента в собственной базе данных 13 абонента, либо возвратить номер последовательности в UIN 8, пославший эту команду Get Profile, как обсуждалось выше, в связи с задачей 31 Процедура 88 выполняет опросную задачу 89 определения того факта, действительно ли.ID абонента, переданный командой Get Profile, представляет ID локального абонента. Другими словами, задача 89 определяет, считает ли абонент, профиль которого запрашивается, что SIM 10 является его . или её собственным узлом SIM. Это определение может быть сделано путем оценки Ю абонента, в котором указан собственный SIM 10 этого абонента. Если задача 89 определяет, что SIM 10, выполняющий процедуру 88, является собственным SIM 10, то задача 90 просматривает абонентскую запись 16 этого. идентифицированного абонента в его собственной базе данных 13 и отсылает профиль этого абонента обратно, к локальному UIN 8, в соответствии с параметрами команды Get Profile Задача 90 также блокирует профиль этого абонента или включает номер последовательности в профиль этого абонента, отправляемый обратно, к локальному UIN 8. После задачи 90 программное управление выходит из процедуры 88. Если задача 89 определяет, что абонент, профиль которого запрашивается, не является локальным абонентом, то опросная задача 91 определяет, не зарегистрирован ли в настоящее время этот абонент, в качестве постороннего абонента SIM 10, выполняющего процедуру 88. Абонент считается посторонним абонентом, если он имеет запись постороннего абонента для этого идентифицированного абонента в его собственной базе данных 14 посторонних абонентов. Если он или она не зарегистрированы как посторонние абоненты, то задача 92 форматируе т и отправляет команду "запроса профиля" (Pro file Request) к собственному SIM этого абонента. Если он или она зарегистрированы в качестве посторонне го абонен та , задача 93 форма тир уе т и • отправляет команду "обновления профиля" (Profile-Update) к собственному SIM 10 После задач 92 и 93 эта команда будет отправлена к собственному SIM 10 этого абонента, а программное управление выйдет из процедуры 88. Команда Profile-Request идентифицирует контролирующий SIM 10, запрашивающий этот профиль и ID абонента, для которого делается этот запрос Команда Profile-Update идентифицирует контролирующий SIM 10, запросивший обновление этого профиля, ID абонента, для которого делается запрос и суммирующий элемент данных. Обе эти команды Profile-Request и Profile-Update устанавливают, надо ли заблокировать запись 16 этого абонента в собственном SIM 10 или возвратить номер последовательности. Команда Profile-Request запрашивает SIM 10, чтобы он выдал полный профиль абонента, который является поднабором полной записи 16 абонента. Номер 316 последовательности включается в профиль этого абонента, если команда Profile-Request требует, чтобы он был включен. Этот профиль абонента может потребовать передачи относительно большого объема данных. С другой стороны, команда Profile Update запрашивает собственный SIM 10, чтобы он проверил, действителен ли все еще профиль абонента, хранящийся в настоящее время в контролирующем SIM 10 базы данных посторонних абонентов. Чтобы определить, действителен ли этот профиль, некоторый вид суммирующи х данных посылается к этому собственному SIM 10 Этими суммирующими данными может быть контрольная сумма этого профиля абонента, исключая любые номера 316 последовательности. Или в качестве альтернативы, это может быть другой тип кода обнаружения ошибки, такой как контроль циклическим избыточным кодом. В другом вариан те реализации изобре тения эти сумми1 р ующие данные формируют дату или дату и штамп времени, который указывает последнее время, когда этот профиль абонента обновлялся. Если собственный S1M 10 определяет, путем оценки этих суммарных данных, что профиль абонента, хранящийся в собственном SIM 10 этого абонента, не изменился по сравнению с профилем абонента, хранящимся в базе данных 14 посторонних абонентов контролирующего SIM 15, тогда сети связи 11 не нужно передавать профиль этого абонента обратно, к этому контролирующему SIM 10, и ресурсы сети не занимаются. На фиг. 14 показана блок-схема команды "отве тного сообщения о про филе" (Pro fileResponse) процедуры 94. Процедура 94 выполняется контролирующим SIM 10, когда он принимает ответ от собственного SIM 10 на команды, •посланные выше в связи с задачами 92 или 93. Задача 95 определяет, является ли ответное сообщение, принятое SIM 10, ответом верификации или профилем абонента. Ответ верификации есть короткая коммуникация, которая информирует контролирующий SIM 10, что специфицированная запись а бонен та в его базе данн ы х 14 13 32539 посторонних абонентов содержит текущий профиль абонента. Этот ответ верификации предпочтительно содержит ID абонента для идентификации этого абонента, о котором был сделан запрос, и обсуждавшийся выше номер 316 последовательности Этот профиль последовательности может сохраняться в профиле абонента в базе данных 14 посторонних абонентов Если обнаружен этот запрос верификации, выполняется задача 96, отправка профиля абонента из базы данных 14 посторонних абонентов к локальному UIN 8 Если этот запрос верификации в задаче 95 не обнаружен, выполняется задача 96 сохранения профиля абонента в базе данных 14 посторонних абонентов этого SIM. После задачи 97 выполняется задача 96 отправки профиля этого абонента к локальному UIN 8. После задачи 96 программное управление выходит из процедуры 95 На фиг. 15 показана команда "обновления абонента" (Subscriber-Update) процедуры 98. Процедура 98 выполняется контролирующим SIM 10, когда он принимает команду SubscriberUpdate от UIN 8. Команда Subscriber-Update идентифицирует абонента, к которому относится эта команда, и передает позицию или позиции данных, которые обновляются, и новые значения или состояния, которые должны ассоциироваться с этими позициями Эта команда SubscriberUpdate передается UIN 8 во время задачи 58 Процедура 98 выполняет опросную задачу 99 определения то го факта , я вляе тся ли это т идентифицированный абонент локальным або нентом. Если этот абонент - локальный, задача 100 обновляет позиции соответствующи х данных в собственной базе данны х 13 и осуществляе т рециркуляцию элемента 35 суммарных данных для того, чтобы отразить это т обновленный про филь данных. Кроме того, задача 100 разблоки рует запись 16 этого абонента путем изменения позиции 36 данных о ней. После задачи 100 прог раммное управление выходи т из процедуры 98. Если задача 99 определяет, что этот абонент не является локальным абонентом, она посылае т команду Subscriber-Upda te к собственном у SIM 10 абонента в задаче 101 Кроме того, она обнов ляет соответствующие позиции данных, включая элемент 35 суммарных данных в ее базе данных 14 посторонни х абоненто в в задаче 102. Ко гда собственный SIM 10 примет эту команду, он бу дет выполнять свою собственную версию проце дуры 98. После задачи 101-102 программное уп равление переходит к процедуре 98 На фиг. 16 показана блок-схема команды "запроса профиля" (Profile-Request) процедуры 103 Процедура 103 выполняется собственным SIM 10, когда он принимает команду ProfileRequest от любого контролирующего SIM 10, входящего в окружение 1. Команда Profile-Request идентифицирует абонента, к которому эта команда прикладывается, она определяет, надо ли заблокировать профиль этого абонента, или возвратить номер последовательности, и идентифицируе т контролирующий SIM, которому должен быть послан ответ на эту команду. Эта команда Profile-Request передается управляющим SIM 10 во время задачи 92, обсуждавшейся выше. Процедура 103 выполняет задачу 104 получения профиля абонента от собственной базы данных 13 Как указывалось выше, профиль абонента предпочтительно является поднабором всех позиций данных, хранящихся в записи 16 абонента После задачи 104, задача 105 проверяет позицию 36 данных с целью определить, не заблокирована ли запись этого абонента Если в текущий момент запись 16 заблокирована, задача 105 ожидает момента, когда запись 16 будет разблокирована (не показано). Поисковые вызовы снабжены номерами 37 последовательности, как обсуждено выше, чтобы их можно было индивидуально идентифицировать после приема их распределительной сетью 5. Номера 37 последовательности контролируются в собственных узлах SIM, исключающи х возможность дублирования этих номеров последовательности Если команда Profile-Request инструктир ует собственный SIM 10 включи ть номер 37 последовательности, задача 105 включает номер 37 последовательности в профиль абонента. Затем задача 105 посылает этот профиль к запросившему SIM 10 в форме команды ProfileResponse, обсуждавшейся выше, в связи с фиг. 14 Задача 105 может также сделать приращение или по-другому изменить номер последовательности позиции 37 данных, так чтобы новый номер последовательности стал сразу же доступен. От контролирующего SIM 10, принявшего профиль, этот профиль направляется к UIN 8, как обсуждалось выше, в связи с процедурой 95 После задачи 105 выполняется задача 106 определения, инструктировала ли команда Profile-Request собственный SIM 10 заблокировать запись 16 этого абонента Если такой запрос был сделан, задача 106 установит элемент 36 данных записи 16 абонента с целью указаний того, что запись 16 этого абонента теперь заблокирована Кроме того, может быть установлен таймер, чтобы -эта запись 16 абонента автоматически разблокировалась по истечении определенного интервала времени. За счет этого исключается возможность в случае сбоя в работе UIN 8 создавать помехи для способности други х UIN 8 использовать распределительную сеть 5. До те х пор, пока запись 16 остается заблокированной, поисковые вызовы не могут бы ть размещены. Как указывалось выше, запись 16 остается заблокированной все время, пока производится обновление профиля абонента Благодаря этому предотвращается размещение поисковых вызовов в соответствии с устаревшей записью абонента. После подачи 106 программное управление выходит из процедуры 103. ' На фиг. 17 показана блок-схема команды Profile-Update процедуры 107 Процедура 107 выполняется собственным SIM 10, когда он принимает команду Profile-Update от любого контролирующего SIM 10 в окружении 1. Команда ProfileUpdate идентифицирует абонента, к которому относится эта команда, идентифицирует управляющий SIM 10, к которому должен посылаться ответ на эту команду, инструктирует собственный SIM 10, чтобы он либо заблокировал запись 16 этого абонента, либо включил номер 3 7 по сле дова 14 32539 тельности в возвращаемый ответ и включает суммирующие данные Команда Profile-Update передается контролирующим SIM 10 во время задачи 91, обсуждавшейся выше Процедура 107 выполняет задачу 108 ожидания события, когда запись 16 этого идентифицированного абонента будет разблокирована. Задача 108 может определить, заблокирована ли запись 16 в результате оценки позиции 36 данных в записи 16 этого абонента Более часто записи 16 абонента в задаче 108 разблокированы и существенных потерь времени не имеет места. Однако, если во время, когда осуществляется обновление абонента, принимается команда Profile-Update, программное управление не выйдет из задачи 108 до тех пор, пока эта запись не будет разблокирована. Эта затійсь может разблокироваться, как указано выше, в связи с задачей 100 После задачи 108 опросная задача 109 определяет, соответствуют ли, или другим образом согласуются ли суммарные данные, принятые с этой командой Profile-Update, с суммарными данными 35, включенными в запись 16 этого абонента в собственной базе данных 13 для этого идентифицированного абонента Если эти суммарные данные соответствуют, задача 110 форматирует и отправляет команду Profile-Response верификации обратно, запросившему SIM 10 Эта команда Profile-Response содержит ID этого абонента. Она также содержит номер последовательности из позиции 37 данных, если была проинструктирована командой Profile- Update, чтобы сделать это Принимающий SIM 10 обрабатывает эту команду Profile-Update в процедуре 107, обсуждавшейся выше. Если задача 109 определяет, что суммарные данные не соответствуют, задача 111 форматируе т и о тправляе т это т полный про филь абонента, который является поднабором записи 16, к затребо ванному в команде ProfileR es po ns e SIM 1 0 . Э та к ом ан да Pro fi le Response также содержит номер последовательности из позиции 37 данных, если была инстр укция сдела ть это в команде Pro fHeUpdate. После задачи 110 или 11" выполняется задача 112 определения, инстр ук тиро вала ли команда Profile-Request собственный SIM 10 заблокировать запись 16 этого абонента. Если такой запрос был, задача 112 устано ви т элемент 36 данных записи 16 абонента для указания того, что запись 16 этого абонента теперь заблокирована. После задачи 112 программное упра вление вы ходи т из процедуры 107. На фиг. 18 показана блок-схема команды . Session-Done процедуры 113. Процедура 113 выполняется собственным SIM 10, когда он принимает команду Session-Done от любого UIN 8 в окружении 1. Эта команда идентифицирует абонента, к которому подается эта команда, и означает, что этим абонентом не было принято никаких изменений. Команда Session-Done передается узлом UIN 8 во время задачи 42, обсуждавшейся выше. Процедура t13 выполняет задачу 114 разблокирования записи 16 идентифицированного абонента путем изменения позиции 36 данных в ней. Э то разблокиро вание поз воляе т в буду щем использовать запись 16. После задачи 114 программное управление выходит из процедуры 113. На фиг 19 показана блок-схема команды "поисковый вызов" (Page) процедуры 115. Процедура 115 выполняется собственным SIM 10, когда.он принимает команду Page от любого UIN 8 в окружении 1. Эта команда идентифицирует абонента, к которому эта команда прикладывается, идентифицирует номер последовательности, ассоциированный с этой страницей, и в случае необходимости может содержать сообщение. Команда Page передается UIN 8 как результат задачи 74, обсуждавшейся выше. Процедура 115 выполняет задачу 116 сохранения любого сообщения, ассоциированного с этим поисковым вызовом, в соответствующей ячейке памяти собственной базы данных 13 и устанавли вает канал записи 16 абонента для идентификации таблицы активности, которая используется для хранения данных этого поискового вызова. Кроме того, состояние этого поискового вызова может обновляться в таблице активности, отражающей факт приема этого поискового вызова собственным SIM 10. После задачи 116 программное управление выходит из процедуры 115. На фиг 20 показана блок-схема команды Inquiry процедуры 117. Процедура 117 выполняется собственным SIM 10, когда он примет команду Inquiry от любого UIN 8 в окружении 1. Команда Inquiry идентифицирует абонента, к которому относится эта команда, UIN 8, к которому должен быть послан ответ, и номер последовательности, который идентифицирует отдельный поисковый вызов. Эта команда Inquiry передается UIN 8 как результат задачи 64, описанной выше. Процедура 117 выполняет задачу 118 просмотра поискового вызова, указанного в таблице активности абонента. Затем задача 119 отправляет состояние или поисковый вызов, ассоциированные с этим номером последовательности, в зависимости от типа команды запроса, обратно, к запросившему UIN 8. После задачи 119 программное управление выходит из процедуры 117. На фиг 21 показана блок-схема команды "обновление состояния" Status-Update процедуры 120. Процедура 120 выполняется собственным SIM 10, когда он примет команду StatusUpdate от любого узла в окружении 1, и в частности, от PTN 6. Команда Status-Update содержит информацию, которая позволяет проследить ход процесса доставки поискового вызова. Соответственно, PTN 6 может отправить одну команду Status-Update, когда он примет поисковый вызов от UIN 8, другую, когда он передаст этот поисковый вызов к указанной системе 2 доставки, и еще одну, когда указанная система 2 доставки проинформирует, что она доставила этот поисковый вызов. Команда Status-Update содержит данные, идентифицирующие абонента, которому адресована эта команда, номер последовательности поискового вызова, к которому относится эта информация обновления, и данные, идентифицирующие тек ущее состояние этого поискового вызова. Процедура 120 выполняет задачу 121 просмотра этого указанного поискового вызова в таблице акти вности абонен та. Кроме 15 32539 того, задача 121 модифицирует эти данные состояния, ассоциированные с указанным поисковым вызовом, в соответствии с данными, переданными командой Status-Update. После задачи 121 программное управление выходит из проце дуры 120. На фиг. 22 показана блок-схема процедуры 122 PTN 2-"поисковый вызов принят" (РадеReceved). Процедура 122 выполняется узлом PTN б, когда он примет поисковый вызов от UIN 8 для доставки через одну из е го подсистем, если таковая имеется. Процедура 122 выполняется в ответ на команду, посланную UIN 8 в соответст вии с исполнением задачи 73, обсуждавшей ся выше. Задача 123 форматирует этот поисковый вызов и стави т его в очередь для доставки с по мощью системы 2 доста вки , указанной в этом поисковом вызове. Этот поисковый вызов не дол жен доставляться немедленно. Скорее, узлы PTN могут собирать поисковые вызовы для дос тавки к нижестоящим системам 2 доставки эффективным образом. После задачи 123, зада ча 124 может форматиро ва ть и о тправля ть ко манду Status-Update к собственному SIM 10 этого поискового вызова . Ничто не требуе т о т PTN 6 немедленной отправки команды Status-Update . Фактически, PTN 6 предпочтительно ожидает по лучения подтверждения от системы доставки 2, прежде чем снять с очереди поисковый вызов и отправить команду Status-Update к собственному SIM 10. После задачи 124 программное управле ние выходит из процедуры 122. Резюмируя, настоящее изобретение обеспечивает улучшенный способ доставки поисковых вызовов. Настоящее изобретение обеспечивает операции множественной доставки поисковых вызовов. Соответственно, для отдельной системы не требуется иметь емкость, могущую покрывать исключительно большой регион. Более того, отдельные поисковые вызовы могут доставляться системами, такими как каналы ВЧсвязи или компьютерные сети. Кроме то го, нас тоящее изобретение обеспечивает распределенную систему, с мощностью обработки, сконцентрированной в удаленных пунктах UIN, Благодаря распределению мощности обработки эта общая сеть не отказывает при отказе любого индивидуального компонента, стоимость оборудования равномерно распределена по этой сети, ресурсы сети сохраняются, а общая скорость приема и доставки поисковых вызовов повышается. Более того, стоимости систем электросвязи снижены по сравнению с централизованной системой, потому что передачи сообщений осуществляются ближайшими узлами. Настоящее изобретение было описано ваше со ссылками на предпочтительные варианты реализации изобретения. Однако специалисты в этой области техники согласятся, что в этих предпочтительных вариантах реализации могут быть сделаны изменения и модификации, не выходя за пределы объема настоящего изобретения. Например, специалисты в этой области техники должны оценить гибкость настоящего изобретения Команды, обсуждавшиеся выше, как направляемые от первого узла, такого как UIN, ко второму узлу, такому как контролирующий SIM, и затем к третьему узлу, такому как собственный SIM, могут быть посланы в режиме ретрансляции от этого первого узла, или могут быть посланы в последовательных сообщениях из этого первого узла. Кроме того, элементы данных, рассмотренные выше, могут счита ться минимальным набором элементов данных. Специалисты в этой области те хники согласятся, что дополнительные данные могли бы быть полезны для различных конкретных вариантов реализации настоящего изобретения. Например, дата и штамп времени часто записываются с различными позициями данных в подобных системах. Эти и другие изменения и модификации, которые очевидны для специалистов в этой области техники, могут быть включены в объем настоящего изобретения. 16 212539 Фиг. 1 10 /_ ± узел управления информацией абонента (SIM) 12 12 смстви а достав ші узел управления сетью ії коммутационная сеть оконечный ум л ПОМПОВОГО вылом узел упр авле ни я инфор маци ей абоне нта (SI M) 10, узел упр авле ния инфор маци ей абоне нта (SI M) оконечный уз«п ♦+ снспмм достввкм ПОИСКО ВОГ О вызова система дос тае т Фиг. 2 17 си ст*м> достав Г 32539 к • 32— запись абонента ID абонента 5— запись абонента 16 запись абонента 32- ID абонента онента 33- код защиты абонента онента 34- код защиты поиск, вызова нента 3 7 - следующий номер последовательности 3 7 а связь с таблицей активности абонента а а 18- связь с таблицей обслуживания абонента 35- суммарные данные профиля абонента • 36- блокировка м Л • другие I 13 Фиг. 3 17 таблица обслуживания абонента обслуживание обслуживание аігтивно адрес системы игнорирование разрешено система доставки 1 19 • • • система доставки N поддержание связи архив подтверждение статуса другие Фиг. 4 таблица активности абонента номер последовательности состояние СВЯЗЬ С ПОИСКОВЫМ вызовом • • • Фиг. 5 18 код игнорирования 32539 прием запроса источника 2i\ 23 требуется запрос источника собрать данные адреса завершения от вызывающего абонента собрать данные опции обслуживания от вызывающего абонента \ 7 30 запросить профиль абонента от сети; ус тановить флаг текущего профиля; установить все флаги защиты \ 31 включить выбранное обслуживание і •^проигра ть соотве тствующее сообщение для ис точника бслуживани е источника 42 поставить команду ^на очередь к собственному SIM, если необходимо 43 45 v освободить вызов 1 Г Г стоп J Фиг. 6 19 I 32539 23 санкционировать источник источник 10 в сети PSTN hfphtify b fjcnegty собрать данные источника ID источник санкционирован источник ю от сети PSTN или предел попыток превышен Фиг. 7 20 программы 32539 следующий I абонент I обслуживание абонента^ 46 sjаутентификация (абонента) собрать данные обслуживания запрос на выход имеется? анализ формата и содержимого ответа запрос действителен? поставить команду обновления абонента принятия запроса проиграть сообщение принятия запроса защита действительна 58 29 вызов подтвержден еще одно изменение 55 профиль абонента ожидание получения профиля не действительна 57 Фиг. 8 21 32539 46, защита \ собрать данные спвцифи-47 \ Щфоминого кода защ иты 48. 7 • установ и ть специф ициро ванный ф лаг тек ущей з ащи ты; • сбр оси ть специф ициро ванный ф лаг з ащи ты Фиг. 9 41 '^об сл ужи в ани е и сточни к» защи та ^(об сл ужи в ани е поиск , вызов а) обсл ужив ание поиск , вызо треб ует защи ты \ соб р ать данны е / о б сл ужи в ани я Л пои ск , в ызо в а / OU постави ть ком анд у з апро са на очер едь к 68 отв ет с инф ормаци ей остояния пр иня т? подач а о тв ета с инф ормацией со стояния 44 собств енном у (SIM) Фиг. 10 22 32539 68 источник поиск, вызова Л собрать данные подтверждения 7 собрать данные игнорирования защита (игнорирование) игнорирован запрошено? 69 текущий недействительное игнорирование действительное игнорирование если нет запрета, поставить поис. вызов на очередь к оконечн. узлу поиск, вызова 74' 73 поставить поис вызов на очередь к собственному SIM если состояние подтверждения активно, проиграть значение 75 следующий абонент Фиг. 11 23 ♦(выход 32539 38 фоновая задача обработа ть очередь на выход пере уста новить те кущий 76 поста вить принятые сообщения в очередь на выход текущий флаг установлен и профиль принят? текущая за щита абонента имеется? код аутентификации действителе н? сбросить специфицирова нный флаг аутентификации ус тановить специф ицированный флаг аутентификации фла г профиля 83 N сбросить специфицированный текущий флаг аутентифика ции текущая защит а пои ск. процесс проверки {сообщения) вызова имеется? OVERRID E SC R EEN PENDING 80 пр оцесс пр оверки (игнор ирования ) 80 82 Фиг. 12 24 87 \j 88 32539 к ома нда ^ V GET-PROFILE 96 передача профиля абонента к UIN ID локального абонента абонент зарегистри рован как локальный? передача команды обновления профиля к собственному SIW! \ 93 передача команды запроса профиля к собственному SIM 92 с Фиг. 13 команда PROFIL ERESPONSE N сохранить в базе данных посторонних абонентов передать профиль к UIN Фиг. 14 25 95 97 96 32539 98 команда SUBSCRIBER-UPDDATE 100 / обновить базу данных собственного абонента; пересчитать суммарные данные; разблокировать записи ID локального абонента получен? 99 101 ID локального абонента получен? 102 обновить базу данных собственного абонента Фиг. 15 103 команда PROFILE-REQEST 1 получить профиль абонента из собс твенной базы данных 104 105 ес ли не заблокировано, отправить профиль к запрос ившему S IM, как команду PROFILE -RESPONSE; включить номер последовательнос ти, если в команде PROFILE -RE QEST ес ть инс трук ция, требующая сделать э то 1 заблокировать запись абонента, если в команде PROFILE-RE QEST ес ть инс трукция сделать э то Фиг. 16 26 .106 щ 32539 с команда PROFILE-UPDATE ожидать, пока запись абонента не буде т 108 суммарные данные соотве тс твуют? разблокирована отправка пол ного профиля абонента в команде PROFILE-RESPONSE; включает номер последовател ьнос ти, есл и ес ть инс трукция сделать э то в команде PROFILE-UPDATE отправка ве риф ицирова нной команды PROFILE-RESPONSE; вкл ючае т номе р последовательности, если есть инструкция сделать э то в команде PROFILE-UPDATE I блокировка записи абонента, если есть за прос сделать э то в команде PROFILE-REQUEST 112 Фиг. 17 1V 1Мкої команда SESSION DONE] разбл окирова ть за пис ь абоне нта Фиг. 18 114 27 32539 117 команда INQUIRY J 118 119 116 сохранить поиск, вызов и связь в собственной базе * найти номер последовательности, состояние, сообщение отправить к запросившему UNI (выходу Фиг. 19 Фиг. 20 / --------------------\/122 / процедура PTN Y \PAGE-RECEIVEDJ отформатировать и поставить поиск, вызов на очередь для доставки через заданную систему доставки 120 отправить команду STATUS UPDATE к собственному SIM команда STATUS UPDATE обновить состояние указанного поиск, вызова ________ ЛОЛ Фиг. 22 Фиг. 21 Тираж 50 екз Відкрите акціонерне товариство «Патент» Україна, 88000, м Ужгород, вул Гагаріна, 101 (03122)3-72-89 (03122)2-57-03 28 123 124