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

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

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

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

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

4. Способ по п.2, отличающийся тем, что услуги связи ресурсам - участниками транзакций предоставляются Центральным Коммутатором с использованием Инфраструктуры Открытых Ключей Удостоверяющего Центра.

5. Способ по п.2, отличающийся тем, что цифровой сертификат соответствует формату Х.509, и указанный УС содержится в расширении сертификата Х.509; или указанный УС содержится в поле псевдонима сертификата; или в другом соответствующем поле сертификата.

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

7. Способ по п.2, отличающийся тем, что Центральный Коммутатор является Удостоверяющим центром (УЦ).

8. Способ по п.2 и по п.7, отличающийся тем, что указанный УЦ является Интернет Сервис Провайдером (ИСП).

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

10. Способ по п.1, отличающийся тем, что он включает шаг обновления данных в Файле ресурса Администратором Адресов Центрального Коммутатора.

11. Способ по п.1, отличающийся тем, что сетевые идентификаторы УС являются телефонным номером, или DNS именем, или URL, или адресом электронной почты, или Универсальным Платежным Идентификационным Кодом (УПИК), или Банковским Идентификационным Кодом (БИК), или другим сетевым идентификатором, или именем на естественном языке.

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

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

14. Способ по п.7 или 8, отличающийся тем, что Файлы ресурсов ИСП и ЦК совпадают.

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

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

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

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

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

20. Способ по п.18 или 19, отличающийся тем, что после получения платежной инструкции ЦК аутентифицирует сетевой идентификатор (УС) вызывающего ресурса, авторизует платежную инструкцию и предоставляет услугу проведения транзакции между вызывающим и вызываемым ресурсами.

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

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

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

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

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

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

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

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

29. Способ по п.2 или 28, отличающийся тем, что ресурс-шифровальщик ЗКК передает ЗЗКК в ЦК для размещения ЗЗКК в Файле ресурса, которому принадлежит ЗКК.

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

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

32. Способ по п.18, отличающийся тем, что ЦК является банком и/или Расчетным Центром или Центром Авторизации и/или ИСП и/или Удостоверяющим Центром.

33. Способ по любому из пп.1, 27, 28, 30, 31, отличающийся тем, что финансовые данные и реквизиты финансовых счетов являются банковскими данными и реквизитами банковского счета.

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

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

36. Способ по п.34, отличающийся тем, что для временных ресурсов Файла продается без УС или с временным УС.

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

38. Способ по п.37, отличающийся тем, что записываемый носитель информации является переносимым записываемым носителем информации.

39. Способ по п.38, отличающийся тем, что переносимый записываемый носитель информации является SIM картой для устройства GSM или идентификационным модулем для устройств связи третьего поколения (3G), или смарт картой, или картой с магнитной полосой, или носимым записываемым чипом памяти или процессором оснащенным памятью, или CD или DVD.

40. Способ по п.34, отличающийся тем, что Файл является Цифровым Паспортом ресурса.

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

42. Способ по п.2, отличающийся тем, что включает продажу услуг аутентификации с использованием указанного УС и/или Файла с оплатой за каждую операцию аутентификации.

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

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

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

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

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

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

49. Система по п.48, отличающаяся тем, что указанный цифровой сертификат соответствует формату Х.509, а в расширении Х.509 содержатся: указанный УС ресурса, или УС ресурса и УС Центра Авторизации, или УС ресурса и УС Центра Авторизации и зашифрованные или незашифрованные реквизиты банковского или другого финансового счета, или УС ресурса и зашифрованные или незашифрованные реквизиты банковского или другого финансового счета.

50. Система по п.48, отличающаяся тем, что Центральный Коммутатор является Удостоверяющим Центром.

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

52. Система по п.48, отличающаяся тем, что использует протокол защищенных соединений (Secure Socket Layer - SSL), а также Инфраструктуру Открытых Ключей PKI и услуги Удостоверяющего Центра УС.

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

54. Система по п.53, отличающаяся тем, что сообщение авторизации является авторизацией, подписанной цифровым способом, используя Закрытый Ключ Центра Авторизации.

55. Система по п.54, отличающаяся тем, что Продавец получает от Центра Авторизации сообщение авторизации и разрешает покупку, если авторизация платежа Центром Авторизации предоставлена.

56. Система по п.44, отличающаяся тем, что в ней, по меньшей мере, один из центров авторизации является банком.

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

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

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

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

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

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

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

Описание изобретения к патенту

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

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

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

Патент США №6151624 (в дальнейшем "патент 624") автора K.Teare и других, который включен в настоящее изобретение во всей полноте, который также рассматривается автором как наиболее близкий прототип настоящей заявки на изобретения и описывает систему и метод, которые способствуют поиску и доступу к сетевым ресурсам, таким как вэб-страница с использованием их естественно языковых наименований. В случае вэб-страницы система и метод 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/1-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 - TT), причем ВА может выступать в качестве временного абонента получателя или инициатора звонков в сети, в то время как Администратор Цифровой Сертификации-АЦС (предпочтительно он же свич сервер) выпускает ЕТА и ЦС ЕТА (цифровой сертификат ЕТА); размещает ЕТА и ЦС ЕТА сразу в Файле Номера Абонента или передает их торговому представителю (реселлеру); реселлер присваивает ЕТА/ЦС конкретному временному Абоненту, размещая их в ПФН такого Абонента.

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

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

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

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

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

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

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

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

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

