RU2718175C1 - Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий - Google Patents

Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий Download PDF

Info

Publication number
RU2718175C1
RU2718175C1 RU2019102204A RU2019102204A RU2718175C1 RU 2718175 C1 RU2718175 C1 RU 2718175C1 RU 2019102204 A RU2019102204 A RU 2019102204A RU 2019102204 A RU2019102204 A RU 2019102204A RU 2718175 C1 RU2718175 C1 RU 2718175C1
Authority
RU
Russia
Prior art keywords
account
payment
order
authorizations
accounts
Prior art date
Application number
RU2019102204A
Other languages
English (en)
Inventor
Ино ДУН
Сяохуа ЧЖОУ
Юйсюань ПИ
Сяоин ВАН
Е Шень
Original Assignee
Алибаба Груп Холдинг Лимитед
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Алибаба Груп Холдинг Лимитед filed Critical Алибаба Груп Холдинг Лимитед
Application granted granted Critical
Publication of RU2718175C1 publication Critical patent/RU2718175C1/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0607—Regulated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q30/0637—Approvals

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

По данной заявке испрашивается приоритет Китайской Патентной Заявки Номер 201610500388.0, поданной 29 июня 2016г., и озаглавленной «Network Transaction Method and Device Based on Authorization Separation Control», которая во всей свой полноте включена в настоящее описание посредством ссылки.
Область техники, к которой относится изобретение
Данная заявка относится к области техники Интернет приложений, в частности, к способу и устройству для сетевых транзакций, основанным на разделении и управлении авторизацией.
Предпосылки создания изобретения
Во время процесса сетевых транзакций, «заказ» и «платеж» являются двумя базовыми операциями для пользователей-покупателей. Здесь, «заказ» относится к операции пользователя-покупателя, выбирающего и подтверждающего товары, которые должны быть куплены, а «платеж» относится к процессу переноса пользователем-покупателем соответствующей суммы средств пользователю-продавцу за товары, которые должны быть куплены.
Обычно, «заказ» и «платеж» выполняются одним и тем же пользователем, но в некоторых обстоятельствах, может существовать потребность в том, чтобы разные пользователи выполняли «заказ» и «платеж». Например, в сценарии корпоративного снабжения, на основании внутреннего распределения полномочий в корпорации, сотрудник по снабжению должен проводить заказ, а должностные лица или финансовый администратор должен проводить оплату. Существующие системы сетевой транзакции не могут успешно удовлетворять такие требования реальной жизни, тем самым приводя к неудобству пользователя и возможно приводя к ненужному потреблению ресурсов системы.
Сущность изобретения
Для данной технической проблемы, данная заявка предоставляет устройство и способ сетевой транзакции, основанные на управлении разделения авторизации, техническое решение которых является следующим:
Способ сетевой транзакции, основанный на разделении и управлении авторизациями, применимый к стороне системы транзакции, предварительно создающей и хранящей связующие отношения между разными учетными записями, причем одна из любых двух связанных учетных записей, по меньшей мере, с авторизациями заказа пользователя-покупателя, а другая одна, по меньшей мере, с авторизациями оплаты пользователя-покупателя, и способ сетевой транзакции, содержащий этапы, на которых:
принимают заказ, поданный посредством первой учетной записи;
определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений ;
инициируют запрос оплаты к второй учетной записи на основании заказа, поданного посредством первой учетной записи;
в ответ на подтверждение запроса оплаты второй учетной записью, определяют, что заказ был успешно оплачен.
Устройство сетевой транзакции, основанное на разделении и управлении авторизациями, применимое к стороне системы транзакции, предварительно создающей и хранящей связующие отношения между разными учетными записями, причем одна из любых двух связанных учетных записей, по меньшей мере, с авторизациями заказа пользователя-покупателя, а другая одна, по меньшей мере, с авторизациями оплаты пользователя-покупателя, и устройство сетевой транзакции, содержащее:
модуль приема заказа, выполненный с возможностью приема заказа, поданного посредством первой учетной записи;
модуль определения учетной записи оплаты, выполненный с возможностью определения второй учетной записи, связанной с первой учетной записью, на основании предварительно сохраненных связующих отношений ;
модуль инициирования запроса оплаты, выполненный с возможностью инициирования запроса оплаты к второй учетной записи на основании заказа, поданного посредством первой учетной записи;
модуль определения оплаты, выполненный с возможностью, в ответ на подтверждение запроса оплаты второй учетной записью, определения, что оплата заказа успешна.
Посредством использования механизма для разделения авторизаций заказа и авторизаций оплаты пользователя-покупателя, техническое решение, предоставленное посредством данной заявки, разрешает разным учетным записям выполнять операции заказа и оплаты для одной транзакции, тем самым, не допуская проблемы неудобства, возникающего при использовании несколькими пользователями одной и той же учетной записи, при этом также эффективно сокращая ненужное потребление ресурсов стороны системы.
Следует понимать, что предшествующее общее описание и подробное описание ниже являются лишь примерными и пояснительными, и не ограничивают данную заявку.
Краткое описание чертежей
Для того, чтобы четко объяснить варианты осуществления данной заявки или технические решения текущих технологий, простое введение в чертежи, требуемые в описании вариантов осуществления или текущих технологий, приводится ниже. Очевидно, что чертежи в нижеследующих описаниях показывают лишь немногие варианты осуществления данной заявки. Для специалиста в соответствующей области техники существует возможность получения других чертежей на основании этих чертежей.
Фигура 1 является блок-схемой последовательности операций способа сетевой транзакции данной заявки;
Фигура 2 является принципиальной схемой устройства сетевой транзакции данной заявки.
Подробное описание
Чтобы позволить специалисту в соответствующей области техники лучше понять технические решения данной заявки, в сочетании с чертежами вариантов осуществления данной заявки, подробное описание технических решений в вариантах осуществления данной заявки приводится ниже. Конечно, описываемые варианты осуществления являются лишь частью вариантов осуществления данной заявки, и не являются полным набором вариантов осуществления. На основании вариантов осуществления данной заявки, все прочие варианты осуществления, полученные специалистом в соответствующей области техники, должны лежать в рамках объема правовой защиты данной заявки.
Сначала, следует отметить, что, в данной заявке, «пользователь» относится к фактическому оператору. Например, сотрудник по снабжению и финансовый администратор являются разными пользователями. «Учетная запись» относится к виртуальному идентификатору в сети. Деятельность фактического пользователя в сети отражается посредством поведения «учетной записи». В приложениях реальной жизни, даже несмотря на то, что разрешено нескольким фактическим пользователям использовать одну и ту же учетную запись, это будет приводить к неудобству.
Сегодняшние системы сетевой транзакции первоначально разработаны имея в виду независимых пользователей-покупателей. Т.е., по умолчанию заказ и оплата должны совершаться одним и тем же человеком в транзакции. Тем не менее, при данном механизме, касательно сценария потребности, упомянутого в разделе Предпосылок создания изобретения, при заказе и оплате, выполняемыми разными людьми, необходимо чтобы сотрудник заказа и сотрудник оплаты использовал одну и ту же учетную запись транзакции, чтобы совершать их собственные операции. Таким образом в приложении реальной жизни, после того как сотрудник заказа подает заказ, ему требуется заставить сотрудника оплаты совершить оплату на текущем устройстве, или уведомить сотрудника оплаты посредством телефона, и т.д., и заставить сотрудника оплаты войти в ту же самую учетную запись на другом устройстве и совершить оплату.
Очевидно, поскольку фактические авторизации «пользователя» не согласуются с авторизациями «учетной записи», необходимо использовать «неудобный» подход в виде совместного использования несколькими пользователями одной и той же учетной записи, чтобы решать проблему. Тем не менее, фактические операции пользователя являются очень сложными и громоздкими, независимо от используемых подходов. Также, из-за того, что несколько людей используют одну и ту же учетную запись, становятся неизбежными разнообразные типы проблем, такие как невозможное параллельное использование, конфликт операций, повторные входы в систему, и т.д., понижающие эффективность работы. Применительно к стороне системы, это может добавить много дополнительной обработки, например: сообщения об ошибке, аутентификация идентификационных данных, и т.д., приводя к ненужному расходу ресурсов обработки.
Ориентируясь на проблемы существующих технологий, техническое решение, предоставленное данной заявкой, состоит в разрешении конфигурации разных авторизаций операции покупателя, содержащих авторизации заказа, авторизации оплаты, и т.д., для разных учетных записей, и в выполнении связывания учетных записей с разными авторизациями операции. При фактическом выполнении транзакции, учетные записи в связующих отношениях могут осуществлять координацию, чтобы выполнять операции одной транзакции, тем самым эффективно избегая разнообразных проблем, возникающих при совместном использовании несколькими людьми одной и той же учетной записи.
Предполагая в небольшой корпорации, A является сотрудником по снабжению, а B является финансовым руководителем. На основании решения данной заявки, в системе транзакции, возможно, что пользователь A и пользователь B раздельно регистрируются в разных учетных записях. Предполагая, что идентификаторами зарегистрированной учетной записи являются ID_a и ID_b соответственно, учетная запись ID_a имеет авторизации заказа пользователя-покупателя, а учетная запись ID_b имеет авторизации оплаты пользователя-покупателя. Далее, связующее отношение между учетной записью ID_a и учетной записью ID_b создается и сохраняется на стороне системы транзакции. Важность создания связующих отношений состоит в том, что: в текущей системе транзакции, разрешено двум связанным учетным записям действовать вместе в качестве покупателя и осуществлять координацию при совершении одной и той же транзакции.
Фигура 1 показывает взаимосвязанную блок-схему последовательности операций способа сетевой транзакции, предоставленного данной заявкой. Следует отметить, что взаимодействующими субъектами, участвующими в схеме, являются: учетная запись ID_a и учетная запись ID_b, т.е.: их можно понимать в качестве логических субъектов транзакции, или двух особых примеров объектов «учетной записи» в системе программного обеспечения системы транзакции. Их также можно понимать в качестве фактических устройств пользователя, например: мобильных телефонов, PC, и т.д., которые в настоящее время вошли в учетную запись. «Систему транзакции» можно понимать в качестве платформ программного обеспечения и аппаратного обеспечения, используемых чтобы выполнять сетевую транзакцию в широком смысле. Эти элементы не влияют на описание решения данной заявки.
S101, учетная запись ID_a подает заказ в систему транзакции.
На основании предшествующего описания, учетная запись ID_a является учетной записью с авторизациями заказа. При нормальных обстоятельствах, данная учетная запись используется пользователем, фактически исполняющим задачу заказа (например, сотрудником по снабжению). Здесь, предполагается, что учетная запись ID_a используется сотрудником A по снабжению; и сотрудник A по снабжению выбирает модель, стиль, количество, и торговца и т.д. для товаров, которые должны быть куплены на платформе электронной торговли, использует особые операции, чтобы сгенерировать соответствующий заказ, и подает заказ системе транзакции. Для удобства описания, данный заказ идентифицируется как X. В дополнение к содержанию информации о товарах, которые должны быть куплены, данный заказ также должен содержать идентификатор подающей учетной записи; т.е.: ID_a, указывающий, что данный заказ был подан посредством учетной записи ID_a.
S102, на основании предварительно сохраненных связующих отношений , определяется учетная запись, связанная с учетной записью ID_a.
После того, как система транзакции принимает заказ, сначала она синтаксически анализирует идентификатор учетной записи, подающей заказ, затем, на основании предварительно сохраненных связующих отношений , она определяет учетную запись, связанную с учетной записью, подающей заказ. В частности, она определяет «учетную запись с авторизациями оплаты», которая связана с «учетной записью с авторизациями заказа».
В данном варианте осуществления, учетной записью заказа для заказа X является ID_a, и на основании предварительно сохраненной информации связывания, может быть определено, что учетной записью, связанной с учетной записью ID_a, является учетная запись ID_b.
S103, применительно к заказу, поданному посредством учетной записи ID_a, инициируется запрос оплаты к учетной записи, связанной с учетной записью ID_a.
На основании решения данной заявки, нет необходимости в том, чтобы заказ и оплата в одной транзакции выполнялись посредством одной и той же учетной записи. В данном варианте осуществления, так как учетная запись ID_a не имеет авторизаций оплаты, последующие операции оплаты для заказа X пропускаются к учетной записи ID_b, с которой она связана, для совершения.
Инициирование запроса оплаты к связанной учетной записи может быть достигнуто многими путями, например: передавая сообщение уведомления соответствующей учетной записи, используя систему внутренних сообщений системы транзакции. Если другие режимы контакта ассоциированы с целевой учетной записью, такие как электронная почта, обмен текстовыми сообщениями, обмен мгновенными сообщениями, и т.д., эти каналы также могут быть использованы, чтобы передавать сообщение уведомления целевой учетной записи, для того чтобы действительный пользователь, соответствующий целевой учетной записи, имел возможность увидеть уведомление настолько быстро, насколько это возможно, и выполнил оплату.
Чтобы облегчить использование пользователем оплаты, можно предоставить портал сокращенной операции в сообщении уведомления, чтобы подтверждать запрос оплаты. Например, ссылка, которая может непосредственно перенаправлять пользователя в интерфейс информации о заказе и интерфейс подтверждения оплаты, может быть добавлена в тело сообщения уведомления, или QR-код оплаты может быть непосредственно добавлен в тело сообщения уведомления, и т.д. Для того, чтобы удовлетворять требования пользователя оплаты в отношении просмотра заказов, можно добавлять подробности или краткую информацию в тело сообщения уведомления или в интерфейс подтверждения оплаты.
Следует понимать, что разные действительные пользователи могут осуществлять связь, не полагаясь на функции, предоставляемые системой транзакции. Вследствие этого, «активное уведомление» не является требуемой функцией системы транзакции.
S104~S105, учетная запись ID_b подтверждает запрос оплаты, и система транзакции определяет, что оплата заказа была успешно совершена.
После того, как учетная запись ID_b подтверждает заказ X и выполняет соответствующую оплату, система транзакции будет принимать релевантную информацию подтверждения. Затем, она может определять, что данная оплата была успешно совершена и переходить в последующий процесс отгрузки и доставки.
В сравнении с текущими технологиями, в одном аспекте, решение данной заявки обеспечивает конфигурацию разных авторизаций операции для разных учетных записей покупателя, для того чтобы согласовывать авторизации учетной записи с фактическими обязанностями сотрудника, гарантируя взаимно-однозначное соответствие между виртуальными учетными записями и фактическими пользователями. В другом аспекте, посредством настройки связующих отношений между разными учетными записями, учетным записям обеспечивается возможность, в связующем отношении, координировать и выполнять операции одной транзакции . Пользователи с разными обязанностями используют разные учетные записи, причем каждый выполняет свои соответствующие функции. Это может эффективно не допускать разнообразных проблем, таких как конфликт операций и повторные входы в систему, и увеличить общую эффективность работы. Применительно к стороне системы, это может соответственно уменьшить дополнительную обработку, такую как сообщения об ошибке и аутентификация идентификационных данных, сокращая ненужное потребление ресурсов обработки.
В вышеупомянутом варианте осуществления, «привязывание 1 учетной записи заказа к 1 учетной записи оплаты» используется только чтобы представить иллюстративное объяснение базового решения данной заявки, но в других вариантах реализации данной заявки, связующие отношения могут быть более гибко сконфигурированы для того, чтобы удовлетворять разнообразные требования комплексного использования. Дополнительные примеры приводятся ниже.
На основании решения данной заявки, применительно к двум связанным учетным записям, одна должна, по меньшей мере, иметь авторизации заказа пользователя-покупателя, а другая должна, по меньшей мере, иметь авторизации оплаты пользователя-покупателя. Тем не менее, это не означает, что каждой учетной записи разрешается иметь один вид авторизаций пользователя-покупателя. Например, касательно вышеупомянутой учетной записи ID_a и учетной записи ID_b, они могут быть сконфигурированы так, что учетная запись ID_a имеет только авторизации заказа, а учетная запись ID_b имеет как авторизации заказа, так и авторизации оплаты. Фактической потребностью, соответствующей данному подходу, может быть: сотрудник по снабжению использует учетную запись ID_a и может только размещать заказы, но не выполнять оплаты; должностное лицо использует учетную запись ID_b и может просматривать и оплачивать заказы, размещенные сотрудником по снабжению, как, впрочем, и размещать свои собственные заказы.
Соответственно, на вышеупомянутом Этапе S102, после того как система транзакции принимает заказ и синтаксически анализирует идентификатор учетной записи, подающей заказ, она может сначала определять, имеет ли данная учетная запись авторизации оплаты. Если нет, она переходит к определению учетных записей, связанных с данной учетной записью, на основании предварительно сохраненных связующих отношений . Если учетная запись, подающая заказ, имеет авторизации оплаты (например, учетная запись ID_b), транзакция может быть выполнена в соответствии с традиционными потоками транзакции, т.е.: одна и та же учетная запись выполняет заказ и оплату.
Следует понимать, что в дополнение к авторизациям заказа покупателя и авторизациям оплаты покупателя, учетная запись в системе транзакции также может содержать другие типы авторизаций. Это может не относиться к решению данной заявки и не будет дополнительно объясняться.
В дополнение, на основании решения данной заявки, число учетных записей, соответствующих каждому связующему отношению и, составляет 2, но любой заданной учетной записи разрешено иметь несколько связующих отношений , т.е.: одна учетная запись может быть связана с несколькими другими учетными записями. Например:
Одна учетная запись с авторизациями оплаты связывается с несколькими учетными записями с авторизациями заказа:
Фактической потребностью, соответствующей данному типу конфигурации связывания, может быть: Несколько сотрудников по снабжению могут использовать свои собственные исключительные учетные записи, чтобы размещать заказы, которые затем передаются вместе принципалу для просмотра и оплаты. Легко представить, что если используется решение в виде нескольких людей использующих одну и ту же учетную запись, предоставленное текущими технологиями, это будет чрезвычайно хлопотно при фактической реализации. Тем не менее, посредством реализации решения данной заявки, связывающего одну учетную запись с авторизациями оплаты вместе с несколькими учетными записями с авторизациями заказа, будет очень легко удовлетворить данную потребность.
Типичным решением конфигурации является настройка системы из главных учетных записей и вспомогательных учетных записей. Одна главная учетная запись может открывать несколько вспомогательных учетных записей под своим именем, с связующими отношениями автоматически создающимися между вспомогательными учетными записями и главной учетной записью. Пользователь главной учетной записи может добавлять или удалять вспомогательные учетные записи и модифицировать авторизации вспомогательной учетной записи, тем самым удовлетворяя административные потребности при фактическом использовании. Например, главная учетная запись имеет авторизации оплаты, и она может быть предоставлена должностным лицам и финансовому администратору для их использования. Под именем данной главной учетной записи, может быть открыто несколько вспомогательных учетных записей с авторизациями заказа, для использования несколькими сотрудниками по снабжению. При данном решении конфигурации, разные сотрудники по снабжению могут раздельно использовать вспомогательные учетные записи, чтобы выполнять покупки, вся информация по заказу будет представляться в отчете главной учетной записи, и релевантный принципал будет выполнять единообразный просмотр и оплату этих заказов.
Одна учетная запись может иметь авторизации заказа, связанные с несколькими учетными записями с авторизациями оплаты:
Фактической потребностью, соответствующей данному типу конфигурации связывания, может быть: Один сотрудник по снабжению совершает покупку для нескольких разных отделов, и соответственно разным принципалам требуется просматривать заказы и подтверждать оплаты.
При данной конфигурации связывания, поскольку учетная запись оплаты для заказа не является уникальной, требуется чтобы поданный заказ включал в себя идентификатор назначенной учетной записи с авторизациями оплаты, чтобы позволить системе транзакции определять, какая учетная запись должна оплачивать текущий заказ. Естественно, касательно идентификатора учетной записи с авторизациями оплаты, включенного в заказ, система транзакции может дополнительно верифицировать, присутствует ли связующее отношение между учетной записью, подающей заказ, и ее назначенной учетной записью оплаты. В дополнение, перед подачей заказа, система транзакции также может предоставлять учетной записи, размещающей в настоящее время заказ, информацию по нескольким учетным записям оплаты, с которыми она связана, на основании связующих отношений , чтобы способствовать непосредственным выборам. Вкратце, система транзакции может определять какой учетной записи должен быть отправлен запрос оплаты для текущего заказа на основании предварительно сохраненной информации связывания и идентификатора учетной записи, включенного в заказ.
Например, учетная запись ID_a, которая имеет авторизации заказа, связывается с тремя учетными записями с авторизациями оплаты: ID_b1, ID_b2, и ID_b3. Вследствие этого, когда учетная запись ID_a размещает заказ, система транзакции может отображать ID_b1, ID_b2, и ID_b3 в списке в интерфейсе подтверждения заказа и просить заказывающего пользователя выбрать одну в качестве учетной записи оплаты текущего заказа. Предполагая, что заказывающий пользователь выбирает ID_b2, «ID_b2» будет включен в заказ в качестве дополнительной информации, и впоследствии, система транзакции будет непосредственно передавать запрос оплаты данного заказа к учетной записи ID_b2.
На основании решения данной заявки, связующие отношения между учетными записями могут быть назначены во время фазы регистрации учетной записи, и они также могут быть назначены или модифицированы после регистрации учетной записи, при необходимости.
В дополнение, может быть понятно, что в примерах данной заявки, «система транзакции» относится к программному обеспечению и аппаратному обеспечению, используемому чтобы выполнять сетевые транзакции, в широком смысле; ее не следует понимать, как данность, особое физическое устройство или платформу электронной торговли. Например, при использовании сторонней системы транзакции оплаты, «система транзакции» может быть разделена, исходя из функций, на две части: платформу электронной торговли и платформу оплаты. Здесь, платформа электронной торговли первоначально используется чтобы выполнять функции, относящиеся к «заказу», а платформа оплаты первоначально используется чтобы выполнять функции, относящиеся к «платежу». Модифицированные этапы, соответствующие решению данной заявки, являются следующими: Первая учетная запись подает заказ платформе электронной торговли; платформа электронной торговли инициирует запрос оплаты к второй учетной записи через платформу оплаты; после того как вторая учетная запись выполняет оплату посредством платформы оплаты, платформа оплаты подает обратно информацию успешной оплаты платформе электронной торговли, и платформа электронной торговли определяет, что данный заказ был успешно оплачен, и может переходить к последующему процессу отгрузки и доставки.
Здесь следует отметить, что платформа электронной торговли и платформа оплаты могут использовать разные системы учетной записи, но один действительный пользователь должен иметь межплатформенное связующее отношение (отметим, что здесь «связывание» имеет значение отличное от «связывания» в решении данной заявки) для учетной записи платформы электронной торговли и учетной записи платформы оплаты. Вследствие этого, связывание двух учетных записей в решении данной заявки может быть связыванием двух учетных записей в платформе электронной торговли, связыванием двух учетных записей в платформе оплаты, или связыванием учетной записи платформы электронной торговли и учетной записи платформы оплаты. Соответственно, связующие отношения могут быть сохранены в платформе электронной торговли или платформе оплаты, или может осуществляться их обмен и синхронизация в заданной форме между двумя платформами. Это может быть гибко сконфигурировано специалистом в соответствующей области техники при необходимости.
Соответствуя вышеупомянутым вариантам осуществления способа, данная заявка также предоставляет устройство сетевой транзакции, основанное на разделении и управлении авторизациями. Данное устройство конфигурируется на стороне системы транзакции. Как показано на Фигуре 2, данное устройство может содержать:
модуль 110 хранения связующего отношения , используемый чтобы хранить предварительно созданные связующие отношения между разными учетными записями; одна из любых двух связанных учетных записей, по меньшей мере, имеет авторизации заказа пользователя-покупателя, а другая одна, по меньшей мере, имеет авторизации оплаты пользователя-покупателя;
модуль 120 приема заказа, используемый чтобы принимать заказ, поданный посредством первой учетной записи;
модуль 130 определения учетной записи оплаты, используемый чтобы определять вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений ;
модуль 140 инициирования запроса оплаты, используемый чтобы инициировать запрос оплаты к второй учетной записи для заказа, поданного посредством первой учетной записи;
модуль 150 определения оплаты, используемый чтобы определять, что заказа был успешно оплачен, после того как вторая учетная запись подтверждает запрос оплаты.
В одном варианте реализации данной заявки, модуль 130 определения учетной записи оплаты может быть использован, чтобы:
определять, имеет ли первая учетная запись авторизации оплаты, и если нет, определять вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений .
В одном варианте реализации данной заявки, модуль 140 инициирования запроса оплаты может быть использован, чтобы:
использовать внутренние сообщения системы транзакции, чтобы отправлять сообщение уведомления о запросе оплаты второй учетной записи;
или
использовать ассоциированный режим контакта второй учетной записи, чтобы отправлять сообщение уведомления о запросе оплаты второй учетной записи.
В одном варианте реализации данной заявки, портал сокращенной операции может быть предоставлен в сообщении уведомления об оплате, используемый чтобы подтверждать запрос оплаты.
В одном варианте реализации данной заявки, связующие отношения между разными учетными записями могут содержать:
одну учетную запись с авторизациями оплаты, связанную с несколькими учетными записями с авторизациями заказа,
или
одну учетную запись с авторизациями заказа, связанную с несколькими учетными записями с авторизациями оплаты.
В одном варианте реализации данной заявки, когда одна учетная запись с авторизациями заказа связывается с несколькими учетными записями с авторизациями оплаты, заказ, подаваемый посредством первой учетной записи, может включать в себя идентификатор назначенной учетной записи с авторизациями оплаты;
Соответственно, модуль 150 определения учетной записи оплаты может быть использован, чтобы: определять вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненной информации связывания и идентификатора.
Предшествующие описания варианта реализации дают понять, что специалист в соответствующей области техники может четко понимать, что данная заявка может быть выполнена с помощью программного обеспечения плюс необходимые режимы платформы аппаратного обеспечения общего назначения. На основании такого понимания, сущность технического решения данной заявки, или часть, которая вносит вклад в текущие технологии, могут быть реализованы в форме продукта программного обеспечения. Данный продукт компьютерного программного обеспечения может быть сохранен на запоминающем носителе информации, таком как ROM/RAM, магнитный диск, или оптический диск, и может включать в себя некоторое число инструкций, чтобы предписывать компьютерному устройству (которое может быть персональным компьютером, сервером, или сетевым устройство) выполнять способы вариантов осуществления, или определенных частей вариантов осуществления, данной заявки.
Отдельные варианты осуществления в данном Описании описываются постепенно, и для вариантов осуществления достаточно ссылаться друг на друга в отношении их идентичных или сходных частей. Описание каждого варианта осуществления сконцентрировано на моментах, которыми он отличается от других вариантов осуществления. В частности, описания вариантов осуществления устройства являются относительно простыми, так как они главным образом идентичны вариантам осуществления способа, и описания коррелированных признаков достаточно посредством ссылки на варианты осуществления способов. Варианты осуществления устройства, описанные выше, являются лишь иллюстративными. Здесь, модули, описанные как отдельные части, могут или могут не быть физически отдельными. При реализации решений варианта осуществления данной заявки, функции каждого модуля могут быть достигнуты в одном и том же или нескольких единицах программного обеспечения и/или аппаратного обеспечения. Некоторые или все из модулей могут быть выбраны, чтобы достигать цели решения этих вариантов осуществления, на основании фактических потребностей. Это может быть понятно и реализовано специалистом в соответствующей области техники, без приложения творческих усилий.
Предшествующее является лишь особыми вариантами реализации данной заявки. Следует отметить, что специалист в соответствующей области техники может выполнить некоторое число улучшений и усовершенствований, не отступая от принципов данной заявки, и эти улучшения и усовершенствования должны лежать в рамках объема правовой защиты данной заявки.

