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

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

 

Область изобретения

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

Описание связанных технологий

Патент США №6151624 (в дальнейшем "патент б24") автора К.Теаге и других, который включен в настоящее изобретение во всей полноте, который также рассматривается автором как наиболее близкий прототип настоящей заявки на изобретение и описывает систему и метод, которые способствуют поиску и доступу к сетевым ресурсам, таким как вэб-страница с использованием их естественно языковых наименований. В случае вэб-страницы система и метод 624 патента увязывают естественно языковое имя (далее “имя”) с так называемым Uniform Resource Locator ("URL") в файле метаданных, который также содержит дополнительную описательную информацию о вэб-странице. После введения и подтверждения естественно языкового имени в строке введения данных вэб-браузера система и метод обращаются в индексную базу данных, содержащую метаданные, позволяющие найти соответствующий URL, связанный с заданным естественно языковым именем. Система и метод 624 патента затем отсылают пользователю отвечающую запросу вэб-страницу обозначенную соответствующим URL. Такой способ освобождает пользователя от необходимости знать полный URL желаемой вэб-страницы до того как пользователь получит к доступ к вэб-странице.

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

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

Более того, патент 624 не заявляет возможности осуществления связи с другими ресурсами и методами связи, а именно электронной почты, голосовой почты и устройств PDA (personal digital assistant).

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

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

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

Структура Управления Открытых ключей (Public Key management Infrastructure-PKI) решает указанные две проблемы. В одном из подходов PKI основана на цифровых сертификатах, которые связывают открытые ключи с соответствующими лицами с некоторой степенью целостности. PKI обычно включает базу данных цифровых сертификатов с возможностью проведения операций над ними, чтобы оперировать такими данными и поддерживать базу данных. Например, обрабатываются требования предоставления нового цифрового сертификата, отзыва существующих сертификатов, проверяются состояния существующих сертификатов.

Ближайшие прототипы и их отличия

Патент США №6151624, выданный RealNames, не предоставляет возможности межсетевой связи между сетями коммуникаций и Интернет; проверки on-line статуса; защищенного соединения; поддержки стандартов связи 3-го поколения, таких как MMS/I-mode/FOMA и единых услуг связи и сообщений (unified communication and messaging).

Патент США №6324645, принадлежащий VeriSign предлагает использование цифровых сертификатов, но не детализирует использование сертификатов для устройств сетей коммуникаций, имеющих связь с Интернет; защищенные услуги покупок в сети и транзакционных услуг, основанных на проверке ЕТА и динамических URL (Uniform Resource Locators).

Патент США №5793762, названный "System and method for providing packet data and voice services to mobile subscribers", и патент США №5457736, названный "System and method for providing microcellular personal communications services (PCS) utilizing embedded switches". Основное отличие между этими патентами и настоящим изобретением состоит в том, что кроме осуществления звонков и связи проводная сеть-мобильная сеть, мобильная сеть-проводная сеть, мобильная сеть-мобильная сеть, настоящее изобретение предлагает также возможность соединений типа браузер-проводная сеть, браузер-мобильная сеть, мобильная сеть-браузер, и проводная сеть-браузер, предоставляя таким образом возможность соединений (кросоперабельность) не только между всеми мобильными через Интернет, но также между мобильными, проводными сетями и Интернет пользователями, таким образом, что пользователь любой сети или Интернет может сделать звонок, не будучи абонентом мобильной связи.

Патент США №5732359, названный "Mobile terminal apparatus and method having network inter-operability", предлагает кросоперабельность между сетями мобильной и спутниковой связи, но не защищает кросоперабельности между любой телефонной сетью и Интернет.

Патент США №6353621, названный "Method to allow seamless service to mobile subscribers across various mobile switching centers supporting multiple intersystem standards", описывает телефонные соединения и метод кросоперабельности для мобильных сетей на уровне установки множества Коммутаторов, поддерживающих различные протоколы обмена (протокол TCP/IP для Интернет включен). Тем не менее, указанный патент не обеспечивает установления соединения с целью обмена между аппаратом и программой или программой и аппаратном.

Патент США №5521962, названный "Temporary storage of authentication information throughout a personal communication system", описывает метод управления информацией для аутентификации для пользователей мобильных сетей, снижая количество копий такой информации, размещенных в инфраструктуре конкретной сети беспроводной связи.

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

Ограничения и недостатки известных систем и методов, описанных выше, могут быть сняты и устранены различными воплощениями настоящего изобретения, в частности предлагающего методы, системы, компьютерные потоки данных, записи на носителях бизнес модели, включая кроме всего прочего, создание Первичного Файла Номера или ПФН (primary number file - PNF), содержащего единый телефонный адрес ЕТА, имеющего телефонный номер, принадлежащий сетевому ресурсу.

Одним из преимуществ предлагаемых изобретением является метод создания Вторичного Файла Номера или ВФН (secondary number file), а также Главный Файл Номера или ГФН (default number file), причем ВФН и ГФН являются зеркальными копиями ПФН; ГФН размещают на центральном коммутаторе (свич сервере), который предоставляет услуги соединения устройствам сети и сам является сетевым ресурсом, а ВФН размещают на сервере Интернет провайдера.

Другим конкретным предлагаемым преимуществом является метод, включающий выпуск временного цифрового сертификата, содержащего ЕТА для использованием хотя бы одним Временным Абонентом - ВА (Temporary Target - ТТ), причем ВА может выступать в качестве временного абонента получателя или инициатора звонков в сети, в то время как Администратор Цифровой Сертификации - АЦС (предпочтительно он же свич сервер) выпускает ЕТА и ЦС ЕТА (цифровой сертификат ЕТА); размещает ЕТА и ЦС ЕТА сразу в Файле Номера Абонента или передает их торговому представителю (реселлеру); реселлер присваивает ЕТА/ЦС конкретному временному Абоненту, размещая их в ПФН такого Абонента.

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

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

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

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

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

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

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

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

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

Фиг.1А является диаграммой файла номера.

Фиг.1В является схемой воплощения системы для навигации сетевых ресурсов, основанной на метаданных.

Фиг.2А является схемой последовательности операций для метода услуг регистрации в системе, изображенной на Фиг.1В.

Фиг.2В является схемой последовательности операций для метода активизации файла номера в системе, изображенной на Фиг.1В.

Фиг.3 является схемой последовательности операций для метода работы опросного “паука” в системе, изображенной на Фиг.1В.

Фиг.4 является блок-схемой услуг построения индекса в системе, изображенной на ФИГ.1В.

Фиг.5 является схемой последовательности операций для метода работы услуг разрешения в системе на Фиг.1В.

Фиг.6 является схемой последовательности операций для метода работы услуг

поиска номера в системе, изображенной на Фиг.1В.

Фиг.7А является примером страницы статистического отчета, сгенерированной системой на Фиг.1В.

Фиг.7В является другим примером страницы статистического отчета, сгенерированной системой Фиг.1В.

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

Фиг.9 является упрощенной блок-схемой систем разрешения и навигации.

Подробное описание воплощения изобретения

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

Формат Файла Номера

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

Как указано, кроме вэб-страниц метаданные могут увязывать другие сетевые ресурсы с телефонным номером. Например, метаданные могут увязывать телефонный номер со средством мгновенных сообщений (instant messaging) пользователя, мобильным телефонным номером (когда телефонный номер, на котором основан файл метаданных, является номером стационарного телефона) или даже средством видеоконференций Интернет. В таком духе телефонный номер и связанные с ним метаданные могут быть использованы для обнаружения мириадов средств связи, связанных с телефонным номером в дополнение к вэб-странице.

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

