RU2686618C1 - Method of providing user access to services of local service operator, user terminal device and system server for implementation of method - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to providing user access to services of local service operator. Disclosed is a method of providing user access to services of a local service provider, comprising: in universal ticketing system centralized collection and storage in a single database of information relating to conditions for providing services of multiple local service delivery systems, controlled by local operators of service delivery systems, where services are provided at location of user; for a local service provision system selected by a user from a plurality of local service delivery systems, transmitting to a user a set of access rules for services of a local service provision system, stored in a single database, where a set of rules contains a mandatory set of rules; requests user consent for compliance with a mandatory set of rules; selecting, upon agreement with the user, a set of additional rules, with the consent of the user, selecting a storage medium for storing user identification data, verifying the user's ability to comply with a mandatory set of local operator rules, registering a user in the local system of the local operator using the user's identification data; when the user is in the service rendering zone, the user identification data are read from the selected data medium, the user registration with the read identification data in the local service provision system is verified, and when the user logs on in the local service provision system, the user selects the service in accordance with an additional set of rules and with compliance checking of at least one of the rules from the set of mandatory rules.

EFFECT: high security of the system while improving reliability of counterfeit protection.

29 cl, 12 dwg

Description

TECHNICAL FIELD

The invention relates to the field of network communications and can be used for user access to services without significant territorial restrictions, in terms of the place of ordering services and the location of enterprises providing services. Among other things, the system allows the user to ensure unhindered use of vehicles, both on a predetermined route and when changing the user's route.

BACKGROUND

Known systems, such as the Moscow Transport System, use special information carriers, for example, the Troika card or a special SIM card, to provide transportation services. The said Troika card can be used to provide services of other transport systems, for example, a commuter train system, but the infrastructure of this transport system is used to access the services of the corresponding transport, ticket or other service system, and the Troika card is used only as information carrier.

In most cases, the user is forced to use the ticket carrier indicated by the owner (operator) of the ticket system (QR, barcode, numeric code, special paper or plastic cards, etc.), which creates significant inconvenience and can be optimized due to the new approach to application of modern contactless technologies based on open standards.

The closest to the proposed technical solution is the invention according to the Eurasian patent EA004994, published 10.28.2004. This patent describes an invention that allows the use of one system to provide access to several services. At the same time, in a well-known technical solution, a storage medium provides access only to transport services of one system, and information providing access to other services is provided only on the basis of identification data printed on the travel document. The authenticity of the data or media is not verified.

Thus, in the level of technology there are no means to ensure the convenient integration of various transport, ticket and other service systems, and to ensure a high level of integrated security in terms of unauthorized access to transport, ticket and other service systems.

ESSENCE

The present invention is intended to eliminate this and other shortcomings of the prior art, as well as to achieve a technical result consisting in increasing the security of the system, both from the point of view of the end user and from the point of view of systems in which, using the proposed invention, reliability protection against fakes. In addition, the proposed system provides the ability to integrate transport, ticket and other service systems without making changes in their functionality, and also does not require the release of special identifiers or storage media.

The present invention reduces the cost of issuing identification means and travel documents, reduces the number of transactions performed by users when ordering and receiving services, and reduces the number of valid identifiers that, in the particular case, are carriers of tickets of all form factors, for example, transport cards, printed tickets, one-time tickets with magnetic stripe and chip, providing access to services, provides a high degree of protection against their use by unauthorized persons, as well as gives you the opportunity to take a fee for services (including transport) in the mode of maximum automation.

To achieve this technical result in the method of providing user access to the services of a local service operator in the universal ticket processing system, centralized collection and storage of information related to the conditions of service provision of multiple local service systems managed by local service providers is carried out in a single database, where Services are provided at the location of the user; for a local service delivery system selected by a user from a variety of local service delivery systems, they transfer to the user a set of access rules to the services of the local service delivery system stored in a single database, where the set of rules contains a mandatory set of rules; requests the user's consent to comply with the mandatory set of rules; choose, in agreement with the user, a set of additional rules, with the user's consent, choose a storage medium for storing the user's identification data, check the user's ability to comply with the mandatory set of rules of the local operator, register the user in the local system of the local operator using the user's identification data; when a user is in the service area, they read the user's identification data from the selected media, check the user registration with the read identification data in the local service delivery system, and when the user registers in the local service delivery system, at the user's choice, provide the service to the user in accordance with the additional set of rules and verifying compliance with at least one of the rules from the set of mandatory rules.

In the particular case, the service is a transport service.

In the particular case, the transport service is reusable.

In the particular case, the transport service is the transportation of the user.

In the particular case, the transport service is a pass for a toll road.

In the particular case, the transport service is a pass to the parking of vehicles.

In the particular case, the user identification data is part of the user account details in the bank issuing the user account.

In the particular case, part of the bank details of the user’s account are the details of the bank card linked to the user’s account.

In the particular case, part of the bank details of the user’s account is a unique token linked to a bank card linked to the user’s account.

In the particular case, the universal ticket processing system token is an identifier tied to a bank card tied to the user's account.

In the particular case, the selected storage medium is a portable data storage device made with the possibility of non-contact reading of data.

In the particular case, the portable storage device is a contactless bank card of the user.

In the particular case, the portable storage device is the user's device.

In the particular case, when the user is in the service area, after reading the user's identification data, the validity of the user's bank details is additionally checked, and the service is provided only for the user with valid bank details.

In the particular case, the validity of the user's bank details is verified and confirmed by the acquirer bank servicing the local service delivery system.

In the particular case, to ensure user access to the local system's equipment, a wireless connection of the storage medium and the computing means of the local system used in verifying the identification code is used, and the specified wireless connection is set up in advance.

In the particular case, the user is connected to the universal ticket processing system via the Internet using the user's terminal device by binding a bank card.

In the particular case, if it is necessary to access the services of a local operator, the user's terminal device transmits through the contactless data transmission device, the identification code and the code set of data to the local system, the local system requests the acquirer of the local system to confirm the validity of the bank details of the user with the transmitted identifier, and For a user with valid bank details, services are provided.

In the particular case, verification of the validity of the user's bank details is carried out by the payment system when registering a bank card in the universal ticket processing system.

In the particular case, when ordering a service by a payment system, the validation of the bank details of the user is repeated.

In the particular case, if the service is connected, the bank, the acquirer servicing the local operator, when checking the validity of the bank details of the user's bank card user connected to the universal ticket processing system, sends a request to the universal ticket processing system about the user of the purchased ticket to provide the service user and the user tied to the account, and if the ticket is available, the universal ticket system th processing provides the user with a service without debiting the account user, where the system of universal ticket processing calculates a local operator, acquirer bank and the issuing bank under such an exchange of data between the bank and acquirer processing system of universal ticket.

In the particular case, if the service is not connected, the data exchange between the acquirer bank and the bank issuing the user’s account is carried out, while the acquirer knows that the terminal devices of the local operators are relevant organizations and, if the organization is connected to the universal ticket processing system, the issuer notifies the universal payment system ticket processing about the provision of a one-time service for the implementation of the generation of a ticket for such a one-time service.

In the particular case, the acquirer bank and local operators are connected to the universal ticket processing system using the interface provided by the universal ticket processing system or, in the case of the bank providing the acquirer and local operators, their own interfaces, the universal ticket processing system is connected to the acquirer bank and local operators such interfaces provided

In the particular case, for information exchange between the participants of the universal ticket processing system, an intrasystem identifier is used that is different from a bank card identifier, which is the user's identification data in the user account details in the issuing bank of the user account, and the hash sum calculated using the PAN bank card.

In the particular case, the user’s e-mail, the user's mobile phone number and / or the user's personal account in the universal ticket processing system are used to inform the user about the completed operations, business and business information.

In the particular case, the terminal devices of local operators interacting with a bank card tied to the user's account are devices of the acquirer bank or devices of local operators connected to the universal ticket processing system.

In the particular case, a code set of data characterizing the verified details of the user's account is formed, ensuring unconditional payment between the acquirer bank, the local system and the issuer bank corresponding to the user's account details, while simultaneously registering the user's account details in the local operator's system.

