United States Patent [19]
`Langhans et al.
`
`[54] AUTOMATED PURCHASING CONTROL
`SYSTEM
`
`[75]
`
`Inventors: Stephen Langhans, San Francisco;
`Laurence M. Goodman, Foster City;
`Sigman L. Shapiro, Alamo, all of
`Calif.
`
`[73] Assignee: Visa International, Foster City, Calif.
`
`[ * ] Notice:
`
`The term of this patent shall not extend
`beyond the expiration date of Pat. No.
`5,500,513.
`
`[21] Appl. No.: 597,050
`
`[22] Filed:
`
`Feb. 5,1996
`
`Related U.S. Application Data
`
`[63] Continuation of Ser. No. 241,106, May 11, 1994, Pat. No.
`5,500,513.
`[51] Int. CI.6
`[52] U.S. CI
`[58] Field of Search
`
`G06K 5/00
`235/380; 395/238
`235/380; 340/825.33;
`364/408
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`iiiiiiiin
`
`US005621201A
`[ii] Patent Number:
`[45] Date of Patent:
`
`5,621,201
`*Apr. 15,1997
`
`4,812,628 3/1989 Boston et al
`4,891,503 1/1990 Jewell
`5,177,342 1/1993 Adams
`
`235/380
`340/825.33
`340/825.33
`
`FOREIGN PATENT DOCUMENTS
`
`2118341 10/1983 United Kingdom
`
`235/380
`
`Primary Examiner—Donald T. Hajec
`Assistant Examiner—Jeffrey R. Filipek
`Attorney, Agent, or Firm—Townsend and Townsend and
`Crew LLP
`
`[57]
`
`ABSTRACT
`
`An automated purchasing control system which can be
`customized for a corporate customer. The system receives an
`authorization request over the phone lines from a remote
`point-of-sale terminal and processes the request using
`unique software. The software has a database customized to
`a corporate user to establish that company hierarchial struc(cid:173)
`ture. Elements of the hierarchial structure are independently
`reconfigurable, so that a company can specify different
`hierarchial relationships in the software for authorization,
`billing and reporting purposes. Different authorization tests
`can be established for each position in a hierarchy, with a
`particular position being required to pass not only its own
`test, but the test of elements higher in the hierarchial tree.
`
`4,727,243 2/1988 Savar
`
`235/379
`
`14 Claims, 9 Drawing Sheets
`
`TERMINAL
`
`TERMINAL
`
`SERVICE
`TERMINAL
`
`r94
`ATM
`
`r
`ATM
`
`Patent Owner, Ex. 2004, p. 1
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 1 of 9
`
`5,621,201
`
`PURCHASING
`
`ACCOUNTING
`
`PREPARES &
`PROCESSES
`
`RFQ r
`QUOTE
`ANALYSIS
`VENDOR
`SELECTED
`
`RECEIVES
`COPY OF P.O.
`
`P.O. PLACED
`H C O P I ES TO END
`USER i ACCTG
`
`RECEIVES PO.
`
`RECEIVES
`COPY OF P.O.
`
`RECEIVES
`ACKNOW(cid:173)
`LEDGEMENT
`
`ACKNOWLEDGES
`PO-
`
`SHIPS
`MATERIAL
`1
`SENDS
`INVOICE
`
`RECE
`VES
`PAYMENT
`
`CLOSES
`QRPEfi
`
`F/a /
`
`RECEIVES
`INVOICE
`
`I
`
`RECEIVES COPY
`OF RECEIVAL
`
`I
`
`MATCH INV. WITH
`H-
`PO. I RECEIVAL
`8'
`_ H
`PAYS INVOICE
`I
`
`CLOSES
`FILE
`
`SUBJECT
`TO AUDIT
`
`10
`
`ERROR
`
`ERROR
`U
`RECEIVES
`MATERIAL
`
`SENDS COPY
`OF RECEIVAL
`TO
`PURCHASING
`AND
`ACCOUNTING
`J
`CLOSES
`REQUISITION
`I
`
`SUBJECT
`TO AUDIT
`
`10
`
`RECEIVES COPY
`OF RECEIVAL
`I
`CLOSES OPEN
`ORDER
`I
`SUBJECT
`TO AUDIT
`
`10
`
`PR/OR ART
`
`Patent Owner, Ex. 2004, p. 2
`
`

`

