ДИСТАНЦИОННЫЙ ВВОД ИЗОБРАЖЕНИЯ С ЦЕНТРАЛИЗОВАННОЙ ОБРАБОТКОЙ И ХРАНЕНИЕМ Российский патент 2004 года по МПК G06F17/60 

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

Предшествующий уровень техники

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

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

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

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

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

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

Другие подходы концентрировались на исключении бумажных квитанций и документов. В патенте США №5590038 описана универсальная карточка электронных транзакций (УЭТ-карточка) или интеллектуальная карточка, которая хранит информацию транзакций в памяти на карточке в качестве замены бумажной квитанции. Аналогичным образом, в патенте США №5479510 описан способ электронной передачи и сохранения информации покупателя в момент покупки, которая считывается в более поздний момент времени, чтобы гарантировать, что приобретенные товары или услуги доставлены корректно определенному лицу.

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

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

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

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

Предлагались системы проверки биометрических данных, включающие в себя системы проверки подписей, направленные на решение проблем защищенности. Например, в патенте США №5657393 описаны способ и устройство для проверки рукописной подписи с использованием выделения и сравнения характеристик подписи, включая длину и угол линий выделенных элементов подписи. Кроме того, патент США №5602933 раскрывает способ и устройство для проверки дистанционно собранных данных с соответствующими данными, хранящимися в центральном пункте.

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

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

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

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

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

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

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

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

Также задачей системы DataTreasury™ является поиск бумажных и электронных транзакций в удаленных пунктах.

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

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

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

Еще одной задачей системы DataTreasury™ является извлечение данных счетов клиентов из срочных документов служащих и генерирование выписок со счетов клиентов из данных счетов.

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

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

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

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

фиг.1 - блок-схема, иллюстрирующая три основных операционных элемента изобретения: терминал доступа системы DataTreasury™ (ТДД), коллектор доступа системы DataTreasury™ (КДД) и концентратор обработки системы DataTreasury™ (КОД);

фиг.2 - блок-схема архитектуры ТДД;

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

фиг.3b - представление образца бумажной квитанции, обработанной посредством ТДД;

фиг.4 - блок-схема архитектуры КДД;

фиг.5 - блок-схема последовательности операций, иллюстрирующая опрос множества ТДД посредством КДД;

фиг.6 - блок-схема архитектуры КОД;

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

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

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

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

Детальное описание предпочтительных вариантов осуществления изобретения

На фиг.1 представлена система DataTreasury™ 100. Система DataTreasury™ 100 имеет три операционных элемента: терминал доступа системы DataTreasury™ (ТДД) 200 (удаленная подсистема доступа к данным), коллектор доступа системы DataTreasury™ (КДД) 400 (промежуточная подсистема сбора данных) и концентратор обработки системы DataTreasury™ (КОД) 600 (центральная подсистема обработки данных).

Архитектура системы DataTreasury™ 100 состоит из трех уровней. На нижнем уровне ТДД 200 извлекают данные с клиентских объектов. На следующем уровне КДД 400 опрашивает ТДД 200 для приема данных, которые накапливаются в ТДД 200. На верхнем уровне КОД 600 опрашивают КДД 400 для получения данных, которые накапливаются в КДД 400. КОД 600 сохраняют клиентские данные в центральном пункте, генерируют информационные сообщения из данных и передают эти информационные сообщения к клиентам в удаленные пункты.

В предпочтительном варианте осуществления система DataTreasury™ 100 совместима с промышленным стандартом Price Waterhouse SAS70. Более конкретно, система DataTreasury™ 100 удовлетворяет стандарту разработки программного обеспечения, стандарту развертывания системы и стандарту надежности, определенным в стандарте Price Waterhouse SAS70. За счет совместимости со стандартом Price Waterhouse SAS70 система DataTreasury™ 100 обеспечивает защищенность, доступность и надежность, требуемые в критически важных финансовых приложениях, используемых банками и брокерскими компаниями.

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

На фиг.2 представлена блок-схема архитектуры ТДД 200. ТДД 200 расположены на клиентских объектах. К клиентам системы DataTreasury™ 100 относятся продавцы, потребители и банкиры. ТДД 200 действуют в качестве пунктов контакта с клиентами для предоставления услуг, обеспечиваемых системой DataTreasury™ 100. В предпочтительном варианте осуществления ТДД 200 проектируется по техническим условиям заказчика на основе универсального простого клиентского сетевого компьютера (СК), который использует операционную систему JAVA/OS компании SUN Microsystem. Заказной ТДД 200 включает в себя сканер 202 ТДД модем 204 ТДД цифровую память 206 ТДД, контроллер (рабочую станцию) 210 ТДД интерфейс 212 ТДД карточек, а также, факультативно, принтер 208 ТДД и панель подписи 214.

Специалистам в данной области техники должно быть также ясно, что ТДД 200 может быть спроектирован по техническим условиям заказчика на основе универсального клиентского сетевого компьютера, который использует другие операционные системы, если такая операционная система обеспечивает поддержку мультипроцессорной обработки, управления памятью и динамического связывания, что требуется системой DataTreasury™ 100.

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

В дополнение к сканированию изображений и текста, сканер 202 ТДД также сканирует элементы типа DataGlyph™ (глифы данных) согласно технологии, введенной компанией Xerox. Специалистам в данной области техники известно, что технология DataGlyph™ компании Xerox представляет цифровую информацию машиночитаемыми данными, которые кодированы в виде множества простых индивидуальных элементов - глифов. Каждый глиф состоит из диагональной линии под 45°, которая может составлять 1/100 долю дюйма в зависимости от разрешения устройств сканирования и печати. Каждый глиф представляет двоичный 0 или двоичную 1 в зависимости от его наклона вниз влево или вправо соответственно. Таким образом, элементы DataGlyph™ могут представлять строки символов, подобно представлениям ASCII (Американский стандартный код обмена информацией) или ЕВСIDIС (расширенный двоичный код обмена информацией). Кроме того, способы шифрования, известные специалистам в данной области техники, используются для шифрования данных, представленных согласно технологии DataGlyph™.

Использование технологии глифов в системе DataTreasury™ 100 повышает точность, экономичность и эффективность системы. Технология DataGlyph™ компании Xerox предусматривает использование кодов исправления ошибок для коррекции ошибок сканирования или для устранения повреждений документов, вызванных чернильными пятнами или обычным износом. Технология DataGlyph™ также приводит к снижению стоимости системы, поскольку система будет требовать меньше ручного вмешательства в процесс ввода данных и коррекции, ввиду повышенной точности, обеспечиваемой использованием элементов технологии DataGlyph™. Поскольку элементы технологии DataGlyph™ представляют большое количество информации в малом объеме пространства, сканер 200 ТДД будет требовать меньше времени для ввода большого объема информации.

Интерфейс 212 карточки ТДД и панель подписи 214 ТДД вместе с доступом к сети Интернет и к телефонной сети через модем 204 ТДД позволяют клиенту системы DataTreasury™ 100 инициировать торговые и банковские транзакции через сеть Интернет или телефонную сеть с помощью ТДД 200 с использованием различных карточек, включая дебетовые карточки, интеллектуальные карточки и кредитные карточки. После выбора покупки или банковской транзакции посредством стандартного интерфейса сети Интернет, клиент системы DataTreasury™ 100 вводит дебетовую карточку, интеллектуальную карточку или кредитную карточку в интерфейс 212 карточки ИДД.