To achieve the above technical result, a portable device has been proposed for providing user access to equipment of local operators of local systems, comprising an information input unit, an information output unit, information processing means, and means for accessing a central server, wherein the device contains means of authenticating the user according to the results of interaction user with means of entering information, and the information processing unit is made forming the output displayed on the tool information of the local systems list, with the possibility for the user to select a local system, while the portable device is configured to receive from the central server a mandatory set of rules for access to the equipment of the local system chosen by the user, display on the information display tools and obtain the user's consent rules are selected from a single database of information relating to the conditions of transportation of local systems formed locale by the operators of the systems for a local system selected by the user, the portable device is configured to store data on the storage medium to store the user's identification code, to ensure that the central server can request the user to register in the local system and form a reminder that the user is provided with the local service operator is carried out using the storage medium, according to the results of at least one mandatory rules from a set of mandatory rules.

To ensure the above technical result, a server for providing user access to local system equipment is proposed, containing data transfer means of data processing and means of filling and storing a single database of information relating to the traffic conditions of local systems formed by local system operators and centrally collected from using the means of data collection, while the server is made to provide sampling and transmission, upon user request, about the set of rules for access to the local system equipment stored in a single database, the choice of the corresponding rule set, the storage medium for storing the user's identification code, checking the user's ability to comply with the set of mandatory rules of the local operator, user registration in the local system ensuring that the user is provided with local operator using the media, according to the results of at least one mandatory rule from the ora mandatory rules.

BRIEF DESCRIPTION OF THE DRAWINGS

Additional objectives, features and advantages of the present invention will be clear from reading the following description of the embodiment of the invention.

The proposed invention is illustrated by drawings:

FIG. 1 illustrates an exemplary version of the System described in the present invention, or at least part of such a System.

FIG. 2 illustrates an approximate variant of the interaction of the described System with the user (users) and Operators (local operators) of local servers in cities.

FIG. 3 illustrates an exemplary communication option of the described System and local operators (operators of local systems, operators of local servers).

FIG. 4 illustrates an approximate version of the interaction of the described system (UBS), user, organization (credit organization), attracted by the operator of the local server and UBS tools (for integration with the credit organization).

FIG. 5 illustrates a rough version of ticket processing.

FIG. 6 illustrates an exemplary version of the interaction scheme of the main functional participants of the transaction in the framework of the UBP.

FIG. 7 illustrates one of the exemplary variants of the scenarios for the operation of universal ticket processing (ATM), in particular, shows an exemplary scenario of registering a PAN (bank) card and creating a Token in the UAB.

FIG. 8 illustrates one of the exemplary variants of universal ticket processing scenarios, in particular, shows an exemplary variant of the binding of the Ticket to the identifier (issue and loading of the Ticket Token to the user terminal with NFC).

FIG. 9 illustrates one of the exemplary variants of the universal ticket processing scenarios, in particular, shows an exemplary variant of the binding of the ticket to the identifier (issue of the Ticket Token without downloading it).

FIG. 10 illustrates one of the exemplary variants of the universal ticket processing scenarios, in particular, shows an approximate variant of the Ticket Token validation scenario.

FIG. 11 illustrates one of the exemplary variants of universal ticket processing scenarios, in particular, an exemplary variant of the ID validation scenario is shown.

FIG. 12 illustrates an example of a general-purpose computer system.

DETAILED DESCRIPTION

The objects and features of the present invention, methods for achieving these objects and features will become apparent by referring to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it may be embodied in various forms. The entity described in the description is nothing but specific details provided to assist a person skilled in the art in an exhaustive understanding of the invention, and the present invention is defined only in the scope of the appended claims.

Used in the present description of the invention, the terms "component", "element", "system", "module", "part" and the like are intended (used) to refer to computational entities, in particular, computer entities (computational entities, entities or objects related with a computing device, such as a computer, a computerized device, an automated device, etc.), which may be hardware, equipment (for example, a device, instrument, apparatus, apparatus, part of the device, in particular, a processor, microprocessor, printed circuit board, etc.), software (for example, executable software code, compiled application, software module, part of software and / or code, etc.) or firmware (firmware from English firmware). For example, a module (component, etc.) may be a process running (executing) on a processor, a processor, an object, an executable file, a program, a function, a method, a library, a subroutine, and / or a computing device (for example, a microcomputer or computer) or a combination of software or hardware. By way of illustration: as an application running on a server (for example, on a central server (151, FIG. 1)) can be a component or a module, or a server can be a component or a module. At least one component can be (located) inside the process. A module (component, etc.) may be located on a single computing device (for example, a computer) and / or may be distributed between two or more computing devices. For example, in a particular case, an application (for example, a module, a component, etc.) can be represented by a server module (server part) and a client module (client part). In the particular case, the client module is installed on at least one computing device, and the server module is installed on the second computing device, from which, in the particular case, control, tuning, etc. are performed. the first computing device (and / or its composite modules (components, parts, etc.)).

In some cases, the following terms and abbreviations are used in the description of the invention:

The system (100, FIG. 1) is a set of ordered hardware and software tools that support the process of issuing, receiving, recording, trading, replenishing, writing off obligations identifiers for automated access to services, including transport services.

A ticket is a carrier of information or an information block certifying the right to use the services indicated when issuing a Ticket. The ticket can be printed on paper or similar media, or executed in electronic form, including as a record in the database (for example, in the database 161 (FIG. 1) associated with the central server 151 (FIG. 1)).

Connection form - a data set presented in an ordered form identifying the User (212, FIG. 2), representing his personal data and preferences, and confirming the User’s desire (212, FIG. 2) to use the proposed System (100, FIG. 1) on the conditions reflected in the connection form.

User (212, FIG. 2) - an individual using the user's terminal device (131, FIG. 1) or third-party systems connected to the System (100, FIG. 1) in order to receive services (including, but not limited to, transport, ticket and other services) from enterprises that actually provide them, for example, third-party systems, including those including, but not limited to, third-party transport, ticket or other service systems.

User ID in the System (100, FIG. 1) - a set of data that uniquely identifies the User (212, FIG. 2) in the System (100, FIG. 1). The specified set of data can correspond one-to-one to a unique data carrier, for example, be stored on the terminal (in particular, personal) user device (131, FIG. 1), including on a bank card similar to a smart card, with a chip, including the number supporting the implementation of contactless interaction, on the user's terminal device (131, FIG. 1) with a contactless module or another interface for interacting with public networks.

Tariff is a rate or rate system for various services provided by companies, organizations, firms and institutions.

A token is a collection of data that makes it possible to receive a service when presented. In the context of the present invention, the service is debiting funds from a predetermined account (bank, individual, special, etc.) linked to a bank card (101, FIG. 1) and / or a user's terminal device (131, FIG. 1) for example , a smartphone or other device, in particular, working on a contactless interface owned (owned) by the user (212, FIG. 2). Technologically, for the successful implementation of a token, it is necessary to have a trusted center certifying the validity of the token and ensuring the withdrawal of funds from the account tied to the token, in particular, in order to receive it, to receive the service.

In FIG. 1 shows an exemplary embodiment of a system 100 implementing the described invention or at least a part of the described invention. The proposed system (Universal Ticket System) 100 implements Universal Ticket Processing (600, FIG. 6), hereinafter the ATM. The UBP allows users of the system 100 to remotely (remotely) purchase a ticket with the ability to bind a previously purchased ticket to a user's (own) unique identifier (ID) (bank card 101, user terminal 131 with NFC technology). communication, “near field communication”, “near contactless communication”, a data transmission system using electromagnetic fields of near action), or any other medium, including the payment Token of payment systems 545 ( FIG. 5), in particular, the Payment Token of International Payment Systems (hereinafter referred to as MPS)), using funds that can be used as user’s terminal devices 131, as well as a central server (central system server, system server, service server, central server services, centralized server (systems, services)) 151, designed for hardware performance of certain functions relating to the essential features of the proposed invention. Such mentioned user terminal devices 131 may be various (including digital, analog, combined, mechanical, etc.) devices, in particular, but not limited to, electronic devices. For example, such user terminal devices can be personal computers, electronic computers (computers), laptops, servers, workstations, all-in-one computers, computer stands, banking and vending payment terminals, desktop computers, test benches, demonstration computer stands, tablets, smart phones, mobile (cell) phones, satellite phones, personal digital assistants (PDA), “smart” (smart) things, such as watches, bracelets, pendants, clothes, such as belts, headgear Ora, etc.

To the described System 100, a user (212, FIG. 2) is connected (and disconnected) using the user’s terminal device 131 via the Internet 121 by linking his bank card 101. For example, the user (212, FIG. 2) may use the terminal device a user 131, for example, a computer, a user's mobile device, another form of interface, for example, an office of an agent, with a computer installed, which are a means of interacting with ATMs via a thin client (635, FIG. 6).