`U . S.
`
`P a t e nt
`
`Apr. IS, 1997
`
`Sheet 2 of 9
`
`5,621,201
`
`«M
`§
`
`»—
`
`8
`
`CO
`
`So
`
`•K
`
`ACCOUNT 8
`ARDHOLDER
`
`• ci
`UJ
`—1 C
`
`ACCOUNT 7
`ARDHOLDER
`
`UJ
`—J C
`
`_J
`
`ACCOUNT 6
`ARDHOLDER
`
`UJ
`UJ
`—I C
`
`ACCOUNT 5
`CARDHOLDER
`
`UJ
`
`UJ
`
`ACCOUNT 4
`ARDHOLDER
`
`UJ 5 C
`
`ACCOUNT 3
`ARDHOLDER
`
`UJ
`UJ
`_J C
`
`ACCOUNT 2
`ARDHOLDER
`
`UJ
`—1 C
`
`ACCOUNT 1
`ARDHOLDER
`
`—1
`
`—1 C
`
`*
`CO
`
`to
`
`•
`CM
`1
`UJ
`UJ
`—1
`
`eo
`
`UJ
`
`M 1 >
`UJ
`—1
`
`UJ
`
`1
`
`1
`UJ >
`UJ
`1
`
`1—
`UJ
`
`s
`
`UJ
`
`1
`UJ
`UJ
`1
`
`>•
`
`>-1
`
`<=>
`C3
`
`eo
`1
`
`—1
`>
`UJ
`-J
`
`CM
`
`i
`
`1—
`
`UJ
`
`0
`CO
`
`C<J
`—j
`
`UJ >
`UJ
`—1
`
`•fc
`
`oo
`1
`
`UJ
`1—
`
`UJ
`
`UJ
`—1
`
`Patent Owner, Ex. 2004, p. 3
`
`

`

`U.S. Patent
`
`Apr. 15,1997
`
`Sheet 3 of 9
`
`5,621,201
`
`<_3
`OS
`ac
`UJ
`
`to
`
`o
`LU
`a:
`
`8
`
`m
`
`ACCOUNT 7
`CARDHOLDER
`
`LU
`LU
`1
`
`Patent Owner, Ex. 2004, p. 4
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 4 of 9
`
`5,621,201
`
`V
`§
`
`OS
`CZ>
`
`0> UJ oo
`
`CT5
`
`cn
`i
`LU
`
`IS
`<-2
`
`CO
`
`S3«l
`
`OUNT
`3H0LD
`
`LU
`
`LU
`1
`
`oo
`
`1
`
`LU
`
`7?r
`
`oo
`i
`
`I
`
`a.
`LU
`
`Csj
`
`cn
`2
`
`as
`«£
`Q_
`
`«_
`- * LU
`> LU
`-J
`
`Patent Owner, Ex. 2004, p. 5
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 5 of 9
`
`5,621,201
`
`JO
`
`r 12
`
`ACCOUNT NO.
`
`AUTH. LEVEL 8
`
`r 14
`BILLING
`LEVEL 8
`
`,16
`REPORTING
`LEVEL 8
`
`,18
`
`TEST NO.
`
`.20
`
`,22
`
`^24
`
`PARAMETERS
`FIG. 5.
`
`TEST NO.
`
`PARAMETERS
`
`•26
`
`LEVEL 3
`GROUP
`
`x. 28
`AUTH.
`LEVEL 2
`
`r 30
`
`BILLING
`LEVEL 2
`
`^ 34
`
`,36
`
`-38
`
`TEST NO.
`
`PARAMETERS
`
`TEST NO.
`
`.42
`LEVEL 9
`ACCT. I AUTH.
`
`.44
`.46
`LEVEL 9
`LEVEL 9
`ACCT. I BILL
`ACCT I REPORT
`FIG. £
`
`32
`REPORTING
`LEVEL 2
`JL 40
`
`PARAMETERS
`-JL
`LEVEL 9
`ACCT 2 AUTH.
`
`56
`
`58
`zL
`ACCOUNT #
`
`^
`BIN #
`
`60
`
`SERVICE
`-
`CODE
`
`52-
`
`&
`CVV
`
`^ 50
`
`l54
`CARD NUMBER
`
`FIG 7.
`
`Patent Owner, Ex. 2004, p. 6
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 6 of 9
`
`5,621,201
`
`\
`\
`
`ssl
`
`•—CD
`
`or
`:cott:
`C3
`
`"l
`/
`
`oo
`
`oo
`en
`
`CO
`
`CO
`<=>
`o_
`
`^6
`
`Oi
`
`"-
`
`\
`^
`
`^
`^
`
`/
`f
`
`t—
`
`t—
`
`CO
`
`to
`a.
`Q-
`
`on
`\
`
`i
`•*c
`^^ ac
`
`UJ
`•—
`
`CVJ
`oo
`
`—1
`<c
`^^
`2E
`OS
`LU
`1—
`
`o*
`
`^
`
`Patent Owner, Ex. 2004, p. 7
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 7 of 9
`
`5,621,201
`
`( S T A RT
`
`}
`
`DETERMINE BIN,
`ACCOUNT NUMBER FROM
`AUTH. REQ
`
`•110
`
`112
`
`LOOK UP DATABASE
`ENTRY FOR ACCT. NO.
`(LEVEL GRP)
`
`z 118
`GO TO
`TEST
`
`L 116
`
`LOAD
`PARAMETERS
`
`^120
`
`STORE TEST
`RESULTS
`
`COMPARE TEST RESULTS
`TO AUTH. RESPONSE
`
`•128
`
`TRANSMIT
`AUTH. MESS.
`
`(
`
`E ND
`
`)
`
`FIG, 3
`
`Patent Owner, Ex. 2004, p. 8
`
`

`

