Система и способ управления покупками Российский патент 2024 года по МПК G06Q20/10 

Область техники, к которой относится изобретение

Настоящее изобретение в целом относится к системам и способам управления покупками.

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

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

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

Недостатки уровня техники

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

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

Таким образом, существует потребность в улучшенной системе управления покупками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фиг. 1 схематично показана система для управления покупками в соответствии с одним или несколькими описанными здесь вариантами осуществления.

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

На фиг. 3 схематично показана система для управления покупками в соответствии с одним или несколькими описанными здесь вариантами осуществления.

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

На фиг. 5 схематично показана часть системы для управления покупками в соответствии с одним или несколькими описанными здесь вариантами осуществления.

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

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

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

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

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

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

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

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

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

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

Настоящее описание относится к системам управления покупками и к способам управления покупками. Далее варианты осуществления описанного выше решения представлены более подробно со ссылками на чертежи.

На фиг. 1 схематично представлена система 100 управления покупками в соответствии с одним или несколькими описанными здесь вариантами осуществления. Система 100 управления покупками может содержать центральную базу 110 данных, интерфейс 120 клиента к центральной базе 110 данных и связанный с банком модуль 130 базы данных, способный сообщаться с модулем 520 авторизации транзакции в банке 500 держателя карты. Центральная база 110 данных может, например, быть облачным сервисом. Связанный с банком модуль 130 базы данных может располагаться в банке 500 держателя карты, чтобы обеспечивать быстрый ответ на запрос на одобрение покупки, а также разрешать добавлять информацию о виде транзакции, которую по нормативным причинам не разрешено отправлять за пределы брандмауэра банка, в качестве метаданных, связанных с первым идентификатором транзакции, в связанный с банком модуль 130 базы данных. Существуют строгие нормативные требования к информации о транзакциях, которую разрешено получать извне и/или отправлять за пределы банка, но путем размещения связанного с банком модуля базы данных в пределах этого банка информация о транзакции, которую не разрешено получать извне и/или отправлять за пределы банка, может вводиться в связанный с банком модуль 130 базы данных.

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

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

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

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

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

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

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

Еще одним примером такой сторонней организации 150 является продавец/поставщик 400. Если продавец/поставщик 400 имеет доступ к центральной базе 110 данных и может добавлять метаданные, связанные с идентификатором транзакции, то такой продавец/поставщик 400 может, например, добавлять электронный чек в качестве метаданных, связанных с идентификатором транзакции. Продавец/поставщик 400 может использовать сторонний интерфейс 160 или специальный интерфейс для продавцов/поставщиков 400. В частности, такой интерфейс может быть веб-интерфейсом или мобильным приложением. Тем не менее, электронный чек также может быть добавлен другой стороной, например, покупающим частным лицом из группы 300 покупателей, если продавец/поставщик 400 не имеет доступа к центральной базе 110 данных.

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

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

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

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

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

Когда связанный с банком модуль 130 базы данных получил метаданные, связанные с идентификатором транзакции, из модуля 520 авторизации транзакции в банке 500 держателя карты может быть отправлен запрос на одобрение покупки. Запрос на одобрение покупки содержит информацию о транзакции, которая может быть такой же, как информация для авторизации транзакции, которая при использовании для оплаты покупки платежной карты отправляется через сеть платежных карт из банка продавца в банк 500 держателя карты и принимается модулем 520 авторизации транзакции. Пример такой информации авторизации транзакции показан на фиг. 6. Информация о транзакции в запросе на одобрение покупки не обязательно должна содержать всю информацию для авторизации транзакции, она может содержать сумму и достаточно информации, чтобы связать ее с желаемым идентификатором транзакции. Если запрос на одобрение покупки не содержит идентификатора транзакции, то он, следовательно, должен содержать другую информацию о транзакции, позволяющую связанному с банком модулю 130 базы данных связывать покупку с идентификатором транзакции, например, с информацией о транзакции, идентифицирующей группу 300 покупателей. Если группе 300 покупателей назначена одна или несколько платежных карт, эта информация о транзакции может быть, например, номером платежной карты или токеном для номера платежной карты. Средство 135 банковской обработки связанного с банком модуля 130 базы данных может затем просто связать покупку со следующим идентификатором транзакции, доступным для этой группы 300 покупателей.

