СИСТЕМЫ ДЛЯ ОБЕСПЕЧЕНИЯ СОЗДАНИЯ И УПРАВЛЕНИЯ СПИСКАМИ ТОВАРОВ С УНИКАЛЬНЫМИ ИДЕНТИФИКАЦИОННЫМИ КОДАМИ ДЛЯ ТОВАРОВ И СВЯЗЫВАНИЯ СПИСКОВ СО СПОНСОРСКИМИ ПРОГРАММАМИ ПЛАТЕЖНЫХ ФИНАНСОВЫХ ТРАНЗАКЦИЙ НА ОСНОВЕ БАНКОВСКИХ КАРТ
SYSTEMS FOR CREATING AND MANAGING LISTS OF COMMODITIES WITH UNIQUE IDENTIFICATION CODES FOR COMMODITIES AND ASSOCIATING LISTS WITH SPONSORSHIP PROGRAMMES OF BANK CARD-BASED PAYMENT FINANCIAL TRANSACTIONS

Родственные заявки
[0001] Данная заявка притязает на приоритет заявки на патент США № 61/422471, поданной 13 декабря 2010 года, заявки на патент США № 13/117003, поданной 26 мая 2011 года, и заявки на патент США № 13/117010, поданной 26 мая 2011 года, все из которых включены в настоящий документ по ссылке.
Область техники, к которой относится изобретение
[0002] Настоящее изобретение, в общем, относится к системам для обеспечения создания и управления списков товаров, а более конкретно - к системам с уникальными идентификационными кодами для каждого товара, которые включают в себя ассоциирование списков со спонсорской программой платежных финансовых транзакций на основе банковских карт, чтобы определять то, может или нет карта для проведения платежных финансовых транзакций, ассоциированная с указанной программой финансовых транзакций на основе банковских карт, использоваться для того, чтобы оплачивать товары, представленные для покупки.
Описание предшествующего уровня техники
[0003] Многие поставщики, обеспечивающие регулируемое медицинское обслуживание, предлагают участникам скидки на отпускаемые по рецепту лекарства. Тем не менее, лишь незначительная часть поставщиков, обеспечивающих регулируемое медицинское обслуживание, также предлагает участникам скидки на отпускаемые без рецепта (OTC) лекарственные средства. Следовательно, обычная практика заключается в том, что участники посещают кабинет неотложной помощи при таких болезнях, как насморк и кашель. Эти посещения и зачастую фармацевтические препараты, выписываемые в ходе этих посещений, типично являются очень дорогими и зачастую страхуются с покрытием поставщиками, обеспечивающими регулируемое медицинское обслуживание.
[0004] Многие из этих посещений и ассоциированные затраты могут исключаться, если участникам выдается фиксированная ежемесячная сумма в долларах для расходования на OTC-продукты, такие как OTC-микстуры от кашля, антигистамины, аспирин и т.д. Та незначительная часть поставщиков, обеспечивающих регулируемое медицинское обслуживание, которые предлагают страховые OTC-выплаты своим участникам, традиционно нацелены на реализацию этого с использованием бумажных ваучеров или форм, которые выдаются участникам и погашаются в розничных магазинах. Эти традиционные способы зачастую подвержены ошибкам и не позволяют предлагать средства формирования сообщений, ассоциированные со способами.
[0005] В одной системе и способе для упрощения погашения страховых выплат для клиента предоставляется карта для проведения финансовых транзакций по страховым выплатам, которая включает в себя ассоциирование идентификационного кода с клиентом. Идентификационный код сохраняется на карте для проведения финансовых транзакций по страховым выплатам. Осуществляется доступ к записи счета, ассоциированной с идентификационным кодом, и после этого выполняется определение с целью выявлять, является или нет товар, представленный для покупки клиентом, допустимым для скидки по страховым выплатам. Надлежащая скидка для товара вычисляется в том случае, если определено, что товар является допустимым для скидки по страховым выплатам.
[0006] Современные способы рассматривают несколько субъектов относительно поставщиков, обеспечивающих регулируемое медицинское обслуживание, и множество субъектов с точки зрения ритейлеров, но не могут учитывать сложности, внутренне присущие вследствие сценария "многие-ко-многим" при создании, ассоциировании и управлении списком(ками) допустимых товаров. Одна организация, обеспечивающая регулируемое медицинское обслуживание, и один список товаров плюс один бренд ритейлера не несут в себе сложности. Тем не менее, несколько организаций с несколькими списками товаров, принимаемыми несколькими ритейлерами, представляют собой более сложный сценарий. При использовании современных способов идентифицируется сам список. Тем не менее, современные способы не позволяют создавать, ассоциировать и управлять списком, даже если результирующий вывод списка требуется для того, чтобы выполнять сопоставление товаров в торговой точке на основе представленного механизма платежей или идентификации.
[0007] Большинство планов медицинского страхования в США предоставляют страховое покрытие для связанных со здравоохранением товаров в розничных магазинах. Примеры включают в себя, но не только, лекарства от аллергии, средства от кашля и простуды, обезболивающие средства, витамины и т.п.
[0008] Федеральное правительство, через Министерство здравоохранения и социального обеспечения, а более конкретно через Центры по координации программ государственной медицинской помощи Medicare и Medicaid лимитирует использование денежных средств для страховых выплат, направляемых для одного бренда ритейлера. Одновременно они не требуют от планов медицинского страхования предлагать идентичный список допустимых товаров при условии, что товары являются поднабором общего утвержденного списка и что их предлагают всем участникам.
[0009] Современные способы не рассматривают то, как список(ки) допустимых товаров создается, ассоциируется с программой финансовых транзакций на основе банковских карт и управляется на постоянной основе. Современные способы рассматривают только то, что товар, представленный для покупки клиентом, определяется как допустимый или недопустимый на основе списка. Список предоставляется поставщиком или работником, обеспечивающим регулируемое медицинское обслуживание, в примере гибкой карты для проведения финансовых транзакций по страховым выплатам.
[0010] Страховые выплаты по программам государственной медицинской помощи Medicare и Medicaid открывают перспективу расходования миллиардов в год. Во многих случаях участвующие покупатели не обращаются к этим денежным средствам вследствие сложности и неудобства, ассоциированного с современным процессом. Удобство электронного процесса для работы с витриной привлекает дополнительных участвующих покупателей для участвующих ритейлеров и повышает доходы ритейлера от продаж допустимых продуктов. Держатели карт для проведения финансовых транзакций платят полную розничную цену с использованием карты для проведения финансовых транзакций в любом POS в магазине, включающем в себя, но не только, аптечный прилавок.
[0011] Существует потребность в системах и способах для публикации несколькими ритейлерами того, какие товары они продают, и добавления собственных товаров под собственной торговой маркой в списки допустимых товаров. Существует дополнительная потребность, чтобы несколько планов медицинского страхования (или спонсоров) имели (i) начальную точку в форме главного утвержденного списка; (ii) возможность просматривать сопоставления товаров от нескольких участвующих ритейлеров; (iii) возможность создавать поднабор из этого списка; (iii) возможность создавать специализированный список; и (iv) ассоциировать этот список с конкретным механизмом платежей, финансируемым спонсором.
Сущность изобретения
[0012] Соответственно, цель настоящего изобретения заключается в предоставлении систем для того, чтобы автоматизировать создание и ассоциирование списков товаров, вызываемых в ходе покупки из торгового терминала, при определении того, является или нет представленный товар допустимым для покупки посредством представленного механизма платежей (например, через проведение через считывающее устройство магнитной карты для проведения финансовых транзакций).
[0013] Другая цель настоящего изобретения заключается в том, чтобы предоставлять ритейлерам возможность оповещать о том, какие товары они продают в конкретном списке товаров, а также возможность добавлять собственные продукты под собственной торговой маркой в эти списки.
[0014] Дополнительная цель настоящего изобретения заключается в предоставлении систем, которые дают спонсорам возможность создавать списки товаров и ассоциировать эти списки с программами платежей в целях расчетов с ритейлерами, продающими допустимые товары участникам спонсора.
[0015] Еще одна другая цель настоящего изобретения заключается в предоставлении систем, которые дают возможность спонсорам каждого списка определять настройки публикации.
[0016] Эти и другие цели настоящего изобретения достигаются в системе для участия нескольких ритейлеров в программах лимитированного расходования денежных средств на основе банковских карт. Инфраструктура ритейлера включает в себя сервер торгового терминала, соединенный со складским концентратором и с таблицами продуктов/прейскурантом(ами). Процессор принятия решения соединен с ритейлером. Процессор управления каталогами включает в себя сервер, соединенный с процессором принятия решения. Процессор управления каталогами создает каталог UPC для каждого участвующего ритейлера. Каждый каталог включает в себя первый и второй наборы UPC-данных. Первый набор служит для продуктов национальных брендов, а второй набор служит для продуктов под собственной торговой маркой ритейлера.
Краткое описание чертежей
[0017] Фиг.1 является общей архитектурой системы одного варианта осуществления настоящего изобретения вне рамок инфраструктуры сети ритейлера.
[0018] Фиг.2 является общей архитектурой системы одного варианта осуществления настоящего изобретения в рамках инфраструктуры сети ритейлера.
[0019] Фиг.3 является блок-схемой последовательности операций способа, иллюстрирующей работу сервера анализа корзины, используемого в одном варианте осуществления настоящего изобретения.
[0020] Фиг.4 является блок-схемой последовательности операций способа, иллюстрирующей принятие решения по содержимому корзины в одном варианте осуществления настоящего изобретения.
[0021] Фиг.5 является блок-схемой последовательности операций способа, иллюстрирующей работу коммутатора процессора принятия решения в одном варианте осуществления настоящего изобретения.
[0022] Фиг.6 иллюстрирует вариант осуществления в последовательности операций обработки для публикации каталогов.
Подробное описание изобретения
[0023] Предусмотрены системы и способы для обеспечения для нескольких ритейлеров автоматизации процесса сопоставления товаров, представленных в торговой точке, с выбранной покупателем картой для проведения финансовых транзакций, чтобы определять, разрешена или нет покупка представленных товаров посредством представленной карты для проведения финансовых транзакций. Более конкретно настоящее изобретение предусматривает сопоставление товаров с несколькими списками товаров для ассоциированных со спонсором программ платежей/расчетов.
[0024] В настоящем изобретении предусмотрены системы и способы для реализации программы финансовых транзакций на основе банковских карт, имеющей покупателей. Покупатели лимитированы в покупке выбранных товаров у выбранных ритейлеров, и ритейлеры составляют часть частной сети между хостами, имеющей возможность передавать сообщения в и из сетевого компьютера. Каждый покупатель имеет уникальный идентификационный код, который соответствует списку выбранных товаров и списку выбранных ритейлеров.
[0025] В настоящем изобретении предусмотрены системы и способы для реализации процесса принятия решения, который дает возможность использования корзины с каталогами продуктов. Каждый каталог содержит список универсальных кодов продуктов (UPC), каждый из которых идентифицирует товар, который может покупаться посредством карты для проведения финансовых транзакций. Кошелек является идентификатором для финансового счета, ассоциированного с картой для проведения финансовых транзакций. В качестве неограничивающих примеров финансовый счет может быть банковским счетом, кредитной картой для проведения финансовых транзакций, дебетовой картой для проведения финансовых транзакций, предоплатной картой для проведения финансовых транзакций, сторонним источником финансирования и т.п. В качестве неограничивающих примеров карта для проведения финансовых транзакций может быть картой для проведения финансовых транзакций, выбираемой, по меньшей мере, из одного из кредитной карты для проведения финансовых транзакций, дебетовой карты для проведения финансовых транзакций, подарочной карты для проведения финансовых транзакций, карты для проведения финансовых транзакций по переводу денежных средств, другими типами элемента для аутентификации платежей, допускающего выполнение перевода денежных средств и т.п. В одном варианте осуществления карта для проведения финансовых транзакций, включающая в себя, но не только, дебетовую карту для проведения финансовых транзакций или кредитную карту для проведения финансовых транзакций, имеет несколько учреждений для проведения финансовых транзакций или кошельков. Карта для проведения финансовых транзакций также может иметь только один расходный кошелек. Товары в корзине распознаются в соответствии с одним или более ассоциированных каталогов.
[0026] Как проиллюстрировано на фиг.1, процессор 10 принятия решения включает в себя сервер 12 анализа корзины, сервер 14 управления процессом, коммутатор 16, каталоги 18 продуктов и данные 20 счета покупателя.
[0027] Если обобщать, на фиг.1 инфраструктура ритейлера, обозначаемая как 22, включает в себя POS 24 на кассе ритейлера (далее ритейлер 24). Ритейлер 24 включает в себя сервер 26 торгового терминала (POS) со сканнером 28 штрихкода, который соединяется со складским концентратором 30 и с таблицами 32 продуктов/прейскурантом(ами). Отдел 34 разработки продуктов ритейлера поддерживает связь с таблицами 32 продуктов/прейскурантом(ами) и с сервером 36 управления каталогами. Отдел 34 разработки продуктов ритейлера представляет собой часть отдела 38 эксплуатации POS ритейлера.
[0028] Сервер 36 управления каталогами включается в процессор 40 управления каталогами. Инфраструктура 22 ритейлера также включает в себя сеть 42 ритейлера с коммутатором 44 ритейлера.
[0029] Коммутатор 44 ритейлера соединяется с процессором 10 принятия решения. Сервер 12 анализа корзины соединяется с каталогами 18 продуктов и проверяет правильность допустимых товаров в корзине, как подробнее поясняется ниже. Содержимое корзины, включающее в себя, но не только, UPC, цену, количество и т.п., передается между сервером 12 анализа корзины и коммутатором 16 из коммутатора 44 ритейлера. Сервер 36 управления каталогами обменивается данными с сервером 12 анализа корзины в форме каталогов 18 продуктов.
[0030] Эмитент карт для проведения финансовых транзакций (далее финансовый процессор 46) соединяется с процессором 10 принятия решения и включает в себя номера 48 карт для проведения финансовых транзакций и процессор 50 эмитента (транзакции).
[0031] Процессор 52 страховых выплат включает в себя процессор (собиратель) 54 страховых требований, соединенный с коммутатором 16. Процессор 52 страховых выплат поддерживает связь с коммутатором 16. Сервер 12 анализа корзины может контактировать с процессором 52 страховых выплат через коммутатор 16 в реальном времени и принимать авторизацию страхового требования. Процессор 52 страховых выплат может обмениваться данными через стандартные языки обработки рецептов, NCPDP5.1 и NCPDPd.0.
[0032] Информация 56 счета включает в себя данные 20 счета покупателя, которые предоставляются на сервер 12 анализа корзины и связаны с номерами 48 карт для проведения финансовых транзакций, получаемыми из финансового процессора 46, который включает в себя процессор 50 эмитента (транзакции). Процессор 50 эмитента обменивается данными с коммутатором 58 и с коммутатором 16, когда требуются транзакции финансового утверждения.
[0033] Как указано выше, настоящее изобретение обеспечивает для нескольких ритейлеров автоматизацию процесса сопоставления товаров, представленных при покупке на POS 26, с выбранным покупателем механизмом платежей, чтобы определять то, разрешена или нет покупка представленных товаров посредством представленного механизма платежей. Более конкретно настоящее изобретение предусматривает сопоставление товаров с несколькими списками товаров для ассоциированных со спонсором программ платежей/расчетов.
[0034] В варианте осуществления по фиг.2 процессор 10 принятия решения включается в розничную инфраструктуру 22. Общая архитектура системы в варианте осуществления по фиг.2 включает в себя коммутатор 58, чтобы обмениваться данными с процессами ритейлера, которые находятся под защитой брандмауэра ритейлера.
[0035] Процесс принятия решения использует компоненты в процессоре 10 принятия решения. В комбинации коммутатор 16, сервер 12 анализа корзины, сервер 36 управления каталогами и сервер 14 управления процессом предоставляют принятие решения. В одном варианте осуществления процесс принятия решения также позволяет авторизовать финансовую транзакцию.
[0036] Финансовые транзакции, которые инициируются посредством операции покупки на кассе ритейлера, типично передаются в форме ISO 8583 из коммутатора 44 ритейлера в коммутатор 16. Коммутатор 16 разбивает сообщение ISO 8583 на сообщения, подходящие для обработки посредством следующих компонентов обработки, таких как сервер 12 анализа корзины.
[0037] В одном варианте осуществления коммутатор 16 передает данные содержимого корзины и идентификационную информацию транзакции на сервер 12 анализа корзины в форме данных, которая синтаксически проанализирована и отформатирована посредством коммутатора 16.
[0038] Сервер 12 анализа корзины сравнивает содержимое корзины с каталогом(ами) 18 продуктов. Каталог(и) 18 продуктов ранее загружен на сервер 12 анализа корзины из сервера 36 управления каталогами. Каталоги 18 продуктов содержат список товаров утвержденных продуктов, идентифицированных посредством UPC и краткого описания. Данные содержимого позиций корзины обрабатываются итеративно посредством сервера 12 корзины.
[0039] В настоящем изобретении может обрабатываться принятие решения для множества каталогов 18. В настоящем изобретении каталог 18 непосредственно связан с кошельком счета. Этот кошелек может быть ассоциирован с лимитированным расходованием на основе каталога 18, который используется для того, чтобы распознавать список товаров. Например, карта для проведения финансовых транзакций может поддерживать расходование по каталогу пищевых продуктов, а также каталогу отпускаемых без рецепта лекарственных препаратов. Один или более расходных кошельков, каждый из которых имеет конкретный расходный баланс от конкретного эмитента, может быть идентифицирован для одной карты для проведения финансовых транзакций.
[0040] В настоящем изобретении ритейлер 24 собирает корзину и при проведении через считывающее устройство или сканировании карты для проведения финансовых транзакций покупателя комплектует корзину, отправляет ее в процессор 10 принятия решения для (i) обработки запроса на покупку ритейлером либо для (ii) обработки запроса на покупку процессором принятия решения. Входящая и исходящая связь между ритейлером 24 и процессором 10 принятия решения может осуществляться через формат сообщений ISO 8583, формат XML-веб-служб и т.п., причем все из означенного применяет обмен данными в реальном времени. В качестве неограничивающего примера ввод может осуществляться посредством, по меньшей мере, одного из проведения карты для проведения финансовых транзакций через гнездо на устройстве считывания карт для проведения финансовых транзакций, соединенном с мобильным устройством, через гнездо на мобильном устройстве, сканирования, через беспроводную связь, касания картой для проведения финансовых транзакций мобильного устройства, посредством ввода информации на мобильном устройстве, фотографий, выбора карты для проведения финансовых транзакций из приложения на мобильном устройстве и из онлайнового субъекта.
[0041] Как проиллюстрировано на фиг.1 и 2, ритейлер обменивается данными с коммутатором 44 ритейлера, который проталкивает данные транзакции в процессор 50 принятия решения. Коммутатор 16 принимает транзакцию и в итоге обрабатывает ее. Коммутатор 16 является шлюзом для всех типов транзакций. Транзакция может представлять собой один из множества типов. В одном варианте осуществления изобретения, транзакция может быть запросом на принятие решения, запросом на авторизацию или результирующей POS-транзакцией. Коммутатор 16 определяет характер запроса 56 на проведение транзакции и форматирует данные и маршрутизирует запрос через последующие процессы, как определено посредством типа запроса.
[0042] Фиг.3 является блок-схемой последовательности операций способа, иллюстрирующей работу сервера 12 корзины с этапами 60-80. Сервер анализа корзины принимает данные транзакции с корзиной из коммутатора 16 и определяет то, является или нет транзакция с корзиной допустимой. Если не является, то запрос на обработку отклоняется. Если она является допустимой, то сервер 12 корзины извлекает учетные данные транзакции из данных управления процессом. Если учетные данные не являются допустимыми, то запрос на обработку отклоняется. Когда учетные данные являются допустимыми, выполняется определение в отношении того, имеются или нет соответствующие условиям товары в корзине. Если нет, то выполняется возврат без необходимости обработки. Если да, требуется авторизация и затем возврат с необходимостью обработки.
[0043] Транзакция принятия решения содержит идентификационные данные транзакции и информацию корзины, отформатированные и перенаправленные в процесс сервера корзины. Транзакция авторизации содержит идентификационные данные транзакции и запросы на финансовую авторизацию для конкретного финансового платежного счета (кошелька). Результирующая транзакция содержит идентификационную информацию транзакции, обработанную транзакцию принятия решения содержимого корзины (товаров в корзине, помеченных для конкретного кошелька и каталога) и информацию финансовой авторизации.
[0044] Сервер 12 корзины принимает транзакцию принятия решения из коммутатора 16. Сервер 12 корзины полностью обрабатывает карту для проведения финансовых транзакций по мере возможности и возвращает результат транзакции в коммутатор для последующей обработки по мере необходимости. Коммутатор 16 принимает транзакцию принятия решения и определяет то, требуется или нет последующая обработка. Транзакция принятия решения может требовать от коммутатора 16 получение авторизации по финансовой транзакции от одного или более эмитентов. Коммутатор 16 форматирует информацию 60 транзакции для маршрутизации и обработки эмитентом.
[0045] Коммутатор 16 ожидает завершение транзакции с ритейлером 24 до тех пор, пока запрос(ы) на авторизацию не обрабатывается и возвращается эмитентом(ами). Информация авторизации форматируется и возвращается ритейлеру 24, и транзакция добавляется в журнал постоянных данных всех транзакций, проходящих через коммутатор 16. Коммутатор 16 форматирует результирующую POS-транзакцию и возвращает ритейлеру 24, и транзакция добавляется в журнал постоянных данных всех транзакций, проходящих через коммутатор 16.
[0046] Обращаясь к блок-схеме последовательности операций способа принятия решения содержимого корзины по фиг.4 с этапами 82-112, список товаров в корзине принимается с использованием сервера 12 анализа корзины и коммутатора 16. При достижении конца корзины считается общая сумма товаров, корзина закрывается, и создается корзина с соответствующим примечанием. Если конец не достигнут, то товары из корзины сравниваются с индексированными товарами в каталоге. Когда нет совпадения с товарами в каталоге, достигается конец каталога 18, и увеличивается индекс. Если конец каталога 18 не достигнут, увеличивается индекс списка корзины, и товар помечается.
[0047] Работа коммутатора 16 проиллюстрирована на фиг.5 на этапах 114-134. Коммутатор 16 принимает и перегруппировывает данные транзакции, принятые из транзакции. Выполняется определение посредством коммутатора 16 в отношении типа транзакции. Когда транзакция представляет собой принятие решения, корзина форматируется. Для POS-OUT-транзакции она форматируется для POS. Коммутатор 16 затем выполняет авторизацию, форматирует транзакцию для финансового процессора 46 и затем маршрутизирует 508 эмитенту для авторизации. Сообщение 509 авторизации принимается из финансового процессора 46. Коммутатор 16 форматирует его и возвращает его ритейлеру 24 через коммутатор 44 ритейлера. Транзакция затем регистрируется в журнале транзакций.
[0048] Существует несколько авторизаций для нескольких кошельков. Коммутатор 16 выполнен с возможностью соединяться с несколькими финансовыми процессорами 40, когда существует несколько авторизаций. Коммутатор 16 может соединяться с несколькими системами финансовой обработки, чтобы обрабатывать лимитированное расходование для нескольких кошельков, привязанных к нескольким процессорам эмитента. На основе правил, предоставляемых посредством сервера 14 управления процессом, коммутатор разделяет финансовые транзакции для нескольких эмитентов карт для проведения финансовых транзакций и принимает авторизацию из нескольких финансовых процессоров.
[0049] В настоящем изобретении сервер 12 анализа корзины изолирует информацию финансового счета покупателя от зависимости в отношении соответствия установленным требованиям HIPAA и PCI-DSS.
[0050] Ритейлер 24 изолирован от сведений по нескольким кошелькам, нескольким демографическим данным эмитентов карт для проведения финансовых транзакций и т.п. PAN транзакции привязан к структуре счета, которая задает применимые правила управления процессом. Правила управления процессом предоставляются в коммутатор 16 из сервера 14 управления процессом, чтобы устанавливать путь финансовых авторизаций. Номер 48 карты для проведения финансовых транзакций и ассоциированные каталоги 18 для этой карты для проведения финансовых транзакций предоставляются для использования посредством сервера 12 анализа корзины каталогов с кошельком.
[0051] Процессор 10 принятия решения не отправляет демографические данные ритейлеров. Номер 48 карты для проведения финансовых транзакций и ассоциированные каталоги 18 для этой карты для проведения финансовых транзакций предоставляются для использования посредством сервера 12 анализа корзины каталогов, связанных с PAN, эмитентами карт для проведения финансовых транзакций и кошельками.
[0052] В настоящем изобретении выполняются следующие этапы.
[0053] Принимается набор данных товаров, например, корзина. Каждый товар в корзине имеет универсальный код продукта (UPC) для того, чтобы уникально идентифицировать товар, и имеет количество, чистую цену и налог на добавленную стоимость в соответствии с прайс-листом ритейлера.
[0054] Каждый товар в корзине оценивается и сравнивается посредством UPC с товарами, утвержденными для конкретного кошелька, как связанными с каталогом 18 продуктов из плана/продуктов. Каждый товар в корзине помечается как допустимый или недопустимый для конкретного продукта/плана. Допустимые товары группируются согласно продукту/плану, и выполняется вычисление общей стоимости всех товаров, менее подходящих скидок и льгот для каждой группы. Общие суммы по товарам, по группам и идентификационная информация корзины форматируются в XML-структуры данных, ISO 8583, NCPDP5.1 или NCPDPd.0, для последующей обработки ритейлером 24, процессором 52 страховых выплат и т.п.
[0055] Принятие решения может выполняться у ритейлера 24 и быть внутренним для ритейлера, либо принятие решения может выполняться внешне для ритейлера и иметь несколько ритейлеров, подключенных к нему.
[0056] XML-структура данных проталкивается в коммутатор 16. Коммутатор 16 используется для того, чтобы транслировать данные в указанный ритейлером формат для систем, хостинг которых выполняется в сети ритейлера, и в форматы ISO 8583, XML, NCPDP5.1 или NCPDPd.0 для обработки посредством процессора 50 эмитента или процессора 54 страховых требований. Запрос на финансовую авторизацию на основе XML или запрос на финансовую авторизацию на основе ISO 8583 инициируется, когда финансовый процессор не является неотъемлемой частью внутренней сети ритейлера, и когда ритейлер требует инициирования транзакций посредством настоящего изобретения. В этом случае система и способ сервера 14 управления процессом настоящего изобретения определяет содержимое запроса на авторизацию для общих сумм по группам, и коммутатор 16 компонует и передает запросы на авторизацию на основе XML в финансовый процессор 46. Коммутатор 14 форматирует запросы на авторизацию на основе XML в форматах, требуемых посредством соответствующего процессора эмитента.
[0057] Товары, выбранные посредством покупателя и помещенные в корзину, представляются для покупки в процессе выполнения оплаты участвующего ритейлера 24. Этот процесс может представлять собой физическую кассу в розничном магазине, набор товаров в корзине, выбранных из каталога и идентифицированных покупателем во время выполнения оплаты, либо вручение рецепта в розничном магазине, аптечном прилавке для выдачи онлайновых или телефонных заказов, среди других процессов.
[0058] Процесс использования физических касс для выполнения оплаты наличными ритейлера или физического аптечного прилавка ритейлера требует сканирования или введения вручную товаров в корзине в POS 26 в магазине ритейлера. Процесс использования каталога 18, онлайновых или телефонных покупок требует выбора и идентификации товаров посредством способа покупок и их ввода в качестве товаров в корзине.
[0059] Независимо от способа покупок все данные товаров в корзине, включающие в себя цену, количество, налоги, полученные в торговой точке скидки, комплектуются в одну транзакцию и форматируются согласно спецификациям системных сообщений для торговых терминалов в магазинах. Одна транзакция также должна включать в себя идентификационную информацию ритейлера и идентификационную информацию покупателя, которая может включать в себя, по меньшей мере, следующее:
1. Идентификатор ритейлера
2. Идентификатор магазина
3. Идентификатор терминала
4. PAN - первичный номер счета
5. Временная метка
6. STAN - порядковый номер операции с банковской картой
7. Сведения по позиции <в расчете на уникальный товар в корзине>
a. UPC
b. Чистая цена
c. Налог
d. Количество
e. Краткое описание товара
[0060] Эта транзакция поступает из POS 26 в складской концентратор 30, в коммутатор 44 ритейлера и затем в коммутатор 16. Данные транзакции могут включать в себя данные товаров и данные идентификатора клиента (номер карты для проведения финансовых транзакций) и т.п. Связь осуществляется через ритейлеров 24, складской концентратор 30 и с коммутатором 44 ритейлера. Все ритейлеры 24 подключаются к сети, и данные проходят из коммутатора 44 ритейлера ритейлерам 24, а затем в другой коммутатор у ритейлера. Коммутатор 16 использует коммутатор 44 ритейлера или внутренний коммутатор ритейлера, при этом связь с ритейлером 24 осуществляется множеством способов, включающих в себя, но не только, структуры данных ISO 8583 или XML.
[0061] Данные транзакции принимаются из инициирующего ритейлера 24. Транзакция с корзиной направляется из сервера 12 корзины в коммутатор 16. Коммутатор 16 форматирует данные в XML-структуру данных из любой структуры ритейлера, которая принята, и передает транслированную XML-структуру на сервер 12 анализа корзины.
[0062] Сервер 12 анализа корзины использует PAN, чтобы определять каталоги 18 и кошельки для счета покупателя. Персональная информация покупателя вообще не извлекается в ходе принятия решения или обработки финансовых транзакций. PAN покупателя связывает один или более конкретных каталогов продуктов с транзакциями с корзиной.
[0063] Если идентификатор покупателя, например, номер счета карты для проведения финансовых транзакций (PAN), не распознается посредством коммутатора 16, возникает ошибка, и происходит отклонение. Если PAN является ошибочным, коммутатор 16 возвращает сообщение инициирующему ритейлеру 24 о том, что транзакция отклонена.
[0064] Коммутатор 16 сопоставляет данные товаров, принятые в транзакции с корзиной, по одному товару за раз. Коммутатор 16 добавляет два индикатора для каждой позиции корзины. Формируется флаг, который сообщает то, является товар допустимым или недопустимым, а также определяется индикатор группы (каталога) 18, которому принадлежит товар.
[0065] При выполнении обработки каждый товар в корзине и общие суммы по каждой группе используются для того, чтобы комплектовать транзакцию с корзиной, и возвращаются ритейлеру 24 для обработки. В другом варианте осуществления обработанная транзакция с корзиной возвращается в коммутатор 16.
[0066] При получении обработанной транзакции с корзиной сервер 12 анализа корзины сопоставляет идентификатор покупателя с эмитентом карт для проведения финансовых транзакций, ассоциированным с идентификатором покупателя.
[0067] Коммутатор 16 создает сообщение с запросом на авторизацию по платежу на основе XML, которое включает в себя идентификационные данные финансового процессора 46 и идентификационную информацию транзакций ритейлера. Эта авторизация по платежу затем отправляется в финансовый процессор 46. В различных вариантах осуществления структуры данных ISO 8583, XML и NCPDPd.0 используются для сообщений с запросом на авторизацию между коммутатором 16 и финансовым процессором 46.
[0068] В различных вариантах осуществления коммутатор 16 (i) принимает сообщение авторизации обратно из финансового процессора 46 или процессора 54 страховых требований; (ii) создает журнал данных авторизованных транзакций на основе идентификационного номера транзакции, и (iii) создает сообщение авторизации в надлежащем формате, чтобы перенаправлять сообщение ритейлеру 24.
[0069] В другом варианте осуществления настоящего изобретения процессор 40 управления каталогами создает каталог 18 UPC для каждого участвующего ритейлера 24. Каждый каталог 18 включает в себя первый и второй наборы UPC-данных. Первый набор служит для продуктов национальных брендов, а второй набор служит для продуктов под собственной торговой маркой ритейлера 24.
[0070] Система и способы настоящего изобретения дают возможность ритейлерам 24 inComm принимать способ оплаты на основе карты для проведения финансовых транзакций в торговой точке для продуктов, включающих в себя, но не только, лекарства и медикаменты, страхуемые с покрытием спонсором, включающим в себя, но не только, программу государственной медицинской помощи Medicare и/или Medicaid. Настоящее изобретение предоставляет системы и способы, которые обеспечивают замену для способов компенсации, которые традиционно включают в себя страховые требования вручную или оффлайновые системы, которые не взаимодействуют с POS 18 ритейлера 24.
[0071] В некоторых случаях механизм приема/погашения карты для проведения финансовых транзакций использует существующий интерфейс обмена сообщениями POS-to-inComm для обработки транзакций.
[0072] В различных вариантах осуществления настоящее изобретение предоставляет системы и способы, которые дают возможность некоторым спонсорам создавать списки, которые являются конкретными для организации, и, следовательно, лимитируют публикацию списка для ритейлеров 24. Другие спонсоры могут выбирать разрешать публикацию своего списка и обеспечивать его доступность на сервере управления каталогами, что дает возможность другим спонсорам выбирать список, который уже создан. В качестве неограничивающего примера, программа государственной медицинской помощи Medicaid может создавать список, ориентированный на профилактическую карту, заполненную витаминами и аспирином с низкой дозировкой действующего вещества, и давать возможность использования этого списка другими, позволяя другим государствам использовать преимущество их достижений, направленных на идентификацию наиболее эффективных товаров для профилактической карты.
[0073] В одном варианте осуществления карты для проведения финансовых транзакций не активируются или покупаются через POS-транзакцию ритейлера. Карты для проведения финансовых транзакций выдаются покупателю согласно планам медицинского страхования для управления программами государственной медицинской помощи Medicare и Medicaid от имени федерального правительства и правительств штатов. В одном варианте осуществления покупатель активирует карту для проведения финансовых транзакций по телефону и через технологию интерактивного распознавания речи. Карта для проведения финансовых транзакций может быть использована у участвующих ритейлеров 24, чтобы оплачивать допустимые розничные товары и услуги, как указано спонсором, включающие в себя, но не только, отпускаемые без рецепта лекарства и медикаменты, в качестве примеров.
[0074] В одном варианте осуществления каталог 18 UPC создается и поддерживается для каждого участвующего ритейлера 24. Каталог 18 состоит из двух наборов UPC-данных: один набор служит для продуктов национальных брендов, а другой набор служит для продуктов под собственной торговой маркой ритейлера 24. Каталог 18 отражает задание того, что разрешается для покупки с использованием процессора 40 управления каталогами/карты для проведения финансовых транзакций InComm. Каталог 18 должен соответствовать опубликованным инструкциям от спонсора, включающего в себя, но не только, Центры по координации программ государственной медицинской помощи Medicare и Medicaid (CMS).
[0075] Каталог 18 периодически обновляется как каталог 18 национальных брендов, и затем сопутствующие обновления ритейлером 24 в каталоге 18 собственных торговых марок. Процессор 40 управления каталогами формирует утвержденный каталог 18 национальных брендов, который является согласованным с требованиями агентства по утверждению. Процессор 40 управления каталогами, в качестве прокси-сервера для агентства по программам медицинского страхования и утверждению, отвечает за обеспечение того, что товары под собственной торговой маркой, предлагаемые ритейлером 24, находятся в рамках справочника допустимых товаров. Ритейлер 24 отвечает за задание и поддержание списка тех товаров под собственной торговой маркой ритейлера 24, которые находятся в рамках каталога 18 национальных брендов. Процессор 40 управления каталогами несет ответственность за план медицинского страхования, что все товары под собственной торговой маркой, предлагаемые ритейлером 24, утверждаются в рамках справочника. Одна последовательность операций обработки используется для того, чтобы публиковать начальный каталог 18 и затем поддерживать его в дальнейшем.
[0076] Начальное составление каталогов 18 посредством процессора 40 управления каталогами начинается с полного списка UPC национальных брендов для данных семейств продуктов. Процессор 40 управления каталогами сужает этот список. В одном варианте осуществления это выполняется только посредством процессора 40 управления каталогами, а в другом варианте осуществления это осуществляется с использованием как процессора 40, так и утверждающего спонсора или агентства, к примеру, спонсора или агентства, который содержит только UPC, которые являются согласованными с CMS-справочником.
[0077] Утверждение каталога 18 национальных брендов и каталога 18 собственных торговых марок выполняется по различным путям. Процессор 40 управления каталогами управляет каталогом 18 национальных брендов, а ритейлер 24 управляет каталогом 18 собственных торговых марок. Процессор 40 управления каталогами, в качестве прокси-сервера для агентства по программам медицинского страхования или утверждению, анализирует и утверждает товары в каталоге 18 собственных торговых марок.
[0078] Диалог между ритейлером 24 и процессором 40 управления каталогами может принимать форму файлов данных, которыми обмениваются на различных стадиях предложения, утверждения и публикации. Фиг.6 иллюстрирует последовательность операций обработки для публикации каталогов 18.
[0079] После начальной версии каталога 18 корректировочные версии выпускаются на периодической основе, к примеру, ежеквартально. Назначение корректировочной версии состоит в том, чтобы регулировать каталог 18 национальных брендов таким образом, чтобы включать в него дополнительные продукты, удалять устаревшие продукты или изменять информацию, относящуюся к конкретному UPC. Если содержимое каталога 18 национальных брендов изменяется, это может оказывать влияние на содержимое каталога 18 собственных торговых марок. Следовательно, процесс анализа требуется для того, чтобы обеспечивать, что изменения на национальном уровне отражаются в качестве изменений на уровне собственной торговой марки.
[0080] Ритейлер 24 обрабатывает обновления в порядке согласно рамкам выбранного периода времени, к примеру, 90 дней, от последней версии каталога 18. В качестве неограничивающего примера, каталоги 18 выпускаются ежеквартально, за сорок пять дней до квартала (январь, апрель, июль, октябрь), для обработки и интеграции ритейлером 24 в (или за один день до) первый день каждого квартала. Если ритейлер 24 присоединяется к программе в середине срока, разрешается исключение для первого цикла обновлений. Только на первом цикле обновления ритейлер 24 может выбрать ожидание в течение одного цикла до обновления своих начальных настроек. Например, ритейлер 24 присоединяется 1 мая и внедряет каталог 18 с 15 февраля за квартал, начиная с апреля. Следующее обновление каталога 18 выпускается 15 мая, но ритейлер 24 может пропускать этот цикл в качестве разового события. Но будущие версии каталога 18 в перспективе должны обеспечивать внедрение каждые 90 дней.
[0081] В отношении товаров под собственной торговой маркой пример 1 является одним вариантом осуществления ежеквартального процесса.
Пример 1
Ежеквартальный процесс (даты Q1 (квартала 1) предоставлены в качестве примера)
Дата
Процесс
11/15
Ежеквартальное обновление, доступное для ритейлера
Всегда 15 число, примерно за 45 дней
12/1
Ритейлер отвечает обновленным каталогом, который включает в себя продукты под собственной торговой маркой
Всегда 1 число, примерно за 30 дней
12/10
MG утверждает/отклоняет продукты под собственной торговой маркой и отправляет результаты обратно ритейлеру
Всегда 10 число, примерно за 20 дней
01/01
Ритейлер утверждает обновления в своей системе
[0082] Процессор 40 управления каталогами и ритейлер 24 обмениваются данными друг с другом в ходе этапа в процессе управления каталогами. В одном варианте осуществления процесс передачи файлов выполняется через SFTP (FTP по SSH). Ритейлеру 24 предоставляется SFTP-адрес и уникальный каталог на SFTP-сервере в процессоре 40 управления каталогами, в который можно помещать и извлекать файлы данных, которые должны быть переданы. Файлы проталкиваются в SFTP-веб-узел и извлекаются из SFTP-веб-узла ритейлером 24.
[0083] Процессор 40 управления каталогами может автоматически сканировать и обрабатывать эти файлы, размещенные в SFTP-каталоге ритейлера 24 периодически, что может представлять собой, в качестве неограничивающего примера, каждые два часа и т.п.
[0084] Пример 2 является примером структуры папок процессора 24 управления каталогами. Следует принимать во внимание, что также могут быть использованы другие структуры папок.
Пример 2
Структура папок процессора управления каталогами
[0085] /Production (предоставляется посредством процессора 40 управления каталогами ритейлеру в начале обслуживания)
/In (для файлов, поступающих от ритейлера)
/Out (для файлов, направляемых ритейлеру)
Настоящее изобретение может использовать множество соглашений о присвоении имен файлов. Пример 3 является конкретным вариантом осуществления, но могут использоваться другие.
Пример 3
Соглашения о присвоении имен файлов
Соглашения о присвоении имен файлов
[0086] Общий формат, который используется в настоящее время, принимает форму "<MRID><file_type>_<file_state>_<file_number>_YYYYMMDDHHMMSS.txt", где
[0087] "MRID" является трехсимвольным указателем, назначаемым посредством процессора 40 управления каталогами для ритейлера 24.
[0088] "file_type" является трехсимвольным (или меньше) указателем, который означает тип файла.
[0089] "file_state" является однобуквенным указателем, где "S" задает файл для отправки в MG от ритейлера 24, а "R" задает файл для возврата ритейлеру 24 из процессора 40 управления каталогами.
[0090] "File_number" является уникальным пятисимвольным указателем, используемым для того, чтобы идентифицировать объем содержимого файла.
[0091] "YYYY" означает год из четырех знаков.
[0092] "MM" означает месяц года.
[0093] "DD" означает день месяца.
[0094] "HHMMSS" означает часы, минуты и секунды дня.
Имя файла
Назначение
FTP-папка
_YYYYMMDDHHMMSS.txt
Файл от ритейлера в MG
/Production/In
_YYYYMMDDHHMMSS.txt
Файл из MG ритейлеру
/Production/Out
[0095] Соглашения о форматах файлов и данных - файлы данных, передаваемые между процессором 40 управления каталогами и ритейлерами 24, могут подчиняться множеству соглашений, включающих в себя, но не только, нижеупомянутые соглашения:
[0096] Файл и форматы данных могут представлять собой ASCI. Поля в файле разграничиваются посредством символа "|" вертикальной черты.
- Структура файлов - файлы могут иметь 3 типа записи,
- Запись заголовка товара: тип "HDRD".
- Записи товаров: указываются для каждого типа файла.
- Запись контрольной суммы: тип "CHKS". Запись контрольной суммы является последней записью файла. В большинстве случаев контрольная сумма является просто количеством записей.
- Для CQU запись заголовка файла с типом записи "FILE"
[0097] Возврат каретки и перевод строки - все записи в файле могут завершаться посредством возврата каретки и перевода строки.
[0098] Типы полей - "M"=денежный, "D"=дата, "N"=числовой, "A"=буквенно-цифровой.
[0099] Денежные поля - числовые поля могут содержать фактическую десятичную запятую и иметь 2 десятичных разряда, т.е.: "99999,99". Это могут быть числа со знаком; положительные числа не имеют знака, отрицательные числа имеют знак "минус".
[00100] Поля даты - поля даты могут передаваться в следующем формате: MM/DD/YYYY.
[00101] Числовые поля - числовые поля могут быть выровнены влево, т.е. 99999,99.
[00102] Алфавитно-цифровые поля - алфавитно-цифровые поля могут быть выровнены влево, что приводит к удалению начальных пробелов.
[00103] Максимальная длина (Max Len) - Оно указывает максимальное число символов, разрешенное для длины поля.
[00104] Обязательный (Req'd) - "Y" равняется "обязательный", и запись может считаться недопустимой, если данные не включены. "N"="необязательный".
[00105] Имена файлов - ниже представлены имена трех файлов, которые могут быть использованы:
1. Имя типа файла: CQU - процессор 40 управления каталогами публикует главный каталог 18, который содержит все активные товары национальных брендов ("каталог 18"), на периодической основе, к примеру, ежеквартально. CQU содержит все UPC-коды национальных брендов, которые являются допустимыми для данного набора планов медицинского страхования.
2. Имя типа файла: CQR - ритейлер 24 анализирует главный каталог 18 (CQU) и создает CQR-каталог 18 собственных продуктов под собственной торговой маркой ритейлера 24 для анализа посредством процессора 40 управления каталогами. Процессор 40 управления каталогами отвечает утверждением или отказом.
3. Имя типа файла: CQP - ритейлер 24 консолидирует конечные товары под собственной торговой маркой и товары национальных брендов в один файл данных и отправляет этот файл для утверждения посредством процессора 40 управления каталогами. Процессор 40 управления каталогами отвечает утверждением или отказом.
[00106] Заголовок файла конкретного CQU разграничивает все планы медицинского страхования и программы медицинского страхования, поддерживаемые посредством файла.
[00107] Запись заголовка файла используется. Соответствующая запись представлена в примере 4.
Пример 4
Запись заголовка файла
Запись заголовка товара
Запись контрольной суммы по товарам
Запись заголовка товара
Записи товаров
Запись контрольной суммы по товарам
[00108] Ритейлер 24 должен формировать файл товаров под собственной торговой маркой, который должен отправляться для утверждения посредством процессора 40 управления каталогами (в качестве прокси-сервера для агента по программам медицинского страхования и утверждению). Формат для этого файла описывается ниже. При анализе товаров в файле, которые не являются допустимыми для включения в план, помечаются "N" в коде операции; все допустимые товары помечаются "E". Файл возвращается ритейлеру 24 в течение пяти рабочих дней после отправки. См. пояснение по соглашению о присвоении имен файлов в разделе 4 касательно идентификации имен файлов для отправки и возврата.
Пример 5
Ответный каталог ритейлера (имя типа файла: CQR)
Запись заголовка товара
Записи товаров
Запись контрольной суммы по товарам
[00109] Ритейлер 24 формирует файл, который содержит как утвержденные товары под собственной торговой маркой, так и применимые товары национальных брендов для утверждения посредством процессора 40 управления каталогами, до развертывания. Формат для этого файла описывается ниже. При анализе товаров в файле, которые не являются допустимыми для включения в план, помечаются "N" в коде операции; все допустимые товары помечаются "E". Файл возвращается ритейлеру 24 в течение пяти рабочих дней после отправки. См. пояснение по соглашению о присвоении имен файлов в разделе 4 касательно идентификации имен файлов для отправки и возврата.
Пример 6
Формирование файла для развертывания (имя типа файла: CQP)
Запись заголовка товара
Записи товаров
Запись контрольной суммы по товарам
[00110] Другие варианты осуществления изобретения должны становиться очевидными специалистам в данной области техники в ходе изучения подробного описания и практического применения изобретения, раскрытого в данном документе. Данное подробное описание и примеры должны рассматриваться только как примерные, при этом истинный объем и сущность изобретения указываются посредством прилагаемой формулы изобретения.