`U.S. Patent
`
`Apr. 15, 1997
`
`Sheet 8 of 9
`
`5,621,201
`
`DECLINE
`
`)
`
`Fia IO.
`
`Patent Owner, Ex. 2004, p. 9
`
`

`

`U.S. Patent
`US. Patent
`
`Apr. 15, 1997
`Apr. 15,1997
`
`Sheet 9 of 9
`Sheet 9 of 9
`
`5,621,201
`5,621,201
`
`AUTHORIZATION
`REQUEST
`
`I50
`
`
`
`
`ACCOUNT
`BLOCKED?
`
`
`
`I62
`
`
`
`
`
`CASH
`ADVANCE LINIT
`
`
`EXCEEDEO?
`
`YES
`
` NO
`
`
`VELOCITY
`CHECII:PASS
`YES
`CARDHOLDER
`
`
`
`OTB AVAILABL
`
`
`
`
`I52
`
`I
`
`YES
`
`154
`
`no
`
`'56
`
`DECLINE
`
`‘ I64
`
`
`
`no
`
`YES
`
`'66
`CAROHOLDER
`ovmumr 0TB
`AVAIL?
`
`
`no
`
`I68
`
`NCC
`IN MCCC FOB
`OVERLINIT?
`
`
`
`ITO
`
`REFER
`
`
`
` CONTINUE
`
`
`'
`BENNNTEANN
`
`
`
`
`
`
`no
`
`
`
`
`APPROVE
`
`YES
`
`DECLINE
`
`"0
`
`DECLINE
`
`N0
`
`
`
`
`NCCC
`
`
`NO- STOP
`OVERLINIT OTB
`
`
`ON NCC?
`AVAIL?
`
`
`
`NO
`
`
`
`DECLINE
`
`
`
`YES
`
`COMPANY
`OTB AVAILABLE"
`
`
`
`YES
`
`APPROVE
`
`FIG. //.
`F162 //.
`
`Patent Owner, Ex. 2004, p. 10
`
`Patent Owner, Ex. 2004, p. 10
`
`