Claims (37)

1. Компьютерно-реализуемый способ сетевой транзакции, основанный на разделении и управлении авторизациями, применимый к стороне системы транзакции, при этом предварительно создаются и сохраняются связующие отношения между разными учетными записями, причем одна из любых двух связанных учетных записей, по меньшей мере, имеет авторизации заказа пользователя-покупателя, а другая одна, по меньшей мере, имеет авторизации оплаты пользователя-покупателя, и способ сетевой транзакции содержит этапы, на которых:
принимают заказ, поданный посредством первой учетной записи;
определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений;
инициируют запрос оплаты к второй учетной записи на основании заказа, поданного посредством первой учетной записи;
в ответ на подтверждение запроса оплаты второй учетной записью определяют, что оплата заказа успешна.
2. Способ по п. 1, в котором этап, на котором определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений, содержит этапы, на которых:
определяют, имеет ли первая учетная запись авторизации оплаты, и если нет, дополнительно определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений.
3. Способ по п. 1, в котором этап, на котором инициализируют запрос оплаты к второй учетной записи, содержит этапы, на которых:
используют внутренние сообщения системы транзакции, чтобы отправлять сообщение уведомления о запросе оплаты второй учетной записи;
или
используют ассоциированный режим контакта второй учетной записи, чтобы отправлять сообщение уведомления о запросе оплаты второй учетной записи.
4. Способ по п. 3, в котором портал сокращенной операции включается в сообщение уведомления об оплате, выполненный с возможностью подтверждения запроса оплаты.
5. Способ по п. 1, в котором связующие отношения между разными учетными записями содержат:
одну учетную запись с авторизациями оплаты, связанную с несколькими учетными записями с авторизациями заказа,
или
одну учетную запись с авторизациями заказа, связанную с несколькими учетными записями с авторизациями оплаты.
6. Способ по п. 5, в котором, когда одна учетная запись с авторизациями заказа связывается с несколькими учетными записями с авторизациями оплаты, заказ, подаваемый посредством первой учетной записи, включает в себя идентификатор назначенной учетной записи с авторизациями оплаты;
этап, на котором определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненных связующих отношений, содержит этап, на котором: определяют вторую учетную запись, связанную с первой учетной записью, на основании предварительно сохраненной информации связывания и идентификатора.
7. Устройство сетевой транзакции, основанное на разделении и управлении авторизациями, применимое на стороне системы транзакции, при этом устройство транзакции сети содержит:
модуль хранения связующего отношения, выполненный с возможностью хранения предварительно созданных связующих отношений между разными учетными записями; одна из любых двух связанных учетных записей, по меньшей мере, имеет авторизации заказа пользователя-покупателя, а другая одна, по меньшей мере, имеет авторизации оплаты пользователя-покупателя;
модуль приема заказа, выполненный с возможностью приема заказа, поданного посредством первой учетной записи;
модуль определения учетной записи оплаты, выполненный с возможностью определения второй учетной записи, связанной с первой учетной записью, на основании предварительно сохраненных связующих отношений;
модуль инициирования запроса оплаты, выполненный с возможностью инициирования запроса оплаты к второй учетной записи, на основании заказа, поданного посредством первой учетной записи;
модуль определения оплаты, выполненный с возможностью, в ответ на подтверждение запроса оплаты второй учетной записью, определения, что оплата заказа успешна.
8. Устройство по п. 7, в котором модуль определения учетной записи оплаты выполнен с возможностью:
определения, имеет ли первая учетная запись авторизации оплаты, и если нет, определения второй учетной записи, связанной с первой учетной записью, на основании предварительно сохраненных связующих отношений.
9. Устройство по п. 7, в котором модуль инициирования запроса оплаты выполнен с возможностью:
отправки сообщения уведомления о запросе оплаты второй учетной записи, используя внутренние сообщения системы транзакции;
или
отправки сообщения уведомления о запросе оплаты второй учетной записи, используя ассоциированный режим контакта второй учетной записи.
10. Устройство по п. 9, в котором в сообщении уведомления об оплате присутствует портал сокращенной операции, выполненный с возможностью подтверждения запроса оплаты.
11. Устройство по п. 7, в котором связующие отношения между разными учетными записями содержат:
одну учетную запись с авторизациями оплаты, связанную с несколькими учетными записями с авторизациями заказа,
или
одну учетную запись с авторизациями заказа, связанную с несколькими учетными записями с авторизациями оплаты.
12. Устройство по п. 7, в котором, когда одна учетная запись с авторизациями заказа связывается с несколькими учетными записями с авторизациями оплаты, заказ, подаваемый посредством первой учетной записи, включает в себя идентификатор назначенной учетной записи с авторизациями оплаты;
модуль определения учетной записи оплаты выполнен с возможностью: определения второй учетной записи, связанной с первой учетной записью, на основании предварительно сохраненной информации связывания и идентификатора.
RU2019102204A 2016-06-29 2017-06-19 Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий RU2718175C1 (ru)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201610500388.0 2016-06-29
CN201610500388.0A CN106875243A (zh) 2016-06-29 2016-06-29 一种基于权限分离控制的网络交易方法及装置
PCT/CN2017/088944 WO2018001129A1 (zh) 2016-06-29 2017-06-19 一种基于权限分离控制的网络交易方法及装置

