Файловая структура для упрощения реструктуризации учетной записи в системе электронных платежей - RU2540814C2

Чертежи

Показать все 11 чертежа(ей)

Описание

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

Датами приоритета для данной заявки являются 14.11.2008 (дата подачи предварительной патентной заявки США №61/114508) и 12.11.2009 (дата подачи патентной заявки США №12/617071). Содержание указанных патентных заявок США, а также патентной заявки США №11/829988 (опубликованной 21.02.2008 как патентная заявка США №20080046364) полностью включено в данное описание посредством ссылки в полном объеме и для всех случаев, разрешенных законом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.3 приведен пример записи заголовка файла данных об изменении учетной записи эмитента в текущем формате файла автоматического обновления по биллеру (automatic biller update, ABU).

На фиг.4А и 4В представлен пример области данных в файле данных об изменении учетной записи эмитента.

На фиг.5А и 5В иллюстрируется текущий формат файла RPPS для преобразования портфолио клиента.

На фиг.6 представлен пример процесса.

На фиг.7 представлен пример элементов данных для комбинации преобразования учетной записи и файла ABU согласно аспекту изобретения.

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

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

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

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

Способ может включать шаг 116 получения файла данных, указывающего на реструктуризацию учетной записи определенного получателя 102. Файл данных определяет по меньшей мере один старый номер учетной записи, ассоциированный с данным получателем, и по меньшей мере один новый номер учетной записи, ассоциированный с тем же получателем (в частности, новых номеров учетных записей, ассоциированных с получателем, может быть несколько). Способ может также включать помещение (например, на шаге 122) старых и новых номеров учетных записей получателя в структуру преобразования данных, построенную в формате, облегчающем преобразование номера учетной записи (такой структурой может быть, например, таблица преобразования). Далее, способ может также включать получение данных о перечислениях от определенной участвующей стороны (шаги 128, 130). Данные о перечислениях могут, например, включать платежи и/или аннулирования от одного или более инициаторов платежа (см. шаг 128). Данные о перечислениях могут также включать, в дополнение к платежам и/или аннулированиям или вместо них, подтверждения от получателей (см. шаг 130). Данные о перечислениях, как правило, включают указание старого или нового номера учетной записи получателя. Так, платежи или аннулирования инициатора оплаты могут включать старый номер учетной записи, который должен быть преобразован в новый номер учетной записи, тогда как подтверждения от получателей могут включать новый, уже преобразованный номер учетной записи, который нуждается в обратном преобразовании, чтобы избежать путаницы у инициатора платежа.

Способ может также включать шаг маршрутизации данных о перечислениях в соответствии с имеющимся старым или новым номером учетной записи получателя и структурой данных. Один вариант маршрутизации (проиллюстрированный в блоках 126, 132, 134, 138 и 140) будет подробно рассмотрен далее. Данные о перечислениях потенциально могут быть направлены по более чем одному адресу. Шаг маршрутизации может включать маршрутизацию платежа и/или аннулирования на единственный новый номер учетной записи, ассоциированной с получателем. Этот номер может соответствовать, например, новой учетной записи получателя или номеру учетной записи третьей стороны, т.е. правопреемника счетов к получению первоначального получателя. Как было отмечено, в дополнение к информации о номере учетной записи данные о перечислениях могут включать идентификационные данные, такие как ИД биллера (включающий, при широкой трактовке, идентификацию биллера или концентратора). Вышеупомянутый файл данных может задавать новый идентификатор получателя, идентифицирующий третью сторону, такой как новый ИД биллера, идентифицирующий правопреемника.

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

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

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

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