Интерфейс 212 карточки ТДД извлекает идентификационную информацию с карточки для последующей передачи адресату транзакции, осуществляемой через сеть Интернет. Кроме того, сканер 202 ТДД может вводить рукописную подпись с документа, или панель подписи 214 ТДД может вводить записанную на ней электронную подпись с помощью специального пера. Аналогичным образом, эти средства защищенности позволяют реципиенту кредитной карточки активизировать карточку с помощью ТДД 200, расположенного на объекте продавца. Средства защищенности будут обнаруживать несанкционированное использование дебетовых карточек, интеллектуальных карточек и кредитных карточек, обусловленное их неправомерным захватом. Соответственно средства защиты системы DataTreasury™ 100 предоставляют более надежную альтернативу для транзакций, осуществляемых через сеть Интернет или телефонную сеть, по сравнению с традиционными методами, которые требуют только пересылки номера счета карточки и даты истечения срока ее действия.

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

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

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

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

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

Контроллер 210 ТДД выполняет задачи обработки и задачи ввода/вывода, обычно выполняемые процессором. Контроллер 210 ТДД осуществляет сжатие, шифрование и тегирование РИ для формирования тегированного шифрованного сжатого растрового изображения (ТШСРИ). Контроллер 210 ТДД также управляет вводом/выводом. Более конкретно, контроллер 210 ТДД управляет такими устройствами, как сканер 202 ТДД, цифровая память 206 ТДД, принтер 208 ТДД и модем 204 ТДД.

Цифровая память 208 ТДД хранит такие данные, как ТШСРИ. Модем 204 ТДД передает данные от ТДД 200 к соответствующему КДД 400 в соответствии с командами от контроллера 210 ТДД. Более конкретно, модем 204 ТДД передает ТШСРИ от цифровой памяти 208 к соответствующему КДД 400. В предпочтительном варианте осуществления модем 204 ТДД представляет собой высокоскоростной модем с установлением соединения по телефонной линии. Цифровая память 208 ТДД имеет достаточно большой объем, чтобы хранить введенные данные до передачи их к КДД 400. Цифровая память 208 ТДД может представлять собой запоминающее устройство с произвольной выборкой (ЗУПВ) или накопитель на жестких дисках.

На фиг.3а представлена блок-схема 300 последовательности операций, детально описывающая работу ТДД. На этапе 310 сканер 202 ТДД сканирует бумажные квитанции, вводя данные в ТДД, обслуживаемый оператором. На этапе 312 контроллер 210 ТДД определяет, выполнена ли успешно операция. Если сканирование успешно, то сканер 202 ТДД формирует РИ. Если сканирование безуспешно, то контроллер 210 ТДД уведомляет оператора о неисправности и на этапе 370 предлагает оператору устранить неисправность.

Если РИ создано, контроллер 210 ТДД на этапе 314 выполняет обычный алгоритм сжатия изображений, например программу формата файла тегированного изображения (ФФТИ), для сжатия РИ. На этапе 315 контроллер 210 ТДД определяет, успешно ли выполнено сжатие. Если сжатие успешно, то он формирует сжатое РИ (СРИ). Если сжатие безуспешно, то контроллер 210 ТДД уведомляет оператора о неисправности и на этапе 370 предлагает оператору устранить неисправность.

Если СРИ создано, то контроллер 210 ТДД на этапе 318 выполняет алгоритм шифрования, известный специалистам в данной области техники, для шифрования СРИ. Шифрование обеспечивает защиту против несанкционированного доступа в процессе последующей передачи данных, что будет подробно рассмотрено ниже. На этапе 320 контроллер 210 ТДД определяет, успешно ли выполнена операция шифрования. Если шифрование успешно, то он формирует шифрованное сжатое растровое изображение (ШСРИ). Если шифрование безуспешно, то контроллер 210 ТДД уведомляет оператора о неисправности и на этапе 370 предлагает оператору устранить неисправность.

Если ШСРИ создано, то контроллер 210 ТДД на этапе 322 осуществляет тегирование ШСРИ с помощью временных меток, что включает время сканирования, идентификационный номер для идентификации продавца, обусловившего сканирование, и любую дополнительную полезную информацию. На этапе 324 контроллер 210 ТДД определяет, успешно ли выполнена операция тегирования. Если тегирование успешно, то он формирует тегированное шифрованное сжатое растровое изображение (ТШСРИ). Если тегирование безуспешно, то контроллер 210 ТДД уведомляет оператора о неисправности и на этапе 370 предлагает оператору устранить неисправность.

Если ТШСРИ создано, то контроллер 210 ТДД на этапе 326 сохраняет ТШСРИ в цифровой памяти 208 ТДД На этапе 328 контроллер 210 ТДД определяет, успешно ли выполнена операция сохранения. Если операция сохранения выполнена успешно, то цифровая память 208 ТДД будет содержать ТШСРИ. Если операция сохранения безуспешна, то контроллер 210 ТДД уведомляет оператора о неисправности и на этапе 370 предлагает оператору устранить неисправность.

Если ТШСРИ надлежащим образом сохранено в цифровой памяти 208 ТДД, то контроллер 210 ТДД на этапе 330 определяет, все ли бумажные квитанции просканированы. Если не все бумажные квитанции просканированы, то процедура возвращается к этапу 310, на котором следующая бумажная квитанция обрабатывается, как описано выше. Если все бумажные квитанции просканированы, то контроллер 210 на этапе 334 запрашивает оператора о проверке числа просканированных квитанций. Если число просканированных квитанций, как определено контроллером 210 ТДД, не равно числу просканированных квитанций, как определено оператором, то контроллер 210 ТДД на этапе 338 запрашивает оператора, не желает ли он повторно просканировать все квитанции.

Если оператор принимает решение просканировать повторно все квитанции на этапе 338, то контроллер 210 ТДД на этапе 342 удалит все ТШСРИ, связанные с пакетом из цифровой памяти 208 ТДД. После того как оператор подготовит пакет квитанций для повторного сканирования на этапе 346, процедура возвращается к этапу 310, на котором первая квитанция в пакете будет обрабатываться, как описано выше.

Если оператор принимает решение на этапе 338 не сканировать повторно все квитанции из пакета, то процедура возвращается к этапу 334, на котором контроллер 210 запрашивает оператора о проверке числа просканированных квитанций, как описано выше.

Если число просканированных квитанций, как определено контроллером 210 ТДД, равно числу просканированных квитанций, как определено оператором, контроллер 210 ТДД на этапе 350 распечатывает мандат пакета на принтере 206 ТДД. Оператор присоединяет этот мандат пакета к пакету квитанций, которые были просканированы. Этот мандат пакета должен содержать релевантную информацию сеанса обработки, в том числе время сканирования, число квитанций, идентификационный номер оператора, осуществляющего обработку данных. Если для пакета квитанций возникают проблемы после того, как произведен ввод изображений согласно блок-схеме 300, то мандат пакета позволит быстро их локализовать для повторного сканирования с помощью ТДД 200.

На этапе 354 контроллер 210 ТДД определяет, завершен ли сеанс сканирования. Если сеанс сканирования не завершен, то процедура переходит к этапу 310, на котором первая квитанция в следующем пакете сеанса сканирования будет обрабатываться, как обсуждено выше. Если сеанс сканирования завершен, то контроллер 210 ТДД на этапе 358 селективно распечатывает отчет о сеансе на принтере 206 ТДД. Контроллер 210 ТДД на этапе 362 записывает статистическую информацию для сеанса в цифровой памяти 208. На этапе 366 контроллер 210 ТДД завершает сеанс сканирования.

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

А. Эмитент - организация, такая как банк или корпоративный финансовый институт, например GE Capital, GM, AT&T, которая обеспечивает кредит для кредитной карточки и выпускает карточку для клиента.

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

С. Сборщик данных - специализируется на маркетинге, инсталляции и поддержке терминалов кредитных карточек электронных кассовых аппаратов. Сборщик данных, подобно коллектору доступа к данным 400 в системе DataTreasury™ 100, действует в качестве электронного пункта сбора данных для исходной транзакции с кредитной карточкой, когда карточка введена в электронный кассовый аппарат. После сбора данных Сборщик передает транзакцию Процессору.

