WO2020036516A1 - Способ доступа пользователя к услугам локального оператора - Google Patents

Способ доступа пользователя к услугам локального оператора Download PDF

Info

Publication number
WO2020036516A1
WO2020036516A1 PCT/RU2019/050130 RU2019050130W WO2020036516A1 WO 2020036516 A1 WO2020036516 A1 WO 2020036516A1 RU 2019050130 W RU2019050130 W RU 2019050130W WO 2020036516 A1 WO2020036516 A1 WO 2020036516A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
local
service
bank
rules
Prior art date
Application number
PCT/RU2019/050130
Other languages
English (en)
French (fr)
Inventor
Игорь Николаевич АРСЕНЬЕВ
Александр Юрьевич НЕССЛЕР
Original Assignee
Игорь Николаевич АРСЕНЬЕВ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Игорь Николаевич АРСЕНЬЕВ filed Critical Игорь Николаевич АРСЕНЬЕВ
Publication of WO2020036516A1 publication Critical patent/WO2020036516A1/ru

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points

Definitions

  • the invention relates to the field of network communications and can be used to access users to services without significant territorial restrictions, in terms of the place of ordering services and the location of enterprises providing services.
  • the system allows the user to ensure unhindered use of vehicles, both on a predetermined route, and when changing the user's route.
  • Troika card can be used to provide services of other transport systems, for example, the suburban 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.
  • the present invention is intended to eliminate this and other disadvantages of the prior art, as well as to achieve a technical result, which consists in improving 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, when using the proposed invention, the reliability is significantly increased protection against fakes.
  • the proposed system provides the ability to integrate transport, ticket and other service systems without making changes to their functionality, and also does not require the release of special identifiers or storage media.
  • the present invention leads to lower costs for the issuance of identification tools and travel documents, reduces the number of operations performed by users when ordering and receiving services, reduces the number of valid identifiers that are, in a particular case, ticket holders of all form factors, for example, transport cards, printed tickets, one-time tickets with a magnetic strip and a chip, providing access to services, provides a high degree of protection against their use by unauthorized persons, as well as makes it possible to accept payment for services (including transport) in the maximum automation mode.
  • centralized collection and storage of information related to the conditions for the provision of services of a multitude of local service delivery systems managed by local operators of service delivery systems is carried out in a single database, where services are provided at the user's location; for a local service delivery system selected by a user from a variety of local service delivery systems, a set of access rules for services of a local service delivery system is stored in a single database, where the set of rules contains a mandatory set of rules; requests the user's consent for compliance with the mandatory set of rules; they select, in agreement with the user, a set of additional rules, with the consent of the user, select a storage medium for storing user identification data, check the user's ability 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 credentials; when the user is in the service area, the user identification data is read from the selected storage medium, the user registration is checked with the identification data
  • the service is a transport service.
  • the transport service is reusable.
  • the transportation service is the transportation of the user.
  • the transport service is a pass for a toll road.
  • the transport service is a parking permit for vehicles.
  • the user's identity is part of the details of the user account in the bank of the issuer of the user account.
  • part of the bank details of the user’s account are the details of a bank card tied to the user’s account.
  • part of the bank details of the user’s account is a unique token associated with a bank card tied to the user's account.
  • the token of the universal ticket processing system is an identifier tied to a bank card tied to the user's account.
  • the selected storage medium is a portable data storage means configured to read data non-contactly.
  • the portable storage medium is a contactless bank card of the user.
  • the portable storage medium is the user's device.
  • the validity of the user’s bank details is additionally checked, and the service is provided only for the user with valid bank details.
  • the validity of the user's bank details is checked and confirmed by the bank acquirer serving the local service delivery system.
  • a wireless connection is used between the storage medium and the computing means of the local system used to verify the identification code, and the specified wireless connection is configured in advance.
  • the user is connected to the universal ticket processing system via the Internet using the user's terminal device by linking a bank card.
  • the user terminal transmits via the contactless data device, the identification code and the code set of data to the local system, the local system asks the local system acquirer for confirmation of the validity of the user's bank details with the transmitted identifier, and, for a user with valid bank details, services are provided.
  • the validation of the user's bank details is carried out by the payment system when registering a bank card in the universal ticket processing system.
  • the acquirer bank serving the local operator when verifying 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 availability of funds in the user's account or the user of the purchased ticket to provide the service to the user and the user tied to the account, moreover, if there is a ticket, the universal ticket system th processing provides the user with a service without debiting the account the user where the universal ticket processing system calculates by the local operator, the acquirer bank and the issuing bank, taking into account such data exchange between the acquirer bank and the universal ticket processing system.
  • the issuer notifies the universal ticket processing for the provision of a one-time service for generating a ticket for such a one-time service.
  • 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 case the acquirer and local operators provide their own interfaces, the universal ticket processing system connects to the acquirer bank and local operators via such provided interfaces
  • an intra-system identifier is used that is different from the bank card identifier, which is the user's identification information regarding the details of the user account in the bank of the user account issuer, and the intrasystem identifier is the hash amount calculated using PAN bank card.
  • the user’s e-mail, user’s mobile phone number and / or user’s personal account in the universal ticket processing system are used to inform the user about completed operations, official and commercial information.
  • 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.
  • a code set of data is generated that characterizes the verified details of the user account, ensuring unconditional payment between the bank acquirer, the local system and the bank by the issuer corresponding to the details of the user account, with the simultaneous registration of the details of the user account in the system of the local operator.
  • a portable device for providing user access to the equipment of local operators of local systems, comprising an information input unit, an information output unit, information processing means, and an access tool to a central server, the device comprising user authentication means based on the results of interaction a user with information input means, and the information processing unit is configured to form an output displayed on the means information, a list of local systems, with the ability to select a local system by the user, while the portable device is configured to receive a mandatory set of access rules from the central server for accessing the equipment of the local system selected by the user, display information on the means of display, and obtain user consent for compliance with the mandatory set of rules rules are selected from a single database of information related to the conditions of transportation of local systems formed by the locale system operators, for the local system selected by the user, the portable device is capable of storing data on the storage medium for storing the user identification code, with the possibility of transmitting to the central server a request for user registration in the local system and forming a reminder that providing the user with a local
  • a server for providing user access to the equipment of local systems, comprising means for transmitting data, data processing tools, and means for filling and storing a single database of information related to the conditions of transportation of local systems formed by local system operators and collected centrally from using data collection tools, while the server is designed to provide sampling and transmission, at the request of the user, on a set of rules for accessing the equipment of the local system stored in a single database, choosing the appropriate set of rules, a storage medium for storing the user identification code, checking the user’s ability to comply with the set of mandatory local rules operator, user registration in the local system with the provision of the user local operator services using the information carrier, based on the results of at least one mandatory rule from the set of mandatory rules.
  • FIG. 1 illustrates an exemplary embodiment of the System described in the present invention, or at least part of such a System.
  • FIG. 2 illustrates an example 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 example communication option of the described System and local operators (operators of local systems, operators of local servers).
  • FIG. 4 illustrates an exemplary embodiment of the interaction of the described system (UBS), the user, organization (credit institution), engaged by the local server operator and UBS tools (for integration with a credit institution).
  • UBS described system
  • the user organization
  • UBS tools for integration with a credit institution.
  • FIG. 5 illustrates an exemplary embodiment of ticket processing.
  • FIG. 6 illustrates an exemplary version of the interaction scheme of the main functional participants of the transaction within the framework of the UBP.
  • FIG. 7 illustrates one example scenario for universal ticket processing (UBP), in particular, an example scenario for registering a PAN (bank) card and creating a Token in a UBB is shown.
  • UBP universal ticket processing
  • FIG. 8 illustrates one of the example scenarios of the operation of universal ticket processing, in particular, an example scenario of the binding of a Ticket to an identifier is shown (issuing and downloading a Ticket Token to a user terminal with NFC).
  • FIG. 9 illustrates one of the example scenarios of universal ticket processing, in particular, an example scenario of linking the Ticket to an identifier is shown (issuing a Ticket Token without downloading it).
  • FIG. 10 illustrates one of the example scenarios of universal ticket processing, in particular, an example variant of the Ticket Token validation scenario is shown.
  • FIG. 11 illustrates one exemplary scenario for universal ticket processing, in particular, an example variant of an identifier validation scenario is shown.
  • FIG. 12 illustrates an example of a general purpose computer system.
  • the terms “component”, “element”, “system”, “module”, “part” and the like are intended (used) to refer to computing entities, in particular computer entities (computing entities, entities or objects related with a computing device, for example, a computer, a computerized device, an automated device, etc.), which may be hardware, equipment (for example, a device, tool, apparatus, apparatus, integral part of the device, in particular, a processor, microprocessor, printed circuit board, etc.), software (for example, executable program code, a compiled application, software module, part of the software and / or code, etc.) or firmware (firmware from English firmware).
  • a module can be a process running (executing) on a processor, processor, object, executable file, program, function, method, library, subprogram and / or computing device (for example, a microcomputer or computer) or a combination of software or hardware.
  • a server for example, on a central server (151, FIG. 1)
  • the server can be a component or module.
  • At least one component may be located within the process.
  • a module (component, etc.) can be located on one computing device (for example, a computer) and / or can be distributed between two or more computing devices.
  • an application for example, a module, component, etc. .
  • a server module server part
  • client module client part
  • the client module is installed on at least one computing device
  • the server module is installed on the second computing device, from which, in the particular case, control, monitoring, etc. are performed.
  • the first computing device and / or its component modules (components, parts, etc.)).
  • System (100, FIG. 1) is a complex of ordered software and hardware that provides the process of issue, receipt, accounting, turnover, replenishment, write-off of identifiers of obligations for automated access to services, including transport services.
  • Ticket is the information carrier or information block certifying the right to use the services specified when issuing the Ticket.
  • the ticket can be printed on paper or similar media, or made in electronic form, including as a record in a database (for example, in a database 161 (FIG. 1) associated with a central server 151 (FIG. 1)).
  • Connection form the 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.
  • the user identifier in the System is a set of data that uniquely identifies the User (212, FIG. 2) in the System (100, FIG. 1).
  • the specified data set may be one-to-one a unique data carrier, for example, be stored on the user's terminal (in particular, personal) device (131, FIG. 1), including on a bank card similar to a smart card with a chip, including one that supports contactless communication, on a user terminal device (131, FIG. 1) with a contactless module or other interface for interacting with public networks.
  • Token - a set of data that makes it possible to receive a service when presented.
  • the service is the debiting of funds from a predetermined account (bank, individual, special, etc.) associated with a bank card (101, FIG. 1) and / or user terminal device (131, FIG. 1) for example , a smartphone or other device, in particular, operating via a contactless interface belonging to (belonging to) the user (212, FIG. 2).
  • a predetermined account bank card
  • user terminal device 131, FIG. 1
  • Technologically, for the successful implementation of the token it is necessary to have a trusted center that certifies the validity of the token and ensures that funds are debited from the account tied to the token, in particular, to receive the service upon presentation.
  • FIG. 1 shows an exemplary embodiment of a system 100 that implements the described invention or at least part of the described invention.
  • the proposed system (Universal Ticket System) 100 implements Universal ticket processing (600, FIG. 6), hereinafter - UBP).
  • UBP is designed to provide users of system 100 with the ability to remotely (remotely) purchase a ticket with the ability to bind a previously purchased ticket to a (personal) unique identifier (ID) of the user (bank card 101, user terminal 131 with NFC technology (co K p.
  • ID personal unique identifier
  • These user terminals 131 may include various (including digital, analog, combined, mechanical, etc.) devices, in particular, but not limited to, electronic devices.
  • such user terminals can be personal computers, electronic computers (computers), laptops, servers, workstations, monoblocks, computer stands, bank and vending payment terminals, desktop computers, test stands, demonstration computer stands, tablets, smartphones, mobile (cell) phones, satellite phones, personal digital assistants (PDAs), yMHbie (smart) things, such as watches, bracelets, pendants, items of clothing such as belts, headgear s, etc.
  • computers electronic computers
  • laptops laptops
  • servers workstations
  • monoblocks computer stands
  • bank and vending payment terminals desktop computers
  • test stands demonstration computer stands
  • tablets smartphones
  • mobile (cell) phones mobile (cell) phones
  • satellite phones personal digital assistants
  • PDAs personal digital assistants
  • yMHbie smartt things, such as watches, bracelets, pendants, items of clothing such as belts, headgear s, etc.
  • the user (212, FIG. 2) connects (and disconnects) using the terminal device of the user 131 via the Internet 121 by linking his payment bank card 101.
  • the user (212, FIG. 2) can use the terminal device user 131, for example, a computer, a user’s mobile device, another form of interface, for example, an agent’s office, with a computer installed, which are a means of interacting with the UBP through a thin client (635, FIG. 6)
  • the described invention can be implemented by a network service and, in a particular case, is intended for users (212, FIG. 2) using contactless payment technology (EMV Contactless), moreover, contactless bank card and Token can be form factors of the carrier
  • EMV Contactless contactless payment technology
  • contactless bank card and Token can be form factors of the carrier
  • System (Universal Ticket System) 100 is a single network information platform for ticket and accounting operations that allows Users (212, FIG. 2) of System 100 to use (their own) unique user identifier (unique personal identifier, unique user ID (212, FIG. 2 ), user identifier, personal identifier, personal user ID, own unique identifier (user)), in particular, using an intra-system identifier (user), as more upgrade equ described in the present invention for access to all Tickets sold by the Operators of local transport, ticket or other service systems connected to it (222, FIG. 2).
  • the central part of 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 a bank card, UID card, payment Card Token on the terminal device 131 user with NFC technology, etc.) and Ticket parameters of a particular service provider - merchant (from the English Merchant — merchant, merchant, merchant), which is a local operator of transport systems (he also herator of the local server, he is, in a particular case, the issuer of a ticket, or an organization engaged by a merchant, for example, to provide similar information and technical activities) and such parameters may include cost, date of purchase, validity, scope, number of trips, balance , set of services, place of use and other details).
  • - BT unique Ticket Token
  • UBP core token generation service (issuers' banks (675, FIG. 6)), unique ticket token generation service) 1 11 checks for compliance (and this correspondence is the correspondence of the unique user identifier bundle with the BT number in the database) of the unique user identifier previously formed BT, conducts (checks) the validity of the unique user identifier, records BT, in particular, records in the database.
  • the aforementioned validation of the unique user identifier is carried out using the Moon algorithm (Luhn) or another algorithm, including using HASH.
  • the UBP core re-releases BT (in particular, by generating a new BT based on the old one with its replacement in the database, and also in accordance with at least one UBP rule, in particular with the aim of controlling the circulation of BT and antifraud (from the English anti-fraud)) after each completed operation, during the implementation of which BT is used or canceled (in particular, activated).
  • a bank card identifier is used to work with a bank card (in particular, with a user’s (bank) account (212, FIG.
  • HASH amount (cryptogram) of a bank card (the HASH amount calculated for a bank card, for example, for a bank card number, CVV2 code, CVC2 code, etc.) and which is used in information exchange between participants in the System (100, FIG. 1), as described in the framework of the present invention.
  • intra-system identifiers intra-system user identifiers
  • main intra-system identifier can be a PAN (Primary Account Number, payment card number) of a bank card in one of the forms known or invented later.
  • Universal ticket system (universal ticket processing system 100 that implements the proposed method in which user devices 131 and a central server 151 are used, while a user terminal 131 configured to provide uninterrupted access to a central server 151 of transport, ticket services or other services performed with providing access to the servers of local transport, ticket and other service operators (242, FIG. 2), in particular, through exported and interfaces that use operator terminal devices 141 that support standard contactless interfaces
  • data is exchanged (maintained) via the contactless interface of operator terminal device 141 through which a ticket is purchased (at least one ticket is purchased).
  • the central server 151 has the ability to collect information regarding payment options, destinations, discounts, seasonal rates and documents, based on Benefits are provided.
  • the central server 151 can be used as a proxy server for parsing and analyzing (parsing) typical user requests (user requests).
  • the local system transport, ticket, etc.
  • the central server 151 can collect and process information from open sources established by the relevant regulator (640, FIG. 6), in particular, by executive authorities (OIV) (645, FIG.
  • the local server of the operator in particular, the UPS server, configured to collect, store and transmit to the user a set of access rules for the services of local transport, ticket and other service operators (222, FIG. 2).
  • the mentioned access rules include cost, validity period, mode of operation, rules for using services, parameters for providing ticket services, in general, a tariff menu for all services of a local operator.
  • the central server 151 is configured to generate notifications if the user (212, FIG. 2) made or made a choice of a local transport, ticket or other service operator (222, FIG.
  • the difference between the old rules and the set of rules for accessing the services of local operators includes a change in the terms of use, for example, the validity period, cost, procedure for receiving the service, etc. at least one transport, ticket or service system to be accessed
  • the user terminal 131 is executed by forming, by interacting with the central server 151, a list of rules defined by the corresponding local transport operator (222, FIG. 2), and requests the consent of the user (212, FIG. 2) of the user terminal device 131 for compliance with the rules (in particular, the description of the procedure for authorization of payment for the selected service), and, with the consent of the user (for example carried out by the user (212, FIG.
  • identifier associates for example, a bank card or token in the user's terminal device
  • selects the city and type of service in particular, from the available ones (which, in in a particular case, they are local operators), after which the procedure for writing off the cost of the service and generating a ticket based on the confirmed payment and then linking the ticket to a bank card or a bank card token on the terminal device are carried out Household users.
  • the user interface in a mobile application or through a web portal allows the user to display all connected transport or other systems to the UPS.
  • the terminal device of the operator 141 is configured to collect and store user data (212, FIG.
  • the comparison is a check on the side of the local operator for a ticket that is tied to a specific unique user ID without online contacting the UBP and in order to verify the unique user ID and its validity.
  • the mentioned requirements may relate to the processing of user personal data or other (open) data, in particular, a unique user identifier.
  • the user profile stored in the UBD database can be used, which orders the services of (local) operators (222, FIG. 2) seasonally (for example, every Friday evening in the evening outside the city time) or user profile (212, FIG. 2), which orders the services of operators strictly on working days at fixed hours, for such users (212, FIG. 2) an optimal package of services can be generated, and the most attractive service intervals can be offered and corresponding m tivatsionnye mechanisms, both financial and loyal, for example, reducing the cost of services, or the provision of services in the foreground.
  • the user terminal 13 1 is configured to form a reminder (for example, in the application, by sending an e-mail to the user's e-mail (212, FIG. 2), etc.) about the need for these documents during a trip. Data in the user profile is automatically added in accordance with purchases and user actions.
  • the user terminal 131 is configured to freely change the serving local transport, ticket or other service system, if there are alternatives. For example, traveling by intercity or regular bus, or using subways or commuter trains.
  • System 100 provides the User (212, FIG. 2) a Connection Form for binding a user device (bank card or other smart card with a chip, including a contactless, user terminal device 131 with a contactless module or other interface for interacting with public networks or otherwise devices simulating them) as a carrier of a user identifier in the System 100, which is a special case of an intra-system user identifier (212, FIG. 2).
  • payment is made by the user (212, FIG. 2) in the mode of direct debit of funds by the processing center of the local system selected by the user, and payment for the services of local operators (222, FIG. 2) is made (carried out) in an automated mode by transferring funds from user in UBR, and from the UBP system 100 to local operators (222, FIG. 2) with the generation of a one-time identifier of the provided service in the system 100.
  • local operators (222, FIG. 2) are registered in the system 100 with an increased degree protection, and the responsibility (according to the rules of the IPS) to the user (212, FIG.
  • the aforementioned one-time identifier of the provided service is an identifier of a transaction that combines the issue of a one-time ticket, its payment and redemption, moreover, such an identifier is used in the UBP system and stored in its database.
  • the system 100 stores user account data (user accounts (212, FIG. 2)) and provides them to processing centers of local transport, ticket or other service systems upon request, and the user (212, FIG. 2) confirms the possibility of cancellation means (for example, by using a user terminal 131, in particular using an application installed on a user terminal 131).
  • the user terminal 131 determines the location (in particular, geolocation) user (212, FIG. 2) (in particular, the user’s terminal device 131), and provides a comparison of the location (geo-location information) of the user (212, FIG. 2) with the location of the local transport, ticket or other service system or local transport point, ticket or other service system, and offers (for example, in the application, on the website, etc.) the optimal tariff and information about the operator of local systems in accordance with the (approximate) location of the user (212, FIG. 2).
  • each user When connected to System 1 00, each user (212, FIG. 2) is assigned an intra-system identifier (hash sum (from the English HASH) of data generated by system 100 according to a specific algorithm) used to identify the user (212, FIG. 2) inside 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 medium that allows issuing payment functionality of the bank card), or the local transport, ticket or other operator (222, FIG.
  • an intra-system identifier key sum (from the English HASH) of data generated by system 100 according to a specific algorithm) used to identify the user (212, FIG. 2) inside 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 medium that allows issuing payment functionality of the bank card), or the local transport, ticket or other operator (222, FIG.
  • a ready-made identifier for registration (which can be a disguised bank card number or a bank card UID (chip number) or a bank card token), for example, a ready-made one is used tamper-proof access device, such as open contactless smart card data.
  • a unique user identifier (212, FIG. 2) provides access to UBP services that provide automated ordering of services, their accounting and replenishment of service limits, the choice of accounting procedures for services in accordance with predefined rules, automatic replenishment of balance, renewal ticket validity period, including with instant recurrent payment, etc.
  • the formation of the guaranteed, on the part of the user (212, FIG. 2) and system 655 of ensuring the technical functionality of the ticket processing, the amount of payment and the volume of services provided, respectively, is performed.
  • the application installed on the user’s terminal device 131) can provide the user (212, FIG. 2) with the possibility of “seamless” (without performing additional operations with user’s side) changing transport, ticket or other operators when traveling on a specific route.
  • the operator may be the owner of the toll road, the operator of tickets for entertainment events, etc.
  • This approach provides the opportunity to obtain the user (212, FIG. 2) a multifunctional storage medium of information about access to the service, expanding the possibilities of domestic tourism and provides high mobility when configuring orders for complex services.
  • the application (in particular, the mobile application) installed on the user terminal 131 tracks the movements of the user (212, FIG. 2) and, in accordance with geodata (in particular, the location of the user (212, FIG. 2), in particular, the user's terminal device 131), notifies the user (212, FIG. 2) of the availability of the selected (by the user (212, FIG. 2)) transport, ticket or other service operator and the location of the stop or terminal of the operator 141.
  • the operator selects the operator, it can be made (for example, by the user, in particular, in the application) in advance, but the prepayment of services or the setting of the payment limit can be made "on the spot", for example, in the drop-off zone upon completion of the service in the case of the zone 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 payment.
  • a unique user identifier (212, FIG. 2) is activated in the system 100.
  • the activation of a unique user identifier is carried out by checking, for example, using 3D secure technology, a bank card or a banking token cards in an NFC-enabled device at the issuing bank to confirm that the bank card is not blocked or stolen.
  • the central server (151, FIG. 1) enters the unique user identifier and the intra-system identifier in all terminal devices of the user (s) 131 and terminal devices of the operator (s) 141, which in the particular case are POS terminals (newpos, verifone and others), mPOS terminals, transport validators and other workstations.
  • the terminal devices of the operator work (interact) with a (real) bank card (101, FIG. 1), as a carrier of a unique identifier (W) for the user and the services available to the user (access to the service), and are the devices of the acquirer bank (610, FIG. 6), or the operator (222, FIG. 2) of the local transport, ticket or other service system that are connected to the UBP (100, FIG. 1).
  • a (real) bank card 101, FIG. 1
  • W unique identifier
  • the terminal devices of the operator work (interact) with a (real) bank card (101, FIG. 1), as a carrier of a unique identifier (W) for the user and the services available to the user (access to the service), and are the devices of the acquirer bank (610, FIG. 6), or the operator (222, FIG. 2) of the local transport, ticket or other service system that are connected to the UBP (100, FIG. 1).
  • the user's TIN (in particular, using the UBF interfaces) or another unique identifier (personal identifier, personal key, personal code) is associated with a unique user identifier (212, FIG. 2) in the system (UBP) 100, for example, SNILS (insurance personal account number), user phone number, email 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) to report on the services provided to the user, for example, with the creation of documents for reporting to the user (check, information about the provided service, etc.).
  • UBP unique user identifier
  • the user When accessing the services of, for example, a transport operator, the user (212, FIG. 2) uses a unique user identifier and an intra-system identifier, the system provides services.
  • the “conventional units” units of the tariff menu of the local operator) are written off and the balance is reduced by the amount of units (quantity) corresponding to the services provided.
  • debiting and payment can be made according to predefined rules (in particular, stored in the user profile and tariff menu in the UBP), for example, once a half hour, once a day, once a week or a month.
  • the user may be provided with an advance for services not confirmed by immediate payment.
  • Some features for example, the possibility of delayed direct debit of funds or changing the balance of the user in the UPS, may exist due to the possibility of temporary disconnection of the user (212, FIG. 2) or terminals (for example, transport terminals, etc.) from the transmission network data i.e. lack of constant communication with the UBP.
  • a transport terminal for example, a transport terminal, a bank card or other smart card with a chip, a contactless smart card, a user terminal 131 with an NFC module, or other access to public networks (from Public data network).
  • the network configuration of the transport terminal can be done in advance and remotely. For example, can be customized a no Bluetooth connection in the emulation or registration mode in the registry of the operating system of the user's terminal device (131, FIG.
  • connection to a wired or wireless network is configured, for example, using a wi-fi connection, transport, ticket or other 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.
  • the user selects the tariff using the user terminal device 131, payment is made in the pay-as-you-go mode, using the payment system available to the terminal device of the operator 141, in particular, the terminal local operator’s device, online or offline (offline).
  • the user terminal 131 contains a protected memory area certified for the selected operator, which stores information on previously paid by the user but not fulfilled obligations of local operators (units, tickets, etc.) available to the user (212, FIG . 2).
  • the user terminal 131 contains data structures in the protected area of the memory that provide automated payment and replenishment of the number of service units, the choice of the procedure for writing off service units (transport units, arbitrary units), in accordance with predefined rules.
  • the procedure for the return of funds for unproven services can be determined by the system (UBP) 100 and selected by the user (212, FIG. 2) from the conditions previously determined by the parties.
  • payment for services and / or their sets can be made in cash at terminals or at ATMs with cash reception, and taking them into account through interaction with terminal devices (user terminal devices 131 and / or operator terminal devices 141) connected to System 100.
  • payment for services and / or their sets can be made in cash at the terminal device of the local operator of the transport, ticket or other service system or at an ATM with cash reception.
  • FIG. Figure 2 shows an example of the interaction of the System 100 with the user (s) 212 and the Operators (local operators) 222 of local servers 242 in cities.
  • the user 212 registers (262) his unique user identifier in the system 100 through the Connection Form to the system 100 and selects a set of services (Tickets).
  • the system 100 uses a user device (supporting an intra-system user identifier, in particular, a user identifier in the System 100), in particular, a user terminal device (131, FIG. 1) providing access to a central server (Systems) 151 and registered in the System 100, which allows the user (212, FIG. 2) to access the service previously ordered through the System 100 from the Operator of the local system (operator of local systems, operator of local servers) 222.
  • a user device supporting an intra-system user identifier, in particular, a user identifier in the System 100
  • a user terminal device 131, FIG. 1
  • Systems central server
  • the central server (Systems) 151 has access to the servers of local (independent) system operators (242, FIG. 2) that provide sales and accounting services (Tickets) on their own behalf or on behalf of a third party.
  • System 100 assigns (272) a set of services ordered by user 212 to an intra-system identifier and exchanges this data with Operators of local servers 222.
  • Servers of local operators contain a set of rules for accessing services (service attributes defined by the rules for using local operators of systems 222) and translate (in particular, transfer) them to System 100 using the available tools of System 100, in particular, the Internet (121, FIG. 1).
  • Local operators of systems 222 are independent information systems (IS), for example, ASOP, ASKP, RZD, TsPPK, AEROEXPRESS, AEROFLOT, TIKETLEND, etc., acting as a technological link of access to the possibility of ordering services by the User (212, FIG.
  • IS independent information systems
  • a card validation 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, MPS.
  • System (100, FIG. 1) this information exchange takes into account and settles with one of the operators of the local systems (222, FIG. 2), in particular, the acquirer represented by the bank (610, FIG. 6), and the user (in particular, presented the issuing bank (675, FIG. 6) ⁇
  • the functioning of a part of the described system 100, or at least one of its parts, as described in the framework of the present invention operates (works) by pay-as-you-go (pay for what you used (what you used )), with information exchange between the bank acquirer (610, FIG. 6) and the issuing bank (675, FIG. 6) of the card (acquirer bank -> bank card issuer), while the acquirer bank (610, FIG. 6) knows which local onepaTopa terminals (POS-terminals (post-terminals)) belong to which organization and if the organization is connected to System (100, FIG. 1), then the issuer (550, FIG. 5) notifies the System (100, FIG. 1) of a one-time pass (user 212, for example, upon transition through the turnstile in the subway, bus, etc.), because system 100 must generate a Ticket for a one-time service.
  • POS-terminals post-terminals
  • both the acquirer bank (610, FIG. 6) and transport operators (and other ticket operators) 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 on).
  • the 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 the 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).
  • the 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).
  • FIG. 3 shows an exemplary embodiment of the communication of the described system 100 and local operators (operators of local systems, operators of local servers).
  • the system 100 is connected to the Operators of local servers 222, which can be located in different cities and be responsible for different types of services (including transport, but not limited to).
  • the local operators can be the Operator of the local server ((620, FIG. 6) ASOP, Automated Payment System) 343, for example, the city of Moscow;
  • the operator of the local server (SEKOP, Electronic Payment Control System) 353, for example, the city of St. Russia;
  • Local server operator (ASKP, Automated Drive Control System) 363, for example, the city of Rostov;
  • the operator of the local server ((620, FIG. 6), ASOP) 373, for example, the city of Sochi;
  • the operator of the local server ((620, FIG. 2) can be the Operator of the local server ((620, FIG. 6) ASOP, Automated Payment System) 343, for example, the city of Moscow;
  • SEKOP Electronic Payment Control System 353, for example, the city of St. Russia;
  • Local server operator (ASKP, Automated Drive Control System) 363, for example, the city of Rostov;
  • the operator of the local server ((620, FIG. 6), ASOP) 373, for example, the
  • ASOP ASOP
  • the city of Novgorod Veliky Novgorod
  • the operator of the local server 222 may be (may be) module 313 of the system 100.
  • the specialized operator 313 of the system (UBP) 100 can act as a local operator system, which implements, at least, the functionality for issuing, accounting and handling service identifiers (in particular, an intra-system identifier) and correlation of such identifiers with service classifiers (in in particular, the functional of the IS of the local operator), as well as and with the functionality (IS of a local operator) of interaction with external IPs owned by counterparties (ticket agents or subagents for the provision of services) that provide sales and accounting of transport, ticket or other services. If the local operator does not have its own IS, the UBP provides it with all the necessary functionality of such an IS.
  • FIG. Figure 4 shows an example of the interaction of the described system (UBP) 100, user 212, organization (credit organization) 424, involved by the operator of the local server 222 and UBP tools (for integration with a credit organization) 434.
  • UBP described system
  • the system (UBP) 100 prepares (forms) a list of rules and requests the consent of the said user (in particular, through the application installed on the user's terminal device 131) to verify compliance with the given rules, in particular, the set of services selected by the user, the user's payment instrument, and, with the consent of the user (212, FIG. 2), checks the possibility of its compliance with the rules.
  • the user selects the mentioned rules through the system interface, and such rules are generated by the System 100 itself, taking into account the rules of the local system operators and based on the options (conditions) available to the user, for example, the tariff menu items that the user selects.
  • the System 100 collects user data in advance (212, FIG. 2), in particular, elements of the tariff menu selected via UBP interfaces, and stores data (information) in the database of the central server 161 about which rules the user (212 FIG. 2) is ready to follow. Also, based on the information previously collected by the System, local systems (and / or their operators) can be determined that correspond to the model wishes of the user (212, FIG. 2), in particular, based on historical data about the user's choice, in a particular case, which are user profile. The mentioned historical data is generated by the System 100 based on the customer experience of the User (212, FIG. 2), in particular his profile, in cases where the user (212, FIG.
  • System 100 may, based on an analysis of historical data and a user profile in UBP, offer the most attractive combinations of services for the User profile (212, FIG. 2), taking into account data received from third-party information systems, for example, in case of changing user data in systems integrated with UBP (for example, local systems of operators) data is added to the user profile (the user profile is enriched with data).
  • third-party information systems for example, in case of changing user data in systems integrated with UBP (for example, local systems of operators) data is added to the user profile (the user profile is enriched with data).
  • 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 for interacting 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.
  • the mentioned rules for interacting with the system and access rules are stored on the system side.
  • access rules are responsible for the possibility of using elements, and use rules for the specifics of interaction with a particular local system or UBP.
  • This action of the User (212, FIG. 2) may be of a conclusive nature and cause a chain of contractual obligations and instructions, between the User (212, FIG. 2), the System 100 itself, Third-party information systems, Operators of local systems, organizations performing official, organizational and financial and legal functions for System 100 and its participants.
  • the selected set of services is assigned a unique identifier, which is the identifier of the service, and the local system operator (s) is provided for internal registration and processing with a ready-made intra-system identifier (user (and service)), different from the unique user identifier, for example, the user identifier is used in System 100, protected from fake, for example, the identifier of a contactless smart card or other device emitting it.
  • System 100 may provide the user (212, FIG. 2) with the possibility of a “seamless” change of the Local System Operators under the conditions of internal restrictions predefined by System 100, and examples of such restrictions may be a restriction per trip (no more than one trip), session, client pass .
  • the unproven service of one Local System Operator can be, at the request of the user (212, FIG. 2), if this is determined in advance, converted into the service of another Local System Operator (or to another service of the same Local System Operator).
  • the operator may be the owner of the toll road, or the operator of a transport, ticket or other service system or other service provider.
  • a unique user identifier is activated in System 100.
  • a unique user identifier and an intra-system user identifier are entered (carried out) into the specified ones (in particular, available and / or selected by the user (212, FIG. 2)) local systems of operators (systems of local operators).
  • an unconditional (common) user identifier is attached to the unique user identifier of the system (UBP) 100, for example, the user's phone number, user email address, etc., which includes an indication of the method of data transfer and allowing the user (212 , FIG. 2) receive fiscal documents (in particular, generated using the fiscalization system (665, FIG. 6)), and the System 100 and the operators of local systems to report to the user (212, FIG. 2) through C for 100 services, this operation can be performed at the stage of processing by the System 100 of the User Connection Form (212, FIG. 2) or by other means at the discretion of the User (212, FIG. 2).
  • the user When accessing the services of local system operators, the user (212, FIG. 2) uses the user identifier in the System 100, and the System 100 takes into account the status of the services (the service is provided, not provided, the rest of the services) provided to the user (212, FIG. 2). There is a record (in particular, the system 100 records) of the services rendered and a corresponding decrease (decrease) in the balance of the limit of obligations (services, tickets), in accordance with the services provided, in particular, it writes off conventional units (transport units) from the (bank) account user (212, FIG. 2).
  • a request for reservation or blocking of funds is made from the identifier of the terminal device of the local operator the cost of the service, and, when restoring the communication channel, checking the presence of the binding of the identifier mentioned above to the BT with the subsequent registration of the fact of the provision of the service of the corresponding write-off of funds (in particular, conventional units (transport units ) With the user accounts (212, FIG. 2)).
  • the system (UBS ) 100 associates (454) the service with a payment card or Payment card Token on the user's terminal device 131 using the UBS 100's own funds.
  • a unique identifier in particular, a payment card or Payment card token on the terminal user device operator 131 to the terminal device of the operator (222, FIG.
  • the terminal device of the operator sends (474), in particular, transmits an authorization request (request for authorization) to the credit institution 424, in particular, the organization engaged by the operator of the local server ( 222, FIG. 2).
  • the credit institution 424 routes (484) the transport transaction (605, FIG. 6), in particular, to the system 100, by means of the tools provided by the UBS (UBS tools) 434.
  • UBS tools the tools provided by the UBS
  • the System 100 maintains (records) 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 by the mentioned User of a (personal) user ID in the System 100.
  • confirmation of the provision of the service may be the redemption (activation) of the ticket providing the right to receive it.
  • the System 100 captures the user's territorial preferences (212, FIG. 2), in particular, implemented using geo-referencing (geo-referencing), and, in accordance with the geography of use of the System 100, can notify (for example, using a terminal device user 131, in particular, using the application installed on it) user (212, FIG. 2) on the availability of the selected local system operator (local system operator) and the location of the points of receipt of previously op Achen services (in particular the geographical location of terminals operators, in particular, local operators).
  • the choice of the local system operator and the size of the purchased services can be made (by the user (212, FIG.
  • reduction of the balance of available services in particular, debiting funds from the user's account (212, FIG. 2)
  • restoration of their fixed limit can be performed by UBP based on the parameters specified by the user according to predefined rules, for example, every half hour , once a day, once a week, month, three months, a year or another interval specified by the user (212, FIG. 2) and System 100.
  • the user (212, FIG. 2) may be granted access to services not immediately confirmed by them by payment.
  • the network configuration of the terminal device of the local systems operator can be made in advance and remotely by System 100.
  • a Bluetooth connection can be configured in the emulation or registration mode in the operating system registry of the user terminal device (131, FIG. 1), or the connection to the wi-fi network of the local systems operator is configured, to which the terminal device of the local systems operator is connected.
  • System 100 can give (present) a hint (for example, to the terminal device of the user 131, in particular, through the application installed on it) regarding the use of a specific user identifier and a 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.
  • the user selects the tariff set by the Local System Operator and, using the user identifier, is made (carried out) payment in pay-as-you-go mode (for example, the full cost of a one-time service), using the means of a payment system available to the local Operator of the local system online or offline.
  • pay-as-you-go mode for example, the full cost of a one-time service
  • the Local System Operator can transfer to the 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.
  • FIG. 5 shows an exemplary embodiment of ticket processing.
  • the user (passenger) 212 buys a ticket of the city transport system (a specific city, a specific type of ticket) and binds it (51 1) to his payment card or token of the payment card through UBP 100.
  • the user (passenger) 212 pays for the fare using the linked ticket to his payment card or payment card token (512).
  • the local operator 533 sends (513) an authorization request (authorization request) to the 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 UBP 535 software module, in particular, the acquirer integrated in the bank processing (610, FIG. 6).
  • a balance decrease (515) is recorded Optionally (alternatively), for example, if the Ticket is not purchased (by user 212), the expiration date of the (Ticket) has expired, the UBP system refused, then Weier 525 binds (516) to at least one of the payment systems 545 (FIG.
  • the payment system 545 in particular, the Ministry of Railways authorizes (517) a bank card from an issuer (issuer of a passenger payment card) 550, then (optional) funds from the issuer's account 550 through the acquirer 525 (518) are transferred to the settlement account of the bank of the local operator (bank servicing the local operator 533) 555 and then (optionally) the funds are credited (519) to the settlement account of the local operator (in particular, the carrier) 533.
  • FIG. Figure 6 shows the interaction scheme of the main functional participants of the transaction within the framework of the UBP operation, and the composition and sequence of the transmitted data between which is determined during the application implementation.
  • FIG. 7 shows one of the example scenarios of universal ticket processing (UBP) scenarios, in particular, an example scenario of registering a RATCH (bank) card and creating a Token in UBP is shown.
  • UBP universal ticket processing
  • the Ticket Token ID registration logic includes:
  • the UBP Core sends a request for the formation of the Token (in particular, the IPS Token).
  • the validity of the PAN (bank) card is verified, in particular, using the mentioned Moon algorithm.
  • the bank issuer 675 forms a confirmation of the validity of the (bank) card and creates a bunch of the Payment Token and the key (Key), which is a special case of procedures regulated by the rules of the IPU.
  • the Payment Token is formed and transferred to at least one of the described devices (in particular, to the user’s terminal device 131 and / or the operator’s terminal device 141), which in the particular case ensures the safe functioning of the systems, as in the framework of the MMS , and in the framework of UBP.
  • a notification about the loading of the Payment Token is transmitted to at least one of the payment systems 545, in particular, to the MPS, and the issuing bank 675.
  • System 655 contains a database of directories 656 of the basic conditions that determine the interaction protocols. Data formats, payment terms and other working conditions of local transport operators and the possibility of their interaction with universal ticket processing. To facilitate interaction with by local transport operators, system 655 contains interaction gateways 660, which should provide stable communication with local operators.
  • Interaction can be provided, for example, through 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.
  • Gateways can also support logical secure communication channels, for example, using protocols of virtual private networks (Virtual Private Network).
  • the 670 clearing system and fiscalization system 665 provide, respectively, the ability to offset cash and record cash flows in accordance with financial reporting standards.
  • the system 655 addresses the issuers 550 and non-issuers 630 using the application interfaces defined for them, for example, using the application interface 625, respectively, the description of which can be contained in the reference 655 of the basic conditions.
  • FIG. Figure 8 shows one of the example scenarios of universal ticket processing, in particular, an example of the scenario for linking the Ticket to an intra-system identifier (issuing and downloading the Ticket Token to the user terminal 131 with NFC).
  • user 212 After user 212 has registered a unique (personal) identifier (user) in system 100 and has established a payment Token, user 212 selects an available service provider and type of Ticket. Further, the described system 100 requests from the merchant (local operator of transport systems) 808 a unique ticket identifier. Next, the system 100 deducts the cost of the Ticket from the user’s account 212. Next, the system 100 generates a Ticket Token for downloading to the user terminal 131. Next, the system 100 registers the BT in the registry, in particular, in the system registry of UBP.
  • control module handling UBP 818 can function:
  • control module for handling UBP 818 can operate in the information flow between the Bank Acquirer and the MPS to determine the presence of BT in the system.
  • the circulation control module is used to control BT generation, intercepting the information flow between the acquirer and the MPS, or for additional verification of the existing BT, in the information flow between the MPS and the Issuer.
  • FIG. Figure 9 shows one of the example scenarios of universal ticket processing, in particular, an example of the scenario for linking the Ticket to an identifier (issuing a Ticket Token without downloading it) is shown.
  • the user 212 After the user 212 has registered a unique (personal) identifier (user) in the system 100 and has agreed to direct debiting, the user 212 selects the available service provider and the type of Ticket. Further, the described system 100 requests a unique ticket identifier from the merchant 808. Next, the system 100 deducts the cost of the Ticket from the user’s account (user’s card account, 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 the BT in the registry.
  • FIG. 10 shows one of the example scenarios of universal ticket processing, in particular, an example scenario of the Ticket Token validation is shown.
  • FIG. 11 shows one of the example scenarios of universal ticket processing, in particular, an example variant of the script for validating an intra-system identifier is shown.
  • user access to the equipment of local systems in the universal ticket processing system 100, can be centralized collection and storage in a single database 161 of information (data) related to the conditions of transportation of local systems of local operators 222 (operators of local systems, operators of local servers 242 ) generated by the local operators of systems 222, for the user 212 selected at least one of the local systems, and the user 212 (in particular, to the terminal devices about the user 131) transmit the mandatory set of rules for accessing the equipment of the local system stored in a single database 161, requests the consent of the user 212 for compliance with the mandatory set of rules and, with the consent of the user 212, select the storage medium for storing the user identification code 212, check the user’s ability 212 correspond to the set of mandatory rules of at least one of the local operators 222, and user 212 is registered, at least in one of the local systems, they provide the user 212 with the services of a local operator using an information carrier based on the results of at least one mandatory rule from a set of mandatory rules,
  • the user’s terminal device 131 transmits, via a contactless data device, an identification code and a code set of data to the local system and the local system asks the local system acquirer bank 610 for confirmation of the validity of the user's bank details with the transmitted identifier , and, for a user with valid bank details, services are provided (local system of local op the speaker).
  • a portable user communicator 212 can be used as the mentioned storage medium.
  • one of the mentioned (mandatory) rules is payment for 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.
  • the user identification code of the local system generated in the local system can be used, and this identification code of the user of the local system is stored in a single database 161 and local the transport system is provided with such a user identification code of the local system upon request containing a universal user identification code, we use first to identify the user in the system (combined ticket processing) 100 It is also worth noting that to ensure user access to the equipment of the local system, a wireless connection between the storage medium and the computing resources of the local system used to verify the identification code (user or user of the local system) and above the specified rule can be used, and setting up the specified wireless connection can be implemented in advance.
  • 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, can be final (computing) devices a user or operator including a processor 21, a system memory 22, and a system bus 23 that couples various system components, including the system memory, to the processor 21.
  • 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, can be final (computing) devices a user or operator including a processor 21, a system memory 22, and a system bus 23 that couples various system components, including the system memory, to 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 read only memory (ROM) 24 and random access memory (RAM) 25.
  • ROM 24 stores the basic input / output system 26 (BIOS), which consists of basic routines that help exchange information between elements within the computer 20, for example, at the time of launch.
  • BIOS basic input / output system 26
  • 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 CD, a digital video disc, and other optical means.
  • the hard disk drive 27, the magnetic disk drive 28 and the optical disk drive 30 are connected to the system bus 23 via the hard disk drive interface 32, the magnetic disk drive interface 33, and the optical drive interface 34, respectively.
  • Storage devices and their respective computer-readable means provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for computer 20.
  • Computer 20 includes a file system 36 associated with or included with the operating system 35 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 a keyboard 40 and pointing device 42.
  • Other input devices Oguta include a microphone, joystick, game pad, satellite dish, scanner, or any other.
  • serial port interface 46 that is connected to the system bus, but can be connected via other interfaces, such as a parallel port, game port, or universal serial bus (UPTTT) Monitor 47 or other type of device a visual display is also connected to the system bus 23 via an interface, for example, a video adapter 48.
  • video adapter 48 In addition to the monitor 47, personal computers typically include other peripherals output (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.
  • the remote computer (or computers) 49 may be another computer, server, router, network PC, peer to peer device, or other node on a single network, and typically also includes includes most or all of the elements described above with respect to computer 20, although only an information storage device 50 is shown.
  • Logical connections include a local area network (LAN) 51 and a global computer yuternuyu network (SCS) 52.
  • LAN local area network
  • SCS global computer yuternuyu network
  • a computer 20 used in a LAN network environment is connected to a local area network 51 via a network interface or adapter 53.
  • a computer 20 used in a GKS network environment typically uses a modem 54 or other means for communicating with a 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.
  • program modules or parts thereof described with reference to computer 20 may be stored on a remote information storage device. It should be noted that the network connections shown are typical, and other means may be used to establish communication communication between computers.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Primary Health Care (AREA)
  • Marketing (AREA)
  • General Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Health & Medical Sciences (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

СПОСОБ ДОСТУПА ПОЛЬЗОВАТЕЛЯ К УСЛУГАМ ЛОКАЛЬНОГО ОПЕРАТОРА
ОБЛАСТЬ ТЕХНИКИ
Изобретение относится к области сетевых коммуникаций и может быть использовано для доступа пользователей к услугам без существенных территориальных ограничений, в части места заказа услуг и расположения предприятий, оказывающих услуги. Помимо прочего, система позволяет обеспечить пользователя беспрепятственное использование транспортных средств, как на заранее заданном маршруте, так и при изменении маршрута пользователя.
УРОВЕНЬ ТЕХНИКИ
Известные системы, такие как Московская транспортная система, используют для предоставления транспортных услуг специальные носители информации, например, карта «Тройка» или специальная сим-карта. Указанная карта «Тройка» может быть использована для предоставления услуг других транспортных систем, например, системы поездов пригородного сообщения, но для доступа к услугам соответствующей транспортной, билетной или иной сервисной системы используется инфраструктура этой транспортной системы, а карта «Тройка» используется только в качестве носителя информации.
В большинстве случаев пользователь вынужден использовать носитель билета, обозначенный владельцем (оператором) билетной системы (QR, штрих код, числовой код, специальные бумажные или пластиковые карты и т.п.), что создает существенные неудобства и может быть оптимизировано за счет нового подхода к применению современных бесконтактных технологий на базе открытых стандартов.
Наиболее близким к предложенному техническому решению является изобретение согласно патенту Евразии ЕА004994, опубликованному 28.10.2004. В указанном патенте описано изобретение, позволяющее использовать одну систему для предоставления доступа к нескольким услугам. Вместе с тем, в известном техническом решении носитель информации обеспечивает доступ только к транспортным услугам одной системы, а сведения, обеспечивающие доступ к другим услугам, предоставляются только по идентификационным данным, нанесенным на проездной документ. Подлинность данных или носителя информации не проверяются.
Таким образом, в уровне техники отсутствуют средства, обеспечивающие удобную интеграцию различных транспортных, билетных и прочих сервисных систем, и обеспечение высокого уровня комплексной безопасности с точки зрения неправомерного доступа к транспортным, билетным и иным сервисным системам.
РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Настоящее изобретение предназначено для устранения указанного и других недостатков уровня техники, а также для достижения технического результата, заключающегося в повышении безопасности системы, как с точки зрения конечного пользователя, так и с точки зрения систем, в которых, при использовании предложенного изобретения, существенно повышается надежность защиты от подделок. Кроме того, предложенная система обеспечивает возможность интеграции транспортных, билетных и прочих сервисных систем без внесения изменений в их функциональность, а также не требует выпуска специальных идентификаторов или носителей информации.
Настоящее изобретение приводит к снижению затрат на выпуск идентификационных средств и проездных документов, снижает количество операций, совершаемых пользователями при заказе и получении услуг, позволяет уменьшить количество действующих идентификаторов, являющихся, в частном случае, носителями билетов всех форм-факторов, например, транспортных карт, печатных билетов, одноразовых билетов с магнитной полосой и чипом, предоставляющих доступ к услугам, обеспечивает высокую степень защиты от их использования посторонними лицами, а также дает возможность принимать плату за услуги (в том числе транспортные) в режиме максимальной автоматизации.
Для достижения указанного технического результата в способе обеспечения доступа пользователя к услугам локального оператора услуг в системе универсального билетного процессинга осуществляют централизованный сбор и хранение в единой базе данных информации, относящейся к условиям предоставления услуг множества локальных систем предоставления услуг, управляемых локальными операторами систем предоставления услуг, где услуги предоставляются по месту нахождения пользователя; для локальной системы предоставления услуг, выбранной пользователем из множества локальных систем предоставления услуг, передают пользователю набор правил доступа к услугам локальной системы предоставления услуг, сохраненный в единой базе данных, где набор правил содержит обязательный набор правил; запрашивает согласие пользователя на соответствие обязательному набору правил; выбирают, по согласованию с пользователем набор дополнительных правил, при согласии пользователя, выбирают носитель информации для хранения идентификационных данных пользователя, проверяют возможность пользователя соответствовать обязательному набору правил локального оператора, регистрируют пользователя в локальной системе локального оператора с использованием идентификационных данных пользователя; при нахождении пользователя в зоне оказания услуг считывают идентификационные данные пользователя с выбранного носителя информации, проверяют регистрацию пользователя со считанным идентификационными данными в локальной системе предоставления услуг, и при регистрации пользователя в локальной системе предоставления услуг, по выбору пользователя, предоставляют пользователю услугу в соответствии с дополнительным набором правил и с проверкой соблюдения, по крайней мере одного из правил из набора обязательных правил.
В частном случае, услугой является транспортная услуга.
В частном случае, транспортная услуга является многоразовой.
В частном случае, транспортной услугой является транспортировка пользователя.
В частном случае, транспортной услугой является пропуск на проезд по платной автодороге.
В частном случае, транспортной услугой является пропуск на стоянку транспортных средств.
В частном случае, идентификационными данными пользователя является, часть реквизитов счета пользователя в банке эмитенте счета пользователя.
В частном случае, частью банковских реквизитов счета пользователя являются реквизиты банковской карты, привязанной к счету пользователя.
В частном случае, частью банковских реквизитов счета пользователя является уникальный токен, привязанный к банковской карте, привязанной к счету пользователя.
В частном случае, токеном системы универсального билетного процессинга является идентификатором, привязанным к банковской карте, привязанной к счету пользователя.
В частном случае, выбранным носителем информации является портативное средство хранения данных, выполненное с возможностью бесконтактного считывания данных.
В частном случае, портативным средством хранения данных является бесконтактная банковская карта пользователя.
В частном случае, портативным средством хранения данных является коммуникатор пользователя. В частном случае, при нахождении пользователя в зоне предоставления услуг, после считывания идентификационных данных пользователя, дополнительно проверяется валидность банковских реквизитов пользователя, а предоставление услуги осуществляется только для пользователя с валидными банковскими реквизитами.
В частном случае, валидность банковских реквизитов пользователя проверяется и подтверждается банком эквайрером, обслуживающим локальную систему предоставления услуг.
В частном случае, для обеспечения доступа пользователя к оборудованию локальной системы используют беспроводное соединение носителя информации и вычислительных средств локальной системы, используемых при проверке идентификационного кода, а настройку указанного беспроводного соединения осуществляют заранее.
В частном случае, пользователь связан с системой универсального билетного процессинга через сеть Интернет с использованием оконечного устройства пользователя посредством привязки банковской карты.
В частном случае, при необходимости доступа к услугам локального оператора, оконечное устройство пользователя передаёт через устройство бесконтактной передачи данных, идентификационный код и кодовую совокупность данных локальной системе, локальная система запрашивает у банка эквайрера локальной системы подтверждение валидности банковских реквизитов пользователя с переданным идентификатором, и, для пользователя с действительными банковскими реквизитами осуществляется предоставление услуг.
В частном случае, проверка валидности банковских реквизитов пользователя осуществляется платежной системой при регистрации банковской карты в системе универсального билетного процессинга.
В частном случае, при заказе услуги платежной системой осуществляется повторная проверка валидности банковских реквизитов пользователя.
В частном случае, если услуга подключена, то банк эквайер, обслуживающий локального оператора, при осуществлении проверки валидности банковских реквизитов пользователя банковской карты пользователя, подключенной к системе универсального билетного процессинга, отправляет запрос в систему универсального билетного процессинга о наличии средств на счете пользователя или наличии у пользователя купленного билета для оказания пользователю услуги и привязанного к счету пользователя, причем при наличии билета система универсального билетного процессинга предоставляет пользователю услугу без списания средств со счета пользователя, где система универсального билетного процессинга осуществляет расчет локальным оператором, банком эквайером и банком эмитентом с учетом такого обмена данными между банком эквайером и системой универсального билетного процессинга.
В частном случае, если услуга не подключена, то осуществляется обмен данными между банком эквайером и банком эмитентом счета пользователя, при этом банку эквайеру известна принадлежность оконечных устройств локальных операторов соответствующим организациям и, если организация подключена к системе универсального билетного процессинга, то эмитент уведомляет систему универсального билетного процессинга об оказании разовой услуги для осуществления генерации билета под такую разовую услугу.
В частном случае, банк эквайер и локальные операторы подключены к системе универсального билетного процессинга с использованием интерфейса, предоставляемого системой универсального билетного процессинга или, в случае, предоставления банком эквайером и локальными операторами собственных интерфейсов, система универсального билетного процессинга подключается к банку эквайеру и локальным операторам по таким предоставляемым интерфейсам
В частном случае, для информационного обмена между участниками системы универсального билетного процессинга используется внутрисистемный идентификатор, отличный от идентификатора банковской карты, являющегося идентификационными данными пользователя в части реквизитов счета пользователя в банке эмитенте счета пользователя, причем внутрисистемным идентификатором является хеш-сумма, вычисленная с использованием PAN банковской карты.
В частном случае, для информирования пользователя о совершенных операциях, служебной и коммерческой информации используется электронная почта пользователя, номер мобильного телефона пользователя и/или личный кабинет пользователя в системе универсального билетного процессинга.
В частном случае, оконечными устройствами локальных операторов, осуществляющих взаимодействие с банковской картой, привязанной к счету пользователя, являются устройства банка эквайера или устройства локальных операторов, подключенных к системе универсального билетного процессинга.
В частном случае, формируется кодовая совокупность данных, характеризующая верифицированные реквизиты счета пользователя, обеспечивающая безусловное проведение платежа между банком эквайрером, локальной системы и банком эмитентом, соответствующим реквизитам счета пользователя, с одновременной регистрацией реквизитов счета пользователя в системе локального оператора.
Для достижения указанного выше технического результата предложено портативное устройство для обеспечения доступа пользователя к оборудованию локальных операторов локальных систем, содержащее блок ввода информации, блок вывода информации, средство обработки информации, и средство доступа к центральному серверу, при этом устройство содержит средства аутентификации пользователя по результатам взаимодействия пользователя со средствами ввода информации, а блок обработки информации выполнен формирующим отображаемый на средстве вывода информации список локальных систем, с возможностью выбора пользователем локальной системы, при этом портативное устройство выполнено с возможностью получения от центрального сервера обязательного набора правил доступа к оборудованию выбранной пользователем локальной системы, отображения на средствах отображения информации и получения согласия пользователя на соответствие обязательному набору правил, где правила выбираются из единой базы данных информации, относящейся к условиям перевозок локальных систем, сформированных локальными операторами систем, для выбранной пользователем локальной системы, портативное устройство выполнено с возможностью хранения данных о носителе информации для хранения идентификационного кода пользователя, с обеспечением возможности передачи центральному серверу запроса на регистрацию пользователя в локальной системе и формирования напоминания о том, что предоставление пользователю услуги локального оператора осуществляется с использованием носителя информации, по результатам выполнения по крайней мере одного обязательного правила из набора обязательных правил.
Для обеспечения указанного выше технического результата предложен сервер системы обеспечения доступа пользователя к оборудованию локальных систем, содержащий средства передачи данных средства обработки данных и средства наполнения и хранения единой базы данных информации, относящейся к условиям перевозок локальных систем, сформированных локальными операторами систем, и централизованно собранных с использованием средств сбора данных, при этом сервер выполнен обеспечивающим выборку и передачу, по запросу пользователя, обязательного набора правил доступа к оборудованию локальной системы, сохраненных в единой базе данных, выбора, соответствующего набору правил, носителя информации для хранения идентификационного кода пользователя, проверки возможности пользователя соответствовать набору обязательных правил локального оператора, регистрации пользователя в локальной системе с обеспечением предоставления пользователю услуги локального оператора с использованием носителя информации, по результатам выполнения по крайней мере одного обязательного правила из набора обязательных правил.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Дополнительные цели, признаки и преимущества настоящего изобретения будут понятны из прочтения последующего описания осуществления изобретения.
Предложенные изобретения иллюстрируются чертежами:
ФИГ. 1 иллюстрирует примерный вариант Системы, описываемой в настоящем изобретении, или, по крайней мере, часть такой Системы.
ФИГ. 2 иллюстрирует примерный вариант взаимодействия описываемой Системы с пользователем (пользователями) и Операторами (локальными операторами) локальных серверов в городах.
ФИГ. 3 иллюстрирует примерный вариант связи описываемой Системы и локальными операторами (операторами локальных систем, операторами локальных серверов).
ФИГ. 4 иллюстрирует примерный вариант взаимодействия описываемой системы (УБС), пользователя, организации (кредитной организации), привлеченной оператором локального сервера и инструментов УБС (для интеграции с кредитной организацией).
ФИГ. 5 иллюстрирует примерный вариант билетного процессинга.
ФИГ. 6 иллюстрирует примерный вариант схемы взаимодействия основных функциональных участников проведения транзакции в рамках работы УБП.
ФИГ. 7 иллюстрирует один из примерных вариантов сценариев работы универсального билетного процессинга (УБП), в частности, показан примерный вариант сценария регистрации PAN (банковской) карты и создания Токена в УБП.
ФИГ. 8 иллюстрирует один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария привязки Билета к идентификатору (выпуск и загрузка Билетного Токена в оконечное устройство пользователя с NFC).
ФИГ. 9 иллюстрирует один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария привязки Билета к идентификатору (выпуск Билетного Токена без его загрузки). ФИГ. 10 иллюстрирует один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария валидации Билетного Токена.
ФИГ. 11 иллюстрирует один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария валидации идентификатора.
ФИГ. 12 иллюстрирует пример компьютерной системы общего назначения.
ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, обеспеченными для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется только в объеме приложенной формулы.
Используемые в настоящем описании изобретении термины «компонент», «элемент», «система», «модуль», «часть» и подобные предназначены (используются) для обозначения вычислительных сущностей, в частности, компьютерных сущностей (вычислительных сущностей, сущностей или объектов, связанных с вычислительным устройством, например, компьютером, компьютеризированным устройством, автоматизированным устройством и т.д.), которые могут являться аппаратным обеспечением, оборудованием (например, устройством, инструментом, аппаратом, аппаратурой, составной частью устройства, в частности, процессором, микропроцессором, печатной платой и т.д.), программным обеспечением (например, исполняемым программным кодом, скомпилированным приложением, программным модулем, частью программного обеспечения и/или кода и т.д.) или микропрограммой (прошивкой от англ firmware). Так, например, модуль (компонент и т.д.) может быть процессом, выполняющимся (исполняющимся) на процессоре, процессором, объектом, исполняемым файлом, программой, функцией, методом, библиотекой, подпрограммой и/или вычислительным устройством (например, микрокомпьютером или компьютером) или комбинацией программного или аппаратного обеспечения. В качестве иллюстрации: как приложение, запущенное на сервере (например, на центральном сервере (151, ФИГ. 1)), может быть компонентом или модулем, так и сервер может быть компонентом или модулем. По крайней мере, один компонент может находиться (располагаться) внутри процесса. Модуль (компонент и т.д.) может располагаться на одном вычислительном устройстве (например, компьютере) и/или может быть распределен между двумя и более вычислительными устройствами Так, например, в частном случае приложение (например, модуль, компонент и т.д.), может быть представлено серверным модулем (серверной частью) и клиентским модулем (клиентской частью). В частном случае, клиентский модуль устанавливается, по крайней мере, на одно вычислительное устройство, а серверный модуль устанавливается на второе вычислительное устройство, с которого, в частном случае, производится управление, контроль настройка и т.д. первого вычислительного устройства (и/или его составных модулей (компонентов, частей и т.д.)).
В отдельных случаях, далее в описании изобретения используются следующие термины и сокращения:
Система (100, ФИГ. 1) - комплекс упорядоченных программно-аппаратных средств, обеспечивающих процесс эмиссии, приёма, учёта, оборота, пополнения, списания идентификаторов обязательств по автоматизированному доступу к услугам, в том числе, по транспортным услугам.
Билет носитель информации или информационный блок, удостоверяющий право использования услуг, указанных при выпуске Билета. Билет может быть отпечатан на бумажном или аналогичном носителе, либо выполнен в электронном виде, в том числе в виде записи в базе данных (например, в базе данных 161 (ФИГ. 1), связанной с центральным сервером 151 (ФИГ. 1)).
Форма подключения - представленная в упорядоченной форме совокупность данных идентифицирующая Пользователя (212, ФИГ. 2), представляющая его персональные данные и предпочтения, и подтверждающая желание Пользователя (212, ФИГ. 2) использовать предложенную Систему (100, ФИГ. 1) на условиях, отраженных в Форме подключения.
Пользователь (212, ФИГ. 2) - физическое лицо использующее оконечное устройство пользователя (131, ФИГ. 1) или сторонних систем, подключенных к Системе (100, ФИГ. 1), с целью получения услуг (включая, но не ограничиваясь, транспортные, билетные и прочие услуги) от предприятий, фактически их оказывающих, например, сторонних систем, в том числе включающих, но не ограничиваясь, сторонние транспортные, билетные или иные сервисные системы.
Идентификатор пользователя в Системе (100, ФИГ. 1) - совокупность данных, однозначно определяющее Пользователя (212, ФИГ. 2) в Системе (100, ФИГ. 1). Указанная совокупность данных может взаимно однозначно соответствовать уникальному носителю данных, например, храниться на оконечном (в частности, персональном) устройстве пользователя (131, ФИГ. 1), в том числе, на банковской карте, аналогичной смарт-карте, с чипом, в том числе поддерживающей режим осуществления бесконтактного взаимодействия, на оконечном устройстве пользователя (131, ФИГ. 1) с бесконтактным модулем или другим интерфейсом взаимодействия с сетями общего доступа.
Тариф - ставка или система ставок оплаты за различные услуги, предоставляемые компаниями, организациями, фирмами и учреждениями.
Токен - совокупность данных, дающая возможность, получить услугу, при его предъявлении. В контексте данного изобретения, услугой является списание денежных средств с заранее заданного счета (банковского, индивидуального, специального и пр.), привязанного к банковской карте (101, ФИГ. 1) и/или оконечному устройству пользователя (131, ФИГ. 1) например, смартфону или иному устройству, в частности, работающему по бесконтактному интерфейсу, принадлежащей (принадлежащему) пользователю (212, ФИГ. 2). Технологически, для успешной реализации токена, необходимо наличие доверенного центра, удостоверяющего валидность токена и обеспечивающего списание средств со счета, привязанного к токену, в частности, чтобы при его предъявлении, получить услугу.
На ФИГ. 1 показан примерный вариант системы 100, реализующей описываемое изобретение или, по крайней мере, часть описываемого изобретения. Предложенная система (Универсальная билетная Система) 100 реализует Универсальный билетный процессинг (600, ФИГ. 6), далее - УБП). УБП предназначен для обеспечения пользователей системы 100 возможностью удаленной (дистанционной) покупки билета с возможностью привязки ранее купленного билета к (собственному) уникальному идентификатору (ID) пользователя (банковская карта 101, оконечное устройство пользователя 131 с технологией NFC(coKp. от англ. Near field communication, «коммуникация ближнего поля», «ближняя бесконтактная связь», система передачи данных с использованием электромагнитных полей близкого действия), либо иному носителю, в том числе платежному Токену платежных систем 545 (ФИГ. 5), в частности, платежному Токену Международных платёжных систем (далее - МПС)), с использованием средств, в качестве которых могут использоваться оконечные устройства пользователя 131, а также центральный сервер (центральный сервер системы, сервер системы, сервер услуг, центральный сервер услуг, централизованный сервер (системы, услуг)) 151, предназначенные для аппаратного выполнения определенных функций, относящихся к существенным признакам предложенного изобретения. Такими упомянутыми оконечными устройствами пользователя 131 могут являться различные (в том числе цифровые, аналоговые, комбинированные, механические и т.д.) устройства, в частности, но не ограничиваясь, электронные устройства. Так, например, такими оконечными устройствами пользователя могут являться персональные компьютеры, электронные вычислительные машины (ЭВМ), ноутбуки, серверы, рабочие станции, моноблоки, компьютерные стенды, банковские и вендинговые платежные терминалы, настольные компьютеры, испытательные стенды, демонстрационные компьютерные стенды, планшеты, смартфоны, мобильные (сотовые) телефоны, спутниковые телефоны, персональные цифровые помощники (PDA), «yMHbie»(smart) вещи, например, часы, браслеты, кулоны, предметы одежды, такие как ремни, головные уборы, и т.д.
К описываемой Системе 100 пользователь (212, ФИГ. 2) подключается (и отключается) с использованием оконечного устройства пользователя 131 через сеть Интернет 121 посредством привязки своей платежной банковской карты 101. Так например, пользователь (212, ФИГ. 2) может использовать оконечное устройство пользователя 131, например, компьютер, мобильное устройство пользователя, иную форму интерфейса, например офис агента, с установленным компьютером, которые являются средством взаимодействия с УБП посредством тонкого клиента (635, ФИГ. 6)·
Стоит также отметить, что описываемое изобретение может быть реализовано сетевой услугой и, в частном случае, предназначено для пользователей (212, ФИГ. 2), использующих бесконтактную технологию оплаты (EMV Contactless), причем форм- факторами носителя могут являться Бесконтактная банковская карта и Токен Бесконтактной банковской карты, размещенный на любом носителе это позволяющем (оконечное устройство пользователя 131, например, смартфон, мобильный телефон, «умные» (SMART) часы, ремень и т.д.)
Система (Универсальная билетная Система) 100 - это единая сетевая информационная платформа билетно-учётных операций, позволяющая Пользователям (212, ФИГ. 2) Системы 100 использовать (собственный)уникальный идентификатор пользователя(уникальный персональный идентификатор, уникальный ID пользователя (212, ФИГ. 2), пользовательский идентификатор, персональный идентификатор, персональный ID пользователя, собственный уникальный идентификатор (пользователя)), в частности, с использованием внутрисистемного идентификатора (пользователя), как более подробно описано в рамках настоящего изобретения, для доступа ко всем Билетам, реализуемыми, подключёнными к ней Операторами локальных транспортных, билетных или иных сервисных систем (222, ФИГ. 2) .
Центральной частью УБП является ядро УБП 111 - функциональный модуль центрального сервера системы 151, выполняющий функцию генерации уникального Билетного токена (далее - БТ) состоящего из предоставленных уникальных идентификаторов пользователя (в частности, PAN номер банковской карты, UID карты, платежный Токен карты на оконечном устройстве пользователя 131 с технологией NFC и т.д.) и параметров Билета конкретного поставщика услуг - мерчанта(от англ. Merchant— купец, торговец, коммерсант), являющегося локальным оператором транспортных систем (он же оператор локального сервера, он же, в частном случае, эмитент билета, либо организация, привлеченная мерчантом, например, для оказания подобной информационно-технической деятельности) причем такие параметры могут включать стоимость, дату покупки, срок действия, область действия, количество поездок, баланс, набор услуг, место использования и прочие реквизиты). Ядро УБП (сервис генерации токенов (банков эмитентов (675, ФИГ. 6)), сервис генерации уникальных билетных токенов) 1 11 осуществляет проверку на соответствие (причем такое соответствием является соответствие связки уникального идентификатора пользователя с номером БТ в базе данных) уникального идентификатора пользователя ранее сформированным БТ, проводит (осуществляет) проверку валидности уникального идентификатора пользователя, производит учет БТ, в частности, записей в базе данных. В частном случае, упомянутая проверка валидности уникального идентификатора пользователя осуществляется с использованием алгоритма Луна (Luhn) или иному алгоритму, в том числе с использованием HASH. Ядро УБП осуществляет перевыпуск БТ (в частности, посредством генерация нового БТ на основе старого с его заменой в базе данных, а также, в соответствии, по крайней мере, с одним правилом УБП, в частности с целью контроля обращения БТ и антифрода (от англ anti -fraud)) после каждой совершенной операции, в процессе реализации которой используется или погашается (в частности, активируется) БТ. Идентификатор банковской карты используется для работы с банковской картой (в частности с (банковским) счетом пользователя (212, ФИГ. 2), с которым связана такая банковская карта), причем такой идентификатор банковской карты отличается от внутрисистемного идентификатора (пользователя), который в частном случае является HASH-суммой (криптограммой) банковской карты (HASH- суммой, вычисленной для банковской карты, например, для номера банковской карты, кода CVV2, кода CVC2 и т.д.) и который используется в информационном обмене между участниками Системы (100, ФИГ. 1), как описано в рамках настоящего изобретения. Стоит отметить, что могут использоваться иные внутрисистемные идентификаторы (внутрисистемные идентификаторы пользователя), причем, в частном случае, основнымвнутрисистемным идентификатором может являться PAN (Primary Account Number, payment card number) банковской карты в одном из известных или изобретенных позднее видах.
Универсальная билетная система (система универсального билетного процессинга 100, реализующая предложенный способ, в которой используются оконечные устройства пользователя 131 и центральный сервер 151 , при этом оконечное устройство пользователя 131, выполненное с возможностью бесперебойного доступа к центральному серверу 151 транспортных, билетных услуг или иных сервисных услуг, выполненному с обеспечением доступа к серверам локальных транспортных, билетных и прочих сервисных операторов (242, ФИГ. 2), в частности, посредством экспортируемых ими интерфейсов, которые используют оконечные устройства оператора 141, поддерживающие стандартные бесконтактные интерфейсы. В частном случае реализации, обмен данными осуществляется (ведется) по бесконтактному интерфейсу оконечного устройства оператора 141 посредством которого происходит покупка билета(осуществляющего приобретение, по крайней мере, одного билета). Кроме того, центральный сервер 151 имеет возможность сбора информации относительно вариантов оплаты, пунктов назначения, скидок, сезонных расценок и документов, на основании которых предоставляются льготы. Кроме того, центральный сервер 151 может использоваться в качестве прокси сервера для разбора и анализа (парсинга) типичных пользовательских запросов (запросов пользователей). Для подключения к УБП, локальная система (транспортная, билетная и т.д.) может присоединиться к стандартизованному интерфейсу УБП, либо открыть доступ к своим (локальным) серверам (242, ФИГ. 2) через центральный сервер 151 в режиме прокси. В частном случае, при «автономном» подключении, в частности, при отсутствии оператора локальной системы или его выходе из строя или отключении или приостановлении действия и пр., центральный сервер (услуг) 151 может собирать и обрабатывать информацию из открытых источников, установленных соответствующим регулятором (640, ФИГ. 6), в частности, органами исполнительной власти (ОИВ) (645, ФИГ. 6), администрацией, департаментами и прочими органами управления и регулирования, в том числе, тарифной политикой, например, такую информацию, как расписания и пункты назначения, стоимость проездных документов и прочего. Таким образом, локальный сервер оператора, в частности, сервер УБП, выполнен с возможностью сбора, хранения и передачи пользователю набора правил доступа к услугам локальных транспортных, билетных и прочих сервисных операторов (222, ФИГ. 2). Упомянутые правила доступа включают стоимость, срок действия, режим работы, правила пользования услугами, параметры оказания услуг билета, в общем случае, тарифное меню по всем услугам локального оператора. Кроме того, при изменении правил доступа, центральный сервер 151 выполнен формирующим уведомления, если пользователь (212, ФИГ. 2) делал или сделал выбор локального транспортного, билетного или прочего сервисного оператора (222, ФИГ. 2) по старым правилам. В частном случае, отличие упомянутых старых правил от набора правил доступа к услугам локальных операторов включает изменение правилами пользования, например, срок действия, стоимость, порядок получения услуги и пр. При выборе пользователем (212, ФИГ. 2) оконечного устройства пользователя 131, по крайней мере, одной транспортной, билетной или сервисной системы, к которой будет производиться доступ, оконечное устройство пользователя 131 выполнено формирующим путем взаимодействия с центральным сервером 151 список правил, заданных соответствующим локальным транспортным оператором (222, ФИГ. 2), и запрашивает согласие пользователя (212, ФИГ. 2) оконечного устройства пользователя 131 на соответствие правилам (в частности, описанию процедуры авторизации платежа за выбранную услугу), и, при согласии пользователя (например, осуществленного пользователем (212, ФИГ. 2) с использованием оконечного устройства пользователя 131, в частности, посредством взаимодействия пользователя (212, ФИГ. 2) с приложением, установленном на таком оконечном устройстве пользователя 131, например, с использованием графического интерфейса пользователя (ГИИ, GUI, от англ graphical user interface) приложения), проверяет возможность соответствия правилам. Так, пользователь (212, ФИГ. 2) с использованием мобильного приложения или веб-портала выбирает какой из идентификаторов привязывает, например, банковскую карту или токен в оконечном устройстве пользователя, выбирает город и тип услуги, в частности, из доступных (которые, в частном случае, являются локальными операторами), после чего осуществляется процедура списания стоимости услуги и генерация билета на основании подтвержденного платежа и последующая привязка билета к банковской карте или токену банковской карты на оконечном устройстве пользователя. Интерфейс пользователя в мобильном приложении или через веб-портал (в частности, веб-сайт) позволяет отображать пользователю все подключенные транспортные или иные системы к УБП. В частном случае реализации, оконечное устройство оператора 141 выполнено с возможностью сбора и хранения данных пользователя (212, ФИГ. 2), относящихся к правилам и требованиям локального (транспортного, билетного или иного сервисного) оператора (222, ФИГ. 2), сравнения сохранённых данных пользователя (212, ФИГ. 2) и требований локального оператора (222, ФИГ. 2), а также выбора максимально экономичного тарифного плана локального оператора (222, ФИГ. 2). В частном случае, упомянутое сравнение является проверкой на стороне локального оператора на предмет наличия билета, привязанного к конкретному уникальному идентификатору пользователя без онлайн обращения в УБП и с целью проверки уникального идентификатора пользователя и его валидности. Упомянутые требования могут касаться обработки персональных данных пользователя или иных (открытых) данных, в частности, уникального идентификатора пользователя.
В качестве модели подбора оптимального тарифа может служить хранящийся в БД УБП профиль пользователя (212, ФИГ. 2), который заказывает услуги (локальных) операторов (222, ФИГ. 2) сезонно (например, поездка каждую пятницу в вечернее время за город в летнее время) или профиль пользователя (212, ФИГ . 2), который заказывает услуги операторов строго в рабочие дни в фиксированные часы, для таких пользователей (212, ФИГ. 2) может быть сформирован оптимальный пакет услуг, а также предложены наиболее привлекательные интервалы оказания услуги и соответствующие мотивационные механизмы, как финансовые, так и лояльные, например, снижение стоимости услуг, либо предоставление услуг в приоритетном режиме. В случае необходимости наличия документов для использования льготного плана, оконечное устройство пользователя 13 1 выполнено формирующим напоминание (например, в приложении, посредством передачи электронного письма на электронную почту пользователя (212, ФИГ. 2) и т.д.) о необходимости наличия указанных документов в поездке. Данные в профиль пользователя добавляются автоматически в соответствии с совершенными покупками и действиями пользователя. Кроме этого, оконечное устройство пользователя 131 выполнено с возможностью свободной смены обслуживающей локальной транспортной, билетной или иной сервисной системы, при наличии альтернатив. Например, перемещение междугородным или рейсовым автобусом, или использование метрополитенов или поездов пригородного сообщения.
При необходимости, с использованием оконечного устройства пользователя 131, обеспечивается выбор тарифа. Преимущественно, оконечное устройство пользователя 131 используется в качестве удаленного рабочего места для средств выбора тарифа, установленных на центральном сервере (системы) 151. Система 100 предоставляет Пользователю (212, ФИГ. 2) Форму подключения для привязки устройства пользователя (банковская карта или другая смарт-карта с чипом, в том числе бесконтактная, оконечное устройство пользователя 131 с бесконтактным модулем или другим интерфейсом взаимодействия с сетями общего доступа или иного устройства их имитирующего) в качестве носителя идентификатора пользователя в Системе 100, являющегося частным случаем внутрисистемного идентификатора пользователя (212, ФИГ. 2).
В частном случае реализации, оплата производится пользователем (212, ФИГ. 2) в режиме безакцептного списания средств процессинговым центром выбранной пользователем локальной системы, а оплата услуг локальных операторов (222, ФИГ. 2) производится (осуществляется) в автоматизированном режиме путем перечисления средств от пользователя в УБР, а от системы УБП 100 к локальным операторам (222, ФИГ. 2) с генерацией разового идентификатора оказанной услуги в системе 100. В этом случае локальные операторы (222, ФИГ. 2) прописываются в системе 100 с повышенной степенью защиты, а ответственность (согласно правилам МПС) перед пользователем (212, ФИГ. 2) несет мерчант (локальный оператор, оператор оконечного устройства), что может быть осуществлено с использованием системы (средств) PayPass с генерацией разового билета в УБП. Проход по банковской карте к которой нет привязанных в настоящий момент услуг, осуществляется по стоимости разового тарифа локального оператора с генерацией и гашением в УБП одного билета непосредственно в момент оплаты. В общем случае упомянутый разовый идентификатор оказанной услуги является идентификатором транзакции, объединяющей эмиссию разового билета, его оплату и погашение, причем такой идентификатор используется в системе УБП и хранится в ее базе данных. В другом варианте реализации, система 100 хранит данные пользовательского счета (счета пользователя (212, ФИГ. 2)) и предоставляет их процессинговым центрам локальных транспортных, билетных или иных сервисных систем по запросу, а пользователь (212, ФИГ. 2) подтверждает возможность списания средств (например, посредством использования оконечного устройства пользователя 131, в частности, с использованием приложения, установленного на оконечном устройстве пользователя 131).
В частном случае реализации, оконечное устройство пользователя 131 (с использованием программного и аппаратного обеспечения, в частности, модулей, например, с использованием GPRS -модуля и соответствующего программного обеспечения для него) определяет местоположение (в частности, геопозицию) пользователя (212, ФИГ. 2) (в частности, оконечного устройства пользователя 131), и обеспечивает сравнение местоположения (геоданных о местоположении) пользователя (212, ФИГ. 2) с расположением локальной транспортной, билетной или иной сервисной системы или пункта локальной транспортной, билетной или иной сервисной системы, и предлагает (например, в приложении, на веб-сайте и т.д.) оптимальный тариф и информацию об операторе локальных систем в соответствии с (ориентировочным) местоположением пользователя (212, ФИГ. 2).
Каждому пользователю (212, ФИГ. 2) при подключении к Системе 1 00 присваивается внутрисистемный идентификатор (хеш-сумма (от англ. HASH) данных, сгенерированная системой 100 по определенному алгоритму), используемый для идентификации пользователя (212, ФИГ. 2) внутри систем (транспортных, билетных или иных сервисных систем, включая локальные системы и систему 100) без раскрытия его уникального идентификатора пользователя (212, ФИГ. 2), зарегистрированного в системе 100 (банковская карта и/или иной носитель, позволяющий эмитировать платежный функционал банковской карты), либо локальному транспортному, билетному или иному оператору (222, ФИГ. 2) предоставляется для регистрации готовый идентификатор (которым может являться маскированный номер банковской карты или UID банковской карты (номер чипа) или Токен банковской карты), например, используется готовое устройство доступа, защищенное от подделки, например, открытые данные бесконтактной смарт-карты.
В более сложном варианте, уникальный идентификатор пользователя (212, ФИГ. 2) обеспечивает доступ к сервисам УБП, обеспечивающим автоматизированный заказ услуг, их учет и пополнение лимитов услуг, выбор порядка учета услуг, в соответствии с заранее заданными правилами, автоматическое пополнение баланса, продление срока действия билета, в том числе с моментальным рекуррентным платежом и т.д.
После выбора тарифа и транспортной, билетной или иной сервисной системы, производится формирование гарантированных, со стороны пользователя (212, ФИГ. 2) и системы 655 обеспечения технической функциональности билетного процессинга, размера оплаты и объема предоставляемых услуг, соответственно. Транспортных, билетных или иных сервисных систем (систем локальных операторов) в рамках формирования гарантированных условий и набора правил может быть несколько, в частности, в рамках формирования набора правил. Приложение (установленное на оконечном устройстве пользователя 131) может предоставить пользователю (212, ФИГ. 2) возможность «бесшовной» (без совершения дополнительных операций со стороны пользователя) смены транспортных, билетных или иных операторов при поездке по определенному маршруту.
В частном случае, оператором может быть владелец платной автодороги, оператор билетов на развлекательные мероприятия и т.д. Данный подход обеспечивает возможность получить пользователю (212, ФИГ. 2) мультифункциональный носитель информации о доступе к услуге, расширяющий возможности внутреннего туризма и обеспечивает высокую мобильность при конфигурировании заказов на комплексные услуги.
В процессе путешествия, приложение (в частности, мобильное приложение) установленное на оконечном устройстве пользователя 131, отслеживает перемещения пользователя (212, ФИГ. 2) и, в соответствии с геоданными (в частности, местоположением пользователя (212, ФИГ. 2), в частности, оконечного устройства пользователя 131), уведомляет пользователя (212, ФИГ. 2) о доступности выбранного (пользователем (212, ФИГ. 2)) транспортного, билетного или иного сервисного оператора и месте расположения остановки или оконечного устройства оператора 141. В частном случае реализации, выбор оператора может быть произведен (например, пользователем, в частности, в приложении) заранее, но предоплата услуг или задание платежного лимита может производиться «на месте», так, например, в зоне высадки по завершению оказания услуги в случае зонального тарифа, где фактическая стоимость услуги определятся, либо посредством оплаты билета при посещении мероприятия, например, с почасовой или поминутной оплатой.
Перед использованием транспортного, билетного или иного сервисного оператора, уникальный идентификатор пользователя (212, ФИГ. 2) активируется в системе 100. В частном случае, активация уникального идентификатора пользователя осуществляется посредством проверки, например, с использованием технологии 3D secure, банковской карты или токена банковской карты в устройстве поддерживающем NFC в банке эмитенте, для подтверждения, что банковская карта не заблокирована и не украдена. В частном случае, производится занесение центральным сервером (151, ФИГ. 1) уникального идентификатора пользователя и внутрисистемного идентификатора во все оконечные устройства пользователя (пользователей) 131 и оконечные устройства оператора (операторов) 141, которыми в частном случае являются POS терминалы (newpos, verifone и прочие), mPOS терминалы, транспортные валидаторы и прочие АРМ. Стоит отметить, что оконечные устройства оператора работают (взаимодействуют) с (реальной) банковской картой (101, ФИГ. 1), как с носителем уникального идентификатора (Ш)пользователя и услуг доступных пользователю(доступа к услуге), и являются устройствами банка эквайера (610, ФИГ. 6), либо оператора (222, ФИГ. 2) локальной транспортной, билетной или иной сервисной системы, которые подключены к УБП (100, ФИГ. 1).
В частном случае, к уникальному идентификатору пользователя (212, ФИГ. 2) в системе (УБП) 100 привязывается ИНН пользователя (в частности, с использованием интерфейсов УБП) или другой уникальный идентификатор (персональный идентификатор, персональный ключ, персональный код), например, СНИЛС (страховой номер индивидуального лицевого счета), номер телефона пользователя, адрес электронной почты и т.д., позволяющий пользователю получать, фискальные документы (в частности, сформированные с использованием системы фискализации (665, ФИГ. 6)), в частности, инструментов фискализации, и отправляемые центральным сервером 151, а системе (100, ФИГ. 1) отчитываться по предоставленным услугам перед пользователем, например, с созданием документов для отчета перед пользователем (чек, информация о оказанной услуге и т.д.).
При доступе к услугам например транспортного оператора, пользователь (212, ФИГ. 2) использует уникальный идентификатор пользователя и внутрисистемный идентификатор, система предоставляет услуги. Происходит списание «условных единиц» ( единицы тарифного меню локального оператора) и соответствующее уменьшение баланса на сумму единиц (количество), соответствующую предоставленным услугам. В частном случае реализации, списание и оплата может производиться по заранее заданным правилам (в частности, хранящихся в профиле пользователя и тарифном меню в УБП), например, раз в полтора часа, раз в сутки, раз в неделю или месяц. Пользователю (212, ФИГ. 2) может быть предоставлен аванс по услугам, не подтверждаемый немедленной оплатой. Некоторые особенности, например, возможность отложенного безакцептного списания денежных средств или изменения баланса пользователя в УБП, могут существовать в связи с возможностью временного отключения пользователя (212, ФИГ. 2) или терминалов (например, транспортных терминалов и т.д.) от сети передачи данных, т.е. отсутствия постоянной связи с УБП.
В частных случаях реализации, в качестве средства доступа к терминалу, например, транспортному терминалу, может использоваться банковская карта или другая смарт- карта с чипом, бесконтактная смарт-карта, оконечное устройство пользователя 131 с модулем NFC или другим доступом к сетям общего доступа (от англ. Public data network). В частном случае реализации, настройка сети транспортного терминала может производиться заранее и удаленно. Например, может быть настроено соединение no Bluetooth в режиме эмуляции или регистрации в реестре операционной системы оконечного устройства пользователя (131, ФИГ. 1), или настроено соединение с проводной или беспроводной сетью, например, с использованием wi-fi-соединения, транспортной, билетной или иной сервисной системы, к которой подключено оконечное устройство оператора 141, в частности, оконечный терминал системы локального оператора, например, POS -терминал.
В самом простом случае, пользователь (212, ФИГ. 2) выбирает тариф с помощью оконечного устройства пользователя 131, оплата производится в режиме pay-as-you- go, с использованием средств платежной системы, доступной оконечному устройству оператора 141, в частности, оконечному устройству локального оператора, в режиме онлайн или офлайн (автономном режиме).
В более сложном варианте, оконечное устройство пользователя 131 содержит сертифицированную для выбранного оператора защищенную область памяти, в которой хранится информация о ранее оплаченных пользователем, но не исполненных обязательствах локальных операторов (единицах, билетах и т.п.), доступных пользователю (212, ФИГ. 2). В более сложном случае, оконечное устройство пользователя 131 содержит в защищенной области памяти структуры данных, обеспечивающие автоматизированную оплату и пополнение количества сервисных единиц, выбор порядка списания сервисных единиц (транспортных единиц, условных единиц), в соответствии с заранее заданными правилами.
Порядок возврата средств за неоказанные услуги может быть определен системой (УБП) 100 и выбран пользователем (212, ФИГ. 2) из условий, ранее определенных сторонами.
В частном случае реализации, оплата услуг и/или их наборов может производиться наличными денежными средствами в терминалах или в банкоматах с приемом наличных, и их учетом посредством взаимодействия с оконечными устройствами (оконечными устройствами пользователя 131 и/или оконечными устройствами оператора 141), подключенными к Системе 100.
В частном случае реализации, оплата услуг и/или их наборов может производиться наличными в оконечном устройстве локального оператора транспортной, билетной или иной сервисной системы или в банкомате с приемом наличных.
Стоит отметить, что в частном случае описываемая система 100 ведет учет всех операций, совершенных участниками (например, пользователями, локальными операторами, банками и т.д ), как операций покупки, так и валидации (в частности, фиксации факта оказания услуг), данный информационный обмен учитывается в неизменяемых журналах совершенных операций в системе 100 и преобразуется системой 100 в человекопонятный язык, например, в виде реестров и отчетов (в частности, для каждого участника системы свой набор реестров и отчетов), доступных для каждого участника системы 100 посредством инструментов системы, в частности, на основании реестров и отчетов происходит (осуществляется) формирование дебиторских и кредиторских задолженностей между участниками системы (и системой 100), и (соответственно) и финансовых обязательств, расчет между оператором и локальными системами, банком эквайером и банком эмитентом (в частном случае, являющимся пользователем) осуществляется в порядке и на условиях, фиксируемых в открытых офертах системы или в рамках заключенных локальных договоров.
На ФИГ. 2 показан примерный вариант взаимодействия Системы 100 с пользователем (пользователями) 212 и Операторами (локальными операторами) 222 локальных серверов 242 в городах.
Пользователь 212 регистрирует (262) свой уникальный идентификатор пользователя в системе 100 посредством Формы подключения к системе 100 и выбирает набор услуг (Билетов).
Система 100 использует устройство пользователя (поддерживающее внутрисистемный идентификатор пользователя, в частности, идентификатор пользователя в Системе 100), в частности, оконечное устройство пользователя (131, ФИГ. 1), обеспечивающее доступ к центральному серверу (Системы) 151 и зарегистрированное в Системе 100, что позволяет пользователю (212, ФИГ. 2) получить доступ к ранее заказанной через Систему 100 услуге у Оператора локальной системы(оператора локальных систем, оператора локальных серверов) 222.
Центральный сервер (Системы) 151 имеет доступ к серверам локальных (самостоятельных) операторов систем (242, ФИГ. 2), оказывающих продажу и учёт услуг (Билетов) от своего имени или по поручению третьей стороны.
Система 100 присваивает (272) набору услуг, заказанных пользователем 212, внутрисистемный идентификатор и обменивается этими данными с Операторами локальных серверов 222.
Сервера локальных операторов (сервера локальных операторов систем) 242 содержат набор правил доступа к услугам (атрибутам услуг, заданных правилами пользования локальными операторами систем 222) и транслируют (в частности, передают) их в Систему 100 посредством доступных инструментов Системы 100, в частности, по сети Интернет (121, ФИГ. 1). Локальные операторы систем 222- это самостоятельные информационные системы (ИС), например, АСОП, АСКП, РЖД, ЦППК, АЭРОЭКСПРЕСС, АЭРОФЛОТ, ТИКЕТЛЕНД и т д , выступающие технологическим звеном доступа к возможности заказа услуги Пользователем (212, ФИГ. 2), выполняющие функции выпуска локальных билетов, учётной политики выпущенных билетов, они задают и определяют нормы и правила ранее заказанного Пользователем (212, ФИГ. 2) локального билета (Билета, имеющего хождение только внутри системы локального оператора) через Систему 100, условия его хождения (использования)в пределах системы локального оператора.
Стоит отметить, что проверка валидности карты осуществляется штатными методами МПС (3D secure и прочие методы) при регистрации карты в Системе (100, ФИГ. 1). Стоит также отметить, что может осуществляться повторная проверка валидности карты, в частности, при заказе услуги (фактической покупке), в частности, средствами, по крайней мере, одной из платежных систем (545, ФИГ. 5), например, МПС.
Если услуга подключена, то банк эквайер (610, ФИГ. 6), который обслуживает оператора локальной системы (как транспортные, так и прочие билетные), при валидации подключенной к Системе (100, ФИГ. 1) карты спрашивает систему (100, ФИГ. 1) о наличии денег (на счете) или наличии Билета (" - списать деньги или есть билет?"), а Система (100, ФИГ. 1) отвечает о наличии Билета ("-билет есть! - не списывай деньги, а зажги зеленую лампочку и окажи услугу"). Система (100, ФИГ. 1) этот информационный обмен учитывает и ведет расчет с одним из операторов локальных систем (222, ФИГ. 2), в частности, представленным банком эквайером (610, ФИГ. 6), и пользователем (в частности, представленным банком эмитентом (675, ФИГ. 6)·
Если услуга не подключена, то функционирование части описываемой системы 100, или по крайней мере, одной ее части, как описано в рамках настоящего изобретения, функционирует (работает) по pay-as-you-go (плати за то, что использовал (чем воспользовался)), с информационным обменом между банком эквайером (610, ФИГ. 6) и банком эмитентом (675, ФИГ. 6) карты (банк эквайер -> банк эмитент карты), при этом банк эквайер (610, ФИГ. 6) знает какие оконечные устройства локального onepaTopa(POS -терминалы (постерминалы)) принадлежат какой организации и если организация подключена к Системе (100, ФИГ. 1), то эмитент (550, ФИГ. 5) уведомляет Систему (100, ФИГ. 1) о разовом проходе (пользователя 212, например, при переходе через турникет в метро, автобусе и т.д.), т.к. система 100 должна сгенерировать Билет под разовую услугу.
К Системе (100, ФИГ. 1), как банк эквайер (610, ФИГ. 6), так и операторы транспортные (и прочие билетные) подключаются самостоятельно по интерфейсу Системы (100, ФИГ. 1), либо Система (100, ФИГ. 1) подключается к ним по их интерфейсу, если такой есть (возможно осуществление и так и так).
Для информирования пользователя о совершенных операциях (прочей служебной и коммерческой информации) может использоваться его электронная почта, номер телефона оконечного устройства пользователя (131, ФИГ. 1) и/или его личный кабинет в Системе (100, ФИГ. 1), который может быть реализован приложением (программным обеспечением, установленным на оконечном устройстве пользователя (131, ФИГ. 1), например, мобильным приложением для мобильного (вычислительного) устройства пользователя), в частности, установленным на мобильном устройстве пользователя).
На ФИГ. 3 показан примерный вариант связи описываемой системы 100 и локальными операторами (операторами локальных систем, операторами локальных серверов).
Система 100 подключена к Операторам локальных серверов 222, которые могут быть размещены в разных городах и отвечать за разные типы услуг (в том числе транспортные, но не ограничиваясь ими).
Стоит отметить, что локальными операторами (222, ФИГ. 2) могут являться Оператор локального сервера ((620, ФИГ. 6) АСОП, Автоматизированная Система Оплаты Проезда) 343, например, города Москва; Оператор локального сервера (СЭКОП, Система Электронного Контроля Оплаты Проезда) 353, например, города Санкт-Петербург; Оператор локального сервера (АСКП, Автоматизированная Система Контроля Проезда) 363, например, города Ростов; Оператор локального сервера ((620, ФИГ. 6), АСОП) 373, например, города Сочи; Оператор локального сервера ((620, ФИГ. 6), АСОП) 383, например, города Новгород (Великий Новгород); и, в частном случае, модуль системы 313, который может включать Оператора локального сервера 393, например, Крыма. Стоит отметить, что оператором локального сервера 222 может являться (может выступать) модуль 313 системы 100.
В частном случае, в качестве системы локального оператора может выступать специализированный модуль 313 системы (УБП) 100, реализующий, по крайней мере, функционал выпуска, учёта и обращения идентификаторов услуги (в частности, внутрисистемного идентификатора) и соотнесение таких идентификаторов с классификаторами услуг (в частности, функционал ИС локального оператора), а также и с функционалом (ИС локального оператора) взаимодействия с внешними ИС, принадлежащими контрагентам (агентам по продаже билетов или субагентам по оказанию услуг), оказывающим продажу и учёт транспортных, билетных или иных услуг. В случае отсутствия у локального оператора своей ИС, УБП предоставляет ему весь необходимый функционал такой ИС.
На ФИГ. 4 показан примерный вариант взаимодействия описываемой системы (УБП) 100, пользователя 212, организации (кредитной организации) 424, привлеченной оператором локального сервера 222 и инструментов УБП (для интеграции с кредитной организацией) 434.
При выборе пользователем (212, ФИГ. 2), с использованием инструментов системы (УБП) 100, набора услуг к которым будет производиться доступ, система (УБП) 100 готовит (формирует) список правил и запрашивает согласие упомянутого пользователя (в частности, через приложение, установленное на оконечном устройстве пользователя 131) на проверку соответствия заданным правилам, в частности, набора услуг, выбранных пользователем, платежного инструмента пользователя, и, при согласии пользователя (212, ФИГ. 2), проверяет возможность его соответствия правилам.
Выбор пользователем (212, ФИГ. 2) упомянутых правил осуществляется посредством интерфейса системы, причем такие правила формируются самой Системой 100, с учётом правил Локальных операторов систем и на основании доступных пользователю опций (условий), например, элементов тарифного меню, которые выбирает пользователь.
В частном случае реализации, Система 100 заранее собирает данные пользователя (212, ФИГ. 2), в частности, выбранные посредством интерфейсов УБП элементы тарифного меню, и хранит данные (информацию) в базе данных центрального сервера 161 о том, каким правилам пользователь (212, ФИГ. 2) готов следовать . Также, основываясь на ранее собранной Системой информации, могут быть определены локальные системы (и/или их операторы), соответствующие модельным пожеланиям пользователя (212, ФИГ. 2), в частности, основанным на исторических данных о выборе пользователя, в частном случае, являющиеся профилем пользователя. Упомянутые исторические данные формируются Системой 100 на основании клиентского опыта Пользователя (212, ФИГ. 2), в частности, его профиля, в случаях, когда пользователь (212, ФИГ. 2) совершает дополнительные действия (покупки), например, включающие новый выбор пользователя из тарифного меню, с использованием (своего) уникального идентификатора пользователя, Система 100, при согласии упомянутого пользователя (в частности, выраженное с использованием оконечного устройства пользователя 131, например, с использованием установленного на нем приложения или на веб-сайте системы 100 и т.д.), может определять локацию совершения операции и предлагать оптимальные услуги доступные на данный момент в Системе.
Кроме того, Система 100 может на основании анализа исторических данных и профиля пользователя в УБП предлагать наиболее привлекательные комбинации услуг для профиля Пользователя (212, ФИГ. 2) с учетом данных, полученных от Сторонних информационных систем, например, в случае изменения данных пользователя в системах, интегрированных с УБП (например, локальные системы операторов) в профиль пользователя добавляются данные (профиль пользователя обогащается данными).
Далее пользователь (212, ФИГ. 2), следуя правилам взаимодействия с Системой 100, где интерфейсы системы 100 реализуют контроль исполнения правил взаимодействия с ней, и в соответствии с указаниями (в частности, тарифного меню УБП) локальных серверов (242, ФИГ. 2) операторов (222, ФИГ. 2) и пожеланиям пользователя, подтверждает выбор набора услуг. В частном случае, упомянутые правила взаимодействия с системой и правила доступа хранятся на стороне системы. Также, в частном случае, правила доступа отвечают за возможность использования элементов, а правила использования за специфику взаимодействия с той или иной локальной системой или УБП.
Данное действие Пользователя (212, ФИГ. 2) может иметь конклюдентный характер и вызывать цепочку договорных обязательств и поручений, между Пользователем (212, ФИГ. 2), самой Системой 100, Сторонними информационными системами, Операторами локальных систем, организациям выполняющими служебные, организационные и финансово-юридические функции для Системы 100 и ее участников.
После этого, выбранному набору услуг присваивается уникальный идентификатор, являющийся идентификатором услуги, а локальному оператору систем(ы) предоставляется для внутренней регистрации и обработки готовый внутрисистемный идентификатор (пользователя (и услуги)), отличный от уникального идентификатор пользователя, например, используется идентификатор пользователя в Системе 100, защищенный от подделки, например, идентификатор бесконтактной смарт-карты или иного устройства ее эмитирующего.
После выбора пользователем (212, ФИГ. 2) тарифа и локального оператора (в частности с использованием оконечного устройства пользователя 131), производится, в частном случае, в тарифном меню УБП, задание гарантированных, со стороны Системы 100 размера оплаты услуг, а со стороны локального оператора осуществляется задание объема предоставляемых услуг, соответственно, причем объем обязательств и их стоимость, а также их тарификация хранятся в тарифном меню. Операторов локальных систем может быть несколько. Система 100 может предоставить пользователю (212, ФИГ. 2) возможность «бесшовной» смены Операторов локальных систем на условиях заранее заданных Системой 100 внутренних ограничений, причем примерами таких ограничений может являться ограничение в одну поездку (не более одной поездки), сеанса, прохода клиента.
В частном случае, после приобретения пакета услуг (пользователем (212, ФИГ. 2)), неоказанная услуга одного Оператора локальных систем может быть по желанию пользователя (212, ФИГ. 2), если такое определено заранее, преобразована в услугу другого Оператора локальных систем (или в другую услугу того же Оператора локальных систем).
В частном случае, оператором может являться владелец платной автодороги, либо оператор транспортной, билетной или иной сервисной системы или иное предприятие, оказывающее услуги. Перед обращением к локальному оператору системы за услугой, уникальный идентификатор пользователя активируется в Системе 100. В частном случае, производится (осуществляется) занесение уникального идентификатора пользователя и внутрисистемного идентификатора пользователя в заданные(в частности, доступные и/или выбранные пользователем (212, ФИГ. 2)) локальные системы операторов (системы локальных операторов).
В частном случае, к уникальному идентификатору пользователя системой (УБП) 100 привязывается безусловный (общераспространенный) идентификатор пользователя, например, номер телефона пользователя, адрес электронной почты пользователя и т.д., включающий в себя указание на способ передачи данных и позволяющий пользователю (212, ФИГ. 2) получать фискальные документы (в частности, формированные с использованием системы фискализации (665, ФИГ. 6)), а Системе 100 и операторам локальных систем отчитываться по предоставленным пользователю (212, ФИГ. 2) через Систему 100 услугам Данная операция может быть выполнена на этапе обработки Системой 100 Формы подключения Пользователя (212, ФИГ. 2) или иными способами по усмотрению Пользователя (212, ФИГ. 2).
При доступе к услугам операторов локальных систем, пользователь (212, ФИГ. 2) использует идентификатор пользователя в Системе 100, а Система 100 учитывает статус услуг (услуга оказана, не оказана, остаток услуг), оказываемых пользователю (212, ФИГ. 2). Происходит учет (в частности, система 100 осуществляет учет) оказанных услуг и соответствующее снижение (уменьшение) остатка лимита обязательств (услуг, билетов), в соответствии с предоставленными услугами, в частности, осуществляет списание условных единиц (транспортных единиц) со (банковского) счета пользователя (212, ФИГ. 2).
При валидации уникального идентификатора пользователя на устройстве мерчанта (в частности, оконечного устройства локального оператора), например, на POS- терминале (платежном терминале точки продаж) или аналогичных устройствах чтения упомянутого идентификатора, осуществляется проверка наличия БТ через модуль контроля обращения УБП (818, ФИГ. 8) и при наличии привязки такого идентификатора к БТ фиксируется факт оказания услуги. В случае, когда провести проверку привязки идентификатора к БТ в модуле контроля обращения УБП (818, ФИГ. 8) невозможно (например, офлайн (off-line) режим) с идентификатора оконечного устройства локального оператора происходит запрос на резервирование или блокировку денежных средств в размере стоимости услуги, а, при восстановлении канала связи, проверка наличия привязки упомянутого идентификатора к БТ с последующей регистрацией факта оказания услуги соответствующего списания денежных средств (в частности, условных единиц (транспортных единиц) со счета пользователя (212, ФИГ. 2)).
Стоит отметить, что после выбора (454) пользователем 212 доступных в системе 100 опций для подключения услуг (например, конкретный город, оператора локальной системы (сервера), типа услуги и т.д.) и совершения (454) оплаты, система (УБС) 100 привязывает (454) услугу к платежной карте или Токену платежной карты на окончательном устройстве пользователя 131 с использованием собственных средств УБС 100. После того, как пользователь 212 прикладывает (464) уникальный идентификатор (в частности, платежную карту или Токен платежной карты на оконечном устройстве пользователя 131) к оконечному устройству оператора (222, ФИГ. 2), оконечное устройство оператора шлет (474), в частности, передает, авторизационный запрос (запрос на авторизацию) в кредитную организацию 424, в частности, организацию, привлеченную оператором локального сервера (222, ФИГ. 2). Далее кредитная организация 424 маршрутизирует (484) транспортную транзакцию (605, ФИГ. 6), в частности, в систему 100, посредством предоставленных УБС инструментов (инструментов УБС) 434. Далее в УБС 100 осуществляется (494) уменьшение остатка услуги и система 100 возвращает (494) ответ в кредитную организацию 424 с использованием инструментов УБС 434. В общем случае, Система 100 ведет (осуществляет) учет полученных Пользователем (212, ФИГ. 2) ранее заказанных и оплаченных услуг посредством фиксации в Системе 100 факта предъявления упомянутым Пользователем (персонального) идентификатора пользователя в Системе 100.
В частном случае, подтверждением оказания услуги может быть погашение (активация) билета, предоставляющего право на её получение.
В процессе получения услуги, Система 100 фиксирует территориальные предпочтения пользователя (212, ФИГ. 2), в частности, реализованные с использованием географической привязки (геопривзки), и, в соответствии с географией пользования Системой 100, может уведомлять (например, с использованием оконечного устройства пользователя 131, в частности, с использованием установленного на нем приложения) пользователя (212, ФИГ. 2) о доступности выбранного локального оператора системы (оператора локальной системы) и месте расположения точек получения ранее оплаченных услуг (в частности, географическое местоположение оконечных устройств операторов, в частности, локальных операторов). В частном случае реализации, выбор оператора локальной системы и размер приобретаемых услуг может быть произведен (пользователем (212, ФИГ. 2)) заранее (например, с использованием оконечного устройства пользователя 131, в частности, с использованием установленного на нем приложения), но предел оказания услуг может определяться (тарифным меню УБП) в момент окончания их предоставления в соответствии с заданными Системой 100 правилами (в частном случае, тарифным меню).
В частном случае реализации, снижение остатка доступных услуг (в частности, списание средств со счета пользователя (212, ФИГ. 2)) и восстановление их фиксированного лимита может производиться УБП на основании параметров заданных пользователем по заранее заданным правилам, например, раз в полтора часа, раз в сутки, раз в неделю, месяц, три месяца, год или иной интервал заданный пользователем (212, ФИГ. 2) и Системой 100. Пользователю (212, ФИГ. 2) может быть предоставлен доступ к услугам, не подтверждаемый немедленной их оплатой. Некоторые указанные особенности могут существовать в связи с возможностью отключения пользователя (212, ФИГ. 2) или оконечного устройства оператора локальных систем от сети.
В частном случае реализации, настройка сети оконечных устройство оператора локальных систем может производиться заранее и удаленно Системой 100. Например, может быть настроено соединение по Bluetooth в режиме эмуляции или регистрации в реестре операционной системы оконечного устройства пользователя (131, ФИГ. 1), или настроено соединение с сетью wi-fi оператора локальных систем, к которой подключено оконечное устройство оператора локальных систем.
Соответственно, при взаимодействии пользователя (212, ФИГ. 2) с оконечным устройством Оператора локальной системы Система 100 может давать (предъявлять) подсказку (например, на оконечное устройство пользователя 131, в частности, через установленное на нем приложение), относительно использования конкретного идентификатора пользователя и уникального идентификатора пользователя. В случае необходимости, активируется протокол связи от оконечного устройства оператора 141 локальной системы к Системе 100 или активируется платежный функционал идентификатора пользователя.
В самом простом случае, при отсутствии в Системе 100 информации об уникальном идентификаторе пользователя и услуги или внутрисистемном идентификаторе (пользователя) и услуги, пользователь (212, ФИГ. 2) выбирает тариф, установленный Оператором локальной системы и с помощью идентификатора пользователя производится (осуществляется) оплата в режиме pay-as-you-go (например, полной стоимости разовой услуги), с использованием средств платежной системы, доступной локальному Оператору локальной системы в режиме онлайн или офлайн. Для целей учета совершенных операции в данном режиме Оператор локальной системы может передать в Систему 100 (в частности, на центральный сервер 151) данные, необходимые для формирования (в частности, с использованием системы фискализации (665, ФИГ. 6)) отчетных и фискальных документов (650, ФИГ. 6) по оказанной услуге.
На ФИГ. 5 показан примерный вариант билетного процессинга. Пользователь (пассажир) 212 покупает билет городской транспортной системы (конкретный город, конкретный тип билета) и привязывает его (51 1) к своей платежной карте или Токену платежной карты через УБП 100. Пользователь (пассажир) 212 оплачивает проезд с использованием привязанного билета к своей платежной карте или Токену платежной карты (512). Локальный оператор 533 шлет (513) авторизационный запрос (запрос на авторизацию) эквайеру 525 (в частности, в банк эквайер (610, ФИГ. 6). Банк эквайер (610, ФИГ. 6) маршрутизирует (514) билетную транзакцию (в частности, в систему 100) с помощью программного модуля УБП 535, в частности, интегрированного в процессинг банка эквайера (610, ФИГ. 6). В системе (в частности, в УБП (600, ФИГ. 6)) 100 фиксируется (515) уменьшение Баланса Билета. Опционально (альтернативно), например, если Билет не куплен (пользователем 212), истек срок действия (Билета), система УБП ответила отказом, то эквайер 525 связывается (516), по крайней мере, с одной из платежных систем 545 (ФИГ. 5), в частности, с МПС, далее (опционально) платежная система 545, в частности, МПС авторизует (517) банковскую карту у эмитента (эмитента платежной карты пассажира) 550, далее (опционально) средства со счета эмитента 550 через эквайера 525 поступают (518) на расчетный счет банка локального оператора (банка, обслуживающего локального оператора 533) 555 и далее (опционально) средства зачисляются (519) на расчетный счет локального оператора (в частности, перевозчика) 533.
На ФИГ. 6 показана схема взаимодействия основных функциональных участников проведения транзакции в рамках работы УБП, причем состав и последовательность передаваемых данных между которыми определяется в процессе прикладной реализации.
На ФИГ. 7 показан один из примерных вариантов сценариев работы универсального билетного процессинга (УБП), в частности, показан примерный вариант сценария регистрации РАТЧ(банковской) карты и создания Токена в УБП.
Логика регистрации идентификатора Билетного Токена включает:
- регистрацию уникального идентификатора пользователя (PAN (банковских) карт, срока действия (банковской) карты (Expiry date));
- создание учетной записи.
Стоит отметить, что после регистрации уникального идентификатора пользователя в платежную систему Ядро УБП Шпередает запрос на формирование Токена (в частности, Токена МПС). Далее осуществляется проверка валидности PAN (банковской) карты, в частности, с использованием упомянутого алгоритма Луна. Далее банком эмитентом 675 формируется подтверждение валидности (банковской) карты и создается связка Платежного Токена и ключа (Key), являющимся частным случаем процедур, регламентируемых правилами МПС. Далее осуществляется формирование Платежного Токена и передача его, по крайней мере, на одно из описываемых устройств (в частности, на оконечное устройство пользователя 131 и/или оконечное устройство оператора 141), что в частном случае, обеспечивает безопасное функционирование систем, как в рамках МПС, так и в рамках УБП. Далее осуществляется передача уведомления о загрузке Платежного Токена, по крайней мере, в одну из платежных систем 545, в частности, в МПС, и банк эмитент 675. Система 655 содержит базу данных справочников 656 базовых условий, определяющих протоколы взаимодействия. Форматы данных, условия оплаты и прочие условия работы локальных транспортных операторов и возможность их взаимодействия с универсальным билетным процессингом. Для обеспечения взаимодействия с локальными транспортными операторами система 655 содержит шлюзы взаимодействия 660, которые должны обеспечивать устойчивую связь с локальными операторами. Взаимодействие может обеспечиваться, например, по физическим каналам связи, например, по сетям спутниковой связи, или по сетям телефонной связи даже в том случае, если локальный оператор имеет сеть передачи данных с ограничениями взаимодействия со стороны сетей общего пользования Также шлюзы могут обеспечивать поддержку логических защищенных каналов связи, например, с использованием протоколов виртуальных сетей частного доступа ( Virtual Private Network). Клиринговая система 670 и система 665 фискализации обеспечивают, соответственно, возможность взаимозачёта денежных средств и учет движения денежных средств, в соответствии со стандартами финансовой отчетности.
Обращение системы 655 к эмитентам 550 и не эмитентам 630 производится с использованием определенных для них прикладных интерфейсов, например, с использованием прикладного интерфейса 625, соответственно, описание которых может содержаться в справочнике 655 базовых условий.
На ФИГ. 8 показан один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария привязки Билета к внутрисистемному идентификатору(выпуск и загрузка Билетного Токена в оконечное устройство пользователя 131 с NFC).
После того как пользователь 212 зарегистрировал уникальный (персональный) идентификатор (пользователя) в системе 100 и установил платежный Токен, пользователь 212 выбирает доступного поставщика услуг и тип Билета. Далее описываемая система 100 запрашивает у мерчанта (локального оператора транспортных систем) 808 уникальный идентификатор билета. Далее система 100 списывает стоимость Билета со счета пользователя 212. Далее система 100 осуществляет генерацию Билетного Токена для загрузки на оконечное устройство пользователя 131. Далее система 100 регистрирует БТ в реестре, в частности, во внутрисистемном реестре УБП.
Стоит отметить, что модуль контроля обращения УБП 818 может функционировать:
1. В информационном потоке между POS-терминалом и банком Эквайером;
2. В информационном потоке между банком Эквайером и МПС;
3. В информационном потоке между МПС и банком Эмитентом.
В предпочтительном случае реализации изобретения, модуль контроля обращения УБП 818 может функционировать в информационном потоке между банком Эквайером и МПС для определения наличия БТ в системе. В других случаях реализации модуль контроля обращения используется для управления генерацией БТ, перехватывая информационный поток между банком Эквайером и МПС, либо для дополнительной верификации имеющегося БТ, в информационном потоке между МПС и банком Эмитентом.
На ФИГ. 9 показан один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария привязки Билета к идентификатору (выпуск Билетного Токена без его загрузки).
После того как пользователь 212 зарегистрировал уникальный (персональный) идентификатор (пользователя) в системе 100 и согласовал безакцептное списание, пользователь 212 выбирает доступного поставщика услуг и тип Билета. Далее описываемая система 100 запрашивает у мерчанта 808 уникальный идентификатор билета. Далее система 100 списывает стоимость Билета со счета пользователя (карточного счета пользователя, счета карты пользователя). Далее система 100 осуществляет генерацию Билетного Токена для формирования связки с внутрисистемным идентификатором. Далее система 100 регистрирует БТ в реестре.
На ФИГ. 10 показан один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария валидации Билетного Токена.
На ФИГ. 11 показан один из примерных вариантов сценариев работы универсального билетного процессинга, в частности, показан примерный вариант сценария валидации внутрисистемного идентификатора.
Стоит отметить, что доступ пользователя к оборудованию локальных систем, в системе универсального билетного процессинга 100 может осуществляться централизованный сбор и хранение в единой базе данных 161информации (данных), относящейся к условиям перевозок локальных систем локальных операторов 222 (операторов локальных систем, операторов локальных серверов 242), сформированных локальными операторами систем 222, для выбранной пользователем 212, по крайней мере, одной из локальных систем, причем пользователю 212 (в частности, на оконечное устройство пользователя 131) передают обязательный набор правил доступа к оборудованию локальной системы, сохраненной в единой базе данных 161, запрашивает согласие пользователя 212 на соответствие обязательному набору правил и, при согласии пользователя 212, выбирают носитель информации для хранения идентификационного кода пользователя 212, проверяют возможность пользователя 212 соответствовать набору обязательных правил, по крайней мере, одного из локальных операторов 222, причем регистрируют пользователя 212, по крайней мере, в одной из локальных систем и предоставляют пользователю 212 услуги локального оператора с использованием носителя информации по результатам выполнения по крайней мере одного обязательного правила из набора обязательных правил, при этом, для доступа к услугам локального оператора, на оконечном устройстве пользователя 212 формируется кодовая совокупность данных, характеризующая проверенные (верифицированные, достоверные) банковские реквизиты пользователя 2 12, обеспечивающая безусловное проведение платежа между банком эквайрером 610 локальной системы и банком эмитентом 675, соответствующим банковским реквизитам пользователя 212, с одновременной регистрацией банковских реквизитов пользователя 212 в системе локального оператора,
Стоит отметить, что при необходимости доступа к услугам локального оператора, оконечное устройство пользователя 131 передаёт, через устройство бесконтактной передачи данных, идентификационный код и кодовую совокупность данных локальной системе и локальная система запрашивает у банка эквайрера 610 локальной системы подтверждение валидности банковских реквизитов пользователя с переданным идентификатором, и, для пользователя с действительными банковскими реквизитами осуществляется предоставление услуг (локальной системы локального оператора).
Стоит также отметить, что в качестве упомянутого носителя информации может быть использован портативный коммуникатор пользователя 212.
Также, одним из упомянутых (обязательных) правил является оплата услуг (локальной) системы (локального оператора).
Оборудованием локальной системы (в частном случае оконечным устройством оператора 141) является транспорт (локальной) системы (локального оператора), причем оборудованием (локальной) системы является стояночное оборудование (транспортной) системы, например, лифтовый парковочный комплекс.
Стоит отметить, что для предоставления услуг локальной (транспортной, билетной, или иной сервисной) системы может быть использован идентификационный код пользователя локальной системы, сгенерированный в локальной системе, при этом, осуществляется хранение такого идентификационного кода пользователя локальной системы в единой базе данных 161 и локальной транспортной системе предоставляется такой идентификационный код пользователя локальной системы по запросу, содержащему универсальный идентификационный код пользователя, используемый для идентификации пользователя в системе (объединенного билетного процессинга) 100 Стоит также отметить, что для обеспечения доступа пользователя к оборудованию локальной системы может быть использовано беспроводное соединение носителя информации и вычислительных средств локальной системы, используемых при проверке идентификационного кода (пользователя или пользователя локальной системы) и выше указанного правила, а настройка указанного беспроводного соединения может быть осуществлена заранее.
На ФИГ. 12 показан пример компьютерной системы общего назначения, которая включает в себя многоцелевое вычислительное устройство в виде компьютера 20 или сервера, или мобильного (вычислительного) устройства, или модуля описываемой в настоящем изобретении системы, которые, в частном случае, могут являться окончательными (вычислительными) устройствами пользователя или оператора, включающего в себя процессор 21, системную память 22 и системную шину 23, которая связывает различные системные компоненты, включая системную память с процессором 21.
Системная шина 23 может быть любого из различных типов структур шин, включающих шину памяти или контроллер памяти, периферийную шину и локальную шину, использующую любую из множества архитектур шин. Системная память 22включает постоянное запоминающее устройство (ПЗУ) 24 и оперативное запоминающее устройство (ОЗУ) 25. В ПЗУ 24 хранится базовая система ввода/вывода 26 (БИОС), состоящая из основных подпрограмм, которые помогают обмениваться информацией между элементами внутри компьютера 20, например, в момент запуска.
Компьютер 20 также может включать в себя накопитель 27 на жестком диске для чтения с и записи на жесткий диск (не показан), накопитель 28 на магнитных дисках для чтения с или записи на съёмный магнитный диск 29, и накопитель 30 на оптическом диске для чтения с или записи на съёмный оптический диск 31 такой, как компакт-диск, цифровой видео-диск и другие оптические средства. Накопитель 27 на жестком диске, накопитель 28 на магнитных дисках и накопитель 30 на оптических дисках соединены с системной шиной 23 посредством, соответственно, интерфейса 32 накопителя на жестком диске, интерфейса 33 накопителя на магнитных дисках и интерфейса 34 оптического накопителя. Накопители и их соответствующие читаемые компьютером средства обеспечивают энергонезависимое хранение читаемых компьютером инструкций, структур данных, программных модулей и других данных для компьютера 20.
Хотя описанная здесь типичная конфигурация использует жесткий диск, съёмный магнитный диск 29 и съёмный оптический диск 31, специалист примет во внимание, что в типичной операционной среде могут также быть использованы другие типы читаемых компьютером средств, которые могут хранить данные, которые доступны с помощью компьютера, такие как магнитные кассеты, карты флеш -памяти, цифровые видеодиски, картриджи Бернулли, оперативные запоминающие устройства (ОЗУ), постоянные запоминающие устройства (ПЗУ) и т.п.
Различные программные модули, включая операционную систему 35, могут быть сохранены на жёстком диске, магнитном диске 29, оптическом диске 31, ПЗУ 24 или ОЗУ 25. Компьютер 20 включает в себя файловую систему 36, связанную с операционной системой 35 или включенную в нее, одно или более программное приложение (приложения)37, другие программные модули 38 и программные данные 39. Пользователь может вводить команды и информацию в компьютер 20 при помощи устройств ввода, таких как клавиатура 40 и указательное устройство 42. Другие устройства ввода (не показаны) могут включать в себя микрофон, джойстик, геймпад, спутниковую антенну, сканер или любое другое.
Эти и другие устройства ввода соединены с процессором 21 часто посредством интерфейса 46 последовательного порта, который связан с системной шиной, но могут быть соединены посредством других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (УПТТТ) Монитор 47 или другой тип устройства визуального отображения также соединен с системной шиной 23 посредством интерфейса, например, видеоадаптера 48. В дополнение к монитору 47, персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показано), такие как динамики и принтеры.
Компьютер 20 может работать в сетевом окружении посредством логических соединений к одному или нескольким удаленным компьютерам 49. Удаленный компьютер (или компьютеры) 49 может представлять собой другой компьютер, сервер, роутер, сетевой ПК, пиринговое устройство или другой узел единой сети, а также обычно включает в себя большинство или все элементы, описанные выше, в отношении компьютера 20, хотя показано только устройство хранения информации 50. Логические соединения включают в себя локальную (вычислительную) сеть (ЛВС) 51 и глобальную компьютерную сеть (ГКС) 52. Такие сетевые окружения обычно распространены в учреждениях, корпоративных компьютерных сетях, Интернете.
Компьютер 20, используемый в сетевом окружении ЛВС, соединяется с локальной сетью 51 посредством сетевого интерфейса или адаптера 53. Компьютер 20, используемый в сетевом окружении ГКС, обычно использует модем 54 или другие средства для установления связи с глобальной компьютерной сетью 52, такой как Интернет.
Модем 54, который может быть внутренним или внешним, соединен с системной шиной 23 посредством интерфейса 46 последовательного порта. В сетевом окружении программные модули или их части, описанные применительно к компьютеру 20, могут храниться на удаленном устройстве хранения информации. Надо принять во внимание, что показанные сетевые соединения являются типичными, и для установления коммуникационной связи между компьютерами могут быть использованы другие средства.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой. Специалисту в данной области становится понятным, что могут существовать и другие варианты осуществления настоящего изобретения, согласующиеся с сущностью и объемом настоящего изобретения.

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ
1. Способ обеспечения доступа пользователя к услугам локального оператора услуг, заключающийся в том, что:
- в системе универсального билетного процессинга осуществляют
централизованный сбор и хранение в единой базе данных информации, относящейся к условиям предоставления услуг множества локальных систем предоставления услуг, управляемых локальными операторами систем предоставления услуг, где услуги предоставляются по месту нахождения пользователя;
- для локальной системы предоставления услуг, выбранной пользователем из множества локальных систем предоставления услуг, передают пользователю набор правил доступа к услугам локальной системы предоставления услуг, сохраненный в единой базе данных, где набор правил содержит обязательный набор правил;
- запрашивает согласие пользователя на соответствие обязательному набору правил;
- выбирают, по согласованию с пользователем набор дополнительных правил,
- при согласии пользователя, выбирают носитель информации для хранения идентификационных данных пользователя, проверяют возможность пользователя соответствовать обязательному набору правил локального оператора, регистрируют пользователя в локальной системе локального оператора с использованием идентификационных данных пользователя;
- при нахождении пользователя в зоне оказания услуг считывают
идентификационные данные пользователя с выбранного носителя информации, проверяют регистрацию пользователя со считанными идентификационными данными в локальной системе предоставления услуг, и при регистрации пользователя в локальной системе предоставления услуг, по выбору пользователя, предоставляют пользователю услугу в соответствии с дополнительным набором правил и с проверкой соблюдения, по крайней мере одного из правил из набора обязательных правил,
при этом услугой является транспортная услуга.
2. Способ по и. 2, отличающийся тем, что транспортная услуга является многоразовой.
3. Способ по и. 2, отличающийся тем, что транспортной услугой является транспортировка пользователя.
4. Способ по п. 1, отличающийся тем, что транспортной услугой является пропуск на проезд по платной автодороге.
5. Способ по п. 1, отличающийся тем, что транспортной услугой является пропуск на стоянку транспортных средств.
6. Способ по п. 1, отличающийся тем, что идентификационными данными пользователя являются часть реквизитов счета пользователя в банке эмитенте счета пользователя.
7. Способ по п. 4, отличающийся тем, что частью банковских реквизитов счета пользователя являются реквизиты банковской карты, привязанной к счету
пользователя.
8. Способ по п. 4, отличающийся тем, что частью банковских реквизитов счета пользователя является уникальный токен, привязанный к банковской карте, привязанной к счету пользователя.
9. Способ по п. 7, отличающийся тем, что токен системы универсального билетного процессинга является идентификатором, привязанным к банковской карте, привязанной к счету пользователя.
10. Способ по п. 1, отличающийся тем, что выбранным носителем информации является портативное средство хранения данных, выполненное с возможностью бесконтактного считывания данных.
11. Способ по п. 8, отличающийся тем, что портативным средством хранения данных является бесконтактная банковская карта пользователя.
12. Способ по п. 8, отличающийся тем, что портативным средством хранения данных является коммуникатор пользователя.
13. Способ по п. 5, отличающийся тем, что при нахождении пользователя в зоне предоставления услуг, после считывания идентификационных данных пользователя, дополнительно проверяется валидность банковских реквизитов пользователя, а предоставление услуги осуществляется только для пользователя с валидными банковскими реквизитами.
14. Способ по п. 11, отличающийся тем, что валидность банковских реквизитов пользователя проверяется и подтверждается банком эквайрером, обслуживающим локальную систему предоставления услуг.
15. Способ по п. 1, отличающийся тем, что для обеспечения доступа пользователя к оборудованию локальной системы используют беспроводное соединение носителя информации и вычислительных средств локальной системы, используемых при проверке идентификационного кода, а настройку указанного беспроводного соединения осуществляют заранее.
16. Способ по п. 1, отличающийся тем, что пользователь связан с системой универсального билетного процессинга через сеть Интернет с использованием оконечного устройства пользователя посредством привязки банковской карты.
17. Способ по п. 14 или 16, отличающийся тем, что при необходимости доступа к услугам локального оператора, оконечное устройство пользователя передаёт через устройство бесконтактной передачи данных, идентификационный код и кодовую совокупность данных локальной системе, локальная система запрашивает у банка эквайрера локальной системы подтверждение валидности банковских реквизитов пользователя с переданным идентификатором, и, для пользователя с
действительными банковскими реквизитами осуществляется предоставление услуг.
18. Способ по п. 17, отличающийся тем, что проверка валидности банковских реквизитов пользователя осуществляется платежной системой при регистрации банковской карты в системе универсального билетного процессинга.
19. Способ по п. 18, отличающийся тем, что при заказе услуги платежной системой осуществляется повторная проверка валидности банковских реквизитов
пользователя.
20. Способ по п. 6 или 14, отличающийся тем, что если услуга подключена, то банк эквайер, обслуживающий локального оператора, при осуществлении проверки валидности банковских реквизитов пользователя банковской карты пользователя, подключенной к системе универсального сервисного процессинга, отправляет запрос в систему универсального сервисного процессинга о наличии средств на счете пользователя или наличии у пользователя купленного билета для оказания
пользователю услуги и привязанного к счету пользователя, причем при наличии билета система универсального билетного процессинга предоставляет пользователю услугу без списания средств со счета пользователя, где система универсального билетного процессинга осуществляет расчет локальным оператором, банком эквайером и банком эмитентом с учетом такого обмена данными между банком эквайером и системой универсального билетного процессинга.
21. Способ по п. 6 или 14, отличающийся тем, что если услуга не подключена, то осуществляется обмен данными между банком эквайером и банком эмитентом счета пользователя, при этом банку эквайеру известна принадлежность оконечных устройств локальных операторов соответствующим организациям и, если
организация подключена к системе универсального билетного процессинга, то эмитент уведомляет систему универсального билетного процессинга об оказании услуги для осуществления генерации билета под такую услугу.
23. Способ по п. 21 или 22, отличающийся тем, что банк эквайер и локальные операторы подключены к системе универсального билетного процессинга с использованием интерфейса, предоставляемого системой универсального билетного процессинга или, в случае предоставления банком эквайером и локальными операторами собственных интерфейсов, система универсального билетного процессинга подключается к банку эквайеру и локальным операторам по таким предоставляемым интерфейсам.
23. Способ по п. 1, отличающийся тем, что для информационного обмена между участниками системы универсального билетного процессинга используется внутрисистемный идентификатор, отличный от идентификатора банковской карты, являющегося идентификационными данными пользователя в части реквизитов счета пользователя в банке эмитенте счета пользователя, причем внутрисистемным идентификатором является хеш-сумма, вычисленная с использованием
РА банковской карты.
24. Способ по п. 1, отличающийся тем, что для информирования пользователя о совершенных операциях, служебной и коммерческой информации используется электронная почта пользователя, номер мобильного телефона пользователя и/или личный кабинет пользователя в системе универсального билетного процессинга.
25. Способ по п. 16, отличающийся тем, что оконечными устройствами локальных операторов, осуществляющих взаимодействие с банковской картой, привязанной к счету пользователя, являются устройства банка эквайера или устройства локальных операторов, подключенных к системе универсального билетного процессинга.
26. Способ по п. 1, отличающийся тем, что формируется кодовая совокупность данных, характеризующая верифицированные реквизиты счета пользователя, обеспечивающая безусловное проведение платежа между банком эквайрером, локальной системы и банком эмитентом, соответствующим реквизитам счета пользователя, с одновременной регистрацией реквизитов счета пользователя в системе локального оператора.
27. Портативное устройство для обеспечения доступа пользователя к
оборудованию локальных операторов локальных систем, содержащее блок ввода информации, блок вывода информации, средство обработки информации, и средство доступа к центральному серверу, при этом устройство содержит средства
аутентификации пользователя по результатам взаимодействия пользователя со средствами ввода информации, а блок обработки информации выполнен
формирующим отображаемый на средстве вывода информации список локальных систем, с возможностью выбора пользователем локальной системы, при этом портативное устройство выполнено с возможностью получения от центрального сервера обязательного набора правил доступа к оборудованию выбранной
пользователем локальной системы, отображения на средствах отображения информации и получения согласия пользователя на соответствие обязательному набору правил, где правила выбираются из единой базы данных информации, относящейся к условиям перевозок локальных систем, сформированных локальными операторами систем, для выбранной пользователем локальной системы, портативное устройство выполнено с возможностью хранения данных о носителе информации для хранения идентификационного кода пользователя, с обеспечением возможности передачи центральному серверу запроса на регистрацию пользователя в локальной системе и формирования напоминания о том, что предоставление пользователю услуги локального оператора осуществляется с использованием носителя
информации, по результатам выполнения по крайней мере одного обязательного правила из набора обязательных правил.
28. Сервер системы обеспечения доступа пользователя к оборудованию локальных систем, содержащий средства передачи данных средства обработки данных и средства наполнения и хранения единой базы данных информации, относящейся к условиям перевозок локальных систем, сформированных локальными операторами систем, и централизованно собранных с использованием средств сбора данных, при этом сервер выполнен обеспечивающим выборку и передачу, по запросу
пользователя, обязательного набора правил доступа к оборудованию локальной системы, сохраненных в единой базе данных, выбора, соответствующего набору правил, носителя информации для хранения идентификационного кода пользователя, проверки возможности пользователя соответствовать набору обязательных правил локального оператора, регистрации пользователя в локальной системе с
обеспечением предоставления пользователю услуги локального оператора с использованием носителя информации, по результатам выполнения по крайней мере одного обязательного правила из набора обязательных правил.
PCT/RU2019/050130 2018-08-16 2019-08-14 Способ доступа пользователя к услугам локального оператора WO2020036516A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2018129867 2018-08-16
RU2018129867A RU2686618C1 (ru) 2018-08-16 2018-08-16 Способ обеспечения доступа пользователя к услугам локального оператора услуг, оконечное устройство пользователя и сервер системы для реализации способа

Publications (1)

Publication Number Publication Date
WO2020036516A1 true WO2020036516A1 (ru) 2020-02-20

Family

ID=66430319

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2019/050130 WO2020036516A1 (ru) 2018-08-16 2019-08-14 Способ доступа пользователя к услугам локального оператора

Country Status (2)

Country Link
RU (1) RU2686618C1 (ru)
WO (1) WO2020036516A1 (ru)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023003486A1 (ru) * 2021-07-19 2023-01-26 Публичное Акционерное Общество "Сбербанк России" Способ и устройство предоставления данных о пользователе

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EA004994B1 (ru) * 1999-08-27 2004-10-28 Казовский Наум Иосифович Способ предоставления телекоммуникационных услуг и транспортная карта с магнитной полосой, предназначенная для реализации способа
RU2421812C2 (ru) * 2005-05-16 2011-06-20 Мастеркард Интернэшнл Инкорпорейтед Способ и система для использования бесконтактных платежных карт в транспортной системе
US20130246132A1 (en) * 2012-03-17 2013-09-19 David J. Buie Smart tranportation services & payment system and method
US20150178698A1 (en) * 2013-12-23 2015-06-25 Egan Schulz Systems and methods for transportation check-in and payment using beacons

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EA004994B1 (ru) * 1999-08-27 2004-10-28 Казовский Наум Иосифович Способ предоставления телекоммуникационных услуг и транспортная карта с магнитной полосой, предназначенная для реализации способа
RU2421812C2 (ru) * 2005-05-16 2011-06-20 Мастеркард Интернэшнл Инкорпорейтед Способ и система для использования бесконтактных платежных карт в транспортной системе
US20130246132A1 (en) * 2012-03-17 2013-09-19 David J. Buie Smart tranportation services & payment system and method
US20150178698A1 (en) * 2013-12-23 2015-06-25 Egan Schulz Systems and methods for transportation check-in and payment using beacons

Also Published As

Publication number Publication date
RU2686618C1 (ru) 2019-04-29

Similar Documents

Publication Publication Date Title
US20230081174A1 (en) Systems and methods for proxy card and/or wallet redemption card transactions
US20180053157A1 (en) Systems and methods for consumer modifiable payment card transactions
US8584936B2 (en) Techniques for authorization of usage of a payment device
US8387873B2 (en) System and method for mass transit merchant payment
US20170046679A1 (en) Systems and methods for mimicking post-paid user experience with stored-value card accounts
US11475436B2 (en) System and method for providing a security code
US7360691B2 (en) Secure device and mobile terminal which carry out data exchange between card applications
RU2581784C2 (ru) Устройство и способ представления счета и его оплаты
US9390410B2 (en) Automated transaction system and settlement processes
US20130204785A1 (en) Mobile managed service
US10546287B2 (en) Closed system processing connection
US20140101034A1 (en) Methods and systems for prepaid mobile payment staging accounts
US20080091599A1 (en) Stored value card account transfer system
US20050098624A1 (en) Family stored value card program
AU2012352047B2 (en) System and method of using load network to associate product or service with a consumer token
AU2019253898A1 (en) System and method for providing a security code
CA2845580C (en) Systems and methods for proxy card and/or wallet redemption card transactions
WO2011146932A1 (en) Systems and methods for appending supplemental payment data to a transaction message
RU2686618C1 (ru) Способ обеспечения доступа пользователя к услугам локального оператора услуг, оконечное устройство пользователя и сервер системы для реализации способа
WO2007010353A1 (en) A system to enable a user to effect a payment to a third party and a method of operating the system
US20190220848A1 (en) Linked Data Structures
AU2009219114B2 (en) An electronic claims and payment system
WO2013022376A1 (ru) Способ и система проведения объединенной программы лояльности
AKINRINDE The Implementation of Electronic Purse (E-Purse) System in the Banking Sector (A case study of Afribank (Nigeria) PLC)
AU2016201081A1 (en) Secured payment travel reservation system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19849750

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19849750

Country of ref document: EP

Kind code of ref document: A1