Далее будут приведены дополнительные данные о маршрутизации, которая может включать, например, проверку данных о перечислениях (на шаге 126), чтобы определить (на шаге 132), содержится ли в структуре данных старый номер учетной записи получателя или новый номер учетной записи получателя. Кроме того, маршрутизация может включать выполнение преобразования (на шаге 134). Это преобразование может, например, включать идентифицирование платежных данных о перечислениях, направленных на новый номер учетной записи получателя (когда данные о перечислениях содержат старый номер), или старого номера учетной записи получателя (когда данные о перечислениях содержат новый номер) при условии, что старый номер учетной записи получателя содержится в структуре данных в ассоциации с новым номером его учетной записи или новый номер учетной записи получателя содержится в структуре данных в ассоциации со старым номером его учетной записи. Так, для платежа и/или аннулирования от инициатора платежа (шаг 128) старый номер учетной записи может быть преобразован в новый номер учетной записи с направлением платежа по адресу правильной учетной записи получателя (см. шаг 140). В то же время применительно к подтверждениям 130 от получателя новый номер учетной записи может быть преобразован в старый номер учетной записи для отсылки инициатору платежа (см. блок 138), чтобы не создать путаницы у инициатора платежа при получении подтверждения. Следует отметить, что если старый ИД биллера и старый номер учетной записи в таблице не обнаружены (ветвь "НЕТ" от блока 132), платеж и/или аннулирование просто посылаются ("старому") получателю (см. шаг 142). Аналогично, подтверждения, для которых данные в таблице преобразования отсутствуют, могут обрабатываться обычным способом.

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

Другой дополнительный шаг способа может включать повторение шага 116 получения файла данных, шага 122 помещения файла в структуру, шага 126 получения данных о перечислениях и шага (точнее, шагов 132, 134, 138, 140) маршрутизации данных для по меньшей мере второго файла данных, содержащего сведения о реструктуризации учетной записи по меньшей мере еще одного получателя (например, когда реструктуризация требуется для нескольких получателей, таких как получатели 102 и 104). В другом аспекте могут быть повторены шаг 126 получения данных о перечислениях и шаги (например 132, 134, 138, 140) маршрутизации данных по меньшей мере для второго файла данных о перечислениях от по меньшей мере еще одного из инициаторов платежа (например, если многие инициаторы платежа все еще используют старый номер учетной записи).

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

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

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

Технологии согласно изобретению могут быть использованы с любыми типами систем электронной оплаты счетов. В одном или более вариантов эти технологии могут применяться с электронной платежной системой MASTERCARD RPPS® фирмы MasterCard International Incorporated, США. Так, изобретение может обеспечить, например, эффективное решение проблем маршрутизации платежей и передачи сообщений, неизбежных при полных или частичных преобразованиях портфолио. В число биллеров могут входить, например, эмитенты платежных карт, телекоммуникационные или энергетические компании. Им может потребоваться перевыпуск номеров учетных записей пользователей в результате разделения портфолио, переходов учетных записей в результате слияний и приобретений, резких изменений в карточном портфолио и т.д. В одном или более вариантах может допускаться идентификация платежей, требующих преобразования номера учетной записи, преобразования платежей на новые номера учетных записей и изменения маршрутизации платежей от одного ИД биллера к другому

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

В другом аспекте варианты изобретения обеспечивают единый файл эмитента для таких программ, как MasterCard® Automatic Billing Updater (ABU) и MasterCard® Remote Presentment and Payment (RPPS). В настоящее время программа MasterCard Automatic Billing Updater и Услуга по преобразованию учетных записей на основе программы MasterCard RPPS требуют, чтобы эмитенты и/или биллеры представляли отдельные соответствующие файлы, чтобы передать информацию об изменении учетной записи. Изобретение обеспечивает интегрирование требуемых элементов данных из обеих программ в новый единый (объединенный) файл. Варианты изобретения способны, например, предложить эмитентам единый подход к участию в обеих названных программах и/или повысить функциональную эффективность. Следует отметить, что программа MasterCard® ABU упоминается в данном описании и на чертежах только в качестве неограничивающего примера системы, осуществляющей регулярные платежные транзакции (например, для регулярных бескарточных платежей). Также следует подчеркнуть, что программа MasterCard® RPPS упоминается в данном описании и на чертежах только в качестве неограничивающего примера приложения, связанного с преобразованием учетных записей при электронном переводе (денежных) средств.

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

