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

Чертежи

Описание

По данной заявке испрашивается приоритет Китайской Патентной Заявки Номер 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, магнитный диск, или оптический диск, и может включать в себя некоторое число инструкций, чтобы предписывать компьютерному устройству (которое может быть персональным компьютером, сервером, или сетевым устройство) выполнять способы вариантов осуществления, или определенных частей вариантов осуществления, данной заявки.

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

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

Реферат

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

Формула