Затем средство 135 банковской обработки связанного с банком модуля 130 базы данных проверяет, удовлетворяет ли запрошенная покупка правилам покупок, связанным с идентификатором транзакции, то есть правилам покупок, применяемым к группе 300 покупателей. В дополнение к примерам, приведенным выше, правила покупок могут, например, относиться к максимальной сумме каждой покупки, максимальной итоговой сумме, соблюдению бюджета или к ограничениям на то, где и когда можно совершать покупки (например, международные покупки или покупки в выходные дни могут быть заблокированы). Если запрос на одобрение покупки содержит информацию о продавце, например, имя продавца или код для идентификации продавца, то правила покупок могут также относиться к конкретным продавцам, разрешенным или заблокированным для группы 300 покупателей. Это позволяет покупающей организации 200 блокировать покупки у выбранных поставщиков/продавцов и/или разрешать покупки только у выбранных поставщиков/продавцов. Например, покупающая организация 200 может использовать эту функцию, чтобы блокировать покупки в магазинах спиртных напитков, таких как Systembolaget, или разрешать покупки только в определенных продуктовых сетях, таких как ICA и/или Coop, или у определенных видов продавцов, таких как продуктовые магазины.

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

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

На основе одобрения/отклонения, полученного от средства 135 банковской обработки связанного с банком модуля 130 базы данных, наряду с общей авторизацией транзакции, выполняемой путем проверки, например, данных карты, баланса счета, лимитов и поведения, модуль 520 авторизации транзакции одобряет или отклоняет транзакцию. Если средство 135 банковской обработки связанного с банком модуля 130 базы данных отклонило транзакцию, модуль 520 авторизации транзакции отклоняет транзакцию, даже если общие проверки авторизации транзакции указывают на ее допустимость. Аналогичным образом, если общие проверки авторизации транзакции указывают на недопустимость транзакции, модуль 520 авторизации транзакции отклоняет эту транзакцию, даже если средство 135 банковской обработки связанного с банком модуля 130 базы данных одобряет покупку. В таких ситуациях модуль 520 авторизации транзакции может даже не отправлять запрос на одобрение покупки связанному с банком модулю 130 базы данных, поскольку транзакция в любом случае будет отклонена.

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

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

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

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

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

Поля в центральной базе 110 данных, позволяющие связывать метаданные с идентификаторами транзакций, также могут динамически устанавливаться покупающей организацией 200, так что покупающая организация 200 может определять желаемые метаданные и формат данных для этих метаданных. Это позволяет, например, связывать метаданные, касающиеся центров затрат, счетов и другой информации для выставления счетов, с идентификаторами транзакций в центральной базе 110 данных. Таким образом покупающая организация 200 может определять метаданные, которые она желает получать, и формат, в котором она желает их получать в электронном счете-фактуре, чтобы эти метаданные можно было извлекать из центральной базы 110 данных и добавлять в электронный счет-фактуру. Такой электронный счет-фактура может отправляться банком 500, центральной базой 110 данных или третьей стороной. Если счет-фактура для транзакций, выполненных с использованием системы 100, является электронным счетом-фактурой, содержащим метаданные, указанные покупающей организацией 200, это обеспечивает возможность автоматической обработки счета-фактуры в покупающей организации 200, что позволяет значительно сократить управленческую нагрузку.

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

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

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

Шаг 410: Покупающая организация 200 формирует свои правила покупок в центральной базе 110 данных (это может происходить в любой момент до шага 460, а метаданные могут быть добавлены покупающей организацией 200 в любой момент в ходе этой последовательности действий).

Шаг 415: Центральная база 110 данных заказывает карточные счета для покупающей организации 200 в банке 500 держателя карты.

Шаг 420: Банк 500 держателя карты заказывает платежные карты у эмитента 600 платежных карт.

Шаг 425: Дополнительная информация, такая как персонализация карт, логотипы и т.п., может предоставляться эмитенту 600 платежных карт из центральной базы 110 данных. Платежные карты также могут заказываться у эмитента 600 платежных карт непосредственно из центральной базы 110 данных.

