Language selection

Search

Patent 2497243 Summary

Third-party information liability

Some of the information on this Web page has been provided by external sources. The Government of Canada is not responsible for the accuracy, reliability or currency of the information supplied by external sources. Users wishing to rely upon this information should consult directly with the source of the information. Content provided by external sources is not subject to official languages, privacy and accessibility requirements.

Claims and Abstract availability

Any discrepancies in the text and image of the Claims and Abstract are due to differing posting times. Text of the Claims and Abstract are posted:

  • At the time the application is open to public inspection;
  • At the time of issue of the patent (grant).
(12) Patent: (11) CA 2497243
(54) English Title: METHOD, SYSTEM AND SOFTWARE APPLICATION FOR REAL TIME DATA PROCESSING
(54) French Title: METHODE, SYSTEME ET APPLICATION LOGICIELLE PERMETTANT LE TRAITEMENT DES DONNEES EN TEMPS REEL
Status: Granted and Issued
Bibliographic Data
(51) International Patent Classification (IPC):
  • G06F 09/52 (2006.01)
(72) Inventors :
  • RAPP, ROMAN (France)
(73) Owners :
  • SAP SE
(71) Applicants :
  • SAP SE (Germany)
(74) Agent: GOWLING WLG (CANADA) LLP
(74) Associate agent:
(45) Issued: 2008-02-05
(22) Filed Date: 2005-02-14
(41) Open to Public Inspection: 2005-08-19
Examination requested: 2005-02-14
Availability of licence: N/A
Dedicated to the Public: N/A
(25) Language of filing: English

Patent Cooperation Treaty (PCT): No

(30) Application Priority Data:
Application No. Country/Territory Date
04003607.2 (European Patent Office (EPO)) 2004-02-19

Abstracts

English Abstract

The Invention relates to a method for locking data objects in a computer system, the method comprising a first processing module requesting a lock service module to lock one or more (n) data objects for access for further data processing modules by creating one or more lock objects for the one or more data objects, said method further comprising: - the lock service receiving names of one or more (m) key fields of the one or more data objects to be locked; - the lock service receiving n values for each of the m key fields of n data objects to locked; - the lock service receiving a maximum number (k) of locks to lock the n data objects; - the lock service checking whether n < =k and in case yes, creating one or more lock objects comprising the m names and n values for the m key fields in case no, querying the n values of the m key fields and determining numbers (yl to ym) of different values (Val_1.1 to Val_m.ym) of the key fields 1 to m; - the lock service determining consecutively from a first to i-th field where i < =m until yl*...*yi > = k and in case the condition is satisfied, - creating one or more lock objects comprising the names of the key fields 1 to m and values Val_1.1 to Val_(i-1).y(i-1) for the key fields 1 to i-l and comprising wildcards for the remaining key fields.


French Abstract

L'invention concerne une méthode pour verrouiller des objets de données dans un système informatique, le procédé comprenant un premier module de traitement demandant à un module de service de verrouillage de verrouiller un ou plusieurs objets de données (n) pour l'accès par des modules de traitement de données supplémentaires en créant un ou plusieurs objets de verrouillage pour le ou les objets de données, ladite méthode comprenant en outre : - la réception par le service de verrouillage des noms pour un ou plusieurs (m) champs clés du ou des objets de données à être verrouillés; - la réception par le verrouillage de réception des n valeurs pour chacun des m champs clés des n objets de données verrouillés, - la réception par le service de verrouillage d'un nombre maximal (k) de verrous pour verrouiller les n objets de données; - la vérification par le service de verrouillage si n <= k, et si c'est le cas, la création d'un ou de plusieurs objets de verrouillage comprenant les m noms et les n valeurs pour les m champs clés, et si ce n'est pas le cas, l'interrogation des n valeurs des m champs clés et la détermination des numéros (yl à ym) de valeurs différentes (Val_1.1 à Val_m.ym) des champs clés 1 à m; - la détermination consécutive par le service de verrouillage du champ 1 à i où i <= m jusqu'à yl*... *yi> = k, et si la condition est satisfaite, - la création d'un ou de plusieurs objets de verrouillage, comprenant les noms des champs clés 1 à m et les valeurs Val_1.1 à Val_(i-1).y(i-1) pour les champs clés 1 à i-l et comprenant des caractères de remplacement pour les champs clés restants.

Claims

Note: Claims are shown in the official language in which they were submitted.