Publications (1)

Publication Number Publication Date
RU2718175C1 true RU2718175C1 (ru) 2020-03-30

Family

ID=59239412

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2019102204A RU2718175C1 (ru) 2016-06-29 2017-06-19 Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий

Country Status (15)

Country Link
US (1) US20190130379A1 (ru)
EP (1) EP3480768A4 (ru)
JP (1) JP2019526115A (ru)
KR (1) KR20190021417A (ru)
CN (1) CN106875243A (ru)
AU (3) AU2017287304A1 (ru)
BR (1) BR112018077343A8 (ru)
CA (1) CA3028250C (ru)
MX (1) MX2018016300A (ru)
PH (1) PH12018502746A1 (ru)
RU (1) RU2718175C1 (ru)
SG (1) SG11201811404VA (ru)
TW (1) TW201810149A (ru)
WO (1) WO2018001129A1 (ru)
ZA (1) ZA201900581B (ru)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111694892B (zh) * 2019-03-13 2023-10-03 腾讯科技（深圳）有限公司 资源转移方法、装置、终端、服务器及存储介质
CN110807689A (zh) * 2019-10-30 2020-02-18 中国工商银行股份有限公司 处理方法及其系统、电子设备和介质
CN110807636A (zh) * 2019-11-01 2020-02-18 拉扎斯网络科技（上海）有限公司 数据处理方法及装置、电子设备、可读存储介质
JP7018485B2 (ja) * 2020-07-22 2022-02-10 弁護士ドットコム株式会社 電子契約プログラム、情報処理装置及び情報処理方法
CN112184210A (zh) * 2020-09-08 2021-01-05 中国银联股份有限公司 跨网络交易方法、系统及计算机可读存储介质
CN114221776A (zh) * 2020-10-26 2022-03-22 广州融至益教育科技有限公司 应用于智能电子存钱场景中的账号绑定方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2394275C2 (ru) * 2004-10-26 2010-07-10 Дзе Кока-Кола Компани Система и способ проведения транзакций
US20140074575A1 (en) * 2012-09-13 2014-03-13 Visa International Service Association Systems and methods to program interaction with a user through transactions in multiple accounts
RU2540814C2 (ru) * 2008-11-14 2015-02-10 Мастеркард Интернейшнл Инкорпорейтед Файловая структура для упрощения реструктуризации учетной записи в системе электронных платежей
CN104636924A (zh) * 2013-11-15 2015-05-20 腾讯科技（深圳）有限公司 一种安全支付方法、服务器以及系统
US20150149358A1 (en) * 2013-11-25 2015-05-28 Apple Inc. Linked user accounts
US20150178725A1 (en) * 2013-12-23 2015-06-25 Nicholas Poetsch Transaction authorization control and account linking involving multiple and singular accounts or users
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001331758A (ja) * 2000-05-22 2001-11-30 Sumisho Computer Systems Corp 認証ワークフローシステム、認証サーバ装置、決裁に関する認証方法、記録媒体
US20020143655A1 (en) * 2001-04-02 2002-10-03 Stephen Elston Remote ordering system for mobile commerce
JP2003216880A (ja) * 2002-01-17 2003-07-31 Sony Corp 電子商取引システム、電子商取引装置、商品注文装置、電子商取引方法、電子商取引プログラム及び電子商取引プログラム格納媒体
JP2005018742A (ja) * 2003-06-06 2005-01-20 Ricoh Co Ltd 画像形成装置利用システム及びオフィス用品情報サーバ
US8145569B2 (en) * 2007-12-13 2012-03-27 Google Inc. Multiple party on-line transactions
US8930244B2 (en) * 2008-01-15 2015-01-06 Sciquest, Inc. Method, medium, and system for processing requisitions
US20100078472A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US8108977B1 (en) * 2008-10-31 2012-02-07 Metabank Machine, methods, and program product for electronic order entry
JP2010237731A (ja) * 2009-03-30 2010-10-21 Toppan Printing Co Ltd 決済方法および決済システム
US20120239560A1 (en) * 2011-03-04 2012-09-20 Pourfallah Stacy S Healthcare payment collection portal apparatuses, methods and systems
WO2012142045A2 (en) * 2011-04-11 2012-10-18 Visa International Service Association Multiple tokenization for authentication
JP6372856B2 (ja) * 2012-12-17 2018-08-15 株式会社ＡｌｉｖｅＣａｓｔ 電子商取引支援方法
US20140244481A1 (en) * 2013-02-26 2014-08-28 Timothy Onyenobi Online multi payment system
CN103280038A (zh) * 2013-05-10 2013-09-04 江苏怡丰通信设备有限公司 基于家庭网关的金融支付系统及其支付方法
CN104063791B (zh) * 2013-10-30 2016-10-19 腾讯科技（深圳）有限公司 一种安全支付方法及相关设备、系统
CN104077689B (zh) * 2013-10-30 2016-01-20 腾讯科技（深圳）有限公司 一种信息验证的方法、相关装置及系统
US20150206128A1 (en) * 2014-01-17 2015-07-23 Tycoon Unlimited, Inc. Contactless wireless transaction processing system
JP6396061B2 (ja) * 2014-03-31 2018-09-26 ぴあ株式会社 チケット販売装置及びチケット販売方法
CA2896572C (en) * 2014-07-10 2023-10-03 Mahnaz Meshkati Universal electronic payment credential processing
CN105321073A (zh) * 2014-07-14 2016-02-10 中国移动通信集团广东有限公司 一种建立账户间关系的方法、账户管理平台和系统
CN104901936B (zh) * 2014-10-17 2018-12-07 腾讯科技（深圳）有限公司 一种业务处理方法、装置、终端及服务器
CN104700271A (zh) * 2015-03-31 2015-06-10 北京奇艺世纪科技有限公司 购物订单支付方法及系统
US10163083B2 (en) * 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
CN105678553A (zh) * 2015-08-05 2016-06-15 腾讯科技（深圳）有限公司 一种处理订单信息的方法、装置和系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2394275C2 (ru) * 2004-10-26 2010-07-10 Дзе Кока-Кола Компани Система и способ проведения транзакций
RU2540814C2 (ru) * 2008-11-14 2015-02-10 Мастеркард Интернейшнл Инкорпорейтед Файловая структура для упрощения реструктуризации учетной записи в системе электронных платежей
US20140074575A1 (en) * 2012-09-13 2014-03-13 Visa International Service Association Systems and methods to program interaction with a user through transactions in multiple accounts
CN104636924A (zh) * 2013-11-15 2015-05-20 腾讯科技（深圳）有限公司 一种安全支付方法、服务器以及系统
US20150149358A1 (en) * 2013-11-25 2015-05-28 Apple Inc. Linked user accounts
US20150178725A1 (en) * 2013-12-23 2015-06-25 Nicholas Poetsch Transaction authorization control and account linking involving multiple and singular accounts or users
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器

