WO2021183042A1 - Système et procédé de gestion de données d'utilisateur d'entité - Google Patents

Système et procédé de gestion de données d'utilisateur d'entité Download PDF

Info

Publication number
WO2021183042A1
WO2021183042A1 PCT/SG2020/050137 SG2020050137W WO2021183042A1 WO 2021183042 A1 WO2021183042 A1 WO 2021183042A1 SG 2020050137 W SG2020050137 W SG 2020050137W WO 2021183042 A1 WO2021183042 A1 WO 2021183042A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
account management
user
data
platform
Prior art date
Application number
PCT/SG2020/050137
Other languages
English (en)
Inventor
Edmund Kee Yong NG
Chee Perng YEO
Henry Joseph KWAN
Thi Nhu Y TRAN
Original Assignee
Doxa Holdings International Pte. Ltd.
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 Doxa Holdings International Pte. Ltd. filed Critical Doxa Holdings International Pte. Ltd.
Priority to PCT/SG2020/050137 priority Critical patent/WO2021183042A1/fr
Publication of WO2021183042A1 publication Critical patent/WO2021183042A1/fr

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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • Various embodiments generally relate to systems, methods and computer- readable media, for managing entity user data.
  • an account management platform for connecting an entity user and a new user on the platform comprising: one or more processors; a memory device coupled to the one or more processors; the account management platform stored in the memory device and configured to be executed by the one or more processors, the account management platform comprising instructions for: receiving, by an access module, a request for access to the account management platform; determining, by the access module, whether the request is made by the entity user associated with a first ERP platform or the new user associated with a second ERP platform, wherein the first ERP platform and the second ERP platform are incompatible with each other; sending an invitation to the new user if the access module determines that the request is made by the new user; receiving, by the access module, a request from the new user to access the account management platform; receiving, by the access module, entity profile data including at least an identifying information, determining, by the access module, whether the entity profile data corresponds with an entity profile data criteria, storing the entity profde data in the
  • the step of determining whether the entity profile data corresponds with the entity profile data criteria comprises comparing the entity profile data with the entity profile data stored in the memory of the processors.
  • the hash value is generated via the application of one or more hashing algorithms to the identifying information.
  • the identifying information comprises at least one or more of the following attributes: an entity name, identification number, Unique Entity Number (UEN), street address, telephone number.
  • UPN Unique Entity Number
  • the authentication credential including at least a user id and password for accessing the platform.
  • the entity profile data criteria comprises the identifying information associated with the entity profile registered with a government authority.
  • the step of determining whether the entity profile data corresponds with the entity profile data criteria further includes comparing the identifying information associated with the entity profile data with the identifying information associated with the entity profile registered with a government authority.
  • an account management system for connecting an entity user and a new user on the system, implemented as machine executable instructions stored on a set of at least one non-transitory computer readable medium, each operatively connected to an associated processor, the system comprising: an access module configured for granting access to the system to the entity user associated with a first ERP platform and the new user associated with a second ERP platform, wherein the first ERP platform and the second ERP platform are incompatible with each other; a data integration module configured to receive master data from the access module, the master data being associated with a first entity profile data associated with the entity user or a second entity profile data associated with the new user, wherein the data integration module is configured to translate the master data into a translated data such that the translated data is compatible with the first ERP platform and the second ERP platform; and a digital ledger configured to store the master data into a memory of the processor.
  • the translated data comprises a first translated entity profile data associated with the entity user and a second translated entity profile data associated with the new user.
  • the first entity profile data associated with the entity user comprises identifying information.
  • the second entity profile data associated with the new user comprises identifying information.
  • the identifying information comprises at least one or more of the following attributes: an entity name, identification number, Unique Entity Number (UEN), street address, telephone number.
  • UPN Unique Entity Number
  • the master data stored in the digital ledger comprises a first hash value based on the first entity profile data associated with the entity user and a second hash value based on the second entity profile data associated with the new user.
  • the system further comprises an order to cash module configured to receive payment for fulfilment of an order for an entity user.
  • the translated data facilitates supply chain management transactions between the entity user and the new user.
  • the digital leger is a blockchain.
  • the system further comprises an identity and access management module configured to delegate roles and responsibilities to the entity user and the new user.
  • the master data further comprises any one or more of the following: purchase requisition data, purchase orders, invoices, transaction data.
  • FIG. 1 illustrates a high-level block diagram of a typical system architecture of Enterprise Resource Planning (ERP) Systems
  • FIG. 2 is a block diagram illustrating a high-level system architecture for an account management platform according to various embodiments
  • FIG. 3 is a block diagram illustrating a processing server of the account management platform according to various embodiments
  • FIG. 4 is a flow diagram illustrating an example process for providing access management to the account management platform for the registration and configuration of a new user
  • FIG. 5 is a flow diagram illustrating an example process for inviting a new user to the account management platform through an entity user who wishes to transact with the new user
  • FIG. 6 is a flow diagram illustrating a process for registration of a Purchase Order according to various embodiments.
  • the system and method as described in this description may include a memory which is for example used in the processing carried out in the image processing device.
  • a memory used in the embodiments may be a volatile memory, for example a DRAM (Dynamic Random Access Memory) or a non-volatile memory, for example a PROM (Programmable Read Only Memory), an EPROM (Erasable PROM), EEPROM (Electrically Erasable PROM), or a flash memory, e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • DRAM Dynamic Random Access Memory
  • PROM Programmable Read Only Memory
  • EPROM Erasable PROM
  • EEPROM Electrical Erasable PROM
  • flash memory e.g., a floating gate memory, a charge trapping memory, an MRAM (Magnetoresistive Random Access Memory) or a PCRAM (Phase Change Random Access Memory).
  • Coupled may be understood as electrically coupled or as mechanically coupled, for example attached or fixed, or just in contact without any fixation, and it will be understood that both direct coupling or indirect coupling (in other words: coupling without direct contact) may be provided.
  • module layer, and application are used interchangeably herein.
  • FIG. 1 shows a typical high-level system architecture of current ERP systems used by entities for payment transactions between entities.
  • a company ABC buys goods and/or services from companies 123 and 1011. Companies 123 and 1011 will be recorded and created in company ABC’s ERP system.
  • company 456 also buys from companies ABC, 123, and XYZ.
  • Identify discrepancies and/or duplications refer to one entity (for example, a seller/vendor) having to maintain a different login account provided by another entity (for example, a buyer). Each entity can be utilizing different systems/ERPs to get into each of these systems to respond to the purchased orders sent to it. The seller/vendor will need to synchronize all these disparate transactions across different buyers and/or systems.
  • FIG. 2 illustrates a system 100 for managing entity accounts managed by one or more administrators to a plurality of entities that may provide services for one or more entities and its users.
  • the system 100 includes a processing server 101.
  • the processing server 101 discussed in more detail below, may be configured to operate an account management platform.
  • the account management platform may be a platform designed to provide a plurality of different services to various entities. Such services may include allowing different entities to transact with one another, regardless of different B2B solution providers used by the entities, registration of procurement status for purchase orders, or processing or recording business-to-business (B2B) payments and transactions, or different ERP systems.
  • B2B business-to-business
  • the processing server 101 may be configured to utilize data related to the services provided on the account management platform.
  • the data may be stored locally in the processing server 101 and/or externally, such as in a data warehouse 110.
  • a data warehouse 110 may be an external server, server farm, cloud storage, or other mechanism used for the external storage of data that may be accessed by the processing server or other computer system through a suitable form of communication.
  • the processing server 101 may utilize cloud storage of the data warehouse that is accessed via the internet.
  • the data warehouse may be managed, operated, and/or owned by the same entity that manages, operates, and/or owns the processing server.
  • the data warehouse may be managed, operated and/or owned by a third party.
  • the system 100 may include at least one platform administrator 120.
  • the platform administrator 120 may be an authorized user of the account management platform that is configured to perform administrative functions on the account management platform, including the creation and management of entities, users, and permission, the addition and modification of other data, the creation and management of digital ledgers, etc..
  • the platform administrator 120 may be an employee of the entity that owns and/or operates the processing server 101.
  • the platform administrator 120 may access the account management platform using a suitable computing device, such as a desktop computer, laptop, notebook computer, tablet computer, smartphone, etc.
  • the processing server may have a user interface that is accessible via a computing device, such as a web page, application program, or application programming interface, etc., which may be used to access functions provided by the account management platform.
  • Entity Users 130,140 or a new user 150 may access the account management platform, which will be explained hereinafter.
  • An entity user 130, 140 may be a business, company, individual, etc., which currently use the account management platform to avail itself of one or more services.
  • a new user 150 user may be created in the account management platform at the request of an entity user.
  • an entity user that is already registered on the platform and uses the account management platform may be a supplier of goods or services.
  • the entity user may (for example, directly or through the platform administrator) have the new user 150 or buyer added to the account management platform. For example, this can be done by requesting the platform administrator to send an email to the new user 150 to register itself as an entity user with the account management platform.
  • FIG. 3 shows a block diagram illustrating an embodiment of an account management platform 200 on a processing server.
  • the account management platform 200 includes an access module 205, a data integration layer 201, an Identity and Access Management layer 202 that are configured to receive data from entity users 130, 140 or new users 150-180 over one or more data communications network (not shown).
  • the account management platform may include a data warehousellO which may include one or more databases to store user entity data and transaction data, or other data.
  • the access module 205 allows entity users 130, 140 and new users 150-180 to gain access or to set up their respective accounts in the account management platform 200.
  • the access module 205 may include registration or account setup procedures to create a new account for a new user 150-180 on the account management platform 200.
  • the access module 205 may also include authentication procedures (for example a login ID and a password) to determine the identity of the user or entity and the entity’s profile (for example, the associated organization or company, level of access, etc.) before granting access to the platform.
  • the new user 150-180 has been granted access to the platform, the status of the new user 150 becomes that of an entity user 130, 140 and the new user may configure the account for customized access. For example, if the new user is a supplier, the supplier may create or update the supplier account or provide updated product or service information.
  • the entity user 130, 140 gains access to the account management platform through the access module 205.
  • the access module 205 may include security measures, such as authentication (for example, providing user ID and password), to identify the user by accessing the entity profile data stored in the data warehouse 110.
  • User accounts may also be created through the access module 205.
  • the system administrator may provide access to the entity user via emailing a registration link to the access module 205. Once an account has been created, the entity user may access the account management platform through the access module 205.
  • the account management platform 200 may have a plurality of entity users 130, 140 registered on the account management platform. When a new user 150-180 sets up an account on the account management platform, it will have to provide identifying information which will be stored as an entity profile.
  • the entity profile may be a set of information or data that is unique to a related entity user and/or entity profile.
  • the data elements of the entity profile are called attributes.
  • an entity profile may store the following attributes: a name of an entity, identification number, Unique Entity Number (UEN), street address, telephone number, or a combination of data values that when combined, is unique to the entity.
  • the platform administrator 120 may verify the identifying information of the entity profile.
  • such verification may be done by identifying records associated with the entity, such as incorporation records registered with a governmental jurisdiction and compare such records with proof provided by each entity. Once such information is verified, the platform administrator proceeds to generate a set of authentication credentials such as a username or password to the entity. The services provided by the account management platform may then be accessed by the entity users.
  • the account management platform 200 includes a data integration layer 201 which may be configured to receive data received by the access module 205.
  • the data may include entity profile data or other data from data warehouses, platform administrators, entity users, external entity data sources, data providers, or other systems via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, Internet or the like.
  • the data integration layer may receive electronically transmitted data signals, where data may be superimposed or otherwise encoded on the data signal and decoded, parsed, read or otherwise obtained via receipt of the data signal by the data integration layer.
  • the data integration layer includes extract modules, transform modules and load modules (not shown). The data integration layer performs the extract and transform functions of the ETL (i.e.
  • the extraction process of the data integration layer is preferably initiated by the load module, by the extract module.
  • the data integration layer may initiate the process of calling for retrieval of a master data from an external entity data source.
  • the external entity data source may be from a ERP system of an external entity that is incompatible with the ERP systems of the entity users.
  • the extract, transform and load modules preferably function as integrated ETL tools.
  • the data integration layer ensures that different or incompatible systems will be able to work with the account management platform 200 as the data integration layer ensures that all data transmitted and/or received between any third party system will work with the account management platform 200.
  • the extract modules, transform modules and load modules within the data integration layer provides the translation of master data to ensure interoperability between these incompatible systems and the account management platform.
  • the account management platform 200 may interface with the processing server 100 via a communication network.
  • a central processing unit or processor (not shown) executes instructions contained in the account management platform 200, stored in storage devices (not shown).
  • a processor may provide the central processing unit (CPU) functions of a computing device on one or more integrated circuits.
  • processor broadly refers to and is not limited to single or multi-core general purpose processor, a special purpose processor, a conventional processor, a graphical processing unit, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, one or more Application Specific Integrated Circuits (ASICs), one or more Field Programmable Gate Array (FPGA) circuits, any other type of integrated circuit, a system on a chip (SOC), and/or a state machine.
  • DSP digital signal processor
  • ASICs Application Specific Integrated Circuits
  • FPGA Field Programmable Gate Array
  • entity users and external entity data sources may exchange information via any data communications network, such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, and/or Internet Protocol (IP) network such as the Internet, an Intranet or an extranet.
  • LAN Local Area Network
  • MAN Metropolitan Area Network
  • WAN Wide Area Network
  • IP Internet Protocol
  • Each device, module or component within the system may be connected over a network or may be directly connected.
  • network may be used interchangeably and do not imply a particular network embodiment.
  • any type of network may be used to implement the online or computer networked embodiment of the present invention.
  • the network may be maintained by a server or a combination of servers or the network may be serverless.
  • any type of protocol for example, HTTP, FTP, ICMP, UDP, WAP, SIP, H.323, NDMP, TCP/IP
  • HTTP HyperText Transfer Protocol
  • FTP FTP
  • ICMP UDP
  • WAP Wireless Fidelity
  • SIP Session Initiation Protocol
  • H.323, NDMP TCP/IP
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • the account management platform may be configured to maintain a digital ledger for storage of entity user data.
  • a single digital ledger may be used to store all data associated with the entity user.
  • one digital ledger may be used to store all data for all entities of the account management platform, where the unique identifier for an entity may be used to identify data values associated with that entity.
  • each entity may have a separate digital ledger.
  • the account management platform may be configured to generate data values for user data.
  • the digital ledger used to store entity user data may be a blockchain configured to store the associated data.
  • a blockchain may comprise a plurality of blocks, wherein each block comprises at least a block header and one or more data values.
  • Each block header may include a timestamp as well as a reference value referring to the block header of the previous block added to the blockchain and a reference value referring to the one or more data values included in the respective block.
  • the reference value may be a hash value generated via the application of one or more hashing algorithms to the respective data.
  • the reference value to a previous block header may be a hash value generated via hashing of the block header of the previous block.
  • the blockchain may be immutable, as a change in any data value would result in a change to the has value included in the respective block’s block header, also resulting in a change in the hash value of the subsequent block’s block header, which would carry through the remaining blocks in the blockchain, thus preventing modification to any data values or data in the blockchain.
  • the data values may include entity profiles, purchase requisitions, purchase orders, invoices, transaction data, and other data stored in the ledger as discussed herein.
  • the account management platform includes an Identity and Access Management layer.
  • the Identity and Access Management layer comprises an identity management module (not shown) and an access management module (not shown).
  • the account management platform couples the identity management and access management modules by facilitating delegation of roles and rights, and providing workflow-enabled management of end user entity profiles.
  • the identity management module of the layer manages end user entity user profiles, while the access management module manages access to resources or to various modules within the account management platform.
  • the access management module also provides means for defining and managing authentication and authorization policies for the various modules.
  • the Identity and Access Management layer comprises the aforesaid modules that define the entity profiles and the assets the entity profiles have access to. It is part of a security protocol to define Access Policy and control.
  • the Identity and Access Management layer includes means for providing and managing entity profiles, and means for defining and managing authentication and authorization policies.
  • entity profiles and authentication or authorization information is administered through administrative users. Administrative users are assigned administration rights, thus conferring to them the rights and responsibilities of managing policy and entity profiles for specific modules.
  • the Identity and Access Management layer is shown as a single layer on Fig. 3, in some embodiments, the account management platform may only include an identity management module or an access management module that are separate modules. However, the functions of each of the identity management module and the access management module, if existing as separate modules, are as described above.
  • the account management platform includes various modules for entity users to access the various modules to perform supply chain management functions.
  • the account management platform may include, but is not limited to, a financing module 212, a procure-to-pay module, an order to cash module and a mobile application module.
  • the aforesaid modules facilitate transactions between multiple buyers and suppliers.
  • the financing module 212 provides financing functions for entity users. This allows entity users (for example, suppliers or vendors) to have access to financing resources provided by external partner funders who may or may not be entity users.
  • the entity users may also access a procure-to-pay module 210.
  • the procure-to-pay module 210 provides procurement functions that ensures the traceability and improved productivity by automating some of the time-consuming procurement process and workflow.
  • FIG. 4 is a flow diagram illustrating an example process for providing access management to the account management platform for the registration and configuration of a new user.
  • a new user may receive an invitation via email, on their computing device, to open an account with the account management platform.
  • the new user will be brought to a suitable interface or the access module of the account management platform 200, via the suitable interface over a data communication network.
  • the access module will request for the new user to provide identifying information of its entity.
  • the identifying information provided by the new user is stored as entity profile data and may include name of entity, Unique Entity Number (UEN), entity address, telephone number, contact information, or combination of data values that when combined, is unique to the entity.
  • the access module may also request for proof of identity of the new user, such as proof of entity address.
  • the access module processes the entity profile data provided by the new user and assesses if the entity profile data is unique.
  • the access module may have an entity administrator 120 that processes the entity profile data and determines if the entity profile data is unique. For example, the access module may compare the entity profile with existing entity profile data within the data warehouse or with external entity data sources.
  • the access module accepts the request and proceeds to create an entity user account for the new user at step 550.
  • the access module may generate a set of authentication credentials, such as user name and password, and assign them to the new user.
  • the access module may proceed to inform the new user of the differences and to seek confirmation from the new user on the difference. For example, the access module may identify records associated with the new user, such as incorporation records registered with a government organization and compare such records with proof provided by the entity.
  • the access module proceeds to update the entity profile data with the updated entity profile data at step 536. If the entity profile data is not deemed to be unique, the access module proceeds to reject the new user and to end the process at step 535.
  • the entity profile data associated with the new user may be stored in a database and/or a digital ledger.
  • a digital ledger may be a data file that is configured to store data that may be access by the account management platform (either locally or via data warehouse).
  • the digital ledger may be rewritable, such that data stored in the digital ledger may be modified.
  • data stored in the digital ledger may be immutable, such as data stored in a blockchain ledger.
  • the access module proceeds to send a confirmation email to the new user with the authentication credentials.
  • FIG. 5 is a flow diagram illustrating an example process for inviting a new user to the account management platform through an entity user who wishes to transact with the new user.
  • the process flow is similar to the process as exemplified by the process of FIG. 4.
  • An entity user that is currently a user of the account management platform may wish to transact with a new business partner.
  • the entity user may be a buyer, and wishes to purchase new equipment from a supplier.
  • the entity user may send a connection request, at step 610, to the new business partner through the user interface of the account management platform.
  • the access module will determine if the new business partner is an entity user of the account management platform.
  • the access module request the entity user to provide an email contact address of the new partner, and proceeds to send an invitation email to the new partner to join the account management platform. If the new business partner accepts the invitation and connects with the account management platform, this will kickstart the new user registration process at step 510 as shown in FIG. 4.
  • the access module will process the request by the existing entity user that wishes to transact with the new business partner according to the specific type of supply chain transactions as requested. Once the access module accepts the request, the entity user proceeds to access the various modules within the platform that will seek to connect with the other entity user.
  • the transaction data that is transacted between the first entity user (for example, the buyer) and the second entity user (for example, the supplier) will be updated and stored in the database and a digital ledger.
  • the digital ledger may be the same ledger used to store the entity profile data.
  • the transaction data may be stored directly in the ledger.
  • the platform may generate a hash value of the specific transaction data, which may be stored in the digital ledger in place of the actual transaction data.
  • the hash value may be generated by applying one or more hashing algorithms to the formatted transaction data or data associated therewith, such as the identification number and a timestamp of the approval time of the transaction data.
  • the approved and formatted transaction data may be stored in an immutable format in the digital ledger. This provides auditability of the transaction data by each of the entities, since the hash value is unique and any modification made to the transaction data would result in a different hash value, thereby enabling each entity to prove the transaction as it was approved at the time of the approval.
  • FIG. 6 is a flow diagram illustrating a process for registration of a Purchase Order according to various embodiments.
  • the entity user may be using an Enterprise Resource Planning (ERP) system that is incompatible with the account management platform.
  • ERP Enterprise Resource Planning
  • the account management platform ensures that regardless of the ERP system that the entity user is utilizing, the account management platform will be able to extract the data from an incompatible ERP system and to utilize the data in the the account management platform.
  • ERP Enterprise Resource Planning
  • an entity user may access the account management platform and master data from an external entity data source of the entity user can be extracted by the account management platform when the entity user performs a transaction or request on the account management platform.
  • the master data may be entity profile data such as the following: name of an entity, identification number, Unique Entity Number (UEN), tax code, street address, telephone number, or a combination of data values that when combined, is unique to the entity.
  • entity profile data such as the following: name of an entity, identification number, Unique Entity Number (UEN), tax code, street address, telephone number, or a combination of data values that when combined, is unique to the entity.
  • the master data is usually present and maintained in the entity user’s ERP and/or accounting system.
  • the data integration layer 201 may be configured to receive master data received by the access module 205.
  • the master data may include entity profile data from external entity data sources of the entity user and is received by the access module 205 via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, Internet or the like.
  • the data integration layer includes extract modules, transform modules and load modules (not shown).
  • the data integration layer performs the extract and transform functions of the ETL (i.e. Extract, Transform, Load) process, respectively.
  • the extraction process of the data integration layer is preferably initiated by the load module, by the extract module.
  • the data integration layer may initiate the process of calling for retrieval of master data from the external entity data source of the entity user.
  • the external entity data source may be from an ERP system of an entity user that is incompatible with the ERP systems of other entity users.
  • the extract, transform and load modules preferably function as integrated ETL tools.
  • the data integration layer ensures that different or incompatible systems will be able to work with the account management platform 200 as the data integration layer ensures that all master data transmitted and/or received between any third party system will work with the account management platform 200.
  • the extract module, transform module and load module within the data integration layer translates the master data to the account management platform to ensure interoperability between incompatible systems and the account management platform.
  • the data integration layer 201 ensures that there is no duplicate data entry and no duplicate data created on the account management platform 200.
  • the translated master data is used by the account management platform to raise a purchase requisition request by the entity user at step 430.
  • the procurement module notifies the designated authorizing entity of the requisition to obtain approval or authorization at step 440. If the purchase requisition is denied, the procurement module sends a notification back to the entity user of the decision. If the requisition is approved, the entity user is notified and the purchase requisition is converted into a purchase order at step 460.
  • the purchase order is sent to the entity user at step 460 via the data integration layer at step 470 in the proper format designated by the entity user for sending to the appropriate supplier.
  • the data integration layer ensure that the master data contained in the purchase order continues to be maintained in the system of origin or the external entity data source of the entity user for as long as the entity user uses the external entity data source.
  • Steps 460-480 shows master data being sent back to the external entity data source of the entity user to allow the consistency of data at the external entity data source.
  • Figure 6 depicts the integration between an external entity data source such as an external ERP system that integrates with the account management platform.
  • the master data is maintained in the external entity data source and thus it shows the direction of the integration being from the external entity data source to the account management platform.
  • Steps 460-480 shows that the issuance of Purchase Order being done at the account management platform and the Purchase Order sent back to the external entity data source so that the master data between the two systems are synchronized in order to continue to function properly.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Une plateforme de gestion de comptes destinée à mettre en relation un utilisateur d'entité et un nouvel utilisateur sur la plateforme comprend : un ou plusieurs processeurs ; un dispositif de mémoire couplé au ou aux processeurs ; la plateforme de gestion de comptes stockée dans le dispositif de mémoire et configurée pour être exécutée par le ou les processeurs, la plateforme de gestion de comptes comprenant des instructions permettant la réception, par un module d'accès, d'une demande d'accès à la plateforme de gestion de comptes ; la détermination, par le module d'accès, si la demande est faite par l'utilisateur d'entité associé à une première plateforme ERP ou par le nouvel utilisateur associé à une seconde plateforme ERP, la première plateforme ERP et la seconde plateforme ERP étant incompatibles l'une avec l'autre ; l'envoi d'une invitation au nouvel utilisateur si le module d'accès détermine que la demande est faite par le nouvel utilisateur ; la réception, par le module d'accès, d'une demande provenant du nouvel utilisateur pour accéder à la plateforme de gestion de comptes ; la réception, par le module d'accès, de données de profil d'entité comprenant au moins une information d'identification ; la détermination, par le module d'accès, si les données de profil d'entité correspondent à un critère de données de profil d'entité, le stockage des données de profil d'entité dans le dispositif de mémoire du processeur, chaque profil d'entité comprenant au moins une information d'identification ; la création d'un nouveau compte d'utilisateur d'entité sur la base des données de profil d'entité et l'envoi d'un justificatif d'authentification au nouvel utilisateur d'entité ; la génération, par le serveur de traitement, d'une valeur de hachage pour les données de profil d'entité et ; le stockage, dans la mémoire du serveur de traitement, de la valeur de hachage générée dans un registre numérique.
PCT/SG2020/050137 2020-03-13 2020-03-13 Système et procédé de gestion de données d'utilisateur d'entité WO2021183042A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SG2020/050137 WO2021183042A1 (fr) 2020-03-13 2020-03-13 Système et procédé de gestion de données d'utilisateur d'entité

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2020/050137 WO2021183042A1 (fr) 2020-03-13 2020-03-13 Système et procédé de gestion de données d'utilisateur d'entité

Publications (1)

Publication Number Publication Date
WO2021183042A1 true WO2021183042A1 (fr) 2021-09-16

Family

ID=77670736

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2020/050137 WO2021183042A1 (fr) 2020-03-13 2020-03-13 Système et procédé de gestion de données d'utilisateur d'entité

Country Status (1)

Country Link
WO (1) WO2021183042A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023091364A1 (fr) * 2021-11-16 2023-05-25 Mastercard International Incorporated Procédé et système de planification de ressources d'entreprise

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002005508A2 (fr) * 2000-07-11 2002-01-17 Sap Aktiengesellschaft Procede, appareil et systeme de transactions commerciales en reseau d'egal a egal
US20090055479A1 (en) * 2001-12-21 2009-02-26 Hans Hakan Sjoberg Method of transferring data between different types of computer systems
CN109492375A (zh) * 2018-11-01 2019-03-19 北京京航计算通讯研究所 基于java中间件集成模式的sap erp单点登录系统
WO2019101225A2 (fr) * 2019-02-28 2019-05-31 Alibaba Group Holding Limited Système et procédé de gestion de données basée sur une chaîne de blocs
US20190312869A1 (en) * 2018-04-05 2019-10-10 Accenture Global Solutions Limited Data security and protection system using distributed ledgers to store validated data in a knowledge graph

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002005508A2 (fr) * 2000-07-11 2002-01-17 Sap Aktiengesellschaft Procede, appareil et systeme de transactions commerciales en reseau d'egal a egal
US20090055479A1 (en) * 2001-12-21 2009-02-26 Hans Hakan Sjoberg Method of transferring data between different types of computer systems
US20190312869A1 (en) * 2018-04-05 2019-10-10 Accenture Global Solutions Limited Data security and protection system using distributed ledgers to store validated data in a knowledge graph
CN109492375A (zh) * 2018-11-01 2019-03-19 北京京航计算通讯研究所 基于java中间件集成模式的sap erp单点登录系统
WO2019101225A2 (fr) * 2019-02-28 2019-05-31 Alibaba Group Holding Limited Système et procédé de gestion de données basée sur une chaîne de blocs

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023091364A1 (fr) * 2021-11-16 2023-05-25 Mastercard International Incorporated Procédé et système de planification de ressources d'entreprise

Similar Documents

Publication Publication Date Title
US11593901B2 (en) Systems and methods for using blockchains to record, manage, and transfer ownership rights to land titles
TWI764037B (zh) 跨區塊鏈的交互方法及系統、電腦設備及儲存媒體
US20200242595A1 (en) Systems, methods, and apparatuses utilizing a blended blockchain ledger in a cloud service to address local storage
WO2020134699A1 (fr) Procédé et dispositif de remboursement de facture basés sur une chaîne de blocs et dispositif électronique
AU2016309943A1 (en) A computer implemented method for processing a financial transaction and a system therefor
US20190251556A1 (en) Distributed ledger on-boarding system for standby guarantee resources
US9509678B2 (en) Facilitated information exchange to a service provider for a requested service
US11663593B2 (en) Hierarchy-based blockchain
Kwame et al. V-chain: A blockchain-based car lease platform
CN111902838A (zh) 因特网数据使用控制系统
JP2023015223A (ja) 電子ブロックチェーンに組み込まれる取引の妥当性を確認するシステムと方法
CA3159606A1 (fr) Flux de travail de transactions securisees sur la chaine de blocs
Serban et al. The concept of decentralized and secure electronic marketplace
US20140108616A1 (en) System and method for entitling digital assets
WO2021183042A1 (fr) Système et procédé de gestion de données d'utilisateur d'entité
JP7274198B2 (ja) 資産情報登録方法
US20230179419A1 (en) System and method of tokenization
AU2020202543A1 (en) Unauthenticated access to artifacts in commerce networks
US20210097463A1 (en) Decentralized Resource Management System
CN112837043B (zh) 基于区块链的数据处理方法、装置及电子设备
US11928677B2 (en) Hierarchy-based distributed ledger
Ayed Consolidating fragmented identity: Attributes aggregation to secure information systems
WO2022260688A1 (fr) Système et procédé de traitement de transactions de déclarations de sinistre basé sur des chaînes de blocs
KR20240087430A (ko) 프라이빗 블록체인 환경에서의 부동산 거래 시스템
KR20220133532A (ko) O2o 신원인증 및 전자결제 통합관리 서비스 시스템 및 방법

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: 20924779

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: 20924779

Country of ref document: EP

Kind code of ref document: A1