Note: Descriptions are shown in the official language in which they were submitted.
CA 02944267 2016-10-05
SYSTEMS AND METHODS FOR TIMING DATA TRANSFER
IN A DATABASE
FIELD
[0001] The present application generally relates to database management
and, more
particularly, to systems and methods for managing data transfer timing in a
database.
BACKGROUND
[0002] Databases are used for numerous purposes and, in some
instances, a database
is configured to allow for a transfer from one record in the database to
another record in that
database or another database. For example, a database may be configured such
that a value is
stored in a record and that value may be increased when a transfer from
another record (which
may be in the same database or another database) is received. Similarly, the
value may be
decreased by transferring a portion of the value to another record (which may
be in the same
database or another database). For example, the value may represent an account
balance and
the balance may be increased or decreased based on transfers into and out of
the account.
[0003] Accordingly, a value is sometimes transferred from one database
record to
another database record. Data transfers from the database may, however, occur
or be
configured to occur at undesirable times.
[0004] There is a need for improvements to existing database management
systems to
achieve improvements over convention databases and database management
systems.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] Reference will now be made, by way of example, to the
accompanying
drawings which show example embodiments of the present application, and in
which:
CA 02944267 2016-10-05
- 2 -
[0006] Figure 1 illustrates a block diagram of an example operating
environment of a
database management system in accordance with example embodiments of the
present
disclosure;
[0007] Figure 2 illustrates a block diagram of an example database and
an example
database management system in accordance with example embodiments of the
present
disclosure;
[0008] Figure 3 illustrates, in block form, example records of a
database in accordance
with example embodiments of the present disclosure;
[0009] Figure 4 illustrates an example data transfer schedule in
accordance with
example embodiments of the present disclosure;
[0010] Figure 5 is a flowchart of an example method of managing data
transfer timing
in accordance with example embodiments of the present disclosure;
[0011] Figure 6 is a flowchart of an example method of rescheduling a
data transfer in
accordance with example embodiments of the present disclosure; and
[0012] Figure 7 is a flowchart of an example method of managing a data
transfer
using a reserved account in accordance with example embodiments of the present
disclosure.
[0013] Similar reference numerals may have been used in different
figures to denote
similar components.
DESCRIPTION OF EXAMPLE EMBODIMENTS
[0014] The present application describes methods and systems for
managing data
transfer timing in a database.
[0015] In one aspect, the present application describes an electronic
system for
managing data transfer timing in a database. The electronic system includes a
communication
interface, a memory, and a processor coupled with the memory and the
communication
interface. The processor is programmed with processor-executable instructions
which, when
executed, configure the processor to: receive, via the communication
interface, a signal
CA 02944267 2016-10-05
- 3 -
representing an electronic message from a third party system, the electronic
message
notifying the electronic system of a first scheduled data transfer to a
database managed by the
electronic system and including value change information that affects a value
of the database,
the electronic message associated with a first transfer time in the future;
and in response to
receipt of the electronic message: i) evaluate a second scheduled data
transfer from the
database to a recipient at a second transfer time in the future at which at
least a portion of the
value is expected to be transferred to the recipient; and ii) reschedule the
second scheduled
data transfer when an effect on the value of the database by the second
scheduled data transfer
at the second transfer time meets defined criteria.
[0016] In another aspect, the present application describes a method for
managing
data transfer timing in a database. The method includes: receiving, at an
electronic system, a
signal representing an electronic message from a third party system, the
electronic message
notifying the electronic system of a first scheduled data transfer to a
database managed by the
electronic system and including value change information that affects a value
of the database,
the electronic message associated with a first transfer time in the future;
and in response to
receiving the electronic message: i) evaluating, by the electronic system, a
second scheduled
data transfer from the database to a recipient at a second transfer time in
the future at which at
least a portion of the value is expected to be transferred to the recipient;
and ii) rescheduling,
by the electronic system, the second scheduled data transfer when an effect on
the value of the
database by the second scheduled data transfer at the second transfer time
meets defined
criteria.
[00171 In a further aspect, the present application describes a non-
transitory
processor-readable medium storing processor-executable instructions for
managing data
transfer timing in a database. The processor-executable instructions, when
executed by a
processor, cause the processor to perform one or more of the described
methods. In this
respect, the term processor is intended to include all types of processing
circuits or chips
=
capable of executing program instructions, including a combination of chips or
processors.
That is, the term "processor" is intended to include a plurality of processors
coupled together.
[0018] Other aspects and features of the present application will be
understood by
those of ordinary skill in the art from a review of the following description
of examples in
conjunction with the accompanying figures.
CA 02944267 2016-10-05
- 4 -
[0019] In the present application, the term "and/or" is intended to
cover all possible
combinations and sub-combinations of the listed elements, including any one of
the listed
elements alone, any sub-combination, or all of the elements, and without
necessarily
excluding additional elements.
[0020] In the present application, the phrase "at least one of ...or..." is
intended to
cover any one or more of the listed elements, including any one of the listed
elements alone,
any sub-combination, or all of the elements, without necessarily excluding any
additional
elements, and without necessarily requiring all of the elements.
[0021] As will be explained in greater detail below, methods and
systems are
described for managing data transfer timing in a database. For example, the
methods and
systems may manage transfers from the database so that transfers occur at
times when the
transfer will not unduly impact a value in the database or will not violate a
transfer rule of the
database.
[0022] The database may, for example, be a database of account records
that store a
.. value associated with an account. The value may, for example, represent
credit, currency,
points, etc. The database may be configured to permit the value to be
increased by incoming
transfers into the account from another account (which may be another account
in the same
database or an account in another database).
[0023] For example, in an embodiment, the database may be a financial
database,
such as a banking database, which stores a plurality of records for banking
customers. That
is, the banking database stores account balances for various accounts
associated with
customers. The banking database accepts incoming transfers of value into the
accounts and
allows outgoing transfer of value from the accounts.
[0024] As will be described in greater detail below, management
systems are
described which facilitate the scheduling of outgoing data transfers from an
account. For
example, the system may schedule outgoing data transfers at times when such
data transfers
will not unduly impact the value of the account.
[0025] Reference is now made to Figure 1, which illustrates, in block
diagram form,
an example operating environment 100 of a database management system 110. The
database
management system 110 is an electronic system for managing data transfer
timing in a
CA 02944267 2016-10-05
- 5 -
database. More particularly, the database management system 110 manages data
transfer
timing in a first database 112. The database management system 110 is coupled
with the first
database 112 to allow the database management system 110 to access records of
the first
database 112. For example, the database management system 110 may retrieve
data in the
first database 112, such as one or more values associated with user records in
the first
database 112.
[0026] In at least some embodiments, the first database 112 is a
banking database.
The banking database stores account balances (i.e., bank account values) of
one or more bank
accounts. That is, the banking database stores a value indicative of an
account balance on a
per-account basis. In such embodiments, the database management system 110 may
be
referred to as a bank account management system.
[0027] The database management system 110 is operated or owned by the
same party
that operates the first database 112. For example, the database management
system 110 and
the first database 112 may both be operated by a common financial institution.
[0028] The database management system 110 may send and receive signals from
other systems or servers by way of a connection which, in the example, is made
through a
network 104. The network 104 may include public networks (e.g. the Internet),
private
networks, virtual private networks (VPNs), wired networks, wireless networks,
and
combinations thereof. At least some of the signals may represent electronic
messages.
[0029] A third party system 120 may send electronic messages to the
database
management system 110 through the network 104. The third party system 120 is a
distinct
system from the database management system 110 and is operated by a third
party. That is,
the third party system 120 is operated by a party that does not operate the
database
management system 110 or the first database 112. The third party system 120 is
associated
with a database which, in the illustrated embodiment, is a second database
122. More
particularly, the third party system 120 is associated with at least one
record in a database
(which may be either the second database 122 or the first database 112), such
as an account.
The third party system 120 is remotely located from the database management
system 110.
[0030] While the third party system 120 is associated with the second
database 122, it
may not operate the second database 122. Rather, the second database 122 may
be operated
by another party, such as a financial institution. The third party system 120
is associated with
CA 02944267 2016-10-05
- 6 -
the second database since it is associated with a record in that database.
More particularly,
the third party system 120 owns a value in the second database 122 (e.g., by
owning an
account) and/or has permission to transfer from a value in the second database
(e.g., to
transfer at least a portion of the value to another record in the second
database or in another
database, such as the first database 112). That is, the third party system 120
may affect a
value in the second database 122 by transferring at least a portion of the
value to another
record (e.g., another account) in the second database or in another database
but the third party
system 120 may not control or operate the second database itself. That is, the
third party
system 120 cannot control or manage other records not owned or associated with
the third
party that operates the third party system 120.
[0031] In one embodiment, the third party system 120 is a payroll
processing system.
The payroll processing system processes payment to primary payees, such as
employees,
contractors or others, by causing the second database 122 to transfer value
from an account
(which may be referred to as a "payroll processor account") associated with
the payroll
processing system to another account associated with the party being paid
(which may be
referred to as a "payee account"). The payroll processing system may also
automatically
handle remittance payroll deductions (which may be referred to as
"remittances"), such as
remittances to government organizations for tax (e.g., income tax), employment
insurance,
public pension plans, etc. The payroll processing system may automatically
calculate an
.. amount of remittances and may automatically transfer the amount of the
remittances to the
appropriate government organization by configuring a transfer of at least a
portion of a value
in the payroll processor account to the accounts associated with the
government
organization(s) to which the remittances are directed. The payroll processing
system may
also automatically calculate a net payment amount that is to be transferred to
the primary
payee (such as the employee, contractor, etc.) by determining the amount to be
paid after the
remittances and may automatically configure a data transfer from the payroll
processor
account to the payee account to occur on a payment date.
[0032] Thus, the third party system 120 may configure a transfer of
value from one
record in a database (e.g., the second database 122) to another record in a
database (e.g., the
first database 112). To configure the data transfer, the third party system
120 stores, in
memory, identification information for the record to which the transfer will
be made. For
example, the third party system 120 may store information identifying the
record that that has
CA 02944267 2016-10-05
- 7 -
a value that will be increased as a result of the data transfer. For example,
the third party
system 120 may store a record identifier that identifies a specific record
that the data transfer
is to be made into. The record identifier may be an account number into which
a transfer of
value is to be made (e.g., the account number of a primary payee). The record
identifier is
unique within a database.
[0033] The third party system 120 may also store a database identifier
that identifies a
specific database that the transfer is to be made into. The database
identifier uniquely
identifies the database that will receive a data transfer initiated by the
third party system 120
(e.g., the payroll processing system). For example, where payment is to be
made into the first
database 112, the third party system 120 includes information identifying the
first database
112. The database identifier may, for example, include an institution number
identifying an
institution (such as a financial institution) that operates the database.
[0034] The database identifier may be a Business Identifier Code such
as a Society for
Worldwide Interbank Financial Telecommunication (SWIFT) code which may adhere
to a
standard format, such as the International Organization for Standardization
(ISO) 9362
standard.
[0035] Prior to initiating a transfer of value from one record
controlled by the third
party system 120 to a record in the first database 112, the third party system
120 causes a
signal representing an electronic message to be transmitted to the database
management
system 110 associated with the record receiving the data transfer. The
electronic message
notifies the database management system 110 of a scheduled data transfer to
the first database
112. The electronic message may include information regarding the scheduled
data transfer.
For example, the electronic message may include a transfer time, value change
information,
and a record identifier. The record identifier identifies a specific record
into which the
transfer is to be made. For example, the record identifier may identify an
account into which
a transfer is to be made.
[0036] The transfer time indicates a time in the future when the
transfer is expected to
occur. For example, the transfer time may indicate a date at which the
transfer is scheduled to
occur. The transfer time is, in at least some embodiments, at least one day
away from the date
that the electronic message is sent to the database management system 110.
That is, in at least
some instances, the third party system 120 may notify the database management
system 110
CA 02944267 2016-10-05
- 8 -
of a scheduled data transfer at least one day before the date at which the
data transfer is
scheduled. Thus, at least some of the electronic messages sent from the third
party system
120 include a transfer time that is at least one day after the date the
electronic message is sent.
[0037] The value change information included in the electronic message
indicates an
amount by which a value, in the record specified by the record identifier, is
to be changed.
For example, the value change information may be a numerical value
representing a number
that is to be added to a present value in the record when the transfer occurs.
The number may
represent a number of dollars, points, etc. For example, the number may be a
decimal number
having two decimal places to represent a number of dollars and cents
associated with the data
transfer.
[0038] When the transfer between records occurs, the record into which
the transfer is
being made may be adjusted to increase a value by the amount specified in the
value change
information. Similarly, the record from which the transfer is being made may
be adjusted to
decrease a value by the amount specified in the value change information.
Thus, the transfer
is a zero-sum transfer in which the two records affected are adjusted by a
corresponding
amount.
[0039] While the first database 112 (i.e. the database into which a
transfer is received)
and the second database 122 (i.e. the database from which a transfer is sent)
are illustrated as
separate databases, they may be a common database in some embodiments. That
is, the third
party system 120 may rely on the same database (i.e., the first database 112)
that is managed
by the database management system 110. For example, where the third party
system 120 is a
payroll processing system and the database management system 110 and first
database 112
are operated by a financial institution, the payroll processing system may use
an account that
is operated by that same financial institution; that is, use an account/record
in the first
database 112.
[0040] Accordingly, a record in the first database 112 may be adjusted
when a transfer
from another record occurs. That is the value in the record in the first
database 112 may be
increased due to an incoming transfer. Similarly, the value in that same
record may be
decreased due to an outgoing transfer. For example, in some embodiments, the
value may be
decreased when a transfer is made from that record to another record,
associated with a =
CA 02944267 2016-10-05
- 9 -
recipient. The other record may be stored in a third database 132. However,
the record may
instead be stored in the first database 112 or the second database 122.
[0041] The recipient of the data transfer from the record in the first
database 112 may,
for example, be a service provider or other bill payee such as, for example, a
utility provider
(e.g., electricity, natural gas, water, sewage provider), a fitness center, an
investment account,
a telephone provider, a mobile network operator, an Internet provider, or a
provider of another
type. Transfers from the record to the recipient (i.e., to a record associated
with the recipient)
may be scheduled and may, for example, occur regularly. In some instances, a
transfer to a
particular recipient may occur at a defined period (e.g., monthly), and
transfers to that
recipient may be for a recurring or similar amount.
[0042] The database management system 110 may send electronic messages
to a
recipient system 130, which is associated with the recipient of a scheduled or
expected data
transfer, through the network 104. For example, as will be explained in
greater detail below
the database management system 110 manages the timing of a data transfer from
the first
database 112 into a record associated with the recipient system 130. If a
transfer is to occur
from the record in the first database 112 to another record (e.g., a record in
the third database
132), the database management system 110 automatically schedules or
reschedules the data
transfer to avoid or reduce the risk that the data transfer will unduly impact
a value in the
record in the first database 112 or violate a transfer rule of the first
database 112.
[0043] In some embodiments, prior to rescheduling the data transfer, the
database
management system 110 sends a reschedule request to the recipient system 130.
The request
may specify a transfer time for the data transfer from the record in the first
database 112 to the
recipient (i.e., to the other record, which may be in the third database). The
recipient system
130 receives this request, evaluates it based on predefined criteria, and
sends the database
management system 110 a response to the request. The response may be an
approval
message, approving the request or a denial message indicating that the request
has not been
approved.
[0044] When the database management system 110 receives the response,
it
reschedules the data transfer based on the response. For example, if the
response approves the
request, it may schedule the data transfer from the record in the first
database 112 to occur at
the transfer time specified in the message that was sent to the recipient
system 130.
CA 02944267 2016-10-05
- 10 -
[0045] Reference will now be made to Figure 2 which illustrates, in
block diagram
form, the first database 112 and the database management system 110. The
database
management system 110 includes at least one processor 224, memory 222 coupled
to the
processor 224 and a communication interface 226 coupled to the processor 224.
The
communication interface 226 may include subsystems for wired or wireless data
communication. The communication interface 226 allows the database management
system
110 to send and receive electronic messages. For example, the communication
interface 226
may allow electronic messages to be sent and received over the network 104
(FIG. 1).
[0046] The memory 222 may include volatile and non-volatile memory. At
least a part
of the memory 222 may store processor-readable instructions that, when
executed by the
processor, cause the processor 224 to carry out some of the operations
described herein.
[0047] The processor 224 is also coupled with the first database 112,
allowing the
processor 224 to retrieve values stored in records in the first database 112.
[0048] The database management system 110 includes other components
that are not
illustrated including, for example, a power source interface. The database
management
system 110 may also include an output interface such as display (not shown)
and/or an input
device (not shown) such as a keyboard or mouse.
[0049] Referring now to Figure 3, example records 302a, 302b in the
first database
112 (FIG. 1 and 2) are illustrated. The records 302a, 302b, in the example,
are defined on a
per-account basis, with a first record 302a being associated with a first
account and a second
record 302b being associated with a second account. Each record 302a, 302b
stores a
respective value 304a, 304b ¨ the first record 302a stores a first value 304a
and the second
record 302b stores a second value 304b.
[0050] While Figure 3 illustrates an embodiment in which each record
is associated
with a single account, in other embodiments, records may be defined on a per-
user or per-
customer basis so that a record may be associated with multiple accounts if a
the user
associated with that record is associated with multiple accounts. By way of
example, a record
may include a first value associated with a chequing account for a customer
and another value
associated with a savings account for that customer.
CA 02944267 2016-10-05
- 11 -
[0051] As noted in the discussion above, a database management system
110 is
configured to manage data transfer timing in the first database 112. For
example, the
database management system 110 may manage a schedule for data transfers from
the
database. Referring now to Figure 4, an example schedule 402 for data
transfers is illustrated.
In the example, the schedule 402 is defined on a per-account or per-record
basis. That is, the
schedule 402 is associated with a particular record and a particular account
and involves only
transfers from that account/record. However, in other embodiments, the
schedule 402 could
be defined on a per-user basis or could be defined globally for the database.
In such
embodiments, each entry 404, 406 in the schedule 402 specifies a transferor
identifier, such as
an account identifier, which uniquely identifies the transferor.
[0052] Each entry 404, 406 in the schedule 402 includes a transfer
time. The transfer
time is the time is the time at which the data transfer is scheduled to occur.
In the example, a
first entry 404 indicates a data transfer scheduled for January 1, 2017 and a
second entry 406
indicates a further data transfer scheduled for January 3, 2017.
[0053] The entries 404, 406 also include respective recipient identifiers,
uniquely
identifying a recipient of the data transfer. The recipient identifiers may,
for example, specify
a record identifier for the recipient, such as an account number, and a
database identifier for
the recipient, such as an institution number or SWIFT number.
[0054] The entries 404, 406 also include value change information
indicating an
amount by which a value in the recipient record will be changed due to the
data transfer. In
the example, the first entry 404 specifies value change information of
$120.00, indicating that
a value in a respective recipient's record will be increased by $120.00 while
the second entry
406 specifies value change information of $45.00, indicating that a value in
the respective
recipient's record will be increased by $45.00.
[0055] The schedule 402 may be stored in memory 222 (FIG. 2) associated
with the
database management system 110.
[0056] The schedule 402 may be defined, updated or modified based on
user input or
through automatic scheduling or rescheduling provided by the database
management system
110 itself. For example, the schedule 402 may, in some embodiments, be
modified or created
based on user input. A user associated with a record, such as an account
holder, may input a
command to schedule a data transfer from the record. By way of example, the
user may input
CA 02944267 2016-10-05
- 12 -
such a command through a web interface or through an application operating on
a device such
as a mobile application operating on a mobile device. The user may define an
amount
associated with the data transfer and a date for the data transfer. In
response to receiving this
user input, the schedule 402 may be created or updated to reflect the inputted
information. A
confirmation number for the transfer may also automatically be generated and
provided to the
user through a user interface through which the user input the command to
schedule the data
transfer.
[0057] The database management system 110 may itself create, add to,
or modify the
schedule 402. That is, the database management system 110 may adjust the
schedule without
direct user input. For example, the database management system 110 may select
a date for a
data transfer without direct user input specifying the date. Rather, as will
be described below,
the database management system 110 may select the date based, at least in
part, on timing
information specified in a received electronic message from a third party
system 120 (FIG. 1)
notifying the database management system 110 of an incoming data transfer to a
record
associated with the schedule 402.
[0058] In at least some embodiments, the database management system
110 may
automatically modify a user-created entry in the schedule 402 based on the
timing
information in the received electronic message from the third party system
120. For example,
if a user schedules a data transfer for a transfer time but, based on the
timing information in
the message received from the third party system 120, the database management
system 110
determines that that transfer time does not meet certain defined criteria,
then the database
management system 110 may reschedule the data transfer for another transfer
time. The
defined criteria may, for example, specify that a value in the record is not
to fall below a
certain threshold. For example, the defined criteria may specify that the
value in the record is
not to fall below zero. If the database management system 110 determines that
the user-
scheduled transfer time will cause the value to fall below the threshold, then
it may
automatically reschedule the data transfer.
[0059] Reference will now be made to Figure 5 which illustrates an
example
embodiment of a method 500 for managing data transfer timing in a database.
The method
500 may be performed by the database management system 110. For example, a
processor
224 (FIG. 2) associated with the database management system 110 may perform
the method
CA 02944267 2016-10-05
- 13 -
500. The processor may be programmed with processor-executable instructions
which, when
executed, configure the processor to perform the method 500.
[0060] At operation 502, the database management system 110 receives,
via the
communication interface 226 (FIG. 2), a signal representing an electronic
message. The
electronic message is sent from a third party system 120 (FIG. 1) and may be
received
through a network 104 (FIG. 1). The electronic message notifies the database
management
system 110 of a first scheduled data transfer to a database managed by the
database
management system 110; for example, the first database 112 illustrated in
Figure 1.
[0061] The electronic message received at the database management
system 110
includes value change information that affects a value in the database managed
by the
database management system 110. The electronic message is associated with a
first transfer
time, which is a time in the future at which the first scheduled data transfer
is expected to
occur. The first transfer time may be specified in the electronic message
itself or it may be
determined, by the database management system 110 based on a predefined time
period. The
predefined time period may, for example, define an amount of time that
typically elapses
between receipt of electronic messages of the type received in operation 502
and the
occurrence of the data transfer associated with such electronic messages. The
predefined time
may, for example, be determined based on historical time periods between such
electronic
messages and such data transfers. In some instances, the first transfer time
may be one or
more days away from the day the electronic message is received at operation
502.
[0062] The first transfer time may, in some embodiments, be specified
as a range of
times. For example, the first transfer time may specify a minimum expected
time at which the
data transfer is expected to occur and a maximum expected time at which the
data transfer is
expected to occur.
[0063] The value change information included in the electronic message
specifies an
amount associated with a data transfer. For example, the value change
information may be a
decimal number indicating an amount by which a value in the database will be
increased due
to the data transfer.
[0064] The electronic message may also include a record identifier
which uniquely
identifies, within the first database 112, a record which will be affected by
the data transfer.
=
CA 02944267 2016-10-05
- 14 -
That is, the record identifier identifies the record that will receive the
data transfer and whose
value will be increased.
[0065] As noted above, in some embodiments, the database management
system 110
may be operated by a financial institution which provides a first database 112
which is a
banking database. In such embodiments, the record identifier may be an account
identifier
such as an account number and the value change information may indicate the
amount of a
financial transfer such as the number of dollars and cents that will be
transferred into the
account represented by the account identifier. In some such embodiments, the
third party
system 120 may be a payroll processing system which processes a payment to the
account
associated with the account identifier. The payroll processing system may send
the electronic
message to the database management system 110 to provide the database
management system
110 with advance warning of a data transfer to an account in the database
management system
110.
[0066] In response to receipt of the electronic message, at operation
504, the database
management system 110 evaluates a second scheduled data transfer from the
first database
112 to a recipient. The second scheduled data transfer is an expected data
transfer at a second
transfer time in the future from the record associated with the record
identifier included in the
electronic message to a record associated with a recipient. More particularly,
at the second
transfer time, at least a portion of a value of the database is expected to be
transferred to a
record associated with the recipient. This record (i.e., the record to which
the second
scheduled data transfer is directed) may be referred to as a recipient record
or a recipient.
[0067] The first scheduled data transfer and the second scheduled data
transfer both
affect a common record (e.g., both affect a common account). However, the
first scheduled
data transfer represents an incoming transfer to the record while the second
scheduled data
transfer represents an outgoing transfer from the data record. Consequently,
the first
scheduled data transfer represents a data transfer that will increase the
value in the record
while the second scheduled data transfer represents a data transfer that will
decrease the value
in that record.
[0068] The second scheduled data transfer may be evaluated based on
defined criteria.
The defined criteria may, for example, specify that a value in the record is
not to fall below a
CA 02944267 2016-10-05
- 15 -
certain threshold, which may be referred to as a minimum value. The minimum
value may be
zero in some embodiments.
[0069] The database management system 110 may, at operation 504,
determine an
effect on the value in the record by the second scheduled data transfer at the
second transfer
time. For example, the database management system 110 may determine if the
second
scheduled data transfer is expected to cause the value to fall below the
threshold. In doing so,
the database management system 110 may also consider the effect of the first
scheduled data
transfer on the value. If the value is expected to drop below the threshold
due to the second
scheduled data transfer, then the defined criteria may be determined (at
operation 506) to be
met while if the value is not expected to drop below the threshold, then the
defined criteria
may be determined not to be met.
[0070] If, at operation 506, the database management system 110
determines that the
defined criteria is not met (e.g., if the value will not fall below the
minimum value as a result
of the second scheduled data transfer), then the database management system
110 may not
reschedule the data transfer. Thus, at operation 510, the second data transfer
occurs at the
second scheduled time. That is, the data transfer occurs at the time at which
it was previously
scheduled to occur.
[0071] If, however, at operation 506, the database management system
110
determines that the defined criteria is met (e.g., if the value will fall
below the minimum value
if the second scheduled data transfer were to occur as scheduled), then the
database
management system 110 may reschedule the second scheduled data transfer at
operation 508.
[0072] The second scheduled data transfer may be rescheduled, in at
least some
embodiments, by updating a schedule 402, such as a schedule 402 of the type
described above
with reference to Figure 4. The second scheduled data transfer may be
rescheduled to a third
transfer time which the database management system 110 selects based on
defined rules. For
example, the database management system 110 may select a third transfer time
which is later
than the second transfer time, so as to delay the data transfer. The database
management
system 110 may select the third transfer time based on the first transfer
time. That is, the
database management system 110 may select a third transfer time that is after
the first transfer
time. That is, it is after the transfer time when the incoming data transfer
to the record is
expected to occur. In some embodiments, the database management system 110 may
select
CA 02944267 2016-10-05
- 16 -
the third transfer time to be shortly after the first transfer time. For
example, in some
embodiments, the third transfer time may be selected to be within a day of the
first transfer
time. In some embodiments, the third transfer time may be selected to be
within a week of
the first transfer time.
[0073] Accordingly, in response to the receipt of the electronic message at
operation
502, the database management system 110 may automatically reschedule the
second
scheduled data transfer to a third transfer time.
[0074] As described above, in response to receiving notification of a
first scheduled
data transfer, the database management system 110 may evaluate a second
scheduled data
transfer to determine whether the second scheduled data transfer should be
rescheduled. The
second scheduled data transfer may be a data transfer that was previously
configured by a user
associated with a record, such as an owner of a bank balance represented by a
value in the
record. The second scheduled data transfer may be defined in a schedule 402
(FIG. 4) that
represents one or more data transfers previously configured by the user. In
such
.. embodiments, during operation 504, the database management system 110 may
retrieve the
schedule 402 to identify the second scheduled data transfer. Thus, the
database management
system 110 may evaluate data transfers that were previously configured by a
user directly.
[0075] In some embodiments, during the method 500 of Figure 5, the
database
management system 110 may consider a scheduled data transfer that has not been
defined in a
.. schedule, but which is nevertheless expected to occur. For example, the
database
management system 110 may identify data transfer trends to identify an
expected data
transfer. For example, the database management system 110 may be configured to
identify
expected data transfers based on historical data transfer logs for the
database. The historical
data transfer logs identify past data transfers from the record identified in
the electronic
.. message received at operation 502. The historical data transfer logs
specify prior transfer
times of data transfers from the database to recipients and associated
recipient information
and value information indicating an amount associated with the prior data
transfers. The
database management system 110 parses this information to identify an expected
future data
transfer. More particularly, the database management system 110 identifies an
expected
recipient of a future data transfer, an expected amount associated with that
data transfer and
also an expected transfer time associated with that data transfer. Thus, the
database
CA 02944267 2016-10-05
- 17 -
management system 110 may be configured to identify a second transfer time for
an expected
future data transfer. This identification is performed prior to evaluating the
second scheduled
data transfer at operation 504. Then, operation 504 may be performed based on
the identified
second transfer time and the expected amount, as determined from the
historical data transfer
logs.
[0076] By way of example, in some embodiments, the database management
system
110 may identify an expected day of the month for a data transfer to the
recipient based on
one or more previous days of prior months on which a transfer from the
database to that
recipient occurred. For example, where data transfers have historically
occurred on a
particular day of the month (e.g., on the 10th day of each month), the
database management
system 110 may determine that a data transfer to the recipient is likely to
occur on this date.
[0077] The expected amount associated with the second data transfer
may be
determined by the database management system 110 based on the amount in the
most recent
data transfer to the recipient of the second data transfer. For example, if
the most recent
amount was $45.00, then the database management system 110 may conclude that
the
expected amount of an expected data transfer is also $45. In other
embodiments, other criteria
may be used to determine the expected amount. For example, in some
embodiments, the
expected amount may be determined as the mean of the amounts of prior data
transfers to that
recipient. In some embodiments, the expected amount may be determined as a
trimmed mean
of the amounts of prior data transfers to that recipient.
[0078] In at least some embodiments, the database management system
110 may not
unilaterally reschedule the second data transfer at operation 508. Instead,
the database
management system 110 may seek approval from the recipient of that second data
transfer
prior to rescheduling. Referring now to Figure 6, an example of one such
embodiment is
illustrated. Figure 6 illustrates a flowchart of an example method 600 of
selectively
rescheduling a data transfer. The method 600 may be performed by the database
management
system 110 at operation 508 of the method 500 of Figure 5.
[0079] At operation 602, the database management system 110 sends a
reschedule
request to a system associated with the recipient of the second scheduled data
transfer. For
example, the database management system 110 may send a reschedule request to
the recipient
system 130 (FIG. 1) via a network 104. The reschedule request may include a
proposed
CA 02944267 2016-10-05
- 18 -
transfer time, which may be referred to as a third transfer time. The third
transfer time is later
than the second transfer time. That is, the third transfer time is later than
the transfer time at
which the second scheduled data transfer is currently expected to occur.
Techniques for
selecting the third transfer time are described above.
[0080] The recipient system 130 is configured to evaluate received
reschedule
requests based on predefined criteria and send the database management system
110 a
response to the request. The response may be an approval message, approving
the request or
a denial message indicating that the request has not been approved. This
denial message may
also be referred to as a denial of request message or a refusal.
[0081] The response to the reschedule request is received at the database
management
system 110 at operation 604 and is evaluated by the database management system
110 at
operation 606. More particularly, at operation 606, the database management
system 110
determines whether the request was approved or whether it was denied.
[0082] When the response indicates that the request was approved by
the recipient
system 130, the database management system 110 reschedules the data transfer
to the third
transfer time.
[0083] If, however, the response indicates that the request was denied
by the recipient
system 130, the database management system 110 does not reschedule the data
transfer to the
third transfer time. Rather, the database management system 110 schedules the
transfer to
occur at a time that is earlier than the third transfer time. For example, in
some embodiments,
the database management system 110 schedules the transfer to occur at the
second transfer
time and, at operation 610, the transfer occurs at this time.
[0084] In some embodiments, other actions may be taken in response to
receiving a
denial message. For example, in some embodiments, when the denial message is
received,
the database management system 110 may attempt to reschedule another scheduled
data
transfer from the database to a further recipient. This further scheduled data
transfer may be
referred to as a third scheduled data transfer. That is, the database
management system 110
may identify another outgoing data transfer from the same record to a
different recipient and
may follow the method 600 to attempt to attempt to reschedule this other
outgoing data
transfer.
CA 02944267 2016-10-05
- 19 -
[0085] While not illustrated in Figure 5 or Figure 6, in at least some
embodiments, the
database management system 110 may notify a user, such as an account-holder,
when data
transfers from a record associated with that user (e.g., from the user's
account) are
rescheduled or automatically scheduled by the databased management system 110.
Such
notification may occur by way of an electronic message, such as an email
message.
[0086] Reference will now be made to Figure 7 which illustrates an
example method
700 of managing a data transfer using a reserved account. The method 700 may
be performed
by the database management system 110. For example, a processor 224 (FIG. 2)
associated
with the database management system 110 may perform the method 700. The
processor may
be programmed with processor-executable instructions which, when executed,
configure the
processor to perform the method 700.
[0087] At operation 702, the database management system 110 detects an
incoming
transfer to a database. For example, the database management system 110 may
detect a first
scheduled data transfer to the database. More particularly, the database
management system
110 detects that a value of a record in the database has been increased as a
result of the first
scheduled data transfer. For example, the database management system 110 may
determine
that a value representing an account balance has increased through a data
transfer. The data
transfer may be a payroll data transfer processed by a payroll processing
system.
[0088] In response to detecting the first scheduled data transfer to
the database, the
database management system 110 determines, at operation 704, whether one or
more transfer
conditions are satisfied. For example, the database management system 110 may
determine
that an outgoing data transfer from the record is scheduled within a defined
time period
following the transfer that was detected in operation 702. For example, in one
embodiment,
the database management system 110 may determine that a scheduled data
transfer is to occur
within 2 weeks. In some embodiments, the time period that is used in operation
704 may
depend upon a period of incoming data transfers for the account. For example,
the time
period may depend on a pay period which is the amount of time between payroll
payments.
In such embodiments, at operation 704, the database management system 110
determines
whether an outgoing data transfer is to occur before an expected next pay
date.
[0089] Thus, in at least some embodiments, at operation 704, the database
management system 110 identifies scheduled data transfers within a certain
time period. The
CA 02944267 2016-10-05
- 20 -
identification of data transfers may be in the manner described above with
reference to Figure
5. For example, in some embodiments, a schedule 402 may be consulted and, in
some
embodiments, the database management system 110 may identify expected data
transfers
based on historical information regarding past data transfers.
[0090] If the transfer condition(s) are satisfied (e.g., if an outgoing
data transfer is to
occur during the defined time period), then the database management system 110
may, at
operation 706, automatically transfer at least a portion of the value in the
record to a reserved
portion of the database, such as a reserved account. The reserved account may
be a restricted
access account which has greater restrictions than an account into which the
incoming data
transfer was received. The reserved account may, for example, only permit its
value to be
used for certain defined purposes. For example, the reserved account may only
permit data
transfers to recipients of scheduled data transfers. In some embodiments, the
reserved
account may only permit outgoing data transfers for payment of bills. Data
transfers for other
purposes may be restricted.
[0091] The amount that is transferred to the reserved account at operation
706 may be
an amount that is equal to the total outgoing data transfers during the
defined time period used
in the evaluation at operation 704. For example, if the time period is based
on a pay period of
one month, an amount sufficient to cover expected outgoing payments during
that pay period
may be transferred to the reserved account. If a transfer to a recipient is
expected to occur
during the time period, then the portion of the value that is expected to be
transferred to the
recipient is transferred at operation 706 to the reserved account.
[0092] After an amount is transferred to the reserved account, at
operation 708,
transfers may be made from that reserved account at the scheduled times.
[0093] The present application is not limited to particular
processors, computer
languages, computer programming conventions, data structures, other such
implementation
details. Those skilled in the art will recognize that the described processes
may be
implemented as a part of computer-executable code stored in volatile or non-
volatile memory,
as part of an application-specific integrated chip (ASIC), etc.
[0094] Certain adaptations and modifications of the described
embodiments can be
made. Therefore, the above discussed embodiments are considered to be
illustrative and not
restrictive.