-21-
CLAIMS
What is claimed is:
1. A method for locking data objects in a computer system
(101), the method comprising a lock service module (113,
205) receiving from a first processing module (114, 201) a
request to lock one or more (n) data objects for access for
further data processing modules (115) by creating one or
more lock objects (116, 206) for the one or more data
objects, said method further comprising:
- the lock service (113, 205) receiving names (205) of one
or more (m) key fields of the one or more data objects to be
locked;
- the lock service (113, 205) receiving n values (203) for
each of the m key fields of n data objects to locked;
- the lock service (113, 205) receiving a maximum number (k)
(204) of locks to lock the n data objects;
- the lock service checking whether n < =k and
in case yes,
creating one or more lock objects (116, 206)
comprising the m names and n values for the m key fields
in case no,
querying the n values of the m key fields and
determining numbers (yl to ym) of different values
(Val_1.1 to Val m.ym) of the key fields l to m;
- the lock service (113, 205) determining consecutively from
a first to i-th field where i < =m until yl*...*yi > = k and in
case the condition is satisfied,
- creating one or more lock objects (116, 206) comprising
the names of the key fields 1 to m and values Val_1.1 to
Val_(i-1).y(i-1) for the key fields l to m and comprising
wildcards for the remaining key fields.
2. The method of claim 1, further comprising:
determining one or more common characteristics of different
values of a key field for the remaining key fields and

-22-
writing the determined common characteristics and one or
more wildcards into the remaining key fields of the or each
lock object (116, 206).
3. A computer system (101) comprising a lock mechanism for
locking data objects, the lock mechanism comprising a lock
service module (113) capable of receiving a lock request
from a first processing module (114) to lock one or more (n)
data objects for access for further data processing modules
(115) by creating one or more lock objects (116) for the one
or more data objects, comprising:
- memory (108) having program instructions;
- input means (109, 103) for receiving and entering data;
- output means (109, 104) for sending and presenting data
- storage means (107) for storing data;
- a processor (105) responsive to the program instructions;
said program instructions comprising program code means
for performing a method according to any of claims 1 to 2
when the program instructions are loaded into the memory and
executed by the processor.
4. A computer readable medium comprising program instructions
for locking data objects in a computer system, the program
instructions comprising instructions for:
performing a method according to any of claims 1 or 2 when
the program instructions are executed in the computer
system.
5. A computer program product comprising a computer readable
medium according to claim 4.

Description

Note: Descriptions are shown in the official language in which they were submitted.


CA 02497243 2005-02-14
- 1 - 2004P00103 EPO1
TITLE
Method, System and Software Application for Real Time Data
Processing
DESCRIPTION OF THE INVENTION
Field of the Invention
The technical field of this invention is in the area of
electronic data processing. More particularly, the invention
relates to methods, computer program products and systems for
data locking.
Background of the Invention
A data base management system is usually equipped with a special
lock mechanism that synchronizes access to data on the database.
The purpose of the lock mechanism is to prevent two transactions
from changing the same data on the database simultaneously.
Locks may be defined generically as "lock objects". A lock entry
is a specific instance of a lock object and locks a certain
database object, such as a correction or a table entry or a file
or a whole table.
Locks are usually set and deleted automatically when user
programs access a data object and release it again.
When interactive transactions are programmed, locks may be set
and released by calling specific function modules.
The tables in which data records should be locked with a lock
entry are defined in a lock object together with their key
fields. When tables are selected, one table (the primary table)
is first selected. Further tables (secondary tables) can also be
added using foreign key relationships.
The lock argument of a table in the lock object consists of the
key fields of the table.
The lock argument fields of a lock object may be used as input
parameters in the function modules for setting and removing

CA 02497243 2005-02-14
- 2 - 2004P00103 EP01
locks generated from the lock object definition. When these
function modules are called, the table entries to be locked or
unlocked are specified by defining certain values in these
fields. These values can also be generic or wildcards. The lock
argument fields therefore define which subset of the table
entries should be locked.
A simple case of a lock object consists of exactly one table and
the lock argument of the table is the primary key of this table.
Several tables can also be included in a lock object. A lock
entry therefore can lock an entire logical object, and not only
a record of a table. Such a logical object can be for example a
document comprising an entry in a header table and N entries in
a position table.
Further, a lock mode may be assigned for each table in the lock
object. This mode defines how other users can access a locked
record of the table.
The lock mode controls whether several users can access data
records at the same time. The lock mode can be assigned
separately for each table in the lock object. When the lock is
set, the corresponding lock entry is stored in the lock table of
the system for each table.
Access by more than one user can be synchronized in the
following ways:
Exclusive lock: The locked data can only be displayed or edited
by a single user. A request for another exclusive lock or for a
shared lock is rejected..
Shared lock: More than one user can access the locked data at
the same time in display mode. A request for another shared lock
is accepted, even if it comes from another user. An exclusive
lock is rejected.
Exclusive but not cumulative: Exclusive locks can be requested
several times from the same transaction and are processed
successively. In contrast, exclusive but not cumulative locks
can be called only once from the same transaction. All other
lock requests are rejected.