Also Published As

Publication number Publication date
EP3480768A1 (en) 2019-05-08
SG11201811404VA (en) 2019-01-30
EP3480768A4 (en) 2020-01-15
CA3028250A1 (en) 2018-01-04
PH12018502746A1 (en) 2019-10-14
KR20190021417A (ko) 2019-03-05
CA3028250C (en) 2021-05-04
AU2017287304A1 (en) 2019-01-17
BR112018077343A2 (pt) 2019-04-02
ZA201900581B (en) 2021-03-31
JP2019526115A (ja) 2019-09-12
WO2018001129A1 (zh) 2018-01-04
AU2019101569A4 (en) 2020-01-23
CN106875243A (zh) 2017-06-20
AU2020250277A1 (en) 2020-11-05
US20190130379A1 (en) 2019-05-02
BR112018077343A8 (pt) 2023-04-25
TW201810149A (zh) 2018-03-16
MX2018016300A (es) 2019-10-14

Similar Documents

Publication Publication Date Title
RU2718175C1 (ru) Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий
JP6858493B2 (ja) リソース転送システム
US10592985B2 (en) Systems and methods for a commodity contracts market using a secure distributed transaction ledger
TWI640937B (zh) Online payment method and equipment
US8626596B2 (en) Online transaction method and system using a payment platform and a logistics company
CN110458562B (zh) 票据报销方法、装置和设备及计算机存储介质
JP7162587B2 (ja) 注文情報処理方法、装置およびシステム
US20190197511A1 (en) Method and apparatus for processing information
US11908004B2 (en) Method and system for obtaining credit
TW201802741A (zh) 訂單信息處理以及訂單類型轉換處理方法及裝置
KR20200000595A (ko) 블록체인에 기반한 증서 관리 방법 및 이를 위한 장치, 서버 및 시스템
KR20130083050A (ko) 가상계좌를 이용한 금융기관납부대행시스템 및 그 제어방법
CN115983853A (zh) 基于区块链的客户侧绿电应用服务方法、系统及电子设备
CN104835034A (zh) 可实现资金自动划转的注册与划转方法
KR102381697B1 (ko) 블록체인 기반 재화 계약 서비스 방법 및 장치
US20140201059A1 (en) Prepaid multinational program
JP2022011103A (ja) 仮想通貨を用いたエスクロー処理方法、システムおよびプログラム
Balderas PayPal APIs: Up and Running: A Developer's Guide
JP2023500206A (ja) 取引方法、装置、デバイス及びシステム
JPWO2020040070A1 (ja) トランザクション処理方法、システムおよびプログラム
CN113763058A (zh) 跨系统实现业务交互的方法和装置
WO2017012022A1 (zh) 电子凭证的开证方法、数据交互处理方法、装置和系统

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20210303

PC41 Official registration of the transfer of exclusive right

Effective date: 20210414