Шаг 430: Платежные карты отправляются эмитентом 600 платежных карт покупающим частным лицам 300 (в их распределении может участвовать покупающая организация 200).

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

Шаг 440: Идентификаторы транзакций и связанные с ними метаданные, такие как правила покупок, передаются из центральной базы 110 данных в связанный с банком модуль 130 базы данных.

Шаг 445: Покупающее частное лицо совершает покупку у продавца/поставщика 400.

Шаг 450: Банк 550 продавца принимает информацию о покупке от продавца/поставщика 400.

Шаг 455: Банк 550 продавца запрашивает у банка 500 держателя карты авторизацию транзакции, например, через сеть платежных карт, такую как VISA или MasterCard.

Шаг 460: Банк 500 держателя карты запрашивает одобрение покупки у связанного с банком модуля 130 базы данных.

Шаг 465: Связанный с банком модуль 130 базы данных отправляет одобрение покупки банку 500 держателя карты.

Шаг 470: Банк 500 держателя карты отправляет авторизацию транзакции банку 550 продавца.

Шаг 475: Банк 550 продавца отправляет разрешение на транзакцию продавцу/поставщику 400.

Шаг 480: Связанный с банком модуль 130 базы данных передает информацию о транзакции, касающуюся одобренной покупки, в центральную базу 110 данных (это может происходить в любой момент после шага 460).

Шаг 485: Центральная база 110 данных передает информацию о транзакции в покупающую организацию 200.

Шаг 490 (опциональный): Третьи стороны добавляют метаданные к транзакции (это может происходить в любой момент в ходе последовательности действий).

На фиг. 5 схематично показана часть системы управления покупками 100 в соответствии с одним или несколькими описанными здесь вариантами осуществления изобретения. В центральной базе 110 данных предпочтительно используется динамическая конфигурация «носителей метаданных», позволяющая связывать метаданные с идентификаторами транзакций, так что покупающая организация 200 может определять желаемые метаданные и формат этих метаданных. Как описано выше со ссылкой на фиг. 1-3, центральная база 110 данных может взаимодействовать и обмениваться данными со многими различными сторонами, например, с покупающими организациями 200, покупающими частными лицами или группами 300 покупателей, поставщиками/продавцами 400, банками 500 держателей карт, эмитентами 600 платежных карт и различными другими сторонними организациями 150. Чтобы центральная база 110 данных могла собирать данные от этих сторон и передавать данные этим сторонам и от них, центральная база 110 данных должна иметь соответствующие функциональные возможности, например в виде «адаптеров» для «перевода» или преобразования формата данных, используемого каждой из этих сторон, в единый формат данных, предпочтительно, в формат данных, определенный покупающей организацией 200. Центральная база 110 данных должна содержать специальный адаптер 205, 305, 405, 505, 605, 155 для каждой стороны 200, 300, 400, 500, 600, 150, поскольку разные стороны обычно используют разные форматы данных (если имеется несколько различных сторонних организаций 150, то обычно требуется несколько разных адаптеров 155). Это позволяет покупающей организации 200 определять метаданные, которые она желает получать от разных сторон, а также формат данных в этих метаданных.

Пример использования

Для дальнейшего описания изобретения предлагается следующий вариант использования. Покупающая компания A состоит из подразделений «Обслуживание», «Разработка», «Продажи» и «Управление». Компания А определяет свою политику и правила покупок через интерфейс 120 клиента к центральной базе 110 данных и заказывает платежные карты для всех своих покупающих частных лиц в своем банке Cardbank. У одних покупающих частных лиц есть личные платежные карты, у других - групповые платежные карты.

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

Компания A определяет свое подразделение «Разработка» как группу покупателей «Разработка» с существенно большими ограничениями. Персонал подразделения «Разработка» состоит из сотрудников компании А и консультантов. Персоналу подразделения «Разработка» не разрешается совершать покупки, которые не были заранее одобрены руководителем подразделения «Разработка». У части персонала подразделения «Разработка» есть личные платежные карты, но есть также несколько групповых платежных карт для группы покупателей «Разработка».