CA 02497243 2005-02-14
- 3 - 2004P00103 EPO1
It is possible to synchronize access by several programs to the
same data with a logical lock mechanism having two main
functions: A program can tell other programs which data records
it is just reading or changing. A program can prevent itself
from reading data that is just being changed by another program.
Data records of a table to be locked may also be defined by a
logical condition. When a lock is set, this logical condition is
entered in a lock table. This entry is retained until it is
removed by the program or the program comes to an end. All the
locks set by a program are thus removed at the end of the
program.
When accessing data records, the records just being edited by
other programs may be identified by the entry in the lock table.
Such an entry for the lock may define a number of fully
specified key fields. That is either a value is passed for the
key field or this field is locked generically by means of a
wildcard.
In a multi-user system environment as is frequently the case in
enterprise business software and computer systems, data that is
being processed by one user has to be locked, so that no second
user can change it at the same time. This is essential to avoid
data inconsistencies.
Usually, the data is being locked via the key of the processed
data (e. g. document number, cost centre id). However, business
transactions that process a lot of data at the same time (e. g.
the costing of a car with several thousand components or the
evaluation of a value flow net between many cost centres,
activities and cost objects) can not lock every single piece of
data via its key, since the number of locks that can be set is
restricted because of limited hardware resources. For instance,
a reasonable number of locks per transaction may be around 50
for larger mufti user systems. Anything more could harm the
performance of the system. This is especially true, if several

CA 02497243 2005-02-14
- 4 - 2004P00103 EPO1
hundreds or thousands of users work at the same time setting
locks in the system.
Thus, the mentioned mass transactions can not lock every single
piece of data (e. g. every product number or cost centre ID).
Instead wildcards are being used in a lock entry so that it
affects several single keys and many pieces of data can be
locked via one entry. Document US 6,047,283 discloses such a
lock mechanism in which a dynamic lock table is used for
managing the collision of lock requests of several users
ZO accessing a database, e.g. by means of wildcards.
But the wildcards have to be used with care. Otherwise too much
data is being locked and other users can't continue with their
tasks, since they can't access needed data. E.g. during the
calculation of a product with 100 sub-products, one can not lock
all products by only having wildcard in the lock entry for
product, otherwise not second user could run a costing of an
independent product.
Thus, there is a need for a method, software application and/or
data processing system providing a more efficient solution of at
least a part of the problems described above; particularly it is
desirable to provide a software application having a mechanism
for using wildcards in data locking more efficiently.
The above description is based on the knowledge of the present
inventors and not necessarily that known in the art.
SUMMARY OF THE INVENTION
In accordance with the invention, as embodied and broadly
described herein, methods and systems consistent with the
principles in this specification provide a method for locking
data objects in a computer system, the method comprising a lock
service module receiving from a first processing module a
request to lock one or more (n) data objects for access for

CA 02497243 2005-02-14
- 5 - 2004P00103 EP01
further data processing modules by creating one or more lock
objects for the one or more data objects, said method further
comprising:
- the lock service receiving names of one or more (m) key fields
of the one or more data objects to be locked;
- the lock service receiving n values for each of the m key
fields of n data objects to locked;
- the lock service receiving a maximum number (k) of locks to
lock the n data objects;
- the lock service checking whether n <=k and
in case yes,
creating one or more lock objects comprising the
m
names and n values for the m key fields
in case no,
querying the n values of the m key fields and
determining numbers (yl to ym) of different values
(Val-1.1 to Val m.ym) of the key fields 1 to m;
- the lock service determining consecutively from a first to i-
th field where i <=m until yl*...*yi >= k and in case the
condition is satisfied,
- creating one or more lock objects comprising the names of the
key fields 1 to m and values Val_1.1 to Val_(i-1).y(i-1) for the
key fields 1 to i-1 and comprising wildcards for the remaining
key fields.
The data objects are then locked according to the created lock
objects. The method can be used to optimize the locks in a
generic way and thus replace existing ones, what results in a
better maintainability of the system.
Embodiments of the invention are further directed to a computer
system, a computer program, a computer readable medium and a
carrier signal, each comprising program code or instructions of
locking data sets in a computer system according to the above
method and its embodiments.

