УСТРОЙСТВО И СПОСОБ ПРЕДСТАВЛЕНИЯ СЧЕТА И ЕГО ОПЛАТЫ

Ссылка на связанные заявки

Датами приоритета для данной заявки являются 12.02.2010 (дата подачи предварительной патентной заявки США №61/303,725) и 31.01.2011 (дата подачи предварительной патентной заявки США №61/438,106). Содержание указанных патентных заявок США (включая содержание всех четырех приложений к заявке №61/303,725) включено в данное описание посредством ссылки в полном объеме и для всех случаев, разрешенных законом. При этом релевантные части заявки 61/438,106 воспроизведены в приводимом далее описании.

Область техники

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

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

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

Раскрытие изобретения

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

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

В другом аспекте изобретения другой вариант способа включает следующие операции:

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

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

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

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

Еще в одном аспекте другой вариант способа включает следующие операции:

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

получение оператором процессинговой сети от одной из указанных биллинговых организаций одного из счетов с указанием ассоциированного с ним единственного номера аккаунта биллера и

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

В следующем аспекте еще один вариант способа включает следующие операции:

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

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

При этом способ дополнительно включает:

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

хранение данных, подтверждающих способность посылать счета в электронной форме;

получение от множества сервис-провайдеров потребителей подтверждения способности получать счета в электронной форме;

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

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

хранение в таблице отношений, на основе исторических данных, идентификаторов биллинговых организаций, номеров аккаунтов биллинговых организаций и идентификаторов сервис-провайдеров потребителей,

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

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

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

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

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

Один или более вариантов изобретения способны обеспечить существенные полезные технические результаты. В частности:

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

- функциональность "одним кликом" экономит время и компьютерные ресурсы;

- автоматическое подключение через отслеживание транзакций экономит время и компьютерные ресурсы;

- счет с единственным номером аккаунта биллера (или аналогичным идентификатором) может быть направлен нескольким инициаторам.

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

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

На фиг.1 представлен пример платежной системы;

На фиг.2 иллюстрируется пример взаимосвязей между: (i) платежной сетью, сконфигурированной, чтобы облегчить транзакции между эмитентами и эквайерами, (ii) множеством пользователей, (iii) множеством продавцов (провайдеров), (iv) множеством эквайеров и (v) множеством эмитентов.

На фиг.3 иллюстрируется работа известной системы оплаты счетов.

На фиг.4 иллюстрируется проведение платежей известной автоматизированной клиринговой палатой.

На фиг.5 представлена блок-схема варианта системы.

На фиг.6 и 7 иллюстрируется пример движения данных в системе.

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

На фиг.9 иллюстрируется пример технологии подключения.

На фиг.10 иллюстрируется пример платежа "в один клик".

На фиг.11 представлен вариант интерфейсов системы согласно предварительной патентной заявке США №61/438, 106.

На фиг.12 иллюстрируется пример разработчика потоков работ согласно предварительной патентной заявке США №61/438, 106.

На фиг.13 представлена блок-схема варианта системы, предложенная в предварительной патентной заявке США №61/438, 106.

На фиг.14 иллюстрируется пример потока деталей транзакций согласно предварительной патентной заявке США №61/438, 106.

На фиг.15 иллюстрируется пример потока исходящих данных согласно предварительной патентной заявке США №61/438, 106.

На фиг.16 иллюстрируется пример потока сообщений для процессинга исходящих файлов согласно предварительной патентной заявке США №61/438, 106.

На фиг.17А представлена блок-схема данных из входящих файлов согласно предварительной патентной заявке США №61/438, 106.

На фиг.17В представлен, в табличной форме, пример данных из входящих файлов согласно предварительной патентной заявке США №61/438, 106.

На фиг.18 иллюстрируется пример процесса формирования очереди подтверждений согласно предварительной патентной заявке США №61/438, 106.

На фиг.19 иллюстрируется пример процесса формирования очереди переводов согласно предварительной патентной заявке США №61/438, 106.

На фиг.20А иллюстрируется пример процесса генерирования ежедневного плана согласно предварительной патентной заявке США №61/438, 106.

На фиг.20В иллюстрируется пример данных из указанного плана согласно предварительной патентной заявке США №61/438, 106.

На фиг.21 иллюстрируется пример процесса демона-планировщика согласно предварительной патентной заявке США №61/438, 106.

На фиг.22 представлена блок-схема для инициирования списка заданий при наличии событий, выполняемых в окне, согласно предварительной патентной заявке США №61/438, 106.

На фиг.23 иллюстрируется пример процесса построения исходящих файлов согласно предварительной патентной заявке США №61/438,106.

На фиг.24 иллюстрируется пример связи между входящими и исходящими данными согласно предварительной патентной заявке США №61/438, 106.

На фиг.25 иллюстрируется пример потока исходящих данных при оплате счетов согласно предварительной патентной заявке США №61/438, 106.

На фиг.26 приведены примеры записей статуса SIF/SINF и деталей записи SIF согласно предварительной патентной заявке США №61/438, 106.

На фиг.27 иллюстрируется пример процесса конца дня согласно предварительной патентной заявке США №61/438, 106.

На фиг.28 иллюстрируется пример процесс преобразования портфеля согласно предварительной патентной заявке США №61/438, 106.

На фиг.29 иллюстрируется пример стоп-файла для потока согласно предварительной патентной заявке США №61/438, 106.

На фиг.30 иллюстрируется пример процесса стартапа и инициализации согласно предварительной патентной заявке США №61/438, 106.

На фиг.31 иллюстрируется пример служебного класса согласно предварительной патентной заявке США №61/438, 106.

На фиг.32 иллюстрируется пример бизнес-слоя согласно предварительной патентной заявке США №61/438, 106.

Осуществление изобретения

Технологии согласно изобретению могут использоваться в различных системах и в различных средах. В одном или более вариантах эти технологии могут применяться в рамках электронной платежной системы MASTERCARD RPPS® фирмы MasterCard International Incorporated (США). Однако такой вариант использования не является ограничивающим: так, в других случаях могут использоваться иные системы электронной оплаты счетов, например, описанные в предварительной заявке США №61/438, 106.

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

Более конкретно, на фиг.1, на которой представлен, в качестве примера, вариант системы 100, показаны ее различные возможные компоненты. Система 100 может содержать одно или более портативных платежных устройств различных типов. Например, одним из таких устройств может быть контактное устройство, такое как карта 102. Эта карта может содержать чип интегральной схемы (ИС) 104, имеющей процессорную секцию 106 и секцию 108 памяти. Для целей коммуникации могут быть предусмотрены электрические контакты 110. В дополнение к картам 102 или в качестве альтернативы система 100 может быть также рассчитана на работу с бесконтактными устройствами, такими как карты 112. Карты 112 могут содержать чип 114 ИС, имеющей процессорную секцию 116 и секцию 118 памяти. Для осуществления бесконтактной коммуникации может иметься антенна 120, работающая, например, в радиочастотном диапазоне электромагнитных волн. Могут иметься также осциллятор или осцилляторы и/или соответствующие дополнительные схемы для осуществления модуляции, демодуляции и/или понижения частоты и аналогичных функций. Следует отметить, что карты 102, 112 - это только примеры различных устройств, которые могут использоваться при осуществлении изобретения. Другие типы устройств могут включать обычные карты 150 с магнитной полосой 152 или определенным образом сконфигурированные мобильные телефоны. Таким образом, изобретение может быть адаптировано к широкому ассортименту карт, терминалов и других устройств, например, сконфигурированных в соответствии со стандартом (или спецификацией) на платежную систему.

ИС 104, 114 могут содержать процессорные секции 106, 116 и секции 108, 118 памяти. Желательно, чтобы ИС 104, 114 могли содержать также одну или более управляющих логических схем, таймер и порты ввода-вывода. Такие элементы хорошо известны в технологии ИС и поэтому не проиллюстрированы. Одна или более ИС 104, 114 может (могут) содержать также сопроцессор, который тоже хорошо известен и поэтому не изображен. Управляющая логическая схема, в сочетании с процессорными секциями 106, 116, может обеспечить управление, необходимое для осуществления коммуникации между секциями 108, 118 памяти и портами ввода-вывода. Таймер может обеспечить подачу хронирующего сигнала процессорными секциями 106, 116 и управляющей логической схемой. Сопроцессор может обеспечить возможность выполнения сложных расчетов в реальном времени, таких, которые требуются для криптографических алгоритмов.

Секции (блоки) 108, 118 памяти могут использовать память различных типов, например энергозависимую память, энергонезависимую память, программируемую память и постоянные запоминающие устройства. Секции памяти могут хранить данные о транзакциях по карте, например номер основного счета (primary account number, "PAN") пользователя и/или персональный идентификационный номер (personal identification number, "PIN"). Секции (блоки) 108, 118 памяти могут хранить операционную систему карт 102, 112. Операционная система загружает и выполняет приложения и обеспечивает функции файлового менеджера или другие базовые функции карты в отношении приложений. Одной операционной системой, которую можно использовать для реализации изобретения, является система MULTOS®, лицензируемая фирмой MAOSCO Limited (Великобритания). Альтернативно, можно использовать операционные системы, основанные на технологии JAVA CARD™ (лицензируемой фирмой Sun Microsystems, США), или операционные системы, правами на которые владеют их продавцы. Операционная система предпочтительно записывается в постоянную память ("ROM"), имеющуюся в составе секции 108, 118 памяти. В альтернативном варианте для этого в секциях 108, 118 памяти можно использовать флэш-память или другие типы энергонезависимой или энергозависимой памяти.

В дополнение к базовым сервисам, обеспечиваемым операционной системой, секции 108, 118 памяти могут дополнительно обеспечивать одно или более приложений. В настоящее время одной возможной спецификацией, которой могут соответствовать такие приложения, является спецификация (стандарт) универсальных платежей EMV, разработанная фирмой EMV Co, LLC (США). Должно быть понятно, что указанные приложения могут быть сконфигурированы во многих различных вариантах.

Некоторые варианты полностью соответствуют релевантным стандартам ИСО, в частности ИСО 8583. Индивидуальные организации или группы могут разрабатывать свои спецификации в рамках этого стандарта.

Как было отмечено, карты 102, 112 являются примерами множества платежных устройств, которые могут быть использованы в рамках изобретения. При этом основная функция платежных устройств может не являться платежной. Например, устройствами, реализующими изобретение, могут являться мобильные телефоны. Подобными устройствами могут являться также карты обычных размеров, карты меньших или больших размеров, карты различной формы, брелки для ключей, карманные компьютеры, соответственно сконфигурированные мобильные телефоны или любые другие устройства, способные реализовать настоящее изобретение. Карты или другие платежные устройства могут включать основную часть (например, ламинированные пластиковые слои в случае платежной карты, корпус карманного компьютера, корпус чипа и т.д.), блоки 108, 118 памяти, прикрепленные к соответствующим основным частям, и процессоры 106, 116, также прикрепленные к основным частям и подключенные к блокам памяти. Блоки 108, 118 памяти могут содержать соответствующие приложения. Процессоры 106, 116 могут быть способны выполнять один или более шагов (операций) способа по изобретению. Приложения могут, например, представлять собой идентификаторы приложений, присоединенные к программному коду в виде программно-аппаратного обеспечения, плюс данные, записанные в памяти карты, например в ее электрически стираемой программируемой постоянной памяти (ЭСППЗУ). Следует еще раз отметить, что использование "смарт-карт" не является обязательным: пригодны и традиционные карты с магнитной полосой, причем в некоторых случаях может быть даже использован текущий карточный счет с соответствующим номером счета, но без физической карты.

В составе системы 100 могут использоваться терминалы многих различных типов. Таким терминалом может быть контактный терминал 122, сконфигурированный для взаимодействия с устройством 102 контактного типа, беспроводной терминал 124, сконфигурированный для взаимодействия с беспроводным устройством 112, "магнитный" терминал 125, сконфигурированный для взаимодействия с устройством 150 на основе магнитной полосы, или комбинированный терминал 126. Комбинированный терминал 126 рассчитан на взаимодействие с устройствами 102, 112, 150 любого типа. Некоторые терминалы могут быть контактными терминалами со съемными бесконтактными считывателями. Комбинированный терминал 126 может содержать память (memory, M) 128, процессор (processor, P) 130, модуль 132 считывателя (reader module, R. M) и, возможно, интерфейсный модуль, например сканер 134 штрих-кода (bar code scanner, В. С. S.) и/или считыватель 136 меток радиочастотной идентификации (radio frequency identification, RFID). Блоки и модули 128, 132, 134, 136 могут быть подключены к процессору 130. При этом принципы построения терминала 126, применимые и к терминалам других типов, детально описываются только в иллюстративных целях. Модуль 132 считывателя может быть сконфигурирован для контактной коммуникации с картой или с устройством 102, для бесконтактной коммуникации с картой или с устройством 112, для считывания магнитной полосы 152 или для реализации двух или более из названных вариантов коммуникации. Альтернативно, для взаимодействия с картами различных типов (например, с контактными, с магнитной полосой или бесконтактными) могут иметься считыватели различных типов. Терминалы 122, 124, 125, 126 могут быть связаны с одним или более процессинговыми центрами 140, 142, 144 через компьютерную сеть 138. Сетью 138 может быть, например, Интернет или какая-либо частная сеть (например, виртуальная частная сеть (virtual private network, VPN), такая как VPN BANKNET® фирмы MASTERCARD International Incorporated, США). Чтобы связать различные элементы системы, можно использовать более одной сети. Например, локальная сеть (local area network, LAN) может связывать терминалы с локальным сервером или с другим компьютером предприятия розничной торговли. Платежная сеть может включать эквайеров и эмитентов. Процессинговые центры 140, 142, 144 могут иметь, например, главный компьютер эмитента платежного устройства (или Процессинговые средства других организаций (представленные на других фигурах)).