Компания A определяет свое подразделение «Продажи» как две разные группы покупателей: «Локальные продажи» и «Глобальные продажи». Группа покупателей «Локальные продажи» обычно не выезжает за границу, поэтому правила покупок для нее могут быть ограничены покупками внутри страны. Группа покупателей «Глобальные продажи», напротив, много ездит и поэтому в правилах покупок может быть существенно меньше ограничений. Тем не менее, правила покупки могут, например, указывать на необходимость предварительного одобрения, если выбирается отель, не входящий в список отелей и гостиничных сетей, с которыми компания А согласовала цены. У всего персонала подразделения «Продажи» есть личные платежные карты.

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

Когда сотрудник группы «Обслуживание» пытается совершить покупку с помощью платежной карты, банк продавца отправляет запрос на авторизацию транзакции, например, содержащий информацию для авторизации транзакции, показанную на фиг. 6, в банк Cardbank через сеть платежных карт. Модуль 520 авторизации транзакции банка Cardbank принимает запрос на авторизацию транзакции и выполняет ряд проверок, например, в отношении данных карты, остатка на счете, лимитов и поведения. Если модуль 520 авторизации транзакции банка Cardbank на основе этих проверок решает одобрить транзакцию, он отправляет запрос на одобрение покупки в связанную с банком базу 130 данных в банке Cardbank, где идентификаторы транзакций хранятся со связанными с ними метаданными.

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

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

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

Когда покупки совершает персонал подразделения «Управление», также выполняется схожая последовательность действий. При этом у персонала подразделения «Управление» существенно более строгие правила покупок, например, с ограничениями по допустимым поставщикам/продавцам. Информация о транзакции, отправляемая модулем 520 авторизации транзакции банка Cardbank, также содержит информацию о продавце, например имя продавца или код для идентификации продавца, и следовательно, связанная с банком база 130 данных может сравнивать информацию о продавце с допустимыми продавцами в соответствии с правилами покупок. Персонал подразделения «Управление» может быть ограничен в покупках определенными поставщиками/продавцами, например, ICA и/или Coop, или определенными видами продавцов, например, продуктовыми магазинами. В частности, в классификации продавцов VISA для категории «Различные продуктовые магазины – Круглосуточные магазины и специализированные рынки» используется код MCC 5499 и этот код включается в идентификационный код продавца в информации для авторизации транзакции. Когда персонал подразделения «Управление» покупает продукты в продуктовом магазине, к разным видам товаров могут применяться разные величины НДС. Разные величины НДС для разных товаров при покупке могут затем автоматически сохраняться в качестве метаданных, связанных с идентификатором транзакции, чтобы упростить управление в покупающей организации 200.

Варианты осуществления способа

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

Шаг 710: ввод через интерфейс 120 клиента к центральной базе 110 данных правил покупок, применяемых к группе 300 покупателей.

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

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

Шаг 730: передача метаданных, связанных с первым идентификатором транзакции, из центральной базы 110 данных в связанный с банком модуль 130 базы данных.

Шаг 740: прием в модуле 520 авторизации транзакции, расположенном в банке 500, первого запроса на авторизацию транзакции, связанного с первым идентификатором транзакции и содержащего информацию для авторизации транзакции.

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

Шаг 760: принятие решения по запросу на одобрение покупки путем его одобрения или отклонения в зависимости от того, удовлетворяет ли запрашиваемая покупка правилам покупки, связанным с первым идентификатором транзакции, в связанном с банком модуле 130 базы данных.

Шаг 765: ответ модулю 520 авторизации транзакции в виде одобрения или отклонения запроса на одобрение покупки.

Шаг 770: ответ от модуля 520 авторизации транзакции на первый запрос на авторизацию транзакции, связанный с первым идентификатором транзакции.

Шаг 780: добавление информации о транзакции, полученной от модуля 520 авторизации транзакции, в качестве метаданных, связанных с первым идентификатором транзакции, в связанный с банком модуль 130 базы данных.

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

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

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

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

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

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

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

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

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