CA 02497243 2005-02-14
- 6 - 2004P00103 EPO1
Such computer program can be installed as one or more programs
or program modules on different hardware systems (computers or
computer systems), and run separately and independently of each
other, in their entirety being capable of performing the
inventive method and its embodiments. The different systems may
be connected in the form of a network to communicate with each
other.
Additional objects and advantages of the various embodiments of
the invention will be set forth in part in the description, or
may be learned by practice of the invention. The objects and
advantages of the embodiments of the invention will be realized
and attained by means of the elements and combinations
particularly pointed out in the appended claims. Embodiments of
the invention are disclosed in the detailed description section
and in the appended independent and dependent claims.
The various embodiments can include and/or exclude different
aspects, features and/or advantages, where applicable. In
addition, various embodiments can combine one or more aspects or
features of other embodiments, where applicable.
It is understood that both the foregoing general description and
the following detailed description are exemplary and explanatory
only and are not restrictive of the embodiments of the
invention, as claimed. The description of aspects, features
and/or advantages of particular embodiments should not be
construed as limiting other embodiments or the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and
constitute a part of this specification, illustrate embodiments
of the invention and, together with the description, explain the
principles of the invention. In the drawings,

CA 02497243 2005-02-14
- 7 - 2004P00103 EP01
Fig. 1 is a block diagrams for illustrating an implementation of
the claimed method by means of a computer system;
Fig. 2 shows for illustration an example of possible
interactions between program modules and data according to an
embodiment the invention by means of a block diagram;
Fig. 3 is an exemplary flow diagram for illustrating an example
of the method according to the principles described in this
disclosure.
DESCRIPTION OF THE EMBODIMENTS
Within the concept of this specification, the terms used shall
have their usual meaning in the context of the field of data
processing unless defined otherwise. Particularly, a computer
system broadly refers to any stand alone computer such as a PC
or a laptop or a series of computers connected via a network,
e.g. a network within a company, or a series of computers
connected via the Internet. Computer systems and programs may be
closely related. As used herein, phrases, such as "the computer
provides" and "the program provides or performs specific
actions", "a user performs a specific action" are used to
express actions by a computer system that may be controlled by a
program or to express that the program or program module may be
designed to enable the computer system to perform the specific
action or to enable a user to perform the specific action by
means of a computer system.
In this context, the term "automatically" is not intended to
exclude a user's interactions with the computer system in the
course of processing.
The disclosed methods as described in the summary section may be
implemented by means of a computer system and a computer
software, which allows the creation of business software

CA 02497243 2005-02-14
- 8 - 2004P00103 EP01
applications and which allows the use of data bases or database
applications and Internet applications. Particularly, a lock
object may be implemented as on or more lines of one or more
tables in a data base, preferably in a relational data base. In
object oriented programming languages, a lock object may be
implemented as an instance of a class. The term data object
broadly refers to any data in a data base, which is identified
by a key.
An embodiment of the inventive method as described in the
summary section is characterized in that the method further
comprises determining one or more common characteristics of
different values of a key field for the remaining key fields and
writing the determined common characteristics and one or more
wildcards into the remaining key fields of the or each lock
object. A common characteristics may be a character string
consisting of one or more consecutive characters of the
characters forming the value. For example, in values like
A1BC123, A2BC234, "A" and "BC" are common characteristics. Thus,
A3BC345 may be replaced by A?BC*. In this case "?" is a wildcard
for a single character, "*" is a wildcard for any number of
characters.
Processors suitable for the execution of a computer program
include, by way of example, both general and special purpose
microprocessors, and any one or more processors of any kind of
digital computer. Generally, a processor will receive
instructions and data from a read-only memory or a random access
memory or both. The essential elements of a computer are a
processor for executing instructions and one or more memory
devices for storing instructions and data. Generally, a computer
will also include, or be operatively coupled to receive data
from or transfer data to, or both, one or more mass storage
devices (storage means) for storing data, e.g., magnetic,
magneto-optical disks, or optical disks. Information carriers