Предпочтительно метаданные подготовлены и первоначально размещены в форме Файла номера 64, который является текстовым файлом с грамматикой языка Extensible Markup Language (XML). XML является определением языка, продвигаемого корпорациями Microsoft® Corporation и Netscape® Communications Corporation. Дальнейшая информация об XML предоставлена в документе "XML: Principles, Tools, and Techniques," The World Wide Web Journal, vol.2, no.4 (Fall 1997) (Sebastopol, Calif.: O'Reilly & Assoc., Inc.).

Предпочтительно текст в файле номера 64 является совместимым с форматами Resource Definition Format ("RDF") и СС/РР (Composite Capabilities/Preference Profiles), основанным на RDF для управления информацией, описывающей устройства, а также с другими инициативами XML описаний вэб-способных и мобильных устройств метаданными. RDF является синтаксисом XML, разработанным консорциумом World Wide Web Consortium для выражения семантики. Текстовый файл для метаданных, описанный здесь, также называется файлом MLS. Пример файла MLS представлен далее на Фиг.1А.

MLS файл 900 определен в соответствии с грамматикой, в которой элементы окружены сопровождающими их тегами. Например, "<resource>" и "</resource>" являются дополняющими тегами. MLS файл 900 имеет две главные части, а именно секцию схемы 902 и секцию данных 904. Секция схемы 902 и секция данных 904 вложены в сопроводительные теги ("<xml>, </xml>"), которые указывают, что MLS файл 900 использует грамматику XML.

Секция схемы 902 отмечена тегами <schema> и </schema>. Секция схемы определяет схему, которая используется для организации данных в секции данных. На примере Фиг.1А, ссылка "href" в секции схемы относится к файлу, "MLS-schema", размещенному на вэб-сервере, который содержит определение схемы. Схеме присвоено имя "MLS". Теги в MLS файле 900, который является частью MLSschema, имеет префикс "MLS". Используя этот префикс, XML анализатор, который читает MLS файл 900, может определять теги, которые являются частью MLS схемы.

Секция данных 904 отмечена тегами <xml:data> и </xml:data>. Секция данных содержит один или более MLS записей 905. Каждая MLS запись 905 отмечена тегами <assertions> и </assertions>. Концептуально, каждая MLS запись 905 является набором утверждений о сетевом ресурсе, который указан внутри тега <assertions>. В примере на Фиг.1А, одна MLS запись 905 создает утверждения о сетевом ресурсе home.acme.com, который в качестве примера является домашней Интернет страницей, вымышленной компании Acme Corporation. Разумеется, в соответствии с настоящим изобретением, тег <assertions> может создавать утверждения о сетевом ресурсе, отличном от вэб-страницы. Например, тег <assertions> может определять прозвище пользователя для средства мгновенных сообщений.

В дальнейших воплощениях настоящего изобретения, более одного типа ресурсов могут быть ассоциированы с телефонным номером, а различные ресурсы могут быть доступны на основе доступности одного конкретного ресурса. Например, номер стационарного телефона пользователя может быть ассоциирован с прозвищем пользователя, используемым для мгновенных сообщений, с SMS идентификатором пользователя, со средством видеоконференций режима реального времени, таким как например Microsoft NetMeeting. Файл номера определяет список этих различных ресурсов порядке иерархии, например мгновенные сообщения, затем видеоконференции, затем сообщения SMS и предпочтительно является обновляемым в зависимости от доступности каждого из ресурсов в режиме реального времени в соответствии с известными методами. Таким образом, когда сделана попытка установить контакт с пользователем, используя номер его стационарного телефона, ресурс способствует установлению такого контакта, как это определено установленной иерархией и доступностью конкретного ресурса в режиме реального времени для различных описанных случаев. Продолжая рассматривать приведенный пример, связь будет установлена через средство мгновенных сообщений, если только пользователь доступен в режиме реального времени (режим "on-line" или “онлайн”) через его средство мгновенных сообщений, в противном случае будет предпринята попытка установить связь через видеоконференцию. Если пользователь не доступен в режиме on-line через видеоконференцию, будет попытка установить связь с помощью SMS. Другие средства связи могут быть также предложены, например голосовые или видеосообщения могут быть размещены для последующей доставки пользователю.

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

Язык RDF предоставляет общий механизм для описания многих типов ресурсов. RDF по своей природе не предоставляет средств для описания вэб-страниц. Соответственно, Файл номера 64 выражен в терминологии RDF, специфичной для вэб-страниц, которая описывает главные атрибуты вэб-страницы. Атрибуты включают телефонный номер, ассоциированный с вэб-страницей, а также предпочтительно включают также указатель или URL, описание, атрибут языка, атрибут региона и атрибут реестра. Разумеется, профессионал оценит тот факт, что концепция позволяет использовать другие соответствующие атрибуты для ресурсов, не являющихся вэб-страницами.

Каждая MLS запись 905 имеет набор метаданных 906. В случае примера по Фиг.1А, метаданные 906 содержат значение, которое означает номер телефона, ассоциированный с ресурсом. Значение номера телефона "212-555-1234" находится между тегами <telnumber> и <telnumber>. Метаданные 906 также включают значение описания, значение идентификатора языка и значение идентификатора региона. Пара тегов выделяет каждое значение. Например, на Фиг.1А значением описания является "Home Page of Acme Corporation," значением языка - "English," а значением региона является "Global." Значение описания предоставляет описание сетевого ресурса, который ассоциирован с реальным телефонным номером, который в приведенном примере может быть главным корпоративным телефоном корпорации Acme Corporation. В соответствии с настоящим изобретением, телефонный номер может включать код города или код страны и может содержать цифровые алфавитные или смешанные префиксы или расширения, например 1 -800-USA-RAIL, или любой другой тип символов, широко используемых с телефонными номерами.

Когда множество ресурсов определены в одном MLS файле, предпочтительно, для целей безопасности, чтобы каждый сетевой адрес, объявленный для ресурса, был связан с самым коротким сетевым адресом, содержащимся в файле MLS для каждого ресурса. В предпочтительном воплощении, каждый такой сетевой адрес должен быть логическим продолжением или логическим корнем сетевого адреса в файле MLS, содержащим наименьшее количество символов. Например, в отрывке, приведенном на Фиг.1А, относящемся к вэб-страницам, все последующие декларации ресурсов были бы необходимы для идентификации сетевых адресов, которые описывают файлы, размещенные внутри дерева директория, для которого адрес www.medialingua.com является корнем. Эта связь проверена с помощью Услуг Регистрации (Registration Service) 22 в момент, когда впервые создавался файл MLS.

Разумеется, так как описано выше, может быть описан файлом MLS любой ресурс, не являющийся вэб-страницей, например адрес электронной почты или “прозвище” пользователя для службы мгновенных сообщений ("buddy" identifier from an instant messaging buddy list).

Другим ключевым преимуществом описанного механизма является то, что он может быть использован для предоставления доступа в сеть ресурсами, использующими множетсво номеров телефона. Создаются один или более Файлов Номера 64. Файлы номера 64 содержат множество описаний. Каждое из описаний содержит телефонный номер, взаимосвязанный с определенным одним или более сетевыми ресурсами, связанными с полем <telnumber>. Тем не менее, каждое из описаний относится к одному и тому же сетевому ресурсу, связанному с тегом <resource>.

Например, один или более Файлов Номера 64 имеют описания, которые содержат соответственный телефонный номер корпорации Acme Corporation, такие как главный номер для юридического, маркетингового, технического отделов и отдела продаж. Каждое описание описывает тот же сетевой ресурс. Соответственно, эти описания создают множество телефонных номеров, которые указывают или разрешаются в один и тот же сетевой адрес. Когда некая третья сторона пожелает получить доступ к описанному таким образом сетевому ресурсу, такая третья сторона может использовать любой из таких телефонных номеров этого сетевого ресурса, который известен такой третьей стороне. Резолвер (Resolver) 40 позволит разрешить такой телефонный номер, то есть позволит найти в сети адрес сетевого ресурса, соответствующий номеру, независимо от того, какой именно номер телефона этого ресурса был введен. Соответственно, пользователь может найти и получить доступ к сетевому ресурсу, используя любой из множества известных телефонных номеров ресурса.

В альтернативном варианте исполнения, атрибуты также содержат атрибут списка, выделенный тегом <MLS:listings>. Атрибут списка является одним или более ключевыми словами или другими значениями, которые описывают другие свойства ресурса. Например, каждый ресурс имеет свойство предмета, которое указывает на общую природу продукта, услуг или организации, ассоциированные с ресурсом. Это позволяет организовать базу данных образом, сходным с тем, который используется справочником " желтые страницы". Например, корпорация Acme Corporation имеет в своем Файле номера 64 строку <МLS:listing>содержащую Anvils (наковальни), Rockets (ракеты), Slingshots (рогатки), что указывает на то, что корпорация является производителем наковален, ракет и рогаток.

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

Например, ресурс сервиса по поиску субъектов может содержать ссылки на вэб-страницы ресурсов, куда пользователь может послать сообщение электронной почты владельцу ресурса. Дополнительно или как альтернатива, такой ресурс может содержать ссылки которые позволяют по выбору или послать сообщение SMS, на пейджер или другим образом передать сообщение владельцу ресурса. Более того, ftp или другие ссылки или данные, ассоциированные с владельцем ресурса, могут быть размещены на такой вэб-странице. Таким образом, телефонный номер в поле <telnumber> Файла Номера 64 играет роль "Персонального Интернет Адреса (Personal Internet Address)" или ПИА (PIA), являясь единым персональным идентификатором, который может использоваться другими, чтобы связаться, послать и/или получить информацию о ресурсе многими способами, а именно позвонить, послать сообщение электронной почты, загрузить или “сбросить” файлы, используя ftp, обменяться сообщениями, поучаствовать в чате, послать назначение задачи или встречи, оставить голосовое сообщение или видеосообщение, или проверить on-line статус владельца ПИА. Полезность телефонного номера, ассоциированного с сервисом поиска субъектов, возрастает, когда телефонный номер является одновременно и номером стационарного телефона и мобильного, позволяя таким образом реализовать услуги "одного звонка (one call)" предлагаемые различными операторами телефонной стационарной и мобильной связи, которые позволяют автоматически переводить звонок на предопределенный мобильный номер, если стационарный телефон не отвечает.

В случае если ресурс имеет средства для посылки сообщений, отправитель может быть идентифицирован путем извлечения данных из настроек его компьютера и операционной системы компьютера. Например, во время отсылки сообщения электронной почты представленная система может сопроводить его информацией, идентифицирующей отправителя, извлеченной из настроек операционной системы Window, размещенной в настройках Start/Settings/Control Panel /Users/Properties. Таким образом, ресурс, которому послано сообщение, получит идентификатор отправителя, который может быть далее использован для ответа на письмо отправителя.

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

В другом альтернативном исполнении Файл Номера 64 может содержать другие дополнительные атрибуты. Например, другие атрибуты включают Организацию (Organization), Предмет (Subject), Реферат (Abstract), Тип (Type), Аудиторию (Audience). Атрибут Организация в Файле номера 64 может указывать на организацию или компанию, которая владеет или связана с сетевым ресурсом, например, "Federated Stores Incorporated". В атрибуте Предмет Файла номера 64 содержится описание принадлежности сетевого ресурса к предметной области, например "dogs" (собаки). В атрибуте Реферат Файла номера 64 размещается краткое описание сетевого ресурса. В атрибуте Тип Файла номера 64 размещена информация, описывающая тип сетевого ресурса, например файл " RealAudio file". В атрибуте Аудитория Файла Номера 64 размещена информация о предполагаемой аудитории сетевого ресурса, например "Women age 19-34" (женщины в возрасте 19-34 года).

Определение метаданных для сетевого ресурса, увязывание метаданных с сетевым ресурсом и размещение копии метаданных на сервере, который содержит сетевой ресурс, осуществленное предложенным образом, предоставляет значительные преимущества. Например, поддержка метаданных удобна. Поскольку копия метаданных размещена локально на сервере, который содержит сетевой ресурс, то метаданные могут обновляться в любое время без необходимости контактировать с главной службой. Как это описано далее, механизм обхода метаданных (metadata crawler mechanism) периодически посещает такой сервер с целью контроля за изменениями в метаданных. Если Файл номера 64 изменился, после подтверждения, изменения автоматически распространяются на базу данных и на индекс.

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

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

Другим преимуществом является многоязычная совместимость. Язык XML поддерживает таблицы символов стандарта UNICODE. Как результат, атрибуты, размещенные в Файле номера 64, могут быть выражены на любом естественном национальном языке.

Система Телефонных Номеров

Использование метаданных, размещенных в Файле номера 64, в комбинации с системой обнаружения сетевых ресурсов, атрибуты сетевого ресурса могут быть использованы для обнаружения и подключения к сетевому ресурсу. Например, как описано выше, атрибут “телефонный номер” Файла номера 64 может использоваться для обнаружения вэб-страницы. На Фиг.1В показана блок схема исполнения системы обнаружения сетевых ресурсов, состоящая из Регистра (Registry) 10, Библиотекаря (Librarian) 20, Индекса (Index) 30 и Резолвера (Resolver) 40. Искушенный в технологии специалист оценит тот факт, что вариации исполнения представленной системы обнаружения сетевых ресурсов позволяют реализовать систему для ресурсов, отличных от вэб-страниц.

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

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

Телефонные номера, сетевые адреса и описательная информация загружаются в Registry 10с помощью Librarian 20. В предпочтительном исполнении, Librarian 20 и Index 30 обмениваются с базой данных 12, используя интерфейс ODBC. В предпочтительном исполнении, база данных 12 имеет вместимость порядка несколько сот миллионов записей. Registry 10 и база данных 12 помогают обеспечивать соответствующую структуру и лексику для вэб-сайтов или других используемых ресурсов.

Librarian 20 имеет Сервис регистрации (Registration Service) 22 и Паука (Crawler) 24, каждый из которых соединен с базой данных 12 и с сетью, такой как Интернет 50, или другой сетью коммуникаций. Registration Service 22 получает новые связи телефонных номеров с сетевыми адресами, а также описательную информацию и загружает (“регистрирует”) их в Registry 10. Registration Service 22 получает связи от клиента 70 через Интернет 50. Crawler 24 перемещается по Интернету 50 (ощупывает Интернет), периодически связываясь с зарегистрированными ресурсами, которые соединены с Интернетом, чтобы обнаружить изменения в связях, размещенных или ассоциированных с такими вэб-серверами.

Система телефонных номеров взаимодействует с одним или более вэб-серверами или другими ресурсами, которые соединены с Интернетом 50. Как пример, один вэб-сервер 60 показан на Фиг.1В, но любое количество вэб-серверов может быть использовано в таком исполнении. Локальная база данных 62 связана с вэб-сервером 60 так, что вэб-сервер может извлекать значения из локальной базы данных для использования в вэб-приложениях, исполняемых на вэб сервере.

Файл номера 64 размещен во взаимосвязи с вэб-сервером 60 таким образом, что вэб-сервер может извлекать Файл номера и отправлять его содержание в Интернет 50 в ответ на запросы. В предпочтительном исполнении Файл номера 64 размещает описания одного или более номеров телефонов. Каждое описание телефонного номера содержит телефонный номер ресурса вэб-сервера 60, описание ресурса, сетевой адрес или другой идентификатор места ресурса в сети, а также другую информацию о ресурсе, такую как используемый им язык и предполагаемый географический регион использования. Предпочтительно, Файл номера 64 также размещает идентификатор грамматики, которая используется для форматирования прочей информации в Файле номера. Таким образом, информация в Файле номера является самодостаточной в смысле описания и независимой от языка.

Как указывает путь 29, Crawler 24 может связываться с вэб-сервером с 60 и извлекать значения, размещенные в Файле номера 64, используя соединение через Интернет 50. Как указано в пути 28, Crawler 24 может известить Index 30, что Файлы индекса 34 должны быть обновлены, чтобы отражать изменения в информации, размещенной в Файле номера Number File 64.

Index 30 связан с Регистром 10. Index 30 содержит построитель индекса Index Builder 32 и один или более файлов индекса Index Files 34, которые содержат индекс всех телефонных номеров, записи телефонных номеров, а также ресурсы, известные системе. Например, Файлы индексов Index Files 34 имеют записи индекса для значений, размещенных в Файле номера 64. Index Files 34 построен, администрируется и обновляется построителем индекса Index Builder 32.

В общем, в предпочтительном исполнении, файлы Index Files 34 более компактны, чем индексы, поддерживаемые обычными поисковыми машинами, так как количество информации, представленной во всех Файлах номера 64, является значительно меньшей содержания всех сетевых ресурсов, доступных в Интернете. Такая компактность является несомненным преимуществом, предоставляющим большее масштабирование и чувствительность, чем обычные поисковые машины. В дополнение, компактный размер файлов индекса Index Files 34 позволяет индексу Index 30 быть реплицированным во множество различных географических мест.

Резолвер (Resolver) 40 содержит один или более процессов разрешения (resolver processes) R1, R2, Rn, каждый из которых связан соответственно с Сервисами (Service) 42, 44, 46. Каждый resolver process R1, R2, Rn связывается со своим соответствующим Сервисом 42, 44, 46 для получения запросов, содержащих телефонный номер, конвертации или разрешения телефонного номера в сетевой адрес, связанный с телефонным номером, и отправки адреса и другой информации, связанных с телефонным номером, запрашивающему Сервису.

Клиент 70 подключен к Интернету 50. Клиент является компьютером, сервером, вэб-способным устройством или беспроводным устройством связи или сетью, в которой исполняется программа вэб-браузер 74 под управлением операционной системы 72. Примером вэб-браузера 74 является Netscape Communicator. (3TM)., а примером операционной системы 72 является Microsoft Windows 95.(3TM). Услуги системы телефонных номеров доступны клиенту 70 через Интернет 50, используя браузер 74 в соответствии со стандартными протоколами телекоммуникаций или Интернет/Вэб.

Например, под управлением браузера 74 и операционной системы 72 клиент 70 может установить HTTP соединение с Registration Service 22 через Интернет 50. Браузер 74 извлекает страницы или формы из Registration Service 22, которые подготовлены в формате языка разметки HTML. Браузер 74 показывает страницы или формы. Пользователь клиента 70 читает страницы или вводит информацию в формы и отсылает заполненные формы назад в Registration Service 22. В таком случае клиент 70 и Registration Service 22 выполняют диалог, который пользователь клиента 70 может исполнять функции, предлагаемые ему системой.

Предпочтительно, Сервис Регистрации 22, Паук 24, Построитель Индекса 32 и Резолвер 40 являются одним или более компьютерными программами, имеющими функции и процедуры, описанные здесь. В одном исполнении, каждый из Сервис Регистрации 22, Паук 24, Построитель Индекса 32 и Резолвер 40 является независимым процессом, причем одна или более инструкций каждого из таких процессов может быть активна и исполняться в каждый заданный момент времени. В предпочтительном исполнении, компьютерные программы разработаны с использованием объектно-ориентированного языка программирования и средств программирования, таких как язык Java.

Сервис Регистрации (Registration Service) 22, Паук (Crawler) 24, Построитель Индекса (Index Builder) 32 и Резолвер (Resolver) 40 предпочтительно исполняются на одном или более компонентах ссерверных компьютеров, которые могут быстро получать доступ, управлять и обновлять базу данных 12 и файлы индекса 34. Упомянутые элементы могут быть распределены или разделены. Например, предусмотрено, что Резолвер 40 и его процессы Rl, R2, Rn исполняются на одном серверном компьютере, а Сервис Регистрации 22, Паук 24, и Построитель Индекса 32 функционируют на том же компьютере или на кластере компьютеров, отдельных от сервера, размещающего Резолвер 40. В такой конфигурации Резолвер 40 может быстро получать и отвечать на запросы клиента о получении доступа к сетевым ресурсам, которые размещены в индексе Файлов индекса (Index Files) 34, не мешая и не влияя на работу других элементов и их функций.

В одном из исполнений Библиотекарь (Librarian) 20, а также другие функции системы могут быть доступны клиенту 70 путем установления соединения с одной или более административными вэб-страницами (Web pages) 80, которые предоставляют функции, используя HTTP соединение. Административные вэб-страницы (Web pages) 80 размещены на вэб-сервере и генерируются программой, установленной на этом сервере, которая может поддерживать связь с другими элементами системы. Эта программа посылает страницу верхнего уровня клиенту 70. Браузер 74 клиента отображает эту страницу верхнего уровня, которая представляет меню опций для работы с системой. Например, предпочтительное меню опций показано в Таблице 1.

ТАБЛИЦА 1
ОПЦИИ МЕНЮ ВЕРХНЕГО УРОВНЯ
ФАЙЛ MLS
Создать (Create)
Активизировать (Activate)
Изменить (Modify)
Удалить (Delete)
СТАТИСТИКА И ОПЛАТА СЧЕТОВ
Статистика (Stats)
Оплата счетов (Billing)
ЗАКАЗЧИК
Новый Заказчик (New Customer)
Изменить профиль (Modify Profile)
Изменить контакты (Change Contacts)
Выйти (Logout)

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

В предшествующем обсуждении элементы системы были описаны в отношении Интернета 50 как связующего элемента. Тем не менее, Интернет является всего лишь одним примером связующего элемента, который может быть использован для установления связи между элементами системы. Другие элементы, такие как локальная сеть, региональная сеть, другие проводные или беспроводные сети, Интрасети и Экстрасети, также могут быть использованы. Одновременно, протокол, относящийся к Интернету, такой как Transmission Control Protocol and Internet Protocol, также не обязателен, другие протоколы могут использованы вместо него.

В такой конфигурации система имеет преимущества по сравнению с другими подходами. Например, вэб-сайты заказчика 60 изолированы от базы данных 12. Фалы индекса 34 отделены от базы данных 12 и Файлы индекса доступны только Резолверу (Resolver) 40. Это снижает время загрузки базы данных и увеличивает способность отвечать, а также обеспечивает масштабирование. Такая архитектура хорошо соответствует концепции распределенной репликации Файлов индекса.

Функции Профиля Заказчика

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

Когда выбрана опция ЗАКАЗЧИК/Новый заказчик, система генерирует одну или более вэб-страниц, содержащие формы, позволяющие пользователю ввести новый профиль пользователя. Форма имеет поля для записи имени, адреса, телефонного номера, контактной персоны и способа оплаты, такие вэб-страницы и формы передаются клиенту 70 и показываются браузером. Пользователь клиента 70 вводит соответствующую информацию в поля записей и “нажимает” по кнопке " ПРИНЯТЬ", размещенной на вэб-странице. В ответ, клиент 70 возвращает системе по HTTP заполненную форму. Система извлекает введенную информацию из полей и размещает ее в таблице базы данных 12.

В предпочтительном исполнении, процесс регистрации Заказчик /Новый заказчик инициируется, используя вэб-страницу, сгенерированную системой в форме, показанной в Таблице 2.

ТАБЛИЦА 2 ГЛАВНАЯ СТРАНИЦА РЕГИСТРАЦИИ
Добро пожаловать на сайт системы регистрации Телефонного Номера. Перед тем, как Вы представите на рассмотрение свой Телефонный Номер, Вам следует предоставить нам некоторую информацию о Вас и об организации, которую Вы можете представлять.
Для инициации процесса регистрации Вам сначала следует ввести Ваш адрес электронной почты в качестве Вашего имени (login name), а также выбрать пароль.
Вам также потребуется запомнить это имя и пароль, так как Система Телефонных Номеров использует их для предоставления Вам привилегий доступа.
Имя
Пароль
[НАЗАД] [СЛЕДУЮЩИЙ]

В Таблице 2 обозначения [НАЗАД] и [СЛЕДУЮЩИЙ] означают функциональные кнопки. Пользователь вводит адрес почты пользователя в поле Имя, а также избранный пользователем пароль в поле Пароль. Когда пользователь (нажимает) функциональную кнопку СЛЕДУЮЩИЙ, Имя и Пароль размещаются в базе данных 12 во взаимосвязи друг с другом.

Предпочтительно, система затем показывает вэб-страницу, содержащую форму, которая позволяет системе получать дальнейшую информацию о пользователе. Форма может иметь поля для введения имени пользователя, адреса, города, области, почтового индекса, государства, а также телефонного номера, идентификатор или прозвище из списка службы мгновенных сообщений, адрес электронной почты, оператор мобильной или проводной связи, тип оборудования и номер модели. Пользователь вводит требуемую информацию и нажимает кнопку СЛЕДУЮЩИЙ. Альтернативно, или в дополнение, определенная информация может быть извлечена из информации, уже доступной на компьютере пользователя, например установки предпочтительного языка или страны, а также кода города, содержащихся в вэб-браузере пользователя или в операционной системе Windows® пользователя. Система проверяет каждое значение, чтобы убедиться, что формат значения соответствует требованиям для каждого из полей. Значения размещаются в базе данных 12 в ассоциации с именем пользователя и его адресом электронной почты. Вся вместе эта информация является Профилем заказчика. Когда профиль заказчика создан, пользователь может создать записи типа “телефонный номер” и разместить их в одном или более Файлах номера 64.

Выбор опции меню ЗАКАЗЧИК /Изменить профиль заставляет систему сгенерировать вэб-страницу, содержащую форму, которая позволяет пользователю изменить ранее созданный пользователем профиль. Для защиты операций IP адрес пользователя извлекается из HTTP обмена, в процессе которого пользователь использовал опцию ЗАКАЗЧИК /Изменить профиль. Пользователю разрешено просматривать и изменять только тот профиль, который совпадает с ранее созданным Файлом номера, размещенным на сервере, имеющим тот же IP адрес, что и пользователь. Основываясь на IP адресе пользователя, система просматривает соответствующий профиль в базе данных 12 и извлекает содержание профиля. Содержание профиля показывается на вэб-станице.

Пользователь может затем передвинуть курсор, сгенерированный клиентом 70 к любому другому значению, показанному на вэб-странице, и внести изменения в значения. Когда пользователь выбирает или нажимает кнопку "ПРИНЯТЬ", заполненные значения, содержащиеся на вэб-странице, передаются в систему через HTTP. Система обновляет базу данных 12, используя эти значения.

Выбор опции меню ЗАКАЗЧИК /Изменить контакты позволяет пользователю изменить контакты по оплате, ассоциированные с зарегистрированным Файлом номера. Выбор опции ЗАКАЗЧИК /Выйти позволяет пользователю завершить текущую сессию или войти в систему под другим именем заказчика. Эти функции предусмотрены в вэб-программе, которая получает и загружает соответствующие значения в Регистр (Registry).

Сервис Регистрации

На фиг.2А показана диаграмма исполнения предпочтительного способа функционирования Сервиса Регистрации (Registration Service) 22 Библиотекаря (Librarian) 20.

Предпочтительно, Registration Service 22 имеет вэб-интерфейс, благодаря которому один или более клиентов 70 могут использовать функции, предлагаемые Сервисом Регистрации путем выбора кнопок функций, размещенных на вэб-странице, чтобы активизировать функции.

Главной функцией Сервиса Регистрации является 22 регистрация новых телефонных номеров в Регистре 10. В одном из исполнений Сервис Регистрации 22 вызывается путем использования опции Создать на странице меню верхнего уровня. Как показано на схеме 200, внешний пользователь или "заказчик" системы идентифицирует себя для системы таким образом что информация, введенная позже, может быть ассоциирована с заказчиком. Эта информация включает адрес электронной почты заказчика, куда могут быть направлены заказчику сообщения Службы Регистрации 22 через Интернет 50. В таком контексте термины "заказчик" и "пользователь" относятся к оператору компьютера, удаленно соединенного с системой, например, к клиенту 70.

Как указано на схеме 202, заказчик затем предоставляет информацию Сервису Регистрации 22, который идентифицирует сетевой ресурс вэб-сервера 60 по его местоположению, телефонному номеру, описательной информации о сетевом ресурсе. Например, заказчик вводит телефонный номер "212 555 3000" (он является основным номером компании с именем XYZ Соrр), http://www.xyzcorp.com в поле URL, а также описание ресурса. Предпочтительно, такая информация вводится в поля вэб-страницы, которая спроектирована для целей получения такой информации в форме, показанной в Таблице 3.

ТАБЛИЦА 3
СТРАНИЦА ЗАПИСИ ТЕЛЕФОННОГО НОМЕРА
Телефонный Номер: 212-555-3000
URL: http://www.xyzcorp.com.
Тип:компания
Язык: Английский
Регион: Северная Америка
Описание: Это домашняя страница изготовителя приспособлений, XYZ Corp.
[НАЗАД] [СЛЕДУЮЩИЙ]

Когда пользователь ввел всю информацию, чтобы продолжить обработку Файла номера 64, пользователь нажимает функциональную кнопку СЛЕДУЮЩИЙ, размещенную внизу страницы.

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

На шаге 203А, пользователя информируют об оплате за предоставленные услуги разрешения и он или отклоняет оплату и выходит из программы или принимает условия оплаты и переходит к шагу 204.

На шаге 204, Сервис Регистрации 22 создает Файл Номера 64, основываясь на информации, введенной заказчиком. Таким образом, Файл Номера 64 размещен на сервере, доступном для Сервиса Регистрации 22. Тем не менее. Файл Номера 64 пока не размещен во взаимосвязи с вэб-сервером 60.

В блоке 205, Сервис Регистрации 22 случайным образом генерирует имя файла для Файла Номера 64. Случайное имя файла используется, чтобы предотвратить несанкционированный доступ программ, процессов или пользователей для идентифицирования или изменения Файла Номера 64, когда он размещен в ассоциации с вэб-сервером 60. Если было использовано такое же имя, на любом вэб-сервере, зарегистрированном Регистром 10, авторизованный пользователь может изменять запись, внесенную в Файл Номера 64, ссылаясь на другой сетевой ресурс. В итоге, как будет показано далее, Паук 24 обнаружил бы изменение и разместил телефонный номер в Регистре 10. Соответственно, желательно скрыть имя Файла номера 64 от неавторизованных пользователей.

В блоке 206, Файл Номера 64 послан заказчику как файл-вложение к электронному письму. Объект 206 содержит шаг получения сообщения электронной почты от пользователя. В предпочтительном исполнении система показывает вэб-страницу, имеющую поле ввода адреса электронной почты, в форму, показанную в Таблице 4.

ТАБЛИЦА 4
СТРАНИЦА ЗАПИСИ EMAIL
Пожалуйста, введите свой email адрес, по которому мы можем послать Вам Файл телефонного номера, который Вы только что создали.
joe@xyzcorp. corn
[НАЗАД] [СЛЕДУЮЩИЙ]

После отсылки пользователю Файла Номера 64 электронной почтой система показывает страницу подтверждения на клиенте 70. В предпочтительном исполнении, страница подтверждения имеет форму, показанную в Таблице 5.

ТАБЛИЦА 5
СТРАНИЦА ПОДТВЕРЖДЕНИЯ
Ваш Файл Телефонного Номера был отправлен по адресу [e-mail]. Теперь Вам следует сохранить этот файл на Вашем вэб-сайте в соответствии с инструкциями в сообщении, которое Вы получите. После исполнения этого шага файл должен быть активизирован через услуги активации Файла Телефонного Номера. (Просто следуйте по предыдущей ссылке или обратитесь в Службу Поддержки Пользователей, обратитесь в пункт меню Активизация, относящийся к категории Файл MLS.).
[ЗАКОНЧИТЬ]

На шаге 208, заказчик устанавливает Файл номера 64 на вэб-сервер 60 или способом, доступным на вэб-сервере. Предпочтительно, Файл Номера 64 размещается в таком месте на вэб-сервере 60, которое описано Сервисом Регистрации 22. Например, сообщение email описывает, что Файл Номера 64 должен быть установлен в корневом директории сетевого ресурса, который назван в Файле номера 64. Это сделано, чтобы убедиться, что получающий заказчик аутентичен; Сервис Регистрации 22 предполагает, что только аутентичный представитель заказчика может иметь доступ к корневому директорию вэб-сервера, на котором находится названный сетевой ресурс. Корневой директорий также обозначен для удобства заказчика. Когда Файл Номера 64 размещен в корневом директории вэб-сервера, заказчик может изменять или реорганизовать вэб-сервер, не затрагивая Файла номера. Наоборот, если Файл Номера 64 был бы размещен в подчиненном директории вэб-сервера, тогда мог быть риск отключения Файла номера при случайном удалении директория, в котором Файл содержался.

В блоке 210, заказчик подтверждает Сервису Регистрации 22, что Файл Номера 64 был размещен заказчиком в описанном месте. Подтверждение Заказчика может быть предоставлено в виде сообщения email, направленного в Сервис регистрации 22, или путем введения соответствующей команды, используя вэб-интерфейс Сервиса Регистрации 22.

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

В предпочтительном исполнении пользователь активизирует Файл номера после его создания путем выбора опции меню ФАЙЛ MLS /Активизация из списка опций меню верхнего уровня. В ответ, как показано на 212, система создает страницу, в которой просят пользователя ввести тип активации, и посылает страницу клиенту, который показывает ее. Например, система показывает страницу формы, показанной в Таблице 6.

ТАБЛИЦА 6
СТРАНИЦА ВЫБОРА ТИПА АКТИВИЗАЦИИ
Пожалуйста, выберите нужную услугу:
(*) Живое обновление ранее зарегистрированного Файла Номера.
(*) Регистрация нового Файла Номера на вашем вэб-сайте.
[НАЗАД] [СЛЕДУЮЩИЙ]

Предпочтительно символы, показанные в форме "(*)" в Таблице 6 вверху показываются на дисплее как “radio buttons”, или другие графические элементы, которыми может быть осуществлен выбор пользователя. Когда пользователь выбирает первую опцию ("Живое обновление ранее зарегистрированного Файла Номера "), как показано на 214-216, система активизирует Паука (Crawler), который находит Файл Номера пользователя в Интернете, обновляет базу данных 12, как описано ниже. Таким образом, функция "Живое обновление" предоставляет пользователю возможность заставить систему найти измененный Файл номера и обновиться новой информацией. Альтернативно, как описано ниже в связи с Пауком (Crawler), пользователь может просто ждать и Паук (Crawler) в конце-концов найдет измененный файл и обновит базу данных.

Когда пользователь выбирает вторую опцию ("Регистрация нового Файла Номера на вашем вэб-сайте "), как показано на 220-222, в ответ система создает и посылает клиенту 70 вэб-страницу, с которой пользователь может ввести информацию об оплате, относящуюся к пользователю и к его Файлам Номера в соответствии с насчитанной суммой и действиям, предпринятым в шагах 203 и 203А. Шаги по оплате процесса активации являются полностью необязательной частью процесса, а другие исполнения не предполагают никакого механизма оплаты, включая те, относящиеся к шагам 203 и 203А. В исполнениях которые используют механизмы оплаты, вэб-страница содержит поля для введения информации, относящейся к оплате. Например, поля записи типа кредитной карты, номера карты, даты истечения срока действия карты и имени владельца карты. Система получает значения полей информации по оплате в блоке 224.

В блоке 226 система предлагает пользователю ввести сетевой адрес Файла Номера, чтобы активизировать его, а также описание Файла Номера.

В блоке 228 Сервис Регистрации 22 создает HTTP соединение с вэб-сервером 60, запрашивает и загружает копию Файла Номера 64. Этот шаг выполняется с тем, чтобы убедиться, что Файл Номера 64 действителен и размещен в правильном месте. В блоке 230 Файл Номера 64 анализируется и из него извлекаются значения, идентифицирующие сетевой ресурс. В блоке 232 система создает вэб-страницу, которая отражает все значения, выявленные в процессе анализа из текущего Файла Номера 64, и посылает страницу клиенту 70. На вэб-странице система показывает сообщение следующего содержания:

"Файл номера, который мы загрузили с Вашего сайта, содержит следующие записи. Пожалуйста, проверьте правильность этих записей. Нажмите СЛЕДУЮЩИЙ, чтобы продолжить.

[НАЗАД] [СЛЕДУЮЩИЙ]"

Как показано на блоке 234, пользователь просматривает записи, проверяя их правильность, и нажимает на клавишу СЛЕДУЮЩИЙ. Если какое-то из значений не правильно, пользователь нажимает клавишу НАЗАД, которая активизирует функцию ИЗВЕНИТЬ, описанную здесь.

В предпочтительном исполнении система затем показывает вэб-страницу, содержащую письменное юридическое соглашение, предусматривающее уплату сбора за регистрацию, а также разрешение споров, включая юридические, как показано на блоках 236-238. Соглашение “подписывается” путем нажатия на кнопки “ПРИНЯТЬ” или “ОТКЛОНИТЬ”. Для принятия условий соглашения и продолжения регистрации, пользователь нажимает кнопку ПРИНЯТЬ. Для отклонения условий соглашения и прекращения процесса регистрации пользователь нажимает кнопку ОТКЛОНИТЬ. Использование юридического соглашения является абсолютно необязательным, а исполнение, не использующее такое соглашение, также рассматривается здесь и является предметом настоящего изобретения.

Система затем размещает значения, извлеченные при анализе из Файла Номера 64 в базу данных 12 Регистра 10, как это показано в блоке 240.

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

В блоке 242 Сервис Регистрации 22 уведомляет Index Builder 32, что была создана новая запись в базе данных 12. Маршрут 26 на Фиг.1В представляет такое уведомление. Уведомление включает информацию, достаточную, чтобы идентифицировать новую запись в базе данных 12, например идентификатор строки ("rowid") таблицы, в которой размещена новая запись. В ответ Index Builder 32 выполняет живое обновление Файлов Индекса 34, как это разъяснено ниже.

Таким образом, Файл Номера 64, созданный пользователем, активизируется и становится доступным для использования Резолвером 40.

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

Изменение и удаление информации Файла Номера

После создания Файла Номера, имеющего одну или более записей, записи могут быть отредактированы или удалены, используя функции ФАЙЛ MLS /Изменить и ФАЙЛ MLS /Удалить, показанные в списке меню верхнего уровня.

Когда пользователь выбирает функцию ФАЙЛ MLS /Изменить, система считывает MLS файл с сервера, ассоциированного с пользователем, и показывает содержание этого файла на вэб-странице в форме, показанной в Таблице 7.

ТАБЛИЦА 7
ФОРМА “ФАЙЛ MLS /ИЗМЕНИТЬ СТРАНИЦУ”
Текущий список записей MLS, содержащихся в Вашем Файле MLS, приведен ниже. Для редактирования записи выберите соответствующее слово и нажмите РЕДАКТИРОВАТЬ.
Для удаления записи выберите соответствующее слово и нажмите УДАЛИТЬ.
Для добавления новой MLS записи нажмите ДОБАВИТЬ. Нажмите СЛЕДУЮЩИЙ, когда закончите редактировать Файл MLS.
[НАЗАД] [РЕДАКТИРОВАТЬ] [УДАЛИТЬ] [ДОБАВИТЬ] [СЛЕДУЮЩИЙ]
Телефонный Номер: 212-555-3000
URL: http://www.xyzcorp.com
Тип: Компания
Язык: Английский
Регион: Северная Америка
Описание: домашняя страница производителя приспособлений, XYZ Corp.
Выбрано:
Телефонный Номер: 212-555-1234
URL: http://www.acme.com
Тип: Компания
Язык: Английский
Регион: Глобальный
Описание: Домашняя страница Acme Corp
Выбрано:

Страница состоит из секций текстовых инструкций, набора функциональных кнопок редактирования и списка записей, ныне находящихся в Файле Номера. Текстовые инструкции поясняют функции, исполняемые функциональными кнопками. В предпочтительном исполнении, функциональные кнопки такой страницы действуют на все записи Файла Номера, а не на поля в отдельности. Например, для редактирования записи пользователь выбирает соответствующий телефонный номер, такой как "212-555-1235", и нажимает кнопку РЕДАКТИРОВАТЬ. В ответ система показывает страницу редактирования записи, которая содержит избранную запись. Пользователь может ввести измененный текст в поля записи на странице редактирования.

Похожим образом, чтобы удалить запись, пользователь выбирает соответствующее слово и нажимает кнопку УДАЛИТЬ. В ответ система создает новых Файл Номера, который содержит все предыдущие записи, кроме записи, выбранной для удаления.

Для добавления новой записи к показанному Файлу Номера пользователь нажимает по кнопке ДОБАВИТЬ. В ответ система показывает страницу по форме Таблицы 3, рассмотренную выше в связи с созданием нового Файла Номера.

Для активизации изменений, сделанных с помощью операций РЕДАКТИРОВАТЬ, УДАЛИТЬ и ДОБАВИТЬ, пользователь нажимает кнопку СЛЕДУЮЩИЙ. Нажатие кнопки СЛЕДУЮЩИЙ понуждает систему создать новый Файл номера, предпочтительно в вышеописанном формате XML. Система отсылает по email новый Файл Номера пользователю в соответствующем поясняющем сообщении. Для целей безопасности от пользователя требуется разместить новый Файл Номера в директории, предписанном системой как и в случае создания нового файла.

Паук (Crawler)

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

В блоке 302, Паук 24 считывает базу данных 12 из Регистра 10 и извлекает одну или более строк или записей, которые идентифицируют сетевые ресурсы, заиндексированные в Файлах Индекса 34. Способ выбора строк или записей не является критическим и потому могут использоваться несколько различных схем. Например, Паук 24 может выбирать все строки или записи, которые не были обновлены со времени последнего включения Паука. Или Паук 24 может выбрать все строки или записи, которые были созданы за определенный промежуток времени или которые старше определенного количества дней. Или Паук 24 выбирает список недавно обновленных записей. В предпочтительном исполнении система также устанавливает связи между телефонными номерами и именами Файла MLS и местами размещения, называемыми Таблицей информации о файлах (File Info table). Паук сравнивает выбранные строки с Таблицей информации о файлах и устанавливает сетевой адрес, место размещения или URL Файла Номера, ассоциированного с каждым телефонным номером, строкой или записью.

Для каждой из выбранных строк или записей в блоке 304 Паук 24 опрашивает вэб-сайт заказчика, который представлен строкой или записью, пытаясь обнаружить обновления в Файле Номера 64, который размещен во взаимосвязи с вэб-сайтом. Опрос включает шаги по открытию HTTP соединения с вэб-сайтом, запрашиванию и получению копии Файла Номера. Паук 24 анализирует Файл Номера, используя XML парсер, чтобы найти запись телефонного номера, а также значения внутри каждой записи телефонного номера, которые содержат телефонный номер, сетевой адрес, а также описательную информацию о сетевом ресурсе. XML парсер существует и может быть приобретен у корпорации Microsoft® Corporation.

Для каждой записи в Файле номера, как это показано в блоке 306, паук 24 проверяет, совпадает ли запись со строкой или записью в базе данных 12. Таким образом Паук 24 определяет, отличается ли содержание Файла Номера от записей в базе данных 12. Если так, как показано в блоке 308, то Паук 24 обновляет базу данных 12 и запрашивает построитель индекса (Index Builder) построить заново запись индекса, связанную с обновленной строкой или записью в базе данных 12.

Таким путем Паук 24 опрашивает вэб-сайты в Интернете 50, чтобы обнаружить сайты заказчиков, претерпевших обновление. Поскольку Файлы Номера рассредоточены в сети по большому количеству сайтов заказчиков, каждый заказчик имеет возможность свободно изменять свой Файл Номера в любое время. Заказчик не должен об этом сообщать системе телефонных номеров, так как Паук 24 в конце концов обнаружит каждое изменение и обновит базу данных 12 соответственно. Так, Библиотекарь 20 автоматически контролирует внесение изменений в Файлы Номера, распределенные в сети, и периодически обновляет Регистр 10 в соответствии с изменениями. Выгодно то, что заказчики и конечные пользователи не вовлекаются в процесс обновления базы данных 12.

Паук 24 обновляет базу данных автоматически.

В предпочтительном исполнении заказчик может инструктировать Библиотекаря 20 незамедлительно исполнить Программу Паука 24 в отношении конкретного вэб-сайта. В таком случае изменения конкретного Файла Номера мгновенно обнаруживаются и загружаются в базу данных. Заказчик активизирует мгновенное исполнение Паука 24 путем выбора опции Живого Обновления из меню верхнего уровня. В предпочтительном исполнении, система также выполняет, раз в неделю, полное обновление Файлов Индекса 34, основываясь на содержании базы данных 12. Таким образом, по меньшей мере еженедельно, Файлы Индекса 34 строятся заново на основе текущего содержания базы данных 12.

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

Построитель Индекса (Index Builder)

Индекс 30 содержит Построитель Индекса 32 и Файлы Индекса 34. Построитель Индекса 32 является программой или процессом, который функционирует в двух режимах. В первом режиме Реконструктивный процесс Построителя Индекса 32 периодически опрашивает базу данных 12, обнаруживает изменения в базе данных и индексирует измененные записи телефонных номеров в Файлах Индекса 34. Во втором режиме, Построитель Индекса 32 обновляет Файлы Индекса 34 в режиме реального времени, исполняя очереди инструкций по обновлению индексов. Фиг.4 является блок-схемой предпочтительного исполнения Построителя Индекса 32. Компьютеры, обозначенные GO Machines 100, 102, 104, каждый исполняют программу Построителя Индекса 32. Каждая из машин GO Machine 100, 102, 104 ассоциированы с процессами сетевого интерфейса M1, M2, Мn Агента очередей (Queue Agent) 92a. Агент очередей 92а связан с сетью 106, такой как локальная сеть, и получает запросы на построение записей индекса от Библиотекаря 20. Агент очередей 92а распространяет копию каждого запроса одному из сетевых интерфейсов M1, M2, Мn, который, в свою очередь, передает запрос ассоциированной с ним GO машине 100, 102, или 104. Такая архитектура хорошо отвечает на внешние запросы и является устойчивой к ошибкам.

Внутри каждой GO машины. Построитель Индекса 32 связан с парой очередей 90а, 90b и парой индексов 34а, 34b. Служба GO 42 может иметь доступ к любому из индексов 34а, 34b, но в каждый отдельный момент времени бывает связана только с одним из них. Резолвер 40 отсутствует на Фиг.4 для чистоты, но должно быть понятно, что Служба GO 42 получает доступ к каждому индексу 34а, 34b с помощью процесса Резолвер 40.

Для Службы GO 42 важно поддерживать постоянную связь с одним или другим индексом. Соответственно, используя архитектуру, показанную на Фиг.4, Построитель Индекса строит индексы используя следующий процесс.Служба GO связана с индексом 34b и имеет инструкции передавать запросы на разрешение телефонных номеров только индексу 34b. Как только запрос на построение индекса приходит из Агента очередей 92а в Построитель Индекса 32, Построитель Индекса 32 добавляет запросы к обеим очередям 90а и 90b. Когда одна из очередей становится достаточно полной, например очередь 90а, Построитель Индекса 32 последовательно удаляет записи из такой очереди, в порядке “первый-вошел-первый-вышел” (FIFO), и обновляет индекс 34а записью каждой очереди. Одновременно, если получены какие- то новые требования на построение индекса, они направляются в обе очереди. Когда очередь 90а опустела и индекс 34а полностью обновлен, Построитель Индекса 32 инструктирует Службу GO 42 передать требование на разрешение телефонного номера только индексу 34а. Построитель индекса 32 затем удаляет записи только из очереди 90b и обновляет только индекс 34b из этой очереди. Таким образом, Построитель Индекса 32 может добавлять записи индекса к одной из очередей 90а, 90b, но всегда обновляет только один индекс в единицу времени, используя содержание только одной из очередей в единицу времени. Очередь, с которой Построитель Индекса 32 поддерживает связь, всегда является противоположной или дополнительной к индексам 34а, 34b, с которыми Служба GO 42 является связанной в текущий момент времени. Таким образом Служба GO 42 постоянно поддерживает связь с индексом, а Построитель Индекса 32 может обновлять индекс в режиме реального времени, не прерывая процесса разрешения телефонных номеров.

Предпочтительно, запросы на построение содержат идентификатор, называемый “Fileld”, файла или сроки, которая увязана с Таблицей Информации Файла или ТИФ (File Info table), описанной выше. Построитель Индекса 32 ищет FileID в ТИФ и извлекает все записи базы, данных которых совпадают с FileID. Каждая запись базы данных содержит уникальный идентификатор, который описан в записи базы данных. Эти уникальные идентификаторы генерируются, используя генератор последовательностей сервера базы данных. Используя уникальный идентификатор записи базы данных, который совпадает с FileID, Построитель Индекса извлекает совпадающую запись индекса. Информация записи индекса сравнивается с информацией, содержащейся в запросе на построение. Если информация в запросе на построение отличается, запись индекса обновляется. Если информация в запросе на построение показывает, что связанный сетевой ресурс перестал быть активным или недоступен в сети, запись индекса удаляется.

Для обеспечения масштабирования, надежности и быстрого ответа каждая из GO машин 100, 102, 104 имеет сходную конфигурацию и функционирует параллельно с другими. Хотя на Фиг.4 для иллюстрации показаны только три GO машины 100,102, 104, система может использовать любое число машин. В предпочтительном исполнении Планировщик определяет, когда начать исполнение Построителя Индекса 32.

Резолвер (Resolver)

В общем Резолвер 40 функционирует в качестве интерфейса запросов к метаданным, размещенным в Регистре 10. Резолвер 40 функционирует, получая телефонные номера в качестве запросов от сервисов 42, 44, 46, запрашивает индекс 30 определить сетевые адреса, соответствующие заданным телефонным адресам, и отвечает сервисам, передавая найденные сетевые адреса. Резолвер 40 построен так, чтобы быстро отвечать на операции поиска и обслуживать миллионы запросов в день. Для минимизации времени ответа и обеспечения масштабирования, отвечая на запросы, Резолвер 40 не имеет непосредственного доступа к базе данных 12 Регистра 10. Вместо этого Резолвер поддерживает связь с Индексом 34, который размещен в быстрой главной памяти.

В предпочтительном исполнении Резолвер 40 функционирует на любом количестве множества процессов R1, R2, Rn, каждый из которых связан с сервисом 42, 44, 46, который создает запросы к Резолверу. Сервисы 42, 44, 46 поддерживают связь с процессами R1, R2, Rn Резолвера, используя соединение HTTP. Предпочтительно также, чтобы компьютеры, исполняющие программу Резолвера 40, имели конфигурацию с тройным резервированием. Такая конфигурация обеспечивает быстрый ответ на запросы сервисов 42, 44, 46 и обеспечивает надежность. Каждый из процессов R1, R2, Rn исполнен в виде вэб-приложения, которое исполняет Резолвер. Сервисы 42, 44, 46 поддерживают связь с процессами R1, R2, Rn Резолвера, используя HTTP соединение.

В одном из исполнений процесс Резолвера 40 выполнен в виде динамической библиотеки связей (dynamically linked library или DLL), которая интегрирована в сервисы 42, 44, 46. В предпочтительном исполнении каждый из процессов Резолвера 40 является обособленным процессом или программой, которая функционирует в соответствии с методом, показанным на Фиг.5. Резолвер 40 исполнен с одним или более API (интерфейс создания приложений application programming interface), которые позволяют разрабатывать сервисы, которые используют Резолвер, такие как "желтые страницы" и поисковые сервисы.

Как показано в блоках 502-504, внешний вэб-клиент, сервер или браузер, такие как клиент 70, обращается к Резолверу 40. В одном из исполнений клиент 70 устанавливает соединение с Резолвером 40, используя HTTP соединение. В блоке 502 клиент 70 создает HTTP соединение с Резолвером 40. В блоке 504 клиент 70 предоставляет Резолверу URL, запрашивая тем самым вернуть сетевой адрес, соответствующий конкретному телефонному номеру. Например, URL представлен в форме http://www.resolver.com/resolve? tn=TELRPHONE NUMBER. В такой форме URL строка "http://" определяет URL как HTTP запрос, “www.resolver.com” является доменом сервера, a "resolve" является именем программы, исполняемой на сервере указанного домена, которая собственно и является Резолвером. Выражение "tn=TELEPHONE NUMBER" передает значение "TELEPHONE NUMBER" параметру "mm", который распознается Резолвером. В случаях, когда телефонный номер размещен вместе с кодами города и страны, браузер клиента предпочтительно запрограммирован на добавление кодов страны и города к телефонному номеру, который вводится пользователем без одного или обоих кодов. Такая информация может быть получена в качестве вторичной из установок операционной системы Window пользователя.

В другом исполнении клиент 70 устанавливает соединение с одним из сервисов 42, 44, 46, связанных с процессами Резолвера 40. Сервисы 42, 44, 46 обмениваются с клиентом 70, запрашивая и получая телефонный номер.

Так, в одном из случаев Резолвер 40 получает телефонный номер, запрошенный клиентом 70. В ответ Резолвер 40 строит Объект-спецификатор (Qualifier object) в главной памяти, который содержит телефонный номер. В блоке 506, Резолвер устанавливает связь с Индексом 30 и делает запрос о предоставлении ему сетевого адреса или URL, который соответствует телефонному номеру в запросе клиента 70. В предпочтительном исполнении запрос осуществляется путем посылки Объекту размещения индекса (Index Store object) сообщения, содержащего Объект-спецификатор. Объект размещения индекса кратко излагает или предоставляет краткое пояснение Индекса 30. Объект размещения индекса выполняет запрос к индексу.

В блоке 508 Резолвер 40 получает ответ от Индекса 30, содержащий сетевой адрес или URL, который соответствует телефонному номеру в запросе клиента 70. В предпочтительном исполнении Объект размещения индекса возвращает Объект набор записи (Entry Set object) Резолверу 40. Объект набор записи содержит или упоминает набор одной или более записей из Индекса 30, которые соответствуют запрошенному телефонному номеру. Предпочтительно Объект набор записи сформирован так, чтобы давать местоположение или URL сетевого ресурса, описанного в записи объекта.

Использование Объекта набор записи позволяет системе функционировать, когда введена только часть телефонного номера. Это в частности полезно, когда пользователь представленной системы знает только часть телефонного номера, по которому производится поиск информации. В качестве примера пользователь, который знает только четыре последних цифры телефонного номера, может ввести "3421". Объект набор записи будет содержать все записи телефонных номеров, оканчивающихся на "3421", то есть например номера "212-324-3421", "213-247-3421" и "702-397-3421", а пользователь может затем выбрать номер или соответствующий ресурс, который с его точки зрения является искомым ресурсом.

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

В блоке 510 Резолвер 40 формирует исходящее сообщение на основе ответа индекса. В предпочтительном исполнении Резолвер 40 создает XML файл, содержащий информацию из ответа Индекса 30. В предпочтительном исполнении каждый из сервисов 42, 44, 46 снабжен парсером XML, который может превращать XML файл, созданный Резолвером 40, в текст или другую информация в формате, используемом клиентом 70. В предпочтительном исполнении каждая запись, упомянутая в Объекте набор записи, также содержит значение, которое означает число раз, которое запись была разрешена (искалась или использовалась). Число использований может быть использовано для ранжирования записей во время вывода на дисплей или использовано другим способом одним из сервисов 42-46.

Предпочтительно, чтобы после разрешения каждого телефонного номера Резолвер 40 делал записи в журнал (log file) 84, которые включают телефонный номер, полное количество разрешений в прошлом, включая текущее разрешение, IP адрес и доменное имя клиента или сервера, который запросил текущее разрешение, и время, в которое произошло это разрешение.

В предпочтительном исполнении Индекс 30 и Резолвер 40 физически выполняются на одном компьютере, а Файлы Индекса 34 размещены в главной памяти этого компьютера. Такая конфигурация улучшает время ответа Резолвера 40 путем обеспечения быстрого доступа к Индексу 30. Подразумевается что Резолвер 40 отвечает на несколько десятков миллионов требований на разрешение телефонного номера в день. В предпочтительном исполнении Индекс 30 и Резолвер 40 также выполнены в виде множества программных СОМ объектов (Component Object Model или СОМ), которые обмениваются с исполняемой библиотекой AltaVista, используя API AltaVista. Лицензии на Исполняемую библиотеку AltaVista продаются компанией Digital Equipment Corporation в форме SDK AltaVista (Software Development Kit или SDK).

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

Сервисы (Services)

Сервисы 42, 44, 46 могут быть выполнены в нескольких вариантах. В одном варианте GO сервис 42 является программой компьютера, установленной или прикрепленной к браузеру 74 клиента 70. Например, GO сервис 42 установлен на клиенте 70 как плагин (plug-in) к браузеру 74. Пользователь загружает GO сервис 42 из центрального сайта дистрибуции и размещает сервис на клиенте 70. Пользователь выполняет установку программы, которая устанавливает сервис на браузер 74. После установки GO сервис 42 перехватывает телефонные номера, введенные пользователем в браузер 74, и разрешает телефонные адреса в сетевые адреса, используемые браузером 74.

На фиг.6 показана блок-схема способа функционирования GO сервиса 42 в указанной конфигурации. В блоке 600 пользователь вызывает исполнение браузера 74.

Браузер 74 имеет поле введения URL в котором пользователь по своему желанию печатает сетевой адрес документа для его извлечения и показа в браузере. В блоке 602 пользователь вводит телефонный номер в поле введения сетевого адреса. В блоке 604 GO сервис 42 захватывает удары по клавишам, производимые пользователем при печатании в поле введения сетевого адреса браузера 74, и таким образом получает телефонный номер введенный пользователем.

Далее управление передается в блок 609. В блоке 609 сервис 42 запрашивает Резолвер 40 разрешить телефонный номер, полученный от браузера в сетевой адрес. Например, сервис 42 создает URL который ссылается на предопределенное место в системе, где находится Резолвер 40. Это URL содержит в качестве параметра, передаваемого Резолверу 40 телефонный номер, полученный от браузера. Сервис 42 открывает HTTP соединение с клиента 70 на Резолвер 40, используя этот URL, содержащий телефонный номер. Резолвер 40 извлекает значение телефонного номера из URL и выполняет разрешение, как описано выше. Резолвер 40 затем возвращает значение адреса сетевого ресурса сообщением HTTP браузеру 74.

Если соответствующее значение адреса сетевого ресурса получено от Резолвера 40, в блоке 610, GO сервис 42 перенаправляет браузер 74 на сетевой адрес, найденный Резолвером 40. Например, сервис 42 извлекает значение адреса сетевого ресурса из сообщения HTTP, полученного от Резолвера 40, и передает его функциям браузера 74, которые могут загрузить и показать вэб-страницы. Браузер 74 затем грузит и показывает файл или страницу, расположенную по сетевому адресу в обычной манере. Альтернативно, если получено более одного значений расположения сетевого ресурса от Резолвера 40 в ответ на получение Резолвером 40 только части телефонного номера, то в блоке 610 сервис показывает список значений мест размещения (адресов) сетевых ресурсов. Результаты показываются в порядке от более важных к менее важным разрешениям, основываясь на значениях разрешений, обработанных и содержащихся в Статистическом сервисе (Statistics Service) 82. В другом варианте сервис возвращает клиенту 70 ответ HTTP, содержащий XML в котором содержатся результаты запроса.

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

В другом альтернативном исполнении GO сервис 42 связан с кнопкой или панелью, встроенной в вэб-страницу внешнего вэб-сервера. Кнопка или панель является закрепленным сетевым адресом или URL, который вызывает GO сервис 42, когда кнопка или панель выбрана пользователем, просматривающим внешний вэб-сервер. Такая конфигурация предоставляет возможность вводить телефонные номера не требующие использования браузера.

В другом альтернативном исполнении GO служба 42 включает механизм обнаружения и ответа на языке, используемом клиентом 70, который связывается и делает запрос в службу GO, определяя код страны таким образом. Предположим, что компьютер, на котором исполняется Служба GO 42, функционирует, используя набор символов UTF-8 и английский язык, в то время как клиент 70 использует Японский язык и кодирование другим набором символов. Когда Служба GO 42 посылает клиенту 70 вэб-страницу, содержащую форму ввода телефонного номера, вэб-страница включает скрытое поле с размещенной там предопределенной текстовой строкой. Клиент 70 получает вэб-страницу, а его браузер или операционная система превращает вэб-страницу в набор символов, который он использует. Пользователь клиента 70 вводит телефонный номер в вэб-страницу и отправляет его в Службу GO 42. Служба GO 42 получает вэб-страницу, извлекает значение скрытого поля и сравнивает это скрытое значение с таблицей или сравнивает значения скрытого поля с различными наборами кодировок символов и языками. Сервис GO 42 определяет соответствующий набор символов и язык. Используя язык (код страны), GO сервис 42 выбирает ресурс, имеющий совпадающее значение языка в секции 906 метаданных ресурса. Таким образом система определяет язык клиента, пославшего запрос, и предоставляет ему ресурс, соответствующий этому языку.

В другом альтернативном исполнении Служба GO 42 и Резолвер 40 используют значения метаданных Файла номера 64, ассоциированные с ресурсами для ответа на расширенные запросы. Например, предположим, что авиакомпания United Airlines регистрирует Файл номера 64, который описывает ресурсы на нескольких различных языках, таких как английский, французский и японский. Пользователь находит вэб-сайт, принадлежащий United Airlines, который расположен во Франции или подготовлен на французском языке. Пользователь вводит в GO Сервис 42 телефонный номер отдела бронирования United Airlines в США с добавлением к нему слова "France" вот так: "1-800-241-6522 France". Резолвер 40 сравнивает запись с полями метаданных секции 906 Описание, Регион и Язык, связанными с Файлом номера 64 компании United Airlines.

Резолвер 40 и Go сервис 42 перенаправляют браузер пользователя на сайт United Airlines, выполненный на французском языке.

В альтернативном исполнении, когда GO сервис 42 исполнен как плагин к браузеру, установленному на клиенте 70, GO, сервис предоставляет информацию по кодированию символов Резолверу 40. Чтобы получить кодировку символов, используемую в настоящий момент клиентом 70, GO, сервис 42 вызывает функцию операционной системы, которая работает на клиенте 70. GO сервис 42 добавляет информацию об используемой клиентом кодировке символов к URL, чтобы передать запрос пользователя на Резолвер 40. В таком случае Резолвер получает информацию, определяющую язык и кодировку символов, используемые в данный момент клиентом 70, и может вернуть адрес сетевого ресурса, соответствующего данному языку.

В альтернативном исполнении компьютерная система далее содержит микрофон, соединенный с аналого-цифровым преобразователем (АЦП). Этот АЦП соединен через соответствующий интерфейс с шиной компьютерной системы. Под управлением системной программы-драйвера или другой соответствующей программы АЦП получает аналоговый звуковой сигнал с микрофона и преобразовывает его в цифровой сигнал. Драйвер или другая программа получает цифровой сигнал и преобразовывает его в фонему, строку слов, ключевое слово или команду для GO сервиса 42. Преобразованный сигнал используется GO сервисом 42 как входящий сигнал, заменяющий ему ввод с клавиатуры или мышки. Таким образом пользователь может просмотреть интерфейс пользователя 1000 и наговаривать слова в микрофон, давая команды GO сервису 42 на поиск конкретных сетевых ресурсов. Таким образом пользователь использует навигацию по вэбу, применяя слова (номера) разговорного языка.

Другое альтернативное исполнение показано на Фиг.9. Служба выполнена в форме вэб-сервера или промежуточного Вэб-сервера приложений 60а. Вэб-сервер приложений 60а обменивается с клиентом 70 с помощью HTTP сообщений через Интернет 50. Вэб-сервер приложений 60а включает скрипт-процессор с интерфейсом Common Gateway Interface (CGI), сервер приложений, такой как сервер Netscape Kiva, Microsoft Active Server, или Apple WebObjects (ЗТМ). Программное приложение, исполняемое на Вэб-сервере приложений 60а, обменивается с Резолвером 40 через Интернет 50 через пути 40а, 40b используя CGI скрипты для генерации HTTP запросов и ответов. Вэб-сервер приложений 60а использует вызовы функций, предоставляемых API Резолвера 40 для связи через пути 40а, 40b. Используя такую схему Вэб-сервер приложений 60а выпускает запрос, содержащий запросы в Резолверу 40. В ответ Резолвер 40 оценивает запросы, запрашивает Индекс 30 и создает набор метаданных для всех записей индекса, отражающий вэб-страницы, которые удовлетворяют запросу. Набор метаданных упаковывается в XML файл и доставляется Резолвером 40 Вэб-серверу приложений 60а. Вэб-сервер приложений 60а имеет XML парсер (анализатор), который может анализировать код XML из XML файла. Используя проанализированный код XML, Вэб-сервер приложений 60а создает один или более HTML документы и доставляет их клиенту 70. Клиент 70 показывает HTML документы конечному пользователю.

Служба Статистики (Statistics Service)

Как описано выше в отношении Резолвера 40, каждый раз, когда Резолвер производит разрешение телефонного номера, он заносит запись об этом в журнал (log file). Система имеет Службу Статистики 82, которая отвечает за чтение журнала и загрузку информации из журнала в Файлы Индексов 34.

В предпочтительном исполнении Служба Статистики 82 функционирует периодически на основе расписания. Служба Статистики 82 считывает каждую запись журнала и создает индекс объект, основанный на информации, содержащейся в журнале. Затем Служба Статистики 82 посылает сообщение Построителю Индекса 32, который запрашивает Построитель Индекса постоянно размещать значения в Файлы Индекса 34. В ответ Построитель Индекса 32 размещает значения в Файле Индекса 34.

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

Когда выбрана опция СТАТИСТИКА И ОПЛАТА СЧЕТОВ / Статистика, система генерирует вэб-страницу 700 в форме, показанной на Фиг.7А. Вэб-страница 700 имеет список опций верхнего уровня 702. Набор функциональных кнопок 704 позволяет пользователю создавать другие глобальные функции, такие как разрешение адреса, введение информации о новом заказчике, получение услуг поддержки пользователей и расширенной информации по системе телефонных номеров.

Функциональные кнопки отчетов 706 позволяют пользователю получить доступ к функциям создания отчетов системы. В таком исполнении кнопки генерации отчетов 706 включают кнопки Выбор Записей 712, Выбор времени 714, Отчет для Записи 716, Отчет по принадлежности 718.

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

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

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

На фиг.7А приведен пример вэб-страницы, сгенерированной таким образом. График 708 содержит иллюстративную гистограмму. Каждый столбик гистограммы представляет телефонный номер, определенный в текущем Файле номера. Вертикальная ось 720 показывает число разрешений (в тысячах) для каждого телефонного номера. Горизонтальная ось 722 показывает каждый Номер, для которого приведена статистика в отчете. Статистический квадрат 710 содержит столбец 730 описания, взятого из поля Описание из Файла Номера, столбец числа разрешений 732 и столбец процентов 734. Столбец описания 730 перечисляет каждый телефонный номер и его Описание, которое определено в текущем Файле номера. Столбец числа разрешений 732 дает число разрешений телефонного номера которые произошли в течение текущего определенного периода времени. Столбец процентов 734 каждого телефонного номера показывает процент всех разрешений, приходящийся на разрешения этого телефонного номера.

На фиг.7В приведен пример графика другого типа, генерируемого службой статистики. Вертикальная ось 720 является числом разрешений каждого телефонного номера. Горизонтальная ось 722 содержит множество столбиков 738, каждый из которых ассоциирован с телефонным номером. Столбик представляет число разрешений такого телефонного номера. Вторая вертикальная ось 736 показывает процент всех разрешений произведенных системой в отношении телефонных номеров, приведенных на горизонтальной оси 722.

В таком исполнении владелец системы телефонных номеров получает оплату от конечных пользователей, которые зарегистрировали телефонные номера в Регистре 10. Библиотекарь 20 создает требование об оплате на счет каждого пользователя, когда в системе заводится новая запись через Службу Регистрации (Registration Service) 22. В другом исполнении конечные пользователи и заказчики из числа тех, кто регистрирует телефонные номера в Регистре 10, платят вознаграждение владельцу системы телефонных номеров за каждое разрешение, произведенное Резолвером 40 в ответ на требование третьих сторон. Резолвер 40 создает требование об оплате на счет каждого пользователя, после окончания каждого разрешения. В таком исполнении информации об удержании вознаграждения со счетов клиентов документируются и собираются в таблицы базы данных 12. Периодически внешняя бухгалтерская программа считывает таблицы счетов и оплат из базы данных 12 и генерирует счета, которые рассылаются пользователям. Опция меню СТАТИСТИКА И ОПЛАТА СЧЕТОВ / Статистика из списка меню 702 позволяет пользователям наблюдать и исследовать в режиме реального времени остатки по счетам и текущую оплату пользователей зарегистрированных записей телефонных номеров, а также учитывать сумму оплаты за услуги разрешения. Когда выбрана функция Оплата счетов, система считывает таблицы счетов и оплаты из базы данных 12 и генерирует на вэб-странице отчет, подытоживающий оплату услуг системы заказчиком. Эта вэб-страница посылается клиенту 70 и показывается ему.

Обзор оборудования

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

Компьютерная система 800 состоит из шины 802 или другого механизма передачи информации, а процессор 804 связан с шиной 802 для обработки информации. Компьютерная система 800 также содержит главную память 806, такую как оперативная память (random access memory или RAM) или другое устройство хранения, связанное с шиной 802 для размещения информации и инструкций, предназначенных для исполнения на процессоре 804. Главная память 806 также может использоваться для размещения временных переменных или другой промежуточной информации в процессе исполнения инструкций, предназначенных для исполнения процессором 804. Компьютерная система 800 далее содержит постоянную память (read only memory или ROM) 808 или другое устройство постоянного хранения, связанное с шиной 802 для размещения статической информации и инструкций для процессора 804. Устройство хранения 810, такое как магнитный диск или оптический диск, также присутствует и связано с шиной 802 для размещения информации и инструкций.

Компьютерная система 800 может быть связана через шину 802 с дисплеем 812, таким как электронно-лучевая трубка (ЭЛТ), для показа информации пользователю компьютера. Устройство ввода 814, включающее алфавитно-цифровые и другие клавиши, соединено с шиной 802 для обмена информацией и командами с процессором 804. Другим типом устройств ввода является управление курсором 816, такое как мышь, трекбол или клавиши управления курсором для передачи направляющей информации и выбора команд процессора 804, а также для управления движением курсора на дисплее 812. Такое устройство ввода обычно имеет две степени свободы по двум осям, первая ось (х) а вторая ось (у), которые позволяют устройству позиционироваться на плоскости.

Изобретение относится к использованию компьютерной системы 800 для предоставления реализации системы обнаружения сетевых ресурсов по их телефонным номерам. В соответствии с одним из исполнений изобретения, обнаружение сетевого ресурса обеспечивается компьютерной системой 800 в ответ на исполнение процессором 804 одной или более последовательностей инструкций, содержащихся в главной памяти 806. Такие инструкции могут быть считаны в главную память 806 с другого носителя компьютерной информации (computer-readable medium), такого как устройство хранения 810. Выполнение последовательности инструкций, содержащихся в главной памяти 806, побуждает процессор 804 выполнять шаги процесса, описанные здесь. В альтернативных исполнениях, может быть использована другая монтажная схема вместо или в комбинации с программными инструкциями для воплощения изобретения. Таким образом, применения изобретения не ограничиваются любой конкретной комбинацией схем аппаратного и программного обеспечения.

Понятие “носитель компьютерной информации” ("computer-readable medium") использовано для обозначения любого носителя, который участвует в предоставлении на исполнение инструкций процессору 804. Такой носитель, включая но не ограничиваясь, может быть энергонезависимым носителем, энергозависимым носителем, передающим носителем. Энергонезависимые носители включают, например, оптические и магнитные диски, такие как устройство хранения 810. Энергозависимые носители включают динамическую память, такую как главная память 806. Передающие носители включают коаксиальные кабели, медные провода и волоконную оптику, включая провода, составляющие шину 802. Передающие носители могут также принимать форму акустических или световых/радиоволн, таких как создаваемые в процессе обмена данными в радио или инфракрасном волновых диапазонах передачи данных.

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

Различные формы носителей компьютерной информации могут использоваться для несения одной или более последовательностей одной или более инструкций к процессору 804 для исполнения. Например, инструкции могут первоначально быть записаны на магнитный диск удаленного компьютера. Удаленный компьютер может загрузить инструкции в динамическую память и послать инструкции через телефонную линию используя модем. Модем, размещенный рядом с компьютерной системой 800, может принять данные по телефонной линии и использовать инфракрасный передатчик для преобразования данных в инфракрасный сигнал. Инфракрасный приемник, соединенный с шиной 802, может получить данные, принесенные инфракрасным сигналом, и передать данные в шину 802. Шина 802 переносит данные в главную память 806, из которой процессор 804 извлекает и исполняет инструкции. Инструкции, полученные главной памятью 806, могут по выбору быть размещены на устройстве хранения 810 до или после исполнения процессором 804.

Компьютерная система 800 также включает коммуникационный интерфейс 818, связанный с шиной 802. Коммуникационный интерфейс 818 предоставляет двухстороннюю связь, соединенную с сетевой связью 820, которая соединена с локальной сетью 822. Например, Коммуникационный интерфейс 818 может быть картой или модемом цифровой сети с комплексными услугами (integrated services digital network или ISDN) для предоставления соединения передачи данных к телефонной линии соответствующего типа. Другим примером коммуникационного интерфейса 818 может быть сетевая карта локальной сети (local area network или LAN) обеспечивающая соединение для обмена данными с совместимой локальной сетью. Беспроводные связи могут быть также использованы. В каждом таком исполнении коммуникационный интерфейс 818 посылает и получает электрические, электромагнитные или оптические сигналы, несущие потоки цифровых данных, представляющих различные типы информации.

Сетевая связь 820 обычно обеспечивает передачу данных через одну или более сетей или другие устройства данных. Например, сетевая связь 820 может обеспечивать связь через локальную сеть 822 с главным компьютером 824 или оборудованием. Интернет сервис провайдера (Internet Service Provider или ISP) 826. ISP 826 в ответ обеспечивает услуги передачи данных, через мировую сеть пакетной передачи данных часто называемую теперь Интернетом 828. Локальная сеть 822 и Интернет 828 обе используют электрические, электромагнитные или оптические сигналы, несущие потоки данных. Сигналы в различных сетях, сигналы в сетевой связи 820 и сигналы в коммуникационном интерфейсе 818, несущие цифровые данные и из компьютерной системы 800, являются иллюстративными формами несущих волн передачи информации.

Компьютерная сеть 800 может посылать и получать данные, включая программный код, через сеть (сети), сетевую связь 820 и коммуникационный интерфейс 818. В примере с Интернет, сервер 830 может передавать запрошенный код для программного приложения через Интернет 828, ISP 826, локальную сеть 822 и коммуникационный интерфейс 818. Согласно изобретению одно из таких загруженных программных приложений обеспечивает систему наименований для языкозависимых сетей, как это описано здесь.

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

Варианты; преимущества

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

Описание применений

Определения

Слой защищенных протоколов (Secure layer protocols): Secure Sockets Layer (SSL); Microsoft® Passport single sign-in (SSI); other similar.

URL. URL (Uniform Resource Locator) - это уникальный идентификатор, такой как IP адрес. Keyword, телефонный номер или DNS имя, а также любое другие, которое однозначно идентифицирует сетевые ресурсы.

IP адрес. IP (Internet Protocol) адрес является цифровым URL и представляет слой адресации под системой адресации DNS; IP адреса уникальны по определению; IP адреса могут иметь DNS имена, присвоенные им. DNS имя или Keyword не могут быть использованы, если им не сопоставлен IP адрес.

ЕТА - Единый Телефонный Адрес (UTA -Uniform Telephone Address). ETA -это телефонный номер, присвоенный сетевому Абоненту, Пользователю или Ресурсу (вместе Абоненты). Каждый Абонент имеет только один присвоенный ЕТА и потому каждый ЕТА однозначно определяет конкретного Абонента. Каждый ЕТА имеет по меньшей мере один Файл Номера, присвоенный этому ЕТА и связанный с ним. Система адресации ЕТА является уникальным слоем адресации (URL) поверх телефонных номеров, IP адресов и системы DNS имен. ЕТА совместим с системой имен Keyword компании RealNames (справка: компания RealNames прекратила существование летом 2002 года). ЕТА может быть присвоен любому сетевому Абоненту, включая ресурсы Интернет, а также телефоны с проводной или беспроводной (мобильной, спутниковой и другой) линией.

ЕТА Абонент. Абонент обладает способностью работы в “мировой паутине” или web и является сетевым объектом любой природы, устройством (как например компьютерное устройство, носителем информации, чип или процессор), программой (как например web браузер, instant messenger, программа работы с электронной перепиской и прочее), данными (как например вэб-сайт или страница и прочее), частота волны, ее модуляция или деление или их композиция (например, конкретная радиостанция). Абонент способен потребовать у сети присвоить ему URL. Существует только один уникальный ЕТА, присвоенный Абоненту.

IP адрес, определяющий точное место Абонента в Интернет, называется Первичным IP адресом и ПФН принадлежит Абоненту и доступен в месте сети, однозначно определяемом Первичным IP адресом. Все Абоненты имеют средства работы с web, такие как вэб-сервер, вэб-браузер, а также другие аппаратные и программные средства, позволяющие Абоненту управлять данными ПФН, осуществлять соединение, связь и обмен через Интернет. Для каждого Первичного Файла Номера должны быть созданы предпочтительно две зеркальные копии ПФН, называемые Главный и Вторичный Фал Номера; эти копии ПФН размещаются и доступны в режиме реального времени на свич-сервере и сервере Интернет провайдера (ISP) соответственно.

Динамические и статические IP адреса (URL) и “путешествующие” мобильные идентификаторы (ID). Каждый Абонент может быть доступен в сети, используя его URL. В Интернет Абоненты обычно имеют статические IP адреса, присвоенные им, используя выделенную линию Интернет, (как DSL, T1, другие); так называемые dial-up (доступ к Интернету с “дозвоном”) или мобильные (путешествующие) Абоненты обычно имеют временный динамический IP адрес, присвоенный им с помощью DHCP (Dynamic Host Configuration Protocol) и действительный в течение времени, когда Абонент соединен с конкретным ISP или сотой мобильной сети. Во время путешествия номера мобильных устройств запоминаются а сами устройства обслуживаются используя такие стандарты мобильного роуминга (путешествий) как ANSI-41 и GSM-MAP.

ANSI-41

ANSI-41 предоставляет поддержку для путешественников, посетивших вашу зону обслуживания, а также ваших клиентов, когда они путешествуют вне зоны вашего обслуживания. Когда путешественник регистрируется в вашей зоне обслуживания путем

использования MIN/ESN путешественника, ваш мобильный центр коммутации (mobile switching center - MSC) и Регистр посетителей зоны (visiting location register - VLR) определяют соответствующий MSC Регистра домашней зоны путешественника (HLR) для маршрутизации.

Ваш MSC направляет сообщение через сеть SS7 и, если требуется, через шлюз доступа в другие сети SS7 для передачи на MSC/HLR домашней зоны для проверки.

MSC/HLR звонящего проверяет путешественника и посылает ответ, разрешающий звонящему запрашиваемое соединение.

Когда ваш клиент путешествует вне вашей зоны обслуживания, процесс повторяется, но сообщения направляются по сети на ваш MSC/HLR.

GSM-Map

Так же, как и ANSI-41, GSM-MAP позволяет передавать важные данные о MSC/HLR/VLR регистрации и незаметном перемещении между вами и сетью вашего партнера по роумингу, и этот протокол сообщений предоставляет мгновенный доступ к улучшенным возможностям SS7, например к возможности сохранения номера (Number Portability).

Одна особенность, где транспорт GSM-MAP отличается от ANSI-41, - это администрирование путешественника. Сети GSM-MAP используют International Mobile Station Identifier (IMSI), в то время как ANSI-41 использует Mobile ID Number (MIN).

IMSI является идентификатором из 15-цифр, который создан на основе мобильного кода страны (Mobile Country Code -MCC), представляющего страну происхождения путешественника, кода мобильной сети (Mobile Network Code -MNC) определяющего родную сеть (сеть происхождения) пользователя, и, наконец, идентификационный номер мобильной станции (Mobile Station Identification Number -MSIN), который определяет конкретный мобильный узел.

Когда путешественник регистрируется в вашей зоне обслуживания путем:

телефон путешественника был включен в вашей зоне обслуживания; ваш VLR запускает запрос о регистрации на HLR путешественника. Каждый HLR идентифицируется с помощью мобильного кода страны (Mobile Country Code) и мобильного кода сети (Mobile Network Code).

HLR отвечает обслуживающему ваш VLR, а ваш VLR, в ответ, передает в MSC данные путешествующего пользователя.

Таким образом путешественник теперь зарегистрирован в вашей зоне обслуживания.

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

ЕТА Главный, Первичный и Вторичный URL. Первичный URL ЕТА - это URL,

определяющий место размещения Первичного Файла Номера ЕТА, размещенное на собственно Абоненте в Интернет. Вторичный URL ЕТА - это URL, определяющий место размещения Вторичного Файла Номера ЕТА (зеркальная копия Первичного Файла Номера), ассоциирован с ISP. Вторичный Файл Номера преимущественно размещается по месту нахождения ISP в сети Интернет. ЕТА Главный URL определяет место размещения Главного Файла Номера ЕТА на Свич-сервере в сети Интернет. Вторичный URL и Главный URL используются преимущественно, пока Абонент не доступен в режиме реального времени (находится в режиме офлайн - off-line), то есть когда Абонент недоступен по его Первичному URL, а также используется для целей проверки и верификации.

Файл Номера ЕТА. Файл Номера детально описан в заявке на патент США №10/085,717, которая является материнской к настоящему ее Частичному Продолжению (CIP). Такой Файл Номера присвоен конкретному номеру ЕТА, обозначающему Абонента сети.

Главный, Первичный и Вторичный Файлы Номера ЕТА. Файл Номера содержит метаданные, связанные с ЕТА. Файл Номера является преимущественно файлом данных в формате RDF, основанного на XML и СС/РР. Главный Файл Номера размещен по Главному URL на Свич- сервере, который описан выше. Первичный Файл Номера размещен на собственно Абоненте - устройстве, доступном в сети по Первичному URL, a Вторичный Файл Номера размещен по адресу Вторичный URL на ISP. Могут существовать также Третичный, Четвертичный и так далее URL, предоставляя разные или распределенные услуги Интернет и связь; соответственно могут существовать Третичный, Четвертичный и так далее Файлы Номера. ПФН преимущественно содержит три URL, то есть Главный, Первичный и Вторичный URLs. Главный URL всегда совпадает с Первичным URL Свич-сервера. Вторичный URL всегда совпадает с Первичным URL Интернет провайдера (ISP) Абонента. Оба Первичный и Вторичный URL предоставляются Абонентам, когда они подписываются на услуги, оба URL записываются в Первичный Файл Номера в процессе введения в эксплуатацию или выделяются сетью динамически и записываются в ПФН, когда Абонент соединяется с сетью. Оба Главный и вторичный Файлы Номера являются зеркальными копиями Первичного Файла Номера.

Содержание метаданных Файла Номера ЕТА: Метаданные преимущественно используют XML и совместимые с ним RDF и СС/РР, а также другие форматы и могут содержать следующие данные относящиеся к Абоненту:

Телефонный Номер (ЕТА).

Первичный URL. Первичный URL определен, если Абонент доступен в режиме реального времени (lo-line), и не определен, если Абонент не доступен ("off-line").

Вторичный URL

Первичный URL

Первичный URL Центра Авторизации

Первичный URL Администратора Цифровой Сертификации (если он не совпадает с таковым для свич-сервера)

Первичный URL Безопасности Сети

Номер ЕТА Центра Авторизации

Номер ЕТА Администратора Цифровой Сертификации

Номер ЕТА Безопасности Сети

Первичный Открытый Ключ (открытый ключ свич-сервера)

Вторичный Открытый Ключ (открытый ключ родного ISP Абонента)

Открытый Ключ Центра Авторизации

Открытый Ключ Администратора Цифровой Сертификации (если отличен от такового для свич-сервера)

Открытый Ключ Безопасности Сети

On-line статус. On-line статус является производным от Первичного URL.

Текущий статус доступных и дополнительно необходимых ресурсов Абонента (устройства)

Приобретенные ресурсы и текущий статус покупки (доставки/оплаты и прочее)

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

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

Методы и протоколы верификации и авторизации для предоставления доступа.

Другие метаданные, раскрытые в Материнской заявке к настоящему Частичному Продолжению.

Другие данные, предоставленные третьими сторонами, такими как Microsoft Passport или сертификаты VeriSign и прочее.

Цифровой Сертификат Администратора Цифровых Сертификатов (Свича) (предпочтительно содержит все поля Первичного Файла Номера с неизменными значениями).

Авторизованные привилегии для Шифрования методом открытых ключей (предпочтительно является частью Цифрового Сертификата).

Метаданные, размещенные в защищенном сегменте внутренней памяти Абонента:

**3апись Кредитной Карты**

**Информация Банковского Счета**

**Файл Закрытого ключа для шифрования методом открытых ключей**

**Пароль для одноразового телефона**

Проверка доступности Абонента для связи в режиме реального времени (Online status check): Описание команды "ping" для проверки IP адреса.

Команда "ping" или другая сходная проверяет доступность конкретного Абонента в сети в режиме реального времени по его IP адресу или DNS имени. Исполнение команды возможно как в ручном режиме в Windows используя путь Start - Programs - Accessories - Command Prompt. Для проверки конкретного IP адреса или URL командная строка должна быт такой:

ping <здесь надо указать IP адрес>

or

ping <здесь указать DNS имя>

Ниже приведен конкретный пример исполнения команды ping:

Microsoft Windows 2000 [Version 5.00.2195]

(С) Copyright 1985-2000 Microsoft Corp.

C:\>ping www.names.ru Pinging www.names.ru [212.24.32.169] with 32 bytes of data:

Reply from 212.24.32.169: bytes=32 time<10ms TTL=121

Reply from 212.24.32.169: bytes=32 time=10ms TTL=121

Reply from 212.24.32.169: bytes-32 time=10ms TTL=121

Reply from 212.24.32.169: bytes=32 time<10ms TTL=121

Ping statistics for 212.24.32.169:

Packets: Sent=4, Received=4, Lost=0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum=0ms, Maximum=10ms, Average=5ms

C:\>

Вэб сервер (Web server). Это сетевое устройство или программа, установленные на конкретном Абоненте сети; обычно web server предоставляет соединение с Интернет, обработку данных и скриптов и прочее. Web server поддерживает работу SSL (Слой защищенных протоколов) и потому поддерживает инфраструктуру открытых ключей PKI и ее процедуры, он может создавать Запрос на Выпуск Сертификата (Certificate Signature Request -CSR), создавать Открытый и Закрытый ключи, находить, извлекать, получать и размещать в памяти Цифровой Сертификат, выпущенный Администратором ЦС. Он может также действовать в рамках PKI в качестве Вызывающего или Принимающего Абонента инфраструктуры. Web server может быть устройством - просто чипом, таким как АСЕ1101 МТ8 или PIC12C509A/SN fhttp://world.std.com/~fwhite/ace/) или программой. Web server всегда является частью Абонента, но Абонент может не иметь собственного Вэб сервера (web server).

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

обработка адресов и нахождение по ним Абонентов в Интернет и совместимых с Вэб сетей коммуникаций; соединение с выбранными Абонентами; визуализацию статического содержания Интернет (HTML, XML, прочее.); визуализацию динамического содержания Интернет, видео- и аудиообмена в реальном времени с помощью технологий передачи изображения и голоса через IP соединение (динамические языки разметки данных, потоковые данные, VoIP и так далее). Web browser поддерживает SSL (Слой защищенных протоколов) и потому поддерживает инфраструктуру открытых ключей PKI и ее процедуры, он может создавать Запрос на Выпуск Сертификата (Certificate Signature Request -CSR), создавать Открытый и Закрытый ключи, находить, извлекать, получать и размещать в памяти Цифровой Сертификат, выпущенный Администратором ЦС. Он может также действовать в рамках PKI в качестве Вызывающего или Принимающего Абонента инфраструктуры.

Администратор Адресов ЕТА (АА). АА является центральным администратором, который содержит центральное хранилище ЕТА данных, предоставляя регистрацию ЕТА заявителям, услуги управления адресацией ЕТА и разрешения адресов ЕТА в сети и связанных с ЕТА Файлов Номеров. Свич сервер является центральным программно-аппаратным комплексом управления данными, размещенным у Администратора Адресов.

Администратор Цифровой Сертификации (АЦС). АЦС является центральным администратором PKI, предоставляя Цифровые Сертификаты для Файлов Номеров ЕТА и услуги, связанные с SSL. Предпочтительно АЦС одновременно является и Администратором Адресов (АА).

Свич-сервер (Switch server). Свич является сервером Интернет, предоставляя услуги коммутации для Абонентов, обладающих адресами ЕТА и не обладающих таковыми. Свич является Центральным Абонентом (коммутатором) сети и содержит Главные Файлы Номеров ЕТА, предоставляя Главные URL для каждого из них. Сам, будучи Абонентом сети, Свич-сервер имеет свои собственные Главный, Первичный и Вторичный Файлы Номера.

Файл Безопасности Системы. Свич-сервер и ISP могут устанавливать и применять Политику Безопасности сети для избранных или всех IP соединений, обменов, звонков и транзакций. Информационные данные Политики размещены в Файле Безопасности Системы, доступном как на Свич-сервере, так и в ISP, размещаясь соответственно в Главном и Вторичном Файлах Безопасности. Файл Безопасности может обладать собственным ЕТА номером и потому может быть доступен в сети, используя такой ЕТА Номер Безопасности. Такой Номер Безопасности ЕТА может широко известным номером, таким как 911, используемый в США, или номерами 01, 02 и 03, используемыми в России, и так далее.

Он-лайн (On-line) статус.Это статус доступности Абонента для связи в режиме реального времени. Для целей настоящей заявки понятие "on-line статус" понимается как доступность конкретного Абонента через Вэб по его Первичному URL (статус Абонента "on-line"), и понятие "off-line статус" понимается как недоступность Абонента по его Первичному URL (статус Абонента "off-line").

“Вызывающий” и “Отвечающий” абоненты. Вызывающим называется Абонент, инициирующий вызов через IP другого - Отвечающего Абонента, используя номер ЕТА последнего. Вызовы могут осуществляться как аппарат-с-аппаратом, аппарат-с-программой, программа-с-аппаратом и программа-с-программой IP вызовы. Вызывающий может предоставлять Отвечающему Абоненту свой ЕТА номер и другие метаданные из Первичного Файла Номера Вызывающего Абонента. Вызывающий Абонент может быть также анонимным лицом.

IP вызов. IP вызов является Интернет соединением между Вызывающим и Отвечающим Абонентами, установленным для обмена данными, визуального и звукового обмена типа точка-точка с использованием Интернет и протокола TCP/IP, технологий передачи изображения и звука поверх IP (voice & video over IP technology), других соответствующих средств работы с Вэб. Он может быть осуществлен как вызовы типа проводная сеть - мобильная сеть, мобильная сеть - проводная сеть, мобильная сеть - мобильная сеть, настоящее изобретение предлагает также возможность соединений типа браузер-проводная сеть, браузер-мобильная сеть, мобильная сеть -браузер, и проводная сеть-браузер, причем под мобильной сетью понимается как мобильная сотовая, так спутниковая или любая другая беспроводная связь. В защищенном режиме IP вызов может использовать любые известные алгоритмы и методы шифрования, такие как RSA, Диффи-Хелмана и другие, SSL, MS SSI и PKI.

Оператор связи - ISP (Service Provider). Под Оператором связи или ISP в заявке понимаются компании, предоставляющие услуги связи с возможностью доступа в сеть Интернет. Будучи Абонентом, каждый ISP может иметь свои Главный, Первичный и Вторичный Файлы Номера.

Точка продаж и обслуживания (Point Of Sales -POS). POS терминалы - это узел сети, наделенный номером ЕТА, предоставляющий услуги обмена данными, поддержки продаж и проведения транзакций. Каждый POS может быть наделен номером ЕТА и потому может быть Абонентом в сетях, предоставляющих доступ в Интернет.

Реализация

Использование предпочтительных стандартных способов аутентификации (установление подлинности). Рекомендации к стандарту Х.501 (Х.501 recommendations).

Службы каталогов Х.509 (Х.509 directory services); Протокол служб каталогов Х.519 (Х.519 directory services protocol); Предпочтительное использование IETF Kerberos (http://www. ietf. org/html. charters/krb-wg-charter.html): Синтаксис шифрованных сообщений (Cryptographic Message Syntax -CMS); другое.

Цифровые сертификаты, вопросы шифрования: Интернет Х.509, сертификаты PKI могут использоваться в соответствии со спецификацией IETF "Use of ECC Algorithms in CMS", расположенной в Интернет по http://search.ietf.org/intemet-drafts/draft-ietf-smime-ecc-06.txt для распространения открытых ключей. Использование алгоритмов и ключей ЕСС в рамках Х.509 сертификатов описано в работах:

- L.Bassham, R.Housley and W.Polk, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL profile", PKIX Working Group Internet-Draft, November 2000.

- FIPS 186-2, "Digital Signature Standard", National Institute of Standards and Technology, 15 February 2000.

- SECG, "Elliptic Curve Cryptography", Standards for Efficient Cryptography Group, 2000. Документ доступен по адресу www.secg.org/collateral/secl.pdf.

Финансовые услуги и проведение транзакций: Предпочтительно используется стандарт ANSI X9.62-1998, "Public Key Cryptography For The Financial Services Industry:

The Elliptic Curve Digital Signature Algorithm (ECDSA)", American National Standards Institute, 1999; Язык разметки электронный коммерческих документов (Electronic Commerce Markup Language - ECML)

Создание Первичного Файла Номера (Primary Number File -PNF). Когда пользователь впервые становится клиентом услуг, основанных на использовании номера ЕТА, он предоставляет Администратору Адресов и Администратору Цифровых Сертификатов всю необходимую информацию, включая его ЕТА номер, и на основе этой информации формируется Первичный Файл Номера (ПФН). Для использования ПФН для осуществления транзакций и услуг SSL, Администратор Цифровых Сертификатов - АЦС выпускает Цифровой Сертификат (ЦС), позволяющий использовать SSL и PKI. Открытая часть информации для PKI размещается в ЕТА ПФН и доступна другим пользователям PKI, а закрытая часть размещается в защищенном сегменте памяти Абонента. ЦС подписывается Закрытым ключом АЦС и содержит по меньшей мере номер ЕТА и Открытый ключ Абонента. ЦС соответствует формату X.509; номер ЕТА содержится в X.509 - расширении.

Предоставление Первичного URL и синхронизация с Первичным Файлом Номера: Каждый раз, когда Абонент входит в сеть, сеть его регистрирует и присваивает ему Первичный URL; после наделения Первичным URL этот URL предпочтительно передается Абоненту и размещается в метаданных Первичного Файла Номера; значение Первичного URL затем предпочтительно размещается во Вторичном Файле Номера (на ISP) и в Главном Файле Номера (на Свич-сервере). Во время регистрации в сети, Свич предпочтительно аутентифицирует (устанавливает подлинность) Абонента, используя ЦС Абонента; Затем Абонент синхронизирует поля ПФН с соответствующими полями Главного и Вторичного Файлов Номера. Для этого Абонент извлекает значения полей Главного и Вторичного URL из ПФН и, используя их, устанавливает соединение с Главным и Вторичным Файлами Номера соответственно; когда соединение установлено Абонент начинает синхронизацию метаданных. Для авторизации и верификации Абонентом и для предотвращения доступа подставных лиц (самозванцев) к ресурсам сети, Свич-сервер, ISP или любой другой Абонент или посетитель сети с помощью процедур SSL может извлечь ЦС из ПФН, расшифровать его, используя Открытый ключ АЦС, и получить по меньшей мере номер ЕТА и Открытый ключ, принадлежащие Абоненту; затем, обмениваясь по SSL, проверяющее лицо может убедиться, что Абонент не играет роль реального Абонента, а является таковым и имеет соответствующие привилегии.

Обновление Вторичного и Главного Файлов Номера: ISP постоянно и своевременно обновляет Вторичный Файл Номера, устанавливая соединение с Первичным и/или Главным Файлами Номера. Доступность Абонента в режиме реального номера (статус - "on-line") может быть также установлена обычными способами через операторов услуг связи и затем в формат Файла Номера и размещена во Вторичном Файле Номера.

Обновление Главного Файла Номера:

Метод 1: Свич-сервер постоянно и своевременно обновляет Главный Файл Номера, извлекая данные (Свич - пул метод) или получая данные (ISP пуш метод) из Вторичного Файла Номера Абонента; если из сети получен вызов конкретного Абонента, Свич-сервер извлекает Первичный URL этого Абонента из Главного Файла Номера и, если Первичный URL определен, то Свич устанавливает соединение с ним; Если соединение не устанавливается, Свич разрывает связь и присваивает Первичному URL в Главном Файле Номера значение “ноль”, а значение поля статуса устанавливается равным "off-line". В другом случае "on-line статус" Абонента может быть получен, используя другие собственные возможности ISP, и затем извлечены с ISP и размещены на Свич-сервере для каждого конкретного Абонента. Альтернативно Свич-сервер может постоянно проверять командой типа “ping” всех Абонентов, используя их Первичные URL и проверяя таким образом их "on-line статус" постоянно. Каждый раз, когда заканчивается проверка on-line статуса, Свич обновляет поле статуса в Главном Файле Номера каждого Абонента /ЕТА.

Метод 2: Попадая в зону действия сети, каждый Абонент устанавливает соединение со Свич сервером и синхронизирует метаданные своего Первичного Файла Номера с Главным Файлом Номера. Свич постоянно и своевременно соединяется с каждым конкретным Абонентом и обновляет значения полей Главного Файла Номера данными взятыми (Свич-пул метод) или полученными (Абонент пуш метод) из Первичного Файла Номера Абонента; когда получен вызов из сети для конкретного Абонента, Свич- сервер извлекает Первичный URL Абонента из Главного Файла Номера и, если Первичный URL не равен нулю, Свич устанавливает с ним соединение. Если он равен нулю или соединение не удается установить, Свич разрывает соединение и устанавливает значение “ноль” в поле Первичного URL Абонента, а в поле статуса значение "off-line".

Делая Исходящий IP вызов: когда в адресную строку Интернет браузера или другой программы работы с Интернет введен ЕТА номер Вызывающего Абонента, Вызывающий Абонент устанавливает связь и обменивается данными со Свич-сервером, как это описано в материнской Заявке к настоящему Частичному Продолжению, и получает метаданные Отвечающего Абонента из его Главного Файла Номера; если ЕТА Первичный URL Отвечающего Абонента не равен нулю, то Вызывающий Абонент пытается установить связь с Отвечающим Абонентом, используя его ЕТА Первичный URL, взятый из Главного Файла Номера Отвечающего Абонента; если Первичный URL действителен (актуален) и Абонент отвечает, то Вызывающий Абонент и Отвечающий предоставляют друг другу свои ЦС и делают проверку в соответствии с действующей политикой безопасности сети; в зависимости от политики Вызывающий может получить доступ к Первичному Файлу Номера Отвечающего и обратно Отвечающий может проверить Первичный Файл Номера Вызывающего; Вызывающий и Отвечающий обрабатывают данные безопасности, следуя установленным процедурам политики безопасности, получая доступ данным и обмениваясь данными с Отвечающим Абонентом, если позволяют делать привилегии. При этом используется преимущественно Протокол Начала Сессии IETF (IETF Session Initiation Protocol) или сходный с ним для обмена между Вызывающим и Отвечающим Абонентами.

Когда Первичный URL Отвечающего Абонента действителен и Вызывающий Абонент соединился с Отвечающим Абонентом, но последний не отвечает (“не снимает трубку”), Вызывающий Абонент пытается оставить сообщение в памяти устройства Отвечающего Абонента;

Когда Первичный URL не действителен или равен нулю, Браузер извлекает Вторичный URL и пытается обнаружить в сети Вторичный Файл Номера и так далее и, когда найден очередной URL, который ответил, вэб браузер позволяет составить и оставить там сообщение любого типа.

Отвечая входящий IP вызов: когда получен IP вызов, Отвечающий Абонент автоматически переходит в соответствующий режим “ответить”/“отказать в ответе” или другой режим, звонит или другим способом дает знать о входящем соединении (звонке);

Отвечающий Абонент пытается извлечь номер ЕТА и ЦС из Первичного Файла Номера Вызывающего Абонента; Отвечающий Абонент может проверить действительность ЕТА и ЦС, а также привилегии Вызывающего Абонента, используя PKI. После проверки Отвечающий Абонент принимает решение предоставить или отказать в соединении Вызывающему Абоненту в соответствии с политикой безопасности и осуществления вызовов, привилегиями и предпочтениями обеих сторон, определенными в метаданных их Файлов Номеров и их ЦС. Если потребовалось установить защищенное соединение, то обе стороны начинают шифровать обмен данными, используя SSL и PKI, а также свои Открытые и Закрытые ключи. Режим Защищенной связи позволяет осуществить покупки, расплатиться и использовать другие услуги и транзакции в защищенном режиме. Когда проверка, верификация, аутентификация завершена, то сторонами используется преимущественно протокол “IETF Session Initiation Protocol” или сходный с ним для обмена между сторонами.

Включение и выключение списков абонентов. Каждый конкретный Абонент имеет список других сетевых Абонентов, так или иначе относящихся к этому конкретному Абоненту (то есть список телефонов друзей, партнеров, родственников и т.д.). Список может быть разделен по меньшей мере преимущественно на следующие части: те Абоненты, которым не позволено видеть on-line статус этого конкретного Абонента; те Абоненты, которым разрешено видеть on-line статус этого конкретного Абонента; те Вызывающие Абоненты, которым не позволено устанавливать соединение с этим конкретным Абонентом; те Вызывающие Абоненты, которым позволено устанавливать соединение с этим конкретным Абонентом, и т.д. Поэтому каждый Вызывающий Абонент может проверить и получить "on-line статус" только для тех Абонентов сети, которые позволили этому Вызывающему Абоненту его проверять. Перед осуществлением соединения с конкретным Абонентом Вызывающий Абонент может проверить, доступен ли (on-line) Отвечающий (вызываемый) Абонент в сети, и если Отвечающий Абонент в сети не доступен (off-line), Вызывающий Абонент может отказаться от попытки устанавливать соединение и сэкономить время таким образом.

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

абонент заполняет все необходимые поля Первичного Файла Номера (предпочтительно все поля ПФН с неизменными значениями), после чего генерирует файл Требования Подписания Сертификата (Certificate Signature Request -CSR), а также Закрытый и Открытый ключи; Закрытый ключ сохраняется в защищенном сегменте памяти Абонента.

Абонент предоставляет CSR и Открытый ключ для подписи АЦС.

Файл Открытого ключа и Первичный Файл Номера ЕТА шифруются (подписываются) Закрытым ключом АЦС, и этот зашифрованный файл представляет собой Цифровой Сертификат ЕТА.

АЦС подписывает CSR и возвращает его Абоненту в качестве Цифрового Сертификата Абонента (ЦС). ЦС включает ЕТА и подписан АЦС цифровым способом.

Абонент размещает ЦС в Первичном Файле Номера Абонента и делает его доступным для процедур SSL.

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

Простая Аутентификация в незащищенном режиме (SSL не используется):

извлекается ЕТА из Первичного Файла Номера Вызывающего Абонента; извлекается Главный, Первичный и Вторичный Файлы ЕТА Номера Вызывающего Абонента;

проверяются ЕТА, номер Вызывающего Абонента путем сравнения ключевых данных, взятых из Вторичного и Главного Файла Номера с соответствующими взятыми из Первичного Файла Номера; если данные совпали, то проверка (верификация) закончена благополучно и Вызывающему Абоненту разрешается использовать затребованные им услуги и Абоненту предоставляется верификация Свича.

Строгая аутентификация в защищенном режиме (SSL используется) здесь Абонент А (А) аутентифицирует Абонента В (В):

B:

Шифрует Данные В, используя Закрытый ключ В, формируя Данные В1, Создает проверочное сообщение, содержащее ЦС В и Данные В1, Передает Абоненту А проверочное сообщение, а

А:

Извлекает ЦС В и Данные В1 из проверочного сообщения

Расшифровывает ЦС В, используя Открытый ключ АЦС

Извлекает Данные В и Открытый ключ В из расшифрованного ЦС В

Расшифровывает Данные В1, используя Открытый ключ В и формируя Данные А

Сравнивает Данные А с Данными В и, если Данные А идентичны Данным В, то А делает вывод, что В владеет правильным и сертифицированным АЦС Закрытым ключом В, а также проверенными Данными В, поэтому В аутентичен.

Здесь Данные В предпочтительно являются частью ЦС В и ЕТА В; или другими полями ЦС В, или некоторыми или всеми полями ЦС В; или полным ЦС В.

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

Верификация, аутентификация и авторизация Отвечающим Абонентом. Для авторизации и верификации Вызывающий Абонентов и для предотвращения неавторизованного доступа самозванцев к ресурсам Абонента, используя поддельный Первичный Файл Номера ЕТА Вызывающего Абонента, конкретный Абонент через SSL

Извлекает Цифровой Сертификат из Первичного Файла Номера Вызывающего Абонента; расшифровывает ЦС с помощью Открытого ключа АЦС (Свича); проверяет действительность ЦС; аутентифицирует Вызывающего Абонента; предоставляет Вызывающему Абоненту соединение с Отвечающим Абонентом с учетом привилегий Вызывающего Абонента, если он проверку прошел благополучно, и отказывает ему в соединении, если он проверку не прошел.

Верификация, аутентификация и авторизация Вызывающим Абонентом. В порядке проверки, что соединение произошло с настоящим, а не поддельным Отвечающим Абонентом, и чтобы предотвратить неавторизованный доступ самозванцев к ресурсам Вызывающего Абонента с использованием его ПФН, в процессе установления соединения с Отвечающим Абонентом Вызывающий Абонент извлекает ЦС Отвечающего Абонента из его ПФН; расшифровывает данные ЦС, используя Открытый Ключ АЦС (Свича); верифицирует Номер ЕТА Отвечающего Абонента и проверяет его привилегии.

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

Услуги проведения транзакций через IP соединение могут быть предоставлены на основе соответствующей Политики Безопасности Сети (Network Security policy) и привилегий пользователей с использованием слоя Secure Socket Layer (SSL), инфраструктуры PKI и услуг АЦС номеров ЕТА. Метод шифрования Открытым ключом позволяет проверить номера ЕТА через Инфраструктуру шифрования методом открытых ключей - PKI (Public key cryptography infrastructure). Слой SSL (secure socket layer) позволяет использовать PKI для проведения защищенных транзакций электронной и мобильной коммерции, предоставления банковских услуг, услуг обмена данными и обменом в режиме реального времени. Все они основаны на использовании ЦС и содержания Сертификатов. Платежи между Покупателем и Продавцом могут быть осуществлены, используя процедуры, сходные с осуществлением авторизацией оплаты по кредитной карте, как это описано ниже:

Сообщение Покупателя

"Сообщение Покупателя" является сообщением, созданным Абонентом Покупателем. "Сообщение Покупателя" содержит предпочтительно:

ЦС Продавца

Первичный URL Продавца (не обязательно)

Данные о покупке (денежная единица и сумма покупки, время покупки, номер покупки/транзакции и другая необходимая информация о покупке).

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

Сообщение Продавца

"Сообщение Продавца" является сообщением, созданным Абонентом - Продавцом. "Сообщение Продавца" содержит предпочтительно:

ЦС Покупателя

Первичный URL Покупателя (не обязательно)

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

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

Авторизация

"Авторизация" является сообщением, составленным Центром Авторизации. "Авторизация” содержит предпочтительно:

ЦС Покупателя

Первичный URL Покупателя (не обязательно)

"Сообщение Покупателя", подписанное Закрытым ключом Покупателя.

Данные о покупке (денежная единица и сумма покупки, время покупки, номер покупки/транзакции и другая необходимая информация о покупке).

"Авторизация" является авторизацией, подписанной цифровым способом, то есть зашифрованной с использованием Закрытого ключа Центра Авторизации.

Метод авторизации "Оплата"

Содержит шаги:

Устанавливается проводное или беспроводное соединение между Покупателем и Продавцом.

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

Устройство Абонента ожидает получение разрешения (авторизация) Покупателя на совершение покупки и если разрешение получено:

Предпочтительно выполняется Строгая взаимная аутентификация Покупатель/Продавец в защищенном режиме связи

Если Продавец и Покупатель аутентичны. Покупатель:

Составляет "Сообщение Покупателя"

Устанавливает соединение с Центром Авторизации, используя Первичный URL

Центра Авторизации

Выполняет Строгую взаимную аутентификацию с Центром Авторизации в защищенном режиме связи, если это требуется

Передает "Сообщение Покупателя" в Центр Авторизации

Центр Авторизации:

Расшифровывает "Сообщение покупателя", используя Открытый ключ Покупателя, взятый из ЦС Покупателя в процессе Аутентификации и

Центр Авторизации

Составляет сообщение "Авторизация"

Передает сообщение "Авторизация" Покупателю

Покупатель передает "сообщение Авторизация" Продавцу

Продавец расшифровывает сообщение "Авторизация", используя Открытый ключ Центра Авторизации

Или Центр Авторизации:

Разрешает (запрашивает поиск) через Свич-сервер Первичный URL Продавца, используя номер ЕТА Продавца, взятый из ЦС Продавца; ИЛИ берет Первичный URL Продавца из "Сообщения Покупателя"

Устанавливает соединение с Продавцом, используя Первичный URL Продавца

Аутентифицирует Продавца и, если Продавец аутентичен:

Проверяет (верифицирует) стороны сделки и данные о покупке

Составляет сообщение "Авторизация"

Передает сообщение "Авторизация" Продавцу

Продавец расшифровывает сообщение "Авторизация", используя Открытый ключ Центра Авторизации

Продавец разрешает продажу (передачу Покупателю товара/услуги), если оплата авторизована Центром Авторизации

Метод авторизации "Удержание"

Включает шаги:

Устанавливается проводное или беспроводное соединение между Покупателем и Продавцом

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

Устройство Абонента ожидает получение разрешения (авторизация) Покупателя на совершение покупки и, если разрешение получено:

Предпочтительно выполняется Строгая взаимная аутентификация Покупатель/Продавец в защищенном режиме связи

Если Продавец и Покупатель аутентичны. Покупатель:

Составляет "Сообщение покупателя"

Передает "Сообщение Покупателя" Продавцу; и Продавец:

Расшифровывает "Сообщение Покупателя", используя Открытый ключ Покупателя, взятый из ЦС Покупателя, и верифицирует данные о покупке, если это предписано политикой, используемой, и если данные о покупке корректны, то

Составляет "Сообщение Продавца"

Устанавливает соединение с Центром Авторизации, используя Первичный URL Центра Авторизации

Выполняет Строгую взаимную аутентификацию с Центром Авторизации в защищенном режиме, если это требует политика безопасности и если аутентичность сторон установлена:

Передает "Сообщение Продавца" в Центр Авторизации; а Центр Авторизации:

Расшифровывает "Сообщение Продавца", используя Открытый ключ Продавца, извлекает и расшифровывает "Сообщение Покупателя", используя Открытый ключ Покупателя, взятый из ЦС Покупателя

Верифицирует стороны сделки и данные

Составляет сообщение "Авторизация"

Передает сообщение "Авторизация" Продавцу

Продавец расшифровывает сообщение "Авторизация", используя Открытый ключ Центра Авторизации

Продавец разрешает продажу, если авторизация оплаты получена

Запись Кредитной Карты. Запись Кредитной Карты (ЗКК) является типичной записью, размещенной на кредитной карте. ЗКК обычно записана на магнитную полосу кредитной карты или содержится во внутренней памяти смарт-карты или в другой памяти кредитной карты.

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

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

Временные ЕТА. Чтобы снизить стоимость звонков и увеличить гибкость и доступность услуг связи, АЦС (Свич) может выпускать Временные ЦС, содержащие номера ЕТА, последние используются для одноразовых телефонных трубок с возможностью связи через Интернет, а также для браузеров Интернет и других сетевых объектов/Абонентов, которые все вместе называются Временными Абонентами (ВА); все они могут устанавливать соединения в качестве Вызывающего или Отвечающего Абонентов в сети. АЦС (Свич) выпускает ЕТА и ЦС ЕТА; размещает ЕТА и ЦС непосредственно в Файле номера ВА или передает их реселлерам, которые присваивают эти ЕТА/ЦС конкретным ВА, размещая их в Первичном Файле Номера ВА.

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

Режим Псевдостатического ЕТА: Если пользователь хочет использовать конкретный ЕТА номер, трубка предпочтительно требует ввести "Пароль для временного ЕТА номера" для проверки прав пользователя на использование ЕТА (такой пароль сходен по использованию с персональными номерами идентификации для SIM карт GSM телефонов); когда пароль введен, трубка устанавливает соединение с сервером Администратора, выпустившего номер ЕТА (АА,Свич-сервер, ISP, реселлер) через слой SSL и проверяет "Пароль для временного ЕТА номера" или сравнивает пароль с зашифрованным паролем, размещенным в защищенной памяти трубки; если проверка прошла успешно (пароль верный), пользователю предоставляется доступ к ресурсам сети, используя выбранный ЕТА, а сам пользователь признается законным владельцем ЕТА; если проверка не увенчалась успехом, то трубке может быть отказано в предоставлении ресурсов сети или она может быть объявлена украденной в зависимости от того, что предусмотрено политикой безопасности сети, или

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

Режим Динамических ЕТА: Когда после приобретения трубки пользователь включает ее в первый раз, трубка устанавливает соединение со Свич-сервером через Интернет; Свич-сервер регистрирует трубку в сети и присваивает ей Динамический номер ЕТА и Главный Файл Номера; Главный Файл Номера является копией Первичного Файла Номера ЕТА; Динамический ЕТА может быть использован только в течение конкретного соединения, если только пользователь не потребует закрепить за ним номер ЕТА на стандартный период времени или на других стандартных условиях использования. Динамический ЕТА отзывается после завершения соединения или присваивается Временному Абоненту на стандартный период времени по требованию пользователя. Для удержания Динамического номера ЕТА на стандартных условиях трубка должна быть способна обновлять свой Первичный Файл Номера конкретным динамическим ЕТА, а АЦС должна выпустить ЦС, содержащий ЕТА, и присвоить ЦС трубке, как это описано выше.

Использование ПФН в качестве данных Цифрового Удостоверения Личности.

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

Шифрование сессий с использованием укороченных Пар ключей. Для

ускорения шифрования передачи потоков звука и изображения в режиме реального времени Абоненты могут использовать Короткие сессионные Пары ключей. Для этого каждый Абонент:

- Генерирует новую Пару коротких ключей (Открытый и Закрытый)

- Закрытый ключ сохраняется в Защищенном сегменте внутренней памяти Абонента и используется только в течение одной сессии связи

- Каждый Абонент шифрует новый короткий Открытый ключ с помощью Оригинального Закрытого ключа, Отсылающего Абонента, или с помощью Оригинального Открытого Ключа, Получающего Абонента, и передает зашифрованный таким образом Короткий Открытый ключ Получающему Абоненту

- Получающий Абонент расшифровывает сообщение, содержащее Короткий Открытый ключ противоположного Абонента, и использует его для шифрования/де шифрования обмена данными (потоковыми данными) с Отсылающим Абонентом.

ИЛИ альтернативно:

Каждый из Абонентов создает Пару новых коротких ключей таким образом, что Короткий открытый ключ каждого Абонента является простым числом некоторым по счету ближайшим с недостатком или избытком к номеру ЕТА (или номеру, вычисляемому на основании ЕТА установленным в сети способом), причем близость в номеру ЕТА определяется текущей Политикой Безопасности сети, а Закрытый короткий ключ каждым Абонентом подбирается так, чтобы быть практически весьма трудно вычисляемым.

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

Таким образом каждый Абонент имеет Короткий Открытый ключ

противоположного Абонента и использует его для шифрования/дешифрования обмена данными (потоковыми данными) с противоположным Абонентом.

Понятно, что в Инфраструктуре Открытых Ключей Абоненты могут шифровать сообщения (потоки) двумя способами:

175. с использованием Закрытого ключа Отсылающего Абонента, причем Получающий Абонент расшифровывает его Открытым ключом Отсылающего Абонента. Зашифрованное сообщение в этом случае может быть расшифровано любым Абонентом, имеющим открытый ключ Отсылающего Абонента, и тайна переписки НЕ гарантирована

176. с использованием Открытого ключа Получающего Абонента, причем Получающий Абонент расшифровывает сообщение, используя свой Закрытый ключ. Зашифрованное сообщение в этом случае НЕ может быть расшифровано никем, кроме Получающего Абонента, и тайна переписки ГАРАНТИРОВАНА

Бизнес модель 1: продажа номеров ЕТА, которые действительны в течение некоторого периода времени или на количество предоставленных услуг или на определенную сумму денег и так далее.

Бизнес модель 2: продажа Цифровых Сертификатов, где номер ЕТА является главной верифицируемой частью сертификата, привилегии содержат условия использования, которые действительны в течение некоторого периода времени или на количество предоставленных услуг или на определенную сумму денег и так далее.

Бизнес модель 3: Продажа ПФН с постоянным ЕТА номером для постоянных Абонентов или без постоянного ЕТА номера для Временных Абонентов.

Бизнес модель 4: Продажа медиа-носителей (SIM карты для GSM и более поздних версий стандартов 3-го поколения связи (3G standards), CD, DVD, или другие медиа-носители) с ПФН файлами, записанными на такие носители.

Бизнес модель 5: Продажа записываемых чипов памяти или процессоров с ПФН файлами, записанными в память.

Бизнес модель 6: Продажа ПФН в качестве Цифрового Удостоверения Личности.

Бизнес модель 7: Продажа “разрешений” номера ЕТА и /или Файла Номера (транзакций поиска Первичного URL по известному ЕТА номеру/ Файлу Номера) с оплатой за каждое “разрешение”.

Бизнес модель 8: Продажа номера ЕТА и/или данных Файла Номера третьим сторонам с оплатой за каждое предоставление ЕТА и/или данных Файла Номера.

Бизнес модель 9: Продажа услуг аутентификации номера ЕТА и/или данных Файла Номера с оплатой за каждую аутентификацию.

Бизнес модель 10: Продажа услуг Авторизации оплаты по номеру ЕТА и/или данным Файла Номера с оплатой за каждую авторизацию.

Бизнес модель 11: Продажа средств разработки (Software Development Kit-SDK), реализующих функциональность использования ЕТА указанными в заявке методами.

Сведущие и профессионалы оценят также возможность использования Записи Кредитной Карты (ЗКК) или записи банковского счета, зашифрованной с использованием Закрытого ключа Центра Авторизации. Такая реализация предоставляет возможность ограничить до одной число сторон, способных прочесть ЗКК, и такой единственной стороной является Центр Авторизации. Благодаря этому такая реализация обеспечивает устойчивую безопасность при проведении транзакций и защиту от воровства с высочайшим уровнем безопасности. Другой особенностью является то, что такая реализация позволяет использовать обычные существующие устройства авторизации платежей с использованием основных видов кредитных карт и потому делает реализацию заявленного способа авторизации очень недорогой. Использование Зашифрованной ЕТА-ЗКК (3-ЕТА-ЗКК) делает аутентификацию вдвое более надежной, позволяя сравнить ЕТА, извлеченный из 3-ЕТА-ЗКК, с ЕТА, извлеченным из ЦС.

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

Сведущие и профессионалы оценят также то, что благодаря выпуску Цифрового Сертификата Счета (ЦСС), содержащего ЕТА (Единый Транзакционный Адрес) сетевого ресурса, а также Открытый ключ ресурса и ЗЗС ресурса, ЦА/УЦ (Центр Авторизации и он же Удостоверяющий Центр - ранее также называемый Администратором Цифровой Сертификации - АЦС) получает возможность “на лету” аутентифицировать конкретный сетевой ресурс и проверить права этого ресурса на использование конкретной ЗЗС, безопасно и надежно сопоставляя ЗЗС такому ресурсу для предоставления услуги проведения защищенных транзакций. Это, в свою очередь, позволяет ЦА/УЦ избежать создания, управления и безопасного содержания базы данных, устанавливающей соответствие между ЗЗС/ЗКК и ЕТА конкретного сетевого ресурса, а последнее обстоятельство, как следствие, позволяет ЦА/УЦ избежать расходов, связанных с наличием такой базы данных. С другой стороны, отсутствие базы данных позволяет ЦА/УЦ освободиться от возможных ошибок системы безопасности содержания финансовых и персональных данных базы данных.

Другой особенностью является то, что ЗЗС позволяет использовать обычную существующую инфраструктуру авторизации основных систем кредитных карт, а потому делает заявленный способ очень недорогим в реализации, практически сводя потребности ЦА/УЦ к наличию единственного POS (point-of-sales) терминала и использованию единственного счета продавца (merchant account) системы приема и обработки платежей кредитных карт.

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

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

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

Инфраструктура проведения транзакций

Инфраструктура проведения транзакций в качестве примера показана на фиг.10 и содержит сетевые ресурсы 1000, каждому из которых присвоен идентификатор ЕТА (Единый Транзакционный Адрес), сетевые ресурсы финансовых институтов 1001 и 1002, каждый из которых имеет присвоенный ему идентификатор ЕТА и инфраструктуру авторизации и клиринга 1003. Каждый сетевой ресурс представляет собой Плательщика или Получателя платежа, а финансовые институты являются организациями, предоставляющими финансовые счета (это предпочтительно банки) для указанных Получателей платежей и Плательщиков, а инфраструктура представляет собой систему авторизации и клиринга транзакций, которая в соответствии с иллюстрацией является расчетным (клиринговым) финансовым учреждением, предоставляющим клиринговые счета другим приведенным на фиг.10 финансовым институтам.

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

Описываемый способ предполагает создание специфических “основанных на нуле” МЕТА идентификаторов системы. Такой метод позволяет назначить зону с “нулевым” кодом страны, содержащую 100 миллиардов доступных номеров и, в частности, номер “полного нуля” +0-000-000-0000; а также “нулевую зону”, такую как [phone], содержащую до 1 миллиона доступных номеров для каждой страны; а также “основанный на нуле” массив номеров в каждом регионе каждой страны, предоставляющий до 1 миллиона дополнительных ЕТА номеров для каждого кода региона, например массив от [phone] до [phone] специально для целей авторизации в регионе Москвы, Россия. Например, для Глобальной Регистратуры идентификаторов ЕТА или Глобальной Палаты Клиринга и Авторизации 1101 транзакций, как показано на фиг.11, может быть присвоен ЕТА из числа идентификаторов “полного нуля”, а для местных узлов авторизации может быть использован например ЕТА с нулевым номером страны, региона или номер, начинающийся с нуля, такой, например, как 000-ОООХ.

По аналогии банковской системой ЕТА финансового счета конкретного ресурса для глобальной адресации и доступности должен включать как ЕТА самого ресурса, так и МЕТА номер финансового института в сети и потому глобальный маршрутный номер будет иметь МЕТА/ЕТА формат. Например запись [phone]/[phone] могла бы означать, что ресурс, относящийся к России и региону 095 города Москвы, имеющий присвоенный ему идентификатор ЕТА [phone], обслуживается финансовым институтом, расположенным также в России, в 095 регионе Москвы и имеющим присвоенный ему маршрутный идентификатор МЕТА [phone].

Таким же способом могут быть обозначены корреспондентские отношения между самими банками, образуя “сложные” МЕТА, содержащие последовательность МЕТА номеров соответствующих банков. Например, как показано на фиг.10, МЕТА2/МЕТА1/ЕТА будут означать что конкретный ЕТА ресурс является клиентом конкретного банка МЕТА1, а сам банк МЕТА1 имеет корреспондентский счет в банке МЕТА2. Это позволяет организовать очень простую маршрутную систему адресации путем размещения соответствующей маршрутной МЕТА информации в Файле Ресурса. Это также позволяет создать инфраструктуру, в которой независимо от собственного места расположения ресурса или его банка каждый конкретный ресурс может выбрать любой конкретный банк для обслуживания собственного счета, а также использовать множество банковских счетов и счетов кредитных карт.

В каждом коде региона конкретной страны финансовые институты могут быть проиндексированы, используя обычные ЕТА, хотя система МЕТА идентификаторов представляется предпочтительной и дает возможность последовательной нумерации, при которой первый присвоенный МЕТА внутри конкретного кода региона имеет “0” в качестве значения крайнего правого разряда, следующий “1”, следующий “2” и так далее, причем номер завершается до размера полного телефонного номера путем добавления нулей слева. Последний ЕТА в таком массиве начинался бы "0", имея далее только цифры "9". Поэтому для примера первый МЕТА, присвоенный в России в регионе 095 Москвы, был бы [phone], а второй [phone], следующий [phone] и последний [phone].

Описанный “нулевой” способ присвоения МЕТА номеров позволяет использовать “нулевые” номера для предоставления услуг проведения транзакций и для создания базы данных МЕТА номеров, имеющих последовательную нумерацию. Этот массив доступных номеров начинается с 000-0000 до 099-9999 для 7-цифровой телефонной нумерации и предоставляя до 1 миллиона доступных маршрутных номеров внутри каждого кода региона каждой страны.

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

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

Как показано, изобретение позволяет использовать идентификаторы ЕТА также и для целей маршрутизации. ЕТА представляют собой более высокий слой идентификации, расположенный поверх традиционных систем маршрутизации в Интернет и коммуникационных сетей и для финансовой инфраструктуры. Поэтому ЕТА слой расширяет, объединяет и унифицирует адресацию в Интернет и сетях телекоммуникаций и адресацию финансового обмена и маршрутизации, он также создает универсальный транспортный слой ISO/OSI для сетевых ресурсов любой природы.

Инфраструктура системы Клиринга и Авторизации

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

В одном из исполнений, показанных на фиг.12, система может использовать существующую инфраструктуру, такую как основанная на нумерации SWIFT или на отечественной нумерации, такой, например, как нумерация American Bank Association (АВА) системы FedWire в США, или нумерация, основанная на Банковских Идентификационных Кодах (БИК) как в России, или на других системах нумерации, предназначенных для клиринга и межбанковского обмена. В таком исполнении идентификаторам ЕТА могут быть поставлены в соответствие существующие идентификаторы SWIFT, или номера АВА, или номера БИК, или другие маршрутные идентификаторы и соответствующая содержательная информация.

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

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

Цифровые Соглашения о проведении транзакции

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

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

Онлайновые услуги проведения транзакций используют Инфраструктуру Открытых Ключей и цифровую подпись для авторизации транзакций.

Использование МЕТА идентификаторов может быть реализовано путем размещения МЕТА номеров вместе с Зашифрованной Записью Счета (ЗЗС) или без размещения последней в ЦС или Атрибутном ЦС (АЦС). Множество счетов может быть “разрешено” (имеется в виду техника сетевого разрешения имен/адресов/идентификаторов) и управляться, используя инфраструктуру ЕТА для каждого конкретного вызываемого ресурса сети. Для создания возможности управления множеством счетов конкретного ресурса соответствующие МЕТА номера конкретных финансовых институтов должны быть размещены в ЦС или АЦС ресурса. Поэтому, по меньшей мере, идентификатор ЕТА конкретного ресурса, его Открытый Ключ вместе с идентификатором МЕТА финансового института, обслуживающего конкретный счет ресурса, должны быть размещены в Цифровом Сертификате или Атрибутном ЦС, создавая возможность проведения входящих и исходящих платежей для конкретных счетов такого ресурса.

Выделим три типа соглашений, подписанных цифровым способом:

Соглашение о Сделке

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

Платежное Соглашение (ПС)

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

Электронное Платежное Соглашение

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

Предложенный способ предусматривает предоставление по меньшей мере трех типов услуг:

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

- Платежное Соглашение - это когда любой сетевой ресурс может принять безусловное или обусловленное чем-то решение о проведении платежа в пользу другого конкретного сетевого ресурса;

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

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

Например, для электронной коммерции в Интернет, для обычных покупок в супермаркете, на заправочных станциях и везде, где кассир получает деньги введя ЕТА идентификатор клиента в качестве плательщика в POS терминал, а клиент получит счет на оплату на свое сетевое устройство и авторизует платеж путем введения пароля авторизации в свое сетевое устройство. Соглашение о Сделке может значительно упростить оплату за телекоммуникационные услуги, когда сервис провайдер инициирует оплату путем выставления счета (требование проведения оплаты) непосредственно на сетевое устройство клиента и конечный пользователь устройства просто авторизует оплату путем введения пароля авторизации.

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

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

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

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

Использование “ЕТА ЗКК”

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

Пример ЕТА платежа в супермаркете.

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

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

Затем кассир подтверждает ввод ЕТА и затем:

Режим реального времени:

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

Покупатель выбирает “принять” и вводит свой секретный пароль для подтверждения платежа.

Кассир и Покупатель получают сообщение - подтверждение платежа от Центра Авторизации соответственно на POS терминал продавца и на мобильный телефон покупателя.

Подтверждение сохраняется и транзакция завершается.

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

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

Режим off-line

Когда мобильный телефон покупателя не может быть использован для проведения транзакции в режиме реального времени (например, батарея разряжена, или покупатель забыл телефон дома), после того как ЕТА покупателя введен в качестве ЕТА плательщика в память POS терминала для проведения транзакции в режиме off-line, терминал предлагает покупателю осуществить ввод секретного пароля пользователя ЕТА. По выбору кассира, POS терминал может направить на Центральный Коммутатор сети ЕТА номер, получить и показать на дисплее POS терминала личные данные владельца ЕТА номера, включая его фото, имя и другую описательную информацию. Далее кассир может потребовать от покупателя предъявить документ, удостоверяющий его права на использование ЕТА идентификатора.

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

Подтверждение проведения транзакции сохраняется и транзакция завершается.

Пример использования услуг оплаты ЕТА плательщиком

Плательщик выбирает операцию оплаты в интерфейсе телефона. Плательщик вводит ЕТА Получателя платежа в соответствующее поле на дисплее.

Плательщик выбирает валюту и вводит значение суммы транзакции и назначение транзакции, если надо.

Плательщик подтверждает платеж.

Плательщик вводит секретный пароль для подтверждения транзакции.

Платеж проводится после проверки пароля и если пароль верен.

Плательщик получает сообщение авторизации из сети, и это сообщение показывается на дисплее, чтобы подтвердить окончание транзакции.

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

Подтверждение сохраняется и транзакция завершена.

Процедура клиринга и Авторизации

Предположим, что финансовые институты являются банками.

Когда Платежное поручение составлено и скреплено цифровой подписью отправителя, оно отправляется плательщиком в МЕТА банк плательщика. Вместе с тем это может также быть счет на оплату. Такое сообщение (счет на оплату, платежное поручение) может быть направлено вместо этого получателю платежа, или плательщику, или в банк плательщика или получателя, не внося значительных изменений в процедуру авторизации и клиринга транзакции. Банк плательщика аутентифицирует цифровую подпись плательщика и, если она аутентична, то извлекает сумму транзакции и МЕТА/ЕТА номер получателя, или по меньшей мере ЕТА номер получателя, который далее “разрешается” в полный номер МЕТА/ЕТА через Центральный Коммутатор (Свич-сервер), транзакция завершается через МЕТА банк на счет ЕТА получателя описанным выше способом.

Использование существующей клиринговой системы

После получения Платежного поручения банк плательщика может разрешить МЕТА через Центральный Коммутатор (ЦК) в, например, номер SWIFT или другой маршрутный идентификатор банка получателя, а дальше выполнить платеж, используя соответствующие международные или отечественные средства маршрутизации и клиринга или средства третьих сторон. Такой способ позволяет использовать существующую инфраструктуру клиринга и маршрутизации и предоставляет очень недорогую реализацию способа проведения МЕТА/ЕТА платежей, как описано.

Если используется существующая клиринговая система SWIFT или другая, то в Файл МЕТА соответствующего финансового института должна быть внесена соответствующая адресная информация системы SWIFT или другой системы маршрутизации и клиринга. При проведении транзакции отправитель и получатель платежных инструкций обмениваются МЕТА данными, взятыми из собственных Файлов ЕТА или из своих ЦС или ЦСС. Далее плательщик предоставляет своему банку МЕТА/ЕТА маршрут получателя и банк разрешает МЕТА через ЦК, получая от ЦК обыкновенный номер SWIFT или другой маршрутный идентификатор, определенный для банка получателя. Это позволяет банку плательщика завершить транзакцию с банком получателя обычным путем. В таком случае предпочтительное исполнение системы предполагает, что каждый Файл ЕТА и его копии, ЦС или ЦСС должны включать МЕТА в качестве единственной информации для маршрутизации платежей, чтобы ЦК мог брать комиссию за проведение транзакций, поскольку отсутствие обычных банковских деталей в Файле получателя будет вынуждать банк Плательщика обращаться за ними в ЦК для разрешения МЕТА в детали счета получателя. В таком случае ЦК может брать комиссию за разрешение МЕТА номеров и может потребовать от каждого банка плательщика предоставить ЦК информацию о транзакции и о ее сумме, чтобы установить значение комиссии в зависимости от суммы транзакции.

Использование клиринговой системы МЕТА номеров

Когда банк плательщика получает Платежное поручение, банк создает собственное Платежное поручение банка, которое подписывает своей цифровой подписью. Получение содержит, по меньшей мере, сумму, а также МЕТА/ЕТА маршруты плательщика и получателя платежа или их ЕТА номера. После этого банк плательщика разрешает через ЦК МЕТА номер банка получателя в URL банка получателя. Затем банк плательщика создает и подписывает Платежное поручение банка отправителя, устанавливает соединение с МЕТА ПКА и с банком получателя. Стороны взаимно аутентифицируют друг друга и банк плательщика отправляет платежное поручение в ПКА.

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

Реализация банкомата

МЕТА может быть присвоен банкомату и команда “запрос наличных” может поступить от пользователя банкомата для того, чтобы списать деньги с любого другого сетевого ресурса, которому также присвоен ЕТА, причем после авторизации транзакции пользователем ЕТА ресурса наличные будут выданы пользователю банкомата. В соответствии с изложенным POS терминал может быть выполнен как и описанный банкомат.

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

Пользователь банкомата выбирает операцию снятия наличных с использованием ЕТА;

Вводит ЕТА с клавиатуры или вводит пластиковую ЕТА карту в приемное гнездо банкомата для считывания данных ЕТА; банкомат просит пользователя ввести пароль и, если авторизация получена, то банкомат выдает наличные.

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

Бизнес модели

В описанных выше случаях Центр Авторизации может выступать в качестве ПКА для соответствующих зарегистрированных банков, а также может иметь базу данных “разрешения”, устанавливающую соответствие каждого конкретного МЕТА соответствующим деталям определенной системы маршрутизации и клиринга платежей и информации о балансе клирингового счета банка.

Регистратура за вознаграждение выпускает МЕТА номер для банков и других финансовых институтов, а ЦК берет комиссию за услуги разрешения МЕТА номеров в информацию маршрутизации, авторизации и клиринга.

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

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

Изобретение содержит способ создания, выпуска и управления Цифровыми Сертификатами (ЦС), предусматривающий многоуровневую модель дистрибуции и доступ ко множеству счетов, основанный на использовании ЦС и Инфраструктуры Открытых Ключей (далее PKI - Public Key Infrastructure). Различные варианты исполнений описаны ниже, но они приведены не в качестве ограничений применимости изобретения, а лишь для иллюстрации.

Распределенная архитектура дистрибуции удостоверяющих услуг. Удостоверяющие услуги (услуги УЦ), основанные на использовании ЦС и PKI, широко распространены и предоставляются такими компаниями, как VeriSign и другими. Обычно такие провайдеры удостоверяющих услуг не признают ЦС выпущенные своими конкурентами. Это ведет к неоправданной сегментации рынка и недостатку интероперабельности удостоверяющих услуг в глобальном масштабе. Последнее обстоятельство препятствует в использовании пользователями удостоверяющих услуг и в результате бизнес Удостоверяющих Центров (УЦ) страдает от недостаточного проникновения на фокусный рынок.

Изобретение предлагает способ распространения удостоверяющих услуг через сеть, в которой Удостоверяющий Центр “Tier One” является доверенным лицом для всех нижних уровней, а нижние уровни являются “перестраховщиками” для верхних уровней, с которыми они связаны. На фиг.16, самый нижний Удостоверяющий Центр уровня "Tier END" подписывает Цифровой Сертификат DC^END для своих пользователей и обращается к Удостоверяющему Центру более высокого уровня "Tier (END-1)" для обмена выпущенного ЦС на новый. УЦ "Tier (END-1)" использует DC^END, подписанный УЦ "Tier END" как запрос на выпуск Цифрового Сертификата (далее Certificate Signature Request или CSR), причем УЦ "Tier (END -1)" извлекает данные из ЦС DC^END и подписывает его, используя свой Закрытый Ключ ^(END-1), выпуская тем самым свой цифровой сертификат DC^(END-1), который далее передается в УЦ “Tier (END-2)” и там обрабатывается таким же способом, как описано выше, и так далее по цепи УЦ вверх, когда будет достигнут УЦ “Tier One” и последний Цифровой Сертификат DC^{Tier One} будет выпущен. Выпущенный ЦС “DC^{Tier One}” затем возвращается пользователю через цепь участвующих УЦ или напрямую и размещается на устройстве пользователя, на его карте или другим способом размещается в памяти чипа или процессора или наносится печатным способом на поверхности или записывается на носители другим способом.

Такая модель распространения основана на юридически оформленных взаимоотношениях доверия между верхними и нижними уровнями УЦ, создавая условия для приема Удостоверяющими Центрами верхнего уровня ЦС выпущенных УЦ нижнего уровня, причем каждый ЦС, выпущенный УЦ нижнего уровня, воспринимается каждым УЦ верхнего уровня как CSR для выдачи ЦС более высокого уровня. Такая модель позволяет делегировать ответственность за несоответствующее содержание ЦС тем, кто выпустил CSR, на основе которого был выпущен соответствующий ЦС, то есть делегировать ответственность с верхних уровней иерархии УЦ, начиная с “Tier One”, на нижние уровни вплоть до “Tier End”, который отвечает перед верхними уровнями за проверку прав пользователя на использование конкретных Идентификатора Ресурса (ИР), Записи Счета (ЗС) и Зашифрованной Записи Счета (ЗЗС) в заявке CSR пользователя. Такое распространение предоставляет необходимую защиту для верхних уровней, защищая их от ошибок и обмана, связанных с небрежностью или преднамеренными действиями нижних уровней при проверке прав пользователей на использование конкретных ИР, ЗС и ЗЗС.

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

Такая архитектура также создает возможность замены ЦС, когда новый провайдер услуг нижнего уровня Tier END(N) может добавить поле своих услуг в существующий ЦС пользователя и обратиться с запросом о замене прежнего ЦС на новый независимо от того, к кому из УЦ этот пользователь обратился за выпуском ЦС, впервые или непосредственно перед этим.

Содержание ЦС

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

Каждая область предпочтительно содержит одно из полей: Идентификатор Ресурса (ИР) или Записи Счета (ЗС) или Зашифрованной Записи Счета (ЗЗС) или их композицию, причем:

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

- ИР является уникальным алфавитно-цифровым идентификатором, совпадающим с конкретным телефонным номером или ENUM (http://www.ietf.org/html.charters/enum-charter.html), или с ЕТА (Единый Телефонный Адрес), или с DNS именем, или с другим известным сетевым идентификатором, обеспечивающими сетевую интероперабельность и глобальный доступ для сетевых устройств любого типа. ИР является подвидом ЗС, он не зашифрован и используется для телекоммуникационных целей и аутентификации. ИР может содержать дополнительную прикрепленную информацию в форме ЗС или ЗЗС. Поле ИР может быть комбинированным “сложным” ИР1/ИР2/ИРЗ, отражая тем самым например корреспондентские отношения между банками. В одном из исполнений ИР является маршрутным идентификатором и/или идентификатором счета, которые вместе формируют полную запись финансового счета, причем один или оба из них могут являться идентификаторами ЕТА.

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

Предпочтительное исполнение предполагает, что каждый ЦС структурирован так, как показано на фиг.17.

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

Предпочтительное исполнение предполагает использование или только значения полей ИР, или ЗС, или ЗЗС, или/и их композиции для поля Заголовка и областей ЦС.

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

Если ЗС или ЗЗС используются сервис провайдером, который не известен по умолчанию, тогда ИР сервис провайдера должен быть указан в поле ИР, чтобы обеспечить доступ к его услугам. В последнем случае полное заполнение области потребует наличия (ИР+ЗС) или (ИР+ЗЗС) или (ИР+ЗС+ЗЗС).

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

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

В другом исполнении запись каждого сервис провайдера размещается в отдельном ЦС, причем все ЦС, выпущенные для конкретного ресурса, имеют одинаковое значение Заголовка ЦС и содержат одинаковый Открытый ключ этого ресурса. Поэтому каждый из таких ЦС в отдельности может служить средством аутентификации ресурса в сети и служить узконаправленным целям, для которых такой конкретный ЦС был выпущен. Такие ЦС могут быть размещены в предметные области памяти устройств и доступны по имени предметной области, которую они обслуживают. Например, предметная папка Bank может содержать все ЦС, связанные с банковским обслуживанием, в папках BANKJNAMED - с именами банков, а папка CARD для карт может содержать папки CARD_NAMED с именами конкретных карт, где, в свою очередь, хранятся ЦС, выпущенные различными банками и центрами обслуживания карт.

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

Исполнение смарт карты и сетевых устройств.

В этом случае исполнение предусматривает многоуровневое распространение ЦС, как описано выше, и позволяет использовать как смарт карты, так и сетевые устройства, обеспечивая унифицированный доступ к распределенным услугам проведения транзакций, предоставляемых множеством узлов обслуживания различных сервис провайдеров. В таком исполнении каждая смарт карта и сетевое устройство наделены ЦС с помощью описанной архитектуры дистрибуции удостоверяющих услуг. Данные каждого ЦС сегментированы, как описано выше, и содержат поля для адресации и идентификации, способствуя установлению соединений, аутентификации и доступу к услугам проведения транзакций, предоставляемых различными банками, организациями, занятыми управлением наличностью, системами кредитных карт, агентствами кредитного рейтинга и другими организациями. Услуги с использованием смарт карт предоставляют возможность безопасного доступа ко всем финансовым счетам и инструментам управления наличностью, чьи поля записей включены в финансовую область ЦС. Поэтому эти услуги являются независимыми от вендоров услуг и универсальными. Владелец смарт карты может проводить транзакции с каждым или одновременно со всеми своими счетами, включенными в ЦС через банкоматы во всем мире, если банкоматы поддерживают работу через PKI и каналы телекоммуникаций, и/или использовать для транзакций свое сетевое устройство для указанных целей. Предпочтительно смарт карты являются ЕТА картами, а поле ИР в ЦС является МЕТА адресом конкретного сервис провайдера. Смарт карты могут быть картами с магнитной полосой или любым другим носителем информации, или чипом памяти, или процессором, или сетевым устройством, содержащим ЦС.

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

Пример 1: Предположим что значением финансового поля 1 (ИР+ЗЗС) является (www.authorizationcenter.com/FREEDOM/gateway.htm + ЗЗКК VISA). Предположим также ЗЗС зашифрована Открытым ключом конкретного Центра Авторизации платежей по кредитным картам VISA. Когда смарт карта вставлена в картоприемник банкомата, банкомат извлекает ЦС из смарт карты, используя и проверяя под ним подпись и используя Открытый ключ^{Tier One}. Банкомат затем извлекает и использует сетевой адрес www.authorization_center.com/FREEDOM/gateway.htm, чтобы установить соединение с шлюзом Центром Авторизации, которому принадлежит адрес. Если соединение установлено успешно, стороны производят взаимную аутентификацию, предоставляя свои ЦС. В ходе обмена значение поля ЗЗС становится доступным Центру Авторизации (ЦА), ЗЗС расшифровывается Центром Авторизации, используя Закрытый ключ ЦА, и в результате ЦА имеет расшифрованную Запись Кредитной Карты VISA. Затем Транзакция завершается путем удержания суммы платежа со счета Кредитной Карты VISA обычным способом через инфраструктуру авторизации платежей VISA International.

Пример 2: Предположим значением финансового поля 1 (ИР+ЗС) является (АВА 021000089+“Name”). В указанном случае АВА021000089 (нумерация американской банковской ассоциации American Bank Association) является маршрутным номером банка Citibank в федеральной системе проведения платежей FedWire. Поэтому операции по конкретному счету возможны после осуществления соединения с АВА 021000089, взаимной аутентификации и поиске счета с именем “Name” во внутренней системе счетов банка CitiBank. Если соответствующий внутренний счет найден, то пользователю смарт карты будет предоставлен доступ к счету.

Пример 3: Предположим значением финансового поля 1 (ИР) является ЕТА ([phone]), который является телефонным шлюзом банка. Когда смарт карта вставлена в картоприемник банкомата и этот ИР адрес извлечен банкоматом из ЦС карты, банкомат получает доступ к банку, устанавливая соединение по указанному номеру телефона, и после взаимной аутентификации сторон между смарт картой и банком последний извлекает Заголовок ЦС и ищет ему соответствие во внутренней системе счетов. Если соответствующий Заголовку ЦС счет найден, то банк предоставляет доступ к найденному счету.

Пример 4: Предположим, что владелец карты обращается в банк за предоставлением кредита; предположим также, что значением финансового поля 1 (ИР) является ЕТА ([phone]), принадлежащий телефонному шлюзу Агентства Кредитного Рейтинга (АКР). Когда смарт карта вставлена в картоприемник смарт карт ридера и адрес ИР считан из ЦС, ридер устанавливает связь с АКР, используя номер ЕТА, и после взаимной аутентификации между смарт картой и АКР последнее извлекает из ЦС карты Заголовок ЦС и ищет соответствующий Заголовку счет во внутренней системе счетов АКР. Если соответствующий счет найден, то АКР предоставляет карт ридеру данные кредитного рейтинга найденного счета; полученный кредитный рейтинг принимается во внимание кредитующим банком и на основе полученного значения Кредитного рейтинга владельца смарт карты принимается решение о кредитовании владельца или отказе в выдаче кредита.

Пример 5: Предположим, что значением финансового поля 1 (ИР) является ЕТА ([phone]), который является номером телефонного шлюза Департамента Выдачи Въездных Виз. Когда смарт карта вставлена в картоприемник ридера пограничной службы паспортно-визового контроля и значение адреса шлюза Департамента считано из ИР поля ЦС, ридер устанавливает соединение со шлюзом Департамента, используя номер [phone], и после взаимной аутентификации между картой и Департаментом последний извлекает Заголовок ЦС и ищет ему соответствие во внутренней визовой базе данных Департамента и, если владелец карты имеет действительную и непросроченную въездную визу, то владельцу карты предоставляется возможность пересечь границу и въехать в страну.

Пример 6: Предположим, значением финансового поля 1 является ЕТА ([phone]), значением финансового поля 2 является ([phone]), а.... значением финансового поля N является ([phone] + ЗЗС), причем поле 1 и поле 2 содержат номера доступа к шлюзам банков и поле N является телефонным номером доступа к шлюзу Центра Авторизации платежей по кредитным картам VISA, причем ЗЗС в поле N представляет Зашифрованную Запись Кредитной Карты VISA. Когда смарт карта вставлена в картоприемник банкомата, ИР адреса извлекаются банкоматом из полей 1, 2,…N Цифрового Сертификата, после чего банкомат устанавливает связь с шлюзами банков и ЦА VISA, используя соответствующие адреса ИР доступа к шлюзам. После взаимной аутентификации с каждым из банков и ЦА VISA каждый банк ищет соответствие Заголовку ЦС во внутренних системах счетов банков, а ЦА VISA расшифровывает ЗЗС, используя собственный Закрытый ключ, и получает таким образом соответствующий счет кредитной карты VISA. Если найдены счета, соответствующие Заголовку ЦС, а ЗКК VISA существует и действительна, то банкомат выводит для пользователя смарт карты на дисплей балансовую информацию по каждому банковскому счету и по счету карты VISA и позволяет провести транзакцию через любой из счетов в соответствии с правилами соответствующего банка и привилегиями владельца карты.

Использование сетевых устройств

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

Бизнес модели

Бизнес модель предполагает продажу самого ЦС и услуги по его выпуску. Модель также предполагает продажу замены ЦС.

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

Архитектура Проведения Расчетов через Интернет (АПРИ)

Платежные Узлы (ПУ). Платежные узлы являются узлами (ресурсами) сети, причем сетевой адрес (идентификатор) каждого ПУ используется в качестве идентификатора счета, соответствующего ПУ. В отношении самого платежа каждый ПУ может являться или одним из узлов- Плательщиков, или узлов-Посредников или узлов - Получателей платежа. Каждый ПУ имеет уникальный сетевой адрес, связанный с ПУ; сетевой адрес может иметь формат телефонного номера и являться ЕТА или ENUM, или быть www или адресом электронной почты (e-mail), или любым другим соответствующим сетевым адресом, который может быть разрешен с помощью средств разрешения адресов сети в соответствующий сетевой адрес Основной Клиринговой Организации или ОКО (то есть Клиринговой Организации, которая используется по умолчанию). Каждый ПУ может являться как вызывающим ресурсом, так и отвечающим ресурсом в процессе исполнения платежа, причем Вызывающий узел является одновременно Плательщиком, а Отвечающий узел является Получателем при проведении Атомарных платежей. Вызывающий ПУ может быть как Плательщиком, так и Посредником в проведении “End-to-End” Платежа (далее ЕЕП), а Получатель может выступать в качестве Посредника или Получателя ЕЕП.

ЕТА.

В контексте АПРИ ЕТА понимается как Единый Транзакционный Адрес. ЕТА является уникальным идентификатором ресурса. ЕТА совпадает с одним из сетевых идентификаторов, таких как телефонный номер, www адресом, адресом электронной почты, IP или другим уникальным сетевым адресом, или с именем на естественном языке. ЕТА совпадает или связан с идентификатором транзакционного счета ресурса.

Атомарный Платеж (АП). Атомарный Платеж исполняется как телекоммуникационное соединение типа точка-точка, то есть является транзакционным соединением (далее именуется transactional call или t-call). T-call является соединением точка-точка, при котором транзакционная инструкция создается вызывающим ресурсом в форме сетевого соединения, использующего параметрическую строку в нотации пространства имен (namespace string), то есть строки, содержащей адрес ЕТА Отвечающего ресурса, и платежная инструкция, содержащая специфические параметры платежа и цифровую подпись Вызывающего ресурса. Далее для определенности мы будем говорить о транзакции как о платеже, хотя это может быть транзакция любого другого рода. Для простоты мы также станем считать, что платежная инструкция является частью пространство имен URN (например, пространство имен ЕТА), а платежная инструкция располагается за вопросительным знаком - "?" в URN нотации пространства имен (рассмотрено в приведенном ниже примере). Предпочтительный формат строки Т-са11 в описанном случае использует формат, описанный как URN Syntax в RFC 2141 и RFC 2396, и может следовать подходу, изложенному в "Resolution of URIs Using the DNS" (RFC 2168), "Architectural Principles of Uniform Resource Name Resolution" (RFC 2276), “DDDS and Namespace Definition Mechanisms implementations” (RFC 3401, 3402, 3403, 3404, 3405, 3406). Однако, несмотря на требования, изложенные в указанных RFC, упомянутых выше для простоты, в приведенных ниже примерах мы не будем следовать требованиям к синтаксису URL Syntax requirements. Мы также не станем указывать порты, упрощая тем самым синтаксис пространства имен, хотя различные порты могут быть использованы для разделения сетевых соединений, переданных с целью передачи платежных инструкций от, например, сетевых вызовов, переданных с целью навигации в Интернет, поскольку использование одинакового пространства имен, но разных портов упрощает разделение потоков данных, предназначенных для платежных приложений и приложений, обеспечивающих навигацию в Интернет, но в данном случае затрудняет понимание смысла предлагаемого изобретения. Для торговых автоматов (vending machine) использование портов в нотации означало бы использование одинакового DNS адреса и например порта 80 для доступа к Интернет серверу торгового автомата для просмотра для покупки доступных напитков, например порта 88 для оплаты купленных напитков с использованием рассматриваемого торгового автомата.

В отношении пространства имен и его административного домена (имеется в виду authoritative domains, то есть домен, который имеет административные права над множеством имен домена собственной зоны владения), используя аналогию с DNS, Атомарный платеж может быть или восходящим к корневому домену (домен верхнего уровня) или нисходящим к хостам (домены нижнего уровня) внутри зоны владения (authority zone) текущего домена.

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

PAYEE_UTA?PAR_1=VAL1&PAR_2=VAL2&……/PAYER_UTA/PAYER_DIG_SIGNATURE.

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

Например:

THE DEFAULT CLEARING.com?payee.com/credit/USD/1000/ON/payer.com/Kjnkethab kjdlkcmncv

В приведенном примере:

THE DEFAULT CLEARING.com является идентификатором ОКО

payee. com является ЕТА идентификатором Получателя (одновременно сетевой адрес и идентификатор счета)

Credit - означает операцию кредитования счета Получателя

US - означает валюту платежа (Доллары США)

1000 - является суммой платежа

ON - означает требование провести клиринг операции в режиме реального времени

payer.com - является ЕТА идентификатором Плательщика (одновременно сетевой адрес и идентификатор счета)

Kjnkethabkjdikcmncv - является предполагаемой цифровой подписью Плательщика.

Другой пример:

credit.THE DEFAULT CLEARING.com?+l-('212H23-4567/USD/1000/+l-(202H23-4567/Kj nkethabkj dikcmncv

в нем:

[phone] является ЕТА идентификатором Получателя (телефонный номер или ENUM) и

[phone]б7 является ЕТА идентификатором Плательщика (телефонный номер или ENUM).

В дальнейшем мы станем называть "t-call строкой" такую нотацию платежной инструкции:

credit.THE DEFAULT CLEARING.com?payee.com/USD/1000/ON/payer.com/Kjnkethabkjdl kcmncv.

End-to-End Платеж (ЕЕП). ЕЕП является платежом, начинающимся на ресурсе Плательщика и заканчивающимся на ресурсе Получателя. ЕЕП может быть Атомарным платежом, но обычно понимается как цепь последовательных платежей, в которых участвуют ресурсы Плательщика, Получателя и Посредников. ЕЕП протекает скозь цепь ресурсов-Посредников от Плательщика к Получателю в форме последовательности Атомарных платежей, реализованных как цепь t-call соединений точка-точка. Для проведения каждого Атомарного платежа оба ресурса (узла), являющиеся сторонами платежа, должны поддерживать архитектуру доверительных отношений (то есть использовать PKI), чтобы сделать возможной взаимную аутентификацию сторон Атомарного платежа.

Клиент. Ресурс (узел) Клиента является ресурсом, который является самым нижним уровнем иерархии в многоуровневой инфраструктуре клиринга и потому Клиент имеет только одну связь с материнскими уровнями клиринга и не имеет дочерних связей. Поскольку Клиент не управляет собственным Доменом клиринга, то база данных разрешения клиента не содержит никаких клиентских идентификаторов ЕТА и содержит только идентификаторы ЕТА материнских клиринговых доменов. Поэтому все ЕТА, указанные в соединении t-call клиента, всегда отображаются в идентификатор ЕТА, принадлежащий ОКО для любого конкретного ЕТА идентификатора счета Вызываемого ресурса и затем Клиент устанавливает t-call соединение с использованием соответствующего ЕТА идентификатором, принадлежащим ОКО.

Клиринговые Организации (КО). Клиринговые Организации являются клиринговыми и маршрутными организациями проведения платежей. КО обычно служат в качестве Посредников при проведении ЕЕП, но могут также выступать в качестве клиента, являясь ресурсом Плательщиком или Получателем ЕЕП. В смысле обеспечения транзакционных услуг связи (имеется в виду область transactional telecommunications) каждая КО понимается как Коммутатор - домен пространства имен, который содержит базу данных адресной информации идентификаторов ЕТА, принадлежащих дочерним КО и клиентским ресурсам (хосты в аналогии DNS), для которых текущий КО является ОКО. Аналогично описанному распределенная архитектура DNS серверов предоставляет услуги разрешения DNS имен в IP адреса, при которой материнский DNS сервер (authoritative DNS server) держит адресную информацию для ресурсов, зарегистрированных в зоне ответственности (имеется в виду “zone of authority”) этого DNS сервера.

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

МОКО. Каждая КО нижнего уровня может по умолчанию использовать услуги определенной КО верхнего уровня, которая поэтому является Материнской ОКО (МОКО).

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

Инфраструктура клиринга.

Фиг.18 иллюстрирует многоуровневую структуру отношений клиринга между участниками операций разрешения имен и клиринга, где

⇒ Client #1 является владельцем счета в одном банке CF#1, расположенном в США; CF#1 является Клиентским ОКО (КОКО) для Client #1.

⇒ Client #2 является владельцем счета в банке CF#3, расположенном в России; CF#3 является КОКО для клиента Client #2.

⇒ Client #3 является владельцем счета в банке CF #4, расположенном в России; CF#4 и CF #5 являются КОКО для клиента Client #3.

⇒ CF #1 это банк, расположенный в США; SWIFT и American Bank Association (АВА) являются МОКО для CF #1 и имеют различные способы клиринга.

⇒ CF #2 это международная клиринговая сеть SWIFT; CF#1, CF#3 и CF#5 являются дочерними КО для SWIFT, a SWIFT, в свою очередь, является МОКО для каждой из них.

⇒ CF #3 это Российский банк; SWIFT является МОКО для CF #3.

⇒ CF #4 это Российский банк; CF #3 является МОКО (банк корреспондент) для CF#4.

=> CF #5 это Российский банк; SWIFT и CF #7 являются МОКО для CF #5.

⇒ CF #6 это клиринговая палата Американской банковской ассоциации АВА; CF #1 и CF #7 являются дочерними для клирингового домена АВА.

⇒ CF #7 это банк расположенный в США; АВА является МОКО для CF #7.

Фиг.18 показывает, что Client #1 может перечислить деньги (осуществить платеж) клиенту Client #2, используя единственный маршрут:

(Client#1→CF#1→CF#2→CF#3→Client#2).

Если Client #1 хотел бы перечислить деньги клиенту Client #3, он мог бы использовать один из альтернативных маршрутов:

(Client#1→CF#1→CF#2→CF#3→CF#4→Client#3) или

(Client#→CF#1→CF#2→CF#5→Client#3) или

(Client#1→CF#1→CF#6→CF#7→CF#5→Client#3).

При проведении операций в соответствии с настоящим изобретением АПРИ может поддерживать, например, принципы, изложенные в “Architectural Principles of Uniform Resource Name Resolution” (RFC 2276) или сходные с ними, причем сетевые адреса могут совпадать с идентификаторами счетов.

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

⇒ Получает вызовы t-call от Вызывающих ресурсов (от собственных клиентов или дочерних КО),

⇒ Аутентифицирует Вызывающий ресурс по его идентификатору ЕТА и цифровой подписи,

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

○ Цикл разрешения. КО разрешает ЕТА идентификатор Получателя в ЕТА идентификатор Следующей КО (СКО), который является или ОКО для Получателя, или МОКО для текущей КО.

⇒ Дебитует счет клиента и кредитует счет СКО внутри текущего клирингового домена.

⇒ Создает строку для t-call вызова, такую, например, как credit-NEXT_DEFAULT_CLEARING.com7pavee.com/USD/1000/ON/paver.com, в которой NEXT_DEFAULT_CLEARING.com является адресом для установления сетевого соединения, а остальная часть является копией строки исходного t-call соединения без цифровой подписи.

⇒ Подписывает собственной цифровой подписью строку параметров t-call вызова credit.NEXT_DEFAULT_CLEARING.com7pavee.com/USD/1000/ON/paver.com/digital_signature_of_CURRENT_CF.

⇒ Устанавливает соединение с ОКО, используя созданную строку t-call вызова.

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

База данных КО для осуществления циклов разрешения имен. Каждый КО является Администратором Домена Счетов (по аналогии с Администратором Домена DNS имен) и поддерживает базу данных разрешения пространства имен в “зоне администрирования” ('zone of authority") своего Клирингового Домена. Например каждый банк является клиринговым доменом пространства имен для счетов собственных клиентов (аналогичны хостам для DNS системы), а также для других банков (аналогичны sub domain namespace servers в аналогии DNS), которые используют рассматриваемый банк в качестве банка корреспондента для получения доступа к услугам материнской клиринговой организации рассматриваемого банка. В последнем случае Российский банк может иметь корреспондентский счет в Американском банке, чтобы получить доступ к системе платежей FedWire клиринга платежей банков, входящих в Американскую Банковскую Ассоциацию (American Bank Association).

База данных домена конкретной “зоны администрирования” устанавливает соответствие между ЕТА идентификаторами зарегистрированных в зоне вызываемых ресурсов МЕТА идентификаторам КО. База данных “зоны администрирования” разрешает ЕТА идентификаторы вызываемых ресурсов в соответствующие им МЕТА идентификаторы ОКО, находящиеся в “зоне администрирования”, или разрешает в МЕТА идентификаторы дочерней или материнской ОКО аналогично с тем, как организован домен IN-ADDR.ARPA в Интернет (см. RFC 1033) и поиск соответствий в его базе данных обратной адресации (см. RFC 1034 “Алгоритм Сервера Имен” в качестве примера исполнения). Если Вызываемый ЕТА не может быть разрешен внутри текущего клирингового домена в идентификатор ОКО (то есть резальтат поиска соответствующего идентификатора ОКО отрицателен), то ЕТА идентификатор вызываемого ресурса должен быть разрешен по умолчанию в ЕТА идентификатор МОКО (корневой сервер пространства имен) текущей КО соответственно с определенным для материнского домена платежным методом. Таблица 8 показывает упрощенный пример таблицы базы данных, выполняющей разрешение <Вызываемый ЕТА + метод>→<ОКО ЕТА>.

Каждая КО должна содержать разрешающую базу данных, в которой каждому клиентскому идентификатору ЕТА поставлены в соответствие множество ЕТА его ОКО различных по используемому методу клиринга и все ЕТА, не принадлежащие клиентам будут разрешены в ЕТА МОКО, использующей заданных метод клиринга. Метод клиринга является параметром в строке Т-са11, обеспечивая разрешение, результатом которого является уникальный ЕТА идентификатор ОКО или МОКО для каждой уникальной пары “уникальный ЕТА + уникальный метод”. В базе данных, использующей по умолчанию только один метод, каждый уникальный ЕТА будет иметь единственный уникальный ОКО ЕТА в качестве результата разрешения, если ЕТА вызываемого ресурса содержится в зоне администирования текущего домена, или будет разрешен в МОКО ЕТА текущего домена, если ЕТА вызывающего ресурса не имеет соответствия в разрешающей базе данных.

Таблица 8 показывает таблицу клиринговой разрешающей базы данных, где ЕТА каждого вызываемого ресурса будет разрешен для дочерних КО и клиентов в ОКО с учетом метода клиринга, а для всех ЕТА ресурсов, не являющихся клиентами текущего КО ЕТА ресурсов, будет разрешен в конкретный ЕТА МОКО текущей КО с учетом заданного метода клиринга. Множество методов клиринга могут быть поддержаны, например так, как это используется для идентификаторов Фамильных адресов (Address-family identifiers - AFI) для RIP 2 (RFC 1723) или используя другую известную технику.

Таблица 8

Запрос

Вызываемый ЕТА1

Вызываемый ЕТА2

Вызываемый ЕТА3

…

Вызываемый ЕТАN

Любой ЕТА, что не является клиентом или доменом дочерней КО

Метод

1

2

7

3

…

N

L

1

2

3

…

К

Ответ

ОКО ЕТА1

ОКО ЕТА2

ОКО ЕТА7

ОКО ЕТА3

…

ОКО ETAN

ОКО BTAL

МОКО ЕТА1

МОКО ЕТА2

МОКО ЕТА3

…

МОКО ЕТАК

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

Поскольку значительное число URL в Интернет и телефонных номерах заняты и уже не доступны новым Регистрантам для использования, представляется трудным построить иерархическое пространство имен для клиринговой инфраструктуры, используя существующие глобальные домены Интернет, а также существующие коды стран и регионов для телефонных номеров. Поэтому представляется полезным создать для клиринговой инфраструктуры новые пространства имен URN:<NID><NSS>, описанные в RFC 2276 и RFC 3401-3406, или новые глобальные домены Интернет, такие как например-PAY и “Нулевые” ЕТА (НЕТА) номера для телефонии:

НЕТА: +0-(123)-123 4567, или [phone], или [phone] DNS:70950123456.PAY

Другим исполнением для Интернет может быть преобразование идентификаторов НЕТА в нотацию URN, для чего в нотации URN:<NID><NSS> предполагаемый домен "PAY" должен стать значением поля NID (namespace ID), а идентификатор НЕТА вместе и платежная инструкция должны стать значением NSS (Namespace Specific String) в нотации URN.

Пример иерархической клиринговой инфраструктуры, основанной на НЕТА, показан на фиг.19.

Для конверсии (для последующего разрешения) иерархии НЕТА в иерархию DNS может быть применен Алгоритм, описанный в RFC 3402, или другая известная или новая техника. В качестве иллюстрации, распределенной ниже, приведены некоторые типы преобразований номеров телефонов в нотацию имен DNS, ENUM и других URN:

[phone]→70951234567.pay

[phone]→7095234567.us.pav

[phone]→1234567.washington.us.pav

[phone]→1234567.095.7.рау

[phone]→4567.AT&T.washmgton.us.pav

[phone]→7.6.5.4.3.2.1.0.9.5.7.ABCD.arpa

[phone]→tel:[phone]

[phone]→70951234567.UTAresolution.com

[phone]→UTAresolution.com?70951234567

Другое преобразование в DNS имена может выглядеть так:

[phone]→70951234567.12020000001.10000000001.00000000001.com.

[phone]→70951234567(a.bank.clearmghouse.com

и так далее.

Фиг.20 показывает ту же клиринговую инфраструктуру, что и Фиг.19, где предполагается, что НЕТА преобразовываются в DNS имя в предполагаемом домене. РАУ DNS в котором существуют также субдомена US и RU, относящиеся к США и России и разрешаемые нисходящим порядком в предполагаемом домене. PAY.

Другая техника могла бы использовать новый протокол, например некий вымышленный протокол HTTPSP - "hyper text transfer secure payment protocol", который мог бы быть основан на использовании стандартного протокола HTTPS и приспособлен для передачи платежных инструкций, разрешения имен и клиринга.

Еще одним подходом может быть использование стандартного Интернет транспорта (IP) наряду со специальной распределенной системой доменов, использующей технологию DNS и PKI, в которой все владельцы доменов были бы Клиринговыми Организациями (КО), а система доменов содержала бы таблицу преобразования не DNS→IP, а из преобразования НЕТА→IP или DNS→IP, или e-mail→IP, или “Имя на естественном языке”→IP и так далее. Будучи обособленной системой, основанной на технологии DNS и PKI, последнее решение может оказаться наименее затратным для реализации и наиболее защищенным.

Для разрешения идентификаторов ЕТА с разделением в зависимости от метода клиринга, база данных разрешения может быть исполнена как DDDS DNS база данных в соответствии с RFC 3403, используя поля ORDER и PREF для определения метода клиринга метода определения приоритетов клиринга. База данных КО в этом случае может использовать DDDS Алгоритм, описанный в RFC 3402, в котором Первым Известным Правилом (перевод названия “First Well Known Rule”) могло быть правило обработки строки "t-call" вызова, а Клиринг и Разрешение имен может быть выполнено, используя правила DDDS базы данных и управляться “ключами” (так называемые “keys”), как описано в RFC 3402, причем “ключи” могут предаваться в качестве значений параметров строки t-call вызова.

Несмотря на вышесказанное, более практичным путем может быть использование существующих пространств DNS имен в качестве клиринговых, причем например Client #3 (см фиг.18) мог бы иметь 3 DNS имени, определяющих 3 альтернативных клиринговых маршрута. Предполагая, что CF#6 является доменом СF#6.соm, a CF#5 является доменом CF5.com и CF#2 является доменом CF2.com, клириновый маршрут мог быть написан в нотации DNS имен следующим образом:

Client3.CF4.CF3.CF2.com для (Client#l→CF#1→CF#2→CF#3→CF#4→Client#3)

Client3.CF5.CF2.com для (Client#l→CF#1→CF#2→CF#5→Client#3)

Client3.CF5.CF7.CF6.com для (Client#l→CF#1→CF#6→CF#7→CF#5→Client#3).

В последнем примере ЕТА идентификатору клиента Client #3 соответствует три URL адреса Client3.CF4.CF3.CF2.com. Client3.CF5.CF2.com and Client3.CF5.CF7.CF6.com внутри CF2.com, и CF6.com клиринговых доменов.

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

Услуга разрешения. Услуга разрешения относится только к маршрутизации платежей ЕЕП и реализуется как цепь последовательных “циклов разрешения” - поисков в базе данных Доменной Системы Имен Клиринговых Организаций, как описано в RFC 1035, 1034 and 3403 сетевого адреса соответствующего идентификатору ЕТА Получателя атомарного платежа. Аналогичным образом в реализации DNS системы домен каждой Кредитной Организации становится ее “зоной администрирования” для всех ее клиентов и дочерних КО.

Каждый идентификатор Получателя может быть разрешен в сетевой идентификатор его ОКО, причем ОКО является “зоной администрирования” домена для идентификатора Получателя, который поэтому является идентификатором субдомена или идентификатором хоста в таком случае. Например, идентификатору Получателя=[phone]б7 может соответствовать идентификатор его ОКО=12121234567.citibank.com, причем Citibank-com является материнским доменом для Получателя. Такой способ позволяет незаметно для пользователя маршрутизировать вызовы t-call проведения транзакций через цепь ОКО, соединяющую Вызывающего и Отвечающего ресурсы. Каждый из ОКО может быть банком или Процессинговым Центром обработки платежей по кредитным картам или Расчетным центром или другой клиринговой организацией.

Реализация услуг поиска КО. Для обнаружения и исследования маршрута клиринга транзакций может быть использован протокол RIP-2 (Routing Information Protocol), описанный в RFC 1723, или другая аналогичная техника.

В качестве команды поиска маршрута может быть использована команда "Tracert", описанная в протоколе TCP/IP, или аналогичная ей команда может быть использована для проводных и беспроводных сетей связи.

Ниже для примера приведен результат работы команды "tracert":

C:\>tracert www.multilex.ru

Tracing route to multilex.ru [212.24.32.169]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms gate.medialingua.ru [192.168.1.3]

2 1ms 1ms lms62.118.27.65

3 20ms 21ms 21 ms 10.4.255.100

4 123ms 211ms 131 ms spd-gw-GE-0-l-20.mtu.ru [195.34.53.97]

5 22ms 21ms 25 ms PTT-Pex.core.mtu.ru [195.34.53.65]

6 22ms 23ms 23ms Pex-M9.core.mtu.ru [195.34.53.10]

7 44ms 43ms 42 ms s-b3-pos0-2.telia.net [213.248.101.57]

8 45ms 45ms 45 ms teliasonera-01843-s-b3.c.telia.net [213.248.78.250]

9 68ms 73ms 75 ms mowl-000.sonera.ru [217.74.128.122]

10 75ms 73ms 74ms vlan30-ge5-l.m9-3.caravan.ru [217.74.128.126]

11 77ms 71ms 77ms vlan615-ge0-0-10.office-l.caravan.ru [217.23.151.78]

……………………………………

C:\>

Как видно из приведенного примера, команда "tracert" позволяет найти физический маршрут, соединяющий Вызывающий и Отвечающий узлы (ресурсы) сети, включая все ресурсы-посредники. Применение такого коммуникационного способа поиска для Архитектуры Проведения Расчетов через Интернет (АПРИ) позволяет реализовать улсуги поиска платежного маршрута.

Поиск Клиринговых Организаций и поиск маршрута с оптимизацией по стоимости клиринга ЕЕП рассмотрен в примере "Оптимизация маршрута клиринга по стоимости." раздела "Примеры использования", приведенного ниже.

Удостоверяющие услуги. Для установления отношений доверия между узлами АПРИ может быть использована PKI. Каждый ресурс может быть наделен Цифровым Сертификатом (ЦС), содержащим, по меньшей мере, платежные атрибуты ресурса, как описано в RFC 3281. Платежные Атрибуты должны включать по меньшей мере два -ЕТА, то есть Сертифицированный Идентификатор ЕТА ресурса и ЕТА идентификатор Основной Клиринговой Организиции указанного ресурса. Такой способ Цифровой Сертификации маршрутной информации предоставляет маршрутную информацию для размещения в Маршрутной Базе Данных Клиринговой Организации.

Иллюстрируя содержание ЦС, снова используя DNS аналогию, такие удостоверенные платежные атрибуты могли бы включать информацию всего набора Ресурсных Записей DNS (DNS Resource Record), которые содержатся в мастер файле сервера имен DNS, или какую-то их важную часть области значений отображения (см. RFC 1034). Будучи затем извлеченной из ЦС и размещенной в мастер файле зоны DNS, удостоверенная информация Ресурсных Записей позволит предоставлять достоверные услуги DNS разрешения. Сведение Цифровых Сертификатов с DNS системой например предложено в RFC 2538 "Storing Certificates in the Domain Name System (DNS)" и может быть использовано при создании удостоверенной DNS базы данных при создании АПРИ. Указанный RFC также предусматривает возможность доступа к Открытому Ключу соответствующего ресурса, создавая необходимые условия для использования цифровой подписи и шифрования строки t-call.

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

Аспекты конфиденциальности. Сохранение тайны решается применением PKI для Клиринговой сети как для защищенной коммуникационной сети Электронного Перевода Денег (Electronic Funds Transfer или EFT) и распределенной в защищенной сети Клиринговой базы данных описанным здесь способом. Каждая Клиринговая База данных является защищенной сетевой базой данных, доступной только для участников клиринга. Цифровые Сертификаты и PKI могут быть использованы как источник достоверной информации отображения множества ЕТА идентификаторов вызывающих ресурсов в множество маршрутной информации к их счетам, создавая условия доверия и защищенности при предоставлении услуг разрешения и клиринга.

Примеры использования

Пример реализации Разрешающей базы данных DNS.

Случай 1

Обособленная АПРИ может быть исполнена используя существующие программные реализации DNS резолверов и серверов имен DNS, а также используя существующие протоколы, включая UDP и TCP/IP. Такое программное обеспечение DNS могло бы отображать и разрешать не только DNS адреса, но и любой другой сетевой адрес в адрес IP, предоставляя различные услуги, как предлагается в RFC 3403. Благодаря этому каждый ЕТА идентификатор вызываемого ресурса может быть разрешен в соответствующий ему IP адрес ОКО, а для неклиентов их ЕТА идентификаторы могут быть разрешены в имя DNS сервера Материнской КО, в то время как DNS система может использовать матинский домен ОКО в качестве “корневого” домена и разрешать все неклиентские ЕТА идентификаторы через него или используя многоуровневую модель разрешения.

RFC 1034, 1035 и 1183 в некоторой части могут быть использованы для такого исполнения. Разрешение ЕТА идентификатора в доменное имя (см. “Пример транзакции кредитования”, поясняющий разрешение payer.com→payer.payerbank.com) в таком случае может быть исполнено используя домена INN-ADDR.ARPA для поиска по IP адресу или используя DDDS для поиска других типов ЕТА идентификаторов.

В случае DDDS исполнения результат разрешения ЕТА идентификатора "рауее.соm" может выглядеть так:

рауее.соm.

;; order pref flags service regexp replacement

INNAPTR100 50 "a" "httpsp+N2T" "" раyее.соm

INNAPTR100 50 "a" "https+N2R" "" payee.payeebank.clearing.com.

INNAPTR100 60 "a" "https+N2R" "" payee.payeebankl.clearing 1.com.

INNAPTR100 70 "a" "https+N2R" "" oayee.payeebank2.clearing2.clearing3.com.

INNAPTR100 70 "a" "http+N2B" "" billing.payee.com.

INNAPTR100 50 "a" "wap+N2V" "" wap.payee.com

IN NAPTR 100 80 "a" "sip+N2V" "" payee.com(%sip. someservice.com

INNAPTR100 80 "a" "http+N2IP" ""213.248.101.57,

где услуга "https+N2T" означает “name-to-trace” оценки стоимости маршрута платежа, используя предполагаемый HTTPSP протокол; а три услуги "https+N2R" означают “name-to-route” предоставление альтернативных клиринговых доменов с рангами предпочтения (preference) 50, 60 и 70 для маршрутизации платежа; а последняя услуга "http+N2V", для просмотра содержания WAP сервера Получателя платежа, описывающего предоставление услуг или продукты потребления.

Используя DDDS становится возможным произвести трассировку маршрутов, используя в качестве запроса каждый из идентификаторов ЕТА Плательщика и Получателя для поиска услуг "https+N2R" маршрутизации в DNS базе данных и сравнения полученных результатов для поиска в них совпадающих доменов КО, а когда одинаковые домены КО найдены, становится возможным запросить у них стоимость и длительность проведения клиринга транзакции для целей оптимизации проведения транзакции.

Случай 2

Предположим, что база данных DDDS DNS использует ресурсные записи NAPRT, позволяя разрешать адрес каждого платежного узла в соответствующий ему адрес ОКО. Предположим также, что некоторый Получатель “Payee” (payee.corn) имеет счет в банке “PayeeBank” (PEBank.com) а некоторый Плательщик “Payer” (payer.com), имеет счет в банке “PayerBank” (PRBank.com).

Примем также, что вызов t-call содержит строку "?payee.com/credit/USD/1000/PayerDigSign". Предположим, что описанная в RFC 3402 Уникальная Строка Приложения (Application Unique String или “AUS”) получена приложением при обработке t-call путем извлечения текста, размещенного между знаком '?' и первым знаком '/' (Первое Известное Правило, как описано в RFC 3402), и запрос к базе данных DNS DDDS производится, используя извлеченный текст. В нашем случае запросом будет подстрока “рауее.соm”.

Результатом разрешения DDDS строки “Рауее.соm” мог бы быть такой:

Рауее.соm

;; order pref flags service regexp replacement IN NAPRT 100 10 "" X2Y "" PEBank.com

Теперь приложение изменяет прежнее значение AUS, прибавляя значение “payee” к результату поиска, и переписывает строку AUS в строку Payee.PEBank.com, а Приложение производит в базе данных поиск строки “Payee.PEBank.com”, которая разрешается базой данных в запись:

Payee.PEBank.com

;; order pref flags service regexp replacement

INNAPRT10010 "p" X2Y "" payee.PEbank.DCFl.com

Такая реализация позволяет последовательно разрешить идентификатор “payer.com” в маршрут “payer.PRBank.com” и далее в “payer.PRBank.DCFl.com”, причем полученное DNS имя "payee.PEbank.DCFl.com" является конечным (об этом говорит флаг “P”) и Приложение заканчивает разрешение имени “рауее.сот”, возвращая строку "payee.PEBank.DCFl.com" как полный маршрут клиринга платежа для Получателя. Домен.СОМ не является клиринговым в данном примере.

Такое же разрешение идентификатора Плательщика дало бы последовательные результаты:

Payer.com

;; order pref flags service regexp replacement INNAPRT10010 "" X2Y "" payer.PRBank.com

payer.PRBank.com

;; order pref flags service regexp replacement INNAPRT10010 "p" X2Y "" payer.PRBank.DCFl.com.

Приложение сравнивает конечные клиринговые маршруты для Получателя Рауее.соm→PEBank.com; Payee.com→PEBank.com→DCFl.com и Плательщика Payer, com→PRBank. com; Payer.com→PRBank.com→DCF1.corn с целью найти Точку Поворота Маршрута (ТПМ), то есть первое слева имя домена, содержащееся и совпадающее в маршрутах Получателя и Плательщика, и таким оказывается клиринговый домен DCF1 в нашем случае. Оба конечных маршрута сравниваются с целью поиска совпадающего звена и такое звено считается Точкой Поворота Маршрута, в которой маршрут становится из восходящего клиринга в нисходящий клиринг. Очевидно, что клиринговым маршрутом приведенного платежа Плательщик-Получатель будет Payer.com→PRBank.com→DCFl.com→PEBank.com→Payee.com, причем DCF1 является Точкой Поворота Маршрута.

Может существовать более одной Точки Поворота Маршрута для каждой пары Плательщика и Получателя.

Случай предоставления услуг поиска маршрута

Предположим, что идентификаторы “Payer” Плательщика и “Payee” Получателя могут быть разрешены в ЕТА идентификаторы клиринговых маршрутов:

Payer

;; order pref flags service regexp replacement

IN NAPTR 100 50 "a" "http+N2T" "" paver.com

INNAPTR100 60 "a" "https+N2R" "" Daver.FOObank.ROOclearing.com.

IN NAPTR 100 50 "a" "https+N2R" "" pavee.GObank.REclearing.com.

and

Payee

;; order pref flags service regexp replacement

INNAPTR100 50 "a" "http+N2T" "" pavee.com

INNAPTR100 50 "a" "https+N2R" "" pavee.ZOObank.ROOclearing.com.

INNAPTR100 60 "a" "https+N2R" "" pavee.GObank.TOclearing.com.

Сравнивая результаты разрешения идентификаторов “Payee” и “Payer” для услуг N2R (Name-to-Route), мы обнаружим, что платеж может быть проведен с использованием одного из двух независимых маршрутов, а именно через банк “GObank”, в котором имеют счета и Плательщик и Получатель, ИЛИ через Клиринговую Организацию “ROOclearing”, где имеется корреспондентский счет банка Получателя “ZOObank” и корреспондентский счет банка Плательщика “FOObank”.

Payer→GObank→Payee Payer→FOObank→ROOclearing→ZOObank→Payee

Если Payer желает произвести оплату со своего счета в банке FOObank (этот счет имеет более высокое значение приоритета в поле “pref” записи NAPTR record), тогда он должен использовать второй маршрут клиринга через ROOclering:

Payer→FOObank→ROOclearmg→ZOObank→Payee.

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

Пример транзакции кредитования.

Предположим, инфраструктура АПРИ включает Получателя, банк Получателя, Плательщика, банк Плательщика и Автоматизированную Клиринговую Палату (АКП) “www.CHIPS.com”, показанные на фиг.18. Оба банка и АКП являются Клиринговыми Организациями для собственных клиентов, причем каждый банк является Клиринговой и Маршрутизирующей Организацией для своих конечных клиентов, а АКП является Клиринговой и Маршрутизирующей Организацией для обоих банков, которые являются членами (клиентами) АКП. Предположим также, что услуги разрешения предоставляются DNS базой данных, в которой ЕТА вызываемого ресурса отображается в ЕТА Основной Клиринговой Организации вызываемого ресурса. ЕТА может быть как телефонным номером, так DNS именем или IP адресом или любым другим сетевым адресом или именем.

Представим себе, что Плательщик является web сайтом, имеющим адрес www.payer.com, а Получатель является пользователем мобильного телефона в США, имеющим номер [phone], имеющим счет в банке www.TargetBank.com.

Как показано на фиг.21, задачей является перевод средств платежа со счета www.payer.com на счет [phone]б7 в банке www.TargetBank.com;

Процедура платежа:

1. payer.com создает t-call 1: credit.PayerBank.com?paver.com/USD/1000/CHIPS/+l-(212)-123-4567/DigitalSignatureOFwww.payer.com;

2. www.payer.com устанавливает сетевое соединение, используя строку t-call 1, отформатированную в соответствии с правилами сети, например следуя Синтаксису RFC 2396, RFC 3406.

3. www.payerbank.com получает вызов t-call 1 и применяет к строке вызова Первое Известное Правило, затем банк Плательщика выполняет клиринг, поиск и разрешение идентификатора Получателя, используя параметры, взятые из строки t-call 1 в качестве “ключей” алгоритма, описанного в RFC 3402. Поскольку счет Получателя [phone]б7 расположен вне клирингового домена www.payerbank.com, результат разрешения будет пустым (ошибка DNS разрешения), поэтому результатом поиска Клиринговой Организации должно быть значение Основной Клиринговой Организации Верхнего Уровня, обозначенной как “THE_UPPER_TIER_DEFAULD_CLEARING_FACILITY” или для краткости “UTDCF”, которая может быть одной из клиринговых палат SWIFT, ABA или CHIPS, используемых банком www.payerbank.com в качестве Материнских ОКО. Из перечисленных должна быть выбрана палата CHIPS, поскольку имя “CHIPS” было указано в качестве параметра в строке t-call I.

4. банк www.payerbank.com создает строку t-call 2 в форме credit.chips.com?paverbank.com/payer.com/USD/1000/ON/+1 -(212)-123-4567/DigitalSignatureOFwww.payerbank.com. Уместно заметить, что нотация www.payer.com сама по себе может быть разрешена обратным образом, используя операцию INN-ADDR в payer.paverbank.com внутри www.paverbank.com поскольку www.paver.com, является хостом внутри клирингового домена www.payerbank.com банка Плательщика.

5. Банк Плательщика www.payerbank.com устанавливает сетевое соединение, используя строку вызова t-call 2, отформатированную в соответствии с правилами сети, такими как Синтаксис RFC 2396 и RFC 3406 например.

6. АКП www.CHIPS.com получает вызов t-call 2 и применяет к строке вызова процедуры извлечения параметров, поиска и разрешения имен. В результате идентификатор [phone]б7 разрешается в идентификатор 12121234567.TargetBank.chips.com, поскольку Банк Получателя является субдоменом внутри АКП CHIPS, а сам Получатель является хостом внутри домена Банка Получателя. Параметр “ON” обозначает режим реального времени исполнения клиринга и уведомления о проведении транзакции.

7. АКП www.CHIPS.com создает строку вызова t-call 5 в формате credit.TargetBank.com?chips.com/paverbank.com/paver.com/USD/1000/ON/+l-(212)-123-4567/DigitalSignatureOfwww.chips.com и устанавливает сетевое соединение для завершения операции кредитования. Уместно заметить, что нотация идентификатора Плательщика www.payer.com сама по себе может быть обратным образом разрешена, используя INN-ADDR операцию в имя payer, payerbank. chips.corn внутри www.chips.com, поскольку www.payer.com является хостом в клиринговом домене www.payerbank.com, а www.payerbank.com является суб доменом внутри www.chips.com зоны администрирования АКП CHIPS.

8. www.CHIPS.com создает строку вызова t-call 3 в форме debit.PayerBank.comPchips.com/payerbank.com/payer.com/USD/1000/ON/[phone]/DigitalSignatureOfwww.chips.com и устанавливает сетевое соединение для завершения операции дебитования.

9. www.payerbank.com создает строку вызова t-call 4 в форме debit.paverbank.com?paver.com/USD/1000/ON/[phone]/DigitalSignatureOFwww.payerbank.com.

10. банк www.TargetBank.com создает строку вызова t-call credit. 12121234567?chips.com/paverbank.com/paver.com/USD/1000/ON/[phone]/DigitalSignatureOfwww.TargetBank.com и устанавливает сетевое соединение для завершения операции кредитования Получателя платежа.

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

Очевидно, что передовая техника NAPTR RR и DDDS, предложенная в RFC 2916, 3401-3406, может быть использована для исполнения описанных примеров. В этом случае результат разрешения может быть получен в форме NAPTR:

рауее.сот

IN NAPTR 100 80 "a" "pay+N2C" "" [e-mail]. IN NAPTR 100 80 "a" "pay+N2D" "" Davee.com@.dedit.paveebankl.clearingi.corn, IN NAPTR 100 80 "a" "pay+N2B" "" pavee.com@,billmg.paveebank2.clearmg2.com.

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

Оптимизация маршрута клиринга по стоимости.

Хорошо известно, что электронные платежи имеют стоимость, и стоимость может различаться в зависимости от способа оплаты (через АВА, SWIFT или с помощью кредитной карты), в то время как Плательщик, Получатель и сумма платежа остаются неизменными. Фиг.18 иллюстрирует различные цепочки оплаты, включая различное число участников, и это число также может влиять на стоимость проведения транзакции, а также на время ее проведения.

Предположим, что инфраструктура АПРИ существует и реализует некую команду "cost", предположим также, что эта команда "cost" сходна существующей Интернет команде "tracert", но дополнительно возвращает стоимость проведения атомарного платежа точка-точка и другие характеристики в качестве параметров результата. Такая команда могла быть исполнена используя услуги поиска маршрута, как показано в примере "Случай предоставления услуг поиска маршрута", приведенном выше. Предполагая это для инфраструктуры, показанной на фиг.18, условная команда "cost", примененная к клиенту Client #3, обнаружила бы маршрут клиринга (Client#l→CF#l→CF#2→CF#3→Client#2), возвратив следующий результат:

C:\>cost'Client#2'.

Tracing route cost to 'Client#2' [212.24.32.169] over a maximum of 30 hops:

Route 1

1 10ms 10 ms 10 ms USD 0,32 CF#1 [192.168.1.3]

2 10ms 10 ms 10 ms USD 0,0 CF#2 [62.118.27.65]

3 10ms 10 ms 10 ms USD 0,5 CF#3 [10.4.255.100]

4 10ms 10 ms 10 ms USD 0,0 Client #2 [10.4.255.101]

Route 1 statistics:

Number of CF Nodes=3 Approximate payment cost USD 0,82 Approximate payment time 30 ms

C:\>

Теперь предположим, что клиент Client #1 хотел бы перевести деньги клиенту Client #3. Для этого он может использовать один из альтернативных маршрутов клиринга:

(Client#1→CF#1→CF#2→CF#3→CF#4→Client#3) or

(Client#1→CF#1→CF#2→CF#5→Client#3) or

(Client#1→CF#1→CF#6→CF#7→CF#5→Client#3).

Поэтому отработка команды 'cost' в отношении платежа (Client#1→Client#3) дала бы результат:

C:\>cost 'Client #3'.

Tracing route cost to 'Сliеnt#3' [212.24.32.169] over a maximum of 30 hops:

Route 1

1 10 ms 10 ms 10 ms USD 0,32 CF#1 [192.168.1.3]

2 10 ms 10 ms 10 ms USD 0,0 CF#2 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0,5 CF#3 [10.4.255.100]

4 10 ms 10 ms 10 ms USD 0,5 CF#4 [10.4.255.101]

5 10 ms 10 ms 10 ms USD 0,5 CF#3 [10.4.255.102]

Route 2

1 10 ms 10 ms 10 ms USD 0,32 CF#1 [192.168.1.3]

2 1 day 1 day 1 day USD 0,0 CF#2 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0,5 CF#5 [10.4.255.103]

4 10 ms 10 ms 10 ms USD 0,0 Client #3 [10.4.255.105]

Route 3

1 10 ms 10 ms 10 ms USD 0,32 CF#1 [192.168.1.3]

2 10 ms 10 ms 10 ms USDO,2 CF#6 [62.118.27.65]

3 10 ms 10 ms 10 ms USD 0,5 CF#7 [10.4.255.106]

3 10 ms 10 ms 10 ms USD 0,5 CF#5 [10.4.255.107]

4 10 ms 10 ms 10 ms USD 0,0 Client #3 [10.4.255.108]

Route 1 statistics:

Number of CF Nodes=4

Approximate payment cost USD 1,32

Approximate payment time 50 milliseconds Route 2 statistics:

Number of CF Nodes=3

Approximate payment cost USD 0,82

Approximate payment time 1 day and 30 milliseconds Route 3 statistics:

Number of CFNodes-4

Approximate payment cost USD 1,52

Approximate payment time 50 milliseconds

C:\>

Очевидно, что маршрут “Route 2” обладает наименьшей полной стоимостью ЕЕП в размере 0,82 долларов США, но одновременно с этим имеет наибольшую продолжительность клиринга, равную 1 день против 50 миллисекунд для маршрутов “Route 1” и “Route 3”. Техника команды 'cost' является вычислительной и позволяет управлять стоимостью и временем проведения платежей в режиме реального времени.

Приведенная техника АПРИ предоставляет уникальную реализацию ранжирования маршрутов клиринга с помощью команды “cost” для платежей ЕЕП. Такое ранжирование, в свою очередь, позволяет управлять маршрутами клиринга, учитывая предпочтения пользователей в отношении стоимости и сроков проведения транзакции, а потому изобретение предлагает практически осуществимое решение для финансовых институтов и их соответствующих клирингов, используя команду “cost” трассировки стоимости.

Использование платежных предпочтений в последнем примере с командой “cost” может позволить реализовать различные клиринговые сценарии, так, если первым предпочтением пользователя является клиринг в режиме реального времени и вторым предпочтением минимизация цены, то результатом управления клирингом будет маршрут “Route 1” с ценой cost USD 1.32 и временем 10 миллисекунд как самый дешевый способ маршрут с клирингом в режиме реального времени; а если первым предпочтением пользователя является минимальная цена и вторым - сроки клиринга, результатом управления клирингом будет выбор маршрута “Route 2” с ценой USD 0.82 и временем проведения 1 день.

Как показано в заявке, остается возможным использование существующей технологии Интернет, его транспорта техники разрешения и маршрутизации, а также использование зрелой технологии PKI для целей клиринга платежей, предоставляя в режиме реального времени многоуровневую и многомаршрутную клиринговую инфраструктуру и услуги проведения платежей, способствующие простому управлению стоимостью и маршрутами проведения платежей, создавая условия для сквозного процессирования (Straight Through Processing или STP) платежей ЕЕП. Управление стоимостью платежей в инфраструктуре АРПИ позволяет значительно сократить или вовсе избежать стоимости проведения клиринга, позволяя владельцам счетов управлять и контролировать стоимость в сроки проведения их платежей.

Специфические для разных сетей идентификаторы (такие как ЕТА, МЕТА и другие) и характерные для сетей программное обеспечение и интерфейсы пользователя (телефонный интерфейс пользователя, ориентированный на использование только цифровой клавиатуры) может быть использован для навигации и управления АРПИ, позволяя удобно адресовать платежи и автоматизировать их клиринг.

АРПИ позволяет пользователям адресовать платежи без необходимости знать банковские реквизиты получателя платежа и способы клиринга предоставляя в то же время возможность ЕЕП разрешения деталей счета получателя и сквозной процессинг платежей и их клиринг.

Изобретение АРПИ полностью изменяет сущность проведения платежей переводя их области частных решений проведения клиринга и предоставления банковских услуг в область стандартизованных технологических решений; из области работы с утомительными банковскими реквизитами в область работы с имеющими осмысленное значение и легкими в использовании сетевыми ЕТА идентификаторами и именами; от необходимости знания деталей банковских счетов к свободе использования услуг разрешения счетов; от невозможности проведения платежей с использованием цифровых клавиатур телефонов к свободе адресации платежей, используя существующие контактные списки телефонов; из бумажных технологий 20-го века в цифровые технологии работы в режиме реального времени и полной автоматизации.

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

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

АРПИ широко опирается на использование существующей инфраструктуры Интернет и его технологии, его протоколы, потому предоставляя уникально дешевый встроенный механизм сквозного процессинга платежей и автоматическим управлением, разрешением, маршрутизацией и окончательным проведением расчетов. Изобретение открывает двери модели SID (Shared Information and Data) для АРПИ, предоставляя Technology Neutral Architecture (TNA) для реализации форуму ТМ Forum's (www. tmforum.org) для реализации бизнес модели, называемой New Generation Operations Systems and Software (NGOSS).

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

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

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

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

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

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

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