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

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

Иллюстрации

Показать все

Реферат

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

Датами приоритета для данной заявки являются 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, который использует данную операцию. Этот шаг может выполняться, например, модулем оплаты счета по