U.S. patent application number 13/401748 was filed with the patent office on 2013-08-22 for systems and methods for facilitating secured financial transactions.
The applicant listed for this patent is Mike Leber. Invention is credited to Mike Leber.
Application Number | 20130218768 13/401748 |
Document ID | / |
Family ID | 48983054 |
Filed Date | 2013-08-22 |
United States Patent
Application |
20130218768 |
Kind Code |
A1 |
Leber; Mike |
August 22, 2013 |
Systems and Methods for Facilitating Secured Financial
Transactions
Abstract
Systems and methods for facilitating at least a portion of a
secure electronic financial transaction are provided herein.
Methods may include generating a unique payee identifier that
represents a unique payment relationship between a payee and one or
more payors, receiving a transaction request, the transaction
request comprising the unique payee identifier and a payment, and
authorizing a payment to the payee that corresponds to the
payment.
Inventors: |
Leber; Mike; (Fremont,
CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Leber; Mike |
Fremont |
CA |
US |
|
|
Family ID: |
48983054 |
Appl. No.: |
13/401748 |
Filed: |
February 21, 2012 |
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/023 20130101;
G06Q 20/385 20130101; G06Q 20/405 20130101; G06Q 20/401
20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/40 20120101
G06Q020/40 |
Claims
1. A method for facilitating at least a portion of a secure
electronic financial transaction, the method comprising: executing
instructions via a processor of a transaction processing system
for: generating a unique payee identifier that represents a payee;
receiving a transaction request, the transaction request comprising
an instrument that has been digitally singed by at least one payor
and the unique payee identifier; and authorizing a payment to the
payee according to payment instructions included in the
instrument.
2. The method according to claim 1, further comprising verifying a
digital signature associated with the transaction request.
3. The method according to claim 1, wherein the digital signature
comprises at least one of pretty good privacy (PGP) and secure
socket layer (SSL) authentication.
4. The method according to claim 1, wherein the payment
instructions specify that a payee may receive a set number of
authorized payments from a payor within a given period of time.
5. The method according to claim 1, wherein the payment
instructions specify that a payee may receive an aggregate payment
amount from one or more payors within a given period of time.
6. The method according to claim 1, wherein the payment
instructions comprise any of contract clauses, an invoice, a letter
of intent, a bill of lading, a promissory note, a mortgage, and an
automated clearing house request.
7. The method according to claim 1, wherein the payment
instructions define an apportionment of the payment between two or
more payors.
8. The method according to claim 1, further comprising querying a
third party to determine if the payment of a payor is
allowable.
9. The method according to claim 1, further comprising providing
the authorized payment to the payee.
10. The method according to claim 1, further comprising comparing
the transaction request to a transaction template that comprises a
set of established transaction specifications, wherein transaction
requests that correspond to the transaction template are available
for authorization.
11. A system for facilitating at least a portion of a secure
electronic financial transaction, the method comprising: a memory
for storing executable instructions; a processor for executing the
instructions, wherein the instructions comprise: an identification
generator stored in memory and executable by the processor to
generate a unique payee identifier that represents a payee; a
communications module stored in memory and executable by the
processor to receive a transaction request, the transaction request
comprising an instrument that has been digitally singed by at least
one payor and the unique payee identifier; and a transaction
authorization module stored in memory and executable by the
processor to authorize a payment to the payee according to payment
instructions included in the instrument.
12. The system according to claim 12, wherein the transaction
authorization module verifies a digital signature associated with
the transaction request.
13. The system according to claim 12, wherein the digital signature
comprises at least one of pretty good privacy (PGP) and secure
socket layer (SSL) authentication.
14. The system according to claim 11, wherein the transaction
authorization module compares the transaction request to a
transaction template that comprises a set of established
transaction specifications, wherein the transaction template is
established by a translation templating module that is stored in
memory and executable by the processor.
15. The system according to claim 11, wherein the transaction
request comprises payment instructions.
16. The system according to claim 11, wherein the payment
instructions specify that a payee may receive a set number of
authorized payments from at least one payor within a given period
of time.
17. The system according to claim 11, wherein the payment
instructions specify that a payee may receive an aggregate payment
amount from a payor within a given period of time.
18. The system according to claim 11, wherein the payment
instructions comprise any of contract clauses, an invoice, a letter
of intent, a bill of lading, a promissory note, a mortgage, and an
automated clearing house request.
19. The system according to claim 11, wherein the payment
instructions define an apportionment of the payment between two or
more payors.
20. The system according to claim 19, wherein the communications
module further queries a third party to determine if the payment is
allowable.
21. The system according to claim 11, wherein the communications
module provides the payment authorization to a bank that provides
the authorized payment to the payee.
Description
FIELD OF THE TECHNOLOGY
[0001] Embodiments of the disclosure relate to the facilitation of
secure financial transactions. More specifically, but not by way of
limitation, the present technology may be utilized to facilitate
secure financial transactions between one or more payors and one or
more payees.
BACKGROUND OF THE DISCLOSURE
[0002] Current methods for processing financial transactions
utilizing financial instruments such as checks and credit cards are
woefully ineffective in preventing fraud. As such, fraudulent
transactions may be conducted by a fraudster by obtaining relevant
account information and using the same in a manner which is
unauthorized by the legitimate account holder.
[0003] In some instances, enterprises may employ different types of
heuristics to attempt to determine if a transaction is fraudulent.
For example, it may be determined that because a credit card was
utilized in separate locations that are located across the country
from one another and within a specified time frame, that at least
one of the transactions may be fraudulent. In other instances,
enterprises may not employ any fraud detection measures. Customers
may be subject to time intensive and laborious efforts in order to
recover their money lost during a fraudulent transaction.
SUMMARY OF THE DISCLOSURE
[0004] According to some embodiments, the present technology may be
directed to methods for facilitating at least a portion of a secure
electronic financial transaction. Methods may include: (a)
generating a unique payee identifier that represents a payee; (b)
receiving a transaction request, the transaction request comprising
an instrument that has been digitally signed by at least one payor
and the unique payee identifier; and (c) authorizing a payment to
the payee according to payment instructions included in the
instrument.
[0005] According to additional embodiments, the present technology
may be directed to systems facilitating at least a portion of a
secure electronic financial transaction. The systems may comprise:
(a) a memory for storing executable instructions; (b) a processor
for executing the instructions stored in memory; (c) an
identification generator stored in memory and executable by the
processor to generate a unique payee identifier that represents a
payee; (d) a communications module stored in memory and executable
by the processor to receive a transaction request, the transaction
request comprising an instrument that has been digitally signed by
at least one payor and the unique payee identifier; and (e) a
transaction authorization module stored in memory and executable by
the processor to authorize a payment to the payee according to
payment instructions included in the instrument.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The accompanying drawings, where like reference numerals
refer to identical or functionally similar elements throughout the
separate views, together with the detailed description below, are
incorporated in and form part of the specification, and serve to
further illustrate embodiments of concepts that include the claimed
disclosure, and explain various principles and advantages of those
embodiments.
[0007] The methods and systems disclosed herein have been
represented where appropriate by conventional symbols in the
drawings, showing only those specific details that are pertinent to
understanding the embodiments of the present disclosure so as not
to obscure the disclosure with details that will be readily
apparent to those of ordinary skill in the art having the benefit
of the description herein.
[0008] FIG. 1 illustrates an exemplary system for practicing
aspects of the present technology;
[0009] FIG. 2 illustrates an exemplary conversion application for
facilitating at least a portion of a secure electronic financial
transaction;
[0010] FIG. 3 is a flowchart of an exemplary method for
facilitating at least a portion of a secure electronic financial
transaction; and
[0011] FIG. 4 illustrates an exemplary computing system that may be
used to implement embodiments according to the present
technology.
DETAILED DESCRIPTION
[0012] In the following description, for purposes of explanation,
numerous specific details are set forth in order to provide a
thorough understanding of the disclosure. It will be apparent,
however, to one skilled in the art, that the disclosure may be
practiced without these specific details. In other instances,
structures and devices are shown at block diagram form only in
order to avoid obscuring the disclosure.
[0013] Generally described, the present technology may be directed
to systems and methods for facilitating at least a portion of a
secure financial transaction. More specifically, but not by way of
limitation, the present technology may facilitate at least a
portion of a secured financial transaction such as transaction
request authentication, payment authorization, and/or payment
transmission.
[0014] Broadly speaking, the present technology may be implemented
within the context of a third party transaction processor that is
configured to securely process financial transactions on behalf of
both payor(s) and payee(s). It is noteworthy that in some
instances, the present technology may also comprise the financial
institution (e.g., bank) that transmits monetary assets to the
payee in response to the authorization of payment to the payee.
[0015] The present technology may generate a unique payee
identifier, hereinafter "UPI," that is utilized to verify the
identity of a payee before authorization of a payment to a
payee.
[0016] The present technology may also generate digital instruments
that represent a unique payment relationship between a payee and
one or more payors. In some instances, a payor such as a customer
may desire to execute a secure financial transaction with a payee
such as a merchant. The digital instrument may include payment
instructions that define how payments to the payee are authorized.
For example, the digital instrument may specify the type of
information (such as name, address, account number, etc.) that must
be gathered from the payor before payment can be authorized.
[0017] The payment instructions may allow for multiple transactions
between the parties, as long as the transactions comport with the
payment instructions. For example, the payment instructions may
specify that a payment amount may be requested and provided to the
payee within a specified period of time. Advantageously, payment
instructions may allow for installment payments, pre-dated
payments, or other temporally based payments between payors and
payees. Other variations on payment instructions will be discussed
in greater detail infra.
[0018] In addition to the use of an UPI, the present technology may
also employ security measures such as cryptography that allow
payors to digitally sign the digital instruments. The payor and/or
payee may utilize a program and/or digital security protocol that
can be used to verify the identity of the payor and/or payee and
digitally sign a digital instrument. For example, the present
technology may utilize pretty good privacy (PGP) encryption or
other encryption mechanisms such as a secure socket layer (SSL),
tokenization, along with any other suitable encryption/decryption
systems and processes that would be known to one of ordinary skill
in the art with the present disclosure before them.
[0019] In general, a digital instrument may comprise a set of
payment instructions that govern the manner with which financial
transactions between a payor and a payee are conducted by the
payment processor. That is, payment instructions may include a
specific set of rules that are defined by the payor and/or the
payee. In some instances, the payment processor may specify the
type of payment information that should be obtained from the payor
and/or payee. Also, the payment processor may establish one or more
required types of cryptographic or tokenization processes that may
be employed by the payor and/or payee.
[0020] In some embodiments, the payment information may incorporate
the use of standard commercial agreements and/or negotiable
financial instruments. Examples of these agreements include a
check, a wire, a cashier's check, card-present credit card terms,
card-not-present credit card terms, automated clearing house terms,
an escrow agreement, a contract, a bill, a letter of intent, a
purchase order, a promissory note, and a mortgage--just to name a
few. In other embodiments, the payment information may include only
sections of one or more of the aforementioned agreements.
[0021] The present technology may receive a transaction request
from either the payor or the payee. At a minimum, the transaction
request may comprise a digital instrument that has been digitally
signed, along with a unique payee identifier. Again, the digital
instrument may include payment instructions.
[0022] Once the present technology has processed the transaction
request, the present technology may authorize a payment to the
payee that corresponds to the payment instructions. It is
noteworthy that authorization of the payment may not include an
actual transfer of funds to the payee. For example, authorization
may include communication of an authorization signal from the
payment processor to a financial institution such as a bank.
Alternatively, if the payment processor and the financial
institution are the same entity, authorization of payment may
result in the immediate transfer of funds to the payee.
[0023] In some instances the present technology may allow for a
payment to be split or apportioned amongst multiple payors. In
other embodiments the present technology may allow for payors to
act as guarantors for other parties, such as another payor or a
third party.
[0024] Additionally, while the present technology may be utilized
within the context of secured electronic payments for actual
monetary consideration, the present technology may also be applied
to virtual currency systems such as those utilized in video gaming
environments or other types of virtual social constructs (e.g.,
social networking).
[0025] These and other advantages of the present technology will be
described in greater detail with reference to the collective FIGS.
1-4.
[0026] FIG. 1 illustrates an exemplary system 100 for practicing
aspects of the present technology. The system 100 may include a
transaction processing system 105 that may be implemented in a
cloud-based computing environment. A cloud-based computing
environment is a resource that typically combines the computational
power of a large grouping of processors and/or that combines the
storage capacity of a large grouping of computer memories or
storage devices. For example, systems that provide a cloud resource
may be utilized exclusively by their owners; or such systems may be
accessible to outside users who deploy applications within the
computing infrastructure to obtain the benefit of large
computational or storage resources.
[0027] The cloud may be formed, for example, by a network of web
servers, with each web server (or at least a plurality thereof)
providing processor and/or storage resources. These servers may
manage workloads provided by multiple users (e.g., cloud resource
customers or other users). Typically, each user places workload
demands upon the cloud that vary in real-time, sometimes
dramatically. The nature and extent of these variations typically
depend on the type of business associated with the user.
[0028] In other embodiments, the transaction processing system 105
may include a distributed group of computing devices such as web
servers that do not share computing resources or workload.
Additionally, the transaction processing system 105 may include a
single computing system that has been provisioned with a plurality
of programs that each produces instances of event data.
[0029] Payors and payees may communicate transaction data (e.g.,
digital instruments) between one another and/or the transaction
processing system 105 via individual client devices such as payor
client device 110A and payee client device 110B. The transaction
processing system 105 may communicatively couple with the payor
client device 110A and payee client device 110B via a network
connection 115. The network connection 115 may include any one of a
number of private and public communications mediums such as the
Internet. As mentioned briefly above, the payor client device 110A
and the payee client device 110B may utilize PGP, SSL, or another
suitable cryptographic protocol for transmitting transaction
information between each other and/or the transaction processing
system 105.
[0030] In some embodiments, payor client device 110A and payee
client device 110B may communicate with the transaction processing
system 105 using a secure application programming interface or API.
An API allows various types of programs to communicate with one
another in a language (e.g., code) dependent or language agnostic
manner.
[0031] The transaction processing system 105 may also communicate
with a third party 120 such as a financial institution that may
provide monetary funds to a payee, often using the payee's account
associated with the payee's financial institution of choice. The
transaction processing system 105 and the financial institution 120
may also communicate via the network connection 115, which may
comprise any one of a number of secure/insecure communications
protocols.
[0032] The transaction processing system 105 may be generally
described as a system for facilitating at least a portion of a
secure financial transaction. It is noteworthy that the system may
facilitate at least a portion of a secure financial transaction as
the system may in some instances authorize a payment, whereas in
other instances the system may also transmit payment to the payee
as well.
[0033] The transaction processing system 105 may facilitate at
least a portion of a secure financial transaction by generating a
UPI for each payee. Also, the transaction processing system 105 may
receive a transaction request, where the transaction request may
comprise at least the UPI and a digital instrument that has been
digitally signed by at least one payor. Advantageously, the digital
instrument may include payment instructions such as the payment
amount. It is noteworthy that the transaction request may be
received from either the payor or the payee, as will be described
in greater detail below.
[0034] Referring now to FIG. 2, the transaction processing system
105 may generally comprise memory that includes executable
instructions and a processor that executes the instructions stored
in memory. Further details regarding exemplary memory and processor
for the transaction processing system 105 are described relative to
computing system 400 as described in FIG. 4.
[0035] According to some embodiments, the executable instructions
may be embodied as an application 200. The application 200 may
generally comprise a transaction templating module 205, an
identification generator 210, a communications module 215, and a
transaction authorization module 220. It is noteworthy that the
application 200 may include additional modules, engines, or
components, and still fall within the scope of the present
technology. As used herein, the term "module" may also refer to any
of an application-specific integrated circuit ("ASIC"), an
electronic circuit, a processor (shared, dedicated, or group) that
executes one or more software or firmware programs, a combinational
logic circuit, and/or other suitable components that provide the
described functionality. In other embodiments, individual
modules/engines/generators of the application 200 may include
separately configured web servers. Also, the application 200 may be
provisioned with a cloud as with the transaction processing system
105.
[0036] Prior to facilitating secure financial transactions between
payors and payees, the transaction templating module 205 may be
executed to define transaction specifications used by the
transaction processing system 105. That is, the transaction
templating module 205 may establish digital instruments that are
accepted by the transaction processing system 105, and may be
utilized by the payor and payee to conduct a secure financial
transaction. Additionally, the identification generator 210 may be
executed to generate a UPI for a payee.
[0037] Generally speaking, when a digital instrument that has been
digitally signed by at least one payor has been received, along
with a UPI, the underlying transaction specified in the digital
instrument may be processed according to payment instructions
included in the digital instrument. For example, a payment to the
payee may be authorized in the digital instrument. The presence of
the UPI may ensure that only authorized payees receive payment.
[0038] According to some embodiments, the transaction templating
module 205 may maintain and utilize transaction templates that
comprise a set of established transaction specifications. These
transaction templates define a plurality of types of financial
transactions that the transaction processing system 105 may
process. While transaction templates have been contemplated, the
present technology may utilize other data stores, abstractions, or
collections of transaction data that define the type of transaction
information (e.g., transaction specifications) that are to be
collected from the payor and/or payee before authorization of
payment can be made to the payee.
[0039] Stated otherwise, transaction specifications may comprise
data types that are to be received from either the payor or the
payee in order to facilitate a specific type of secure financial
transaction, typically in the form of a digital instrument.
Non-limiting examples of financial transactions may include payment
for goods and/or services, installment contracts, mortgages,
promissory notes, and so forth. Types of information that may be
gathered include names, addresses, account numbers, payment,
currency preferences, payment dates, and so forth. Therefore, for
as many different types of financial transactions that may be
conducted by different payors and payees, the transaction
processing system 105 may employ combinations of transaction
specifications.
[0040] In some instances, the payor and payee may register with the
transaction processing system 105. Profiles for each payor and
payee may be created. These profiles may include information that
may be utilized by the transaction processing system 105 to
generate digital instrument for a specific payor and payee
combination. That is, in some embodiments, the digital instrument
is a representation of a unique payment relationship between a
payee and one or more payors. Because the digital instrument is
unique to the payee and payor(s) and can be combined with a UPI,
the digital instrument cannot be surreptitiously presented to the
transaction processing system 105 by another party.
[0041] Once transaction templates have been generated by the
transaction templating module 205, the application 200 awaits
receipt of a transaction request from either a payor or a payee. In
some instances, the transaction processing system 105 functions as
an intermediary between the payor and payee. In other instances,
the payor and payee may also communicate directly with one
another.
[0042] In some embodiments, the identification generator 210 may be
executed to generate a UPI each payee. The UPI may be used for
transactions conducted between a payor and a payee. This uniquely
identifying information, when presented along with a digital
instrument, may ensure that the digital instrument is used to
authorize payment to the correct payee.
[0043] In some instances the digital instrument may be generated by
the payor and/or payee, rather than the transaction processing
system 105. For example, the payee may provide to the transaction
processing system 105 a digital instrument such as a contract that
is to be used as the basis for consummating a transaction. The
transaction processing system 105 may provide the digital
instrument to one or more payors on behalf of the payee. A payor
may utilize a program to digitally sign the digital instrument.
This program may reside on the computing device associated with the
payor (see FIG. 1). The signed digital instrument may be provided
back to the transaction processing system 105, along with the UPI
for the payee, for payment authorization. If the signed digital
instrument comports with the requirements established for the
payee, payment may be authorized to the payee.
[0044] From the above examples, it may be understood that the
transaction processing system 105 may be the entity that
establishes the requirements necessary for payment authorization.
Alternatively, the payor or the payee may establish the
requirements necessary for payment authorization, while the
transaction processing system 105 effectuates the requirements
established by the payor and the payee.
[0045] The digital instrument may comprise payment instructions
that include transaction specifications as described above. That
is, the digital instrument may include specific contract provisions
that define the types of information that are to be gathered from
the payor and payee. In some instances the digital instrument is a
contract (e.g., digital instrument) that is based upon a set of
transaction specifications. This digital instrument may be provided
to the payor and the payee, where each party completes and
digitally signs the digital instrument before securely transmitting
the same back to the transaction processing system 105. Again, the
present technology may employ one or more various types of
cryptographic techniques for securing the digital instrument. In
its simplest form, the digital instrument may specify a payment
amount that is to be authorized to the payee.
[0046] A digital instrument may be utilized in conjunction with a
single transaction, or may be utilized as the basis to perform many
transactions. For example, the digital instrument may be used by a
payor to purchase a single product from a payee. In other examples,
the digital instrument may specify that the payee is authorized to
request a set number of payments from the payor within a given
period of time. For example, the payor may specify that the payee
is allowed to request two payments from the payor each month. In
other instances, the digital instrument may specify that the payee
is authorized to request a particular payment amount from the payor
within a given period of time. For example, the payor may authorize
the payee to request up to five hundred dollars in payments each
month. Alternatively, the payor may specify that the payee is to be
paid at a defined point in the future (e.g. pre-dating the
payment). In other embodiments, a payor may maintain a list of
approved payees, where transaction requests that include a digital
instrument for a payee on the list are automatically approved by
the transaction authorization module 220.
[0047] According to other embodiments, payments may be apportioned
between two or more payors, such as in a guarantor/guarantee
relationship. A second payor may be obligated to pay a specified
amount if a first payor fails to make a required payment. Likewise,
a payor may obligate themselves to pay for products/services
purchased by another party, which has limited or no payment
responsibility to the payee.
[0048] For example, a parent (payor) may establish a list of
approved merchants (payees) with which their child may conduct
transactions. The payor may place various types of limits on the
transactions such as amount, frequency, and so forth.
[0049] Generally speaking, the communications module 215 may allow
the payor client device 110A and the payee client device 110B to
interact with the application 200 to conduct financial
transactions. In some instances, the communications module 215 may
employ a web-based interface that is utilized by both payors and
payees to conduct secure financial transactions.
[0050] The communications module 215 may authenticate the payor and
payee devices before establishing a path of communications between
the payor/payee and the application 200. Again, the communications
module 215 may utilize PGP, SSL, or any other suitable method for
establishing secure data transfer between computing devices.
[0051] The communications module 215 may await receipt of a
transaction request from a payor or payee. The transaction request
may include both the digital instrument that has been digitally
signed by at least one payor, along with the UPI for the payee.
Again, either the payor or payee may generate the digital
instrument. If the digital instrument has been generated by the
payor or payee, the transaction authorization module 220 may be
executed to verify that the contents of the digital instrument
complies with transaction specifications (e.g., a transaction
template) established by the transaction processing system 105.
That is, transaction authorization module 220 may compare the
digital instrument received by the communications module 215 to
transaction templates managed by the transaction templating module
205.
[0052] In some instances, the digital instrument may specify that a
third party (such as an insurer) is to be queried to determine if
the payment is insured by the insurer. For example, the transaction
authorization module 220 may query an insurer for the payor to
determine if a payment that corresponds to the payment specified in
the digital instrument is covered by the payor's insurance
policy.
[0053] If the transaction request is approved under the payment
instructions included in the digital instrument, the transaction
authorization module 220 may authorize the transaction. That is,
the transaction authorization module 220 may authorize payment to
be made to the payee from the one or more payors, according to
further payment instructions included in the digital instrument.
Again, authorization for payment may include providing an
authorization signal to a financial institution (e.g., bank) that
monetary funds should be provided to the payee.
[0054] FIG. 3 illustrates a flowchart of an exemplary method for
facilitating at least a portion of a secure financial transaction.
The method may include a step 305 of generating a unique payee
identifier that represents a payee. This UPI may be used as a
verification mechanism to ensure that payments are being approved
for the proper payee.
[0055] Next, the method may include a step 310 of receiving a
transaction request. It is noteworthy that the transaction request
may include an instrument that has been digitally signed by at
least one payor and the UPI.
[0056] The method may include a step 315 of verifying a digital
signature associated with the transaction request, along with a
step 320 of verifying that the UPI is correct.
[0057] Next, the method may then include a step 325 of authorizing
a payment to the payee according to payment instructions included
in the instrument. It is noteworthy that the method may include
fewer or more steps that those recited above.
[0058] FIG. 4 illustrates an exemplary computing system 400 that
may be used to implement the various embodiments of the present
technology. The computing system 400 of FIG. 4 includes one or more
processors 410 and memory 420. Main memory 420 stores, in part,
instructions and data for execution by processor 410. Main memory
420 can store the executable code when the system 400 is in
operation. The system 400 of FIG. 4 may further include a mass
storage device 430, portable storage medium drive(s) 440, output
devices 450, user input devices 460, a graphics display 440, and
other peripheral devices 480.
[0059] The components shown in FIG. 4 are depicted as being
connected via a single bus 490. The components may be connected
through one or more data transport means. Processor unit 410 and
main memory 420 may be connected via a local microprocessor bus,
and the mass storage device 430, peripheral device(s) 480, portable
storage device 440, and display system 470 may be connected via one
or more input/output (I/O) buses.
[0060] Mass storage device 430, which may be implemented with a
magnetic disk drive or an optical disk drive, is a non-volatile
storage device for storing data and instructions for use by
processor unit 410. Mass storage device 430 can store the system
software for implementing embodiments of the present technology for
purposes of loading that software into main memory 420.
[0061] Portable storage device 440 operates in conjunction with a
portable non-volatile storage medium, such as a floppy disk,
compact disk or digital video disc, to input and output data and
code to and from the computing system 400 of FIG. 4. The system
software for implementing embodiments of the present technology may
be stored on such a portable medium and input to the computing
system 400 via the portable storage device 440.
[0062] Input devices 460 provide a portion of a user interface.
Input devices 460 may include an alphanumeric keypad, such as a
keyboard, for inputting alphanumeric and other information, or a
pointing device, such as a mouse, a trackball, stylus, or cursor
direction keys. Additionally, the system 400 as shown in FIG. 4
includes output devices 450. Suitable output devices include
speakers, printers, network interfaces, and monitors.
[0063] Display system 470 may include a liquid crystal display
(LCD) or other suitable display device. Display system 470 receives
textual and graphical information, and processes the information
for output to the display device.
[0064] Peripherals 480 may include any type of computer support
device to add additional functionality to the computing system.
Peripheral device(s) 480 may include a modem or a router.
[0065] The components contained in the computing system 400 of FIG.
4 are those typically found in computing systems that may be
suitable for use with embodiments of the present technology and are
intended to represent a broad category of such computer components
that are well known in the art. Thus, the computing system 400 of
FIG. 4 can be a personal computer, hand held computing system,
telephone, mobile computing system, workstation, server,
minicomputer, mainframe computer, or any other computing system.
The computer can also include different bus configurations,
networked platforms, multi-processor platforms, etc. Various
operating systems can be used including UNIX, Linux, Windows,
Macintosh OS, Palm OS, and other suitable operating systems.
[0066] Some of the above-described functions may be composed of
instructions that are stored on storage media (e.g.,
computer-readable medium). The instructions may be retrieved and
executed by the processor. Some examples of storage media are
memory devices, tapes, disks, and the like. The instructions are
operational when executed by the processor to direct the processor
to operate in accord with the technology. Those skilled in the art
are familiar with instructions, processor(s), and storage
media.
[0067] It is noteworthy that any hardware platform suitable for
performing the processing described herein is suitable for use with
the technology. The terms "computer-readable storage medium" and
"computer-readable storage media" as used herein refer to any
medium or media that participate in providing instructions to a CPU
for execution. Such media can take many forms, including, but not
limited to, non-volatile media, volatile media and transmission
media. Non-volatile media include, for example, optical or magnetic
disks, such as a fixed disk. Volatile media include dynamic memory,
such as system RAM. Transmission media include coaxial cables,
copper wire and fiber optics, among others, including the wires
that comprise one embodiment of a bus. Transmission media can also
take the form of acoustic or light waves, such as those generated
during radio frequency (RF) and infrared (IR) data communications.
Common forms of computer-readable media include, for example, a
floppy disk, a flexible disk, a hard disk, magnetic tape, any other
magnetic medium, a CD-ROM disk, digital video disk (DVD), any other
optical medium, any other physical medium with patterns of marks or
holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASHEPROM, any other
memory chip or data exchange adapter, a carrier wave, or any other
medium from which a computer can read.
[0068] The above description is illustrative and not restrictive.
Many variations of the technology will become apparent to those of
skill in the art upon review of this disclosure. The scope of the
technology should, therefore, be determined not with reference to
the above description, but instead should be determined with
reference to the appended claims along with their full scope of
equivalents.
[0069] In the foregoing specification, the invention is described
with reference to specific embodiments thereof, but those skilled
in the art will recognize that the invention is not limited
thereto. Various features and aspects of the above-described
invention can be used individually or jointly. Further, the
invention can be utilized in any number of environments and
applications beyond those described herein without departing from
the broader spirit and scope of the specification. The
specification and drawings are, accordingly, to be regarded as
illustrative rather than restrictive. It will be recognized that
the terms "comprising," "including," and "having," as used herein,
are specifically intended to be read as open-ended terms of
art.
* * * * *