D. Продавец - вводит кредитную карточку в терминал электронного кассового аппарата и вводит сумму транзакции для инициирования транзакции с кредитной карточкой.

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

ИД (идентификатор) КЛИЕНТА 370: Это поле представляет собой 7-позиционное шестнадцатеричное числовое значение. Это поле уникальным образом идентифицирует клиента, использующего терминал. В данном образце это поле должно идентифицировать продавца кредитной карточки.

ИД_ТЕРМИНАЛА 372: Это поле представляет собой 6-позиционное десятичное числовое значение. Это поле уникальным образом идентифицирует терминал кредитных карточек, который используется для распечатки квитанции кредитной карточки.

ДАТА_ТРАНЗАКЦИИ 374: Это поле содержит дату и время транзакции с кредитной карточкой.

ЭЛЕМЕНТ_СТРОКИ_ТРАНЗАКЦИИ 376: Это поле является последовательностью символов переменной длины. Первые три позиции представляют правильно подтвержденное числовое поле с начальными нулями, указывающее полную длину этого поля. Это поле содержит все данные, касающиеся приобретаемого объекта, включая цену объекта. ТДД 200 будет запоминать поле ЭЛЕМЕНТ_СТРОКИ_ТРАНЗАКЦИИ для каждого элемента строки транзакции на квитанции. Это поле является факультативным, поскольку не все транзакции с кредитными карточками будут иметь элементы строки транзакции.

ПРОМЕЖУТОЧНЫЙ_ИТОГ_ТРАНЗАКЦИИ 378: Это поле представляет собой число с плавающей запятой с двойной точностью. Это поле указывает промежуточный итог ЭЛЕМЕНТОВ_СТРОКИ_ТРАНЗАКЦИИ.

НАЛОГ_С_ПРОДАЖ_ТРАНЗАКЦИИ 380: Это поле представляет собой число с плавающей запятой с двойной точностью. Это поле содержит налог с продаж для ПРОМЕЖУТОЧНОГО_ИТОГА_ТРАНЗАКЦИИ.

СУММА_ТРАНЗАКЦИИ 382: Это поле представляет собой число с плавающей запятой с двойной точностью. Это поле является суммой ПРОМЕЖУТОЧНОГО_ИТОГА_ТРАНЗАКЦИИ и НАЛОГА_С_ПРОДАЖ_ТРАНЗАКЦИИ.

НОМЕР_СЧЕТА_КРЕДИТНОЙ_КАРТОЧКИ 384: Это поле представляет собой 12-позиционное десятичное значение. Это поле идентифицирует кредитную карточку, которая была использована для выполнения данной транзакции.

ДАТА_ИСТЕЧЕНИЯ_СРОКА_КРЕДИТНОЙ_КАРТОЧКИ 386: Это поле идентифицирует дату истечения срока действия кредитной карточки.

КОД_РАЗРЕШЕНИЯ_ТРАНЗАЦИИ 388: Это поле представляет собой 6-позиционное десятичное значение. Это поле указывает код разрешения, который был присвоен для конкретной транзакции.

ТДД 200 также сохраняет дополнительные элементы данных, которые не представлены на фиг.3b, в числе которых следующие:

ИД_ЭМИТЕНТА: Это поле представляет собой 7-позиционное десятичное числовое значение. Это поле идентифицирует эмитента кредитной карточки.

ИД_СБОРЩИКА_ДАННЫХ: Это поле представляет собой 7-позиционное десятичное числовое значение. Это поле идентифицирует сборщика данных.

ИД_ПРОЦЕССОРА: Это поле представляет собой 7-позиционное десятичное числовое значение. Это поле идентифицирует процессор.

СЧЕТ_ЭЛЕМЕНТОВ_СТРОКИ_ТРАНЗАКЦИИ: Это поле представляет собой 3-позиционное десятичное числовое значение. Это поле идентифицирует число элементов строки транзакции на квитанции. Значение НУЛЬ указывает на отсутствие элементов строки транзакции на квитанции.

ДЕНЕЖНОЕ_ВОЗНАГРАЖДЕНИЕ_ТРАНЗАКЦИИ: Данное поле представляет собой число с плавающей запятой с двойной точностью. Это поле является факультативным, поскольку оно появляется только на квитанциях ресторанов или баров.

КОНЕЧНАЯ_СУММА_ТРАНЗАКЦИИ: Данное поле представляет собой число с плавающей запятой с двойной точностью. Это поле является факультативным, поскольку оно появляется только на квитанциях ресторанов или баров. Поле представляет собой сумму полей СУММА_ТРАНЗАКЦИИ и ДЕНЕЖНОЕ_ВОЗНАГРАЖДЕНИЕ_ТРАНЗАКЦИИ.

Метка, присоединенная к ШСРИ на этапе 322 в блок-схеме последовательности операций по фиг.3а, идентифицирует время и место выпуска документа. Более конкретно, метка состоит из следующих полей:

ИД_ТЕРМИНАЛА_ДОСТУПА_К_ДАННЫМ: Это поле представляет собой 7-позиционное шестнадцатеричное числовое значение. Это поле уникальным образом идентифицирует ТДД 200, который использован клиентом.

ДАТА_СЕАНСА_ТДД: Это поле идентифицирует дату и время сеанса ТДД 200, который генерировал изображение документа.

ИД_ПОЛЬЗОВАТЕЛЯ_ТДД: Это поле представляет собой 4-позиционное десятичное числовое значение. Это поле идентифицирует лицо в организации КЛИЕНТА, которое инициировало сеанс ТДД 200.

РЕЗУЛЬТАТ_ГЛИФА_ДАННЫХ: Это поле представляет собой последовательность символов переменной длины. Первые четыре позиции содержат правильно подтвержденную числовую позицию с начальными нулями, которая указывает длину поля. Пятая позиция указывает статус элемента DataGlyph™. Значение 0 указывает на отсутствие глифа данных на квитанции. Значение 1 указывает, что глиф данных присутствовал и не содержал ошибок. Значение 2 указывает, что глиф данных присутствовал и имел номинальные ошибки. Если пятая позиция этого поля имеет значение 2, то остальная часть строки указывает номера ошибочных полей. Как описано ниже, КОД 600 будет ссылаться на эту часть поля для захвата ошибочных данных из квитанции с использованием альтернативных методов. Значение 3 указывает, что глиф данных присутствовал с серьезными ошибками. Иными словами, значение 3 указывает, что элемент DataGlyph™ был серьезно поврежден и является не считываемым.

Квитанция, показанная на фиг.3b, может также содержать подпись, которая может сканироваться сканером 202 ТДД. Глиф данных может идентифицировать местоположение подписи на квитанции.

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

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

КДД 400 образуют основу уровневой архитектуры, показанной на фиг.1 и фиг.4. Как показано на фиг.1, КДД 400 поддерживает регион, содержащий группу ТДД 200. Каждый КДД 400 опрашивает ТДД 200 в своем регионе и принимает ТШСРИ, накопленные в ТДД 200. КДД 400 располагаются в ключевых центральных пунктах, характеризуемых наибольшей плотностью торговых организаций.

В предпочтительном варианте осуществления сервер КДД 402 содержит автономные серверы SMP Alpha 4100 2/566 корпорации DEC (Digital Equipment Corporation), которые соединены с общей сетью, использующей программное обеспечение Windows NT. Серверы Alpha корпорации DEC управляют сбором и промежуточным хранением изображений и данных, которые принимаются от ТДД 200. Специалистам в данной области техники должно быть понятно, что система DataTreasury™ 100 может использовать любое число серверов, которые могут выпускаться и другими поставщиками компьютеров, если только такой сервер удовлетворяет требованиям системы по производительности, эффективности и надежности.