`

`5,621,201
`
`AUTOMATED PURCHASING CONTROL
`SYSTEM
`
`This is a Continuation, of application Ser. No. 08/241,
`106 filed May 11, 1994, now U.S. Pat. No. 5,500,513.
`
`5
`
`BACKGROUND OF THE INVENTION
`
`The present invention relates to computer systems for
`automatic control of purchasing, in particular using credit 10
`cards.
`The typical purchasing system at a large company (e.g., a
`corporation) can be very complex, with the involvement of
`a number of employees at different points in the process, and
`the generation of a large amount of paper. FIG. 1 is a process is
`flow chart illustrating the steps required from start to finish
`for a typical corporate purchase order. The approval process
`in a typical company involves a number of corporate con(cid:173)
`trols. A particular purchase for materials or services must be
`approved for that particular department and also meet bud- 20
`getary restraints for the particular department. These needs
`may vary from project to project. In addition, the company
`may have certain approved vendors which are required to be
`used for certain purchases.
`A purchasing card for government functions has been 25
`developed by Rocky Mountain BankCard. The card, which
`is used like a credit card, can be used to charge purchases.
`The card user is assigned a card number identifying where
`in the government hierarchy that employee falls. A budget
`limit for a department can be applied through the hierarchy 30
`to an individual purchase authorization request by the card(cid:173)
`holder. The hierarchial system for the Rocky Mountain
`BankCard which allows different budgetary limits by depart(cid:173)
`ment can also be used for the billing and reporting purposes.
`Thus, the government can limit spending by cardholders and 35
`receive reports and billings which match the agency's
`departmental structure.
`Another system similar to the Rocky Mountain BankCard
`system has also been used by Pro Card. Both these systems
`also incorporate a merchant blocking feature, which prohib- ^
`its purchases from certain types of merchants. When a card
`is used, the merchant uses a point-of-sale device to transmit
`the card number to a central bank for authorization. In
`addition to the card number, a merchant code (i.e., SIC code)
`identifying the merchant category is transmitted. The mer- 45
`chant code will identify the type of merchant involved. Thus,
`for example, it would be possible for the purchasing card
`holder to be allowed to purchase airline tickets, but not
`jewelry.
`Usage monitoring to detect fraud or fraud patterns is 50
`desirable from a bank's perspective. Banks incorporate
`features in administering a credit card system which allows
`them to monitor usage. For example, banks can obtain
`reports showing usage in a particular geographic area, or
`usage for particular types of merchants, and compare these 55
`to the incidents of reported fraud. One useful test is that of
`"velocity checking." Velocity checking involves determin(cid:173)
`ing how often a card is used within a particular time period.
`Such a check could, for example, uncover fraudulent activ(cid:173)
`ity, although this may be hard to distinguish from non- 60
`fraudulent cardholder activity.
`
`SUMMARY OF THE INVENTION
`
`The present invention provides an automated purchasing 65
`control system which can be customized for a business
`customer. The system receives an authorization request over
`
`the phone and data lines from a remote point-of-sale termi(cid:173)
`nal and processes the request using unique software. The
`software has a database customized to a business user to
`establish that business's hierarchial structure. Elements of
`the hierarchial structure are independently reconfigurable, so
`that a company can specify different hierarchial relation(cid:173)
`ships in the software for authorization, billing and reporting
`purposes. Different authorization tests can be established for
`each position in a hierarchy, with a particular position being
`required to pass not only its own test, but the test of elements
`higher in the hierarchial tree.
`An example of the benefits of the present invention is that
`a salesperson could be allowed a velocity checking limit for
`the category of hotels at a high frequency level, while an
`accounting clerk with no reason to travel could be allocated
`a lower velocity level, or allocated no authorization for
`hotels at all. The purchase reports for the salesperson could
`be put on a report which is organized in a different hierar(cid:173)
`chial way than the authorization hierarchy. For instance, the
`purchase reports may go to a special project the salesperson
`is working on, while the authorization will be in accordance
`with that salesperson's normal department. The present
`invention thus allows a company's expense and purchasing
`controls to be automated and implemented without human
`intervention through the use of purchasing or credit cards.
`The system takes advantage of the existing credit card
`networks which are adapted to serve the functions of the
`invention.
`
`The present invention merges a company's purchasing
`control system with a credit card authorization system to
`produce a real-time purchasing authorization and control
`system. The software and databases are structured to provide
`an automated electronic implementation of company limits
`and business approval processes, with a dynamic, overlap(cid:173)
`ping hierarchial structure, while approving or disapproving
`purchases by employees in real-time at the time of purchase.
`The entire purchasing process is re-engineered, and made a
`paperless process requiring no human intervention.
`The present invention also allows a company to group
`merchant category codes in order to limit purchases to those
`merchant types which would be needed by a particular
`department or individual. This automatically implements
`that company's purchase control system which would
`require certain types of vendors to be used for certain goods
`or services. This approved vendor grouping more closely
`matches a company's normal process than the merchant
`blocking of all undesired vendors used in prior art systems.
`The present invention has an approved vendor list feature
`which provides companies with the capability to create an
`approved vendor list to restrict and consolidate spending to
`specific merchants. Based on a comparison of the vendor
`data stored in an electronic approved vendor list and the
`merchant information transmitted from the point-of-sale in
`the authorization request, a purchase will be approved if the
`merchant data in the authorization request matches vendor
`information on the approved vendor list, or it will be
`declined if there is no match.
`In operation, the system of the present invention uses
`credit cards which have encoded on them a unique card
`number. This card number would include the individual
`account number, plus a bank identification number (BIN)
`which identifies the card as one designated for a purchasing
`control system. When the user makes a purchase, either in
`person or over the telephone, and the merchant passes the
`card through a point-of-sale (POS) device or terminal, the
`card number is transmitted over a credit card authorization
`
`Patent Owner, Ex. 2004, p. 11
`
`