К сети 138 может быть подключено много различных торговых или других предприятий, представленных на фиг.1 точками продаж (points-of-sale, P. О. S.) 146, 148. Каждая такая организация может использовать один или более терминалов. Кроме того, можно комбинировать различные типы портативных платежных устройств, терминалов или других элементов (компонентов) или комбинировать или объединять признаки устройств, приведенных в качестве примеров на фиг.1.

Портативные платежные устройства могут облегчить транзакции, осуществляемые пользователем через терминалы, такие как терминалы 122, 124, 125, 126 системы, такой как система 100. Подобное устройство может, например, содержать процессор, например процессорные секции 106, 116, рассмотренные выше. Оно может также содержать память, такую как секции 108, 118 памяти, рассмотренные выше, подключенную к процессору. Устройство может содержать также коммуникационный модуль, также связанный с процессором и сконфигурированный для взаимодействия с терминалом, таким как один из терминалов 122, 124, 125, 126. У коммуникационного модуля могут иметься, например, контакты 110 или антенны 120 в сочетании с соответствующим контуром (таким как осциллятор или осцилляторы с соответствующей схемой), что позволяет обеспечить его связь с терминалами посредством контактной или беспроводной коммуникации. Процессор устройства может обеспечивать выполнение одного или более шагов (операций) способов по изобретению. Процессор может выполнять эти операции при взаимодействии с аппаратными средствами и/или в соответствии с программными инструкциями, например, содержащимися в приложениях, записанных в одной из секций памяти.

У портативных устройств может иметься несущая (корпусная) часть, как это было описано выше, например, в виде ламинированных пластиковых слоев (применительно к смарт-картам 102, 112) или корпуса и панели (применительно к мобильному телефону).

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

Должно быть понятно, что терминалы 122, 124, 125, 126 - это только примеры терминальных устройств для взаимодействия с платежным устройством его держателя. Подобное терминальное устройство может содержать процессор, такой как процессор 130, память, такую как память 128, подключенную к процессору, и коммуникационный модуль, такой как модуль 132 считывателя, также подключенный к процессору и сконфигурированный для взаимодействия с портативными устройствами. Процессор 130 может обеспечивать возможности коммуникации с портативными платежными устройствами пользователей через коммуникационный модуль 132. Терминальные устройства могут функционировать с использованием аппаратных компонентов в процессоре 130 или в соответствии с инструкциями, записанными в памяти 128. Необходимая логическая поддержка может, в качестве альтернативы, обеспечиваться дистанционно из соответствующего центра, такого как процессинговый центр 140, по сети 138. В некоторых вариантах для считывания атрибутивных данных, таких как идентификация конкретного продукта, с универсального кода объекта (UPC) или с RFID-метки, имеющегося (имеющейся) на приобретаемом продукте, могут иметься сканер 134 штрих-кода и/или считыватель 136 RFID-метки, подключенные к процессору.

Описанные устройства 102, 112 предпочтительно являются контактными картами или устройствами, соответствующими стандарту ИСО 7816, или бесконтактными картами или устройствами, соответствующими стандарту ИСО 14443. При использовании карты 112 ею можно коснуться терминала 124 или 126 или постукать по нему. При этом произойдет бесконтактная передача электронных данных на чип короткодистанционной связи карты 112 или другого бесконтактного устройства. Карту с магнитной полосой можно просто провести известным образом мимо считывателя. Как упоминалось, в одном или более вариантах номер карты просто передается с помощью телефона, веб-сайта или аналогичного средства.

Для сохранения полезной информации один или более процессинговых центров 140, 142, 144 может содержать базу данных, например хранилище 154 данных. В контексте одного или более вариантов изобретения (например, проиллюстрированных на фиг.2-7) клиент может являться держателем устройства 102, 112 или 150, а организации, представленные на фиг.2-7, могут эксплуатировать процессинговые центры, такие как центры 140, 142, 144 (связанные, в случае необходимости, с хранилищем 154 данных). Как упоминалось, в качестве сети (сетей) 138 можно использовать Интернет и/или VPN, например уже упоминавшуюся сеть BANCNET®.

На фиг.2 показан вариант взаимосвязи различных лиц и организаций в контексте осуществления карточного платежа. В одном или более вариантах, проиллюстрированных на фиг.5-7, 9 и 10, оператор платежной сети может иметь сеть, способную облегчать транзакции типа проиллюстрированных на фиг.2. Множество различных пользователей 2002 (U₁, U₂…U_N) взаимодействует с множеством различных продавцов 2004 (P₁, P₂…P_M). Пользователями 2002 могут быть, например, владельцы (держатели) платежных карт. Продавцы 2004 взаимодействуют с различными эквайерами 2006 (A₁, A₂…A_I). Эквайеры 2006 взаимодействуют с различными эмитентами 2010 (I₁, I₂…I_J), например, через единственного оператора платежной сети (payment network, PN) 2008, сконфигурированной так, чтобы облегчить транзакции между множеством эмитентов и множеством эквайеров. Примерами являются MASTERCARD International Incorporated, оператор сети BANKNET®, или Visa International Сервис Association, оператор сети VISANET®. В общем случае N, М, I и J - это целые числа, которые могут быть равны или не равны одно другому.

В обычном варианте процесса авторизации кредита держатель 2002 карты оплачивает покупку, а продавец 2004 направляет данные о транзакции эквайеру (банку-эквайеру) 2006. Эквайер верифицирует номер карты, тип транзакции и сумму у эмитента 2010 и резервирует для продавца данную сумму с кредитного счета владельца карты в пределах лимита кредитования. К этому моменту произведен обмен запросом на авторизацию и ответом на этот запрос (как правило, в реальном времени). Авторизованные транзакции собираются в "пакеты", которые отсылаются эквайеру 2006. При проведении клиринга и взаиморасчетов эквайер посылает пакет транзакций через ассоциацию кредитных карт, которая дебетует эмитентов 2010 за платежи и кредитует эквайера 2006. После того как оплата эквайеру 2006 произведена, он производит оплату продавцу 2004.

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

На фиг.10 иллюстрируется функционирование известной системы электронной оплаты счетов, такой как упомянутая электронная платежная система MASTERCARD RPPS®, которая является неограничивающим примером подобных систем. Используя сведения, приводимые в данном описании, специалист будет в состоянии обеспечить осуществление одного или более вариантов изобретения, например, путем соответствующего модифицирования известной системы, представленной на фиг.10, на основе приводимых далее рекомендаций. Как показано на фиг.10, в известной системе 1000, на стадии предъявления к оплате биллер 1002 посылает биллинговую информацию (на шаге 1012) своему поставщику 1004 услуг по биллингу (сервис-провайдер биллера - СПБ), т.е. организации, служащей посредником между биллером и потребителем при обмене электронной информацией по оплате счетов. СПБ 1004, в свою очередь, посылает эту информацию в систему 1006 электронной оплаты счетов (шаг 1014). На шаге 1016 система 1006 доставляет биллинговую информацию поставщику 1008 клиентских услуг (сервис-провайдеру потребителя - СПП), т.е. агенту потребителя, который предоставляет интерфейс для предъявления счетов к оплате и оплаты счетов непосредственно клиентам, бизнесам или другим субъектам. СПП принимает новых потребителей и обеспечивает возможность предъявлений к оплате и платежей, а также предоставляет клиентам другие услуги. СПП 1008 выставляет счет потребителю (клиенту) 1010 на шаге 1018.

На стадии платежа клиент 1010 на шаге 1020 посылает СПП 1008 инструкции по оплате счета (счетов). СПП 1008 посылает (на шаге 1022) информацию по оплате счетов системе 1006, которая осуществляет (на шаге 1024) электронную отсылку денежных средств (фондов) и данных СПБ 1004. СПБ 1004 на шаге 1026 предоставляет платежную информацию биллеру 1002.

На фиг.4 иллюстрируется используемый в настоящее время процесс 1100 для осуществления электронных переводов денежных средств (electronic funds transfers, EFT) для оплаты счетов или иных целей. Инициирующее депозитарное финансовое учреждение (originating depository financial institution, ODFI) 1102 (именуемое также "инициатором") посылает инструкции (например, платежные данные и данные о переводе) через сеть, например через автоматизированную клиринговую палату (АСН) 1104, через системы Swift, EPN, CHIPS, Fedwire и др. (шаг 1108). На шаге 1110 АСН 1104 или аналогичная сеть передает эти инструкции получающему депозитарному финансовому учреждению, т.е. указанному получателю или абонированному почтовому ящику 1106. В некоторых вариантах может быть использован формат файла АСН, неограничивающим примером которого может служить формат NACHA АСН CCD. Могут быть применены и другие форматы; например с использованием языка XML. Следует отметить возможность использования многих сетей, в том числе сетей общего пользования (например, АСН) и частных сетей (например, вышеупомянутой системы MASTERCARD RPPS).

В настоящее время при осуществлении прямой передачи файла от одного субъекта другому в режиме GFT (Global File Transfer) используется преимущество прямого канала связи, но не обеспечивается поддержка протокола передачи файлов (FTP). Прямая передача возможна благодаря наличию связи с членом системы и с продавцом или третьей стороной. Как будет понятно специалисту, GFT - это система, доступная через фирму MASTERCARD International Incorporated, в которой файлы передаются через платежную сеть типа показанной на фиг.9, причем данная система является неограничивающим примером передачи файлов данных через платежную сеть. Протокол передачи файлов (FTP) - это стандартный сетевой протокол, применяемый для обмена и манипулирования файлами в сети, использующей данный протокол, например в Интернете. Передача файлов с применением FTP возможна в других вариантах изобретения. В рамках сети, использующей GFT, или в иной сети можно задать политику сохранения файлов и/или политику биллинга.

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

- с использованием виртуальной частной сети (VPN) типа показанной на фиг.9 (такой как сеть BANKNET®);

- с использованием Интернета, с применением соответствующего метода защиты данных, передаваемых через Интернет, например существующего метода MFE (MASTERCARD FILE EXPRESS) фирмы MASTERCARD International Incorporated или хорошо известного протокола безопасной передачи файлов (SFTP), или аналогичных методов. Как будет понятно специалисту, сказанное выше, по существу, применимо также к методам сквозного процессинга (Straight-Through-Processing, STP), которые позволяют беспрепятственно переносить электронные платежи, например, из системы некоторой фирмы, управляющей счетами к оплате, через инфраструктуру банкинга в систему продавца, управляющую счетами к получению. Следует отметить, что, по меньшей мере, в некоторых случаях, STP-технологии могут использоваться и в рамках рассмотренной выше передачи файлов через VPN. Сетью Electronic Payments Network был разработан пакет программ Set 820 для STP, который предлагает получивший широкое применение стандартизованный формат, пригодный для использования в одном или более вариантах (должно быть понятно, что обозначение "820" в этом контексте относится к указанному пакету, а не к процессору 820 на фиг.8). Специалисту должно быть понятно также, что MASTERCARD ФАЙЛ Express является примером приложения, которое доступно онлайн и которое обеспечивает как сжатие, так и шифрование передаваемых данных, используя, например, Международный алгоритм шифрования данных (International Data Encryption Algorithm, IDEA).

Один или более вариантов изобретения соответствуют способам, услугам, системам, устройствам и/или компьютерным программным продуктам, обеспечивающим связь между продавцами (непосредственно или через их сервис-провайдеров) и их клиентами (непосредственно или через сервис-провайдеров этих клиентов), чтобы реализовать электронную технологию для уведомления плательщика об одном или более счетах, отображения одного или более счетов, хранения одного или более счетов клиента, авторизации платежа (или запрашивания или иным образом облегчения этой авторизации), а также технологии для оплачивания счета наличными, дебетовой картой, кредитной картой, предоплаченной или иной платежной картой, посредством EFT-транзакции и/или чека (если не оговорено обратное, упоминания платежных карт должны интерпретироваться, как относящиеся к платежным картам любого типа, упоминания клиентов или потребителей - как относящиеся также к бизнесам, которые приобретают товары и/или услуги). В одном или более вариантах выполнение одного или более шагов способа облегчает оператор платежной сети (payment network, PN) 2008, именуемый далее также, как "ОПС". Один или более вариантов предпочтительно позволяют представить, а затем оплатить счет с использованием различных каналов, включая, (но не ограничиваясь ими) каналы в виде пунктов приема платежей (например, пунктов Western Union), дистанционные каналы (такие как сервисы финансовых организаций по онлайновой оплате счетов, провайдеры услуг по мобильной оплате счетов и др.) и непосредственно через веб-сайт продавца. Данный сервис предпочтительно реализуется без указания имени сервис-провайдера, что позволяет плательщику и продавцу получать к нему доступ независимо от возможной замены их сервис-провайдеров. Как будет пояснено далее, в данный сервис целесообразно интегрировать услугу автоматического обновления по биллингу (Automated Billing Updater, ABU) и/или услугу по отмене регулярного платежа (Recurring Payment Cancellation Service, RPCS). При этом данный сервис может предлагаться в сочетании с сервисом по оплате счетов (например, предоставляемым системой MasterCard RPPS) или быть интегрированным в данный сервис.

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

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

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

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