В предпочтительном варианте осуществления сервер 402 КДД также содержит Системы хранения данных на дисках ЕМС 3300 SYMMETRIX CUBE, которые хранят изображения и данные, собранные и упорядоченные серверами DEC Alpha. Архитектура КДД 400 также использует Аппаратуру обработки дистанционно получаемых данных типа SYMMETRIX (SRDF), поставляемую компанией ЕМС, для обеспечения возможности множеству физически разделенных центров обработки данных, содержащих Системы хранения ЕМС, поддерживать резервирование с избыточностью друг для друга в пределах глобальной сети. Поскольку аппаратура SRDF выполняет операции резервирования в фоновом режиме, она не влияет на рабочие характеристики системы DataTreasury™ 100. Сервер 402 КДД также имеет вторичную память 410. В предпочтительном варианте осуществления вторичная память 410 представляет собой накопитель с автоматической сменой носителей с ограниченными возможностями на магнитной ленте с линейной записью.

Серверы DEC Alpha сервера 402 КДД вводят изображения и данные, полученные от ТДД 200, в базу данных, которая хранится в системе хранения на дисках, с использованием языка манипулирования данными, что хорошо известно специалистам в данной области техники. В предпочтительном варианте осуществления база данных представляет собой реляционную базу данных, поставляемую компанией Oracle.

Специалистам в данной области техники должно быть понятно, что система DataTreasury™ 100 может использовать любую из множества различных моделей баз данных, поставляемых на рынок другими поставщиками, включая базы данных модели “объект-отношение”, если выбранная база данных удовлетворяет требованиям эффективности хранения и доступа системы (см., например, Korth, Silberschatz. Database System Concepts, Chapter 2).

Архитектура КДД 400 использует парадигму на основе WEB, использующую Усовершенствованные Услуги Имен Доменов (DNS), Объектную Модель Компонентов компании Microsoft (DCOM) и Интерфейсы Прикладных Программ (APIs) Windows NT для обеспечения информационного обмена и выравнивания нагрузки между серверами, образующими сервер 402 КДД. Специалистам в данной области техники должно быть понятно, что услуга DNS, известная так же как Bind (привязка), статически транслирует запросы адресов в адреса Протокола Интернет 4 (IР4). В архитектуре КДД 400 усовершенствованная услуга DNS динамически присваивает адреса протокола IP4 для выравнивания нагрузки между серверами, образующими сервер 402 КДД.

В предпочтительном варианте осуществления усовершенствованная услуга DNS спроектирована и реализована с использованием объектов модели DCOM компании Microsoft. С использованием этой модели усовершенствованная услуга DNS собирает в реальном времени статистические данные о характеристиках нагрузки по каждому из серверов, образующих сервер 402 КДД с интерфейсов Windows NE API в установленные интервалы времени. Основываясь на этих статистических данных о характеристиках нагрузки, усовершенствованная услуга DNS настраивает отображение запросов имен в адреса протокола IР4 для направления данных к серверам, которые нагружены в меньшей степени.

Большой набор модемов 404 опрашивает ТДД 200 на клиентских объектах в регионе, обслуживаемом КДД 400. В предпочтительном варианте осуществления набор модемов 404, поставляемый в виде модели CISCO AS5200, представляет собой устройство, состоящее из 48 модемов, соединенных локальной сетью 406, что позволяет серверам 402 КДД набирать номера ТДД 200, не требуя для этого отдельных 48 модемов и последовательных соединений.

Серверы 402 КДД и набор модемов 404 соединены с локальной сетью 406. В предпочтительном варианте осуществления локальная сеть использует протокол уровня аппаратных средств коммутируемой связи 100BaseT/10BaseT. Специалистам в данной области техники известно, что протокол 100BaseT/10BaseT основан на модели сети Ethernet. Кроме того, числа 100 и 10 относятся к скорости канала связи в Мбит/с. В предпочтительном варианте осуществления Сетевой коммутатор модели CISCO Catalyst 2900 поддерживает соединения локальной сети 406 между устройствами, подсоединенными к локальной сети 406, включая серверы 402 КДД и набор модемов 404.

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

Маршрутизатор 408 глобальной сети соединяет локальную сеть 406 с глобальной сетью для обеспечения информационного обмена между КДД 400 и КОД 600. В предпочтительном варианте осуществления маршрутизатор 408 глобальной сети представляет собой маршрутизатор модели CISCO 4700. Маршрутизатор 408 глобальной сети использует соединения с ретрансляцией кадров для соединения локальной сети 406 КДД с глобальной сетью. Специалистам в данной области техники должно быть ясно, что для обеспечения информационного обмена между КДД 400 и КОД 600 могут быть использованы и другие устройства, например, телекоммуникационный коммутатор модели NORTEL Magellen Passport "50", если выбранный маршрутизатор удовлетворяет требованиям эффективности и качества связи системы.

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

Каждый кадр включает в себя один пользовательский пакет и добавляет к нему информацию адресации и проверки. Информационный обмен на основе ретрансляции кадров использует скорости передачи от 56 Кб/с до 1,544 Мб/с.

Кадры могут варьироваться по длине вплоть до предельного значения, примерно равного 1 Кб/с.

Глобальная сеть 412 коммуникационных каналов компании Telco представляет собой коммуникационную сеть, которая принимает кадры, адресованные КОД 600, переданные маршрутизатором 408 глобальной сети от КДД 400. Как известно специалистам в данной области техники, коммуникационные каналы обеспечивают услуги связи в локальных центральных станциях. Эти центральные станции содержат сетевое оборудование и аппаратуру для взаимных соединений телефонных коммуникаций и коммуникаций передачи данных с другими центральными станциями в пределах собственной сети и в пределах сетей других коммуникационных каналов.

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

На фиг.5 представлена блок-схема 500 последовательности операций, описывающая опрос ТДД 200, осуществляемый КДД 400 и передачу ТШСРИ от ТДД 200 к КДД 400. На этапе 502 сервер 402 КДД считывает адрес первого ТДД 200 в его регионе для опроса. На этапе 504 модем в наборе модемов 404 набирает номер первого ТДД 200. КДД 400 на этапе 506 определяет, был ли успешным вызов, направленный к ТДД 200. Если вызов первого ТДД 200 был безуспешным, КДД 400 регистрирует состояние ошибки в сообщении итогов сеанса и на этапе 522 направляет сообщение об ошибке в КОД 600.

Если вызов первого ТДД 200 был успешным, то КДД 400 на этапе 508 будет проверять, готов ли первый ТДД 200 к передаче. Если ТДД 200 не готов к передаче, то КДД 400 регистрирует состояние ошибки и на этапе 522 направляет сообщение об ошибке к КОД 600.

Если на этапе 508 определено, что ТДД 200 готов передавать данные, то ТДД 200 на этапе 510 будет передавать заголовок пакета ТШСРИ в КДД 400. КДД 400 будет определять на этапе 512, успешно ли осуществлена передача заголовка пакета ТШСРИ. Если передача заголовка пакета ТШСРИ безуспешна, то КДД 400 будет регистрировать состояние ошибки в отчете об итогах сеанса и передаст сообщение об ошибке к КОД 600 на этапе 522.

Если передача заголовка пакета ТШСРИ на этапе 512 успешна, то ТДД 200 на этапе 514 будет передавать пакет ТШСРИ к КДД 400. КДД 400 определяет на этапе 516, успешно ли осуществлена передача пакета ТШСРИ. Если передача пакета ТШСРИ безуспешна, то КДД 400 будет регистрировать состояние ошибки в отчете об итогах сеанса и передаст сообщение об ошибке к КОД 600 на этапе 522.

Если передача пакета ТШСРИ на этапе 516 успешна, то КДД 400 на этапе 518 будет сравнивать заголовок пакета ТШСРИ, переданный на этапе 510, с пакетом ТШСРИ, переданным на этапе 514. Если заголовок пакета ТШСРИ не согласуется с пактом ТШСРИ, то КДД 400 будет регистрировать состояние ошибки в отчете об итогах сеанса и передаст сообщение об ошибке к КОД 600 на этапе 522.

