U.S. patent application number 14/089873 was filed with the patent office on 2015-05-28 for synchronous split payment transaction management.
This patent application is currently assigned to International Business Machines Corporation. The applicant listed for this patent is International Business Machines Corporation. Invention is credited to Srihari N. Ananda kumar, Rajath Ramesh, Lohith Ravi.
Application Number | 20150149344 14/089873 |
Document ID | / |
Family ID | 53183478 |
Filed Date | 2015-05-28 |
United States Patent
Application |
20150149344 |
Kind Code |
A1 |
Ananda kumar; Srihari N. ;
et al. |
May 28, 2015 |
SYNCHRONOUS SPLIT PAYMENT TRANSACTION MANAGEMENT
Abstract
A software- and/or hardware-based transaction manager that
reflects the application program interface(s) and/or system(s) for
establishing sessions used to commit to, rollback and/or execute
multiple payments made pursuant to a single financial transaction.
This is accomplished by sharing sessions through co-browsing, or by
continuous event logging and maintaining synchronous payments
across a group of users in order to: support the lifecycle of each
individual payment and session along with completion responsibility
of the overall transaction.
Inventors: |
Ananda kumar; Srihari N.;
(Mysore, IN) ; Ravi; Lohith; (Bangalore, IN)
; Ramesh; Rajath; (Mysore, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
International Business Machines Corporation |
Armonk |
NY |
US |
|
|
Assignee: |
International Business Machines
Corporation
Armonk
NY
|
Family ID: |
53183478 |
Appl. No.: |
14/089873 |
Filed: |
November 26, 2013 |
Current U.S.
Class: |
705/39 |
Current CPC
Class: |
G06Q 20/14 20130101;
G06Q 20/407 20130101; G06Q 20/10 20130101; G06Q 20/29 20130101 |
Class at
Publication: |
705/39 |
International
Class: |
G06Q 20/38 20060101
G06Q020/38 |
Claims
1-8. (canceled)
9. A computer program product comprising software stored on a
software storage device, the software comprising: first program
instructions programmed to establish a set of communication
session(s), over a communication network, between a plurality of
payees and a transaction management computer; and second program
instructions programmed to receive from each payee of the plurality
of payees, through the communication session(s), a commitment to
enter into a first financial transaction; wherein: each payee of
the plurality of payees is connected, by the set of communication
session(s), to the transaction management computer at a time of
receipt of a latest-in-time commitment; and the software is stored
on a software storage device in a manner less transitory than a
signal in transit.
10. The product of claim 9 wherein: the first program instructions
are further programmed to establish the set of communication
session(s) under control of a transaction manager module of the
transaction management computer; and the set of communication
session(s) are maintained in at least one of the following ways:
(i) as a co-browsing session between, at least, the payees and the
transaction management computer, and/or (ii) continuous event
logging.
11. The product of claim 9 wherein the software further comprises:
third program instructions programmed to support a life cycle of
each individual payment; and fourth program instructions programmed
to execute all payments associated with the first financial
transaction.
12. The product of claim 9 wherein: each payee of the plurality of
payees is continuously connected, by the set of communication
session(s), to the transaction management computer from at least a
time of receipt of an earliest-in-time commitment through at least
the time of receipt of the latest-in-time commitment.
13. The product of claim 9 wherein the set of communication
session(s) is one of the following types: (i) constituted by a
single communication in which all payees and the transaction
management computer participate, or (ii) includes a dedicated and
separate communication session respectively between each of the
payees and the transaction management computer.
14. The product of claim 9 wherein the software further comprises:
third program instructions programmed to establish a communication
session, over the communication network, between the transaction
management computer and a first payment execution payment computer;
and fourth program instructions programmed to, responsive to
receipt of commitment from all payees, request, by the transaction
management computer and from the first payment execution computer,
execution of a first payment made under terms of the first
financial transaction.
15. The product of claim 14 wherein: each payee of the plurality of
payees is continuously connected, by the set of communication
session(s), to the transaction management computer from at least a
time of receipt of the latest-in-time commitment through at least a
time of requesting execution of the first payment.
16. The product of claim 14 wherein the software further comprises:
fifth program instructions programmed to establish a communication
session, over the communication network, between the transaction
management computer and a set payment execution payment
computer(s); and sixth program instructions programmed to,
responsive to receipt of commitment from all payees, request, by
the transaction management computer and from the set of payment
execution computer(s), execution of all payments to be made under
terms of the first financial transaction; and seventh program
instructions programmed to request notification, by the transaction
management computer and from the set of payment execution
computer(s), of successful execution of all payments to be made
under terms of the first financial transaction; wherein each payee
of the plurality of payees is continuously connected, by the set of
communication session(s), to the transaction management computer
from at least a time of receipt of the latest-in-time commitment
through at least a time of receipt of a latest-in-time notification
of successful execution.
17. A computer system comprising: a processor(s) set; and a
software storage device; wherein: the processor set is structured,
located, connected and/or programmed to run software stored on the
software storage device; and the software comprises: first program
instructions programmed to establish a set of communication
session(s), over a communication network, between a plurality of
payees and a transaction management computer; and second program
instructions programmed to receive from each payee of the plurality
of payees, through the communication session(s), a commitment to
enter into a first financial transaction; wherein each payee of the
plurality of payees is connected, by the set of communication
session(s), to the transaction management computer at a time of
receipt of a latest-in-time commitment.
18. The system of claim 17 wherein: the first program instructions
are further programmed to establish the set of communication
session(s) under control of a transaction manager module of the
transaction management computer; and the set of communication
session(s) are maintained in at least one of the following ways:
(i) as a co-browsing session between, at least, the payees and the
transaction management computer, and/or (ii) continuous event
logging.
19. The system of claim 17 wherein the software further comprises:
third program instructions programmed to support a life cycle of
each individual payment; and fourth program instructions programmed
to execute all payments associated with the first financial
transaction.
20. The system of claim 17 wherein: each payee of the plurality of
payees is continuously connected, by the set of communication
session(s), to the transaction management computer from at least a
time of receipt of an earliest-in-time commitment through at least
the time of receipt of the latest-in-time commitment.
Description
FIELD OF THE INVENTION
[0001] The present disclosure relates generally to the field of
payment processing, and more particularly to the technical
architecture and participation process associated with group
payments.
BACKGROUND OF THE INVENTION
[0002] Computer network communication "sessions" between two, or
more, separate endpoints, respectively identified by network
addresses, are known. A "session," as that term is used herein,
defines at least some of the resource(s) associated with a
particular user. Sharing the resources of one user to another user
is conventionally accomplished by co-browsing or by other ways of
continuous synching (for example, repetitive logging of events).
One popular example of a communication session is a TCP/IP
(transmission control protocol/internet protocol) session. In a
TCP/IP session, a session provides reliable, ordered, error-checked
delivery of a stream of octets between network-connected endpoints.
As a further example, some communication sessions between endpoints
instead use the connectionless User Datagram Protocol (UDP), which
emphasizes low-overhead operation and reduced latency rather than
error checking and delivery validation. There are still other
existing protocols for creating a session, and it is quite possible
that still more protocols will be developed in the future. Despite
the differences among various types of sessions, in a computer
network communication system, once the session is established and
active, each endpoint that receives a communication (such as a set
of data packets) will "know" which endpoint sent the communication.
For example, if only a first endpoint and second endpoint mutually
establish a communication session between them, then, so long as
the session remains active, the first endpoint will know that
communications received through the session are from the second
endpoint, and the identity of the second endpoint does not need to
be re-determined (for example, re-authenticated) for every
communication received in the context of the active and on-going
session.
[0003] A financial transaction is an exchange of money or some
other financial asset for something else of value, such as
information, goods, services, or money. A financial transaction
involves at least two parties: a payer, who gives up the financial
asset, and a payee, who receives it. The parts of a financial
transaction need not occur simultaneously. For example, money could
be given at one time, and the goods given in return at another. A
financial transaction could also include the giving of a gift,
where the thing of value received in exchange for the financial
asset given is the intangible benefit to the payer of the act
itself or the results it does or is expected to produce.
[0004] A payer in a financial transaction may also be a payee in
the same transaction. This is the case, for instance, when an
individual moves money from one bank account to another. A payer or
payee may be a natural person or any other legal entity.
[0005] In the context of a payment transaction, "commitment" is
when a payee party has been effectively informed that she is
legally bound to make a payment (regardless of whether the party is
bound, in fact and law, under the contract law of her
jurisdiction(s)). This occurs when handing cash to a cashier,
signing a credit card payment receipt, or when clicking a button to
confirm a purchase placed on an e-commerce website.
[0006] As used herein, the relatively broad concept of
"consummation" of a payment transaction includes the following
types: (i) legally binding consummation (or, "being legally
bound"), which status begins at the point(s) in time at which the
payee(s) are legally bound to pay (whether they realize it or not);
(ii) commitment consummation, which status begins at the point(s)
in time at which the payee(s) are sufficiently notified that they
are bound to pay such that a reasonable person in the payee's
circumstances would consider herself bound to pay; (iii) execution
type consummation, which status begins at the point(s) in time at
which money, or other consideration, is actually transferred from
effective possession of the payee(s) to effective possession of the
payment-receiving party(ies); and (iv)
completed-transaction-notification type consummation, which status
begins at the point(s) in time at which the payee(s) are reasonably
considered to have been notified that their money, or other
consideration, has been transferred out of their effective
possession. These types of consummation may, or may not, occur
within seconds of each other (for example, substantially at the
same time), and these types of consummation may overlap--they are
not mutually exclusive ways of describing consummation status in a
given payment transaction.
[0007] Execution, for its part, can be broken down into various
sub-types including: (i) pending execution, which refers to status
after execution has been requested of the parties who are actually
effecting the transfer of money, but before execution is resolved;
and (ii) resolved execution, which refers to the status after the
point(s) in time at which the funds are transferred (or transfer is
denied, for example, for insufficient credit in a credit card
account). In many cases, pending execution will last a very, very
short time because systems (for example, electronic payment
systems) take a very short time to respond to a request that funds
be transferred from a payee to a payment-receiving party.
SUMMARY
[0008] According to one aspect of the present disclosure, there is
a computer program product, system and/or method which performs the
following actions (not necessarily in the following order and not
necessarily in serial sequence): (i) establishing a set of
communication session(s), over a communication network, between a
plurality of payees and a transaction management computer; and (ii)
receiving from each payee of the plurality of payees, through the
communication session(s), a commitment to enter into a first
financial transaction. Each payee of the plurality of payees is
connected, by the set of communication session(s), to the
transaction management computer at a time of receipt of a latest in
time commitment.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS
[0009] FIG. 1 is a schematic view of a first embodiment of a
networked computers system (including one or more processing
devices) according to the present invention;
[0010] FIG. 2 is a flowchart showing a process performed, at least
in part, by the first embodiment computer system;
[0011] FIG. 3 is a schematic view of a portion of the first
embodiment computer system;
[0012] FIG. 4 is a screenshot generated by the first embodiment
computer system;
[0013] FIG. 5A is a screenshot generated by a second embodiment
computer system;
[0014] FIG. 5B is a screenshot generated by a third embodiment
computer system;
[0015] FIG. 6 is a schematic view of a transaction manager paradigm
for a fourth embodiment computer system;
[0016] FIG. 7 is a schematic view of a fifth embodiment computer
system;
[0017] FIG. 8 is an action diagram for a sixth embodiment computer
system; and
[0018] FIG. 9 is a schematic view of a seventh embodiment computer
system.
DETAILED DESCRIPTION
[0019] This Detailed Description section is divided into the
following sub-sections: (i) The Hardware and Software Environment;
(ii) First Embodiment; (iii) Further Comments and/or Embodiments;
and (iv) Definitions.
I. The Hardware and Software Environment
[0020] As will be appreciated by one skilled in the art, aspects of
the present invention may be embodied as a system, method or
computer program product. Accordingly, aspects of the present
invention may take the form of an entirely hardware embodiment, an
entirely software embodiment (including firmware, resident
software, micro-code, etc.) or an embodiment combining software and
hardware aspects that may all generally be referred to herein as a
"circuit," "module" or "system." Furthermore, aspects of the
present invention may take the form of a computer program product
embodied in one or more computer-readable medium(s) having computer
readable program code/instructions embodied thereon.
[0021] Any combination of computer-readable media may be utilized.
Computer-readable media may be a computer-readable signal medium or
a computer-readable storage medium. A computer-readable storage
medium may be, for example, but not limited to, an electronic,
magnetic, optical, electromagnetic, infrared, or semiconductor
system, apparatus, or device, or any suitable combination of the
foregoing. More specific examples (a non-exhaustive list) of a
computer-readable storage medium would include the following: an
electrical connection having one or more wires, a portable computer
diskette, a hard disk, a random access memory (RAM), a read-only
memory (ROM), an erasable programmable read-only memory (EPROM or
Flash memory), an optical fiber, a portable compact disc read-only
memory (CD-ROM), an optical storage device, a magnetic storage
device, or any suitable combination of the foregoing. In the
context of this document, a computer-readable storage medium may be
any tangible medium that can contain, or store, a program for use
by or in connection with an instruction execution system,
apparatus, or device.
[0022] A computer-readable signal medium may include a propagated
data signal with computer-readable program code embodied therein,
for example, in baseband or as part of a carrier wave. Such a
propagated signal may take any of a variety of forms, including,
but not limited to, electro-magnetic, optical, or any suitable
combination thereof. A computer-readable signal medium may be any
computer-readable medium that is not a computer-readable storage
medium and that can communicate, propagate, or transport a program
for use by or in connection with an instruction execution system,
apparatus, or device.
[0023] Program code embodied on a computer-readable medium may be
transmitted using any appropriate medium, including but not limited
to wireless, wireline, optical fiber cable, RF, etc., or any
suitable combination of the foregoing.
[0024] Computer program code for carrying out operations for
aspects of the present invention may be written in any combination
of one or more programming languages, including an object oriented
programming language such as Java (note: the term(s) "Java" may be
subject to trademark rights in various jurisdictions throughout the
world and are used here only in reference to the products or
services properly denominated by the marks to the extent that such
trademark rights may exist), Smalltalk, C++ or the like and
conventional procedural programming languages, such as the "C"
programming language or similar programming languages. The program
code may execute entirely on a user's computer, partly on the
user's computer, as a stand-alone software package, partly on the
user's computer and partly on a remote computer or entirely on the
remote computer or server. In the latter scenario, the remote
computer may be connected to the user's computer through any type
of network, including a local area network (LAN) or a wide area
network (WAN), or the connection may be made to an external
computer (for example, through the Internet using an Internet
Service Provider).
[0025] Aspects of the present invention are described below with
reference to flowchart illustrations and/or block diagrams of
methods, apparatus (systems) and computer program products
according to embodiments of the invention. It will be understood
that each block of the flowchart illustrations and/or block
diagrams, and combinations of blocks in the flowchart illustrations
and/or block diagrams, can be implemented by computer program
instructions. These computer program instructions may be provided
to a processor of a general purpose computer, special purpose
computer, or other programmable data processing apparatus to
produce a machine, such that the instructions, which execute via
the processor of the computer or other programmable data processing
apparatus, create means for implementing the functions/acts
specified in the flowchart and/or block diagram block or
blocks.
[0026] These computer program instructions may also be stored in a
computer-readable medium that can direct a computer, other
programmable data processing apparatus, or other devices to
function in a particular manner, such that the instructions stored
in the computer-readable medium produce an article of manufacture
including instructions which implement the function/act specified
in the flowchart and/or block diagram block or blocks.
[0027] The computer program instructions may also be loaded onto a
computer, other programmable data processing apparatus, or other
devices to cause a series of operational steps to be performed on
the computer, other programmable apparatus or other devices to
produce a computer-implemented process such that the instructions
which execute on the computer or other programmable apparatus
provide processes for implementing the functions/acts specified in
the flowchart and/or block diagram block or blocks.
[0028] An embodiment of a possible hardware and software
environment for software and/or methods according to the present
invention will now be described in detail with reference to the
Figures. FIG. 1 is a functional block diagram illustrating various
portions of networked computers system 100, including: Acme server
computer sub-system (that is, a portion of the larger computer
system that itself includes a computer) 102; Mike's smartphone
(client sub-system) 104; Nancy's agent's computer (client
sub-system) 106; BestCo computer (client sub-system) 108; Rowdy
Rooster Escrow computer (client sub-system) 110; Nancy's credit
card issuer's computer (client sub-system) 112; communication
network 114; Acme server computer 200; communication unit 202;
processor set 204; input/output (i/o) interface set 206; memory
device 208; persistent storage device 210; display device 212;
external device set 214; random access memory (RAM) devices 230;
cache memory device 232; and program 300.
[0029] As shown in FIG. 1, Acme server computer sub-system 102 is,
in many respects, representative of the various computer
sub-system(s) in the present invention. Accordingly, several
portions of computer sub-system 102 will now be discussed in the
following paragraphs.
[0030] Server computer sub-system 102 may be a laptop computer,
tablet computer, netbook computer, personal computer (PC), a
desktop computer, a personal digital assistant (PDA), a smart
phone, or any programmable electronic device capable of
communicating with the client sub-systems via network 114. Program
300 is a collection of machine readable instructions and/or data
that is used to create, manage and control certain software
functions that will be discussed in detail, below, in the First
Embodiment sub-section of this Detailed Description section.
[0031] Server computer sub-system 102 is capable of communicating
with other computer sub-systems via network 114. Network 114 can
be, for example, a local area network (LAN), a wide area network
(WAN) such as the Internet, or a combination of the two, and can
include wired, wireless, or fiber optic connections. In general,
network 114 can be any combination of connections and protocols
that will support communications between server and client
sub-systems.
[0032] It should be appreciated that FIG. 1 provides only an
illustration of one implementation (that is, system 100) and does
not imply any limitations with regard to the environments in which
different embodiments may be implemented. Many modifications to the
depicted environment may be made, especially with respect to
current and anticipated future advances in cloud computing,
distributed computing, smaller computing devices, network
communications and the like. Likewise, the terms "client" and
"server" are not to be taken as limiting the functionality of any
particular device referred to herein by these terms, as some or all
of the various computers in system 100 could function as a client,
as a server, as both, or as neither, depending upon the specific
implementation and context in which a given device is
operating.
[0033] As shown in FIG. 1, server computer sub-system 102 is shown
as a block diagram with many double arrows. These double arrows (no
separate reference numerals) represent a communications fabric,
which provides communications between various components of
sub-system 102. This communications fabric can be implemented with
any architecture designed for passing data and/or control
information between processors (such as microprocessors,
communications and network processors, etc.), system memory,
peripheral devices, and any other hardware components within a
system. For example, the communications fabric can be implemented,
at least in part, with one or more buses.
[0034] Memory 208 and persistent storage 210 are computer-readable
storage media. In general, memory 208 can include any suitable
volatile or non-volatile computer-readable storage media. It is
further noted that, now and/or in the near future: (i) external
device(s) 214 may be able to supply, some or all, memory for
sub-system 102; and/or (ii) devices external to sub-system 102 may
be able to provide memory for sub-system 102.
[0035] Program 300 is stored in persistent storage 210 for access
and/or execution by one or more of the respective computer
processors 204, usually through one or more memories of memory 208.
Persistent storage 210: (i) is at least more persistent than a
signal in transit; (ii) stores the program on a tangible medium
(such as magnetic or optical domains); and (iii) is substantially
less persistent than permanent storage. Alternatively, data storage
may be more persistent and/or permanent than the type of storage
provided by persistent storage 210.
[0036] Program 300 may include both machine readable and
performable instructions and/or substantive data (that is, the type
of data stored in a database). In this particular embodiment,
persistent storage 210 includes a magnetic hard disk drive. To name
some possible variations, persistent storage 210 may include a
solid state hard drive, a semiconductor storage device, read-only
memory (ROM), erasable programmable read-only memory (EPROM), flash
memory, or any other computer-readable storage media that is
capable of storing program instructions or digital information.
[0037] The media used by persistent storage 210 may also be
removable. For example, a removable hard drive may be used for
persistent storage 210. Other examples include optical and magnetic
disks, thumb drives, and smart cards that are inserted into a drive
for transfer onto another computer-readable storage medium that is
also part of persistent storage 210.
[0038] Communications unit 202, in these examples, provides for
communications with other data processing systems or devices
external to sub-system 102, such as client sub-systems 104, 106,
108, 110, and 112. In these examples, communications unit 202
includes one or more network interface cards. Communications unit
202 may provide communications through the use of either or both
physical and wireless communications links. Any software modules
discussed herein may be downloaded to a persistent storage device
(such as persistent storage device 210) through a communications
unit (such as communications unit 202).
[0039] I/O interface set 206 allows for input and output of data
with other devices that may be connected locally in data
communication with server computer 200. For example, I/O interface
set 206 provides a connection to external device set 214. External
device set 214 will typically include devices such as a keyboard,
keypad, a touch screen, and/or some other suitable input device.
External device set 214 can also include portable computer-readable
storage media such as, for example, thumb drives, portable optical
or magnetic disks, and memory cards. Software and data used to
practice embodiments of the present invention, for example, program
300, can be stored on such portable computer-readable storage
media. In these embodiments the relevant software may (or may not)
be loaded, in whole or in part, onto persistent storage device 210
via I/O interface set 206. I/O interface set 206 also connects in
data communication with display device 212.
[0040] Display device 212 provides a mechanism to display data to a
user and may be, for example, a computer monitor or a smart phone
display screen.
[0041] The programs described herein are identified based upon the
application for which they are implemented in a specific embodiment
of the invention. However, it should be appreciated that any
particular program nomenclature herein is used merely for
convenience, and thus the invention should not be limited to use
solely in any specific application identified and/or implied by
such nomenclature.
II. First Embodiment
[0042] Preliminary note: The flowchart and block diagrams in the
following Figures illustrate the architecture, functionality, and
operation of possible implementations of systems, methods and
computer program products according to various embodiments of the
present invention. In this regard, each block in the flowchart or
block diagrams may represent a module, segment, or portion of code,
which comprises one or more executable instructions for
implementing the specified logical function(s). It should also be
noted that, in some alternative implementations, the functions
noted in the block may occur out of the order noted in the figures.
For example, two blocks shown in succession may, in fact, be
executed substantially concurrently, or the blocks may sometimes be
executed in the reverse order, depending upon the functionality
involved. It will also be noted that each block of the block
diagrams and/or flowchart illustration, and combinations of blocks
in the block diagrams and/or flowchart illustration, can be
implemented by special purpose hardware-based systems that perform
the specified functions or acts, or combinations of special purpose
hardware and computer instructions.
[0043] FIG. 2 shows flow chart 250 depicting a method according to
the present invention. FIG. 3 shows program 300 for performing at
least some of the method steps of flow chart 250. This method and
associated software will now be discussed, over the course of the
following paragraphs, with extensive reference to FIG. 2 (for the
method step blocks) and FIG. 3 (for the software blocks).
[0044] Processing begins at step S255, where initiation mod 355
initiates a payment transaction involving one or more parties and a
financial institution (see definition of "financial institutions,"
below, in the Definitions sub-section of this Detailed
Description). In this embodiment, the payers are named Mike and
Nancy, and the payees are Acme Widget Company, Bestco and Rowdy
Rooster Escrow Company. In this example, none of the payees are a
financial institution. Alternatively, the payee could be a
financial institution. The payment was initiated co-operatively by
Mike (working on smartphone 104, see FIG. 1), Nancy's agent
(working on computer 106 with a virtual private network (VPN)
connection, see FIG. 1) and the Acme Widget company server computer
sub-system 102 (see FIG. 1).
[0045] In this example, mod 355 sets up three (3) communication
sessions which will all substantially overlap in time as the
parties commit to and execute at least some of their various split
payments. More specifically, mod 355 sets up the following sessions
(also called a three-way split session): (i) first session between
Mike's smartphone 104 and Acme server sub-system 102; (ii) second
session between Nancy's agent's computer 106 and Acme server
sub-system 102; (iii) a third session between Nancy's credit card
issuer's computer 112 (including any intermediate gateway computers
(not separately shown in FIG. 1)) and Acme server sub-system 102.
In this example, mod 355 acts as the transaction manager for the
three concurrent sessions. Alternatively, there could be a single
session to which Acme's sub-system, Mike, Nancy's agent, and
Nancy's credit card issuer's computer are all parties.
[0046] Processing proceeds to step S260, where user interface mod
360 displays a commitment screen to Mike (on his device 104) and
Nancy's agent (on her device 106). This commitment screen display
is shown by screenshot 400 of FIG. 4. It is substantially the same
display for both Mike and Nancy's agent, except that: (i) Mike's
display will never show buttons 404 and 408 as clickable buttons;
and (ii) Nancy's agent's display will never show buttons 406 and
402 as clickable buttons.
[0047] During step S260, mod 355 maintains the three-way split
session involving Mike, Nancy's agent, Nancy's credit card issuer's
computer, and Acme's subsystem. This three-way split session allows
mod 360 to easily and reliably send the commitment screen
information to Mike and Nancy's agent and keep all participating
parties in sync.
[0048] Processing proceeds to step S265, where user interface mod
360 of server sub-system 102 (see FIG. 1) receives approval
information, indicating Mike's approval. More specifically, Mike
clicks button 402 (see FIG. 4) on his smartphone 104 (see FIG. 1).
In this example, this approval can be revoked by Mike, by hitting
button 406 (see FIG. 4), so long as he acts before all of the other
payees (in this case, Nancy acting through her agent) also approve.
Alternatively, in some embodiments approval may not be revocable at
all. Alternatively, Mike and Nancy may be given a short period to
revoke (for example, five minutes) even after both of them have
indicated their approval. Even if such a short revocation window is
provided, the payment should still be considered as being executed
"substantially simultaneously" to the last necessary approval.
[0049] During step S265, mod 355 maintains the three-way split
session involving Mike, Nancy's agent, Nancy's credit card issuer's
computer, and Acme's subsystem. This three-way split session allows
mod 360 to easily and reliably receive approval information from
Mike and keep all participating parties in sync.
[0050] Processing proceeds to step S270, where user interface mod
360 of server sub-system 102 (see FIG. 1) receives approval
information, indicating Nancy's approval. More specifically,
Nancy's agent clicks button 404 (see FIG. 4) on her computer 106
(see FIG. 1). In this example, the payment can be cancelled by
Nancy's agent, by hitting button 408 (see FIG. 4), so long as she
clicks button 408 prior to clicking button 404. In this example,
Mike and Nancy's agent are acting in "real time," which means that
Mike and Nancy's agent can see each other's actions quickly enough
so that reasonable payees would consider that payment approvals and
notification of payments are made at substantially the same time.
For example, as a practical matter, if Mike has to wait an hour
after Nancy's approval to be informed of the approval, then this
would not be "in real time." On the other hand, if Mike has to wait
ten seconds to be informed of Nancy's approval, then this latency
is still consistent with "real time."
[0051] During step S270, mod 355 maintains the three-way split
session involving Mike, Nancy's agent, Nancy's credit card issuer's
computer, and Acme's subsystem. This three way split session allows
mod 360 to easily and reliably receive approval from Nancy's agent
and keep all participating parties in sync.
[0052] Processing proceeds to step S275, where commitment mod 375
"commits" (see definition in Background section, above) all
payments by sending notification to both Mike and Nancy's agent
that Mike and Nancy are committed to make the payments. Depending
upon the applicable law of contracts, this may or may not be the
same as the moment that Mike and Nancy become legally bound to make
the payments. Also, depending upon the applicable law, and/or
arrangements between the parties, Mike may or may not be
responsible to make Nancy's payment, in case Nancy's payment fails,
and vice versa. The notification reasonably should make Mike and
Nancy's agent (and, constructively, Nancy) aware that they will
have to make their payments and that there is no longer a chance to
"back out of the deal." In some embodiments, step S275 may be
omitted.
[0053] During step S275, mod 355 maintains the three-way split
session involving Mike, Nancy's agent, Nancy's credit card issuer's
computer, and Acme's subsystem. This three-way split session allows
mod 375 to easily and reliably send the commitment screen
information to Mike and Nancy's agent and keep all participating
parties in sync.
[0054] Processing proceeds to step S280, where execution mod 380
conducts execution processing. More specifically, mod 380 performs
the following sub-steps: (i) requests execution of payments that
are immediately payable under the terms of the payment transaction
and are also susceptible to being paid over a computer network;
(ii) receives resolution of the execution requests it has made; and
(iii) notifies Mike and Nancy's agent of how their immediately
payable and immediately executable payment(s) have indeed been
resolved (that is, paid, or refused). In some embodiments,
sub-steps (i), (ii) and (iii) will take place "substantially
instantaneously," meaning within a few seconds, or even a fraction
of a second. After sub-step (i) is performed, execution of the
payments-under-execution will be in pending status. After sub-step
(ii), actual execution has taken place (for example, funds have
been successfully transferred). Sub-step (iii) is post execution,
and may be omitted due to prior notification at step S275. In this
embodiment, sub-steps (i), (ii) and (iii) all take place among and
between computers and through a communication network. In many
embodiments, the executing parties will all be financial
institutions.
[0055] At step S280, if an immediately payable and immediately
executable payment is not successfully resolved, then this may
impact other payments and/or the payment transaction as a whole.
For example, if one immediately payable and immediately executable
payment does not go through, then other immediately payable and
immediately executable payments may be "rolled back."
[0056] Execution mod 380 performs, at a minimum, the initiation of
execution of transaction components that can be automatically
initiated. In some embodiments, execution mod 380 performs
additional functions, such as placing reserve holds on credit card
payment amounts or rolling back component transactions when for
some reason the overall transaction cannot be completed. Also, as
can be seen from FIG. 4, some required payments in the payment
transaction may not be immediately payable (that is, due right
away). Also, even payments due right away may not be executable
over a communication network, such as payments which involve actual
physical transfer of physical goods (see "currency" payment
specified in screenshot 400 of FIG. 4).
[0057] During step S280, mod 355 maintains the three-way split
session involving Mike, Nancy's agent, Nancy's credit card issuer's
computer, and Acme's subsystem. This three-way split session allows
mod 380 to easily and reliably: (i) effect execution with Nancy's
credit card issuer's computer; (ii) notify Mike and/or Nancy's
agent of any executed payment(s); and/or (iii) keep all
participating parties in sync. In this example, the executed
payments are: (i) the payment made by Nancy's credit card (see FIG.
4); and (ii) the payment in Acme credits made by Mike to Acme.
Alternatively, Mike and Nancy's agent could have been dropped from
the three-way split session either after Nancy's approval, or after
notification of the parties of Nancy's approval, but prior to
execution of Nancy's payment.
III. Further Comments and/or Embodiments
[0058] In some embodiments of the present invention, resources
which are associated with various parties by the use of a session
established under session protocol(s) are used to accomplish one,
or more, of the following: (i) payment; (ii) maintaining the
Commit; (iii) rollback; (iv) trust; and/or (v) such other major
events in the payment. In some embodiments, time and frequency are
associated with each session.
[0059] Some embodiments of the present disclosure seek to provide a
technique for synchronously making a split payment. A split payment
is one in which a single payment transaction is split between
multiple distinct "payment vehicles" (for example, distinct credit
and/or debit cards).
[0060] Some embodiments of the present disclosure may have one, or
more, of the following features, characteristics and/or advantages:
(i) provide a mechanism, system, and protocol to maintain the
transaction life cycle for a split payment; (ii) address the
problem of making multiple monetary payments in parallel during the
life cycle of a single transaction; (iii) cover the parameters and
trust co-efficiency factor involved in committing or rolling back
payments during this life cycle (a trust co-efficiency factor
pertains to questions such as: (a) whether the payment cards used
are genuine, (b) whether the members involved in the transaction
are genuine, and/or (c) whether there is a problem in the system,
like one of the commits did not happen or there are discrepancies
in the system or the payment gateway in associating the payments to
one root radical transaction; if any problems are detected, the
system can roll back the transaction); (iv) provide for situations
where those involved in a split payment transaction are a set of
anonymous untrusted participants, who use different payment
vehicles across different communication networks, all managed
within a single transaction life cycle and under a common paradigm
for handling the transaction.
[0061] Some embodiments of the present disclosure recognize that
the current trend toward group transactions, like group shopping
and finding groups through social networking, has been moving
forward with great zeal, but that while conducting transactions in
any payee dashboard, the only option is for payment with just one
single payment vehicle (for example, a single credit card). The
mechanism presented in this disclosure solves this particular issue
by presenting a solution where: (i) multiple users (see definition
of "user," below, in the Definitions section of this Detailed
Description section) can pay in parallel with different payment
vehicles; and/or (ii) a single user can pay in parallel using
multiple payment vehicles. For example, suppose a team of
individuals wishes to book a flight. While booking online together,
there could be a great offer presented based on the size of the
group or the cost of the purchase, but some embodiments of the
present invention recognize as a problem the fact that the
e-commerce software supports only a single payment vehicle for
making the payment for the multiple airline seats. Some embodiments
of the present disclosure provide an option to make the payment in
a distributed environment with: (i) multiple payers in the same
transaction; and/or (ii) multiple payment vehicles for the same
transaction.
[0062] Some embodiments of the present disclosure recognize that
booking tickets for a large group using a single credit card or
debit card can be potentially problematic for various reasons,
including the following: (i) a low credit card/debit card limit
(for example, eight people are booking flights and the cost per
ticket is $1,000, but none of the eight people have a credit card
with a limit greater than $5,000, which is less than the $8,000
needed to book all eight tickets); (ii)
unavailability/synchronization problem (multiple independent
transactions with different cards may result in a some people
getting a ticket while others find that by the time they attempt to
book, all seats are full); (iii) sharing problem (it can be a
cumbersome and problematic process for the secondary payers in a
group transaction to transfer their share of the overall cost to
the primary payer). Some embodiments of the present disclosure
provide a protocol to solve one, or more, of the foregoing
problems.
[0063] In some embodiments of the present disclosure, a synchronous
split payment is carried out by different people, with each person
using: (i) her own mode of payment (mobile, Internet, telephone, or
so forth); and/or (ii) her own payment vehicle. Some embodiments of
the present invention can readily be used in real time to
accommodate group transactions. An example of a payment method
according to the present invention, from an end-user perspective,
follows: (i) a primary user initiates a transaction and adds a set
of payers; (ii) a co-browsing/co-editing session is opened that
tracks the login status, payment status, and other state indicators
of each of the users; (iii) each user specifies his or her
contribution (or alternatively, the primary payer has already
specified each person's contribution amount in step (i)); and (iv)
once each user has locked in his or her contribution, a final
commit is done, either automatically by one or more triggers or
manually by one of the payers, thereby committing the main payment
transaction and successfully completing the split payment. In this
example method: (i) the co-browsing session has an expiry time
which can optionally be extended; and (ii) if the session times
out, by default the individual payment(s) made by each user will be
rolled back.
[0064] Some embodiments of the present disclosure possess one or
more of the following features: (i) parties to a transaction can
add or vote out other parties; (ii) triggers can be set so that
when the transaction amount is collectively reached by contributing
parties, the main transaction is automatically committed; (iii) a
long parent transaction is established that waits to commit or roll
back individual payments of transaction participants; and (iv)
setting of co-browsing sessions and handling of payments can be
done by different modes.
[0065] To generalize the conditions that could be applied for a
group payment, in some embodiments of the present disclosure,
features such as the ability of a primary user to add other payers,
the ability for parties in a transaction to vote out other parties,
the ability to extend the main payment transaction session time,
and so on can be configured policies that govern the group payment
transaction. Whole governance is carried out by a policy engine
which works closely with the system application. Furthermore, these
policies can be enforced by a payee (fund-receiving party) or a
payer (payment-making party).
[0066] For example, given a group payment made by Alice, Bob and
Charlie for booking seats through an airline, the airline's
policies could be configured thus: (i) do not allow extension of a
session more that two times; (ii) each session extension is for 3
minutes and an additional charge of $10 (this could be even more
granular); (iii) allow dynamic change of payment amount with
payers' concordance; (iv) accept partial payment and allot seats to
parties whose payments are done; and (v) commit payment only when
the primary participant wants to do so. Numerous other alternatives
are possible.
[0067] The primary participant (the payer who initiates the payment
transaction) can also establish policies that will govern a
transaction. For instance, the primary participant could establish
the following set of policies: (i) other participants can demand
change of payment mode; (ii) Participant A can ask Participant B to
pay a certain amount (that is, dynamic changing of payment amount);
(iii) allow other participants to add parties; and (iv) allow other
participants to vote out parties. Numerous other alternatives are
possible here as well.
[0068] Some embodiments of the present disclosure facilitate
refunds by the vendor (that is, the payment recipient) in cases of
incomplete transactions, such as where one of the co-payers failed
to pay his or her portion of the transaction prior to session
timeout, or where the transaction was withdrawn by one or more of
the co-payers. In such cases, these embodiments auto-detect and
refund the money of the payers who have already completed their
portion of the failed transaction. Such a feature is helpful in
situations where a user does not have an option to lock the
transaction amount he or she is responsible for, but instead has
only the option of submitting a payment or not.
[0069] FIG. 5A shows a user view of co-browsing session 500a of an
embodiment of the present disclosure. This co-browsing session
displays time-to-expiry of the main payment transaction session
(this is the same as the remaining time of the co-browsing
session), as well as transaction participants and their status
details, including payment status. The view here is on a terminal,
but other users in this or other embodiments could be using other
types of interfaces, such as a webpage, where the view may vary
according to the mode each user employs. There are two options for
logging in to the session: (i) the vendor/payee or the primary
payer provides details of each payer and corresponding payment
mode, allowing each user so authorized to log in; or (ii) all the
co-payers log in to the session (in this embodiment, a session
established via an Internet communications protocol that is defined
for payment) in parallel as authorized by each of the other
co-payers already logged in to the session. In either case, a
transaction tree is created and a long-duration session is set up
to track the state of all child transactions and to commit the
parent transaction accordingly.
[0070] Co-browsing session 500a has three participants: Alice, Bob
and Charlie. Alice is the initial participant, who adds Bob and
Charlie to the parent payment transaction and starts the session
(alternatively, Bob and Charlie can be added when they
independently log in to the session). Alice, being the initial
participant, is automatically logged in. She locks in her payment
amount at $600. Bob and Charlie subsequently log in by their mode.
Bob then locks in his payment amount at $600 (after locking a
payment, a user has the option to unlock it and change the amount).
At this point the session is waiting for Charlie to lock in his
amount before the session times out. Alice and Bob can vote out
Charlie if he does not respond for some time, or one or more of the
participants can increase the session timeout period to give
Charlie more time to respond. If Charlie does not respond before
the session timeout, the actions of Alice and Bob are rolled back
by default. Charlie does respond, however, locking in his payment
amount. This action causes the group to collectively reach a
tentative commitment to the target amount, triggering a final
prompt to the user group to accept the overall transaction. Alice
does so, and the split payment is completed. In other embodiments,
the session might permit only the principal participant to commit
the transaction, or the session itself might automatically complete
the transaction once the sum of the individual commitments reaches
the required amount. Other variations are also possible.
[0071] FIG. 5B shows a user view of co-browsing session 500b of an
embodiment of the present disclosure. In this session, one of the
users (Bob) does not have a locking option on his card (his bank
did not provide one). For the users in the session who have a
locking option (Alice and Charlie), a two-step payment mechanism is
used: (i) the individual transaction amount within the session
period is locked, and (ii) the individual payment is committed. For
example, Alice is paying from a credit card where she has the
option of locking in the transaction amount, so her individual
transaction is not undertaken until the parent transaction is
committed. This avoids the overhead of rolling back a payment. Bob,
however, who is paying through a mobile device, does not have the
option of locking in an amount, so he makes his payment outright.
Providing both payment options is not only user friendly but also
vendor friendly, because if, for whatever reason, the overall
transaction is not completed, the vendor can easily and
automatically detect an orphan payment such as Bob's and provide a
refund. Notice that in this example session, the parent transaction
was automatically committed once the transaction amount was
reached.
[0072] Some embodiments of the present disclosure include a
transaction manager. The transaction manager coordinates the
overall transaction, including logging in participants, creating a
child transaction for each member of the overall transaction,
committing each child transaction and hence the parent transaction,
and, if need be, rolling back one or more transactions. The
transaction manager communicates with different payment gateways,
where payments from different modes can be made synchronously under
a parent payment transaction initiated by the primary payer. Along
with managing the life cycle of the child payment transactions
(including fund locking, payment, payment status, and rollback of
payment for participating individuals), the transaction manager
also maintains the long-life-cycle parent payment transaction,
taking appropriate actions according to the status of its child
transactions.
[0073] FIG. 6 shows transaction manager paradigm 600 according to
an embodiment of the present disclosure. Transaction manager
paradigm 600 includes: primary payer 605; secondary payers 610; and
payment modes 615. Primary payer 605 initiates a group payment.
Payer 605 is later joined by secondary payers 610. Each payer is
using one of modes 615, which in this embodiment include Internet,
phone banking, and mobile money. The transaction manager (not
shown) creates a long-life parent payment transaction and also
spawns child transactions for each participant payment. The
transaction manager is equipped to connect to different payment
gateways, all of which are managed under a single parent
transaction. The transaction manager periodically checks the status
of all child transactions, and if one or more of the child
transactions fails or is interrupted, the transaction manager will
cancel or roll back the parent payment. Alternatively, if all the
child transactions are committed, the transaction manager will
commit the parent payment. Other variations are also possible. For
example, in other embodiments, commitments can be made
automatically based on various triggers, such as committing the
parent payment transaction once the required amount is met by some
subset of the child transactions, or committing all locked child
transactions on session expiry. In some embodiments, participants
can even add or remove other participants based on various
conditions (such as voting), thus keeping the parent payment
transaction flexible. All these alternatives are made possible by
the transaction manager.
[0074] FIG. 7 shows how an embodiment of the transaction manager
maintains the life cycle of the payment transactions made by
individual participants who use different payment channels, and
hence how it maintains the overall payment transaction. Shown in
FIG. 7 are: transaction manager system 700; transaction manager
705; network 710; mode endpoints (payment gateways) 715; and users
720. Participating users 720 provide required payment details and
have committed payments that will process upon the parent payment
being committed. Transaction manger 705 sets up connections with
different payment gateways 715 as necessary depending on the mode
of payment of each of users 720, and keeps track of the status of
each payment. The parent payment is successfully completed when all
the child payments are successful. If some of the child
transactions fail, however, then by default all payments are rolled
back. Alternatively, the primary payer can handle committing the
parent payment manually by committing all successful payments and
ignoring failed ones, or reducing the quantity of the item to be
purchased based on the final amount paid (for example, when there
are unsuccessful child payments). All these abilities make the
transaction manager paradigm effective and well suited for handling
a split payment scenario in the real world.
[0075] FIG. 8 shows action diagram 800 for an embodiment of the
present disclosure. Actions shown include: initiate session 805;
enter session 810; increase session time 815; commit payment 820;
co-browse 825; remove co-payer 830; transaction manager paradigm
835; parent transaction amount reached 840; transaction abort
request 845; and complete transaction 850. The first action is
always initiate session 805, where a primary payer initiates a
transaction and the session manager returns the session id of the
initialized session. A parent transaction session is thus created
here, and the transaction session has some default expiry time
associated with it. Alternatively, if one or more sessions already
exist that are associated with that payer, the transaction manager
gets the associated sessions list and returns that information. In
enter session 810, the payer enters the particular session created
or selected in initiate session 805. Co-payers are then added under
co-browse action 825, and dependent child transactions are spawned
as the co-paying participants log in under the umbrella of the
parent payment transaction. These child transaction sessions are
constrained to the session expiry of the parent. All the
transactions (parent and children) are maintained by transaction
manager paradigm 835, where the following actions can occur: (i) a
participant can lock an associated individual payment amount or
commit an individual payment amount in commit payment action 820;
(ii) other participants can add or vote out a participant to the
parent transaction in remove co-payer action 830; (iii) a primary
payer can increase the expiry time for the parent session upon
request in increase session time action 815; (iv) the parent
transaction can be committed to successfully complete a payment
once the transaction amount of the parent payment has been reached
via the combination of parent transaction amount reached action 840
and complete transaction action 850; (v) if any transaction fails
or is aborted, corrective actions can be taken as per a
configuration established for the session, such as rolling back
child transactions, or committing successful payments while
ignoring failed ones via the combination of transaction abort
requested action 845 and complete transaction action 850; and (vi)
once the payment transaction is complete, notifications can be sent
to payers through their respective payment mode in complete
transaction action 850. Together, these actions provide an
effective and robust way of making synchronous payments using
different payment modes in a real-life scenario.
[0076] Some embodiments of the present disclosure maintain a
transaction session synchronously and also across different clients
and modes. To conduct a split transaction in real time among a
number of co-payers, all co-payers have to be in sync. Each
co-payer can view the details and status of other co-payers (such
as via a co-browsing or co-editing system where only passwords are
hidden from each other but other details involved in the
transaction are visible), and the commit of the transaction is
determined unanimously by all co-payers together in real time (or,
alternatively, at the primary payer's discretion). To realize this
functionality, a transaction manager at the vendor's end maintains
long sessions and continuously synchronizes the information
presented to all co-payers. Some embodiments of the present
disclosure recognize that doing such a transaction asynchronously
may have multiple issues regarding security and practicality, for
instance if the transactions are committed asynchronously and
separately then the vendor may be responsible for handling partial
payments, which may be an undesirable situation.
[0077] As shown in FIG. 9, one embodiment of the present disclosure
includes the following components: vendor system 900; application
server 903; transaction manager 905; group transaction
configuration data 910; enterprise information system (data system)
915; application 920; mode adapter 923; interactive voice response
(IVR) gateway 925; Internet banking gateway 927; short message
service (SMS) gateway 930; payment gateway 935; policy engine 940;
and payment modes 615. In this embodiment, each payment mode 615
interfaces with vendor-side application 920 through one of gateways
925, 927, or 930 associated with adapter 923, as appropriate for
the payment mode being used. Application 920 interfaces with data
system 915 in support of a split payment transaction executed
through the various payment modes 615 and coordinated by
transaction manager 905, which maintains the status of a parent
transaction and its children via group transaction configuration
data 910. Payments are processed on the back end via payment
gateway 935. Some embodiments of the present disclosure may have
one, or more, of the following: (i) payment participation methods
and connection exchanges, along with data modifications, covered as
part of a single set of protocol(s); (ii) a mechanism/protocol
enabling payment synchronously by more than one participant that
involves separately locking, and then later committing; (iii) the
participants are always in sync, and each of them can inspect the
others' respective statuses; (iv) participant(s) can add a new
contributing participant for the payment; (v) participants can lock
the payment amount and commit unanimously, and all together; (vi)
the server maintains long sessions and continuously synchronizes
all the co-payers; (vii) the server provides the infrastructure to
maintain prolonged live sessions; and/or (viii) a single
transaction-managing component at the vendor's end.
[0078] Some embodiments of the present disclosure may have one, or
more, of the following features, characteristics, and/or abilities:
(i) a transaction is unblocked for every individual payment
synchronously and the transaction completes when all payments have
been made; (ii) no session or sessions have larger time intervals
for expiring than others; (iii) authority for transaction
completion is controlled by one or more primary payers; (iv) users
commit transactions together in synchronous mode; (v) the
transaction system module sits in the e-commerce vendor tier;
and/or (vi) a transaction session is maintained in combined form,
independent of the mode or mechanism used by each participant.
[0079] Some embodiments of the present disclosure concentrate on
the technical aspects of split payments, and the process
participation mechanism in some embodiments allows for synchronous
payments, asynchronous payments or mixed synchronous/asynchronous
payments (as shown above in FIG. 4 and its related discussion).
[0080] Some embodiments of the present disclosure may include one,
or more, of the following features, characteristics and/or
advantages, in that they: (i) concentrate on the system and
mechanism for transaction management which actually works for split
payments in real world scenarios (especially cases where the cost
of a commodity changes dynamically); (ii) establish and maintain a
session; (iii) mainly include synchronous transaction processes;
(iv) mainly implement the process of synchronous split payment; (v)
include a mechanism for asynchronous payment and/or mixed type
payment; (vi) provide for synchronous payment (that is, committing
the payments of all the participants substantially together at
once); (vii) provide for asynchronous payment (that is,
participants can commit their payments over a long period, where
the cost of the commodity does not change dynamically); and/or
(viii) provide for mixed type transactions, where a particular
percentage of the total amount is committed synchronously and the
remaining amount can be committed asynchronously.
[0081] Some embodiments of the present invention may include one,
or more, of the following features characteristics and/or
advantages: (i) a method to split a payment transaction between
multiple related parties and synchronously execute it with a
financial entity; (ii) locking the transaction amount within the
session period; (iii) committing the payment and the commit of each
individual payment trigger managing a parent session committing the
payment synchronously; (iv) providing the user a mechanism to
accept the locking and increase the session time for
synchronization of the co-payers; (v) a mechanism of doing a split
transaction in real-time along with a mechanism which defines a
server architecture providing the infrastructure to maintain
prolonged live sessions and keep other participants in the
transaction synchronous; (vi) a mechanism of doing a split
transaction in real-time along with a mechanism which defines a
server architecture providing the infrastructure so that final
commitment can be issued by one of the payers; (vii) a mechanism of
doing a split transaction in real time along with a mechanism which
defines a server architecture providing the infrastructure so that
final commitment can be automated based on a vendor's preference;
(viii) a mechanism of doing a split transaction in real time along
with a mechanism which defines a server architecture providing the
infrastructure so that final commitment can be an automatic payment
or any specific policy; (ix) a co-browsing or co-editing system
where, during the transaction, multiple activities can be carried
out, like a mechanism to dynamically change the amounts in an
ongoing transaction; (x) maintaining a single "long-lived"
transaction within which multiple payment transactions are
accomplished; (xi) policy-driven split payment where policies can
be defined by vendors and primary participants; (xii) there is no
component in between vendor and payor(s); (xiii) there is no
intermediate entity which handles the committed payments from
participants; and/or (xiv) the machine logic can lie in a secure
and practical payment vendor module.
IV. Definitions
[0082] Present invention: should not be taken as an absolute
indication that the subject matter described by the term "present
invention" is covered by either the claims as they are filed, or by
the claims that may eventually issue after patent prosecution;
while the term "present invention" is used to help the reader to
get a general feel for which disclosures herein are believed as
maybe being new, this understanding, as indicated by use of the
term "present invention," is tentative and provisional and subject
to change over the course of patent prosecution as relevant
information is developed and as the claims are potentially
amended.
[0083] Embodiment: see definition of "present invention"
above--similar cautions apply to the term "embodiment."
[0084] and/or: inclusive or; for example, A, B "and/or" C means
that at least one of A or B or C is true and applicable.
[0085] User/subscriber: includes, but is not necessarily limited
to, the following: (i) a single individual human; (ii) an
artificial intelligence entity with sufficient intelligence to act
as a user or subscriber; and/or (iii) a group of related users or
subscribers.
[0086] Data communication: any sort of data communication scheme
now known or to be developed in the future, including wireless
communication, wired communication and communication routes that
have wireless and wired portions; data communication is not
necessarily limited to: (i) direct data communication; (ii)
indirect data communication; and/or (iii) data communication where
the format, packetization status, medium, encryption status and/or
protocol remains constant over the entire course of the data
communication.
[0087] Software storage device: any device (or set of devices)
capable of storing computer code in a manner less transient than a
signal in transit.
[0088] Tangible medium software storage device: any software
storage device (see definition, above) that stores the computer
code in and/or on a tangible medium.
[0089] Non-transitory software storage device: any software storage
device (see definition, above) that stores the computer code in a
non-transitory manner.
[0090] Computer: any device with significant data processing and/or
machine readable instruction reading capabilities including, but
not limited to: desktop computers, mainframe computers, laptop
computers, field-programmable gate array (fpga) based devices,
smart phones, personal digital assistants (PDAs), body-mounted or
inserted computers, embedded-device-style computers, and
application-specific integrated circuit (ASIC) based devices.
[0091] Financial institutions: include, but are not limited to,
banks, credit unions, credit card issuers, e-commerce financial
businesses, retailers with significant consumer financial
operations, utilities (for example telecommunications providers)
with significant consumer financial operations, brokerage houses,
insurance companies, financial transaction facilitators such as
payment clearing houses, governmental entities, and money lending
companies.
[0092] Between: between and/or among.
* * * * *