CA 02497243 2005-02-14
- 9 - 2004P00103 EPO1
suitable for embodying computer program instructions and data
include all forms of non-volatile memory, including by way of
example semiconductor memory devices, such as EPROM, EEPROM, and
flash memory devices; magnetic disks such as internal hard disks
and removable disks; magneto-optical disks; and CD-ROM and DVD-
ROM disks. The processor and the memory can be supplemented by,
or incorporated in, ASICs (application-specific integrated
circuits).
To provide for interaction with a user, the invention can be
implemented on a computer system having a display device such as
a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
for displaying information to the user and a keyboard and a
pointing device such as a mouse or a trackball by which the user
can provide input to the computer. Other kinds of devices can be
used to provide for interaction with a user as well; for
example, feedback provided to the user can be any form of
sensory feedback, such as visual feedback, auditory feedback, or
haptic feedback; and input from the user can be received in any
form, including acoustic, speech, or haptic input.
FIGURES
Reference will now be made in detail to the principles of the
invention and its embodiments by an explanation on the basis of
a data processing process, examples of which are illustrated in
the accompanying drawings
Referring now to FIG. 1, a computer system 101 comprising
computer 102 and operating means 103, 104, in accordance with a
preferred embodiment of the present invention is illustrated.
Those skilled in the art will appreciate that the method and
apparatus of the present invention apply equally to any computer
syst~n, regardless of whether the computer system is a
complicated multi-user computing apparatus or a single user

CA 02497243 2005-02-14
- 10 - 2004P00103 EPO1
device such as a personal computer or workstation. Computer 102
suitably comprises a processor 105, main memory 108, a memory
controller 106, an auxiliary storage interface 112c, a general
input/output interface 112b and a ternninal interface 112a, all of
which are interconnected via a system bus 114. Note that various
modifications, additions, or deletions may be made to computer
syst~n 101 illustrated in FIG. 1 within the scope of the present
invention such as the addition of cache memory or other
peripheral devices. FIG. 1 is presented to simply illustrate some
of the salient features of computer system 101.
Processor 105 performs computation and control functions of
computer system 101, and comprises a suitable central processing
unit (CPU). Processor 105 may comprise a single integrated
circuit, such as a microprocessor, or may comprise any suitable
number of integrated circuit devices and/or circuit boards
working in cooperation to accomplish the functions of a
processor. Processor 105 may suitably execute (object-oriented)
computer programs within main memory 108.
Auxiliary storage interface 112c allows computer system 101 to
store and retrieve information from auxiliary storage devices,
such as magnetic disk (e.g., hard disks or floppy diskettes) or
optical storage devices (e. g., CD-RBI). One suitable storage
device is a direct access storage device (DASD) 107. As shown
in FIG. 1, DASD 107 may be a hard disk drive which may read
programs and data from a hard disk. It is important to note that
while the present invention has been (and will continue to be)
described in the context of a fully functional computer system,
those skilled in the art will appreciate that the mechanisms
of the present invention are capable of being distributed as a
program product in a variety of forms, and that the present
invention applies equally regardless of the particular type of
signal be ari ng medi a t o ac tua l ly car ry out the di str ibut ion .
Further examples of signal bearing media include: recordable
type media such as floppy disks and CD ROMS, and transmission
type media such as digital and analogous communication links,
including wireless communication links.

CA 02497243 2005-02-14
- 11 - 2004P00103 EPO1
Memory controller 106, through use of a processor is responsible
for moving requested information from main memory 108 and/or
through auxiliary storage interface 112c to processor 105.
While fo r the purposes of explanation, memory controller 106 is
shown as a separate entity. Those skilled in the art understand
that, in practice, portions of the function provided by memory
controller 106 may actually reside in the circuitry associated
with processor 105, main memory 108, and/or auxiliary storage
interface 112c.
Terminal interface 112a allows system administrators and
computer programmers to communicate with computer system 101,
normally through monitor 104, keyboard 103, mouse, trackball and
the like or through programmable workstations. Although the
system 101 depicted in FIG. 1 contains only a single main
processor 105 and a single system bus 114, it should be
understood that the present invention applie s equally to
computer systems having multiple processors and multiple system
buses. Similarly, although the system bus 114 of the p referred
embodiment is a typical hardwired, multidrop bus, any
connection means that supports directional communication in a
computer-related environment could be used.
Input/output interface 112b allows computer system 101 via
processor 105 to communicate with general input/output means
109, including a net connection 110, for sending and/or
receiving data, e.g. for a net connection with one or more
further computer systems 111, or for sending or receiving of
data to or from other parties. A plurality of computer systems
like computer system 101, can be connected via the net
connection 110 in the form of a network. In such a case, the
network computers 111 can be used as further input/output means,
including the use as further storage locations.
In the preferred embodiment, memory 108 suitably includes an
operating system, programs and data, particularly a lock service
module 113 (lock service), a first processing module 114, a
further processing module 115 and a lock object 116 for locking
data objects in a database 117 available in DASD storage 107.

CA 02497243 2005-02-14
- 12 - 2004P00103 EPO1
It should be understood that for purposes of this application,
in memory 108 is used in its broadest sense, and can include
Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash
memory, cache memory, etc. While not explicitly shown in FIG. 1,
memory 108 may be a single type of memory canponent or may be
composed of many different types of memory components. For
example, memory 108 and CPU 105 may be distributed across several
different computers that collectively comprise system 101. It
should also be understood that programs in m~nory 108 can include
any and all forms of computer programs, including source code,
intermediate code, machine code, and any other representation of
a computer program.
The c~erating system provides the basic functionality that
controls the computer system 101. Operating system can comprise
any suitable operating system, such as IBM's OS/400, OS/2,
Microsoft's Windows, Java and the various flavours of UNIX. The
database 117 provides the mechanism for persistently storing
object data in the computer system 101, and can be any suitable,
preferably relational database such as those available from IBM,
Oracle or Microsoft.
Those skilled in the art will appreciate that more than one of
the mentioned processors may work in parallel in a computer
system.
Referring now to figure 2, a further preferred embodiment of the
invention is illustrated by a first processing module 201, a
lock service 205 and a lock object 206 located in a main memory
of a computer system like the one shown in Fig. 1. Before
accessing one or more data objects in a database, processing
module 201 passes the names of m key fields 202 of the n data
objects to be locked, a table 203 of the values of the key
fields for the n data objects to be locked and a number 204 of
the maximum number of locks (here k) to the lock service 205.
Thereby, the names of the key fields have to be in an order,
which fits to the structure of the data base and the data

CA 02497243 2005-02-14
- 13 - 2004P00103 EPO1
objects to be locked. After processing the received data, lock
service 205 generates a lock object 206 having x <= k entries
for the n data objects. The entries comprise values for the x*m
key fields that are used to lock the n data objects. If n is
smaller or equal than k, a table (lock object) is returned,
which comprises the n*m values of the n*m key fields, since the
number of data keys does not exceed the possible number of locks
and all data objects can be locked with their full key.
Otherwise, if n greater than k, wildcards are used to lock
several values for one key field at once. To determine where to
use the wildcards, the lock service 205 may use a heuristic
method to optimise the locks. According to such a heuristic
method, lock service 205 may first collect all values that
appear per key field. This may be implemented by means of a
table as shown by table 1:
Tab. 1: Internal table of key field values
Key Field number of Value
different
values
Field 1 Y1 Val 1.1
Val l.yl
Field m ym Val m.l
Val m.ym-
The first column contains the names of the key fields 1 to m.
The second column contains a number yl to ym of different values
contained in the respective key field. The third column
contains the different values val 1.1 to val m.ym of the key
fields 1 to m. Therefore, a field per key field is subdivided
into a number of ym sub fields for a field m. The lock service

CA 02497243 2005-02-14
- 14 - 2004POOI03 EPO1
205 may then loop over the key fields and check, whether the
number yi (i->1 to m) of different values is smaller than k. If
yes, all the values for this key can be locked, if not, all key
values are locked per wildcard. The method continues that way
with the next key field considering, that the number of created
lock entries is the product of the number of values per key
field, which must not exceed k (k<=yl*...*ym).
In a preferred embodiment, table 1 may be sorted according to
ascending or descending values yi before the loop described
above is performed.
The following tables shows by way of non- limiting example how a
lock object could look like. The example consists of a table 2
defining m=3 key fields 1 to 3, .a table 3 defining keys of n=18
data objects to be locked and a maximum number of k=10 locks.
Tab. 2: Names of key fields
Field no Name
1 Controlling Area
2 Activity
3 Branch

CA 02497243 2005-02-14
- 15 - 2004P00103 EPO1
Tab. 3: Keys of data obiects to be locked
Controlling Activity Branch
Area
1000 Open Account A1
1000 Open Account A2
1000 Open Account A3
1000 Open Account A4
1000 Open Account A5
1000 Open Account A6
1000 Open Account A7
1000 Open Account A8
1000 Open Account A9
1000 Close Account A1
1000 Close Account A2
1000 Close Account A3
1000 Close Account A4
1000 Close Account A5
1000 Close Account A6
1000 Close Account A7
1000 Close Account A8
1000 Close Account A9
These data are passed to the lock service 205 by processing
module 201. After receipt, lock service 205 creates an internal
table (table 4 in the example) in order to determine a balanced
number of locks containing wildcards.

CA 02497243 2005-02-14
- 16 - 2004P00103 EP01
Tab. 4: Internal table of key field values
Key Field Number of Value
different
values
Controlling 1 1000
Area
Activity 2 Open Account
Close Account
Branch 9 A1
A2
A3
A4
A5
A6
A7
A8
A9
Look service 205 then checks, whether n is smaller or equal than
k. Since this is not the case in the example, lock service 205
loops over table 4 starting with field 1: The number of values
for that field is smaller than 10 and therefore, all values for
that field can be locked. Continuing with field 2, lock service
205 calculates the maximum number of lock entries for fields 1
and 2, which is 2, what is still smaller than 10 and therefore,
all values for fields 1 and 2 can be locked. Continuing with
field 3, the analogous calculation yields a maximum number of 18
lock entries, what is greater than 10, and therefore, the values
for field 3 can not be locked and are replaced by wildcards.
Consequently, lock service 205 creates a lock object having to
entries. This can be seen in table 5: the lock object comprises
a table with a column for each key field. The values of key
fields 1 and 2 are entered in the respective fields, whereas the

CA 02497243 2005-02-14
- 17 - 2004P00103 EPO1
values of the key field 3 is replaced by a wildcard (**). As
result, the 18 data objects in the database represented by the
keys in table 3, are locked with a lock object having two
entries. Thus, the activities open/close account would be
locked in controlling area 1000 for all branches. If a second
process should try to get access to data objects with those
activities and controlling area part in branches B1 to B2, for
example, this would not be possible, because the wildcards cover
these branches as well.
Table 5: Lock ob-iect having 2 entries
Controlling Activity Branch
Area
1000 Open Account **
Close Account **
This situation may be improved by another embodiment of the
invention according to which common characteristics of different
values of a key field are determined and the determined common
characteristics are entered together with a wildcard into the
key fields. This is now explained in more detail by way of
continuation of the preceding example.
When checking for common characteristics of the values of the
key field 3, lock service 205 finds that the character 'A' is a
common characteristic of all values of key field 3. This
character can now be combined with a wildcard and the
combination can be entered in state of the mere wildcard into
the fields of key field 3. The result is shown in table 6.
Now a second process could have access to those activities in
the branches B1 to B9 at the same time.

CA 02497243 2005-02-14
- 18 - 2004P00103 EPO1
Table 6: Lock obiect having 2 complete entries in the first 2
key fields and a common characteristic together with a wildcard
in the remaining key field
Controlling Activity Branch
Area
1000 Open Account A*
Close Account A*
Referring now to figure 3, a further preferred embodiment of the
invention is illustrated by a flow diagram, which summarizes
processing steps of an example of a lock service module. After
a starting step 301, the lock service receives data from a data
processing module 303 in a step 302. The data comprise m field
names, m*n values of key fields for the n data objects to be
locked and a maximum number of k lock entries. The lock service
then determines in a step 304 an optimized number of x < = k
lock entries, for example by creating and evaluating an internal
table like table 4 described before. The lock service then
determines in a step 305 whether values or wildcards are entered
into the fields of the x entries of a lock object 307 to be
created in step 306. The process then returns to step 302 and
waits for a new lock request or ends in a step 308.
Modifications and adaptations of the present invention will be
apparent to those skilled in the art from consideration of the
specification and practice of the invention disclosed herein.
The foregoing description of an implementation of the invention
has been presented for purposes of illustration and description.
It is not exhaustive and does not limit the invention to the
precise form disclosed. Modifications and variations are
possible in light of the above teachings or may be acquired from
the practicing of the invention. For example, the described
implementation includes software, but systems and methods

CA 02497243 2005-02-14
- 19 - 2004P00103 EPO1
consistent with the present invention may be implemented as a
combination of hardware and software or in hardware alone.
Additionally, although aspects of the present invention are
described for being stored in memory, one skilled in the art
will appreciate that these aspects can also be stored on other
types of computer-readable media, such as secondary storage
devices, for example, hard disks, floppy disks, or CD-ROM; the
Internet or other propagation medium; or other forms of RAM or
ROM.
Computer programs based on the written description and flow
charts of this invention are within the skill of an experienced
developer. The various programs or program modules can be
created using any of the techniques known to one skilled in the
art or can be designed in connection with existing software. For
example, programs or program modules can be designed in or by
means of Java, C++, HTML, XML, or HTML with included Java
applets or in SAP R/3 or ABAP. One or more of such modules can
be integrated in existing e-mail or browser software.
While illustrative embodiments of the invention have been
described herein, the present invention is not limited to the
various preferred embodiments described herein, but includes any
and all embodiments having equivalent elements, modifications,
omissions, combinations (e. g., of aspects across various
embodiments), adaptations and/or alterations as would be
appreciated by those in the art based on the present disclosure.
The limitations in the claims are to be interpreted broadly
based on the language employed in the claims and not limited to
examples described in the present specification or during the
prosecution of the application, which examples are to be
construed as non-exclusive. For example, in the present
disclosure, the term "preferably" is non-exclusive and means
"preferably, but not limited to." Means-plus-function or step-
plus-function limitations will only be employed where for a
specific claim limitation all of the following conditions are