Программа MasterCard ABU требует, чтобы эмитенты имели установленные конечные коммуникационные пункты для выставления и приема единых файлов. Эмитенты или процессоры эмитентов создают и представляют "файл данных изменения учетной записи эмитента", чтобы известить об изменениях учетных записей программу MasterCard ABU. Должно быть понятно, что, как уже упоминалось, программа MasterCard ABU является неограничивающим примером системы и способа процессинга регулярных платежных транзакций, как это описано, например, в патентной заявке США №2009/0171839, озаглавленной "Системы и способы процессинга регулярных платежных транзакций", причем содержание этой заявки полностью включено посредством ссылки в данное описание для использования в любых целях. На фиг.3 приведен пример записи заголовка (колонтитула) файла данных об изменении учетной записи эмитента в текущем формате файла ABU. На фиг.4А и 4В представлен пример записи области данных в указанном файле.

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

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

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

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

В отношении программы ABU следует отметить, что при выписке, например, потребителями и/или продавцами счетов на карту, данные по которой имеются в базе данных (card-on-file), имеющаяся информация по карте может "залежаться". Поэтому программа ABU обеспечивает наличие автономной базы данных, которая позволяет эмитентам посылать оператору 608, 802 платежной сети 208 (рассматриваемой в другой части описания) файл с изменениями в номерах учетных записей и/или в дате истечения срока действия. Такие входящие сообщения эмитента могут поддерживаться в течение скользящего периода, например, составляющего 13 месяцев. Участвующие продавцы и/или их эквайеры ставятся в известность о новых данных. Как показано на фиг.6, на первом шаге 651 держатель 602 карты устанавливает с продавцом 604 отношения, предусматривающие регулярные платежи. На втором шаге 652 эмитент 606 обеспечивает держателя 602 новой или заменяющей картой, что означает изменение номера учетной записи и/или даты истечения срока действия. На третьем шаге 653 эмитент 606 посылает оператору 608 платежной сети вышеупомянутый файл, указывающий изменения в учетной записи, обусловленные, например, ее обновлениями и/или модификациями портфолио. Оператор 608 может направить эмитенту 606 соответствующий ответ с подтверждениями или указаниями ошибок. На четвертом шаге 654 обновленные данные посылаются оператором 608 эквайеру 610; например, в связи запросами, связанными с учетными записями, а также в связи с соответствующим ответом, включающим соответствия между запросами и записями, или с подтверждениями и/или указаниями ошибок. На пятом шаге 655 эквайер 610 передает запросы по учетным записям продавцу 604 с подтвержденными соответствиями между запросами. На шестом шаге 656 оператор 608 подготавливает сводные отчеты 612, 614 об активности эмитента и эквайера соответственно. Разумеется, в каких-то случаях данные шаги могут выполняться в другой последовательности.

Следует отметить, что все упоминания "MasterCard" соответствуют неограничивающим примерам оператора 608, 802 платежной сети 208, функционирующего согласно стандарту или техническим требованиям в отношении платежей. Примеры платежной сети включают варианты, сконфигурированные из условия облегчения транзакций между множеством эмитентов и множеством эквайеров, например виртуальные частные сети, такие как телекоммуникационная сеть BANKNET® фирмы MasterCard International Incorporated или сеть VISANET® ассоциации Visa International Service Association.

На фиг.9 показан вариант взаимосвязи различных лиц и организаций. Множество различных пользователей 202 (U₁, U₂ … U_N) взаимодействует с множеством различных продавцов 204 (P₁, P₂ … P_M). Пользователями 202 могут быть, например, владельцы (держатели) платежных карт. Продавцы 204 взаимодействуют с различными эквайерами 206 (A₁, A₂ … A_I). Эквайеры 206 взаимодействуют с различными эмитентами 210 (I₁, I₂ … I_J), например, через единственного оператора платежной сети (payment network, PN) 208, сконфигурированной так, чтобы облегчить транзакции между множеством эмитентов и множеством эквайеров. Примерами являются MASTERCARD International Incorporated, оператор сети BANKNET®, или Visa International Service Association, оператор сети VISANET®. В общем случае N, M, I и J - это целые числа, которые могут быть равны или не равны одно другому.

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

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