В одном или более случаев сервис согласно изобретению предоставляет одну или более, предпочтительно все, из следующих услуг:

- полный сервис по представлению и оплате счета;

- безопасную аутентификацию и сохранение логина;

- хранилище стейтментов и/или исторической информации;

- выбор клиентом базового или полностью индивидуализированного вариантов платежа;

- возможности полной отчетности для клиента;

- широкий каталог биллеров и/или продавцов с полными поисковыми возможностями;

- гарантию точной информации по EFT (из указателя биллеров в системе RPPS или из подобного указателя аналогичной системы электронной оплаты счетов);

- способность индивидуализировать предложения по каждому ПОС;

- использование со стороны ПОС и биллеров существующих возможностей связи для сервиса (если они уже являются клиентами оператора платежной сети 2008, неограничивающим примером которого является фирма Mastercard International Incorporated, США);

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

- предоставление вышеупомянутых ABU и/или RPCS, предпочтительно интегрированных в сервис, причем сервис может предлагаться в сочетании с сервисом по оплате счетов (например, в рамках системы MasterCard RPPS или аналогичной системы) или быть интегрированным в него.

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

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

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

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

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

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

В одном или более вариантах биллеры используют рассматриваемый сервис следующим образом.

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

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

- Сервис преобразует данные в необходимый формат и сохраняет информацию.

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

- Биллеры просят отослать плательщикам уведомление (уведомления).

- Согласно предпочтительному (неограничивающему) подходу биллер, кроме того, принимает платеж от оператора платежной сети или через систему электронной оплаты счетов, такую как MASTERCARD RPPS, или в виде карточного платежа.

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

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

- ПОС вводит кодовую строку или иным способом запускает сервис со своего веб-сайта.

- ПОС и сервис производят аутентификации креденциалов ПОС и использованного соединения.

- ПОС рекомендует сервис своим клиентам (потребителям).

- ПОС может взимать или не взимать с потребителей плату за сервис.

- Сервис может снабжать ПОС показателями использования сервиса через сайт ПОС.

- Если ПОС является ФО плательщика, ПОС может сообщить сервису доступные способы платежа.

В одном или более вариантах потребители (клиенты) используют рассматриваемый сервис следующим образом.

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

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

- Потребитель заходит на сайт ПОС.

- Потребитель регистрируется для пользования сервисом.

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

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

- Сервис сохраняет уникальные аутентификационные креденциалы потребителя.

- По завершении аутентификации интерфейс прикладной программы (application program interface, API) или аналогичное средство используется для того, чтобы представить сервис потребителю через веб-сайт ПОС. Следует отметить, что это представление может быть реализовано по схеме 'White Label', так что сервис будет иметь те же визуальные характеристики, что и ПОС.

- Потребитель находит и выбирает всех своих биллеров. Желательно, чтобы он мог проводить поиск биллеров различными методами, например по почтовому индексу, по штату (в США), по имени, по категориям продавцов. Сервис предпочтительно запоминает профиль потребителя, чтобы выводить сообщения типа "новые биллеры в вашей зоне".

- Потребитель вводит способ (способы) платежа, который (которые) он хочет использовать для каждого счета. Эти способы могут включать бессрочный депозитный счет (demand deposit account, DDA), различные бренды кредитных или дебетовых карт (например, MASTERCARD, VISA, DISCOVER, AMERICAN EXPRESS). В некоторых случаях ФО могут, если они сочтут это целесообразным, ограничивать типы карт определенными банковскими идентификационными номерами или аналогичными параметрами; эти параметры могут также указывать на предпочтения.

- Потребитель выбирает для каждого счета сумму, которую он готов по нему выплатить, например:

- полную выставленную сумму;

- минимальную допустимую сумму;

- фиксированную сумму;

- сумму, зависящую от управляющих факторов (описанных далее).

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

- еженедельно;

- ежемесячно;

- дважды в месяц;

- по требованию;

- по получении счета.

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

В одном или более вариантах потребителям доступна следующая опция "платежа одним кликом".

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

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

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

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

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

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

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

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

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

- Сервис позволит потребителю использовать настройки для задания способа платежа. Например, если счет за электричество не превышает 100 долларов, потребитель может выбрать платеж с DDA. В случае большей суммы потребитель может предпочесть воспользоваться своей бонусной кредитной картой.

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

- В сервис предпочтительно интегрированы услуги автоматического обновления по биллингу (ABU) и отмене регулярного платежа (RPCS) (см., например, патентную заявку США №2009/0171839, озаглавленную "Системы и способы процессинга регулярных платежных транзакций", патентную заявку США №2010/0174644, озаглавленную "Интегрированная файловая структура для использования совместно с устройством и способом реструктуризации учетных записей в системе электронной оплаты счетов", и патентную заявку США №2008/0046364, озаглавленную "Устройство и способ облегчения реструктуризации учетных записей в системе электронной оплаты счетов", причем содержание данных заявок включено в данное описание посредством ссылки в полном объеме и для всех случаев, разрешенных законом).

В одном или более вариантах предусмотрены следующие возможности по отчетности и/или бюджетированию.

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

- Сервис будет предпочтительно обеспечивать возможность загрузки данных по всем произведенным платежам, например, в целях исчисления налогов. При этом потребитель сможет выбирать форматы загрузки, которые могут импортироваться и/или входить в состав обычных средств, например, таких как программы Excel® (зарегистрированный товарный знак фирмы Microsoft Corporation, США), Qucken® (зарегистрированный товарный знак фирмы Intuit Inc., США), D&B® (зарегистрированный товарный знак фирмы Dun & Bradstreet International, Ltd, США). В одном или более вариантах загрузка включает применяемые в бизнесе системы дебеторской задолженности и/или кредиторской задолженности.

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

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

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

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

- Потребитель может отчитываться по своим платежам в соответствии со способом платежа ежемесячно, ежегодно, по категориям продавцов и т.д.

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

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

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

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

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

- Сервис также предпочтительно обеспечивает включение услуги "Скорость платежа" (Payment Velocity) для биллеров. Она поможет потребителям определять, когда следует произвести платеж. Скорость платежа может варьировать в зависимости от выбранного способа платежа.

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

В одном или более вариантах оператор платежной сети 2008, чтобы обеспечивать платежи, сотрудничает с одной или более финансовыми организациями (ФО). Благодаря сотрудничеству с ФО, осуществляющей процессинг платежных карт всех типов, сервис может предложить различные способы платежа. Однако ПОС может предпочесть приемлемость только его собственных способов платежа. Поэтому сервис предпочтительно должен быть гибким в отношении способов, предлагаемых конкретным ПОС и конкретным биллером. В некоторых случаях при осуществлении платежей используются опции, расширяющие функциональные возможности сервиса, такие как "инициатива эмитента" ("issuer push") и/или "преобразование карта/DDA" (см. далее обсуждение варианта "Карточный платеж, инициируемый ПОС"). Так, если биллер способен получать карточные платежи, платеж может быть преобразован из некарточного платежного канала в карточный. Например, если потребитель указал в качестве источника средств для оплаты счета свой DDA-счет, но у него имеется также дебетовая карта, платеж может быть преобразован из DDA-платежа в платеж дебетовой картой. С другой стороны, платеж бонусной кредитной картой может быть преобразован в DDA/ACH платеж, если получатель платежа не принимает карточные платежи, - но держатель карты, тем не менее, может получить бонус (см., например, заявку US 2010/0100480, которая озаглавлена "Устройство и способ регистрации на карту для оплаты счетов" и содержание которой включено в данное описание посредством ссылки в полном объеме и для всех случаев, разрешенных законом).

Один или более вариантов сервиса представления счета (Bill Presentment, BPT) предлагают участникам возможность представления электронных счетов потребителям. Сервис предусматривает опции различных уровней, что позволяет участникам индивидуализировать использование сервиса. Наличие этих уровней позволяет участникам "начать с малого" и постепенно расширять свои предложения клиентам по мере совершенствования своих систем или по мере изменения своих бизнес-моделей и целей.

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

- подключение к сервису по представлению счетов;

- подтверждение подключения к указанному сервису;

- коррекция подключения к указанному сервису;

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

- резюме представления счета;

- уведомление о получении платежа (см. далее);

- доставка файла изображения (см. далее).

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

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

В одном или более вариантах оператор платежной сети 2008, в соответствии со стандартной современной практикой, сохраняет историю всей информации, направляемой получателям.