CA 02497243 2005-02-14
- 20 - 2004P00103 EPO1
present in that limitation: a) "means for" or "step for" is
expressly recited; b) a corresponding function is expressly
recited; and c) structure, material or acts that support that
structure are not recited.
Other embodiments of the invention will be apparent to those
skilled in the art from consideration of the specification and
practice of the invention disclosed herein. It is intended that
the specification and examples be considered as exemplary only,
with a true scope and spirit of the invention being indicated by
the following claims.

Representative Drawing
A single figure which represents the drawing illustrating the invention.
Administrative Status

2024-08-01:As part of the Next Generation Patents (NGP) transition, the Canadian Patents Database (CPD) now contains a more detailed Event History, which replicates the Event Log of our new back-office solution.

Please note that "Inactive:" events refers to events no longer in use in our new back-office solution.

For a clearer understanding of the status of the application/patent presented on this page, the site Disclaimer , as well as the definitions for Patent , Event History , Maintenance Fee  and Payment History  should be consulted.

Event History

Description Date
Common Representative Appointed 2019-10-30
Common Representative Appointed 2019-10-30
Change of Address or Method of Correspondence Request Received 2018-06-11
Letter Sent 2014-11-07
Inactive: Office letter 2010-11-09
Revocation of Agent Requirements Determined Compliant 2010-11-09
Appointment of Agent Requirements Determined Compliant 2010-11-09
Inactive: Office letter 2010-11-09
Revocation of Agent Request 2010-10-22
Appointment of Agent Request 2010-10-22
Grant by Issuance 2008-02-05
Inactive: Cover page published 2008-02-04
Inactive: Final fee received 2007-11-09
Pre-grant 2007-11-09
Letter Sent 2007-05-14
Notice of Allowance is Issued 2007-05-14
Notice of Allowance is Issued 2007-05-14
Inactive: Approved for allowance (AFA) 2007-04-27
Application Published (Open to Public Inspection) 2005-08-19
Inactive: Cover page published 2005-08-18
Amendment Received - Voluntary Amendment 2005-06-10
Inactive: First IPC assigned 2005-04-04
Letter Sent 2005-03-18
Letter Sent 2005-03-18
Inactive: Filing certificate - RFE (English) 2005-03-18
Application Received - Regular National 2005-03-18
All Requirements for Examination Determined Compliant 2005-02-14
Request for Examination Requirements Determined Compliant 2005-02-14

Abandonment History

There is no abandonment history.

Maintenance Fee

The last payment was received on 2007-01-26

Note : If the full payment has not been received on or before the date indicated, a further fee may be required which may be one of the following

  • the reinstatement fee;
  • the late payment fee; or
  • additional fee to reverse deemed expiry.

Patent fees are adjusted on the 1st of January every year. The amounts above are the current amounts if received by December 31 of the current year.
Please refer to the CIPO Patent Fees web page to see all current fee amounts.

Owners on Record

Note: Records showing the ownership history in alphabetical order.

Current Owners on Record
SAP SE
Past Owners on Record
ROMAN RAPP
Past Owners that do not appear in the "Owners on Record" listing will appear in other documentation within the application.
Documents

To view selected files, please enter reCAPTCHA code :



To view images, click a link in the Document Description column. To download the documents, select one or more checkboxes in the first column and then click the "Download Selected in PDF format (Zip Archive)" or the "Download Selected as Single PDF" button.

List of published and non-published patent-specific documents on the CPD .

If you have any difficulty accessing content, you can call the Client Service Centre at 1-866-997-1936 or send them an e-mail at CIPO Client Service Centre.


Document
Description 
Date
(yyyy-mm-dd) 
Number of pages   Size of Image (KB) 
Description 2005-02-13 20 924
Abstract 2005-02-13 1 38
Claims 2005-02-13 2 82
Drawings 2005-02-13 3 52
Representative drawing 2005-07-25 1 9
Maintenance fee payment 2024-02-04 44 1,811
Acknowledgement of Request for Examination 2005-03-17 1 178
Courtesy - Certificate of registration (related document(s)) 2005-03-17 1 105
Filing Certificate (English) 2005-03-17 1 158
Reminder of maintenance fee due 2006-10-16 1 110
Commissioner's Notice - Application Found Allowable 2007-05-13 1 162
Correspondence 2007-11-08 1 38
Correspondence 2010-10-21 17 611
Correspondence 2010-11-08 1 16
Correspondence 2010-11-08 1 27