извлечение желаемых данных из потока данных

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

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

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

3. Способ по п. 1, отличающийся тем, что номер сообщения, идентификатор типа сообщения и номер версии материнской формы помещают в имени файла материнской формы.

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

5. Способ по п. 3, отличающийся тем, что в поле заголовка формы пользователя помещают такое поле данных состояния, которое устанавливает, является ли форма пользователя пассивной (Р) или активной (А), причем записи, определяемые разговором (ЗОР), форматируют согласно полям, определенным в этой форме пользователя, только тогда, когда эта форма активна.

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

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

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

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

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

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

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

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

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

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

16. Система связи по п. 12, отличающаяся тем, что как материнская форма, так и форма пользователя являются файлами американского стандартного кода для обмена информацией (ASCII).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда процесс для записи сборки данных, определяемых разговором, завершает создание ЗОР, он помещает ее в блок RAM (память с произвольным доступом). Обычно один блок может содержать 5-10 ЗОР. Когда создание блока закончено, он записывается на жесткий диск связанного устройства телефонного обмена или посылается из устройства обмена к некоторому оборудованию ввода/вывода, например к жесткому диску центра управления процессом. Возможно также послать полученные блоки непосредственно к процессу постобработки.

У оператора имеется возможность выдать, например, ЗОР, форматированные разговорами некоторого абонента, из блоков, записанных на жестком диске центра управления процессом. Это выполняется командой Языка человеко-машинного общения (MML). Эта команда начинает программу чтения, в которой жестко закодированы структура файла формата сборки данных, определяемых разговором, и имена полей, соответствующих ее подфайлам. Чтение выполняют из кольцевого буфера жесткого диска.

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

Формат может быть, например, в форме

НОМЕР АБОНЕНТА РАЗГОВОРА - 10

при это имя поля есть номер абонента разговора, а цифровое значение 10 выражает место комбинации поля в ЗОР.

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

Структура подфайла файла формата имеет такой тип:

ПОЛЕ_В_ЗАПИСИ - ПОЗИЦИЯ

ИСТИНА - 0

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

IF CRPARA. SUB_REC(1).FIELD_IN_RECORD = TRUE THEN DO:

CALL MOVB("CALL TIME", MML_ FORMAT.RECORD_HEADER,...

Это означает, что, если поле, расположенное в положении 0 файла формата с именем CRPARA, которое здесь называется FIELD_IN_RECORD (ПОЛЕ_В_ЗАПИСИ), истинно, пользователь выбирает его при создании формата, затем ему дается имя CALL TIME (ВРЕМЯ РАЗГОВОРА) на понятном языке.

Имеется ряд недостатков в известном форматировании записей, определяемых разговором, описанном в разделе "Уровень техники" настоящего описания.

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

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

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

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

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

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

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

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

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

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

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

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

фиг.1 показывает принцип расчета стоимости,

фиг.2 - форматирование ЗОР,

фиг. 3 - элементы сети, принимающие участие в осуществлении этого изобретения,

фиг.4 - материнскую форму,

фиг.5 - форму пользователя,

фиг.6 - форматирование формы пользователя,

фиг.7 - использование формы в форматировании ЗОР.

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

Фиг. 3 показывает сеть связи, которая может быть сетью КТСОП ( коммутируемой телефонной сетью общего пользования) или ISDN (цифровой сетью с интеграцией служб), и которая содержит несколько телефонных устройств коммутации 1, 2,...,N, каждое из которых форматирует запись абонента ЗОР, относящуюся к разговору, произведенному абонентом через коммутационное оборудование. Система управления сетью (СУС), показанная ссылочным номером 4, осуществляет управление сетью путем управления различными коммутационными устройствами. Расчетный центр (РЦ), показанный ссылочным номером 5, принимает записи, определяемые разговором ЗОР, поступающие от различных коммутационных устройств, он обрабатывает их и формирует счета, которые должны быть направлены абонентам. Если нет отдельного управления сетью, тогда управление и конфигурация коммутационного оборудования могут быть выполнены в коммутационном оборудовании непосредственно, вместо использования дистанционной работы. Ссылочный номер 6 показывает универсальный компьютер, который содержит программу, с помощью которой оператор/пользователь использует материнскую форму для создания формы пользователя согласно этому изобретению. Поставщик телефонного коммутационного оборудования для этой цели создает материнскую форму способом, объясняемым здесь далее.

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

Сообщение является "сообщением загрузки сигнала", и его номер равен 04543. Поток данных сообщения является последовательными полями разной длины, например, первое поле в позиции 0 есть последовательный номер, и его длина равна одному байту, следующее поле в позиции 2 есть порядковый номер, и его длина составляет n слов. В действительности, в сообщении нет имен полей, но сообщение состоит из полей бит, которые находятся один за другим без перерывов и без каких-либо меток разделителей. Однако расположение каждого поля определяется однозначно, когда известны позиции и длины полей. Так, например, начало третьего поля инд_записи_разговора (позиция 3) определяется путем перехода от начала сообщения на число бит двух предшествующих полей сообщений, то есть вперед на одно слово и один байт. От этой точки вперед содержится столько бит третьего поля в потоке, сколько показано длиной поля.

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

Фиг. 4 показывает вид материнской формы. Имя файла, видимое в верхней части формы, содержит данные материнской формы: первые цифры последовательностей чисел, здесь 4543, дают номер сообщения, к которому относится форма, следующие три цифры 000 показывают тип сообщения. Буква М показывает, что форма является материнской формой. Три цифры после точки показывают версию в последовательности материнской формы: если сообщение изменено, материнская форма, конечно, также будет изменена, при этом она будет иметь новый номер версии. Эти данные, содержащиеся в имени файла, не являются частью собственно формы, но они поданы на дисплей программой Windows..

Заголовок формы на следующей строке содержит поля Номер формата, которые показывают номер и тип сообщения, Режим вывода, который здесь является BIN (двоичным), и показывает режим ЗОР, созданной с помощью этой формы, и Устройство вывода, которое показывает, куда записываются ЗОР, которые должны быть форматированы. Местом памяти может быть, например, VDS, то есть Система виртуального диска, или VIDAST, где несколько сотен ЗОР собраны на диске и затем посланы в виде блока (кластера) в вычислительный центр. Выходное устройство может также определить, что ЗОР посылаются сразу же после форматирования к cистеме горячего (немедленного) расчета.

Затем следуют данные, относящиеся к строке заголовка ЗОР, которая должна быть форматирована на материнской форме. Эти данные относятся к заголовкам ЗОР и сгруппированы под Именем поля заголовка, Типа и Длины заголовка. Таким образом, все поля заголовка и их данные, существующие в сообщении и не раскрытые набором инструмента, поступят под Именем поля заголовка. В примерах длина записи, длина_ записи_заголовка сначала определена как запись типа W (слово) и длиной в 2 слова.

После них следуют данные, относящиеся к полям данных ЗОР самого сообщения. Они сгруппированы под заголовками Имя поля данных, Тип, Длина, Позиция и Формат. Все поля данных и их данные, существующие в сообщении и не раскрытые набором инструмента, приходят под заголовками. Форма показывает, например, поле абонента А, тип данных, длину, позицию, (26-й байт в сообщении) и формат (BCD кодированный). В столбце Формат формы показан признак поля: BCD означает двоично-кодированный десятичный, DM есть единица информации. Цифры, помещенные после них, есть команды для программы форматирования. Например, цифра 1 может означать преобразование двоично кодированных данных в формат BCD.

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

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

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

Форма пользователя, показанная на фиг.5, имеет расположение, которое вполне подобно расположению материнской формы. Так, имя файла в ее верхней части содержит те же данные, что и материнская форма: первые цифры 4543 последовательности чисел дают номер сообщения, к которому относится материнская форма и, таким образом, также и форма пользователя, следующие три цифры 003 показывают тип сообщения. Буква Р констатирует, что эта форма является пассивной формой. Значение этого будет объяснено позднее. За точкой следуют три цифры, устанавливающие версию формы пользователя: пользователь может в любое время создать новую форму, при этом она будет иметь новый номер версии.

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

За этим следуют данные, относящиеся к строке первого заголовка форматируемой ЗОР, Имя поля заголовка, Тип и Длина. Сами поля, содержащиеся в ЗОР, идут под Именем поля данных, Типом, Длиной, Позицией и Форматом.

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

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

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

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

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

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

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

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

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

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

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

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

Когда оператор желает ввести определенную форму для получения желаемых ЗОР, он нажимает клавишу Активировать форму в программе, которая дает функцию MML с запросом активации формы. Эта команда выбирает желаемую форму из каталога и делает ее активной (функция 72). В то же время расчетный центр вводит ту же форму. Процесс форматирования 73 создает желаемые ЗОР, которые посылаются в расчетный центр.

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

Использование форм также очень удобно при повышении стандарта обмена, которое означает изменение программного обеспечения аппаратуры обмена. При этом в новый каталог компьютера берутся новые сгенерированные и стандартизованные материнские формы, соответствующие новому стандарту и имеющие в качестве своего имени файла, например 4543000М.100. Номер версии здесь был изменен на номер новой сотни, и первый номер равен 100. Активные в настоящее время формы пользователя затем копируются в тот же каталог, и запускается программа преобразования, которая приводит старые формы пользователя в соответствие с новым сообщением, где поля имеют новые позиции. Имена полей используются в качестве ключей для поиска. Версия изменяется в процессе преобразования, например 4543003А.008 --> 4543003Р.101, и подобным образом изменяется номер формата, например 003008 --> 003101. Новые пассивные формы затем посылаются к аппаратуре телефонного обмена на так называемую испытательную сторону, где выполняется тестирование нового программного обеспечения без взаимного влияния со старым действующим программным обеспечением, и к постобработке. Затем новые тестовые ЗОР посылаются от испытательной стороны, если это возможно, и проверяется правильное функционирование постобработки. По завершении тестирования новые формы активируются с испытательной стороны, и выполняется переключение, после чего в пользовании находятся новые формы.

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

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