Расширяющаяся база данных участников. Поскольку оператор платежной сети 2008 (например, фирма MasterCard International Incorporated) может располагать указателем биллеров, таким как Указатель биллеров в системе RPPS, оператор данной сети будет в состоянии обратиться ко многим различным потенциальным участникам, поскольку они, с большой вероятностью, уже будут клиентами системы оплаты счетов, такой как система RPPS/процессинга оплаты счетов. Это позволит оператору платежной сети 2008 предложить более полный, точный и расширяющийся набор участников. В одном или более вариантах оператор платежной сети 2008 будет предлагать, в качестве дополнительной услуги, список биллеров, участвующих в представлении счетов. ПОС (как правило, организация, предлагающая услуги по оплате счетов онлайн) может использовать этот список в качестве перечня биллеров, которых можно рекомендовать своим клиентам в части оплаты счетов онлайн. Такой список будет не только идентифицировать различные виды платежей для биллеров (EFT и соответствующие бренды кредитных и/или дебетовых карт), но также и идентифицировать биллеров, предлагающих ВРТ и способы, доступные для просмотра счетов. Эти способы могут реализовываться по "горячей линии" и могут иметь в своей основе файл изображения (как это будет описано далее), линк для единого входа (single sign 'on, SSO) на сайт биллера для получения стейтмента (см. далее) или просто линк на страницу биллера для ввода логина.

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

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

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

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

- Операции внутри системы - оператор платежной сети 2008 разработает внутрисистемное решение типа SAML/SSO (SAML - язык разметки подтверждения безопасности) или аналогичное решение, которое позволит любому ПОС или концентратору/биллерам участвовать в SSO. Это создаст упрощенную модель, снижающую нагрузку на участников

- Оператор платежной сети 2008 будет находиться в партнерских отношениях с ПОС в части аутентификации плательщика при регистрации.

Доставка изображения - для участников, которые не хотят нести затраты на SSO для прямой или непрямой связи с биллерами, оператор платежной сети 2008 обеспечит услуги по доставке изображения. Оператор платежной сети 2008 будет принимать файлы изображения (ФИ) для биллеров, которые выбирают доставку файла изображения стейтмента потребителя (в противоположность поддержке или допущению SSO). При этом оператор платежной сети 2008 предложит два способа доставки изображения для ПОС (предполагается, что ПОС обеспечит горячую линию на веб-сайт для оплаты счетов плательщика для тех счетов, применительно к которым файлы изображения доступны; в других вариантах могут применяться иные подходы).

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

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

Оператор платежной сети 2008 предпочтительно поддерживает широкий набор типов файлов изображения; однако, желательно ограничить эти файлы стандартными типами широкого применения, чтобы ПОС могли гарантированно воспроизводить их.

- Так, типы файлов могут включать JPEG, Bitmap, TIFF, GIF, MS Word, Rich Text Format или Adobe Reader, (.jpg, .bmp, .tif, gif, .doc, .rtf или .pdf).

- Оператор платежной сети 2008 будет позволять ПОС выбирать приемлемые типы файлов изображения.

- Оператор платежной сети 2008 будет позволять биллерам направлять файлы изображения различных типов, чтобы удовлетворить различные потребности ПОС.

- Оператор платежной сети 2008 может предложить услуги по преобразованию файлов изображения, обеспечивающие, путем преобразования файла изображения из одного типа в другой, его соответствие требованиям ПОС.

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

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

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

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

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

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

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

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

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

Карточный платеж, инициированный ПОС (инициатива эмитента). В некоторых случаях новые процессинговые возможности позволяют ПОС инициировать карточный платеж вместо отсылки уведомления биллеру на инициирование карточного платежа. В настоящее время ПОС может инициировать EFT-платеж непосредственно в системе, такой как система RPPS или другой процессинговый центр EFT. Однако для карточного платежа в типичном случае этот платеж должен инициироваться биллером/эквайером. Благодаря этому новому сервису оператор платежной сети 2008 обеспечит и облегчит процессинг карточных платежей от ПОС.

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

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

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

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

В некоторых случаях, работая в партнерстве с инициирующим депозитарным финансовым учреждением (originating depository financial institution, ODFI), оператор платежной сети 2008, действуя в качестве ПОС, будет принимать и отслеживать платежные поручения, обеспечивать сервис по представлению счетов и инициировать платежи через систему RPPS (или аналогичную систему), поддерживать глобальную систему клиринга и управления или соответствующий шлюз. С этим сервисом будет доступен процессинг платежей (описанный выше, в связи с "Карточным платежом, инициированным ПОС"). Поскольку оператор платежной сети 2008 контролирует процессинг, он будет способен предложить ускоренные платежи для брендов платежных карт, ассоциированных с брендом данного оператора, или EFT-платежи, но только для тех биллеров, которые принимают их.

Как было отмечено, в одном или более вариантах обеспечивается универсальное предложение, обеспечивающее подписчикам доступ к сервису независимо от изменений в составе их сервис-провайдеров. В одном или более вариантах реализация этой возможности облегчается тем, что оператор платежной сети 2008 (ОПС) функционирует как хранилище данных. ОПС получает информацию по счету со стороны продавца и потенциально преобразует ее в собственный формат. Затем эти данные могут храниться в системе хранения ОПС, и ОПС может быть ответственным за соотнесение счетов с конкретным потребителем, группирование этих счетов и обеспечение их доступности даже при изменении места входа потребителя в систему хранения. Например, если потребитель сначала получает доступ к информации через онлайн-банкинг, предоставляемый банком ACME BANC, а затем переходит на онлайн-банкинг от банка BAKER BANC, историческая информация 599, данные 526 о предпочтениях и данные 522 по регистрации (см. фиг.5) останутся доступными для потребителя, несмотря на изменение точки входа. В одном или более вариантах потребитель не получает прямого доступа к хранилищу данных в составе ОПС. Тем не менее, ОПС способен понимать и интерпретировать информацию, затребованную потребителями, изменяющими точки доступа.

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

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

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

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

Таким образом, в дополнение к универсальности и обеспечению для подписчиков доступа к сервису независимо от изменений, касающихся их сервис-провайдеров, один или более вариантов обеспечивают доступ из многих точек входа (например, через различных провайдеров оплаты счетов или с нескольких аккаунтов у одного провайдера оплаты счетов). Как должно быть понятно из фиг.5-7, ПОС эквивалентны инициаторам (хотя специалисту будет понятно, что иногда плательщик может взаимодействовать с сервис-провайдером потребителя, который может являться или не являться ODFI). Кроме того, биллеры 510, 538, 608; ПОС 508, инициатор 604; плательщики 550, 602 и другие субъекты, показанные, для наглядности, в единственном числе, реально могут представлять группы организаций. Так, плательщик может иметь несколько ПОС, любой ПОС может иметь множество плательщиков и т.д. Такая ситуация может иметь место в случае общего аккаунта или если люди имеют дело с несколькими банками.

Сервис-провайдер EFT обозначен, как 606, причем ассоциированный с ним сервер SAML - это неограничивающий пример технологии для защищенного SSO в рамках Интернета. Кроме того, SAML или аналогичные сервисы (обеспечивающие базу данных для хранения креденциалов для SSO и аутентификации), помимо провайдера 606, могут обеспечиваться и другими провайдерами и даже ПОС. Далее, API - это неограничивающий пример интерфейса, потребитель - неограничивающий пример плательщика, а система RPPS - неограничивающий пример системы электронной оплаты счетов.

Уже упоминалось, что в одном или более вариантах плательщикам предоставлена возможность платить, в соответствии с установленными предпочтениями, по множеству счетов посредством единственной команды (одним кликом, нажатием одной кнопки и т.д.). Так, в некоторых вариантах для всех счетов, которые некоторый плательщик решает оплатить через некоторого провайдера, для каждого случая установлены предпочтения по умолчанию, включающие, например, способ платежа, желательную дату платежа, размер платежа и т.д. Когда счета получены, может появиться единственная кнопка, например, с надписью "кликни, чтобы оплатить все". Некоторые или все такие предпочтения могут храниться, например, в базе 526 данных с их обработкой в блоке 536.

ГПИ для оплаты счета может быть сделан доступным в форме веб-сайта, принадлежащего ПОС 508. Как показано на фиг.5, в некоторых случаях потребители или другие плательщики 550 не будут заходить непосредственно на этот сайт, а будут получать доступ к нему через своих сервис-провайдеров. Коммерческие участники, такие как биллеры 510 и ПОС 508, могут иметь прямой доступ к ГПИ (по сети или иным способом). База 522 данных SSO может поддерживаться ОПС или сервис-провайдером (в качестве неограничивающего примера, им может быть сервис-провайдер, обеспечивающий EFT-сервисы). Блок 536 процессинга представления счетов предпочтительно выполнен в форме программной платформы, выполняемой на одном или более серверах под контролем или от имени ПОС.Другая платформа 540 предпочтительно представляет собой программную платформу, выполняемую на одном или более серверах под контролем или от имени ОПС и обеспечивающую сервисы по оплате счетов (неограничивающим примером является сервис RPPS). В некоторых случаях программная платформа 540 может использовать технологии типа описанных в упомянутой заявке США №61/438,106 или другие технологии, применяемые в других системах электронной оплаты счетов. Платформы 536, 540 предпочтительно интегрированы и взаимодействуют одна с другой. Форматтеры 532, 534 позволяют ПОС и биллеру использовать свои собственные (внутренние) форматы файлов, в которых файлы посылаются ОПС и преобразуются в формат ОПС (который может быть собственностью ОПС) форматтерами 532, 534. Эти форматтеры способны также выполнять обратный процесс, изменяя формат, принадлежащий ОПС, в формат, нужный для биллера или ПОС. Форматтеры 532, 534 могут быть реализованы, например, посредством соответствующих программных модулей под контролем ОПС или сервисной службой третьей стороны.

Блок 595 консолидирования транзакций используется в ситуации, когда различные транзакции, поступающие от различных инициаторов, обрабатываются и консолидируются получателем; при этом в некоторых случаях различные платежи поступают от различных провайдеров. Платежи могут также обрабатываться и консолидироваться отдельно для каждого биллера или концентратора. Процессинг 546 ФИ относится к изображениям стейтментов по биллингу. Блок 589 перечисляет функции, которые могут быть реализованы посредством пользовательского интерфейса. При этом блок "Напоминания" соответствует примеру различных сообщений и/или документов (например, таких как указания на конфиденциальность и типовые формы), которые плательщик может получить таким же образом, как и счет (например, через ПИ, инициатора и т.д.). Сообщения, не являющиеся счетами, формами и/или документами, обычно не требуют отклика в форме платежа.

Как было упомянуто, один или более вариантов поддерживают платеж наличными, чеком, дебетовой или кредитной картой и в форме EFT. Потребитель или другой плательщик, который хочет уплатить наличными или чеком, может использовать сервис-провайдера, имеющего близкорасположенный реальный офис, в который могут быть физически переданы наличные или чек. Для карточного платежа соответствующая информация о платежном карточном счете может храниться, например, в базе 526 данных. Необходимая для EFT информация о бессрочном депозитном счете может храниться, например, также в базе 526 данных. Карточный и EFT платежи доступны плательщику и в реальном офисе. В некоторых случаях база 526 данных может не содержать указанную детальную информацию, а может хранить только доступные опции; вместо этого, информацию по бессрочному депозитному счету и/или платежному карточному счету может хранить ПОС. В этом случае при смене ПОС плательщик может быть вынужден повторно ввести информацию по бессрочному депозитному счету и/или платежному карточному счету (за исключением случая, когда новый ПОС допускает использование несвязанного платежного счета, т.е. счета не в его финансовой организации). В одном или более вариантах ОПС делает предпочтения доступной финансовой организации (доступным финансовым организациям). Потребитель доводит свои предпочтения и подробную информацию о банковском счете до сведения ПОС.Однако в некоторых случаях все эти данные хранит ОПС, например, в своей базе 526 данных. В таком случае, когда потребитель или другой плательщик формулирует платежные инструкции, возможна ситуация, в которой ПОС является не финансовой организаций, а просто сервисом, к которому обращается потребитель. Должно быть понятно, что в этой ситуации предпочтения для режима "одним кликом" предпочтительно хранятся в централизованном хранилище, таком как база 526 данных. В результате предпочтения могут быть доставлены независимо от места входа потребителя. Таким образом, в некоторых случаях вся информация о предпочтениях, включая подробную информацию по бессрочному депозитному счету и/или платежному карточному счету, хранится в базе 526 данных. В других случаях часть информации может храниться в базе 526 данных, а часть в других местах, например в одном или более ПОС.

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

Как показано на фиг.5, SSO 502 предусмотрен для ПОС 508 и биллера 510. Каждая организация может воспользоваться облегчением аутентификации или процессингом, обеспечиваемыми SSO (см. блок 506), чтобы получить интерфейс к базам 524, 526, 528 и/или 599 данных в блоке 520. SSO или аналогичная база данных представлен (представлена) также в виде блока 522. ПОС 508 и биллер 510 обеспечивают свое участие в сервисе 504 по представлению счетов (далее именуемом также сервисом ППС), используя соответствующие инструменты 512 в блоке критериев участия 516. Группы (команды) 514 поддержки в составе ОПС оценивают и одобряют участников (см. блок 518). Функциональность по управлению соответствующими параметрами может быть обеспечена в блоке 597.

На фиг.5-7, 9 и 10 термин "биллер" должен пониматься (если прямо не оговорено обратное или это явно не вытекает из контекста), как соответствующий биллеру и/или СПБ, а "ПОС" - как соответствующий ПОС и/или СПП или аналогичной организации, действующей как сервис-провайдер.

Плательщик 550 получает доступ к ПОС 508 через соответствующий ПИ после прохождения аутентификации. Как видно из фиг.5, ПИ 589 может предоставлять много различных возможностей. Форматтеры 532, 534, платформы 536, 540 и биллер 538 рассматриваются в других местах описания. Платформа 536 может обеспечивать, например, валидацию и маршрутизацию 542, уведомления 544, консолидирование 595 транзакций, процессинг 546 ФИ, процессинг 548 SSO, доступность 593 ABU/RPCS или аналогичную функциональность и/или сохранение 591 исторической информации.

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

На фиг.6 и 7 потребители или другие плательщики обозначены, как 602, инициаторы или различные ПОС - как 604, ОПС - как 2008, сервис-провайдер - как 606, а биллеры или финансовые организации биллеров (ФОБ) - как 608. В SSO для включения в сервис организация 604 подает запрос на включение на шаге (в блоке) 610. На шаге (в блоке) 616 ОПС создает указатель, который обновляется на шаге 618. На шаге 624 ФОБ может спонсировать биллера и может включить его в список участников на шаге 626. На шаге 620 ОПС высылает входные креденциалы, и на шагах 612, 628 организации 604, 608 обновляют свои базы данных. Сервис-провайдер 606 или аналогичная организация обновляет сервер SAML или аналогичный сервер на шаге 622. На шаге 614 ОПС может сохранить ключи шифрования.

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

Потребитель 602 может иметь аккаунт у биллера (как это показано в блоке 630) и может присутствовать в базе аккаунтов клиентов (см. блок 632). Потребитель 602 на шаге 634 авторизуется перед организацией 604, и на шаге 636 ему выдается список биллеров, работающих онлайн. На шаге 642 потребитель выбирает биллера для подключения. На шаге 644 организация 604 представляет запрос на подключение (который может включать, например, ИД ФО-инициатора и ИД потребителя, - см. блок 646), и ОПС обрабатывает эти данные на шаге 648. Следует отметить, что информация о биллерах для шага 636 может быть получена на шаге 638 от ОПС через API 640 или аналогичным путем. Организация 608 обрабатывает (на шаге 650) запрос (возможно, с проведением его анализа и коррекции - см. блок 652). На шаге 654 выводится одобрение запроса; процессинг одобрения производится ОПС на шаге 656. Организация 604 отсылает одобрение потребителю на шаге 658.

Возможность коррекции запроса отражена в блоке 660, ее процессинг производится ОПС на шаге 662, после чего на шаге 664 организация 604 направляет ее потребителю. В случае согласия потребителя (шаг 666) он на шаге 668 высылает подтверждение, процессинг которого производится на шагах 670 и 672.

Как показано на фиг.7, организация 606 генерирует стейтмент (шаг 702), который может быть на шаге 704 преобразован ОПС в резюме и направлен потребителю на шаге 706 организацией 604. Потребитель на шаге 708 посредством клика формирует запрос на показ ему счета. Этот запрос на шаге 710 направляется организацией 604 в организацию 606, и на шаге 712 организация 606 или аналогичная организация (сервис-провайдер идентификации) производит верификацию креденциалов SSO. После этого полная информация по счету может быть представлена на шаге 714, например, в новом окне браузера, открывшемся на шаге 716. На шаге 718 потребитель возвращается к начальному окну и кликает на "оплатить", после чего организация 604 на шаге 720 запускает механизм маршрутизации платежа (при доступности ряда опций, включая дебетовую карту). ОПС может осуществить процессинг платежа на шаге 722. Альтернативно, для поддержки сети для EFT на шаге 728 можно использовать третью сторону (ТС) 726. Платеж получен на шаге 730.

На фиг.9 иллюстрируется опция, в которой регистрации плательщика не требуется. В этом случае инициаторы/ПОС должны подтвердить (на шаге 914), что они способны получать электронные счета (е-счета), а биллеры должны подтвердить (на шаге 908), что они способны высылать е-счета. Если ПОС использует ОПС 2008 для процессинга платежей, любые плательщики, использующие сервис ПОС, автоматически становятся участниками. Следует предусмотреть соответствующую модификацию, если инициатор хочет рассылать е-счета, но направлять платежи в ПОС. При начальной настройке 902 задается, что биллер может посылать е-счета на шаге 908, с установкой, на шаге 910, индикатора на профиль данного биллера. Соответствующее преобразование данных обозначено, как 912. Задается также, что инициатор может получать е-счета (шаг 914), с установкой, на шаге 916, индикатора на профиль инициатора. Соответствующее преобразование обозначено, как 918.

С учетом рассмотрения фиг.5 специалисту будет ясно, что шаги 908, 910, 914, и 916 могут обеспечиваться командами программы, входящей в состав платформ 536 и/или 540 с сохранением соответствующих индикаторов в соответствующей базе данных, например в базах 524 и/или 526. Взаимодействие с платформами 536 и/или 540 может быть облегчено при наличии подходящего пользовательского интерфейса, например такого, как ПИ 589. Кроме того, функциональность преобразования может быть реализована, например, в блоках 534 (для двусторонней коммуникации с биллерами) и 532 (для двусторонней коммуникации с потребителями).

Первоначальное получение данных из хранилища данных (ХД) производится на шаге 920; на шаге 922 идентифицируются все платежи, полученные инициатором для определенного биллера (т.е. выявляются платежи между двумя интересующими сторонами). На шаге 924 выделяются номера аккаунтов биллера (например, для случаев, когда был осуществлен платеж между двумя интересующими сторонами). На шаге 926 эти счета, а также любые другие полезные данные, неограничивающим примером которых являются ИД биллера и инициатора (см. таблицу 928), запоминаются в таблице отношений (например, в базе 526). Специалисту будет понятно, что хранилищем данных (ХД) в данном случае может быть, например, хранилище исторических данных 599.

Аспект, связанный с файлом е-счета, иллюстрируется в блоке 904. Биллер 538 посылает этот файл на шаге 942; преобразование данных (например, в блоке 534) производится на шаге 944, и на шаге 946 формируется подтверждение того, что индикатор е-счета биллера соответствует "Y" (например, соответствующая программа в составе платформ 536 и/или 540 проверяет базы данных (например, базы 526 и/или 524), чтобы определить, был ли индикатор установлен в состояние "Y" на шаге 910). С учетом изложенного специалисту будет понятно, что файл е-счета может содержать, например, номер аккаунта биллера и сумму, подлежащую выплате (при этом в некоторых случаях файл е-счета не содержит идентификатора соответствующего инициатора). Платформа 540 для оплаты счетов может просмотреть (на шаге 948) таблицу 928 (хранящуюся, например, в блоке 526), чтобы найти ИД биллера и номер его аккаунта. Если они найдены (ветвь "Да" от блока 950), платформа 540 переходит на шаг 952 и получает идентификатор (ИД) или идентификаторы (ИДы) инициатора и переходит на шаг 954. Специалисту будет понятно, что возможно наличие нескольких ИД инициатора, например, если потребитель производит оплату на аккаунт биллера с использованием нескольких способов платежа (например, со счетов в двух различных банках). Если ИД инициатора не найден, на шаге 954 проверяется, имеются ли еще е-счета. Если да, происходит возврат на шаг 948. Если нет, на шаге 956 производится консолидация е-счетов (т.е. счетов для одного инициатора). На шагах 958 и 960 производятся преобразование данных и отсылка инициатору.

В отношении шага 954 следует отметить, что от одного биллера может быть получено некоторое количество различных счетов (например, группа счетов в единственном файле или группа файлов с единственным счетом в каждом из них, или группа файлов, по меньшей мере некоторые из которых могут содержать группу счетов). Что касается шага 956, многие биллеры могут иметь по одному или более счетов, предназначенных для одного инициатора. Шаг 956 может выполняться, например, с помощью платформы 536 (см., например, блок 595), а шаг 958 - например, с помощью блока 532.

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

В блоке 906 иллюстрируется аспект платежного файла. На шаге 930 инициатор посылает платежный файл, нормальное преобразование и процессинг которого происходит на шаге 932 (например, с помощью платформы 540 после соответствующего преобразования в блоке 532). Если биллер посылает е-счет на шаге 934 (т.е. на шаге 910 индикатор установлен в состояние "Y" и сохранен, например, в базах 524 и/или 526 данных), на шаге 936 проверяется, получен ли счет инициатором (т.е. установлен ли на шаге 916 индикатор в состояние "Y"). Если да, номер аккаунта биллера добавляется на шаге 938 в таблицу 928, созданную на шаге 926 (если его в ней не было) и происходит автоматическая доставка счета на шаге 940, когда биллер вышлет следующий файл е-счета. В некоторых случаях, даже если потребитель еще не выразил желания участвовать в е-биллинге, вместо автоматической доставки может быть сохранена информация для использования в будущем.

Как показано на фиг.10, новый плательщик на шаге 3002 регистрируется на сервисе ППС (специалисту, с учетом рассмотрения фиг.5, будет понятно, что для этого можно применить пользовательский интерфейс 589 с соответствующей аутентификацией). Система на шаге 3004 представляет перечень доступных биллеров (специалисту, с учетом рассмотрения фиг.5, будет понятно, что для этого можно применить, например, пользовательский интерфейс 589, взаимодействующий с платформами 540 и/или 536 при использовании данных, например из базы 524). На шаге 3006 плательщик 550 выбирает биллера (биллеров) для осуществления платежей "одним кликом". На шагах 3008, ЗОЮ выбираются и запоминаются предпочтения (например, в базе 526 данных, которая в типичном случае ведется ОПС 2008 или продавцом, действующим под его управлением). Для выполнения этих шагов плательщик, как правило, будет использовать ПИ 589 при соответствующем взаимодействии с платформами 536 и/или 540. При этом для каждого счета можно задать индивидуальные уникальные предпочтения: например, платить по ипотеке в полном объеме ежемесячно с использованием платежного источника "А"; ежемесячно производить минимальный платеж для кредитной карты "X" с использованием платежного источника "В" и т.д.

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

На шаге 3016 (например, после того как нужные данные были сохранены в процессе регистрации), с учетом аутентификационной информации по плательщику, выводятся выбранные биллеры и предпочтения для платежа "одним кликом". На шаге 3018 плательщик может видеть все счета. Все счета могут быть оплачены "одним кликом" на шаге 3020; на шаге 3022 этим способом могут быть оплачены только некоторые счета, на шаге 3024 платеж может производиться без применения данного способа. На шаге 3026 система использует предпочтения для метода "одним кликом", выбранного на шаге 3020 или 3022. На шаге 3028 плательщику может быть дан шанс изменить эти предпочтения. Если никакие счета не были выбраны для платежа "одним кликом", система на шаге 3030 может выдать пользователю соответствующие подсказки. Переход к шагу 3030 возможен также с шага 3024. На шаге 3032 производится консолидация счетов с их оплатой на шаге 3034. Эти шаги могут выполняться, например, платформой 536, взаимодействующей с ПИ 589 и базами 524, 526 данных (но реальный платеж обычно осуществляется платформой 540).

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

Из изложенного должно быть понятно, что, в широком смысле, вариант способа согласно изобретению включает создание, под контролем оператора процессинговой сети, сервиса по представлению счетов (обеспечиваемого, например, платформой 536), в рамках которого счета, полученные от множества биллинговых организаций, делаются доступными множеству потребителей через множество сервис-провайдеров потребителей. Следует отметить, что в контексте изобретения термин "под контролем" охватывает как ситуации, в которых сервис обеспечивается только оператором процессинговой сети, так и ситуации, когда он обеспечивается оператором процессинговой сети и одним или более продавцами, действующими под управлением и под контролем оператора процессинговой сети. В качестве неограничивающего примера рассмотрим случай, когда продавец функционирует как сервис-провайдер 606, обеспечивающий сервер SAML. Далее, в контексте изобретения термин "оператор процессинговой сети" охватывает любую централизованную сеть электронных платежей, такую как RPPS или BILL PAY, и/или организацию, которая поддерживает (облегчает) платежи посредством платежных карт или аналогичных инструментов (неограничивающим примером такой организации является платежная сеть 2008). Возможности, предоставляемые сетью 2008, могут быть полезны и в случае, когда организация предлагает организациям-потребителям, использующим сеть, опцию осуществления платежей с использованием технологий типа платежных карт (таких как платежи при отсутствии карты или в режиме "card on file").

Под "потребителями" в контексте изобретения понимаются индивидуальные потребители и/или бизнесы, приобретающие товары и/или услуги. Под "биллинговыми организациями" понимаются организации типа СПБ, биллеры, финансовые организации биллеров (ФОБ) и/или концентраторы. Под "сервис-провайдерами потребителей" понимаются такие организации, как различные ПОС (которые иногда могут являться инициаторами (ODFI)) и/или консолидаторы. Кроме того, в некоторых случаях указанные на чертежах организации могут быть заменены другими организациями (например, на фиг.5 данные, поступающие от биллера 538, могут поступать от СПБ). В формуле изобретения перечисленные термины "потребители", "биллинговые организации" и "сервис-провайдеры потребителей" используются там, где нужно обеспечить общность, тогда как ссылки на более специфичные организации приводятся в целях конкретизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как видно из фиг.9, в некоторых случаях отслеживание транзакций может включать хранение данных, характеризующих способность посылать и получать счета в электронной форме (см. шаги 910 и 916 соответственно). В таких случаях отслеживание может включать (см. шаг 926) хранение в таблице отношений, на основе исторических данных, идентификаторов и номеров аккаунтов биллинговых организаций, а также идентификаторов сервис-провайдеров потребителей. Отслеживание транзакций может также включать, при получении оператором процессинговой сети счета от конкретной биллинговой организации в электронной форме, обращение к таблице отношений, чтобы получить идентификаторы по меньшей мере одного сервис-провайдера потребителя, соответствующие идентификаторам указанной биллинговой организации, а также номера ее аккаунтов (см. шаги 950 и 952). Дополнительный шаг (960) в таких случаях может включать обеспечение доступности счета от данной биллинговой организации по меньшей мере одному потребителю, соответствующему идентификаторам по меньшей мере одного сервис-провайдера потребителя.

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

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

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

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

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

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

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

Кроме того, должно быть также понятно, что, в общем случае, еще один вариант способа согласно еще одному аспекту изобретения включает операцию обеспечения, под контролем оператора процессинговой сети, сервиса по представлению счетов с обеспечением доступности счетов, полученных от множества биллинговых организаций, множеству потребителей через множество сервис-провайдеров потребителей, а также операцию обеспечения оператором процессинговой сети по меньшей мере части сервиса по оплате счетов, причем потребителям предоставляется опция оплаты указанных счетов от указанного множества биллинговых организаций, а указанная операция по обеспечению указанного сервиса осуществляется без необходимости регистрации указанного множества потребителей. Дополнительные операции способа включают получение (на шаге 908) от множества биллинговых организаций подтверждения способности посылать счета в электронной форме (с их сохранением); получение (на шаге 914) от множества сервис-провайдеров потребителей подтверждения способности получать счета в электронной форме (с их сохранением); отслеживание множества транзакций, чтобы идентифицировать тех потребителей из указанного множества, которым предназначены счета в электронной форме (см. шаги 920-928). Что касается упомянутого сохранения, то, как показано на фиг.9, в некоторых случаях отслеживание транзакций может включать хранение данных, подтверждающих способность посылать счета в электронной форме (см. шаг 910), и данных, подтверждающих способность получать счета в электронной форме (см. шаг 914).

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

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

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

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

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

Далее, изобретение охватывает также устройства, содержащие один, некоторые или все компоненты, проиллюстрированные на фиг.5. Например, такое устройство может содержать платформу 536 представления счетов, сконфигурированную для обеспечения, под контролем оператора процессинговой сети, сервиса по представлению счетов с обеспечением доступности счетов, полученных от множества биллинговых организаций 538, множеству потребителей 550 через множество сервис-провайдеров 508 потребителей. Как отмечалось, платформа 536 может быть реализована в виде программного модуля, выполняемого на компьютере общего назначения и/или на специализированном устройстве. Такое устройство может содержать также: базу данных (такую как база 520) или любую ее часть (например, базу 526), связанную с платформой представления счетов, доступную оператору процессинговой сети и сконфигурированную для хранения данных о регистрации и предпочтениях, соответствующих каждому потребителю из множества потребителей, и модуль 589 пользовательского интерфейса, сконфигурированный для предоставления любому потребителю из множества потребителей, который совершает переход от одного (первого) из указанных сервис-провайдеров ко второму из указанных сервис-провайдеров, возможности доступа к платформе представления счетов до перехода через первого сервис-провайдера и, после перехода, через второго сервис-провайдера с использованием сохраненных данных о регистрации и предпочтениях. При этом подмножество множества данных о регистрации и предпочтениях соответствует указанному потребителю, а модуль пользовательского интерфейса сконфигурирован с возможностью предоставления указанному потребителю доступа к платформе представления счета через указанного второго сервис-провайдера без необходимости каких-либо действий по обновлению по меньшей мере части подмножества данных о регистрации и предпочтениях.

В другом своем аспекте устройство может содержать: платформу 536 представления счетов, сконфигурированную для обеспечения, под контролем оператора процессинговой сети, сервиса по представлению счетов с обеспечением доступности счетов, полученных от множества биллинговых организаций, множеству потребителей через множество сервис-провайдеров потребителей; платформу 540 оплаты счетов, сконфигурированную для обеспечения оператором процессинговой сети по меньшей мере части сервиса по оплате счетов, причем потребителям предоставляется опция оплаты указанных счетов от указанного множества биллинговых организаций; и базу данных (такую как база 520) или любую ее часть (например, базу 526), связанную с платформой представления счетов и/или с платежной платформой, доступную оператору процессинговой сети и сконфигурированную для хранения данных о регистрации и предпочтениях. Эти данные соответствуют каждому из множества потребителей, причем по меньшей мере часть данных о регистрации и предпочтениях включает данные о платежных предпочтениях, указывающие, как любой из потребителей хочет платить по меньшей мере двум биллинговым организациям. Модуль 589 пользовательского интерфейса сконфигурирован с возможностью предоставления указанному потребителю опции платить по меньшей мере двум биллинговым организациям посредством единственной команды, в соответствии с указанными данными о платежных предпочтениях.

В следующем своем аспекте устройство может содержать платформу 536 представления счетов, сконфигурированную для обеспечения, под контролем оператора процессинговой сети, сервиса по представлению счетов с обеспечением доступности счетов, полученных от множества биллинговых организаций, множеству потребителей через множество сервис-провайдеров потребителей. Такая платформа (возможно, при содействии блока 534) способна получить от одной из биллинговых организаций один из счетов с указанием ассоциированного с ним единственного номера аккаунта биллера. Эта платформа (возможно, при содействии блока 532 и/или модуля 589 пользовательского интерфейса) направляет указанный счет от указанной биллинговой организации с ассоциированным с ним единственным номером аккаунта биллера группе сервис-провайдеров потребителей для представления соответствующему потребителю через этих сервис-провайдеров.

Еще в одном своем аспекте устройство может содержать платформу 536 представления счетов, сконфигурированную для обеспечения, под контролем оператора процессинговой сети, сервиса по представлению счетов с обеспечением доступности счетов, полученных от множества биллинговых организаций, множеству потребителей, и платформу 540 оплаты счетов, сконфигурированную для обеспечения оператором процессинговой сети по меньшей мере части сервиса по оплате счетов, причем потребителям предоставляется опция оплаты указанных счетов от указанного множества биллинговых организаций. В некоторых случаях обеспечение сервиса по представлению счетов осуществляется без начальной регистрации в нем множества потребителей. Платформы 536 и/или 540 получают от множества биллинговых организаций подтверждение их способности посылать счета в электронной форме, а подходящий модуль базы данных (типа описанного выше) обеспечивает хранение указанных данных. Платформы 536 и/или 540 получают также от множества сервис-провайдеров потребителей подтверждение их способности получать счета в электронной форме, а подходящий модуль базы данных (типа описанного выше) обеспечивает хранение указанных данных. Платформы 536 и/или 540 отслеживают множество транзакций, чтобы идентифицировать тех потребителей из указанного множества, которым предназначены счета в электронной форме. Это отслеживание может производиться с помощью модуля базы данных и включать, например, хранение в таблице отношений, на основе исторических данных 599, идентификаторов биллинговых организаций, номеров аккаунтов биллинговых организаций и идентификаторов сервис-провайдеров потребителей. При этом, при получении оператором процессинговой сети счета в электронной форме от одной определенной биллинговой организации, платформы 536 и/или 540 могут обращаться к таблице отношений в модуле базы данных, чтобы выявить по меньшей мере один идентификатор сервис-провайдера потребителя, соответствующий идентификатору указанной определенной биллинговой организации и номеру одного из ее аккаунтов. Платформы 536 и/или 540 взаимодействуют с модулем 589 пользовательского интерфейса, чтобы обеспечить доступность выявленного счета определенной биллинговой организации по меньшей мере одному из множества потребителей, соответствующему по меньшей мере одному идентификатору сервис-провайдера потребителя.

Части выполнения системы и устройства по изобретению

Варианты изобретения могут иметь аппаратные и/или аппаратно-программные аспекты. Используемое программное обеспечение содержит (не ограничиваясь ими) встроенные программы, резидентные программы, микрокод и т.д. Программное обеспечение может использоваться, например, применительно к одному или более терминалам 122, 124, 125, 126; модулю 132 считывателя; платежным устройствам (таким как карты 102, 112); главному компьютеру; серверу; процессинговому центру 140, 142, 144 (возможно, с хранилищем 154 данных) продавца; эмитенту; эквайеру, процессору; концентратору; оператору платежной сети; инициатору; сервис-провайдеру; биллеру; клиенту; банку; потребителю; биллинговой организации; сервис-провайдеру потребителя или любой другой организации, как это проиллюстрировано на чертежах. Встроенное программное обеспечение может быть применено, например, в платежных устройствах, таких как карты 102, 112. Оно обеспечивает реализацию ряда базовых функций (например, отображение, печать, функцию подтверждения посредством соответствующих кнопок), которые, сами по себе, не обеспечивают реализацию итогового приложения, а являются скорее "строительными блоками", которые объединяются основной программой, чтобы реализовать полезное решение.

На фиг.8 представлена блок-схема системы 800, в которой могут быть использованы часть или все из одного или более аспектов или процессов согласно изобретению. Как показано на фиг.8, память 830 конфигурирует процессор 820 (который может соответствовать, например, процессорным секциям 106, 116, 130, процессорам удаленных главных компьютеров в центрах 140, 142, 144, серверам, реализующим одну или более платформ, или процессорам, ассоциированным с любой из организаций (которые представлены на чертежах), чтобы осуществить один или более аспектов или способов, шагов и функций, раскрытых в данном описании (в целом обозначенных на фиг.8, как процесс 880). Различные шаги способа могут выполняться различными процессорами. Память 830 может быть распределенной или локальной, а процессор 820 - распределенным или единственным. Память 830 может быть реализована, как электрическая, магнитная или оптическая память или как любая комбинация из них, или как другие типы запоминающих устройств. Следует заметить, что, если используются распределенные процессоры, каждый распределенный процессор, который входит составной частью в процессор 820, обычно содержит свое собственное адресуемое пространство памяти. Следует заметить также, что некоторые или все из компьютеров системы 800 могут быть встроены в интегральную схему, специализированную или общего назначения. Например, один или более шагов способа могут быть осуществлены скорее как аппаратное обеспечение с использованием специализированной интегральной схемы, чем с использованием встроенного программного обеспечения. Дисплей 840 является примером множества возможных вариантов устройств ввода-вывода (например, таких как дисплеи, мыши, клавиатуры).

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

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

Таким образом, элементы одного или более вариантов осуществления изобретения, такие, например, как упомянутые выше терминалы 122, 124, 125, 126, процессинговые центры 140, 142, 144 с хранилищем 154 информации, процессоры, ассоциированные с любой организацией, представленной на чертежах, или платежные устройства, такие как карты 102, 112, могут использовать компьютерную технологию с соответствующими инструкциями для того, чтобы осуществить описанные шаги вариантов способа по изобретению. В качестве следующего примера, терминалы 122, 124, 125, 126 могут содержать, среди прочих средств, коммуникационный модуль, антенну, связанную с коммуникационным модулем, память и, по меньшей мере, один процессор, связанный с памятью и с коммуникационным модулем и способный опрашивать бесконтактное платежное устройство (вместо антенны и коммуникационного модуля для опрашивания контактного платежного устройства, такого как контактная карта, или для считывания с магнитной полосы, могут быть использованы соответствующие контакты и другие элементы).

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

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

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

Кроме того, необходимо отметить, что любые описанные варианты способа могут включать дополнительный шаг создания системы, содержащей определенные программные модули, записанные в одной или более материальной машиночитаемой запоминающей среде. Все такие модули (или любая их часть) могут быть записаны в единственной среде; альтернативно, каждый модуль может быть записан в отдельной среде. Данные модули могут включать любой или все компоненты, представленные на чертежах (например, платформы представления счетов и/или оплаты счетов, базы данных, такие как базы 520, 597 и/или пользовательские интерфейсы). В этом случае операции (шаги) вариантов способа могут выполняться, как это было описано выше, с использованием дискретных программных модулей системы, загруженных в один или более аппаратных процессоров. При этом компьютерный программный продукт может содержать материальную машиночитаемую запоминающую среду с записанным в ней кодом, выполняемым на одном или более операциях вариантов описанного способа, включающего в данном случае обеспечение системы с дискретными программными модулями. Эти компьютеры могут быть подключены, например, к одной или более сетей 210, к другой виртуальной частной сети (VPN), к Интернету, локальной сети и/или распределенной сети (LAN и/или WAN) через слой электронного интерфейса данных. Компьютеры могут быть программируемыми, например, с использованием компиляторов, интерпретаторов, объектно-ориентированных, ассемблерных и/или машинных языков, например, одного или более из языков: С, C++, Java или Visual Basic (данный список является иллюстративным и неограничивающим). Могут быть использованы также, например, язык Extensible Markup Language (XML), известные прикладные программы, такие как приложения реляционной базы данных, электронные таблицы и аналогичные средства. Компьютеры могут быть запрограммированы для реализации логики и/или потоков данных, проиллюстрированных на чертежах.

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

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

Воспроизведение релевантных частей предварительной заявки США №61/438, 106

Далее приводятся части предварительной заявки США №61/438, 106. В нумерацию фигур и цифровые обозначения внесены необходимые изменения, чтобы избежать путаницы с предыдущим описанием и фиг.1-10. Данный материал приводится, чтобы проиллюстрировать для специалиста один тип платформы 540 оплаты счетов, пригодной для использования в одном или более вариантах изобретения. В случае какого-либо противоречия в определениях или терминологии между данным материалом и предыдущим текстом этот текст имеет преимущество.

Один или более вариантов обеспечивают процессинг платежей (например, электронный перевод денежных средств, "EFT") в пакетном режиме, редактирование информации, полученной от инициаторов платежей, чтобы обеспечить полноту данных, информирование системы расчетов (например, управляемой и/или обеспечиваемой оператором платежной сети, таким как MasterCard International Incorporated, США) или биллинговой системы (например, управляемой и/или обеспечиваемой оператором платежной сети, таким как MasterCard International Incorporated, США) и предоставление информации о переводе денег заинтересованной стороне, например концентратору, представляющему биллера.

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

- Онлайновый указатель биллеров/кредиторов - содержит важные настраиваемые параметры процессинга, которые используются для успешного редактирования платежей и процессинга в платежной машине;

- CSR Tool (инструмент генерирования запроса на подпись сертификата);

- онлайновые средства анализа для платежного центра на базе электронного сервиса.

Далее будет описан неограничивающий вариант архитектуры системы. Как показано на фиг.11, входной препроцессор ВР4 оплаты счетов (обозначенный, как 1504) получает данные в режиме GFT (например, от внешнего участника 1502). После проверки целостности файла и содержащихся в нем данных препроцессор передает поля уровня файла процессору 1506 правил оплаты счетов. Эти поля запоминаются в реляционной базе 1508 данных по оплате счетов, причем производится их валидация (проверка действительности). Если в результате валидации уровня файла он получает статус акцептованного, препроцессор 1504 передает пакет данных (в котором содержатся также части транзакции) в последовательном режиме процессору правил оплаты счетов. Снова производится сохранение полей в реляционной базе данных по оплате счетов и их валидация. По завершении процесса реляционная база данных содержит все данные, необходимые, чтобы выслать файлы подтверждения, перевода, расчета 1510, биллинга 1512, хранилища 1514 данных, модуля 1516 голосового ответа (VRU) и платежного центра 1518. Одно из заключительных действий, выполняемых процессором правил оплаты счетов, состоит в отправке сообщения о том, что имеются транзакции, доступные для дальнейшего процессинга.

Как показано на фиг.11, система 1520 оплаты счетов взаимодействует с приложением ВР4 (1504) и осуществляет коммуникацию посредством сообщений 1522 типа MQ Series® (зарегистрированный товарный знак фирмы International Business Machines Corporation, США). При этом в неограничивающем варианте база 1508 данных по оплате счетов построена на основе базы данных ORACLE® (зарегистрированный товарный знак фирмы Oracle Corporation, США). В других случаях могут использоваться иные форматы сообщений и/или программы базы данных.

На фиг.12 представлен пример оплаты счетов приложения и информационные потоки применительно к движению EFT-файла и транзакции при оплате счетов. Показаны, в частности, точки соприкосновения между ВР4 и процессорами оплаты, а также взаимодействие с MQ-сообщениями.

Далее будут рассмотрены процессоры оплаты счетов.

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

В неограничивающем примере демон-процессор 1650 может принимать от входного препроцессора ВР4 сообщения-запросы трех типов:

- сообщение в виде физического файла;

- сообщение в виде логического файла/файла сообщения;

- пакетное сообщение.

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

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

Процессор 1652 очереди группы подтверждений читает внутреннее рабочее сообщение от очереди подтверждений, получает ИД файла и начинает процессинг очереди подтверждений.

Процессор 1654 очереди группы переводов читает внутреннее рабочее сообщение от очереди переводов, получает ИД файла и начинает процессинг очереди переводов.

Процессор 1656 работ немедленного выполнения читает внутреннее рабочее сообщение от очереди работ немедленного выполнения, получает ИД файла, начинает процессинг срочной очереди. Этот процессор посылает сообщение, когда он идентифицировал работу, которая должна быть выполнена "прямо сейчас".

Демон-планировщик 1658 активируется периодически и проверяет таблицу заданий, чтобы проверить, имеются ли какие-либо задания, требующие немедленного выполнения. Если да, он посылает процессору-органайзеру 1660 исходящих сообщений приведенное ниже сообщение о готовности, не имеющее атрибутов, и помещает его в очередь 1799 готовности к отправке (см. фиг.13).

<тип внутренней работы = "Начать отправку">

</внутренняя работа>

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

<внутренняя работа> (с атрибутом <поле входящее>)

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

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

Процессор-генератор 1662 исходящих сообщений читает сообщения, находящиеся в очереди готовности, сформированной процессором-органайзером. Если имеется сообщение о готовности к отправке, процессор 1662 начинает генерировать исходящие данные и помещает их, в порядке очередности, в таблицы исходящих данных. Затем он считывает данные из этих таблиц и генерирует сообщение (сообщения) с запросом на работу для ВР4 1504.

Процессор операций после отправки переводов обозначен, как 1664. Процессоры системы оплаты счетов предпочтительно общаются друг с другом, используя формат внутреннего рабочего объекта. Когда процессинг определенного процесса завершен, процесс может поставить внутреннее рабочее сообщение в очередь, и после прочтения этого сообщения начнется процессинг другого процесса, отслеживающего сообщения в очереди. Так, входной процесс будет генерировать внутренние рабочие объекты и ставить сообщения в очередь подтверждений, очередь переводов или срочную очередь - см. также фиг.15, где показано, что слежение за списком 1440 заданий (планом) используется, чтобы генерировать отчеты, организовывать расчеты и биллинг и формировать исходящие (см. блоки 1901, 1903, 1905 и 14 соответственно на фиг.15). Далее приводятся сведения по примеру, относящемуся к типам очередей MQ-сообщений.

Очереди входящих MQ-сообщений по оплате счетов в ВР4 включают (см. фиг.13):

- очередь 1771 запросов - логическую очередь, соответствующую рабочим сообщениям на входе ВР4 1504 для процессинга в системе 1520 оплаты счетов;

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

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

- очередь 1777 дефектных ответов - используется, если ВР4 не получает сообщение в ожидаемом им (правильном) формате (если это происходит, ВР4 может поместить ответ системы оплаты счетов в эту очередь).

Очереди исходящих MQ-сообщений по оплате счетов в ВР4 включают:

- очередь 1779 запросов по исходящим сообщениям - логическую очередь, соответствующую сообщениям с запросами на выполнение работы, формируемыми выходным процессом по оплате счетов (ВР4 1504 забирает сообщения из этой очереди и готовит исходящий файл, который должен быть послан потребителю);

- очередь 1781 ответов по исходящим сообщениям - логическую очередь, соответствующую сообщениям-ответам на указанные запросы, посылаемым препроцессором ВР4 1504;

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

- очередь 1785 дефектных ответов по исходящим сообщениям - логическую очередь, в которой находятся посланные ВР4 1504 дефектные ответы на сообщения с запросами на выполнение работы.

Очереди во внутренних потоках работ включают:

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

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

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

- срочную очередь 1790 - внутреннюю очередь, которую также используют для процессинга внутренней работы в рамках оплаты счетов (сообщения в нее помещают в порядке очередности для считывания и процессинга посредством процессора 1656 для срочной очереди);

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

Диспетчер 1791 работ будет рассмотрен далее.

Примеры компонентов поддержки оплаты счетов включают постпереводной скрипт 1668, который генерирует файл полного расчета (settlement in full, SIF) и аккумулирует статистику по биллингу.

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

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

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

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

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

В одном или более вариантах используется программа Фокус (Focus), чтобы определить тип записи, основываясь на поле 1 в записи деталей транзакции/добавлений в комбинации с типом исходной (родительской) записи в иерархии файловой структуры.

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

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

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

Один или более вариантов используют вход, инициированный клиентом (customer-initiated entry, CIE), и поисковую таблицу для описания пакетного входа, которая определяет правильные входы и приписывает ИД каждому пакету, имеющему описание: -ПЛАТЕЖ RPS', 'ОТМЕНА', 'ВОЗВРАТ, 'RPS SDAY', 'ИСКЛЮЧЕНИЕ' и -Е-ПЛАТЕЖ'. Как и раньше, ссылки на систему RPPS не являются ограничивающими.

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

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

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

Блок интервала дат выдает различные временные интервалы, требуемые для приложения.

В некоторых случаях целесообразно проверять, совместим ли формат входящих с форматом исходящих у биллера. В некоторых вариантах все форматы совместимы друг с другом, за исключением того, что с биллерами, которые принимают исходящие пакеты АСН-СТХ (СТХ = Corporate Trade Exchange), должны быть ассоциированы входящие пакеты АСН-СТХ. В других случаях могут быть реализованы иные подходы.

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

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

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

На фиг.14 проиллюстрированы пример потока данных о деталях транзакции в системе и длительность хранения этих деталей. В других вариантах могут применяться иные подходы. Входящий платежный файл поступает от внешнего участника 1502 в ВР4 1504 системы. ВР4 регистрирует сообщения о транзакциях (блок 1898) и поддерживает свою базу 1899 данных для аудита файла и/или пакета. В некоторых вариантах части транзакции в базе 1899 данных не сохраняются. Отправка пакета сообщений, относящихся к фоновым потокам работ, и подтверждений этих сообщений отражена в блоках 1897, 1896 соответственно (см. также блок 1522 на фиг.11). Как показано в блоке 1895, система 1520 направляет загрузчику 1894 хранилища данных части транзакции, которые должны быть сохранены в хранилище 1514 данных. База 1508 данных по оплате счетов содержит части аудита файла и/или пакета, параметры оплаты счетов и части транзакции. В некоторых вариантах данные хранятся здесь в течение ограниченного периода (см. блок 1869). Внутреннее сообщение 1892 о переводе обеспечивает, в частности, электронный перевод 1891 денежных средств (EFT). Соответствующие обновления статуса направляются обратно в систему 1520 (см. блок 1899). Внутреннее сообщение 1888 о переводе посылается в ВР4 1504; исходящие файлы переводов были обработаны в блоке 1654 (фиг.12), а файлы подтверждения - в блоке 1652. Как показано в блоке 1893, параметры EFT 1891 могут быть синхронизированы с системой 1520 и/или включены в сообщения. База 1890 данных EFT включает данные аудита, параметры EFT и части транзакции. В некоторых вариантах данные (как показано в блоке 1868) сохраняются здесь в течение ограниченного периода. Файл SIF соответствует блоку 2216.

Потоки данных в ядре системы оплаты счетов иллюстрируются на фиг.15. В одном или более вариантах важные исходящие компоненты включают:

- процессор 1930 начала дня;

- потоки работ сообщений (рассмотренные в другом месте);

- процессор-планировщик 1658, 1660, 1662 исходящих сообщений;

- процессор файлов подтверждений (см., например, процесс 1200, 1202 формирования очередей);

- процессор файлов переводов (см., например, процесс 10, 1302 формирования очередей);

- процессор 1932 конца дня

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

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

В рассматриваемом далее примере предельное значение кредита для участника устанавливается равным 1800 (специалисту будет понятно, что 1800 в этом контексте - это значение, а не цифровое обозначение). Как видно из следующей таблицы, 19.06.2008 у некоторого участника был особенно напряженный день, и ему пришлось временно увеличить предельную сумму. Служба поддержки увеличила эту сумму до 3000, но установила дату истечения на начало следующего дня. В качестве предельной суммы по умолчанию задано значение 1800. В этом случае процессы начала дня, выполнявшиеся 20,06.2008, обнаруживают, что срок для соответствующей строки истекает, так что третья строка обновляется, чтобы вернуть предельную сумму к нормальному значению.

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

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

- количество процессинговых дней в прошлом, которое будет указано в дубликате файла чека;

- ассоциирование типа формата с типом основных файлов (тип формата задается кодом в таблице FILE Format; тип основных файлов соответствует основному типу файлов GFT, используемому для передачи входящего файла, имеющего подобный формат, в частности, оператору процессинговой сети, например фирме MasterCard International, США);

- назначение: центральный сайт;

- список исключенных дублирующих файлов.

Компоненты 14, 16, 18, 20, 1901, 1903, 1905, 1990, 1440, 1442 и 1444 на фиг.15 будут рассмотрены далее.

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

В одном или более вариантах, по завершении валидации бизнес-правил (в блоке 3001), в поток работ направляются три сообщения:

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

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

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

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

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

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

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

- "Исходящий физический файл готов" - блок 3013. Это сообщение информирует, что требуется послать физический файл одному или более участникам 1502 процесса оплаты счетов. Система оплаты счетов в типичном варианте задержит посылку следующих аналогичных сообщений до получения ответа на сообщение с описанием соответствующего физического файла. Данные, включенные в это сообщение, могут, например, включать:

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

- параметры протокола ICA для получения файла;

- конечная точка для получения файла;

- основной тип, приписанный физическому файлу.

- "Исходящий логический файл готов" - блок 3015. Это сообщение информирует, что участнику 1502 процесса оплаты счетов должен быть послан логический файл. Система оплаты счетов должна отложить отправку других сообщений о логическом файле до получения ответа на это сообщение. В сообщении содержатся, например, следующие данные:

- Количество пакетов, которые подлежат посылке постпроцессору и должны быть упакованы в единственный логический файл.

- Ссылку на физический файл, в который должен быть включен логический файл.

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

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

- ссылку на ассоциированный логический файл;

- исходящий формат, к которому должны быть приведены данные до отправки конечному получателю;

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

- объект, имеющий общепринятый формат и содержащий данные для полей регистрации пакета и транзакции.

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

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

- ожидающий (значения сохранены, но не прошли валидацию в отношении бизнес-правил);

- отложенный (значения сохранены, но валидация отложена до появления окна обслуживания);

- прошел валидацию (валидация в отношении бизнес-правил завершена - все коды ошибок приписаны);

- в очереди для подтверждений (файл и уровень пакета);

- в очереди для переводов (только уровень пакета).

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

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

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

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

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

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

Ниже приводится вариант результирующей таблицы 1202.

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

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

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

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

Ниже приводится вариант результирующей таблицы 1302.

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

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

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

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

- "немедленно" - выходной процесс инициируется сразу же по завершении входного процесса для каждого файла;

- "частота" - выходной процесс инициируется заданное количество раз в день (определяемое временными интервалами в минутах или в других единицах), начиная с определенного момента и в течение всего процессингового дня до наступления другого момента (например, каждые 2 ч с 11:00 и до 20:00);

- " время" - выходной процесс инициируется в заданные моменты (например, в 12:00, 17:00 и 20:00).

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

Ниже приводится пример параметров планирования.

В некоторых случаях с таблицей планирования ассоциируется следующая конфигурационная таблица.

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

В неограничивающем примере по фиг.20А процесс 1930 начала дня создает план (расписание) 1440 на текущий день. Данный процесс, выполняемый в начале каждого процессингового дня, создает расписание на основе параметров 1990 планирования. План определяет, что сегодня нужно сделать, для кого и когда. Пример данных, определяющих план на день, приведен на фиг.20 В. В некоторых случаях сводный план на текущий день генерируется 1 раз в процессе начала дня. Однако объекты с отметкой "немедленно" обычно не могут быть внесены в план, пока реально не поступят ассоциированные с ними входящие файлы. Поэтому в течение процессингового дня будут добавляться строки для указанных объектов как события с временем выполнения, соответствующим текущему времени.

Если требуется динамическое планирование переводов, эти объекты также вводятся в таблицу дневного плана с аналогичными параметрами.

В одном или более вариантах допустимые значения статуса в списке заданий. таковы:

- ожидающее - начальный статус каждого задания;

- в очереди - включен в очередь на процессинг "прямо сейчас" - демон-планировщик идентифицировал задание как готовое к выполнению;

- начато - задание выполняется: начато построение выходного процесса, т.е. сборки деталей транзакции, ассоциированных с заданием;

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

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

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

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

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

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

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

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

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

В данном примере следующие задания подлежат выполнению "сразу сейчас":

- направить исходящий файл подтверждения для участника Р1 в конечный пункт Е1, используя тип основного файла В0;

- направить исходящий файл перевода для участника Р1 в конечный пункт Е1, используя тип основного файла В0;

- направить исходящий файл перевода для участника Р2 в конечный пункт Е2В, используя тип основного файла В0.

- и т.д.

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

В одном или более вариантах допустимыми значениями в таблице статуса заданий являются:

- ожидающее;

- начатое(или в очереди);

- завершенное.

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

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

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

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

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

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

На фиг.22 иллюстрируется пример инициирования списка заданий при наличии событий, выполняемых во время "окна". Процессинг начинается на шаге 1802. На шаге 1604 принятия решения определяется, продолжается ли еще процессинг предыдущего списка заданий. По ветви ""НЕТ"" происходит переход на шаг 1606, коррелирующий задания, выполняемые немедленно, с параметрами исходящих участника, чтобы получить список заданий, подлежащих постановке в очередь на процессинг. Затем, на шаге 1608, изменяют статус "в очереди" заданиям, готовым к процессингу, и переходят на шаг 1610. На этом шаге определяется, имеются ли в данный момент какие-либо события для процессинга в режиме окна. При переходе по ветви "НЕТ" на шаге 1618 посылается сообщение, что исходящие очереди готовы, и процесс завершается на шаге 1620. Если же на шаге 1604 было определено, что процессинг предыдущего списка заданий еще продолжается (переход по ветви "ДА"), процесс переходит прямо на шаг 1620.

Если шаг 1610 выдает "ДА", происходит переход на шаг 1612 и выбираются все входящие файлы со статусом "ожидающий". Затем, на шаге 1614, выдерживается пауза до завершения валидации всех пакетов для этих файлов. На шаге 1616 выдерживается пауза, пока не будут поставлены в очередь подтверждения и переводы для всех выбранных файлов, с последующим переходом на шаг 1618.

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

На фиг.23 иллюстрируется пример процесса построения исходящих файлов. Когда будет сгенерирован список 1440 заданий и будут готовы пакеты 1446 подтверждений и пакеты 1448 переводов может быть начато построение исходящих файлов (логического 1442 и физического 1444). Этот процесс собирает все пакеты подтверждений и переводов 1446, 1448, ассоциированные с каждым заданием из списка, и формирует сообщения постпроцессору, который должен сгенерировать исходящие файлы (см. блок 14).

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

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

- нет;

- пустой файл;

- нулевая сумма.

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

- 'О' - соответствует исходному стилю RPPS (ссылки на RPPS приводятся в качестве неограничивающего примера; в других вариантах может, например, применяться похожий код для указания на какой-то другой стиль, например стиль, используемый в унаследованных системах, т.е. применяемых в настоящее время);

- 'F' - соответствует файлу подтверждения, в который включены все входные записи, разделенные запятыми;

- 'R' - соответствует файлу подтверждения, в который включены только записи об отклонениях, разделенные запятыми;

- 'М' - соответствует файлу подтверждения, который будет доступен через MOL и не должен автоматически высылаться системой оплаты счетов.

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

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

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

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

Далее в таблице приводятся примеры исходящего логического файла данных.

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

- наличие участника в таблицах очередей подтверждений и переводов;

- исходящий формат участника из таблицы конфигурации исходящих;

- тип исходящих из таблицы очередей подтверждений и переводов.

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

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

Этот процесс предпочтительно учитывает также следующие факторы.

- Модификатор ИД файла - этот атрибут логического файла используется для форматов MOD-CIE и ACH-CIE (CIE=вход, инициированный клиентом), чтобы получить уникальный модификатор для каждого файла от единственного участника в единственный календарный день.

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

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

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

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

На фиг.25 иллюстрируется процесс проведения полных расчетов с соответствующим потоком исходящих данных. Как часть процессинга в начале дня генерируется план 1440 на день, основываясь на запланированных параметрах. Этот план включает также сведения для создания файлов полного расчета (SIF). В некоторых случаях файлы SIF применительно к типу "исходящие переводы" будут создаваться только в период окна; для процесса расчетов будет создаваться отдельная запись. В период, соответствующий окну, после завершения процессинга переводов демон-планировщик 1658 начнет процесс расчетов, который приведет к созданию файлов SIF. Эти файлы будут генерироваться параллельно с созданием исходящих файлов.

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

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

Для версии 3 SIF реферальный код аккаунта стороны платежа является обязательным полем. Это поле может быть получено из MPS-параметра системы. Эта ситуация является уникальной для комбинации расчетный сервис - сторона платежа. Профиль данного поля формируется в системе профилирования SAM и передается в систему MPS-параметров. Разумеется, те компоненты, которые являются обязательными в данном примере, в других вариантах могут быть опциями.

Будут доступны следующие MPS-таблицы (подключение DB2® (зарегистрированный товарный знак фирмы International Busuness Machines Corporation) к MPS-таблицам может быть установлено, например, от базы данных по оплате счетов):

- TGPABUD - имя бизнес-партнера - таблица бизнес-партнера;

- TGPAMSD - информация по расчетному сервису - входы источников, ассоциированных с распределением участников;

- TGPAXBD - ИД трансфертного агента - поручения трансфертному агенту.

Логические части значений инициатор/концентратор представлены в приведенной ниже таблице для кода направления:

В неограничивающем примере код типа "04" для стороны платежа всегда сочетается с кодом направления "S," а код типа "05" для стороны платежа - с кодом направления "R". Это зависит от того, кто является отправителем или получателем реальной транзакции. Код дебет/кредит зависит от направления движения денежных средств. Так, для всех платежных транзакций он соответствует дебету для инициатора и кредиту для концентраторов. Инициатором применительно к платежным транзакциям является отправитель, что соответствует коду направления 'S', а концентратором является получатель денежных средств, что соответствует коду направления 'R'.

В ходе процесса SIF в таблицу статуса SIF вводится запись, соответствующая единственному файлу SIF. Серийный номер файла SIF - это уникальное число, приписываемое каждому физическому файлу SIF в последовательном порядке, начиная с 1 и возвращающееся к ней по достижении 99999. Этот параметр может использоваться для отслеживания индивидуальных файлов. Серийный номер файла используется также в процессе подготовки уведомлений о расчетах (SINF), чтобы идентифицировать статус файла. Кроме того, в одном или более вариантах релевантные подробности полного расчета (SIF) приводятся в таблице деталей SIF. Эта таблица может быть использована для генерирования отчетов по полному расчету. Более подробные сведения приводятся в двух таблицах на фиг.26.

В одном или более вариантах файлы SIF будут передаваться в систему SAM с использованием крупных внутренних файлов в формате GFT. Поскольку GFT предусматривает сохранение файлов по умолчанию, физические файлы в системе оплаты счетов сохраняться не будут. В других вариантах могут применяться иные подходы.

После процессинга файлов SIF система SAM будет генерировать соответствующие файлы уведомлений о расчетах (SINF). Файл SINF будет передаваться системе оплаты счетов с использованием внутреннего основного типа файлов в GFT. Будет создано новое TWS-задание, которое будет активировано при поступлении файла SINF в определенное место указателя. Процессинг файлов SINF будет выполнен в системе оплаты счетов с заданием статуса возврата. Этот статус сохраняется, и при появлении ошибок будет сделана запись "неустранимая ошибка" и сгенерировано (например, с помощью программы IBM Tivoli® (зарегистрированный товарный знак фирмы International Business Machines Corporation)) уведомление для немедленного привлечения внимания группы поддержки системы оплаты счетов. В иных вариантах могут быть применены иные подходы.

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

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

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

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

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

- как часть ПКД, должны быть сгенерированы потребности в информации для хранилища 1514 данных;

- должна быть сгенерирована требуемая информация для биллинга 1512 и направлена биллинговому приложению;

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

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

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

Процесс биллинга создаст и отправит приложению MCBS следующие файлы:

a) отправитель биллинга - для всех акцептованных транзакций это детали биллинговых данных для отправки ИД ICA/RPPS;

b) получатель биллинга - для всех акцептованных транзакций это часть биллинговых данных для получения ИД ICA/RPPS;