It is also worth noting that the described invention can be realized by a network service and, in a particular case, is intended for users (212, FIG. 2) using the contactless payment technology (EMV Contactless), and the contact form bank card and Token Contactless bank card, placed on any carrier, this allows (user terminal 131, for example, smartphone, mobile phone, smart watch, belt, etc.)

System (Universal Ticket System) 100 is a unified network information platform for ticket and accounting operations, allowing Users (212, FIG. 2) of System 100 to use (own) unique user identifier (unique personal identifier, unique user ID (212, FIG. 2 ), user ID, personal identifier, personal ID of the user, own unique identifier (user)), in particular, using the system identifier (user), as more under upgrade equ described in the context of the present invention to access all tickets, implemented, connected thereto Operators local transport, ticket, or other service systems (222, FIG. 2).

The central part of the UBP is the UBP core 111 - a functional module of the central server of the system 151 that performs the function of generating a unique Ticket Token (hereinafter - BT) consisting of the provided unique user identifiers (in particular, PAN number of the bank card, UID card, payment Card Token on the terminal device 131 user with NFC technology, etc.) and Ticket parameters of a specific merchant service provider (from English Merchant - merchant, trader, merchant), which is a local operator of transport systems (he the local server operator, in the particular case, the issuer of the ticket, or an organization attracted by the merchant, for example, to provide such information and technical activities) and such parameters may include cost, date of purchase, validity period, scope, number of trips, balance , a set of services, place of use and other details). The kernel UBP (service generation tokens (issuing banks (675, FIG. 6)), service generating unique ticket tokens) 111 checks for consistency (and this match is the bundle of the unique user identifier with the BT number in the database) of the unique user identifier previously generated BT, carries out (carries out) checks the validity of the unique user identifier, makes account of BT, in particular, records in the database. In the particular case, the mentioned verification of the validity of a unique user identifier is carried out using the Luna algorithm (Luhn) or another algorithm, including using HASH. The kernel UBP re-issues BT (in particular, by generating a new BT on the basis of the old one with its replacement in the database, as well as in accordance with at least one UBP rule, in particular to control the circulation of the BT and antifraud). . anti-fraud)) after each perfect operation in the process of implementation of which BT is used or redeemed (in particular, activated). The bank card identifier is used to work with the bank card (in particular, with the (bank) account of the user (212, FIG. 2) with which the bank card is associated), and this bank card identifier differs from the intra system identifier (user), which in private case is the HASH-sum (cryptogram) of a bank card (HASH-sum calculated for a bank card, for example, for a bank card number, CVV2 code, CVC2 code, etc.) and used in the information exchange between the System participants (100 , FIG. 1), as described in the framework of the present invention. It is worth noting that other intra-system identifiers (intra-system user identifiers) can be used, and, in a particular case, the main internal system identifier can be a PAN (Primary Account Number, payment card number) of a bank card in one of the known or invented later forms.