Как уже отмечалось, согласно аспектам изобретения предусматривается единственный файл данных, который содержит элементы данных, которые пригодны для использования в программе ABU и в базах данных для преобразования учетных записей. На фиг.7 представлен пример элементов данных для такой комбинации преобразования учетной записи и файла ABU. Запись "НОМЕР ИД/ИН КЛИЕНТА" соответствует идентификационному номеру клиента фирмы MasterCard и в широком смысле является примером идентификатора, такого, например, как алфавитно-цифровая последовательность.

На фиг.8 показано, как множество биллеров 826, 828 передают информацию об обновлении учетной записи концентратору или консолидатору (в общем случае финансовой организации, проводящей операцию 824 EFT). Финансовая организация осуществляет также карточную операцию 820. На шаге 822 финансовая организация объединяет информацию (например RPPS-типа - см. фиг.5А и 5 В) от биллеров 826, 828 и информацию по карточной операции (например ABU-типа - см. фиг.3, 4А и 4В) в единственный консолидированный файл с элементами, сформатированными, как показано на фиг.7, и посылает его оператору 802 платежной сети; например, используя систему MasterCard GFT (global file transfer, глобальная передача файлов) или схожую систему передачи файлов (см. блок 804). Затем оператор 802, используя консолидированный файл 806, задействует систему, такую как RPPS (см. блок 808), чтобы определить (см. блок 810 принятия решений), требует ли информация о преобразовании EFT-портфолио или аналогичная информация обновления преобразования учетной записи в блоке 812. Кроме того, оператор 802, используя консолидированный файл 806, задействует также другую систему, такую как ABU (см. блок 814), чтобы определить (см. блок 816 принятия решений), требует ли ABU-информация или аналогичная информация обновления в блоке 818.

Из предыдущего рассмотрения должно быть понятно, что способ согласно соответствующему аспекту изобретения включает шаг приема в процессе выполняемой финансовой организацией операции 824 платежа по счету посредством электронного перевода средств первой информации, отображающей реструктуризацию учетной записи биллера 826 или 828, который использует данную операцию. Этот шаг может выполняться, например, модулем оплаты счета посредством электронного перевода средств, запускаемым по меньшей мере на первом аппаратном процессоре. Программные модули будут рассмотрены далее. Дополнительный шаг 822 включает объединение первой информации и второй информации в файл с унифицированным форматированием, пример которого приведен на фиг.7. Этот шаг может выполняться, например, интегрирующим модулем, запускаемым по меньшей мере на первом аппаратном процессоре (в финансовой организации могут быть один или более аппаратных процессоров, так что эти шаги могут осуществлять одним и тем же или различными процессорами). Вторая информация имеет форматирование, отличное от форматирования первой информации. Вторая информация включает информацию для обновления карты (например, новый номер учетной записи карты или новую дату истечения ее срока действия), используемой при регулярных карточных платежах посредством платежных карт, эмитированных указанной финансовой организацией (например, при регулярной карточной операции 820). Следующий шаг 804 включает передачу файла с унифицированным форматированием оператору 608, 802 платежной сети 208, сконфигурированной из условия облегчения транзакций между множеством эмитентов 210 и множеством эквайеров 206. Эта операция также может выполняться интегрирующим модулем.

Неограничивающие примеры второй и первой информации приведены соответственно на фиг.3 и 4 и на фиг.5.

Дополнительный (необязательный) шаг 806 включает прием оператором платежной сети файла с унифицированным форматированием. Данный файл указывает по меньшей мере один старый номер учетной записи и по меньшей мере один новый номер учетной записи, ассоциированные с биллером 826 или 828. Другой предпочтительный, но необязательный шаг включает обеспечение оператором платежной сети функционирования системы регулярных платежных транзакций для осуществления регулярных платежей в режиме "карта не присутствует" в соответствии с файлом с унифицированным форматированием (см. шаги 814, 816, 818). Это может быть обеспечено путем обновления карточной информации для осуществления указанных регулярных платежей в указанном режиме в соответствии с указанным файлом. Еще один предпочтительный, но необязательный шаг включает реализацию оператором платежной сети приложения по преобразованию учетной записи при электронном переводе средств в соответствии с файлом с унифицированным форматированием (см. шаги 808, 810, 812). Это может быть осуществлено маршрутизацией платежей в соответствии с указанным файлом.

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