Если на этапе 518 определено, что заголовок пакета ТШСРИ соответствует пакету ТШСРИ, то КДД 400 на этапе 520 будет устанавливать статус пакета ТШСРИ, чтобы указать, что он готов для передачи в КОД 600. КДД 400 на этапе 520 также передает статус в ТДД, чтобы указать на успешное завершение сеанса опроса и передачи на этапе 520. Затем КДД 400 будет определять на этапе 524, переданы ли ТШСРИ от всех ТДД в его регионе. Если все ТДД в регионе данного КДД 400 передали ТШСРИ к КДД 400, то КДД 400 будет формировать сообщение статуса ТДД 200 на этапе 528 перед завершением сеанса.

Если один или несколько ТДД 200 в регионе данного КДД 400 не передали ТШСРИ к КДД 400, то КДД 400 будет получать адрес следующего ТДД 200 на этапе 526. Затем процедура обработки возвращается к этапу 504, на котором следующий ТДД в регионе данного КДД 400 будет опрашиваться, как описано выше. В предпочтительном варианте осуществления сервер 402 КДД инициирует опрос и передачу данных во время, соответственно оптимальным тарифам, чтобы снизить стоимость передачи данных. Помимо использования массивов недорогих дисковых накопителей и резервных серверов, КДД 400 должен также иметь двойные блоки резервирования на магнитной ленте, которые периодически дублируют запись всего множества вводимых данных. Если в КДД 400 произойдет катастрофический отказ, то производится обращение к блокам резервирования и соответствующие данные непосредственно направляются в КОД 600 для обработки. По мере осуществления опроса ТДД 200 и передачи данных, КДД 400 периодически обновляет данные о своем статусе для КОД 600. При возникновении катастрофического отказа в КДД 400 КОД 600 имеет сведения о том, какой объем данных опроса и резервирования получен в вышедшем из строя КДД 400. Соответственно КОД 600 может просто назначить другой КДД 400 для завершения опроса и передачи данных от ТДД 200 в регионе этого КДД 400.

На фиг.6 представлена блок-схема архитектуры КОД 600. КОД 600 накапливает, обрабатывает и сохраняет изображения для последующего считывания клиентами системы DataTreasury™, которые имеют право доступа к соответствующей информации. Клиентами системы DataTreasury™ могут являться продавцы, компании, выпускающие кредитные карточки, компании, использующие информацию о кредитах, и потребители. Как показано на фиг.6 и фиг.1, КОД 600 опрашивает КДД 400 и получает ТШСРИ, которые были накоплены в КДД 400.

В предпочтительном варианте осуществления сервер 602 КОД содержит автономные серверы SMP Alpha 4100 4/566 компании Digital Equipment Corporation, которые соединены в общую сеть, использующую программное обеспечение Windows NT. Серверы DEC Alpha управляют сбором и промежуточным хранением изображений и данных, которые принимаются от КДД 400.

В предпочтительном варианте осуществления сервер 602 КОД также содержит Систему хранения данных на дисках ЕМС 3700 SYMMETRIX CUBE, предназначенную для хранения изображений и данных, которые собраны и управляются серверами DEC Alpha. Подобно архитектуре КДД 400, архитектура КОД 600 использует Аппаратуру обработки дистанционно получаемых данных типа SYMMETRIX (SRDF), поставляемую компанией ЕМС, для обеспечения возможности множеству физически разделенных центров обработки данных, в которых размещаются системы хранения ЕМС, поддерживать взаимное резервирование с избыточностью в глобальной сети.

Подобно архитектуре КДД 400, архитектура КОД 600 использует парадигму на основе WEB, использующую Усовершенствованные Услуги Имен Доменов (DNS), Объектную Модель Компонентов компании Microsoft (DCOM) и Интерфейсы Прикладных Программ (APIs) Windows NT для обеспечения информационного обмена и выравнивания нагрузки между серверами, образующими сервер 602 КОД, как описано выше в связи с обсуждением архитектуры КДД 400.

Рабочая станция 604 осуществляет управление работой и контроль системы, а также управление сетью КОД 600. В предпочтительном варианте осуществления рабочая станция 604, поставляемая компанией Compag, представляет собой рабочую станцию на платформе Intel, использующую программное обеспечение Microsoft Windows NT 4.x. Рабочая станция 604 должна обеспечивать возможность исполнения Microsoft Windows NT 5.x, когда это программное обеспечение будет поставлено. Рабочая станция 604 использует программное обеспечение СА Unicenter TNG для реализации контроля и управления сетевой системой. Рабочая станция 604 использует программное обеспечение SnoBound Imaging для отображения и обработки ТШСРИ.

Рабочая станция 604 также выполняет проверку идентификации путем сравнения сигнатурных данных, полученных дистанционно ТДД 200, с сигнатурными данными, хранящимися в КОД 600. В предпочтительном варианте осуществления программное обеспечение проверки сигнатурных данных, поставляемое компанией Communications Intelligence Corporation (Редвуд, шт.Калифорния), исполняемое на рабочей станции 604, осуществляет проверку идентификации. Специалистам в данной области техники должно быть понятно, что рабочая станция 604 может исполнять другое программное обеспечение для осуществления проверки идентификации путем сравнения биометрических данных, включая сканирования лица, отпечатки пальцев, сканирования сетчатки, сканирования радужной оболочки и геометрию ладони. Таким образом, КОД 600 может проверить идентификационные данные лица, которое осуществляет покупки по кредитной карточке, путем сравнения биометрических данных, полученных дистанционно, с биометрическими данными, хранящимися в КОД 600.

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

Шлюз 614 дистанционного ввода данных и Аппаратура 616 дистанционного ввода внешних данных корректируют ошибки, возникающие при вводе данных посредством ТДД 200. Поскольку система DataTreasury™ 100 подразделяет документ, как описано со ссылками на фиг.3b, оператору Шлюза 614 дистанционного ввода данных или Аппаратуры 616 дистанционного ввода внешних данных нужно только корректировать фрагменты документа или фрагменты изображения, которые содержат ошибки.

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

Аналогичным образом, подразделение документа на фрагменты уменьшает трафик в локальной сети 606 КОД и в сети 412 каналов Telco, так как сервер 602 КОД только передает фрагменты изображения, содержащие ошибку, к Аппаратуре 616 дистанционного ввода внешних данных, или к Шлюзу 614 дистанционного ввода данных. Соответственно подразделение на фрагменты снижает стоимость системы за счет снижения требований к полосе для сетей межсоединений.

Локальная сеть 606 КОД обеспечивает связь между устройствами, соединенными с локальной сетью 606, включая сервер 602 КОД и сетевую рабочую станцию 604. В предпочтительном варианте осуществления локальная сеть 606 КОД использует протокол уровня аппаратных средств коммутируемой связи 100BaseT/10BaseT, подобно локальной сети 406 КДД, как описано выше. В предпочтительном варианте осуществления локальная сеть 406 КДД представляет собой опорную сеть с топологией высокоскоростной сети ОС2, поддерживающей протокол TCP/IP. Сетевой коммутатор CISCO Catalyst 5500 поддерживает соединения в локальной сети 606 КОД между устройствами, соединенными с локальной сетью 606.

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

Маршрутизатор 612 глобальной сети соединяет локальную сеть 605 КОД с глобальной сетью для обеспечения связи между КДД 400 и КОД 600. В предпочтительном варианте осуществления маршрутизатор 612 глобальной сети представляет собой маршрутизатор CISCO 7507 глобальной сети. Маршрутизатор 612 глобальной сети использует соединения на основе ретрансляции кадров для соединения локальной сети 612 КОД с глобальной сетью. Специалистам в данной области техники должно быть ясно, что для обеспечения связи между КДД 400 и КОД 600 могут использоваться и другие устройства, такие как телекоммуникационный коммутатор модели NORTEL Magellen Passport "50", если выбранный маршрутизатор удовлетворяет требованиям эффективности и качества связи системы.