Фиг.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>, </хm1>"), которые указывают что 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 строку <MLS:listings>, содержащую> 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 может содержать другие дополнительные атрибуты m. Например, другие атрибуты включают Организацию (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 и его процессы R1, R2, Rn исполняются на одном серверном компьютере, а Сервис Регистраций 22, Паук 24, и Построитель Индекса 32 функционируют на том же компьютере или на кластере компьютеров отдельных от сервера, размещающего Резолвер 40. В такой конфигурации Резолвер 40 может быстро получать и отвечать на запросы клиента о получении доступа к сетевым ресурсам, которые размещены в индексе Файлов индекса (Index Files) 34, не мешая и не влияя на работу других элементов и их функций.

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

Каждая из опций меню верхнего уровня может быть выбрана передвижением курсора, который генерируется клиентом 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 Corp), 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@xyzcorh.com

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

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

ТАБЛИЦА 5

СТРАНИЦА ПОДТВЕРЖДЕНИЯ

Ваш Файл Телефонного Номера был отправлен по адресу joe@xyzcorp.com. Теперь Вам следует сохранить этот файл на вашем вэб-сайте в соответствии с инструкциями в сообщении, которое вы получите. После исполнения этого шага файл должен быть активизирован через услуги активации Файла Телефонного Номера. (Просто следуйте по предыдущей ссылке или обратитесь в Службу Поддержки Пользователей, обратитесь в пункт меню Активизация, относящийся к категории Файл 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.

Страница состоит из секций текстовых инструкций, набора функциональных кнопок редактирования и списка записей ныне находящихся в Файле Номера. Текстовые инструкции поясняют функции, исполняемые функциональными кнопками. В предпочтительном исполнении, функциональные кнопки такой страницы действуют на все записи Файла Номера, а не на поля в отдельности. Например, для редактирования записи пользователь выбирает соответствующий телефонный номер, такой как "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, Mn Агента очередей (Queue Agent) 92a. Агент очередей 92a связан с сетью 106, такой как локальная сеть, и получает запросы на построение записей индекса от Библиотекаря 20. Агент очередей 92a распространяет копию каждого запроса одному из сетевых интерфейсов M1, M2, Mn, который в свою очередь передает запрос ассоциированной с ним GO машине 100, 102 или 104. Такая архитектура хорошо отвечает на внешние запросы и является устойчивой к ошибкам.

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

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

Предпочтительно, запросы на построение содержат идентификатор, называемый "FileId", файла или сроки, которые увязаны с Таблицей Информации Файла или ТИФ (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" параметру "rntn", который распознается резолвером. В случаях, когда телефонный номер размещен вместе с кодами города и страны, браузер клиента предпочтительно запрограммирован на добавление кодов страны и города к телефонному номеру, который вводится пользователем без одного или обоих кодов. Такая информация может быть получена в качестве вторичной из установок операционной системы 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. Такое устройство ввода обычно имеет две степени свободы по двум осям, первая ось (x), а вторая ось (y), которые позволяют устройству позиционироваться на плоскости.

Изобретение относится к использованию компьютерной системы 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, а Вторичный Файл Номера размещен по адресу Вторичный 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 и прочее.

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

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

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

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

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

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

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

Проверка доступности Абонента для связи в режиме реального времени (On-line 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<10 ms TTL=121

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

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

Reply from 212.24.32.169: bytes=32 time<10 ms 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 (http://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 ЕСС Algorithms in CMS" расположенной в Интернет по http://search.ietf.org/internet-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, а закрытая часть размещается в защищенном сегменте памяти Абонента. ЦС подписывается Закрытым ключом АЦС и содержит по меньшей мере номер ЕТА и Открытый ключ Абонента. ЦС соответствует формату Х.509; номер ЕТА содержится в Х.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 используется) здесь Абонент А (А) аутентифицирует Абонента В (В):

В:

Шифрует Данные В, используя Закрытый ключ В, формируя Данные В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 и проверяет "Пароль для временного ЕТА номера" ИЛИ сравнивает пароль с зашифрованным паролем, размещенным в защищенной памяти трубки; если проверка прошла успешно (пароль верный), пользователю предоставляется доступ к ресурсам сети, используя выбранный ЕТА а сам пользователь признается законным владельцем ЕТА; если проверка не увенчалась успехом, то трубке может быть отказано в предоставлении ресурсов сети или она может быть объявлена украденной в зависимости от того, что предусмотрено политикой безопасности сети, ИЛИ

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

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

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

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

Для этого каждый Абонент:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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