WO2002075682A2 - Authorisation of online transactions - Google Patents
Authorisation of online transactions Download PDFInfo
- Publication number
- WO2002075682A2 WO2002075682A2 PCT/IE2002/000030 IE0200030W WO02075682A2 WO 2002075682 A2 WO2002075682 A2 WO 2002075682A2 IE 0200030 W IE0200030 W IE 0200030W WO 02075682 A2 WO02075682 A2 WO 02075682A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- transaction
- authorisation
- user
- authority
- authorisation system
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
-
- 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/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
- G06Q20/4037—Remote solvency checks
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
Definitions
- the invention relates to authorisation of online transactions, particularly for customer organisations having multiple personnel who enter transactions.
- WO0057374 describes a system for authorisation for use of credit cards and purchasing at remote locations. It also describes a mechanism for managing credit cards and the requirements and message structures of credit card systems (e.g. NISANET). It relates to the case of single authorisation authorities. EP0745961A also relates to credit cards and allows only a single authorisation authority.
- US5500513A relates to transactions requests coming from point of sale devices.
- US5649116A describes a system which allows authorisations by bank officers. This system is apparently intended for use by banks to manage the cash positions of customers, by combining available funds across groupings of accounts. US5914472A relates to merchant networks and credit card accounts offering only a single authorisation.
- a transaction authorisation system comprising means for authorising a transaction according to stored conditions and for interfacing with a transaction system, wherein
- the authorisation system comprises an authorisation model having a plurality of authority states defining a plurality of required signatories for authorisation of a proposed transaction;
- the system comprises means for allowing online user definition and updating of the model using user client systems
- the system comprises means for receiving a request for a proposed transaction, for determining an applicable authority state, and for authorising the proposed transaction when sufficient signatory approvals have been received to satisfy the authority state.
- at least some authority states comprise a signatory group of signatory nodes, whereby all signatories of the group must approve.
- At least some authority states comprise a signatory set of signatory nodes, whereby any one signatory of the set must approve.
- At least some authority states comprise a complex hierarchical structure of groups and sub-groups, the structure comprising at least three hierarchical levels.
- At least some authority states comprise a hierarchical structure of sets and sub-sets.
- each authority state is associated with a transaction type as defined by conditions .
- system comprises a template update interface comprising means for allowing users to update and define the conditions using a graphical display.
- said interface comprises means for allowing users to define the authority states using a graphical display.
- system comprises means for storing a user-defined template for each association of conditions and authority state, for determining a relevant template for a proposed transaction if parameters of the proposed transaction satisfy the conditions, and for retrieving an authority state associated with the template.
- system comprises means for transmitting a notification to all signatories of a selected authority state, and for dynamically monitoring received responses to determine if the authority state is satisfied.
- system further comprises means for downloading a wizard program via an encrypted connection to a user client system, the wizard program being for guiding a user through a process of defining the control model.
- system comprises an online server for user access, said server comprising:-
- the web channel comprises an account list filter comprising means for building a list of allowable funding accounts associated with a user.
- the web channel further comprises a transaction type filter comprising means for building a list of allowable transaction types associated with a user.
- the channel manager comprises an authorisation data manager comprising means for building look-up tables within objects by querying a rule database.
- the authorisation data manager comprises means for building said objects at the start of a user session and for caching said objects for processing of request by the user.
- the channel manager comprises an authorisation rule engine comprising means for querying the authorisation data manager to check if a proposed transaction meets transaction conditions, and for managing notification of signatures specified in the relevant authority state.
- system further comprises a role manager comprising means for:-
- said permissions comprise "enabled”, “excluded”, and “don't care” flags for a user for an access level.
- the role manager comprises means for combining the permission values with an excluded flag over-riding enabled flags.
- Fig. 1 is a block diagram of an authorisation system of the invention
- Fig. 2 is a diagram of an authority state of the system
- Fig. 3 is a diagram illustrating customer condition editing
- Fig. 4 is a flow diagram illustrating process flow for transaction authorisation.
- Fig. 5 is a more detailed system diagram.
- Fig. 1 user browsers 1 access a transaction control authorisation system 2 via an online transaction execution server 3.
- the users are part of a single corporate customer organisation having many users who are authorised for involvement with transactions executed by the bank on the customers behalf.
- the system 2 is in turn connected to a customer account database system 6 via a transaction server 5.
- the interaction between the browsers 1 and the model 2 is for both customer definition of transaction conditions and also for actual transaction execution.
- the system 2 allows a corporate customer to define the control model 4, and this is used by the bank to control execution of transactions.
- the system 2 thus effectively ties together the customer organisation purchasing policies and the bank's mandate policies in a very effective manner in the one system (2).
- the transaction control model 4 comprises a number (n) of authority states (“AS") 10 and transaction control conditions 11.
- AS 10 defines the customer personnel signatories required for approval of a type of transaction.
- the transaction type is defined by the conditions 11.
- an AS 10 comprises a hierarchical structure comprising a root node 20 and one or both of two types of dependent nodes, namely: groups, and sets.
- a group has in turn at least one dependent signatory, and for authorisation all signatories of the group must authorise i.e. there is a Boolean AND relationship across the signatories of a group.
- a set has a least one dependent signatory only one of whom must authorise i.e. there is a Boolean OR relationship across the signatories.
- Sub-groups and sub-sets are also allowed.
- all of the signatories 24 of the sub-groups 22 and 23 must approve, and only one of the signatories 31 of the set 30 must approve.
- the transaction server 3 executes a template update interface 30 which allows a user to define a set of conditions 11 associated with an authority state 10, and indeed the authority state itself where required.
- the template has a GUI for user definition of conditions 11 and authority states 10 and it links a set of conditions to an AS 10.
- the interface 30 allows users to define :- account limit, transaction type, and funding account conditions 11 in a database 31 in the model 4.
- the system 2 checks the requested transactions parameters against the defined conditions in order to select an AS 10. Once the AS 10 is selected it is used to seek approval.
- a transaction request is received.
- the processor uses parameters of the proposed transaction to execute the conditions (rules) to determine a relevant AS 10. Often the conditions will indicate that a particular user pre-defined AS 10 is applicable. However, in many cases the condition processing indicates that multiple authority states must be combined in a hierarchical structure, such as illustrated in Fig. 2. If no AS exists (decision step 43) there is immediate approval in step 44 and the transaction is submitted in step 45 to the transaction system 5.
- the AS 10 is retrieved in step 48.
- the system 2 then automatically transmits a notification to all signatories in step 49. Over time, responses are received to the notifications (step 50) and the system 2 dynamically monitors the responses to determine if all of the approvals required by the AS have been received. When the AS 10 is satisfied the transaction is approved.
- the user client 1 executes a downloaded authorisation design wizard. This is dynamically downloaded where there has been update to it (server version is later than client version).
- the authorisation system 2, in the online server 3 comprises:
- an authorisation rule engine 70 for real time transaction execution with use of the model 4.
- the system 2 also comprises, in the control model 4, authorisation templates 75 linking authority states 10 with conditions 11.
- an authorisation design wizard (55) is a Java Applet downloaded via an SSL encrypted http connection as part of a user session.
- the user session has previously identified and authenticated the user through the use of digital certificate or an RSA SecurelD, or a bank issued PIN number.
- their user role is checked by the role manager 72 to see if they are entitled to manage the authorisation mechanism for the customer they belong to; if so they are offered the authorisation design wizard 55; if not, they are not.
- the authorisation design wizard 55 is downloaded to the user device 1, where the user may then configure the necessary authorisation rules either from scratch or based on existing templates.
- the rules (described in an XML structure) are transmitted back to the server 3 via an SSL encrypted http connection where they are stored in the model 4.
- the user may define a set of funding accounts for which the authorisation rules are applicable.
- This list of funding accounts is built by the account list filter (61) in the server 3. It is necessary to filter the available accounts to allow bank business rules such as no payments allowed from fixed term deposit accounts to be implemented.
- a transaction condition may define a set of transaction types for which the authorisation rules are applicable. This list of transaction types is built by the transaction list filter (60) in the server 3. It is necessary to filter the available transaction types to allow bank business rules such as no standing order mandates may be submitted to be implemented.
- the filters allow the bank to define mandate processing parameters which then allows the customer to build the model 4 within the confines of how it manages its product set.
- the components 60, 61 and 55 operate exclusively in the definition of the model 4.
- the components 70, 71, and 72 by being located in the channel manager, rather than the web channel of the server 3 allow the authorisation rules, though defined only over the web, to be applied to transaction requests coming from any managed channel such as WAP, ATM, POS, SMS or Web.
- the authorisation conditions 11 for a corporate organisation may be complicated, and though these are readily stored in the database, to allow all processing of these rules to be performed in the database would lead to a bottleneck and potentially low transaction throughput performance.
- the authorisation data manager 71 builds efficient lookup tables within C++ objects through SQL queries on the database. These C++ objects can be built at the start of a user session and cached for all processing of requests by the user.
- the authorisation rule engine 70 on receipt of a transaction request from any managed channel queries the authorisation data manager 71 to see if the request meets the transaction conditions 11 defined previously by the customer.
- the authorisation rule engine 70 notifies all necessary signatories, monitors their response, and on completion submits the transaction to the transaction post program of the back office (5).
- the channel manager part of the server 3 comprises the role manager 72 for controlling user session initial connections in real time according to security criteria. This is both for model definition and for transaction execution interfacing.
- the role manager initially performs user authentication using a mechanism selected according to security requirements. For example the security mechanism may use simple password/username controls, full PKI mechanism, or voice or fingerprint biometrics authentication.
- the role manager 72 has identified the user.
- the role manager 72 determines from a look-up table the values for a number of roles, in this embodiment a user role, a customer role, and a customer type role. It then builds a role object having the various role values as attributes. These attributes comprise permissions in the form of "enabled”, “excluded”, and “don't care” flags for each data/system access level. In combining the permissions the role manager 72 uses an "excluded" permission value to override any number of "enabled” values for the same access level.
- the role manager 72 provides an allowable set of access levels according to security requirements.
- the system 2 allows banks the facility to enable their customers define and manage in an automated manner the authorisations required for the processing of transactions. To ensure the benefit is actually realised by the bank, customer concerns and fears of technology are overcome by providing a user intuitive graphical interface, as described below.
- a customer is a beneficiary owner of a set of accounts on a bank's back office system 5, 6.
- the users are individuals tied to a customer who are allowed to operate a subset of the customer's accounts.
- Each user is assigned a role that defines his/her rights and access levels to the subset of accounts.
- a user with an authorisation administration role is allowed to define the authorisation requirements for transaction requests submitted by other users of that customer.
- a system channel manager manages the following channels
- authorisation rules by setting values for the authorisation rule components itemised in the model.
- a transaction condition is created consisting of • An amount in a specified currency • A set of transaction request types • A set of accounts
- This tri-part configuration of a transaction condition allows the administrator to target transactions of a certain value (such as all large transactions), or of a certain type (all overseas remittances) or for transactions from a set of accounts (day to day expenditure). These combinations allow the customer to create a fine-grained authorisation model that suits their exact business needs.
- An authority state allows user signatory requirements to be defined by functional department or by rank, and allows complex hierarchies to be built.
- the definition of authority sets allows a quorum from specified groups to be used to satisfy an authorisation state.
- the definition of an authority state through the use of groups and sets allows complex hierarchical definitions to be defined that model how authorisation of transactions works in the real world.
- the requisite number of signatures are collected and stored on the channel database. Thus, a full and complete audit trail of all signatures to the transaction are kept.
- the authorisation design wizard is a Java Applet that is run within the browser on the client side, which allows the end-user through the familiar Microsoft WindowsTM Standard style interface to easily devise corporate authorisation rules.
- the wizard's interface presents three panels.
- a leftmost panel extends the length of the applet and allows the user to navigate through the authorisation concepts of
- Another panel displays a visual representation of an authorisation schema.
- Another panel displays a Boolean logic representation of the authorisation schema.
- Signatory groups are created by navigating to a signatory section of the authorisation wizard, and selecting from a context menu "Create New Signatory Group”. Signatory groups may be renamed by editing in place in the navigation pane. A signatory group edit dialogue is displayed. This allows the definition of the group (assigned signatories) in terms of other groups (available signatories).
- signatory sets are OR relationships between signatories and signatory groups.
- the OR nature of this relationship allows the construction of quorums, where some pre-defined number of a group may make a binding decision for the group.
- Signatory sets are created by navigating to an authorisation states section of the authorisation wizard, and by selecting from the context menu "Create New Signatory Set”. Signatory sets may be renamed by editing in place in the navigation panel. A signatory set edit dialogue appears. This allows the definition of a quorum within a group and of the addition of signatories and groups of signatories.
- An authorisation state is an "AND" relationship between signatory groups and signatory sets that defines the full complement of signatories required for the processing of requests.
- An authority state is created by navigating to the authority state section and selecting from the context menu "Create Authority State” Authority states may be renamed by editing in place in the navigation panel.
- the authority state is constructed by adding members from authority groups and from authority sets into the state rule (bottom list).
- Transaction conditions are template rules, defining what type of requests require authorisation before the request is processed. Transaction conditions are defined in terms of the main characteristics of a request, which are its funding account, its type and its amount. Transaction conditions are created by navigating to a transaction conditions section of the navigational panel and selecting from the context menu "Create New Transaction Conditions". Transaction conditions may be renamed by editing in place in the navigational panel. A transaction condition edit dialog appears. This allows the selection of multiple funding accounts (from account), selection of multiple request types (transaction type) and the definition of the amount and the current the amount is expressed in.
- a context menu is presented to the user in response to events in a navigational panel.
- a mouse right button click causes the presentation of the context menu.
- the menu allows the deletion, creation and renaming of the selected item. It also offers a set of options to allow the creation of new items. Only the allowed items are shown, the others are disabled (indicated by the greying out of the menu items).
- the system 2 defines an authorisation template and can decide what parameters to leave blank. In one example, only a single parameter, signatory, is left blank. The customer can then select the template by navigating to an authorisation template section of the authorisation wizard, and by selecting the desired template are prompted for the blank parameters; in this case the identity of the required signatory.
- ClientsRus is a large corporate whose auditors have raised concerns about their purchase order mechanism; their auditors main concerns was that although a PO system was in place it was more often ignored, and that ClientsRus had no mechanism in place that allowed the system to be enforced.
- Alice on login to the web interface is presented with a Java design tool that allows her to create the PO rules as directed by the auditors.
- the rules created by Alice are
- Harriet logs in before Fiona and authorises the payment and sends a mail message to Dave, reminding him how important this colour printer is for the company and asking him to expedite the matter. Dave then digitally signs the transaction.
- Fiona logs in the pending transaction notification has been removed, as once Harriet signed the transaction, rule 1 was satisfied.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Economics (AREA)
- Data Mining & Analysis (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Development Economics (AREA)
- Technology Law (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP02705030A EP1388136A1 (en) | 2001-03-16 | 2002-03-15 | Authorisation of online transactions |
US10/661,619 US20050102243A1 (en) | 2001-03-16 | 2003-09-15 | Authorisation of online transactions |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP01650028.2 | 2001-03-16 | ||
EP01650028 | 2001-03-16 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/661,619 Continuation US20050102243A1 (en) | 2001-03-16 | 2003-09-15 | Authorisation of online transactions |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2002075682A2 true WO2002075682A2 (en) | 2002-09-26 |
Family
ID=8183587
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/IE2002/000030 WO2002075682A2 (en) | 2001-03-16 | 2002-03-15 | Authorisation of online transactions |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1388136A1 (en) |
IE (1) | IE20020191A1 (en) |
WO (1) | WO2002075682A2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8666870B2 (en) | 2005-03-08 | 2014-03-04 | Jda Software Group, Inc. | Configurable state model for supply chain management |
WO2014207615A1 (en) * | 2013-06-26 | 2014-12-31 | Visa Cape Town (Pty) Ltd | Financial account with group authorization |
US10115161B2 (en) | 2005-03-08 | 2018-10-30 | Jda Software Group, Inc. | Configurable state model for supply chain management |
-
2002
- 2002-03-15 WO PCT/IE2002/000030 patent/WO2002075682A2/en not_active Application Discontinuation
- 2002-03-15 IE IE20020191A patent/IE20020191A1/en not_active IP Right Cessation
- 2002-03-15 EP EP02705030A patent/EP1388136A1/en not_active Withdrawn
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8666870B2 (en) | 2005-03-08 | 2014-03-04 | Jda Software Group, Inc. | Configurable state model for supply chain management |
US10115161B2 (en) | 2005-03-08 | 2018-10-30 | Jda Software Group, Inc. | Configurable state model for supply chain management |
WO2014207615A1 (en) * | 2013-06-26 | 2014-12-31 | Visa Cape Town (Pty) Ltd | Financial account with group authorization |
Also Published As
Publication number | Publication date |
---|---|
IE20020191A1 (en) | 2002-10-02 |
EP1388136A1 (en) | 2004-02-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8447680B2 (en) | Business transaction facilitation system | |
US7413112B2 (en) | Method and system for manual authorization | |
US20130161384A1 (en) | Information management system and method for a plurality of interfaced card processors | |
US20060020530A1 (en) | Systems for providing financial services | |
US20120116933A1 (en) | System and method for automatic reconciliation of transaction account spend | |
US20050102243A1 (en) | Authorisation of online transactions | |
US20170286965A1 (en) | System and method for tracking and securing the purchase and sale of controlled substance | |
US11410211B1 (en) | Electronic processing of invoices using assigned users and supplier groups | |
US20230298036A1 (en) | Intelligent recommendations for dynamic policies used in real-time transactions | |
US11966965B1 (en) | Flexible and integrated electronic processing of different invoice categories | |
US11200548B2 (en) | Graphical user interface and operator console management system for distributed terminal network | |
US11636531B1 (en) | Electronic processing of invoices with no purchase orders | |
US20060293960A1 (en) | Interoperable account junctions and omnicompetent value trusts | |
US11470073B2 (en) | Method and apparatus with provider information access authorization | |
WO2002075682A2 (en) | Authorisation of online transactions | |
US11301918B1 (en) | Invoicing portal with easy search and easy user communication | |
US20090204526A1 (en) | Method and system for utilizing a flexible case model for collections | |
US11971811B2 (en) | Auto-decisioning test interface and test database for bypassing functionalities of decision engines and simulating return values | |
US20200211012A1 (en) | Electronic framework and networked system for variable class designations and policies | |
US8341043B2 (en) | Dynamic prepayment risk management | |
Nasution et al. | RAMRSP AIRLINE TICKET SALES SYSTEM DESIGN | |
US20070043835A1 (en) | State-based workpath system and method | |
KR20010000189A (en) | System and method for managing a plurality of accounts of internet sites by using integrated circuit card | |
US20150317738A1 (en) | Computerized method and system for secure communication, and method and system for matching customers with options for investment | |
JP2007094984A (en) | Payment method using electronic money and electronic wallet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 10661619 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2002705030 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWP | Wipo information: published in national office |
Ref document number: 2002705030 Country of ref document: EP |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 2002705030 Country of ref document: EP |
|
NENP | Non-entry into the national phase in: |
Ref country code: JP |
|
WWW | Wipo information: withdrawn in national office |
Country of ref document: JP |