c) отказ в биллинге - для всех отклоненных транзакций это часть биллинговых данных для отправки ИД ICA/RPPS;

d) аудит - содержит сводку посланных/полученных/отклоненных файлов биллинга.

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

Разработка VRU (модуля голосового ответа)

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

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

В неограничивающем примере процесс верификации того, что звонки по VRU были завершены, может быть реализован с помощью скрипта Peri, который запускается посредством задания TWS SRPS0011D в 06:30 с понедельника до субботы. Если не остались строки от циклов предыдущего дня или если эти строки не содержат ключа 'звонок завершен', установленного на 'Y', будут посылаться электронные сообщения в Службу помощи RPPS и на страницу RPPS "Поддержка аккаунта". Если звонки, действительно, не прошли, "Поддержка аккаунта" осуществит звонки вручную и проведет обновление сводной таблицы VRU посредством инструмента CSR.

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

На фиг.28 представлена блок-схема высокого уровня для примера процесса 2200 преобразования портфеля. На этапе 2202 подключения концентраторы 2204 и/или биллер предоставят группе 2206 поддержки информацию, необходимую для регистрации и/или подключения биллера к сервису. Это можно осуществить, например, в блоке 2208 поддержания параметров.

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

В процессе 1930 распределения обязанностей (segregation of duties, SOD) в рамках преобразования портфеля аккаунтов нужно активировать регистрацию для всех регистрации файлов, имеющих дату начала, совпадающую с сегодняшним днем, и инактивировать регистрацию для всех регистрации файлов, имеющих дату окончания, совпадающую с сегодняшним днем.

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

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