`

`5,621,201
`
`system, such as the Visa system, to a remote central com(cid:173)
`puter. The computer will detect that the BIN number is one
`indicating a purchasing control system, and direct the autho(cid:173)
`rization request to the centralized purchasing control com(cid:173)
`puter system. This system will then look up the account 5
`number and identify the hierarchial position of the account
`number. The appropriate test for that account number will be
`identified and applied, along with tests of other elements
`higher in the hierarchy under which that account number
`falls. After
`the tests are performed,
`the computer will, 10
`depending upon the company's customized programming,
`generate a signal indicating the authorization request is
`either allowed or denied. If a particular test is failed, the
`system may simply generate a report item rather than a
`failure to authorize, depending upon how the system has 15
`been customized for the company.
`
`For a further understanding of the nature and advantages
`of the invention, reference should be made to the ensuing
`description in conjunction with the accompanying drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a flowchart illustrating a prior art paper based
`purchasing process;
`FIG. 2 is a chart of a hierarchial company account
`according to the present invention;
`FIG. 3 is a chart of the hierarchy of FIG. 2 modified for
`reporting;
`FIG. 4 is a chart of the hierarchy of FIG. 2 modified for
`authorization;
`FIG. 5 is an illustration of the database parameters for an
`account number at the cardholder level;
`FIG. 6 is a diagram of the database entry for an interme(cid:173)
`diate level in the hierarchy;
`FIG. 7 is an illustration of a card encoded according to the
`present invention;
`FIG. 8 is an illustration of a network according to the
`present invention;
`FIG. 9 is a flowchart of the authorization software of the
`present invention;
`FIG. 10 is a flowchart of the software authorization tests
`for a procurement card according to the present invention;
`and
`FIG. 11 is a flowchart of a software authorization test for
`a travel and entertainment card according to the present
`invention.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`A description of the database structure used by the present
`invention will facilitate an understanding of the invention.
`FIG. 2 is a chart showing a company's hierarchial depart- 55
`mental structure. The chart in FIG. 2 is also the format
`presented on a computer screen for a company employee to
`set up the desired hierarchial database for use in the auto(cid:173)
`mated purchasing control system of the present invention.
`The different boxes can be labeled and provided with the 60
`appropriate tests and test parameters.
`
`The level 1 box identifies the company in the database
`structure. Below that, levels up to a level 9 are allowed to
`show divisions, departments, etc. The level 9 level is des(cid:173)
`ignated as the individual cardholder account level, corre- 65
`spending
`to
`the physical card held by an
`individual
`employee. Between the cardholder level 9 and the company
`
`level 1, up to seven levels may be specified by the compa(cid:173)
`ny's structure.
`Once the basic company structure has been set out,
`separate hierarchies may be indicated for different purposes.
`For instance, the structure of FIG. 2 could be used for
`designating billing accounts, as shown by the asterisk. Only
`the departments or divisions having an asterisk are to receive
`a billing report for the levels beneath them.
`As shown in FIG. 3, a separate hierarchy could be
`designated for reporting purposes. In this example, division
`B is given a report indicating department 3, but not depart(cid:173)
`ment 4. Department 3 will include, at level 9, accounts 5 and
`6, which is entered in the company's organizational structure
`of FIG. 2, plus account number 2, which may be assigned to
`department 3 for reporting purposes. Thus, the company can
`independently configure the reporting hierarchy from the
`billing hierarchy. This can be done by a pointer in the
`account database for cardholder account number 3, which
`points to department 3 for reporting purposes, while point(cid:173)
`ing to department 2 for billing purposes, for instance.
`
`FIG. 4 illustrates yet another hierarchy which might be
`used for authorization purposes. In this instance, the hier(cid:173)
`archy grouping for authorization purposes is different from
`the reporting grouping.
`FIG. 5 illustrates a database entry for a particular card(cid:173)
`holder account number. A first field 10 contains the indi(cid:173)
`vidual cardholder account number. A second field 12 is a
`pointer to the next level up for authorization purposes. Field
`14 is a pointer to the next level up for billing purposes, and
`field 16 is a pointer to the next level up for reporting
`purposes. These fields are followed by a pointer or subrou(cid:173)
`tine call to a first authorization test 18, along with the
`parameters for that test 20. An additional test pointer 22 is
`shown, along with its parameters 24. Further tests are used,
`but are not shown, in order to keep the illustration simple.
`In one embodiment, when authorization is performed, the
`pointer is pointed to another portion of the database where
`the tests for the next level up may be found. Thus, the test
`for the account number level can be found and used, while
`separately an additional read can be done to determine the
`test for that particular department, division, etc., by going to
`the stored test at the location pointed to by the pointer.
`
`In an alternate embodiment, in order to make the autho(cid:173)
`rization process faster by requiring fewer reads, the pointer
`may be used for configuring the database only, with the
`actual tests for each level up in the hierarchy being stored
`along with account number 10. Although this consumes
`additional storage space by duplicating the department tests,
`all relevant tests and parameters are stored at a single
`location.
`
`In yet another embodiment, instead of storing multiple
`tests for each level hierarchy for the particular account
`number, the tests are combined. When the database is
`configured, there may be, for instance, a maximum limit set
`forth at multiple levels in the hierarchy. The particular
`account number will simply use the limiting one of these
`limits (presumably the lowest level for a maximum) as the
`parameter for the limit test. In this way, authorization is
`expedited by not only locating the relevant test and param(cid:173)
`eters in one location, but requiring a single test rather than
`multiple tests be run in real-time. Thus, additional efforts
`spent in configuring the database improves real-time per(cid:173)
`formance of the authorization process. This real-time speed
`is important for a customer waiting at a merchant location
`for credit card authorization.
`
`As can be seen, such a system provides a real-time
`purchasing control system, as opposed to the prior art system
`
`Patent Owner, Ex. 2004, p. 12
`
`

`