Universal ticket system (universal ticket processing system 100 that implements the proposed method, which uses the user terminal 131 and the central server 151, while the user terminal 131, made with the possibility of uninterrupted access to the central server 151 transport, ticketing services or other services made with providing access to servers of local transport, ticket and other service operators (242, FIG. 2), in particular, by means of exported and and interfaces that use terminal terminals 141 that support standard contactless interfaces.In a particular implementation, data is exchanged (conducted) over the contactless interface of the terminal 141 through which the ticket is purchased (purchasing at least one ticket). In addition, the central server 151 has the ability to collect information regarding payment options, destinations, discounts, seasonal rates and documents, based on toryh granted privileges. In addition, the central server 151 may be used as a proxy server for parsing and analyzing (parsing) typical user requests (user requests). To connect to the ATM, the local system (transport, ticket, etc.) can join the standardized interface of the ATM, or open access to its (local) servers (242, FIG. 2) through the central server 151 in proxy mode. In the particular case, with an “autonomous” connection, in particular, in the absence of a local system operator or its failure or disconnection or suspension, etc., the central server (services) 151 can collect and process information from open sources set by the corresponding regulator (640, FIG. 6), in particular, by the executive authorities (OIV) (645, FIG. 6), administration, departments and other management and regulatory bodies, including tariff policies, such as information such as schedules and P nkty purpose, the cost of travel documents and other things. Thus, the local server of the operator, in particular, the server of the ATM, is designed with the ability to collect, store and transfer to the user a set of rules for access to local transport, ticket and other service operators (222, FIG. 2). The mentioned access rules include cost, duration, mode of operation, rules for using services, parameters for providing ticket services, in general, the tariff menu for all services of the local operator. In addition, when the access rules were changed, the central server 151 was made to generate notifications if the user (212, FIG. 2) made or chose a local transport, ticket or other service operator (222, FIG. 2) according to the old rules. In the particular case, the difference between the mentioned old rules and the set of rules for access to services of local operators includes changing the terms of use, for example, validity period, cost, procedure for obtaining the service, etc. When the user selects (212, FIG. 2) the user’s terminal device 131, at least one transport, ticket or service system to be accessed, the user’s terminal device 131 is formed by interacting with the central server 151, a list of rules defined by the corresponding m local transport operator (222, FIG. 2), and requests the user's consent (212, FIG. 2) of the user's terminal 131 for compliance with the rules (in particular, the description of the procedure for authorizing payment for the selected service), and, with the user's consent (for example implemented by the user (212, FIG. 2) using the user’s terminal device 131, in particular, through user interaction (212, FIG. 2) with an application installed on such a user terminal 131, for example, using a graphical Who the user interface (GUI, GUI, from the English. graphical user interface) of the application), checks the possibility of compliance with the rules. Thus, the user (212, FIG. 2) selects which of the identifiers, for example, a bank card or token in the user's terminal device, selects the city and type of service, in particular, from those available (which particular case, are local operators), after which the procedure of writing off the cost of the service and generating a ticket on the basis of a confirmed payment and the subsequent linking of the ticket to a bank card or bank card token on the terminal device is carried out Household users. The user interface in a mobile application or via a web portal (in particular, a web site) allows you to display all connected transport or other systems to the ATM to a user. In the particular case of implementation, the terminal device of the operator 141 is configured to collect and store user data (212, FIG. 2) relating to the rules and requirements of the local (transport, ticket or other service) operator (222, FIG. 2), comparing stored user data (212, FIG. 2) and the requirements of the local operator (222, FIG. 2), as well as the choice of the most economical tariff plan of the local operator (222, FIG. 2). In the particular case, the above comparison is a check on the side of the local operator for the presence of a ticket tied to a specific unique user identifier without online access to the ATM and in order to check the unique user identifier and its validity. These requirements may relate to the processing of personal user data or other (open) data, in particular, a unique user ID.

The user profile (212, FIG. 2) stored in the OCD database that serves the services of (local) operators (222, FIG. 2) seasonally (for example, a trip every Friday in the evening outside the city in the summer time) or a user profile (212, FIG. 2), which orders the services of operators strictly on working days during fixed hours, for such users (212, FIG. 2) an optimal service package can be formed, and the most attractive service intervals can be offered and corresponding mo incentive mechanisms, both financial and loyal, for example, reducing the cost of services, or providing services in a priority mode. If it is necessary to have documents to use the discount plan, the user’s terminal device 131 is formed to form a reminder (for example, in an application, by sending an e-mail to the user's email (212, FIG. 2), etc.) about the need to have these documents in trip. The data in the user profile is added automatically in accordance with the purchases made and the actions of the user. In addition, the user terminal 131 is configured to freely change the serving local transportation, ticket or other service system, if there are alternatives. For example, moving by long-distance or regular bus, or using subways or commuter trains.

If necessary, using the terminal device of the user 131, the choice of tariff is ensured. Advantageously, the user terminal 131 is used as a remote workstation for tariff selection tools installed on the central server (system) 151.

System 100 provides the User (212, FIG. 2) a connection form for linking the user's device (bank card or other smart card with a chip, including contactless, user terminal 131 with a contactless module or another interface for interacting with public networks or other devices simulating them) as a carrier user identifier in System 100, which is a special case of the intra-system user identifier (212, FIG. 2).

In the particular case of implementation, the payment is made by the user (212, FIG. 2) in the mode of direct debiting of funds by the processing center of the local system chosen by the user, and payment for services of local operators (222, FIG. 2) is made (performed) in an automated mode by transferring funds from user in the UBR, and from the UPS system 100 to the local operators (222, FIG. 2) with the generation of a one-time identifier of the rendered service in the system 100. In this case, the local operators (222, FIG. 2) are registered in the system 100 with an increased enyu protection and responsibility (according to the rules IPU) to the user (212, FIG. 2) carries a merchant (local operator, the terminal operator), which can be accomplished using the system (means) PayPass with generation single ticket in the FSM. Passing through a bank card to which there are no currently linked services is carried out at the cost of a one-time tariff of a local operator with generation and cancellation of one ticket at the time of payment. In the general case, the said one-time identifier of the rendered service is a transaction identifier that combines the issue of a one-time ticket, its payment and redemption, and this identifier is used in the UPS system and is stored in its database. In another embodiment, the system 100 stores user account data (user accounts (212, FIG. 2)) and provides the processing centers with local transportation, ticket or other service systems upon request, and the user (212, FIG 2) confirms that it is possible to write off means (for example, by using the user terminal 131, in particular, using an application installed on the user terminal 131).

In the particular case of implementation, the user terminal 131 (using software and hardware, in particular, modules, for example, using the GPRS module and corresponding software for it) determines the location (in particular, geolocation) of the user (212, FIG. 2) (in particular, the terminal device of the user 131), and provides a comparison of the location (location geodata) of the user (212, FIG. 2) with the location of the local transport, ticket or other service system or kta local transport, ticket or other service system, and offers (for example, in the application, on the website, etc.) the best tariff and information about the operator of local systems in accordance with the (approximate) location of the user (212, FIG. 2 ).

Each user (212, FIG. 2), when connected to System 100, is assigned an in-system identifier (hash sum (from the English HASH) of data generated by the system 100 according to a specific algorithm) used to identify the user (212, FIG. 2) within systems (transport, ticket or other service systems, including local systems and system 100) without disclosing its unique user identifier (212, FIG. 2) registered in system 100 (bank card and / or other media that allows issuing payment functionality of the bank a local transport, ticket or other operator (222, FIG. 2) is provided with a ready identifier for registration (which may be a masked bank card number or bank card UID (chip number) or a bank card Token), for example, ready tamper-proof access device, for example, open contactless smart card data.

In a more sophisticated version, the unique user ID (212, FIG. 2) provides access to ATM services that provide automated ordering of services, their accounting and replenishment of service limits, selection of accounting treatment for services, in accordance with predefined rules, automatic balance replenishment, ticket validity, including instant recurrent payment, etc.

After selecting the fare and the transport, ticket or other service system, the guaranteed users are formed (212, FIG. 2) and the system 655 for providing technical functionality of the ticket processing, the amount of payment and the volume of services provided, respectively. Transport, ticket or other service systems (systems of local operators) within the framework of the formation of guaranteed conditions and a set of rules may be several, in particular, within the framework of the formation of a set of rules. The application (installed on the user's terminal 131) can provide the user (212, FIG. 2) with the option of “seamless” (without additional operations by the user) changing transport, ticket or other operators when traveling along a certain route.

In the particular case, the operator may be the owner of the toll road, the operator of tickets for entertainment events, etc. This approach provides the ability for the user (212, FIG. 2) to obtain a multifunctional media of access to the service, expanding the possibilities of domestic tourism and provides high mobility when configuring orders for complex services.

During the journey, the application (in particular, the mobile application) installed on the user’s device 131, tracks the user's movements (212, FIG. 2) and, in accordance with the geodata (in particular, the user's location (212, FIG. 2), in particular, the user’s terminal 131) notifies the user (212, FIG. 2) of the availability of a transport, ticket or other service operator selected by the user (212, FIG. 2) and the location of the stop or terminal of the operator 141. In the particular case R The operator can be selected (for example, by the user, in particular, in the application) in advance, but the prepayment of services or the payment limit can be made “on site”, for example, in the disembarkation zone upon completion of the service in case of a zonal tariff, where the actual cost of the service is determined either by paying for the ticket when attending the event, for example, hourly or per minute.

Before using a transport, ticket or other service operator, a unique user identifier (212, FIG. 2) is activated in system 100. In the particular case, the activation of a unique user identifier is performed by checking, for example, using 3D secure technology, a bank card or a bank token cards in the device supporting NFC in the issuing bank, to confirm that the bank card is not blocked and not stolen. In the particular case, the central server (151, FIG. 1) introduces a unique user identifier and intra-system identifier to all end-user devices 131 and end-user devices 141, which in the particular case are POS terminals (newpos, verifone and others), mPOS terminals, transport validators and other automated workplaces. It should be noted that the terminal devices of the operator work (interact) with a (real) bank card (101, FIG. 1) as a carrier of the user's unique identifier (ID) and services available to the user (access to the service), and are devices of the acquiring bank ( 610, FIG. 6), or the operator (222, FIG. 2) of a local transportation, ticket or other service system that is connected to the UPS (100, FIG. 1).

In the particular case, the user's TIN (in particular, using the UBP interfaces) or another unique identifier (personal identifier, personal key, personal code), for example, is tied to a unique user identifier (212, FIG. 2) in the system (UBP) 100 SNILS (insurance number of an individual personal account), phone number of the user, e-mail address, etc., allowing the user to receive fiscal documents (in particular, generated using the fiscalization system (665, FIG. 6)), in particular , fiscalization tools, and sent by the central server 151, and the system (100, FIG. 1) report on the services provided to the user, for example, creating documents to report to the user (check, information about the service provided, etc.).

When accessing services such as a transport operator, the user (212, FIG. 2) uses a unique user identifier and intra-system identifier, the system provides services. There is a write-off of "conventional units" (units of the tariff menu of the local operator) and a corresponding decrease in the balance by the sum of units (quantity) corresponding to the services provided. In the particular case of implementation, write-off and payment can be made according to predetermined rules (in particular, stored in the user profile and the tariff menu in the UPS), for example, once every hour and a half, once a day, once a week or a month. The user (212, FIG. 2) may be provided with an advance on services, not confirmed by immediate payment. Some features, for example, the possibility of deferred direct debiting of funds or changes in the user's balance in ATMs may exist due to the possibility of temporarily disconnecting the user (212, FIG. 2) or terminals (for example, transport terminals, etc.) from the transmission network data, i.e. lack of continuous communication with the DSS.

In particular cases of implementation, a bank card or another smart card with a chip, a contactless smart card, user terminal 131 with an NFC module or other access to public networks (from English Public data network). In the particular case of implementation, the network configuration of the transport terminal can be made in advance and remotely. For example, a Bluetooth connection can be configured in emulation mode or registered in the operating system’s user’s registry (131, FIG. 1), or configured to connect to a wired or wireless network, for example, using a wi-fi connection, transport, ticket or another service system to which the terminal device of the operator 141 is connected, in particular, the terminal terminal of the local operator system, for example, a POS terminal.

In the simplest case, the user (212, FIG. 2) selects the tariff using the user’s terminal device 131, payment is made in pay-as-you-go mode, using the payment system tools available to the operator’s terminal device 141, in particular, to the terminal local operator, online or offline (offline).

In a more sophisticated version, the user terminal 131 contains a protected memory area certified for the selected operator, which stores information about the previously paid by the user but not fulfilled obligations of local operators (units, tickets, etc.) available to the user (212, FIG 2). In a more complicated case, the user terminal 131 contains data structures in a protected area of memory that provide automated payment and replenishment of the number of service units, the choice of the order of writing off service units (transport units, conventional units), in accordance with predefined rules.

The procedure for refund for unused services can be determined by the system (ATM) 100 and selected by the user (212, FIG. 2) from the conditions previously defined by the parties.

In the particular case of implementation, payment for services and / or their sets can be made in cash at the terminals or at ATMs with cash intake, and their accounting through interaction with terminal devices (user terminal devices 131 and / or operator’s terminal devices 141) connected to System 100.

In the particular case of implementation, payment for services and / or their sets can be made in cash at the terminal device of the local operator of a transport, ticket or other service system or at an ATM with cash intake.

It is worth noting that in the particular case, the described system 100 keeps records of all operations performed by participants (for example, users, local operators, banks, etc.), both purchase and validation operations (in particular, fixing the fact of provision of services), This information exchange is taken into account in the unchangeable logs of completed transactions in the system 100 and is converted by the system 100 into a human-readable language, for example, in the form of registers and reports (in particular, for each participant in the system, its own set of registers and reports) available for each The system 100 is using system tools, in particular, on the basis of registers and reports, there is (is) the formation of receivables and payables between participants of the system (and system 100), and (respectively) and financial liabilities, settlement between the operator and local systems, the acquirer bank and by the issuer bank (in the particular case, being a user) is carried out in the manner and under the conditions fixed in the open offers of the system or within the framework of concluded local contracts.

In FIG. 2 illustrates an exemplary interaction of System 100 with user (s) 212 and Operators (local operators) 222 local servers 242 in cities.

The user 212 registers (262) his unique user ID in the system 100 through the Connection Form to the system 100 and selects a set of services (Tickets).

System 100 uses a user device (supporting an intrasystem user identifier, in particular, a user identifier in System 100), in particular, a user's terminal device (131, FIG. 1) providing access to the central server (System) 151 and registered in System 100, which allows the user (212, FIG. 2) to access the service previously ordered through the System 100 from the local system Operator (local system operator, local server operator) 222.

 The central server (Systems) 151 has access to the servers of local (independent) system operators (242, FIG. 2) providing sales and accounting services (Tickets) on their own behalf or on behalf of a third party.

The system 100 assigns (272) to the set of services ordered by the user 212 an intrasystem identifier and communicates this data with the Operators of the local servers 222.

Servers of local operators (servers of local operators of systems) 242 contain a set of rules for access to services (attributes of services specified by the rules of use of local operators of systems 222) and transmit (in particular, transmit) them to System 100 using the available tools of System 100, in particular, Internet (121, FIG. 1).

The local operators of systems 222 are independent information systems (IS), for example, ASOP, ASKP, RZD, CPPK, AEROEXPRESS, AEROFLOT, TICKETLAND, etc., which are the technological element of access to the possibility of ordering services by the User (212, FIG 2) that perform the functions of issuing local tickets, accounting policies of issued tickets, they set and determine the norms and rules of the local ticket previously ordered by the User (212, FIG. 2) (the Ticket that runs only within the local operator system) through System 100, the conditions for its circulation ( Using) within the local system operator.

It should be noted that validation of the card is verified by standard methods of the IPU (3D secure and other methods) when registering the card in the System (100, FIG. 1). It is also worth noting that the validation of the card can be re-checked, in particular, when ordering a service (actual purchase), in particular, by means of at least one of the payment systems (545, FIG. 5), for example, IPM.

If the service is connected, the acquirer bank (610, FIG. 6), which serves the local system operator (both transport and other ticket), during validation of the card connected to the System (100, FIG. 1) asks the system (100, FIG. 1) about the availability of money (on the account) or the availability of a Ticket ("- to write off money or is there a ticket?"), And the System (100, FIG. 1) answers about the availability of a Ticket ("- there is a ticket! - do not write off money, but light green light and provide service "). The system (100, FIG. 1) this information exchange takes into account and calculates with one of the operators of local systems (222, FIG. 2), in particular, the acquirer represented by the bank (610, FIG. 6) and the user (in particular, the bank issuer (675, FIG. 6).

If the service is not connected, then the operation of part of the described system 100, or at least one part of it, as described in the framework of the present invention, functions (works) according to pay-as-you-go (pay for what you used (with what )), with the exchange of information between the acquirer bank (610, FIG. 6) and the issuer bank (675, FIG. 6) cards (bank acquirer -> bank card issuer), while the bank acquirer (610, FIG. 6) knows which local operator terminal devices (POS terminals (posters)) belong to which organization and if the organization is connected on the System (100, FIG. 1), the issuer (550, FIG. 5) notifies the System (100, FIG. 1) of a one-time pass (user 212, for example, when going through the turnstile in the subway, bus, etc. .) because system 100 must generate a Ticket for a one-time service.

To the System (100, FIG. 1), both the acquirer bank (610, FIG. 6) and transport operators (and other tickets) are connected independently via the System interface (100, FIG. 1) or System (100, FIG. 1) connects to them via their interface, if there is one (implementation is possible and so and so).

To inform the user about the transactions performed (other business and commercial information), his email, telephone number of the user's terminal device (131, FIG. 1) and / or his personal account in the System (100, FIG. 1), which may be implemented by an application (software installed on the user's terminal device (131, FIG. 1), for example, a mobile application for the user's mobile (computing) device), in particular, installed on the user's mobile device).

In FIG. 3 shows an exemplary communication option of the described system 100 and local operators (operators of local systems, operators of local servers).

System 100 is connected to Operators of local servers 222, which can be located in different cities and are responsible for different types of services (including transport services, but not limited to them).

It should be noted that local operators (222, FIG. 2) may be the Local Server Operator ((620, FIG. 6) ASOP, Automated Travel Payment System) 343, for example, the city of Moscow; The local server operator (SEKOP, Electronic Payment Transit Monitoring System) 353, for example, of the city of St. Petersburg; The local server operator (ASKP, Automated System of Control of Directions) 363, for example, the city of Rostov; The local server operator ((620, FIG. 6), ASOP) 373, for example, the city of Sochi; The local server operator ((620, FIG. 6), ASOP) 383, for example, the city of Novgorod (Veliky Novgorod); and, in a special case, the module of the system 313, which may include the Operator of the local server 393, for example, Crimea. It is worth noting that the operator of the local server 222 may (may be) the module 313 of the system 100.

In the particular case, a specialized operator module 313 of the system (UPS) 100 can be used as a local operator system. particular, the IP functionality of the local operator), as well as the functionality (IP of the local operator) of interaction with external ICs owned by contractors (ticket agents or subagents for the provision of services), be ordered sale and registration of vehicles, ticket or other services. If the local operator does not have its own IC, the UPS will provide it with all the necessary functionality of such an IC.

In FIG. 4 shows an exemplary interaction of the described system (UPS) 100, user 212, organization (credit organization) 424, attracted by the operator of the local server 222 and tools UPS (for integration with the credit organization) 434.

 When the user selects (212, FIG. 2) using the tools of the system (UPS) 100, the set of services to be accessed, the system (UPS) 100 prepares (generates) a list of rules and requests the consent of the mentioned user (in particular, through the application installed on the user's terminal 131) to verify compliance with specified rules, in particular, the set of services selected by the user, the user's payment instrument, and, with the user's consent (212, FIG. 2), checks the possibility of its compliance with the rules.

The choice by the user (212, FIG. 2) of the mentioned rules is carried out through the system interface, and such rules are formed by the System 100 itself, taking into account the rules of Local System Operators and based on the options (conditions) available to the user, for example, the menu items that the user chooses.

In the particular case of implementation, System 100 collects user data in advance (212, FIG. 2), in particular, elements of the tariff menu selected via the UPS interfaces, and stores data (information) in the database of the central server 161 about which rules the user (212 , FIG 2) ready to follow. Also, based on the information previously collected by the System, local systems (and / or their operators) can be determined corresponding to the user's model wishes (212, FIG. 2), in particular, based on the historical data on the user's choice, in particular user profile. The mentioned historical data is generated by System 100 based on the customer experience of the User (212, FIG. 2), in particular, his profile, in cases when the user (212, FIG. 2) performs additional actions (purchases), for example, including a new user choice from the tariff menu, using (its) unique user ID, System 100, with the consent of the said user (in particular, expressed using the user’s terminal device 131, for example, using the application installed on it or system 100 web site, etc.), can determine the location of the transaction and offer the best services currently available in the system.

In addition, the System 100 may, based on the analysis of historical data and user profile in ATM, offer the most attractive combination of services for the User profile (212, FIG. 2), taking into account the data received from Third-Party Information Systems, for example, in case of changes in user data in systems integrated with the PDS (for example, local operator systems) data is added to the user profile (the user profile is enriched with data).

Next, the user (212, FIG. 2), following the rules of interaction with the System 100, where the interfaces of the system 100 implement control over the implementation of the rules of interaction with it, and in accordance with the instructions (in particular, the UBP tariff menu) of local servers (242, FIG. 2 ) operators (222, FIG. 2) and the wishes of the user, confirms the choice of a set of services. In the particular case, the mentioned rules of interaction with the system and access rules are stored on the side of the system. Also, in a particular case, the access rules are responsible for the possibility of using elements, and the rules of use for the specifics of interaction with a particular local system or UPS.

This User’s action (212, FIG. 2) may be of a confidential nature and cause a chain of contractual obligations and orders between the User (212, FIG. 2), System 100 itself, Third-party information systems, Operators of local systems, organizations performing office, organizational and financial and legal functions for System 100 and its participants.

After that, the selected service set is assigned a unique identifier, which is the service identifier, and the local operator of the system (s) is provided for internal registration and processing a ready internal system identifier (user (and services)) other than the unique user identifier, for example, the user ID The system 100 is protected from a fake, for example, the ID of a contactless smart card or other device emitting it.

After the user has chosen (212, FIG. 2) the tariff and the local operator (in particular, using the user's terminal device 131), in the special case of the ATM, in the special case of the ATM, the task of guaranteed payment from the System 100 is made, and the local operator performs the task of the volume of services provided, respectively, and the volume of obligations and their cost, as well as their pricing are stored in the tariff menu. There may be several local system operators. System 100 can provide the user (212, FIG. 2) with the ability to seamlessly change the Operators of local systems under conditions predetermined by the System 100 internal restrictions, and examples of such restrictions may be the restriction to one trip (no more than one trip), session, customer pass .

In the particular case, after purchasing a package of services (by the user (212, FIG. 2)), the unspoken service of one Local System Operator may be at the request of the user (212, FIG. 2), if it is determined in advance, converted into a service of another Local System Operator (or to another service of the same Local System Operator).

In the particular case, the operator may be the owner of the toll road, or the operator of the transport, ticket or other service system, or other enterprise providing services. Before contacting the local system operator for the service, the unique user identifier is activated in System 100. In the particular case, the unique user identifier and the intra-system user identifier are entered (performed) into the specified ones (in particular, those available and / or selected by the user (212, FIG. 2)) local systems of operators (systems of local operators).

In the particular case, the system unique identifier of the user (UPS) 100 is associated with an unconditional (common) user identifier, for example, the user's phone number, the user's email address, etc., which includes the data transfer method and allows the user , FIG. 2) to receive fiscal documents (in particular, those formed using the fiscalization system (665, FIG. 6)), and to System 100 and local system operators to report on the provided to the user (212, FIG. 2) through System 100 services This operation can be performed at the stage of processing by System 100 of the User Connection Form (212, FIG. 2) or by other means at the discretion of the User (212, FIG. 2).

When accessing the services of local system operators, the user (212, FIG. 2) uses the user ID in System 100, and System 100 considers the status of services (service provided, not provided, service balance) provided to the user (212, FIG. 2). Accounting takes place (in particular, system 100 performs accounting) of services rendered and a corresponding reduction (decrease) in the balance of obligations (services, tickets), in accordance with the services provided, in particular, writes off conditional units (transport units) from the (bank) account user (212, FIG. 2).

When validating a unique user identifier on a merchant device (in particular, a local operator’s terminal device), for example, a POS terminal (payment terminal of a sales point) or similar reading devices of this identifier, the presence of a BT is checked through the UPS monitoring module (818, FIG 8) and if there is a binding of such an identifier to the BT, the fact of the provision of the service is recorded. In the case when identifying an attachment to a BT is checked in the UBP access control module (818, FIG. 8), it is impossible (for example, offline (off-line) mode) to reserve the device or block funds in the amount of the cost of the service, and, when restoring a communication channel, checking whether the identifier is tied to the BT with the subsequent registration of the fact of rendering the service of a corresponding write-off of funds (in particular, conventional units (transport units ) With the user accounts (212, FIG. 2)).

 It should be noted that after the user selects (454) 212 100 options available in the system for connecting services (for example, a specific city, operator of the local system (server), type of service, etc.) and making (454) payments, the system (UBS ) 100 binds (454) the service to the payment card or payment card Token on the user's final device 131 using the UBS 100 own funds. After the user 212 applies (464) a unique identifier (in particular, the payment card or payment card Token on the user device 131), the operator’s terminal device (222, FIG. 2), the operator’s terminal device (474), in particular, transmits an authorization request (authorization request) to the credit organization 424, in particular, an organization engaged by the local server operator ( 222, FIG. 2). Further, the credit institution 424 routes (484) the transport transaction (605, FIG. 6), in particular, to the system 100, using the tools provided by the UBS (UBS tools) 434. Then, in UBS 100, the service balance (494) decreases (494) response to the credit institution 424 using the UBS tools 434.

In the general case, System 100 maintains (carries out) records of previously ordered and paid services received by the User (212, FIG. 2) by recording in the System 100 the fact of the presentation of a (personal) user identifier by the System 100 mentioned by the User.

In the particular case, the confirmation of the provision of the service may be the redemption (activation) of the ticket granting the right to receive it.

In the process of receiving the service, System 100 captures the territorial preferences of the user (212, FIG. 2), in particular, implemented using geo-referencing (geo-attraction), and, in accordance with the geography of using System 100, can notify (for example, using a terminal user 131, in particular, using the application installed on it) user (212, FIG. 2) about the availability of the selected local system operator (local system operator) and the location of the receiving points earlier op Enhanced services (in particular, the geographical location of the terminal devices of operators, in particular, local operators). In the particular case of implementation, the choice of the local system operator and the size of the purchased services can be made (by the user (212, FIG. 2)) in advance (for example, using the user's terminal 131, in particular, using the application installed on it), but the limit the provision of services may be determined (tariff menu of the cashier settlement) at the time of the end of their provision in accordance with the 100 rules set by the System (in the particular case, the tariff menu).

In the particular case of implementation, reducing the balance of available services (in particular, debiting funds from the user’s account (212, FIG. 2)) and restoring their fixed limit can be performed by the BSS based on the parameters set by the user according to predefined rules, for example, once every hour , once a day, once a week, month, three months, year or another interval specified by the user (212, FIG. 2) and System 100. The user (212, FIG. 2) can be granted access to services that are not confirmed immediately payment Some of these features may exist in connection with the possibility of disconnecting the user (212, FIG. 2) or the terminal device of the operator of local systems from the network.

In the particular case of implementation, the network configuration of the terminal device of the operator of local systems can be made in advance and remotely by System 100. For example, a Bluetooth connection can be configured in emulation mode or registered in the user’s device’s registry (131, FIG. 1), or configured connection to the local systems operator's wi-fi network, to which the terminal device of the local systems operator is connected.

Accordingly, when the user interacts (212, FIG. 2) with the terminal device of the Operator of the local system, the System 100 can give (present) a hint (for example, to the user’s terminal 131, in particular, through the application installed on it) regarding the use of a specific user ID and unique user id. If necessary, the communication protocol is activated from the terminal device of the operator 141 of the local system to the System 100 or the payment functionality of the user identifier is activated.

In the simplest case, if there is no information in the System 100 about the unique identifier of the user and the service or the intra-system identifier (user) and the service, the user (212, FIG. 2) selects the tariff set by the Local System Operator and uses the user identifier (performed) payment in pay-as-you-go mode (for example, the full cost of a one-time service), using the means of the payment system available to the local Operator of the local system online or offline. For the purpose of recording transactions made in this mode, the local system operator can transmit to System 100 (in particular, to the central server 151) the data necessary for generating (in particular, using the fiscalization system (665, FIG. 6)) reporting and fiscal documents (650, FIG. 6) for the service provided.

In FIG. 5 shows a rough version of ticket processing. The user (passenger) 212 buys a ticket of the urban transport system (a specific city, a specific type of ticket) and links it (511) to his payment card or payment card Token through UBP 100. The user (passenger) 212 pays the fare using an associated ticket to his payment card or payment card Token (512). The local operator 533 sends (513) an authorization request (authorization request) to an acquirer 525 (in particular, to the acquirer bank (610, FIG. 6). The acquirer bank (610, FIG. 6) routes (514) the ticket transaction (in particular, into the system 100) using the software module UBP 535, in particular, an acquirer bank integrated in the processing (610, FIG. 6). In the system (in particular, in UBP (600, FIG. 6)) 100 is fixed (515) Tickets. Optionally (alternatively), for example, if the Ticket is not purchased (by user 212), the validity period (Ticket) has expired, the UPS system has refused, then Weyer 525 communicates (516) with at least one of the payment systems 545 (FIG. 5), in particular, with the MPS, then (optionally) the payment system 545, in particular, with the MPS authorizes (517) the issuer’s bank card ( 550), then (optionally) funds from the issuer's account 550 through acquirer 525 (518) are transferred to the bank account of the local operator (the bank servicing the local operator 533) 555 and then (optionally) funds are credited (519) to the settlement account of the local operator (in particular, the carrier) 533.

In FIG. 6 shows the scheme of interaction of the main functional participants of the transaction in the framework of the operations of the ATM, and the composition and sequence of transmitted data between which is determined in the process of application implementation.

 In FIG. 7 shows one of the approximate versions of scenarios for universal ticket processing (PSS), in particular, shows an approximate version of the scenario of registering a PAN (bank) card and creating a Token in PFS.

The registration logic for the Ticket Token ID includes:

- registration of a unique user ID (PAN (bank) cards, expiration date (bank) card (Expiry date));

- create an account.

 It is worth noting that after registering a unique user identifier in the payment system, the Core of the Unified Security System 111 transmits a request to form a Token (in particular, the Token of the IPU). Next, the validity of the PAN (bank) card is checked, in particular, using the Luna algorithm mentioned above. Further, the issuer 675 bank forms a confirmation of the validity of the (bank) card and creates a combination of the Payment Token and the key (Key), which is a special case of the procedures regulated by the rules of the IPU. Next, the Payment Token is formed and transmitted to at least one of the described devices (in particular, to the user’s terminal 131 and / or the operator’s terminal 141), which in a particular case ensures the safe operation of the systems, as in the framework of the IPS and in the framework of the UBP. Then, a notification about the load of the Payment Token is transmitted to at least one of the payment systems 545, in particular, to the MMS, and the issuer bank 675. System 655 contains a database of reference books 656 of the basic conditions defining the interaction protocols. Data formats, payment terms and other operating conditions for local transport operators and the possibility of their interaction with universal ticket processing. To ensure interaction with local transport operators, system 655 contains interaction gateways 660, which should provide stable communication with local operators. The interaction can be provided, for example, via physical communication channels, for example, via satellite communication networks, or via telephone communication networks, even if the local operator has a data network with restrictions on interaction from public networks. Also, gateways can provide support for logical secure communication channels, for example, using Virtual Private Network protocols. The clearing system 670 and fiscalization system 665 provide, respectively, the possibility of offsetting cash and accounting for cash flow, in accordance with financial reporting standards.

The system 655 is addressed to issuers 550 and non-issuers 630 using the application interfaces defined for them, for example using the application interface 625, respectively, a description of which may be contained in the reference 655 of basic conditions.

 In FIG. 8 shows one of the exemplary scenarios of universal ticket processing, in particular, shows an exemplary scenario of linking the Ticket to the intrasystem identifier (issuing and loading the Ticket Token to the user terminal 131 with NFC).

 After the user 212 has registered a unique (personal) identifier (user) in the system 100 and has established a payment Token, the user 212 selects an available service provider and type of Ticket. Next, the described system 100 requests from the merchant (local operator of transport systems) 808 a unique ticket identifier. Next, the system 100 writes off the Ticket cost from the user’s account 212. Next, the system 100 generates the Ticket Token for downloading to the user’s terminal device 131. Next, the system 100 registers the WT in the registry, in particular, in the UBP internal registry.

It should be noted that the module of control of the appeal of the UPS 818 can function

1. In the information flow between the POS-terminal and Acquirer Bank;

2. In the information flow between the bank Acquirer and the IPU;

3. In the information flow between the IPU and the Bank by the Issuer.

In the preferred embodiment of the invention, the UBP 818 call control module can function in the information flow between the Acquirer Bank and the IPU to determine if there is a BT in the system.

In other cases, the implementation of the circulation control module is used to control the generation of BT, intercepting the information flow between the Acquirer Bank and the IPU, or for additional verification of the existing BT, in the information flow between the IPU and the Issuer Bank.

In FIG. 9 shows one of the exemplary variants of the universal ticket processing scenarios, in particular, shows an approximate version of the scenario of linking the Ticket to the identifier (issue of the Ticket Token without loading it).

After the user 212 has registered a unique (personal) identifier (user) in the system 100 and has agreed on a direct debit, the user 212 selects an available service provider and type of Ticket. Next, the described system 100 requests from the merchant 808 a unique ticket identifier. Next, the system 100 deducts the cost of the Ticket from the user's account (the user's card account, the user's card account). Next, the system 100 generates a Ticket Token to form a bundle with an intra-system identifier. Next, the system 100 registers BT in the registry.

 In FIG. 10 shows one of the exemplary variants of the universal ticket processing scenarios, in particular, shows an approximate version of the Ticket Token validation scenario.

 In FIG. 11 shows one of the exemplary scenarios of the universal ticket processing, in particular, shows an exemplary variant of the intra system identifier validation scenario.

It is worth noting that the user’s access to the equipment of local systems in the universal ticket processing system 100 can be centralized collection and storage of information (data) in a single database related to the conditions of transportation of local systems of local operators 222 (local system operators, local server operators 242 ), formed by local operators of systems 222, for at least one of local systems selected by user 212, and user 212 (in particular, to terminal devices User 131) pass a mandatory set of access rules to the local system equipment stored in a single database 161, requests user consent 212 for compliance with a mandatory rule set and, with user consent 212, select the storage medium for storing the user identification code 212, check the user's ability 212 correspond to a set of mandatory rules for at least one of the local operators 222, and the user 212 is registered in at least one of the local systems and provide the user 212 with the services of a local operator using the media based on the results of at least one mandatory rule from the set of mandatory rules, while accessing the services of the local operator, a user’s code set of data 212 is formed that characterizes the verified (verified , reliable) bank details of the user 212, providing unconditional payment between the bank acquirer 610 of the local system and the bank em an instance of 675 corresponding to the bank details of the user 212, with the simultaneous registration of the bank details of the user 212 in the system of the local operator,

It is worth noting that when it is necessary to access the services of a local operator, the user's terminal 131 transmits, through a contactless data transmission device, the identification code and code set of data to the local system and the local system requests the acquirer 610 of the local system to confirm the validity of the bank details of the user with the transmitted identifier , and, for a user with valid bank details, the services are provided (local system of local erator).

 It is also worth noting that the user’s portable communicator 212 can be used as the mentioned storage medium.

Also, one of the mentioned (mandatory) rules is the payment for the services of the (local) system (local operator).

The equipment of the local system (in the particular case the terminal device of the operator 141) is the transport of the (local) system (local operator), and the equipment of the (local) system is the parking equipment of the (transport) system, for example, an elevator parking complex.

It is worth noting that to provide local services (transport, ticket, or other service) system, the identification code of the user of the local system generated in the local system can be used, while storing such identification code of the user of the local system in a single database 161 and local The transport system is given such an identification code of the user of the local system upon request containing a universal identification code of the user. first to identify the user in the system (combined ticket processing) 100.

It is also worth noting that to provide user access to the local system equipment, a wireless connection of the storage medium and the computational tools of the local system used to verify the identification code (user or user of the local system) and the above-mentioned rule can be used, and the setting of the specified wireless connection can be carried out in advance.

In FIG. 12 shows an example of a general-purpose computer system that includes a multi-purpose computing device in the form of a computer 20 or a server, or a mobile (computing) device, or a module of the system described in the present invention, which, in a particular case, may be final (computing) devices user or operator, which includes the processor 21, the system memory 22 and the system bus 23, which connects the various system components, including system memory with the processor 21.

The system bus 23 may be any of various types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. System memory 22 includes a read-only memory (ROM) 24 and a random access memory (RAM) 25. ROM 24 stores basic input / output system 26 (BIOS), consisting of basic routines that help to exchange information between elements within computer 20, for example, at the time of launch.

Computer 20 may also include a hard disk drive 27 for reading from and writing to a hard disk (not shown), a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or recording to a removable optical disc 31, such as a compact disc, digital video disc, and other optical media. The hard disk drive 27, magnetic disk drive 28 and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33 and an optical drive interface 34, respectively. Drives and their respective computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computer 20.

Although the typical configuration described here uses a hard disk, a removable magnetic disk 29 and a removable optical disk 31, the technician will take into account that other types of computer-readable media that can store data that is accessible by computer can also be used in a typical operating environment. such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory (RAM), read-only memory (ROM), etc.

Various program modules, including the operating system 35, can be stored on a hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25. Computer 20 includes a file system 36 associated with the operating system 35 or included in it or more software application (s) 37, other program modules 38 and program data 39. A user can enter commands and information into computer 20 using input devices such as keyboard 40 and pointing device 42. Other input devices (not shown) Oguta include a microphone, joystick, game pad, satellite dish, scanner, or any other.

These and other input devices are often connected to the processor 21 via the serial port interface 46, which is connected to the system bus, but can be connected via other interfaces, such as the parallel port, the game port, or the universal serial bus (USB). A monitor 47 or other type of visual display device is also connected to the system bus 23 via an interface, for example, a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

Computer 20 may operate in a networked environment through logical connections to one or more remote computers 49. A remote computer (or computers) 49 may be another computer, a server, a router, a network PC, a peer device, or another node of a single network, and also typically includes Most or all of the elements described above relate to computer 20, although only information storage device 50 is shown. Logical connections include a local (computer) network (LAN) 51 and a global computer yuternuyu network (GKC) 52. Such networking environments are usually common in offices, enterprise-wide computer networks, the Internet.

The computer 20 used in the LAN network environment is connected to the local network 51 via a network interface or adapter 53. The computer 20 used in the network environment of the GCS typically uses a modem 54 or other means to establish communication with the global computer network 52, such as the Internet.

The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules, or parts thereof, as described in relation to computer 20, may be stored on a remote information storage device. It must be taken into account that the network connections shown are typical, and other means may be used to establish a communication link between the computers.

In conclusion, it should be noted that the information given in the description are examples that do not limit the scope of the present invention as defined by the formula. The person skilled in the art will understand that there may be other embodiments of the present invention consistent with the nature and scope of the present invention.

Claims (35)

1. The way to ensure user access to the services of the local service operator, namely, that: - in the universal ticket processing system, they centrally collect and store in a single database information relating to the terms of service of a multitude of local service systems managed by local operators of service delivery systems, where services are provided at the location of the user; - for a local service delivery system selected by a user from a variety of local service delivery systems, the user is transferred a set of access rules to the services of the local service delivery system stored in a single database, where the rule set contains a mandatory set of rules; - requests the user's consent for compliance with the mandatory set of rules; - choose, in agreement with the user, a set of additional rules, - with the consent of the user, choose the storage medium for storing the user's identification data, check the user's ability to comply with the mandatory set of rules of the local operator, register the user in the local system of the local operator using the user's identification data; - when a user is in the service area, they read the user's identification data from the selected media, check the user registration with the read identification data in the local service delivery system, and when the user registers in the local service delivery system, at the user's choice, provide the service to the user in accordance with an additional set of rules and with verification of compliance with at least one of the rules from the set of mandatory rules. 2. The method according to p. 1, characterized in that the service is a transport service. 3. The method according to p. 2, characterized in that the transport service is reusable. 4. The method according to p. 2, characterized in that the transport service is the transportation of the user. 5. The method according to p. 2, characterized in that the transport service is a pass for traveling on a toll road. 6. The method according to p. 2, characterized in that the transport service is a pass to the parking of vehicles. 7. The method according to p. 1, characterized in that the user identification data is part of the details of the user account in the bank issuer of the user account. 8. The method according to p. 5, characterized in that part of the bank details of the user account are the details of the bank card tied to the user account. 9. The method according to p. 5, characterized in that part of the bank details of the user’s account is a unique token tied to a bank card tied to the user’s account. 10. The method according to p. 8, characterized in that the token of the universal ticket processing system is an identifier tied to a bank card tied to the user's account. 11. The method according to p. 1, characterized in that the selected storage medium is a portable means of data storage, made with the possibility of contactless data reading. 12. The method according to p. 9, wherein the portable means of storing data is a contactless bank card of the user. 13. The method according to p. 9, wherein the portable means of storing data is the user's communicator. 14. The method according to p. 6, characterized in that when the user is in the service area, after reading the user's identification data, the validity of the user's bank details is additionally checked, and the service is provided only for the user with valid bank details. 15. The method according to p. 12, characterized in that the validity of the bank details of the user is checked and confirmed by the bank acquirer serving the local system of service provision. 16. A method according to claim 1, characterized in that in order to provide user access to the local system equipment, a wireless connection of the storage medium and computing means of the local system used in checking the identification code is used, and the specified wireless connection is set up in advance. 17. The method according to claim 1, wherein the user is associated with a universal ticket processing system via the Internet using the user's terminal device by means of a bank card binding. 18. The method according to p. 15 or 17, characterized in that if you need access to the services of a local operator, the user's terminal device transmits through the contactless data transmission device, the identification code and code set of data to the local system, the local system requests confirmation from the acquirer of the local system validity of the bank details of the user with the transmitted identifier, and, for the user with valid bank details, the services are provided. 19. The method according to p. 18, characterized in that the verification of the validity of the user's bank details is carried out by the payment system when registering a bank card in the universal ticket processing system. 20. The method according to p. 19, characterized in that when ordering services by the payment system, the validation of the bank details of the user is repeated. 21. The method according to p. 7 or 15, characterized in that if the service is connected, the bank acquirer servicing the local operator, when checking the validity of the bank details of the user of the user's bank card connected to the universal service processing system, sends a request to the universal service system processing about the availability of funds in the user’s account or whether the user has a purchased ticket for rendering the service to the user and is tied to the user’s account, moreover if the ticket is present The universal ticket processing system provides the user with a service without debiting funds from the user’s account, where the universal ticket processing system is settled by a local operator, an acquiring bank and an issuing bank, taking into account such data exchange between the acquiring bank and the universal ticket processing system. 22. The method according to p. 7 or 15, characterized in that if the service is not connected, then the data exchange between the acquirer bank and the bank is the issuer of the user's account, while the acquirer bank knows the terminal devices of the local operators to the relevant organizations and, if the organization is connected to the universal ticket processing system, the issuer notifies the universal ticket processing system of the service provided for generating a ticket for such a service. 23. The method according to p. 21 or 22, characterized in that the acquirer bank and local operators are connected to the universal ticket processing system using the interface provided by the universal ticket processing system or, in the case of the bank providing the acquirer and local operators of their own interfaces processing is connected to the bank by the acquirer and local operators via such provided interfaces. 24. The method according to p. 1, characterized in that for information exchange between participants in the universal ticket processing system, an intrasystem identifier is used that is different from a bank card identifier, which is the user's identification data in terms of user account details in the issuing bank of the user account, and the intrasystem identifier is hash sum calculated using a PAN bank card. 25. The method according to claim 1, characterized in that the user’s email, the user's mobile phone number and / or the user's personal account in the universal ticket processing system is used to inform the user about the completed operations, business and business information. 26. The method according to p. 17, characterized in that the terminal devices of local operators interacting with a bank card tied to the user's account are devices of the acquirer bank or devices of local operators connected to the universal ticket processing system. 27. The method according to claim 1, characterized in that a code set of data is formed that characterizes the verified account user details, ensuring unconditional payment between the acquirer bank, the local system and the issuer bank corresponding to the user account details, while registering the user account details in the system local operator. 28. A portable device for providing user access to equipment of local operators of local systems, containing an information input unit, an information output unit, information processing means, and means of accessing a central server, the device including means of authenticating the user based on the results of user interaction with information input means , and the information processing unit is made to form a list of local systems displayed on the information output facility, with a choice of users local system, while the portable device is configured to obtain from the central server a mandatory set of rules for access to equipment of a local system selected by the user, display on the display tools and obtain user consent for compliance with a mandatory set of rules, where the rules are selected from a single database of information, relating to the transportation conditions of local systems formed by local system operators for a local user selected by the user the portable device is configured to store data on the storage medium for storing the user's identification code, ensuring that the central server can request the user to register in the local system and form a reminder that the local operator is provided to the user using the storage medium, the results of the implementation of at least one mandatory rule from a set of mandatory rules. 29. The server of the system for providing user access to the equipment of local systems, containing data transmission means of data processing and means of filling and storing a single database of information relating to the transportation conditions of local systems formed by local system operators and centrally collected using data collection tools at the same time, the server is made to ensure the selection and transmission, at the request of the user, of a mandatory set of rules for access to the local system equipment; data in a single database, the choice of the corresponding set of rules, the storage medium for storing the user's identification code, checking the user's ability to comply with the set of mandatory rules of the local operator, user registration in the local system, ensuring the provision of a local operator service to the user using the media, according to the results at least one mandatory rule from a set of mandatory rules.

Images