Что касается SIF 2216, в некоторых случаях процесс создания файла SIF при преобразовании транзакции учитывает детали ИД/1СА нового биллера и/или концентратора в системе RPPS.

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

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

На фиг.29 представлена блок-схема высокого уровня для примера потока 2300 работ для стоп-файла. На этапе 2202 подключения концентраторы и/или биллер предоставят группе 2206 поддержки информацию, необходимую для регистрации и/или подключения биллера к сервису. Это можно осуществить, например, в блоке 2208 поддержания параметров. На шаге 2210 биллер меняет своего концентратора. Если в этом процессе происходит изменение биллера и/или концентратора или даты начала, следует инактивировать существующие взаимодействия и установить новые. В процессе 1930 SOD нужно активировать регистрацию для всех регистрации стоп-файла, имеющих дату начала, совпадающую с сегодняшним днем, и инактивировать регистрацию для всех регистрации стоп-файла, имеющих дату окончания, совпадающую с сегодняшним днем. В блоке 2312 входящих стоп-файлов для аккаунтов производится валидация параметров этих файлов и их загрузка в базу 1508 данных. Во время процессинга 2214 платежей следует ввести дополнительные бизнес-правила для стандартных платежных транзакций, чтобы идентифицировать концентратора (концентраторов) и/или биллера (биллеров), зарегистрировавшихся для сервиса в отношении стоп-файла. При осуществлении процесса SBF поддерживаются ежемесячные выплаты, оплаты загрузки файла, загрузки аккаунта и преобразования портфеля транзакций в составе счетов на уровне подключения биллера.

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