КОД 600 имеет трехуровневую архитектуру памяти, для поддержки требования к массовой памяти в системе DataTreasury™ 100. В предпочтительном варианте осуществления архитектура памяти включает в себя Системы памяти компании ЕМС Symmetrix Enterprise, базирующиеся на технологии RAID (массива недорогих дисков) с волоконными каналами, при которой отдельные системные блоки поддерживают память объемом 1 терабайт. После того как ТШСРИ обработаны и находятся в рабочем режиме в течение 30 суток, они будут перемещаться в системы накопителей с автоматической сменой дисков, основанные на использовании цифровых видеодисков. После того как ТШСРИ находятся в рабочем режиме в течение 90 суток, они будут перемещаться в системы 608 накопителей с автоматической сменой дисков для однократной записи с многократного считывания в целях долговременного хранения в течение срока до 3 лет в соответствии с потребностями клиента.

В альтернативном варианте КОД 600 предназначается для конфигурирования постоянной памяти с высокой плотностью записи, которая будет поставляться компанией NORSAM Technologies (Лос-Аламос, шт.Нью-Мехико), в системы 610 накопителей с автоматической сменой дисков на основе оптической памяти, подобной поставляемой компанией Hewlett Packard, для замены компонентов на цифровых видеодисках для увеличения объема памяти. ПЗУ с высокой плотностью записи согласуется с металлическим диском для однократной записи и многократного считывания с коэффициентом формы ПЗУ на компакт-дисках (КД). ПЗУ с высокой плотностью записи имеет очень большой объем, свыше 320 ГБ на одном жестком диске, и ожидается, что этот объем будет увеличен до нескольких терабайтов (ТБ) на одном жестком диске. КОД 600 использует технологию компаний IВМ и Philips для считывания с ПЗУ с высокой плотностью записи и для записи на такое ПЗУ. Серверы Alpha сервера 602 КОД вводят изображения и данные, принятые от КДД 400 в единую базу данных, которая сохраняется в Рабочих Системах Цифровой Памяти с использованием языка манипулирования данными, как известно специалистам в данной области техники. В предпочтительном варианте осуществления база данных представляет собой реляционную базу данных V8. Oracle, которая спроектирована для поддержки хранения данных и изображений в едином хранилище данных.

Специалистам в данной области техники должно быть ясно, что реляционная база данных состоит из набора таблиц, которые имеют единое имя (см., например, Korth, Silberschatz. Database System Concepts, Chapter 3). Схема базы данных представляет собой логическую структуру базы данных. Каждая таблица в реляционной базе данных имеет атрибуты. Строка в таблице представляет соотношение между набором значений для атрибутов в таблице. Каждая таблица имеет один или несколько сверхключей. Сверхключ представляет собой множество из одного или нескольких атрибутов, которые однозначно идентифицируют строку в таблице. Ключ-кандидат представляет собой суперключ, для которого нет надлежащего подмножества, являясь также суперключом. Главный ключ представляет собой ключ-кандидат, выбранный разработчиком базы данных в качестве средства для идентификации строки в таблице.

Специалистам в данной области техники должно быть ясно, что система DataTreasury™ 100 может использовать и другие модели базы данных, поставляемые другими поставщиками, включая базы данных модели “объект-отношение”, если выбранная база данных удовлетворяет требованиям эффективности хранения и доступа системы (см., например, Korth, Silberschatz. Database System Concepts, Chapter 2).

Базовая схема КОД 600, приведенная для примера, состоит из таблиц, приведенных ниже. Поскольку имена атрибутов являются описательными, они адекватно определяют содержание атрибутов. Главные ключи в каждой таблице идентифицированы двумя звездочками (**). Числовые атрибуты, уникальные для конкретного значения главного ключа, обозначены как “НО”. Числовые атрибуты, которые уникальны в пределах всей реляционной базы данных, обозначены как “НОМ”.

I. КЛИЕНТ. Данная таблица описывает клиента системы DataTreasury™.

А. ** ИД_КЛИЕНТА

В. НАИМЕНОВАНИЕ_КОМПАНИИ

С. КОНТАКТ

D. ВЫВОД_КОНТАКТА

Е. АДР 1

F. АДР 2

G. ГОРОД

Н. КОД_ГОРОДА

I. КОД_ИНДЕКСА

J. КОД_СТРАНЫ

К. ТЕЛЕФОН_РЕЧЕВОЙ_СВЯЗИ

L. ТЕЛЕФОН_ФАКСИМИЛЬНОЙ_СВЯЗИ

М. ДАТА_СОЗДАНИЯ

II. ПОЧТОВЫЙ_АДРЕС_КЛИЕНТА. Эта таблица описывает почтовый адрес клиента системы DataTreasury™.

А. ** ПОЧТА_НА_НО

В. ** ИД_КЛИЕНТА

С. ИМЯ_КЛИЕНТА

D. КОНТАКТ

Е. ВЫВОД_КОНТАКТА

F. АДР 1

G. АДР 2

Н. ГОРОД

I. КОД_ГОРОДА

J. КОД_ИНДЕКСА

К. КОД_СТРАНЫ

L. ТЕЛЕФОН_РЕЧЕВОЙ_СВЯЗИ

М. ТЕЛЕФОН_ФАКСИМИЛЬНОЙ_СВЯЗИ

N. ДАТА_СОЗДАНИЯ

O. КОММЕНТАРИИ

III. МЕСТОПОЛОЖЕНИЕ_ТДД_КЛИЕНТА. Эта таблица описывает местоположение ТДД клиента системы DataTreasury™.

А. ** НО_МЕСТОПОЛОЖЕНИЯ_ТДД

В. ** ИД_КЛИЕНТА

С. ИМЯ_КЛИЕНТА

D. КОНТАКТ

E. BЫBOД_KOHTAKTA

F. АДР 1

G. АДР 2

H. ГОРОД

I. КОД_ГОРОДА

J. КОД_ИНДЕКСА

K. КОД_СТРАНЫ

L. ТЕЛЕФОН_РЕЧЕВОЙ_СВЯЗИ

M. ТЕЛЕФОН_ФАКСИМИЛЬНОЙ_СВЯЗИ

N. ДАТА_СОЗДАНИЯ

О. КОММЕНТАРИИ

IV. МЕСТОПОЛОЖЕНИЕ_КДД_КЛИЕНТА. Эта таблица описывает местоположение КДД, клиента системы DataTreasury™.

А ** ИД_ТЕРМИНАЛА_ТДД

В. ** НО_МЕСТОПОЛОЖЕНИЯ_ТДД

С. ** ИД_КЛИЕНТА

В. ДАТА_ИНСТАЛЛЯЦИИ

Е. ДАТА_ПОСЛЕДНЕГО_ОБСЛУЖИВАНИЯ

F. ДАТА_СОЗДАНИЯ

G. КОММЕНТАРИИ

V. СПЕЦИФИКАЦИИ_ДАННЫХ. Эта таблица представляет спецификации данных для подразделения документов на фрагменты и выборки.

А. ** ИД_СПЕЦИФИКАЦИИ_ДОКУМЕНТОВ

В. ** ИД_КЛИЕНТА

С. ОПИСАНИЕ

D. ПРАВИЛА_ОФОРМЛЕНИЯ_ЗАПИСИ

Е. ДАТА_СОЗДАНИЯ

F. КОММЕНТАРИИ

VI. ПОЛЕ_СПЕЦИФИКАЦИИ_ДОКУМЕНТА. Эта таблица представляет спецификации данных полей для подразделения документов на фрагменты и выборки.

А. ** НО_СПЕЦИФИКАЦИИ_ДОКУМЕНТА

В. ** ИД_СПЕЦИФИКАЦИИ_ДОКУМЕНТА