Маршрутизация платежа может осуществляться, как это было описано со ссылкой на фиг.1, например путем: помещения по меньшей мере одного старого номера учетной записи и по меньшей мере одного нового номера учетной записи, ассоциированных с биллером, в структуру преобразования данных в формате, облегчающем преобразование номера учетной записи (см. шаг 122); получения от инициатора оплаты счета платежных данных (включающих указание старого номера учетной записи биллера - см. шаг 128) и маршрутизацию платежных данных по новому номеру учетной записи биллера в соответствии со структурой преобразования данных (см. шаги 126, 132, 134, 138 и 140).

Обновление карточной информации может быть осуществлено, как это описано со ссылкой на фиг.6 и в вышеупомянутой заявке US 2009/0171839. Например, оператор 608, 802 платежной сети 208 доводит информацию для обновления карты до сведения эквайера 610, 206.

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

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

Далее, способ согласно другому аспекту изобретения включает шаг приема оператором платежной сети, сконфигурированной из условия облегчения транзакций между множеством эмитентов и множеством эквайеров, от финансовой организации файла с унифицированным форматированием (см. шаг 806). Файл с унифицированным форматированием указывает (как это было описано выше) по меньшей мере один старый номер учетной записи и по меньшей мере один новый номер учетной записи, ассоциированные с биллером 826 или 828. Файл с унифицированным форматированием относится к типу файлов, подготавливаемых финансовой организацией (как это было описано) посредством объединения первой информации, отображающей реструктуризацию учетной записи биллера (использующего операцию 824 оплаты счета посредством электронного перевода средств финансовой организацией) и второй информации. Вторая информация имеет форматирование, отличное от форматирования первой информации, и включает информацию для обновления карты, используемой при регулярных карточных платежах посредством платежных карт, эмитированных указанной финансовой организацией (например, при осуществлении карточной операции 820). Дальнейший шаг включает использование оператором платежной сети системы регулярных платежных транзакций для осуществления регулярных платежей в режиме "карта не присутствует" в соответствии с файлом с унифицированным форматированием путем обновления карточной информации для осуществления регулярных платежей в указанном режиме в соответствии с указанным файлом (см. шаги 814, 816 и 818). Еще один шаг включает реализацию оператором платежной сети приложения по преобразованию учетной записи при электронном переводе средств в соответствии с файлом с унифицированным форматированием путем маршрутизации платежей в соответствии с указанным файлом (см. шаги 808, 810 и 812). Описанные шаги, соответствующие данному аспекту изобретения, могут осуществляться посредством описанных выше модулей и других элементов.

Вариант аппарата согласно другому аспекту изобретения содержит первое запоминающее устройство (например, подобное запоминающему устройству 230, описываемому далее) и по меньшей мере первый процессор (например, подобный процессору 220, описываемому далее), подключенный к первому запоминающему устройству. По меньшей мере первый процессор выполнен с возможностью осуществлять шаги способа, описанные применительно к финансовой организации (например, шаги 820, 822, 824, 804). Аппарат предпочтительно содержит также платежную сеть 208, сконфигурированную из условия облегчения транзакций между множеством эмитентов и множеством эквайеров. Функционирование платежной сети, подключенной по меньшей мере к первому процессору, обеспечивается ее оператором. Аппарат предпочтительно содержит дополнительно второе запоминающее устройство (например, подобное запоминающему устройству 230, описываемому далее) и по меньшей мере второй процессор (например, подобный процессору 220, описываемому далее), подключенный ко второму запоминающему устройству и к платежной сети. По меньшей мере второй процессор выполнен с возможностью принимать файл с унифицированным форматированием, например передаваемый на шаге 804 передачи файла. Файл с унифицированным форматированием указывает по меньшей мере один старый номер учетной записи и по меньшей мере один новый номер учетной записи, ассоциированные с биллером. По меньшей мере второй процессор способен обеспечивать функционирование системы регулярных платежных транзакций для осуществления регулярных платежей в режиме "карта не присутствует" в соответствии с файлом с унифицированным форматированием путем обновления карточной информации для осуществления указанных регулярных платежей в указанном режиме в соответствии с указанным файлом (см. шаги 814, 816, 818) и выполнение операций приложения по преобразованию учетной записи при электронном переводе средств в соответствии с файлом с унифицированным форматированием путем маршрутизации платежей в соответствии с данным файлом (см. шаги 808, 810, 812).

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