Что касается архитектуры процесса, в некоторых случаях приложение по оплате счетов построено на основе технологии Java 5 и будет работать на серверах высокого уровня, использующих систему UNIX. Система рассчитана на использование в автономных виртуальных машинах JAVA (JVM), в исполнительной среде JAVA 5. Для использования при разработке были выбраны следующие компоненты и интерфейсы прикладного программирования (application program interface, API); в других случаях могут использоваться другие их варианты:

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

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

Примером пространства имен JAVA, которое может быть использовано в качестве корневого пакета для классов в приложении по оплате счетов, является:

com.acme.billpay/

Примером пространства имен JAVA, которое может быть использовано для классов, специфичных для входного демона-процессора, является:

com.acme.billpay. inbound/

Примером пространства имен JAVA, которое может быть использовано для классов, специфичных для процесса постановки в очередь подтверждений, является:

com.acme.billpay.confirmation

Примером пространства имен JAVA, которое может быть использовано для классов, специфичных для процесса постановки в очередь переводов, является:

com.acme.billpay.remittance/

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

com.acme.billpay.daemon. BillpayDaemonProcess

В неограничивающем примере данный процесс загружает фабрику бинов в фреймворке Spring, используя класс SingletonBeanFactoryLocator, который будет производить поиск файла "beanRefFactory.xml" в пути корневого класса. Он также инициализирует все стартап-приложения компонентов, которые должны быть инициализированы при запуске демон-процесса.

Дополнительные сведения содержатся в приведенной таблице и на фиг.30.

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

Один или более вариантов включает Диспетчер 1791 работ по оплате счетов. Главная обязанность этого компонента состоит в распределении объектов внутренних работ по нескольким внутренним очередям согласно спецификации конфигурации. Например, после того как входящий процесс 1650 осуществил валидацию своих входных данных, он генерирует внутреннее рабочее сообщение для постановки во внутренние очереди процесса. Другой обязанностью данного компонента является построение объектов внутренних работ, основываясь на конфигурации потоков работ (представленной в виде карты пар ключевых значений (имени очереди и InterWorkType)), а также на значениях, конфигурируемых через фреймворк Spring. Значения должны соответствовать константам "enum", определенным в классе InterWorkType.

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

Один или более вариантов содержат компонент подтверждения при оплате счетов (см., например, блок 1200); компонент переводов при оплате счетов (см., например, блок 10) и/или компонент для генерирования исходящих файлов при оплате счетов (см., например, блок 14).

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

com.acme.billpay.util.CommonUtils

(см. также фиг.31).

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

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

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

Error message

Work ID, file ID, Batch ID (в зависимости от применимости)

Stack trace

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

В неограничивающем примере для легирования в журнал приложения выбраны следующие уровни легирования/приоритетности:

Далее приводятся пояснения некоторых терминов, использованных в описании

- НЕФИНАНСОВЫЕ ПЛАТЕЖИ - позволяют как инициатору (например, в рамках системы типа RPPS), так и концентратору и/или биллеру обмениваться информацией по неплатежной транзакции, требующей какого-либо действия на получающей стороне, например изменения номера аккаунта.

- ОТМЕНЫ (REVERSALS) - позволяют инициаторам (например, в рамках системы типа RPPS) отменить любую платежную транзакцию, которая была ошибочно направлена концентраторам и/или биллерам, например дубликат платежа, представленного потребителями, или дубликат файла, посланного инициатором. Эта операция в некоторых случаях включает процессинг превышения дебета.

- ВОЗВРАТЫ и ОТМЕНЫ ВОЗВРАТОВ - позволяют концентратору и/или биллеру (например, в рамках системы типа RPPS) возвратить любую платежную транзакцию или отмену транзакции, направленной инициаторам, вследствие "нефункционирующей связи" на стороне биллера. Это может быть, например, вызвано закрытием аккаунта или ошибкой в аккаунте. Данная операция в некоторых случаях включает обработку возвратов от платежного центра посредством дополнения записи.

- ПРЕОБРАЗОВАНИЕ ПЛАТЕЖЕЙ для подключения ПРЕОБРАЗОВАНИЯ ПОРТФЕЛЯ - применяет средство Product Feature к стандартной платежной транзакции, чтобы идентифицировать концентратора и/или биллера, зарегистрировавшегося для преобразования портфеля, и изменяет имя биллера и номер аккаунта для процессинга.

- ОСТАНОВКА ПЛАТЕЖА ДЛЯ АККАУНТА СО СТОП-ФАЙЛОМ - применяет к платежной транзакции дополнительные бизнес-правила, чтобы идентифицировать концентратора и/или биллера, зарегистрировавшегося для сервиса по стоп-файлу.

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

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

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

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

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

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

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

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

Оператор процессинговой сети осуществляет по меньшей мере одно из следующих действий:

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

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

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

периодическая рассылка и рассылка по меньшей мере в одно заданное время.

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

В некоторых случаях по меньшей мере одна из следующих операций:

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

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

В некоторых вариантах генерируемый периодический план является ежедневным планом.

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

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