Sign In to Follow Application
View All Documents & Correspondence

Atm Modified Version (Automatic Teller Modified Version)

Abstract: The main Aim of this project is to help the people/customer to get their financial transaction with the finiancial/banking institutions with out going to banks. They can access the banks thru ATM -Modified Version, just by swapping the debit/credit card. The customer can get their Demand Drafts /Stamp papers, they can book the railway/bus tickets and Airline Tickets, they can pay the electricity/telephone/house tax/insurance premium/ bills, they can transfer the money from their account to others. They need not wait for long que"s , they need not wait for long time as in banks to get their money The ATM modified vision in connected to internet.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
30 August 2012
Publication Number
15/2014
Publication Type
INA
Invention Field
COMPUTER SCIENCE
Status
Email
Parent Application

Applicants

K. RAJU
#708, CARNATION, SANKALPCENTRAL PARK, YADAVAGIRI, MYSORE - 570 012

Inventors

1. K. RAJU
#708, CARNATION, SANKALPCENTRAL PARK, YADAVAGIRI, MYSORE - 570 012

Specification

COMPLETE SPECIFICATION:-

1. TITLE OF THE PROJECT:- ATM—MODIFIED VERSION
(AUTOMATIC TELLER MACHINE -MODIFIED VERSION)

2. Field of Invention: Automatic Teller Machine

3. Background of Invention with regard to drawback associated with known art;- The present ATM s are having a numerical key pad , they don't have 88keys pad ie., with alphabets . and they transact only giving cash , transfer of amount ,and deposit of amount. Payment of bills . But they don't give stamp papers, Demand Drafts and airline ,railway line, and bus reservations of tickets by swapping Debit/Credit cards and transferring amount. So, to overcome this, I have introduced ATM modified version with 88keys pad & connecting internet

4. Object of Invention :- The objective of this project is to help the people/customer to get their financial transaction with the finiancial/banking institutions with out going to banks. They can access the banks thru ATM -Modified Version, just by swapping the debit/credit card. The customer can get their Demand Drafts /Stamp papers, they can book the railway/bus /Air tickets, they can pay the electricity/telephone/house tax/insurance premium/ bills, they can transfer the money from their account to others. They need not wait for long que's , they need not wait for long time as in banks to get their money/

5. Statement of Invention:- The problem is, Issuing a Demand Draft and Stamp Paper by the Banks is a time consuming. We have to wait for several hours to get our DD/Stamp papers. And also to book our railway tickets, bus tickets,Air line tickets we have to stand in long ques to get our tickets or we should have pc and network connections.

6. Summary of Invention :- An automated teller machine (ATM) is a computerized telecommunications device that provides the customers of a financial institution with access to financial transactions in a public space without the need for a human clerk or bank teller. On most modern ATMs, the customer is identified by inserting a plastic ATM card with a magnetic stripe or a plastic smartcard with a chip, that contains a unique card number and some security information, such as an expiration date or CVC (CVV). Security is provided by the customer entering a personal identification number (PIN).
Using an ATM, customers can access their bank accounts in order to make cash withdrawals (or credit card cash advances) and check their account balances as well as purchasing mobile cell phone prepaid credit. ATMs are known by various casual terms including automated banking machine, money machine, bank machine, cash machine, Any Time Money (in India).

The main intension of ATM Modifed Version is to issue Demand Drafts, Stamp Papers and Reservations to Air line , Railway line and Bus line. The key pad is having alpha numerical with 88 keys. So we can get th names and places of destination can be printed on the receipts

7. Brief description of the accompanying drawing:-

An ATM is typically made up of the following devices:

• CPU (to control the user interface and transaction devices)
• Magnetic and/or Chip card reader (to identify the customer)
• PIN Pad (similar in layout to that of a computer key board with 88keys), often manufactured as part of a secure enclosure.
• Secure cryptoprocessor, generally within a secure enclosure.
• Display (used by the customer for performing the transaction)
• Function key buttons (usually close to the display) or a Touchscreen (used to select the various aspects of the transaction)
• Record Printer (to provide the customer with a record of their transaction

Recently, due to heavier computing demands and the falling price of computer-like architectures, ATMs have moved away from custom hardware architectures using microcontrollers and/or application-specific integrated circuits to adopting a hardware architecture that is very similar to a personal computer. Many ATMs are now able to use operating systems such as Microsoft Windows and Linux.

Industry standard vault configurations include Underwriters Laboratories UL-291 "Business Hours" and Level 1 Safes RAL TL-30 derivatives,1 and CEN EN 1143-1:2005 - CEN III/VdS and CEN IV/LGAI/VdSATM manufacturers recommend that vaults be attached to the floor to prevent theft.

SOFT WARE:-
With the migration to commodity PC hardware, standard commercial "off-the-shelf operating systems and programming environments can be used inside of ATMs. Typical platforms used in ATM development include RMX, OS/2, and Microsoft operating systems (such as MS-DOS, PC-DOS, Windows NT, Windows 2000, Windows XP Professional, or Windows XP Embedded). Java, Linux and Unix may also be used in these environments.

Common application layer transaction protocols, such as Diebold 911 or 912, IBM PBM, and NCR NDC or NDC+ provide emulation of older generations of hardware on newer platforms with incremental extensions made over time to address new capabilities. Most major ATM manufacturers provide software packages that implement these protocols. Newer protocols such as IFX have yet to find wide acceptance by transaction processors. With the move to a more standardized software base, financial institutions have been increasingly interested in the ability to pick and choose the application programs that drive their equipment. WOSA/XFS, now known as CEN XFS (or simply XFS), provides a common API for accessing and manipulating the various devices of an ATM.

J/XFS is a Java implementation of the CEN XFS API. While the perceived benefit of XFS is similar to the Java's "Write once, run anywhere" mantra, often different ATM hardware vendors have different interpretations of the XFS standard. The result of these differences in interpretation means that ATM applications typically use a middleware to even out the differences between various platforms.
Notable XFS middleware platforms include Triton PRISM, Diebold Agilis, CR2 Bank World, KAL Kalignite. NCR Corporation Aptra Edge, Phoenix Interactive VISTAatm, and Wincor Nixdorf Protopas.

With the move of ATMs to industry-standard computing environments, concern has risen about the integrity of the ATM's software stack. Although ATMs were originally developed as just cash dispensers, they have evolved to include many other bank-related functions., especially those which benefit from a fully integrated cross-bank ATM network . Now, ATM-modified version include many functions which are not directly related to the management of one's own bank account, such as:

• Deposit currency recognition, acceptance, and recycling
• Paying routine bills, fees, and taxes (utilities, phone bills, social security, legal fees, taxes, etc.)
• Printing bank statements ,Demand Drafts, Stamp Papers
• Updating passbooks
• Loading monetary value into stored value cards
• Purchasing
o Postage stamps.
o Lottery tickets
o Transfer of monetary value to other accounts
o train tickets ,bus tickets air tickets
o Concert ticket
o Shopping mall gift certificates.

• Games and promotional featuresDonating to charities1-
• Cheque Processing Module

Increasingly banks can make use of the ATM-modified version as a sales device to deliver pre approved loans and targeted advertising using products ATMs can also act as an advertising channel for companies to advertise their own products or third-party products and service

8. Detailed description of the Invention with reference to drawing :-seprate sheets enclosed

Detailed Design
A major task of detailed design is to spell out, in detail, the attributes and methods needed by each class (the second and third "compartments" of the representation for each class in a class diagram.)
The methods needed by each class are implicit in the responsibilities assigned to the class in the CRC cards, and become explicit in the Interaction Diagrams. A responsibility listed for a class on its CRC card generally maps into a method or methods in the detailed design. Likewise, any time an object belonging to a given class is shown as the recipient of a message in either a Sequence or Collaboration Diagram, the class needs a corresponding method. Many of the needed attributes are also either explicitly or implicitly present in the diagrams; the need for others becomes evident as the code for the class is being written. (Thus detailed design and coding are a "round trip" process -detailed design dictates coding, and coding leads to elaboration of the detailed design.)

In designing this system, a few key design decisions were made:

• The class ATM is made an active class - that is, the ATM object has its own thread. Using the Java thread facility leads to defining a run() method in this class whose body is executed by the ATM's thread. The fact that class ATM is active is indicated in class diagrams by enclosing it in a heavier outline.

• Certain signals initiate computation - e.g. the signals from the operator console when the state of the switch is changed, or from the card reader when a card is inserted. In the GUI simulation of the ATM, these signals are sent by the "actionPerformedO" method of the appropriate GUI button; in a real ATM they would be sent by the physical components themselves, which might then also need to be active classes. (Note: this forms an exception to the rule that a responsibility on a CRC card translates into a method in the design - in this case the class sends a signal, rather than receiving it, so it does not need a method directly corresponding to the responsibility.)

• The Transaction hierarchy consists of the abstract class Transaction and seven concrete subclasses (Withdrawal, Deposit, Transfer and Inquiry, Demand Draft, Stamp paper, Airline/Railway line/Bus reservation). The class Transaction has a "virtual constructor" called makeTransactionQ which asks the customer to choose a transaction type and then constructs and returns an object of the appropriate subclass. The Transaction class is made responsible for carrying out the Transaction use case and the Invalid PIN extension; for the former, it makes use of abstract methods getSpecificsFromCustomerO and completeTransaction() which are implemented concretely by each subclass.

• The class Receipt is abstract. The completeTransaction method of each kind of transaction creates a concrete instance that contains the information relevant to that kind of transaction.

• The class Status is abstract. The send method of NetworkToBank constructs a concrete instance that contains the information appropriate to the response received from the bank to a particular message.

In the design below, each class is developed in isolation. No attempt is made to connect each class to
related classes as in the class diagram, because the resulting picture would not fit on a displayable web page. Therefore, this detailed design should be viewed in conjunction with the Class Diagram developed earlier.

• Detailed design for class ATM
• Component parts of the ATM

o Detailed design for class CardReader
o Detailed design for class CashDispenser
o Detailed design for class CustomerConsole
o Detailed design for class EnvelopeAcceptor
o Detailed design for class Log
o Detailed design for class NetworkToBank
o Detailed design for class OperatorPanel
o Detailed design for class ReceiptPrinter

• Detailed design for class Session
• The Transaction class hierarchy

o Detailed design for class Transaction
o Detailed design for class Withdrawal
o Detailed design for class Deposit
o Detailed design for class Transfer
o Detailed design for class Demand Draft
o Detailed design for class Stamp Paper
o Detailed design for class Airline/Railwayline/Bus reservation
o Detailed design for class Inquiry

• Classes representing banking concepts, used by the above

o Detailed design for class Accounflnformation
o Detailed design for class Balances o Detailed design for class Card

Interaction Diagrams for ATM M Modified Version

UML defines two types of Interaction Diagram: the Sequence Diagram and the Collaboration Diagram. In order to illustrate both types, the major use cases are documented using Sequence Diagrams, and the specific subcases of transaction (withdrawal, etc.) and the Invalid PIN Extension are documented using Collaboration Diagrams. (The major reason for using two different types of diagram is pedagogical - to illustrate each type.)

• Sequence Diagram for System Startup Use Case
• Sequence Diagram for System Shutdown Use Case
• Sequence Diagram for Session Use Case
• Sequence Diagram for Transaction Use Case (Since transaction is abstract, this gives the overall flow of a transaction. See the interactions below for specific concrete cases.)
• Collaboration realizing specifics of Withdrawal Transaction Use Case
• Collaboration realizing specifics of Deposit Transaction Use Case
• Collaboration realizing specifics of Transfer Transaction Use Case
• Collaboration realizing specifics of Inquiry Transaction Use Case
• Collaboration realizing Invalid PIN Extension

9. Claims:-

ATM Modified Version is invented to over come the present ATM s. This modified version will give us Stamp Paper , Demand Drafts, and Reservation of seats/ berths in Railway line, Airline and Bus line by swapping Debit/Credit cards by transferring the amount to the respective agencies and giving receipts with name , fare amount and place of Destinations.

Documents

Application Documents

# Name Date
1 3587-CHE-2012 FORM -2 30-08-2012.pdf 2012-08-30
1 3587-CHE-2012-AbandonedLetter.pdf 2019-12-26
2 3587-CHE-2012-FER.pdf 2019-06-18
2 3587-CHE-2012 FORM -1 30-08-2012.pdf 2012-08-30
3 3587-CHE-2012 DRAWINGS 30-08-2012.pdf 2012-08-30
3 3587-CHE-2012 FORM-18 14-11-2014.pdf 2014-11-14
4 3587-CHE-2012 ABSTRACT 16-08-2013.pdf 2013-08-16
4 3587-CHE-2012 DESCRIPTION (PROVISIONAL) 30-08-2012.pdf 2012-08-30
5 3587-CHE-2012 CLAIMS 16-08-2013.pdf 2013-08-16
5 3587-CHE-2012 CORRESPONDENCE OTHERS 22-07-2013.pdf 2013-07-22
6 3587-CHE-2012 FORM-5 16-08-2013.pdf 2013-08-16
6 3587-CHE-2012 DESCRIPTION(COMPLETE) 16-08-2013.pdf 2013-08-16
7 3587-CHE-2012 FORM-2 16-08-2013.pdf 2013-08-16
7 3587-CHE-2012 DRAWINGS 16-08-2013.pdf 2013-08-16
8 3587-CHE-2012 FORM-2 16-08-2013.pdf 2013-08-16
8 3587-CHE-2012 DRAWINGS 16-08-2013.pdf 2013-08-16
9 3587-CHE-2012 FORM-5 16-08-2013.pdf 2013-08-16
9 3587-CHE-2012 DESCRIPTION(COMPLETE) 16-08-2013.pdf 2013-08-16
10 3587-CHE-2012 CORRESPONDENCE OTHERS 22-07-2013.pdf 2013-07-22
10 3587-CHE-2012 CLAIMS 16-08-2013.pdf 2013-08-16
11 3587-CHE-2012 ABSTRACT 16-08-2013.pdf 2013-08-16
11 3587-CHE-2012 DESCRIPTION (PROVISIONAL) 30-08-2012.pdf 2012-08-30
12 3587-CHE-2012 DRAWINGS 30-08-2012.pdf 2012-08-30
12 3587-CHE-2012 FORM-18 14-11-2014.pdf 2014-11-14
13 3587-CHE-2012-FER.pdf 2019-06-18
13 3587-CHE-2012 FORM -1 30-08-2012.pdf 2012-08-30
14 3587-CHE-2012-AbandonedLetter.pdf 2019-12-26
14 3587-CHE-2012 FORM -2 30-08-2012.pdf 2012-08-30

Search Strategy

1 2019-06-1613-05-54_16-06-2019.pdf