Система и продукт

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

На фиг.2 представлена блок-схема системы 200, в которой могут быть использованы часть или все из одного или более аспектов или процессов согласно изобретению. Как показано на фиг.2, запоминающее устройство 230 конфигурирует процессор 220, который может соответствовать, например, процессорам, ассоциированным с любым из блоков на фиг.1, 6, 8 и 9, чтобы осуществить один или более аспектов или способов, шагов и функций, раскрытых в данном описании (в целом обозначенных на фиг.2, как процесс 280). Различные шаги способа могут выполняться различными процессорами. Устройство 230 может быть распределенным или локальным, а процессор 220 - распределенным или единственным. Запоминающее устройство 230 может быть реализовано как электрическая, магнитная или оптическая память или как любая комбинация из них, или как другие типы запоминающих устройств. Следует отметить, что, если используются распределенные процессоры, каждый распределенный процессор, который входит составной частью в процессор 220, обычно содержит свое собственное адресуемое пространство памяти. Следует заметить также, что некоторые или все из компьютеров системы 200 могут быть встроены в интегральную схему, специализированную или общего назначения. Например, один или более шагов способа могут быть осуществлены скорее как аппаратное обеспечение с использованием специализированной интегральной схемы, чем с использованием встроенного программного обеспечения. Дисплей 240 является примером множества возможных вариантов устройств ввода-вывода (например таких, как дисплеи, мыши, клавиатуры).

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

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

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

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

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

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

Кроме того, необходимо отметить, что любые описанные варианты способа могут включать дополнительный шаг создания системы, содержащей определенные программные модули, записанные в одной или более материальной машиночитаемой запоминающей среде. Все такие модули (или любая их часть) могут быть записаны в единственной среде; альтернативно, каждый модуль может быть записан в отдельной среде. Данные модули могут включать любой или все компоненты, представленные на чертежах. В одном или более вариантах модули могут включать модуль оплаты счета посредством электронного перевода средств, находящийся в блоке 824, интегрирующий модуль, находящийся в блоке 822, и модуль платформы платежной сети (см. блоки 208, 608, 802). В этом случае шаги вариантов способа могут выполняться, как это было описано выше, но с использованием дискретных программных модулей системы, запускаемых на одном или более аппаратных процессорах. Могут также иметься дополнительные субмодули. Так, интегрирующий модуль может иметь субмодуль, обеспечивающий карточную операцию 820 или взаимодействующий с ней, и другой субмодуль для осуществления операции создания комбинированного файла. В дополнение, модуль платформы платежной сети может иметь субмодуль системы регулярных платежных транзакций и субмодуль приложения по преобразованию учетной записи при электронном переводе средств. Данный субмодуль может содержать, например, субмодуль получения файла данных, субмодуль структуры преобразования данных, субмодуль данных о перечислениях и субмодуль маршрутизации данных о перечислениях. При этом компьютерный программный продукт может содержать материальную машиночитаемую запоминающую среду (или группу таких сред) с записанным в ней кодом, выполняемым на одном или более шагах вариантов описанного способа, включающего в данном случае обеспечение системы с дискретными программными модулями.

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

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

Реферат

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

Формула