В некоторых вариантах осуществления изобретения центральная база 110 данных предназначена для связи с рядом различных сторон 200, 300, 400, 500, 600, 150 и содержит адаптеры 205, 305, 405, 505, 605, 155, преобразующие формат данных, используемый каждой из этих сторон, в единый формат данных, предпочтительно, в формат данных, определенный покупающей организацией 200.

Способ 700 может дополнительно включать в себя следующие действия.

Шаг 705: передача информации из центральной базы 110 данных эмитенту 600 платежных карт напрямую или через модуль 510 управления платежными картами в пределах банка 500, чтобы эмитент 600 платежных карт мог выпускать платежные карты для покупающей организации 200.

Вышеизложенное описание изобретения не предназначено для ограничения настоящего изобретения описанными формами или конкретными областями использования. Предполагается, что в свете настоящего описания возможны различные альтернативные варианты осуществления и/или модификации настоящего изобретения, явно описанные здесь или подразумеваемые. Здесь описан вариант осуществления изобретения с использованием платежных карт. Тем не менее, изобретение не ограничивается вариантами осуществления с использованием платежных карт и охватывает также другие способы оплаты, например, оплату с использованием смартфонов или других устройств, в частности, с применением кодов QR, EAN или PIN. Соответственно, объем изобретения определяется исключительно формулой изобретения.

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

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

1. Система (100) управления покупками, содержащая центральную базу (110) данных, интерфейс (120) клиента к центральной базе (110) данных и связанный с банком модуль (130) базы данных, способный сообщаться с модулем (520) авторизации транзакции в пределах банка (500), при этом:

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

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

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

передавать упомянутые метаданные, связанные с первым идентификатором транзакции, в связанный с банком модуль (130) базы данных;

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

принимать решение по запросу на одобрение покупки, одобряя или отклоняя запрос на одобрение покупки в зависимости от того, удовлетворяет ли запрошенная покупка правилам покупки, связанным с первым идентификатором транзакции, в связанном с банком модуле (130) базы данных;

отвечать модулю (520) авторизации транзакции путем одобрения или отклонения запроса на одобрение покупки;

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

передавать информацию о транзакции, связанную с первым идентификатором транзакции, в центральную базу (110) данных;

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

центральная база (110) данных выполнена с возможностью осуществлять связь с различными сторонами (200, 300, 400, 500, 600, 150) и содержит адаптеры (205, 305, 405, 505, 605, 155), каждый адаптер соответствует одной из различных сторон (200, 300, 400, 500, 600, 150), адаптеры (205, 305, 405, 505, 605, 155) преобразуют формат данных, используемый соответствующей из этих различных сторон (200, 300, 400, 500, 600, 150), в формат данных, определенный покупающей организацией (200).

2. Система по п. 1, в которой связанный с банком модуль (130) базы данных расположен в пределах банка (500).

3. Система по п. 1, в которой правила покупок применяются к группе (300) покупателей, включающей в себя по меньшей мере одно покупающее частное лицо.

4. Система по п. 1, в которой правила покупок применяются к группе (300) покупателей, включающей в себя всю покупающую организацию (200).

5. Система по п. 1, в которой правила покупок являются общими правилами покупок для подразделения покупающей организации (200), а центральное средство (115) обработки центральной базы (110) данных способно добавлять правила покупок, применяемые к группе (300) покупателей, в качестве метаданных, связанных с первым идентификатором транзакции, в центральную базу (110) данных на основе определения того, к какому подразделению относится группа (300) покупателей.

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

7. Система по п. 1, в которой правила покупок указывают на необходимость добавления определенных метаданных, связанных с идентификатором транзакции, в центральную базу (110) данных до совершения покупки, а средство (135) банковской обработки связанного с банком модуля (130) базы данных способно отклонять запрос на одобрение покупки, если в связанном с банком модуле (130) базы данных отсутствуют эти метаданные, связанные с идентификатором транзакции.

8. Система по п. 1, в которой центральное средство (115) обработки центральной базы (110) данных также способно передавать информацию напрямую или через модуль (510) управления платежными картами в пределах банка (500) в организацию-эмитент (600) платежных карт, выпускающую платежные карты для покупающей организации (200).