С. ИМЯ_ПОЛЯ

D. ОПИСАНИЕ

E. TИП_ДAHHЫX

F. МАКСИМАЛЬНОЕ_ЗНАЧЕНИЕ

G. МИНИМАЛЬНОЕ_ЗНАЧЕНИЕ

Н. НАЧАЛЬНАЯ_ПОЗИЦИЯ

I. КОНЕЧНАЯ_ПОЗИЦИЯ

J. ДЛИНА_ПОЛЯ

К. ПРАВИЛА

L. ДАТА_СОЗДАНИЯ

М. КОММЕНТАРИИ

VII. ДОКУМЕНТ_ШАБЛОНА. Эта таблица определяет разбиение предварительно определенного документа.

А. ** НОМ_ДОКУМЕНТА_ШАБЛОНА

В. ИД_СПЕЦИФИКАЦИИ_ДАННЫХ

С. ОПИСНИЕ

D. ПРАВИЛА

Е. ДАТА_СОЗДАНИЯ

F. КОММЕНТАРИИ

VIII. ФОРМА_ШАБЛОНА. Эта таблица определяет местоположение форм на предварительно определенном документе.

А. ** НО_ФОРМЫ_ШАБЛОНА

В. ** НОМ_ДОКУМЕНТА_ШАБЛОНА

С. СТОРОНЫ_ФОРМЫ

D. СТОРОНА_А_ЭТАЛОННОГО_ИЗОБРАЖЕНИЯ

Е. СТОРОНА_В_ЭТАЛОННОГО_ИЗОБРАЖЕНИЯ

F. ПОВОРОТ_А_ОТОБРАЖЕНИЯ

G. ПОВОРОТ_В_ОТОБРАЖЕНИЯ

Н. ОПИСАНИЕ

I. ПРАВИЛА

J. ДАТА_СОЗДАНИЯ

IX. ПАНЕЛЬ_ШАБЛОНОВ. Эта таблица определяет местоположение панелей в пределах форм предварительно определенного документа.

А. ** НО_ПАНЕЛИ_ШАБЛОНА

В. ** НО_СТОРОНЫ_ШАБЛОНА

С. ** НО_ФОРМЫ_ШАБЛОНА

D. ** НОМ_ДОКУМЕНТА_ШАБЛОНА

Е. ПОВОРОТ_ИЗОБРАЖЕНИЯ

F. UL_Х_ПАНЕЛИ

G. UL_Y_ПАНЕЛИ

Н. LR_Х_ПАНЕЛИ

I. LR_Y_ПАНЕЛИ

J. ОПИСАНИЕ

К. ПРАВИЛА

L. ДАТА_СОЗДАНИЯ

X. ПОЛЕ_ШАБЛОНА. Эта таблица определяет местоположение полей в панелях формы предварительно определенного документа.

А. ** НО_ПОЛЯ_ШАБЛОНА

В. ** НО_ПАНЕЛИ_ШАБЛОНА

С. ** НО_СТОРОНЫ_ШАБЛОНА

D. ** НО_ФОРМЫ_ШАБЛОНА

Е. ** НОМ_ДОКУМЕНТА_ШАБЛОНА

F. ПОВОРОТ_ИЗОБРАЖЕНИЯ

G. UL_Х_ПОЛЯ

Н. UL_Y_ПОЛЯ

I. LR_Х_ПОЛЯ

J. LR_Y_ПОЛЯ

К. ОПИСАНИЕ

L. ПРАВИЛА

М. ДАТА_СОЗДАНИЯ

XI. ПАКЕТ_ТДД. Эта таблица определяет пакеты документов, которые были обработаны в процессе сеанса ТДД.

А. ** НО_ПАКЕТА_ТДД

В. ** НО_СЕАНСА_ТДД

С. ** ДАТА_СЕАНСА_ТДД

D. ** ИД_ТЕРМИНАЛА_ТДД

E. СNТ_БЛОКА_ТДД

F. ДАТА_СОЗДАНИЯ

XII. БЛОК_ТДД. Данная таблица определяет блок в пакете документов, которые были обработаны в сеансе ТДД.

А. ** НОМ_БЛОКА_ТДД

В. ** НО_ПАКЕТА_ТДД

С. ** НО_СЕАНСА_ТДД

D. ** ДАТА_СЕАНСА_ТДД

Е. ** ИД_ТЕРМИНАЛА_ТДД

F. CNT_ФOPMЫ

G. CNT_ДОКУМЕHTA

H. ДАТА_СОЗДАНИЯ

XIII. ДОКУМЕНТЫ_ТДД. Эта таблица определяет документы в блоке документов, которые были обработаны в сеансе ТДД.

А. ** НО_ДОКУМЕНТА_ТДД

В. ** НОМ_БЛОКА_ТДД

С. ДАТА_ЗАПИСИ_ДОКУМЕНТА

D. ДАТА_СОЗДАНИЯ

Таблицы СПЕЦИФИКАЦИИ_ДАННЫХ, ПОЛЕ_СПЕЦИФИКАЦИИ_ДАННЫХ, ДОКУМЕНТ_ШАБЛОНА, ФОРМА_ШАБЛОНА, ПАНЕЛЬ_ШАБЛОНА и ПОЛЕ_ШАБЛОНА реализуют алгоритм разбиения документа на фрагменты, как было описано выше со ссылками на фиг.3b. Перекрестное произведение таблиц СПЕЦИФИКАЦИЯ_ДАННЫХ и ПОЛЕ_СПЕЦИФИКАЦИИ_ДАННЫХ подразделяет произвольные" документы, в то время как перекрестное произведение таблиц ДОКУМЕНТ_ШАБЛОНА, ФОРМА_ШАБЛОНА, ПАНЕЛЬ_ШАБЛОНА и ПОЛЕ_ШАБЛОНА подразделяет предварительно определенные документы системы DataTreasury™ 100. ФОРМА_ШАБЛОНА определяет местоположение форм на предварительно определенном документе. ПАНЕЛЬ_ШАБЛОНА определяет местоположение панелей в пределах форм предварительно определенного документа. Наконец, таблица ПОЛЕ_ШАБЛОНА определяет местоположение полей в пределах панелей формы предварительно определенного документа.

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

На фиг.7 представлена блок-схема 700, описывающая опрос КДД 300 с помощью КОД 600 и передачу ТШСРИ от КДД 300 к КОД 600. На этапе 702 КОД 600 считывает адрес первого КДД 300 в его регионе для опроса. На этапе 704 КОД 600 устанавливает соединение с КДД 300 для передачи. КОД 600 определяет на этапе 706, успешно ли установлено соединение с КДД 300. Если вызов КДД 300 безуспешен, то КОД 600 регистрирует состояние ошибки в итоговом отчете о сеансе и на этапе 722 направляет сообщение об ошибке к администратору КОД 600.

Если соединение с КДД 300 успешно установлено, то КОД на этапе 708 будет проверять, готов ли КДД 300 к передаче. Если КДД 300 не готов к передаче, то КОД 600 регистрирует состояние ошибки в итоговом отчете о сеансе и на этапе 722 направляет сообщение об ошибке к администратору КОД 600.

Если КДД 300 готов к передаче, то КДД 300 на этапе 710 будет передавать заголовок пакета ТШСРИ к КОД 600. КОД на этапе 712 будет проверять, успешна ли передача заголовка пакета ТШСРИ. Если на этапе 712 установлено, что передача заголовка пакета ТШСРИ безуспешна, то КОД 600 регистрирует состояние ошибки в итоговом отчете о сеансе и на этапе 722 направляет сообщение об ошибке к администратору КОД 600.

Если на этапе 712 установлено, что передача заголовка пакета ТШСРИ успешна, то КДД 300 на этапе 714 будет передавать пакет ТШСРИ к КОД 600. КОД 600 на этапе 716 будет проверять, успешна ли передача пакета ТШСРИ. Если на этапе 716 установлено, что передача пакета ТШСРИ безуспешна, то КОД 600 регистрирует состояние ошибки в итоговом отчете о сеансе и на этапе 722 направляет сообщение об ошибке к администратору КОД 600.