`5,621,201
`
`shown in FIG. 1, which requires either cash advances ahead
`of time or requisitions and purchase orders subsequent to the
`time of actual purchase. The present invention, by combin(cid:173)
`ing the credit card network system with a uniquely config(cid:173)
`ured database and operating software allows the merger of 5
`the company's purchasing control system, having multiple
`overlapping hierarchies, with a credit card authorization
`system to produce a real-time purchasing authorization and
`control system.
`FIG. 6 illustrates a database entry in one embodiment for 10
`a mid-level authorization group indicated in a field 26. This
`group may have its pointers to the next level up for autho(cid:173)
`rization in a field 28, for billing in a field 30, and for
`reporting in a field 32. Similarly to an individual account
`number, it will have its own test number 34 with associated is
`parameters 36. An additional test 38 with its parameters 40
`is also illustrated.
`As discussed above, in one embodiment, the database
`entry of FIG. 6 is configured by the company ahead of time
`for control purposes, but it not used in real-time in the 20
`authorization process. This is possible because after the
`parameters in the database fields of FIG. 6 have been set
`forth, the system will use the pointers and parameters to
`configure the fields of the individual account numbers
`shown in FIG. 5. This alignment of the system is self- 25
`correcting, such that if the position in the hierarchy is
`changed for any purpose, such as the billing level in field 30
`is modified, the pointers in both directions will cause the
`change to ripple through related hierarchial components.
`Because FIG. 6 illustrates a mid-level position, it not only 30
`has pointers to the next level, but additionally has pointers,
`in one embodiment, to all levels below it, as illustrated by
`fields 42, 44, 46 and 48.
`FIG. 7 illustrates a physical card encoded according to the
`present invention. The card 50 includes a magnetic strip 52
`Magnetic strip 52 includes a card number 54 composed of a
`BIN number 56 and account number 58. The BIN number is
`a Bank Identification Number which not only identifies the
`issuing bank, but also identifies the type of card issued. For
`the present invention, the BIN number would indicate the
`issuer and the fact that this is an automatic purchasing
`control card according to the present invention. This desig(cid:173)
`nation will indicate, when the card is read, that the database
`and software in a particular computer used by the present
`invention must be located and accessed for authorization.
`The individual account number 58 corresponds to account
`number 10 in FIG. 5 combined with a separate number
`indicating the company to which account number 10
`belongs. This is contrast with a typical credit card, in which
`the account number simply identifies the individual card(cid:173)
`holder account.
`
`35
`
`Another number on the strip is a service code 60 which
`can identify the particular type of card being used. For
`instance, it may identify that the card is a purchasing card, 55
`or a travel and entertainment card for a particular company.
`Alternately, the code could also indicate that the card is a
`cash only use card, or a card for debits for purchase at a
`merchant site in a point-of-sale (POS) device. Finally, a card
`verification value (CVV) 62 is used for error detection and 6o
`fraud detection.
`FIG. 8 is a block diagram of a system for implementing
`the present invention. A corporate card processor system 70
`is shown, with its own CPU 72. The CPU has data storage
`which can be divided up into individual company accounts 65
`74, 76, and 78. A pair of remote accessing terminals 80 and
`82 are shown. First terminal 80 may be connected to
`
`processor 72 through an interface 84 over a communication
`line, such as Digital T-l line 86. Terminal 82 might be
`connected, instead, over a dial-up modem 88 and a public
`packet-switched network communication link 90 to CPU 72.
`These terminals could be used by bank employees config(cid:173)
`uring the account, or be used directly by a corporate cus(cid:173)
`tomer to provide the configuration, which could then be
`verified by bank or other personnel before being entered into
`the system and activated. A separate service terminal 92 is
`also shown for maintenance of the CPU 72.
`Corporate card processor 70 is connected to a network,
`such as a VisaNet network 94. VisaNet network 94 can be
`connected
`to a merchant processing network 96, for
`instance, which would be connected to individual point-of-
`sale devices 98. Point-of-sale devices 98 would be located at
`individual merchant locations, and would receive a corpo(cid:173)
`rate or purchasing card according to the present invention
`and transmit the encoded card information along with the
`merchant identifying information to VisaNet network 94. An
`ATM network 93 is connected to ATMs 95, which can be
`considered a merchant type. The ATMs have a merchant
`code, and are used for cash advances.
`The VisaNet network 94 can be configured to have a
`central computer with a communication processor 100. This
`could be, for instance, an IBM 3745. The communication
`processor is connected to a mainframe 102. One such
`mainframe would be the IBM 3090. Local memory 104
`provides storage for mainframe 102. A control terminal 106
`allows local access for servicing and control of the VisaNet
`network.
`In operation, a credit card authorization request for a
`corporate card received by VisaNet network 94 would be
`identified from the BIN number as a corporate card, and the
`authorization request would be transmitted to corporate card
`processor 70 for authorization.
`In the event that processor 70 is unavailable for any
`reason, the VisaNet system includes stand-in processing
`(STTP) software 106, which can be used when the corporate
`card processor is not available. This STIP software includes
`positive cardholder identification service (PCAS) software
`which can do card number verification, PIN verification and
`balance verification, if desired. This provides a real-time
`backup to insure that an authorization request is responded
`to in real-time, even though the tests are limited.
`FIG. 9 is a flowchart illustrating the operation of the
`corporate card processor software for responding to an
`authorization request. First, from the BIN number, it can be
`determined that it is a corporate card as indicated in step 110.
`The corporate account number can be determined from the
`card number transmitted along with the message. From this
`card number, the software identifies a particular company
`account (Account 74, 76 and 78 in FIG. 8). The database
`entry for the individual account number is then retrieved
`(step 112). This would be, in one embodiment, an account
`record such as is shown in FIG. 5. The account record would
`be examined to determine if there are any test routines (step
`114). If a test is identified, the parameters from the database
`are loaded into the appropriate register of the processor, and
`the test routine pointed to (by address 18 in FIG. 5) is
`fetched and executed (step 118). The test results are stored
`(step 120) both for authorization purposes and for later
`report generation. The database is then examined to deter(cid:173)
`mine if there is another test, such as test 22 in FIG. 5 (step
`122). If there is such another step, the process is repeated for
`the second test.
`
`After all the tests for a particular account number are
`completed, in one embodiment, the routine will check for
`
`Patent Owner, Ex. 2004, p. 13
`
`

`

`5,621,201
`
`pointers to a different authorization level (step 124). If there
`are such pointers for test purposes, the process is repeated
`for that level, starting with step 112 in locating the database
`entry for that level, such as the entry shown in FIG. 6. In an
`alternate embodiment, all the tests of the other level have 5
`been combined with the test routines for the particular
`account number.
`When the tests are completed, the test results are com(cid:173)
`pared to the authorization response indicated by the com(cid:173)
`pany (step 126). For instance, a company may indicate that 10
`a test failure requires the purchase to not be authorized.
`Alternately, the purchase could be authorized, but a report
`could be generated indicating that certain limits have been
`exceeded. The appropriate response is then transmitted (step
`128) from the corporate card processor 70 to VisaNet 94, and
`from there through the network 96 to the originating POS 15
`98.
`FIG. 10 is a flowchart describing the software used for
`performing an exemplary series of tests for a credit card used
`for procurement purposes (a purchasing card). The tests are
`set up in order of priority. One advantage is that the most 20
`likely test to be failed would be performed first. In this way,
`an authorization response, if the authorization is to be
`denied, can be sent immediately back to the user waiting at
`the POS terminal. The software can then continue to process
`the rest of the tests and store them for reporting purposes. 25
`However, since the test has already been indicated as failing,
`there is no need to wait for the remaining tests to be
`performed before sending the authorization denial.
`Another function of the priority set forth in FIG. 10 is that
`certain tests may be required for authorizing a transaction, 30
`while additional tests will not affect authorization, but are
`used for reporting purposes. The tests which are needed for
`authorization can be placed as the first several tests to be
`performed, so that the authorization response can be gener(cid:173)
`ated without waiting for the remaining tests which can be 35
`completed after the authorization response is sent.
`In a particular example of FIG. 10, an authorization
`request is first received at step 110. A first test 112 is
`performed to determine if the account is blocked. If the
`account is blocked, a negative authorization response 114 40
`can be generated.
`Next, a velocity check can be performed (step 114). In the
`example shown, the response for a failed velocity check may
`be a referral of the authorization request to a live, human
`operator to ask some questions of the merchant (step 118).
`A VIP account test 120 determines if a particular account has
`been designated as a VIP account. If so, the remaining tests
`are not needed for authorization, since the VIP account
`would be usable for all the purposes set forth in the follow(cid:173)
`ing tests. Thus, an approval message 122 would be imme(cid:173)
`diately generated.
`The next test could be a country test 124, which may limit
`the cardholder to particular countries. A test 126 determines
`whether the Standard Industrial Classification (SIC) code of 55
`the merchant is acceptable for the account. If it is not, the
`request will be declined. Test 126 can include or exclude
`specific SIC codes. A test 128 determines whether the
`merchant category code of the merchant is in a special
`grouping for that company. If it is not, subsequent test 130 6o
`can be bypassed. Test 130 determines if the particular
`vendor is on an approved vendor list for that SIC code.
`Certainly, if the merchant category is not approved, the
`particular vendor will not be and there is no need to perform
`test 130 if test 128 has failed.
`Test 132 compares the merchant category code to a subset
`of approved SIC codes from test 126. If the code is in the
`
`65
`
`8
`approved grouping, separate test 134 may be used to deter(cid:173)
`mine if there is a special dollar limit for the particular code
`grouping which must be passed.
`Test 136 is used to provide a single transaction limit for
`an authorization request. Test 138 allows a spending limit to
`be applied over a company-defined cycle, such as a monthly
`cycle or other billing cycle. Test 140 allows a company's
`open-to-buy limit to be applied (the available credit at the
`com