9. Система по п. 1, в которой центральная база (110) данных и связанный с банком модуль (130) базы данных синхронизированы так, чтобы они были зеркальными версиями друг друга.

10. Способ (700) управления покупками, включающий в себя:

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

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

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

передачу (730) упомянутых метаданных, связанных с первым идентификатором транзакции, из центральной базы (110) данных в связанный с банком модуль (130) базы данных;

прием (740) в модуле (520) авторизации транзакции, расположенном в банке (500), первого запроса на авторизацию транзакции, связанного с первым идентификатором транзакции и содержащего информацию для авторизации транзакции;

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

принятие (760) решения по запросу на одобрение покупки путем одобрения или отклонения запроса на одобрение покупки в зависимости того, удовлетворяет ли запрашиваемая покупка правилам покупки, связанным с первым идентификатором транзакции, в связанном с банком модуле (130) базы данных;

ответ (765) модулю (520) авторизации транзакции путем одобрения или отклонения запроса на одобрение покупки;

ответ (770) от модуля (520) авторизации транзакции на первый запрос на авторизацию транзакции, связанный с первым идентификатором транзакции;

добавление (780) информации о транзакции, полученной от модуля (520) авторизации транзакции, в качестве метаданных, связанных с первым идентификатором транзакции, в связанный с банком модуль (130) базы данных;

передачу (785) информации о транзакции, связанной с первым идентификатором транзакции, в центральную базу (110) данных и передачу (790) информации о транзакции, связанной с первым идентификатором транзакции, в покупающую организацию (200), причем информация о покупке автоматически вводится в по меньшей мере одну систему управления покупающей организации (200), и

при этом центральная база (110) данных выполнена с возможностью осуществлять связь с различными сторонами (200, 300, 400, 500, 600, 150) и содержит адаптеры (205, 305, 405, 505, 605, 155), каждый адаптер соответствует одной из различных сторон (200, 300, 400, 500, 600, 150), адаптеры (205, 305, 405, 505, 605, 155) преобразуют формат данных, используемый соответствующей из этих различных сторон (200, 300, 400, 500, 600, 150), в формат данных, определенный покупающей организацией (200).

11. Способ по п. 10, в котором связанный с банком модуль (130) базы данных расположен в пределах банка (500).

12. Способ по п. 10, в котором группа (300) покупателей включает в себя по меньшей мере одно покупающее частное лицо.

13. Способ по п. 10, в котором группа (300) покупателей включает в себя всю покупающую организацию (200).

14. Способ по п. 10, в котором правила покупок являются общими правилами покупок для подразделения покупающей организации (200), а добавление (725) правил покупок, применяемых к группе (300) покупателей, в качестве метаданных, связанных с первым идентификатором транзакции, в центральную базу (110) данных включает в себя определение того, к какому подразделению относится группа (300) покупателей.

15. Способ по п. 10, в котором информация о транзакции содержит информацию о продавце, а принятие (760) решения по запросу на одобрение покупки путем одобрения или отклонения запроса на одобрение покупки также зависит от информации о продавце.

16. Способ по п. 10, в котором правила покупок указывают на необходимость добавления определенных метаданных, связанных с идентификатором транзакции, в центральную базу (110) данных до совершения покупки, а принятие (760) решения по запросу на одобрение покупки включает в себя отклонение запроса на одобрение покупки, если в связанном с банком модуле (130) базы данных отсутствуют эти метаданные, связанные с идентификатором транзакции.

17. Способ по п. 10, также включающий в себя передачу (705) информации из центральной базы (110) данных в организацию-эмитент (600) платежных карт напрямую или через модуль (510) управления платежными картами в пределах банка (500), чтобы организация-эмитент (600) платежных карт могла выпускать платежные карты для покупающей организации (200).

18. Способ по п. 10, в котором передача (730) метаданных, связанных с первым идентификатором транзакции, из центральной базы (110) данных в связанный с банком модуль (130) базы данных и передача (785) информации о транзакции, связанной с первым идентификатором транзакции, в центральную базу (110) данных включают в себя синхронизацию центральной базы (110) данных и связанного с банком модуля (130) базы данных, чтобы они были зеркальными версиями друг друга.