Если на этапе 716 установлено, что передача пакета ТШСРИ успешна, то КОД 600 на этапе 718 будет сравнивать заголовок пакета ТШСРИ, переданный на этапе 710, с пакетом ТШСРИ, переданным на этапе 714. Если заголовок патента ТШСРИ не согласуется с пакетом ТШСРИ, то КОД 600 регистрирует состояние ошибки в итоговом отчете о сеансе и на этапе 722 направляет сообщение об ошибке к администратору КОД 600.

Если на этапе 718 установлено, что заголовок пакета ТШСРИ согласуется с пакетом ТШСРИ, то КОД 600 на этапе 720 будет устанавливать статус пакета ТШСРИ, чтобы указать, что он был принят в КОД. КОД 600 будет также на этапе 720 передавать статус в КДД 300 для указания успешного завершения опроса и сеанса передачи. Затем КОД 600 на этапе 724 будет определять, переданы ли ТШСРИ от всех КДД 300 в его регионе. Если все КДД 300 к регионе КДД 600 передали ТШСРИ к КДД 600, то КОД 600 на этапе 728 будет составлять отчет о статусе КДД 300 перед завершением сеанса.

Если один или несколько КДД 300 в регионе КОД 600 не передали ТШСРИ в КОД 600, то КОД 600 на этапе 726 получит адрес следующего КДД 300 в его регионе. Затем процедура обработки возвращается к этапу 704, на котором следующий КДД 300 в регионе КОД 600 будет опрашиваться, как описано выше.

На фиг.8 представлена блок-схема 800, описывающая обработку данных, выполняемую в КОД 600. На этапе 802 КОД 600 извлекает первый пакет ТШСРИ. Затем КОД 600 на этапе 804 выделяет первое ТШСРИ из пакета ТШСРИ. На этапе 806 КОД 600 вводит ТШСРИ в базу данных. На этапе 808 КОД 600 выделяет из ТШСРИ заголовок метки, который включает идентификатор клиента, ключи шифрования и идентификатор шаблона, для получения ШСРИ.

На этапе 810 КОД 600 дешифрует ШСРИ для получения СРИ. На этапе 812 КОД 600 осуществляет декомпрессию СРИ для получения РИ. На этапе 814 КОД 600 выбирает и применяет шаблон РИ к РИ. Затем КОД 600 на этапе 814 делит РИ на фрагменты изображения и помечает шаблон РИ правилами захвата данных для формирования тегированных фрагментов растрового изображения (ТФРИ). На этапе 816 КОД 600 передает ТФРИ на выполнение операций захвата данных для формирования записи данных, полученных из фрагментов изображения (ФИ-данных). КОД 600 отбрасывает ТФРИ после завершения операций захвата данных на этапе 816. На этапе 818 КОД 600 обновляет данные записи ТШСРИ в базе данных с помощью ФИ-данных.

На этапе 820 КОД 600 определяет, обработано ли последнее ТШСРИ в пакете ТШСРИ. Если последнее ТШСРИ в пакете ТШСРИ не обработано, то КОД 600 на этапе 822 выделяет следующее ТШСРИ из пакета ТШСРИ. Затем процедура обработки возвращается к этапу 806, где следующее ТШСРИ будет обрабатываться так, как описано выше.

Если последнее ТШСРИ в пакете ТШСРИ обработано, то КОД 600 на этапе 824 определяет, обработан ли последний пакет ТШСРИ. Если последний пакет ТШСРИ не обработан, то КОД 600 осуществляет выборку следующего пакета ТШСРИ на этапе 826. Затем процедура обработки возвращается к этапу 804, где следующий пакет ТШСРИ будет обрабатываться, как описано выше. Если на этапе 824 определено, что обработан последний пакет ТШСРИ, то КОД 600 завершает обработку данных.

Специалисту в данной области техники должно быть ясно, что пользователь может запросить информацию из реляционной базы данных с использованием языка запросов (см., например, Korth, Silberschatz. Database System Concepts, Chapter 3). Например, пользователь может сделать выборку всех строк таблицы базы данных, имеющей главный ключ с конкретными значениями, путем определения желательных значений главного ключа и имени таблицы для выбранной операции. Аналогичным образом, пользователь может сделать выборку всех строк из множества таблиц базы данных, имеющих главные ключи с конкретными значениями, путем определения желательных значений главных ключей и таблиц с выбранной операцией.

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

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

На фиг.9 представлена блок-схема 900, описывающая выборку данных, выполняемую КОД 600. На этапе 902 КОД 600 принимает запрос на выборку данных. На этапе 904 КОД 600 получает идентификатор клиента. На этапе 906 КОД 600 определяет, действителен ли идентификатор клиента. Если идентификатор клиента не действителен, то процедура обработки возвращается к этапу 904, где КОД 600 будет получать идентификатор другого клиента.

Ели на этапе 906 определено, что идентификатор клиента действителен, то КОД 600 на этапе 908 будет получать профиль защищенности клиента. На этапе 910 КОД 600 получает запрос на выборку данных. На этапе 912 КОД 600 определяет, согласуется ли запрос на выборку данных клиента с профилем защищенности клиента. Если запрос на выборку данных клиента не согласуется с профилем защищенности клиента, то процедура обработки возвращается к этапу 910, где КОД 600 будет получать запрос на выборку данных другого клиента. Если запрос на выборку данных клиента согласуется с профилем защищенности клиента, то КОД 600 на этапе 914 будет передавать результаты к клиенту, как указано профилем защищенности клиента.

На фиг.10 представлена блок-схема, иллюстрирующая использование системы DataTreasury™ для обработки чеков. На этапе 1004 система DataTreasury^ТМ осуществляет ввод чека в удаленном пункте плательщика, в предпочтительном варианте осуществления перед тем, как плательщик представляет чек получателю платежа. Как вариант, плательщик просто представляет или посылает по почте чек получателю платежа. Ввод данных чека в удаленном пункте плательщика на этапе 1004 обеспечивает возможность последующего сравнения чека, как написано плательщиком, с чеком, как принято получателем платежа. Иными словами, этот этап позволяет определить факт изменения чека путем противоправных действий, когда чек перехватывается, прежде чем он принят получателем платежа, и подвергается химической обработке для получения возможности нарушителю работать с незаполненным чеком.

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

На этапе 1010 система DataTreasury™ определяет, успешна ли проверка. Если на этапе 1010 определено, что проверка безуспешна, то система передает на этапе 1012 сообщение об ошибке в удаленные пункты и возвращается к этапу 1004 для повторного ввода. Если на этапе 1010 определено, что проверка успешна, то система на этапе 1014 создает электронную транзакцию, представляющую чек в центральном пункте. Электронная транзакция, представляющая чек, состоит из идентификационного номера банка плательщика, информации маршрутизации, номера счета плательщика, чека плательщика, переводного векселя банка плательщика, суммы чека или переводного векселя, идентификационного номера банка получателя платежа, информации маршрутизации банка получателя платежа, номера счета получателя платежа. На этапе 1016 электронная транзакция, представляющая чек, передается в банк получателя платежа. На этапе 1018 банк получателя платежа передает электронную транзакцию, представляющую чек, банку плательщика.

На этапе 1020 банк плательщика проверяет электронную транзакцию, представляющую чек, и определяет, разрешить ли перевод фондов. Если банк получателя платежа выдает разрешение на этапе 1020, то банк плательщика переводит фонды из банка плательщика в банк получателя платежа на этапе 1022. На этапе 1024 система DataTreasury™ уведомляет банк получателя платежа и удаленные пункты о статусе перевода фондов.

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

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

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

Приоритет по пунктам: