WO2018037258A1

WO2018037258A1 - A method of implementing hierarchically assemblable and selectable menu items in an object-oriented transactional framework

Info

Publication number: WO2018037258A1
Application number: PCT/IB2016/055006
Authority: WO
Inventors: Anthony Albert Zamora
Original assignee: Metropolitan Bank And Trust Company
Priority date: 2016-08-22
Filing date: 2016-08-22
Publication date: 2018-03-01

Abstract

An aspect of the invention is directed to a computer-implemented method of implementing hierarchically assemblable and selectable menu items in an object-oriented transactional framework. The method may be performed by an application server computer system at run-time. The method comprises the steps of: (i) invoking a tree structure characterizing cooperating objects corresponding to the menu items in response to a request from a client application executing on a client computer for information relating to the cooperating objects; (ii) providing the menu items in a sequentially assembled form for each transaction path of a plurality of transaction paths in the transactional framework beginning with a category object, continuing with a user account object, and ending with an action object of the cooperating objects; and (iii) generating and transferring to the client application codes which are arranged to render the sequentially assembled menu items on a user interface for a display screen of the client computer.

Description

A METHOD OF IMPLEMENTING HIERARCHICALLY ASSEMBLABLE AND SELECTABLE MENU ITEMS IN AN OBJECT-ORIENTED TRANSACTIONAL FRAMEWORK

TECHNICAL FIELD The present invention generally relates to object-oriented transactional frameworks in which computer-renderable menu items are assembled in various levels. More particularly, the present invention relates to a computer-implemented method of implementing hierarchically assemblable and selectable menu items in such object- oriented transactional framework. BACKGROUND ART

User interfaces for computing devices such as desktop computers, laptop computers, tablet computers, smart-phones, and the like are designed to perform various important tasks in the burgeoning industry of electronic transactions. As the use of computers in performing transactions on various electronic platforms is growing at an exponential rate, some de facto standards for menu representation have been established as part of simplifying the processes of inspecting data, selecting data to be operated on, and executing a command to operate on the selected data, among others. One of these standards is characterized by a task ontology-based framework for modeling activities or immediate actions of users or otherwise known as the task-oriented user interface for menu items.

In a task-oriented menu commonly designed for electronic banking transactions in an instance, user activities or immediate actions in menu format are represented as commands which may include verbs such as "view," "pay," "transfer," "manage," and "enroll" and as well as verb-noun phrases such as "view account summary," "pay bills," "transfer funds," "manage accounts," and "enroll credit card." In this task-oriented menu representation, each menu item is typically provided with a direct link to a procedure or more commonly known as "method" which governs and regulates the behavior and/or functionality of a function-specific data object associated with it.

A command in the form of a menu item embedded with a direct link to a behavior and/or functionality of its corresponding data object can therefore be executed with ease by simply selecting the same menu item on a computer's user interface through which a transaction on an electronic platform is being conducted. Nonetheless, this particular arrangement is encumbered with technical problems relating to the creation of a new function- specific object in each instance that a new command in a verb or verb-noun form is desired to be created and added to an existing list of commands in a task-oriented menu. For one, in some programming languages, new classes of data objects cannot be declared at runtime and hence cannot be instantiated along with the generation of the features of the data objects. John F. Wood, Jr., in his United States Patent No. 7050997 published on 23 May 2006, discloses an electronic platform characterized by a personal financial management system which models past current and projected financial transaction data as graphical objects using a graphical object-oriented methodology. Each of these objects represents a single financial entity such as accounts, loans, assets or expenses, or a financial activity such as account transfers, deposits or withdrawals. Each object is derived from an object class selected from the group consisting of an account class, a transaction class, a category class, and a template class. The account class comprises objects selected from the group consisting of bank account objects, credit account objects, investment account objects, loan account objects, and mortgage account objects. The transaction class comprises objects selected from the group consisting of account/account transaction objects, account/category transaction objects, account/transaction transaction objects, category/transaction transaction objects, and close account transaction objects.

Wood further discloses use of three primary classes for directly controlling or tracking one form of an electronic transaction such as a financial activity, namely, category class, transaction class, and account class. Particularly, these classes and the objects associated with them are arranged using an object-oriented representation of inheritance. Any combination of these primary classes can be associated with one or more template classes. Through this hierarchical inheritance structure of object-oriented programming, as is well known in the art of electronic digital computing, new category, transaction and account objects (which may serve as "descendants") may contain references to methods which they inherit from other existing objects or classes (which may serve as "ancestors"). This thereby solves the technical problems relating to the creation, at runtime, of a new function- specific object in each instance that a new command in a verb form or in a verb- noun form is desired to be created and added to an existing list of commands in a group of menu items.

Notwithstanding the foregoing, the "no particular arrangement" of the category, account and action objects in the Woods prior art results in a long listing of menu items for display on a user interface for a display screen of a computing device which, in turn, causes an apparent inefficient usage of physical and computing resources of the computing device on which the same objects are renderable for viewing of a transacting user. This may arise from the fact that such long listing of menu items is rendered inefficiently on a computing device having a display screen of limited size, and from another fact that it requires unbounded and/or large amount of memory and computing power of a computing device to render such long listing of menu items. It bears stressing that not every user possesses a powerful computing device which is capable of avoiding response lags and delays in rendering graphical representation of a long listing of menu items.

Accordingly, a technical problem which is encountered in the Woods prior art and which remains unsolved to date is providing an object-oriented transactional framework wherein the display of category, transaction or action, and account objects in relation to one another within a hierarchy of data not only represents intuitively organized menu items and but is generally not constrained by the limited physical properties and/or computing resources of a computing device which is often the case in most handheld models of computing devices such as smart-phones, notably the low-cost models.

SUMMARY OF THE INVENTION The following is a simplified summary of the disclosure associated with the invention in order to provide a basic understanding of one or more aspects of the same disclosure. This summary is not an extensive overview of the disclosure. It is intended to neither identify key or critical elements of the disclosure, nor delineate any scope of the particular implementations of the disclosure or any scope of the appended claims. Its sole purpose is to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.

An aspect of the invention is directed to a computer-implemented method of implementing hierarchically assemblable and selectable menu items in an object-oriented transactional framework. The method is performed by an application server computer system at run-time. The method comprises the steps of: (i) invoking a tree structure characterizing cooperating objects corresponding to the menu items in response to a request from a client application executing on a client computer for information relating to the cooperating objects; (ii) providing the menu items in a sequentially assembled form for each transaction path of a plurality of transaction paths in the transactional framework beginning with a category object, continuing with a user account object, and ending with an action object of the cooperating objects; and (iii) generating and transferring to the client application codes arranged to render the sequentially assembled menu items on a user interface for a display screen of the client computer.

The cooperating objects are grouped into the plurality of the transaction paths. Each of these transaction paths represents a transaction instance of an electronic transaction in the transactional framework. The category object of the cooperating objects which are associated with the sequentially assembled menu items may correspond to an attribute of the transactional framework. The user account object of the cooperating objects which are associated with the sequentially assembled menu items may correspond to a user account upon which the transaction can be conducted. The action object of the cooperating objects which are associated with the sequentially assembled menu items may correspond to a task request associated with the transaction instance of the electronic transaction in the transactional framework.

Another aspect of the invention is directed to a computer-implemented system for implementing hierarchically assemblable and selectable menu items in an object-oriented transactional framework. The system comprises the application server computer system which, at run-time, is configured to: (i) invoke the tree structure characterizing the cooperating objects corresponding to the menu items in response to the request from the client application executing on the client computer for the information relating to the cooperating objects, wherein the cooperating objects are grouped into the plurality of transaction paths, and wherein each transaction path of the plurality of transaction paths represents the transaction instance of the electronic transaction in the transactional framework; (ii) provide the menu items in a sequentially assembled form for each of the transaction paths beginning with the category object of the cooperating objects corresponding to the attribute of the transactional framework, continuing with the user account object of the cooperating objects corresponding to the user account upon which the transaction can be conducted, and ending with the action object of the cooperating objects corresponding to the task request associated with the transaction instance; and (iii) generate and transfer to the client application codes which are arranged to render the sequentially assembled menu items on the user interface for the display screen of the client computer.

The provision of the sequentially assembled menu items in a hierarchical order from the category object, to the user account object and then to the action object ensures not only intuitive organization of data. Additionally, the grouping of action objects as a subgroup of one particular user account object together with the grouping of user account objects as a subgroup of one particular category object all together can result in a creation of a short listing of the menu items as compared with one continuous list of all desired task-oriented menu items. Navigating through a single and normally long list of all possible task-oriented menu items which may be characterized by objects in verb-noun forms can consume a significant amount of computing resources of computing devices rendering the same menu items.

Display of a short listing of intuitively organized menu items is not constrained by the limited physical properties and/or computing resources of a computing device which is often the case in most handheld models of computing devices. The category, user account and action objects included in one transaction path can be navigated by a human client on a user interface for a display screen with limited size without requiring substantial amount of scrolling through a long list of menu items, panning on a wide area of menu items, or frequent switching from one transactional page to another. The computing resources of the computing devices on which the category objects, the user account objects, and the action objects are rendered for display are therefore optimized.

For a better understanding of the invention and to show how the same may be performed, preferred implementations and/or embodiments thereof will now be described, by way of non-limiting examples only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram illustrating components of an application server computer system suitable for use in executing a method of implementing hierarchically assemblable and selectable menu items according to one aspect of the invention.

Figure 2 is a block diagram illustrating components of a client computer suitable for use in an implementation of the invention as described herein. Figure 3 is a block diagram illustrating components of a client computer suitable for use in another implementation of the invention as described herein.

Figure 4 is a block diagram illustrating an exemplary object-oriented environment for software development and software execution in accordance with one or more implementations of the invention as described herein.

Figure 5 is a representation of an exemplary user interface according to one or more operating principles of the invention as described herein.

Figure 6 is a representation of another exemplary user interface according to one or more operating principles of the invention as described herein. Figure 7 is a representation of yet another exemplary user interface according to one or more operating principles of the invention as described herein.

Figure 8 is a sequence diagram illustrating an overview of a general operation characterized by a transaction in accordance with one or more implementations of the invention as described herein. Figure 9 is a block diagram illustrating a data processing system between a client computer and an application server computer system according to another aspect of the invention.

Figure 10-A is a flow diagram illustrating an exemplary operation in the software development and execution environment of Figure 4. Figure 10-B is a flow diagram which is a continuation of the flow diagram in

Figure 10-A.

Figure 10-C is a flow diagram which is a continuation of the flow diagram in Figure 10-B.

Figure 11 is an alternative representation of an exemplary user interface according to one or more operating principles of the invention as described herein.

Figure 12 is a further alternative representation of an exemplary user interface according to one or more operating principles of the invention as described herein.

DETAILED DESCRIPTION OF THE PREFERRED IMPLEMENTATIONS

One or more execution methods, execution systems, transactional frameworks, object-oriented programming systems, classes, and class objects according to one or more implementations of the present invention, including various computer-designed aspects, processes, sub-processes and configurations of the same, may be implemented on a variety of electronic computing devices and systems, including electronic client devices and/or server computers, wherein these computing devices include well-known and appropriate processing mechanisms and computer-readable media for storing, fetching, executing, and interpreting computer-readable instructions, such as programming instructions, codes, signals, and/or the like.

Further, the present invention may include procedures for implementing logic control in programmable controllers in distributed control systems in either wired or wireless data networks.

All the ensuing disclosures and illustrations of the preferred implementations of the present invention, along with one or more components, features or elements thereof, are merely representative for the purpose of sufficiently describing the manner by which the present invention may be carried out into practice in various ways other than the ones outlined in the ensuing description.

It is to be understood and appreciated by a person skilled in the art or having ordinary skills in the art, however, that the exemplary implementations used to describe how to make and use the present invention may be embodied in many alternative forms and should not be construed as limiting the scope of the appended claims in any manner, absent express recitation of those features in the appended claims. All the exemplary drawings, diagrams and illustrations accompanying the ensuing description should also not be construed as limiting the scope of the appended claims in any manner.

Unless the context clearly and explicitly indicates otherwise, it is to be understood that like reference numerals refer to like elements throughout the ensuing description of the figures and/or drawings, that the linking term "and/or" includes any and all combinations of one or more of the associated listed items, that the singular terms "a", "an" and "the" are intended to also include the plural forms, and that some varying terms of the same meaning and objective may be interchangeably used throughout the ensuing disclosure.

THE TRANSACTIONAL FRAMEWORK AND

THE APPLICATION SERVER COMPUTER SYSTEM

The implementations of the present invention are herein described in the domain of online banking applications which can be accessed via websites, mobile sites and/or mobile applications. It is to be understood and appreciated that the present invention may be applied to a wide range of domains such as human resource management applications, inventory and procurement management applications, supply chain management applications, employee information management applications, accounting applications, payroll applications, point-of-sale applications, customer relationship management applications, customer order management applications, warehouse management applications, enterprise resource planning applications, e-commerce business applications, e-government business applications, e-telecom business applications, and the like. An exemplary transactional framework in the domain of online banking applications is illustrated as application software 100 in the block diagram of Figure 1 which illustrates hardware and software components of an application server computer system 102 suitable for use in performing the method of implementing hierarchically assemblable and selectable menu items in accordance with one or more implementations of the present invention.

The transactional framework 100 may be an electronic platform which provides banking services and other related services. More particularly, the transactional framework 100 may be implemented through, or may be executed by, the application server computer system 102 hosted, maintained and operated by a financial institution. The financial institution may be a bank of any type, a credit union, a credit cooperative, or a microfinance institution.

The illustrated application server computer system 102, herein referred to as "server system" for brevity, is preferably a typical bank which provides a wide range of financial services and products that can be accessed conveniently from the comfort of a user's home or office, or from any location, using a client application 104-a, 104-c, 104-e running on a computing framework of the client computer 106-a, 106-c, 106-e. The client applications 104-a, 104-c, and 104-e may be collectively referred to herein as "client application 104" for brevity. The client computers 106-a, 106-c, and 106-e may be collectively referred to herein as "client computer 106" for brevity.

In addition to the application software serving as the transactional framework 100, the server system 102 may further include a server processor 108, a server memory system 110, a data storage system 112, an operating system 114, device drivers 116, virtual machine monitors or hypervisors 118, and a network interface 120 in operative communication with one another.

The transactional framework 100, which may be contained in the server memory system 110 and executable by the server processor 108 from the server memory system 110, may include a display module 122, an account management module 124, and a transaction management module 126 operably communicating with one another for various purposes including data exchange, information sharing, data integration, service integration, and the like.

The transactional framework 100 may be implemented using Java, C++, C#, Objective-C, PHP, Python, Perl, Ruby, ActionScript, Smalltalk, Eiffel, Delphi, Swift, Common Lisp, or other object-oriented programming language in conjunction with one or more software development frameworks which are known in the art.

However, it is to be understood and appreciated that while it is preferred that the development and implementation of the transactional framework 100 is based on an object-oriented programming language, any of the server system 102 and the client computer 106 may include a conversion module (not illustrated in the accompanying drawings) for converting data associated with the transactional framework 100 from a server format into client specific formats or, alternatively, from client specific formats into a server format.

The display module 122, the account management module 124, and the transaction management module 126, along with other undisclosed modules that can constitute or can be integrated into the transactional framework 100, may be implemented in software, hardware, firmware, logical units, logical structures, or any suitable combination thereof.

The display, account management, and transaction management modules 122, 124, and 126 may be combined in various modules or as one module to support electronic transactions related to various banking and/or financial products and services, and may be distributed across a plurality of computer platforms, servers, terminals, mobile devices and the like. The modules 122, 124, 126 may be active (i.e., the modules are provided with activation time attribute) or passive (i.e., the modules are not provided with activation time attribute) in performing desired functions or predetermined computing tasks. It is to be understood and appreciated that each of the display, account management, and transaction management modules 122, 124, 126 may have its corresponding logic and processes, and these logic and processes may or may not be interrelated in respect of one another. It is also to be understood and appreciated that other modules which are not illustrated herein but are suitable for use in the illustrated transactional framework 100 in the domain of conventional electronic banking applications, and as well as in the domains of other applicable applications, may be integrated into the server system 102 in accordance with implementations of the present invention.

The display module 122 may enable display of graphical representations of various objects on a user interface or graphical user interface for a display screen 128-a, 128-c, 128-e of the client computer 106-a, 106-c, 106-e. The display screen 128-a, 128-c, 128-e may be collectively referred to herein as "display screen 128" for brevity. The display module 122 also enables the objects in computer-readable format to be displayed on the display screen 128 of the client computer 106 in human readable format (e.g., text and image formats which are understandable by a human).

The account management module 124 may be arranged to perform various account management functions and/or services. For example, the account management module 124 can be configured to store into and/or retrieve from a user account database system various user account information and other related information. The user account database system may be associated with the data storage system

112 of the server system 102. The account management module 124 can also be configured to restrict access to features and services of the transactional framework 100 based on predetermined user credentials associated with individual user accounts which are registered with the transactional framework 100 and which are activatable for limited usage.

The transaction management module 126 may be arranged to initialize, process and/or terminate secure electronic transactions and as well as to communicate with the account management module 124 for updating of financial and personal information based on the user-triggered secure electronic transactions.

The financial information may be based on a financial type of transactions such as bills payment, fund transfer, crediting an account and debiting an account. The personal information may be based on a personal type of transactions such as account enrollment services, account unenrollment services, change of contact information, change of billing and/or mailing address, and billing statement retrieval.

The data storage system 112 is preferably arranged in a standard database format, and may include one or more interrelated databases. The data storage system 112 may be of the format which utilizes an object-oriented language such as Java. Further, the data storage system 112 may be of the format that utilizes a standard query language such as SQL (Structured Query Language). The herein disclosed objects may be stored or form part of the data storage system 112. Instances of these database objects may include tables, indexes and views of said tables, among others.

The device drivers 116 may include drivers for hardware and/or software components associated with any one or all of possible control and logical operations executable by the server system 102.

The operating system 114 may be used to implement the computer-executable programs, to support hardware devices, and to support basic system operations associated with any one or all of the programs and hardware devices of the server system 102. The hypervisors 118 can be arranged to act as interface between guest software such as guest operating systems and guest applications and any one or more of the hardware components of the server system 102 such as the server processor 108.

The guest applications may or may not be characterized by banking applications. The guest applications may originate from external sources and may provide support to the transactional framework 100. The support may be an enterprise support that can be provided, for example, as analytics applications and/or as software as a service. In some implementations of the present invention, the hypervisors 118 may be implemented in hardware, software, firmware, or by a combination of various techniques which are well known in the art of abstraction of virtual machines on physical machines such as the herein illustrated server system 102.

The network interface 120 may be wired or wireless interface, and can be configured to send and receive signals over two or more communication channels using transceivers or antennas. The network interface 120 may be incorporated directly into the server processor 108 or as an integral component of the server processor 108.

THE CLIENT COMPUTER AND THE CLIENT APPLICATION The client computer 106 may be implemented as a variety of devices which may include a PDA (personal digital assistant), a media player, a desktop computer, a laptop computer, a tablet computer, a notebook computer, a netbook computer, a notebook computer, a phablet computer, a smart-phone and other electronic devices having physical resources which support short-range, medium-range and/or long-range radio communications, and as well as wired or wireless packet-based data communications. Computing devices such as these are employed with combined hardware and software techniques that can be utilized to provide cooperative multitasking which enables applications or software applications, such as the client application 104 alongside with another application, to be executed and run simultaneously. As shown in the block diagram of Figure 2, the hardware architecture of the client computer 106 of the desktop type in accordance with one or more implementations of the present invention may include a system bus 200 that enables communication of the following components: a client processor 202 which may be a CPU (central processing unit), a client memory system 204 containing computer-executable instructions 204-a, a storage interface 206 for storing an operating system, routines, and the instructions 204-a, among others, an external disk drive 208, an input/output controller 210 which may be connected to a keyboard 212, a pointing device 214, an audio device 216, a microphone 218, a display adapter 220 connected to the display screen 128, and a network interface 222 for enabling data communication with other devices over a communication network 224 which may be an Internet Protocol (IP) based data communication network or the "Internet."

As shown in the block diagram of Figure 3, the hardware architecture of the client computer 106 of the smart-phone type in accordance with one or more implementations of the present invention may include a client processor 300 and a client memory system 302 which may include a RAM (Random Access Memory) 304 and a ROM (Read-Only Memory) 306. Computer-executable instructions 308 may be stored on the client memory system 302.

The client computer 106 of the smart-phone type may also include a storage controller 310 on which an operating system 312 and software modules 314 may be made operable, an input/output controller 316, and a network interface controller 318, among others. The network interface controller 318 enables the client computer 106 to communicate with other computing devices over any suitable communication network 320 such as the IP based data communication network or the "Internet." The illustrated components of the client computer 106 of the smart-phone type may communicate with one another through a system bus 322. The processors 202, 300 of the client computer 106 are capable of fetching and processing data from the client memory systems 204, 302 and as well as of executing instructions from the same client memory systems 204, 302, respectively. The processors 202, 300 may be a single processor or may be embodied as multiple processors for efficient data processing. The processors 202, 300 may perform transcoding operations in conjunction with other operations by encoding or decoding of data sent to or from the server system 102.

The client memory systems 204, 302 are capable of storing data associated with the transactional framework 100 and the computer-executable instructions or specifically program instructions 204-a, 308 from any storage location in the server system 102 over the communication networks 224, 320.

Such storage location can be accessed by the processors 202, 300 over the communication networks 224, 320 so that the data associated with the transactional framework 100 and all its hardware and software components can be stored into the client memory systems 204, 302 and that the instructions 204-a, 308 can be executed by the client processors 202, 300.

The client memory systems 204, 302 may also include any one or more of an FRAM (Ferroelectric RAM), a DRAM (Dynamic random access memory), and a synchronous DRAM (SDRAM). The client application 104 may be implemented as a web browsing application

104-a running on the laptop computer 106-a, as a mobile site browsing application 104-c running on the cellular device 106-c, and/or as a mobile application or more commonly known as "mobile app" 104-e running on the smart-phone 106-e.

Preferably, the client application 104-a, 104-c, 104-e is enabled for Java, C++, C#, Objective-C, PHP, Python, Perl, Ruby, ActionScript, Smalltalk, Eiffel, Delphi, Swift, Common Lisp, or other object-oriented programming language.

THE OBJECT-ORIENTED ENVIRONMENT

FOR SOFTWARE DEVELOPMENT AND EXECUTION

Figure 4 shows a block diagram illustrating an exemplary object-oriented environment for software development and execution in accordance with one or more implementations of the present invention. Particularly, the object-oriented environment illustrated in Figure 4 may be used for the purpose of developing and executing the transactional framework 100 of the present invention.

The illustrated development and execution environment may mainly include a software development device 400 having an IDE (integrated development environment) interface 402 and a software execution device 404 having an execution interface 406. The software development device 400 may be any computing device having the capability of running a software development tool 408. The software development device 400 may be a desktop computer, a laptop computer, or the like. The software development tool 408 may be, by way of examples and not by way of limitation, the NetBeans, the Eclipse, or the Java Studio Creator.

A programmer and/or developer of the transactional framework 100 may use the software development tool 408 to create a tree structure 410 which may be a class tree structure representative of menu items. The software development tool 408 may be used by the programmer to create the data objects 412, 414, 416, and to organize the same data objects 412, 414, 416 in such a manner that the computer-renderable tree structure 410 is formable.

The creation of the data objects 412, 414, 416, among other possible objects, may result in a creation of tree data 418 which are representative of definitions of the menu items. The tree data 418 are characterized by complete definitions of behavior and functionality of each object included in the objects 412, 414, 416 which may include the category objects 412, the user account objects 414, and the action objects 416. Put differently, the tree data 418 are characterized by complete definitions of behavior and functionality of each menu item included in the sequentially assembled menu items corresponding to the objects 412, 414, 416.

Since the environment for the development of the transactional framework 100 of the present invention follows the object-oriented principles of programming for software development, new definition of each of the category objects 412, the user account objects 414, and the action objects 416 can be made without writing new codes. The software development tool 408 may include a language component 420, a tree structure engine 422, a message engine 424, and a library component 426, among others.

The language component 420 is the part of the software development tool 408 which can be used to support and interpret one or more languages of a set of programming languages. The language component 420 preferably includes object-oriented programming or scripting languages. The language component 420 can be integrated into the software development tool 408 as an embedded component and in a manner that it can serve either as a language interpreter or as a language translator depending on preferred configurations.

As a language interpreter, sources codes which are associated with a predetermined programming language, such as Java, can be appropriately interpreted by the language component 420 prior to the preparation of the same language for execution on the software execution device 404 in order to display or graphically render the transactional page 436 on the execution interface 406 which is associated with the software execution device 404. As a language translator, any written codes associated with the predetermined programming language can be translated into machine -readable codes by the language component 420, wherein the machine-readable codes are arranged for execution without reference to the functions, processes and/or methods of the language interpreter implementation of the language component 420.

The tree structure engine 422 may be arranged to include the tree structure objects 412, 414, 416 and may be arranged to create the menu items on the transactional framework 100 and as well as the governing behavior and functionality of one menu item in relation to one or more of other menu items. These tree structure objects 412, 414, 416 can be independent of other codes in the software development tool 408. Alternatively, these tree structure objects 412, 414, 416 can rely on other codes pre-stored on the software development tool 408 in order for them to operate in accordance with desired functions.

For example, each time that the software development tool 408 is caused to generate a representation of the tree structure 410 which is representative of the menu items, the object codes generated can use the codes in the library component 426 to define the relationships of the category, user account and action objects 412, 414, 416 with respect to one another. The library component 426 is preferably arranged to utilize object- oriented class libraries which are characterized by hierarchical relationships of data or information.

The menu items that can be particularly generated using the software development tool 408 may be graphically represented on the user interface for the display screen 128 of the client computer 106 as a window, a frame, a dialog box, a menu bar, a cascaded menu, a pop-up menu, a pull-down menu, a tabbed menu, a drop-down list, an icon, or any one or more suitable combinations thereof.

The message engine 424 can be arranged to manage messages to which each individual objects selected from any of the category objects 412, the user account objects 414, and the action objects 416, among other objects, should respond based on the definition of characteristics, attributes or features of their respective classes. Similar to the software development device 400, the software execution device 404 for providing the execution interface 406 may also be a desktop computer, a laptop computer, or the like.

The programmer and/or developer of the transactional framework 100 may use the software execution device 404 to render graphical representation of the menu items as defined by the tree structure engine 422 of the software development tool 408 which is associated with the software development device 400 and which utilizes the resources of the language component 420 and the library component 426. The software execution device 404 and the software development device 400 may or may not be the same unit. In one implementation, the software execution device 404 may be arranged to receive from the software development device 400 the transactional framework objects 428 which may include the tree structure objects 412, 414, 416, the message objects 430, the source code objects 432, and other data objects 434 through appropriate connections. For example, the software execution device 404 may be connected to the software development device 400 through a local area network or through a wide area network if they are separate units. It is to be understood and appreciated that the software execution device 404 and the software development device 400 may be connected to one another through any suitable networking arrangements which are well known in the art. The software execution device 404 executes codes associated with the tree structure objects 412, 414, 416, the message objects 430, the source code objects 432, and the other data objects 434 in order to render them on the execution interface 406. The execution interface 406 may or may not directly correspond to the graphical user interface for the display screen 128 of the client computer 106. The execution interface 406 may be arranged to render the transactional page 436 which may correspond to a leaf of the tree structure 410 which, in turn, is representative of the menu items and preferably includes the category objects 412, the user account objects 414, and the action objects 416, among other objects.

The leaf of the tree structure 410 may correspond to any particular data object selected from any of the category objects 412, the user account objects 414, and the action objects 416.

The leaf of the tree structure 410, in other words, may correspond to one of the menu items represented by the same tree structure 410 which may be built based on the "build" command 438 on the IDE interface 402 associated with the software development device 400. Consistent with the principles of the present invention, the category objects 412, the user account objects 414, and the action objects 416 are arranged to cooperate with one another through various relations, attributes, and methods.

The software execution device 404 may include a language interpreter engine 440 and a graphics engine 442. The language interpreter engine 440 may be required to enable the software execution device 404 to read, process, and execute the codes associated with the transactional framework 100 and generated using the software development tool 408 which is locally residing on the software development device 400.

The graphics engine 442 may be required to create graphics or depict visual codes associated with the graphical representations of the listing of the category objects 412-a, 412-c, and 412-e, the graphical representations of the listing of the user account objects 414-a and 414-c, and the graphical representations of the listing of the action objects 416-a and 416-c. As illustrated in Figure 4, the user account objects 414-a, 414-c are formed under the category object 412-e, and the action objects 416-a, 416-c are formed under the user account object 414-a.

THE COMPUTER-IMPLEMENTED METHOD

PERFORMED BY THE SERVER SYSTEM

An aspect of the present invention is primarily directed to a method of implementing hierarchically assemblable and selectable menu items in the object-oriented transactional framework 100. The method can be performed by the server system 102 at run-time. A first method-step which is included in the method of the present invention is characterized by invoking the tree structure 410 characterizing the cooperating objects 412, 414, 416 corresponding to the menu items in response to a request from the client application 104 executing on the client computer 106 for information relating to the cooperating objects 412, 414, 416. A second method-step which is included in the method of the present invention is characterized by providing the menu items in a sequentially assembled form for each transaction path of a plurality of transaction paths in the transactional framework 100 beginning with the category object 412, continuing with the user account object 414, and ending with the action object 416 of the cooperating objects 412, 414, 416. Implementations of the present invention may utilize one or more category objects 412, one or more user account objects 414, and one or more action objects 416.

The sequentially assembled form may be based on a pre-determined configuration of the menu items. Alternatively, the sequentially assembled form may be based on a realtime or near real-time configuration of the menu items. Arrangements, hierarchies, levels, properties, elements, attributes, and the like may constitute the configuration of the menu items.

A third method-step which is included in the method of the present invention is characterized by generating and transferring to the client application 104 codes which are arranged to render the sequentially assembled menu items on the user interface for the display screen 128 of the client computer 106.

The cooperating objects 412, 414, 416 are preferably grouped into the plurality of the transaction paths. Each of these transaction paths represents a transaction instance of an electronic transaction that can be performed in the transactional framework 100.

The category objects 412 of the cooperating objects 412, 414, 416 which are associated with the sequentially assembled menu items may correspond to an attribute of the transactional framework 100. The attribute of the transactional framework 100 may correspond to a noun form of an object which is representative of one particular category. For example, this one particular category may include "e-banking," "investments," and "loans" terms which are commonly and widely used in the domain of online banking applications.

The user account objects 414 of the cooperating objects 412, 414, 416 which are associated with the sequentially assembled menu items may correspond to a user account upon which the transaction can be conducted in the transactional framework 100. The user account to which the user account object 414 corresponds may be an electronic account consisting of all numeric or alphanumeric figures. The user account may be aliased by a mobile telephone number associated with the owner of the user account for security purposes. A plurality of the user account objects 414 may include, by way of examples and not by way of limitation, bank account objects, credit card account objects, investment account objects, mutual fund account objects, brokerage account objects, loan account objects, mortgage account objects, electronic commerce account objects, escrow account objects, fund raising account objects, social media account objects, educational account objects, insurance account objects, charitable account objects, loyalty program account objects, membership account objects, privilege card account objects, gift card account objects, subscription account objects, identification account objects, payroll account objects, utility account objects, and fund transfer account objects.

The bank account objects which can constitute the user account objects 414 may include, by way of examples and not by way of limitation, deposit account objects, savings account objects, debit account objects, credit account objects, checking account objects, prepaid card account objects, cash card account objects, stored value card account objects, and sponsor-funded stored value card account objects.

The objects 412, 414, 416 are manipulable, assemblable, and selectable. More particularly, the objects 412, 414, 416 may be manipulable, assemblable and selectable on the side of the server system 102. The objects 412, 414, 416 may be selectable on the side of the client computer 106.

The action objects 416 of the cooperating objects 412, 414, 416 which are associated with the sequentially assembled menu items may correspond to a task request associated with the transaction instance in the transactional framework 100. The task request may be in a verb-noun form such as "pay bills," "view statement," and "redeem rewards" which are widely used in the domain of online banking.

The method may further comprise the step of activating and rendering on the user interface for the display screen 128 of the client computer 106 the transactional page 436 corresponding to the leaf of the tree structure 410 in response to a selection of a menu item from the sequentially assembled menu items. The selection of the menu item may be triggered by a human user or client who operates the client application 104 running on the client computer 106 and accessing the transactional framework 100 on the server system 102 over any suitable communication network. EXEMPLARY USER INTERFACES FOR THE

DISPLAY SCREEN OF THE CLIENT COMPUTER

Various representations of exemplary user interfaces which may appear as the execution interface 406 on the software execution device 404 and/or as the user interface for the display screen 128 of the client computer 106 are shown in Figures 5, 6 and 7. It is to be understood and appreciated that these interfaces are non-limiting and can be arranged in various ways without departing from the scope of the appended claims and principles of the present invention.

Figure 5 specifically shows an exemplary website's user interface for the display screen 128 of the client computer 106. The illustrated website's user interface shows graphical representations of the category objects 412, the user account objects 414, and the action objects 416 in the domain of banking applications.

As illustrated in Figure 5, the category objects 412 may include main category objects which are textually represented by "e-banking," "investments," and "loans" and as well as sub-category objects textually represented by "debit card," "credit card," "prepaid card," and "cash card." The sub-category objects are the result of the selection of the "e- banking" main category object of the category objects 412.

The user account objects 414 are textually represented by "Classic Visa <credit card account number>," "Classic MasterCard <credit card account number>," "Platinum MasterCard <credit card account number>," and "World MasterCard <credit card account number>." These textually represented user account objects 414 are the result of the selection of the "credit card" category object 412.

The action objects 416 are textually represented by "pay bills," "view statement," and "redeem rewards." These action objects 416 are the result of the selection of the "Platinum MasterCard" user account object 414. Thus, one transaction instance which is found in one transaction path can be defined by a series of menu item selections beginning from the category objects 412 (as depicted by the underlined "e-banking" and "credit card" menu items), continuing with the user account object 414 (as depicted by the underlined "Platinum MasterCard" menu item), and ending with the action object 416 (as depicted by the underlined "pay bills" menu item).

Figure 6 specifically shows an exemplary mobile app's user interfaces for the display screen 128 of the client computer 106. The illustrated mobile app's user interfaces show graphical representations of the category objects 412, the user account objects 414, and the action objects 416 similar to the cooperating objects 412, 414, 416 illustrated for the website's user interface of Figure 5. As illustrated, a selection of the "credit card" category object 412 may result in a display of the graphical representation of the user account objects 414, and a selection of the "Platinum MasterCard" user account object 414 may result in a display of the graphical representation of the action objects 416. As clearly depicted in the user interfaces of Figures 5 and 6, the rendering of the menu items 412, 414, 416 consistent with the method of the present invention may include fitting a plurality of the category objects 412 associated with the plurality of transaction paths on the user interface for the display screen 128 of the client computer 106. The transaction paths are characterized by a series of user- triggered selections of the menu items beginning from the set of category objects 412, continuing with the set of user account objects 414, and ending with the set of action objects 416.

As further depicted in the user interfaces of Figures 5 and 6, the rendering of the menu items 412, 414, 416 consistent with the method of the present invention may include fitting the plurality of user account objects 414 associated with one of the plurality of the category objects 412 on the user interface for the display screen 128 of the client computer 106. In particular, the plurality of user account objects 414 are fitted on a single display area viewable on the display screen 128. The number of menu items associated with the user account objects 414 may be limited to a certain number that fits on various standard screen sizes of mobile phones or smart-phones.

As further depicted in the user interfaces of Figures 5 and 6, the rendering of the menu items 412, 414, 416 consistent at least with the method of the present invention may include fitting a plurality of action objects 416 associated with one of the plurality of the user account objects 414 on the user interface for the display screen 128 of the client computer 106. In particular, the plurality of action objects 416 are fitted on a single display area viewable on the display screen 128. The number of menu items associated with the action objects 416 may be limited to a certain number that fits on various standard screen sizes of mobile phones or smart-phones.

Figure 7 specifically shows an exemplary user interface containing the transactional page 436 for display on the display screen 128 of the client computer 106. The transactional page 436 may be a result of the selection of the "pay bills" action object 416 on the website's user interface illustrated in Figure 5 or on the mobile app's user interface illustrated in Figure 6.

Through the illustrated transactional page 436 which may originate from the server system 102 and rendered on the client computer 106 through the client application 104 running on it, a transacting user can conveniently perform a bills payment transaction by choosing a financial account to be debited, entering the amount to be paid, and selecting a payment schedule option, among others.

Upon submission of the transactional page 436 serving as an electronic form filled out with the required information from the client computer 106 to the server computer 102 and successful validation of all payment related information, the bills payment transaction can be tagged as successfully completed. The successful validation of all payment related information may involve one or more third party processors and one or more third party settlement procedures. The provision of the sequentially assembled menu items in a hierarchical order from the category object 412, to the user account object 414 and then to the action object 416 ensures not only intuitive organization of data. In addition, the grouping of the action objects 416 into a subgroup of one particular user account object 414 together with the grouping of user account objects 414 into a subgroup of one particular category object 412 all together can result in a creation of short listing of menu items as compared with one continuous list of all possible task-oriented menu items.

Navigating through a single and normally long list of all possible task-oriented menu items which may be characterized by objects in verb-noun forms can consume a significant amount of computing resources of computing devices which may include the server system 102 and the client computer 106.

Display of a short listing of intuitively organized menu items 412, 414, 416 is not constrained by the limited physical properties and/or computing resources of a computing device which is often the case in most handheld models of computing devices such as the illustrated client computer 106-c, 106-e.

The category, user account and action objects 412, 414, 416 included in one transaction path can be navigated through by a human client on the user interface for the display screen 128 with limited size without requiring substantial amount of scrolling through a long list of menu items, panning on a wide area of menu items, or frequent switching from one transactional page 436 to another. The computing resources of the computing devices, such as the client computer 106, on which the category, user account and action objects 412, 414, 416 are graphically rendered for display, manipulation and/or selection are therefore optimized.

For software developers and programmers, the execution interface 406 may be rendered on the software execution device 404 or on the software development device 400 for the purpose of inspecting the graphical representation of the tree structure 410 and validating whether the relationships among the menu items corresponding to the category objects 412, the user account objects 414, and the action objects 416 are in accordance with desired specification and have no operational anomalies. For the end users or clients of the transactional framework 100, the user interface for the display screen 128 of the client computer 106 through which the transactional page 436 is accessible can be used to perform one or more electronic transactions such as online banking transactions of standard configurations which are well known in the art. The historical information associated with the transactions made using a single user account associated with the user account object 414 may be captured in the transactional framework 100 for later retrieval as and when any need arises.

Through the execution interface 406, on the other hand, the graphical representations of the listing of the category objects 412-a, 412-c and 412-e, the graphical representations of the listing of the user account objects 414-a and 414-c, and the graphical representations of the listing of the action objects 416-a and 416-c can be assembled, viewed and manipulated. A selection of a menu item which corresponds to any one of the category objects 412, the user account objects 414, and the action objects 416 may cause a desired function to be called, executed and performed for testing. The desired function may be an embedded function that is selected from any prearranged set of device-resident functions and/or from any pre-arranged set of external functions.

The device-resident functions may include, but not limited to, logic execution, transaction performance, sending and receiving messages, analytical modeling, task management, graphical representations of one or more objects, displaying of graphical representation of one or more of the transactional pages 436 and/or frames within a window of one transactional page 436, interactive navigation, and the like.

The external functions may include data communication, database access, information sharing, and the like. The functions associated with any one or more of the cooperating objects 412, 414, 416 and shared between the software execution device 404 providing the execution interface 406 and the client computer 106 providing the user interface for the display screen 128.

EXEMPLARY OPERATION CHARACTERIZED BY AN ELECTRONIC TRANSACTION Referring now to Figure 8, there is shown a sequence diagram illustrating an overview of a general operation characterized by an electronic transaction which can be performed in accordance with one or more implementations of the present invention. The illustrated operation involves tasks which are executed by each of the client computer 106, a web server computer system 800, and the server system 102. The operation may start when the client computer 106 receives a selection of menu item from a group consisting of the menu items representing the tree structure 410 via the client application 104 running on it, as shown in block 802. The client application 104 may be executed to render the content associated with the application software 100 which forms the transactional framework 100 from the server system 102. Thus, any or all of the software functions and services which are associated with the application software 100 may be available on the client application 104 which is locally running on the computing framework of the client computer 106.

The operation continues to block 804 wherein the client computer 106 generates an HTTP (HyperText Transfer Protocol) request using the client application 104, and consequently to communication path 806 wherein the client computer 106 transmits to the web server computer system 800 (hereinafter referred to as "web server" for brevity) the HTTP request generated based on the selection of the menu item. The client application 104 running on the client computer 106 may be in communication with the web server 800 using any suitable protocols such as the Internet Protocol (IP). The web server 800 may accept various requests and may provide responses using IP based connections and configurations.

Subsequently, the web server 800 processes the HTTP request and transmits the same request in a server specific format to the server system 102 as shown in block 808 and communication path 810, respectively. The web server 800 may be in communication with the server system 102 using any suitable protocols defined by IP based connections and configurations.

At subsequent block 812, the server system 102 processes the formatted request from the web server 800. Once the processing task is successfully completed, the server system 102 accesses and loads into container objects all transactional data which are related to, or which correspond, to the formatted request originating from the client computer 106 through the web server 800 which are in operative communication with one another through any suitable protocols and/or APIs (application programming interfaces). The accessing task and the loading task on the server system 102 are shown in block 814.

Once the transactional data are loaded into the container objects, the server system 102 may be arranged to automatically generate an HTML response which, in effect, corresponds to the HTML request originating from the client computer 106 and passing through the web server 800. The generation of the HTML response by the server system 102 based on the container objects is shown in block 816.

Consequently, the operation may proceed to communication path 818 wherein the server system 102 transmits the HTML response to the web server 800, to block 820 wherein the web server 800 processes the HTML response to render the transactional data loaded into the container objects using any suitable client specific format, and then to communication path 822 wherein the web server 800 transmits the formatted response to the client computer 106.

The client computer 106 processes the response as shown in block 824 and causes the transactional page 436 to be displayed on the user interface for the display screen 128 of the client computer 106 as separately shown in subsequent block 826.

The transactional page 436 contains all transactional data which are loaded into the container objects by the server system 102. The transactional data corresponding to the transactional page 436 may be accessed locally from a resident memory device, an external memory device or a network storage device associated with the server system 102, or may be accessed remotely from a content server computer system (not illustrated in the accompanying drawings) over any suitable communication network such as the IP- based network.

THE COMPUTER-IMPLEMENTED SYSTEM The data processing system between the client computer 106 and the server system 102 consistent with the operations described herein is illustrated in the block diagram of Figure 9. Particularly, the data communication system illustrated in Figure 9 shows hardware and software components which interact with one another to process various data and objects in accordance with one or more implementations of the present invention.

The data processing system may refer to a system for implementing hierarchically assemblable and selectable menu items in the object-oriented transactional framework 100. The system comprises the server system 102 having the server processor 108 and the server memory system 110 which are in operative communication with one another through appropriate circuitries and signaling methods. The server memory system 110 contains computer-executable instructions which are executable by the server processor 108 from the server memory system 110.

When the instructions are executed by the server processor 108, the server system 102, at run-time, is firstly configured to invoke the tree structure 410 characterizing the cooperating objects 412, 414, 416 corresponding to the menu items in response to the request from the client application 104 executing on the client computer 106 for information relating to the cooperating objects 412, 414, 416, wherein the cooperating objects 412, 414, 416 are grouped into a plurality of transaction paths, and wherein each transaction path of the plurality of transaction paths represents the transaction instance of the electronic transaction in the transactional framework 100. The transactional framework 100 may be stored in the server memory system 110.

When the instructions are further executed by the server processor 108, the server system 102, at run-time, is additionally configured to provide the menu items in a sequentially assembled form for each of the transaction paths beginning with the category object 412 of the cooperating objects 412, 414, 416 corresponding to the attribute of the transactional framework 100, continuing with the user account object 414 of the cooperating objects 412, 414, 416 corresponding to the user account upon which the transaction can be conducted, and ending with the action object 416 of the cooperating objects 412, 414, 416 corresponding to a task request associated with the transaction instance in the transactional framework 100.

When the instructions are further executed by the server processor 108, the server system 102, at run-time, is additionally configured to generate and transfer to the client application 104 codes which are arranged to render the sequentially assembled menu items on the user interface for the display screen 128 of the client computer 106. The codes may be generally associated with the tree structure 410, and may be particularly associated with how the tree structure 410 should be rendered on the user interface for the display screen 128 of the client computer 106. The codes may be HTML codes or other codes which are specific to the configuration of any one or both of the client application 104 and the client computer 106. The server system 102 and the client computer 106 may communicate with one another over any suitable data communication network such as the well-known IP-based network. The web server 800 may act as an intermediary device between the client application 104 running on the client computer 106 and the server system 102. The client application 104, or any temporary files associated with it, may be stored on the client memory system 204, 302. The client processor 202, 300 may be used to specifically run the client application 104 on the client computer 106 from the client memory system 204, 302. The client application 104 may be a web browser, a mobile site browser, or a mobile application. The server system 102 may include a tree structure manager 900 which manages the manner by which the tree structure 410 corresponding to the computer-renderable menu items should be rendered on the user interface for the display screen 128 of the client computer 106 and which likewise manages the transaction paths defined by the arrangements of the cooperating objects 412, 414, 416 beginning from the category objects 412, continuing with the user account objects 414, and ending with the action objects 416. The tree structure manager 900 may act as a sub-component of the tree structure engine 422.

The data storage system 112 of the server system 102, which may include one or more clusters of interrelated databases, may be used to store the tree data 418 associated with the leaf of the tree structure 410. The data storage system 112 may also be used to store meta-data or data from third-party resources associated with the tree structure 410 representing the menu items.

The server system 102 may also include an access manager 902 in operative communication with the server processor 108 and the server memory system 110. The access manager 902 may be used to manage APIs or application programming interfaces 904 and as well as authorization or permission rules 906. Access to one or more features and services of the transactional framework 100 as provided by the server system 102 may be managed, regulated or restricted based on one or more user credentials associated with the individual user accounts registered with the transactional framework 100 and owned by account holders.

The server system 102 may also include an administrator interface 908 which may enable an administrator, developer or programmer to access and/or modify the features and services of the transactional framework 100 and the authorization rules 906.

EXEMPLARY OPERATION IN THE SOFTWARE DEVELOPMENT AND EXECUTION ENVIRONMENT

A flow diagram illustrating an exemplary operation in the software development and execution environment of Figure 4 is shown in Figures 10- A, 10-B, and 10-C. At step 1000, the operation starts with displaying graphical representation of the class tree structure 410 based on a default package upon receiving request to do so from a programmer and/or developer of the transactional framework 100.

The default package is provided with computing resources that can be loaded into the software development device 400 for utilization by the software development tool 408, and can be rendered graphically on the software execution device 404.

The class tree structure 410 included in the default package may include existing definitions of menu items and specifications of transaction paths which are associated with the menu items.

At subsequent decision step 1002, the software development tool 408 detects or determines whether it receives a selection of a new package from the developer.

If no new package is selected, the operation may proceed to step 1004 wherein all objects associated with the class tree structure 410 are displayed on the software development device 400 or on the software execution device 404. Otherwise, the operation may be redirected to decision step 1006 wherein the software development tool 408 is arranged to determine whether the selected new package is locally accessible and available for execution on the software development device 400.

If the new package is locally accessible, the operation may advance to step 1008 wherein the software development tool 408 causes retrieval of the new package from a local resource associated with the software development device 400. The local resource may be any one of a resident memory device, an external memory device or a network storage device in operative communication with the hardware and software components of the software development device 400.

If the new package is not locally accessible, the operation may instead advance to step 1010 wherein the software development tool 408 causes retrieval of the new package from a remote resource in communication with the software development device 400. The remote resource may be a remote content server distinct from the server system 102 or a cloud-based server communicating with the server system 102 over any suitable communication network. The retrieved package from the remote resource may be stored locally on the software development device 400 as shown in step 1012. Succeeding any of the steps 1008 and 1012, the class tree structure 410 may be extracted from the retrieved and stored new package as shown in step 1014. Following the extraction of the class tree structure 410 from the new package is the displaying of at least the cooperating objects 412, 414, 416 associated with the class tree structure 410 as shown in the step 1004. Arrangements and attributes of the displayed objects 412, 414, 416 corresponding to the computer-renderable menu items are manipulable and assemblable using the software development device 400 or other device executing the software development tool 408. The developer may form transaction paths by assembling the objects 412, 414, 416 beginning with the category objects 412, continuing with the user account objects 414, and ending with the action objects 416. The cooperating objects 412, 414, 416 may be assembled and manipulated individually by selecting and moving them through hierarchical levels in the transactional framework 100.

At decision step 1016 which succeeds the step 1004, the software development tool 408 detects whether it receives a selection of at least one category object 412 to be manipulated. If one category object 412 is selected for manipulation, the operation proceeds to another decision step 1018 wherein the software development tool 408 determines whether the category object 412 is manipulated by the developer, and then to subsequent step 1020 wherein modifications are stored on the software development device 400 if the category object 412 is manipulated as determined in the previous decision step 1018.

If the category object 412 is not selected as determined in the previous decision step 1016, or if the selected category object 412 is not manipulated as determined in the previous decision step 1018, or the modifications against the manipulated category objects 412 are stored as shown in the previous step 1020, the operation may move to decision step 1022 wherein the software development tool 408 determines whether at least one of the user account objects 414 is selected by the developer for manipulation. If the user account object 414 is not selected by the developer for manipulation as determined in the previous decision step 1022, the operation may proceed to decision step 1028 wherein it is determined by the software development tool 408 whether at least one of the action objects 416 is selected by the developer for manipulation. Otherwise, if the user account object 414 is selected by the developer for manipulation as determined in the previous decision step 1022, the operation may move to decision step 1024 wherein it is determined whether the selected user account object 414 is manipulated.

If there is a manipulation of the user account object 414 as determined in the decision step 1024 upon determination of selection of the same user account object 414 in the decision step 1022, the operation may advance to step 1026 wherein all the modifications against the user account object 414 are stored on the software development device 400 using the software development tool 408.

If the selected user account object 414 is not manipulated as determined in the decision step 1024, or following the storing of the modifications against the user account object 414 in the step 1026, the operation may progress to the decision step 1028 wherein the software development tool 408 determines whether at least one of the action objects 416 is selected by the developer for manipulation.

Again, if no user account object 414 is selected as determined in the previous decision step 1022, the operation may directly proceed to the decision step 1028 for the determination of the selection of at least one action object 416 for potential manipulation by the developer using the software development tool 408.

If an action object 416 is selected as determined in the decision step 1028, the operation may move forward to another decision step 1030 in order to determine whether the selected action object 416 is manipulated. A determined manipulation of the selected action object 416 in the decision step 1030 may cause the operation to continue to step 1032 for storing on the software development device 400 all modifications made by the developer against the selected action object 416 and, consequently, to step 1034 for displaying of class definitions for the class tree structure 410 based on the possible modifications or manipulations made against any one or all of the category, user account, and action objects 412, 414 and 416.

If no action object 416 is selected as determined in the previous decision step 1028, or if no action object 416 is manipulated as determined in the previous decision step 1030, the operation may be redirected to the step 1034 for causing the display of the class definition for the class tree structure 410 based on any possible modifications or manipulations made against the action object 416.

The modifications or manipulations that can be made against any of the category, user account and action objects 412, 414, 416 may be characterized by a change in the position or location of any one of the same sets of objects in the class tree structure 410. A change in the position or location of one object 412, 414 or 416 may cause a change in at least one transaction path of the plurality of transaction paths defined in the class tree structure 410.

Any one of the displayed class definitions associated with the any one or more of the category, user account and action objects 412, 414, 416 may then be modified by the developer or programmer.

The assembling step of the method of implementing hierarchically assemblable and selectable menu items consistent with one or more implementations of the present invention may include providing the object definition 418 of each of the category object 412, the user account object 414, and the action object 416 by means of a template. The object definition in the template may be characterized by any of an attribute, a relation, and a method, each of which is well-known in the art of object-oriented programming.

The provision of the template through which the object definition can be provided ensures simplification of various processes associated with data inspection, data selection, and command execution relating to the cooperating objects 412, 414, 416. If the software development tool 408 receives no selection of a valid class definition associated with any one of the cooperating objects 412, 414, 416 in decision step 1036 which succeeds the previous step 1034, the operation may be proceed directly to step 1038 wherein an instance of the class is consequently added to the transactional framework 100.

Otherwise, a selection of a valid class definition associated with any one of the cooperating objects 412, 414, 416 as determined in the decision step 1036, the operation may proceed to decision step 1040 wherein it is determined whether the selection of the class definition is an attribute, to another decision step 1042 wherein it is determined whether the attribute is modified upon determination that the selected definition is indeed an attribute, and then to step 1044 for storing on the software development device 400 all modifications made against the attribute of any of the cooperating objects 412, 414, 416 in the transactional framework 100.

If the definition is not an attribute as determined in the previous decision step 1040, or if a selected attribute is not modified as determined in the previous decision step 1042, or following the storing of the modified attribute in the step 1044, the operation may proceed to decision step 1046 wherein it is determined whether the selection of the class definition is a relation, to another decision step 1048 wherein it is determined whether the relation is modified upon determination that the selected definition is indeed a relation, and then to step 1050 for storing on the software development device 400 all modifications made against the relation of any of the cooperating objects 412, 414, 416 in the transactional framework 100. If the definition is not a relation as determined in the previous decision step 1046, or if a selected relation is not modified as determined in the previous decision step 1048, or following the storing of the modified relation in the step 1050, the operation may proceed to decision step 1052 wherein it is determined whether the selection of the class definition is a method, to another decision step 1054 wherein it is determined whether the method is modified upon determination that the selected definition is indeed a method, and then to step 1056 for storing on the software development tool 408 all modifications made against the method of any of the cooperating objects 412, 414, 416 in the transactional framework 100.

If the definition is not a method as determined in the previous decision step 1052, or if the method is not modified as determined in the previous decision step 1054, or following the storing of the modified method in the step 1056, the operation may advance to step 1058 wherein the graphical representation of the class tree structure 410 is modified in accordance with one or more modifications made against any one or more of the attribute, relation, and method associated with any one or more of the category objects 412, the user account objects 414, and the action objects 416 which are associated with the tree structure 410 in the transactional framework 100.

If the instance of the class is completed as determined in subsequent decision step 1060, the operation may move to addition of the instance of the class to the transactional framework 100 as shown in the step 1038. Otherwise, if the instance of the class is not yet completed based on the preferred design of the developer or programmer, the operation may be reverted back to the step 1004 wherein the cooperating category, user account and action objects 412, 414, 416 associated with the class tree structure 410 are displayed for possible manipulation by the developer.

As shown in subsequent decision block 1062, it is determined whether the programming task associated with the development of the class tree structure 410 relating to the transactional framework 100 is completed. The operation concludes upon completion of the programming tasks as determined in the decision block 1062. Otherwise, if the programming task is not yet completed, the operation may start all over again from the previously illustrated step 1000. Further examples of hierarchically assembled menu items in accordance with one or more implementations of the present invention are depicted in Figures 11 and 12 showing alternative representations of exemplary and non-limiting user interfaces.

In Figure 11 alone, some hierarchically assembled menu items for an electronic transaction characterized by a person-to-person (P2P) payment are specifically depicted. P2P payment may be defined as a remote money payment between sender and recipient parties. As illustrated, the P2P payment transaction may involve menu items which are organized beginning with the category objects 412 corresponding to names of all registered recipients (e.g., Anthony, Stephen, Julia), continuing with the user account objects 414 corresponding to user accounts of each and every recipient of the registered recipients (e.g., prepaid account, savings account, checking account), and ending with the action objects 416 corresponding to all registered action items (e.g., send money, request money, send load, request load). For the "send and request load" action items, references to mobile telephone or cellular numbers may be readily associated with the user accounts or be required to be entered separately. Although not illustrated, menu items relating to the user accounts may also include user account objects 414 which correspond to the accounts of the sender.

In Figure 12 alone, some hierarchically assembled menu items for an electronic transaction characterized by bills payment are specifically depicted. As illustrated, the bills payment transaction may involve menu items which are organized beginning with the category objects 412 corresponding to names of all registered category of billers (e.g., cable and internet, utilities, government, etc.) and names of billers or service providers (e.g., Maynilad Water Services Inc., Clark Water Corporation, Meralco, etc.), continuing with the user account objects 414 corresponding to the payee's registered user accounts associated with the billers (e.g., consumer accounts), and ending with the action objects 416 corresponding to all registered action items (e.g., pay bills, view statement, update personal information, etc.). Although not illustrated, menu items relating to the user accounts may also include user account objects 414 which correspond to the accounts of the payee or the person initiating the payment.

While the present invention has been described with respect to a limited number of implementations/embodiments, those skilled in the art, having benefit of this disclosure, will appreciate that other implementations/embodiments can be devised which do not depart from the scope of the present invention as disclosed herein.

Claims

A METHOD OF IMPLEMENTING HIERARCHICALLY ASSEMBLABLE AND SELECTABLE MENU ITEMS IN AN OBJECT-ORIENTED TRANSACTIONAL FRAMEWORK CLAIMS

1. A method, performed by an application server computer system (102) at runtime, of implementing hierarchically assemblable and selectable menu items in an object-oriented transactional framework (100), the method comprising the steps of: invoking a tree structure (410) characterizing cooperating objects (412, 414, 416) corresponding to the menu items in response to a request from a client application (104) executing on a client computer (106) for information relating to the cooperating objects (412, 414, 416), the cooperating objects (412, 414, 416) being grouped into a plurality of transaction paths, each transaction path of the plurality of transaction paths representing a transaction instance of an electronic transaction in the transactional framework (100); providing the menu items in a sequentially assembled form for the each transaction path beginning with at least one category object (412) of the cooperating objects (412, 414, 416) corresponding to an attribute of the transactional framework (100), continuing with at least one user account object (414) of the cooperating objects (412, 414, 416) corresponding to a user account upon which the transaction can be conducted, and ending with at least one action object (416) of the cooperating objects (412, 414, 416) corresponding to a task request associated with the transaction instance; and generating and transferring to the client application (104) codes arranged to render the sequentially assembled menu items on a user interface for a display screen (128) of the client computer (106).

2. The method according to claim 1, further comprising the step of activating and rendering on the user interface for the display screen (128) of the client computer (106) a transactional page (436) corresponding to a leaf of the tree structure (410) in response to a selection of a menu item from the sequentially assembled menu items.

3. The method according to claim 1, wherein the providing step includes defining an object definition (418) of any one or more of the category object (412), the user account object (414), and the action object (416) by means of a template.

4. The method according to claim 1, wherein the rendering step includes fitting a plurality of category objects (412) associated with the plurality of the transaction paths on the user interface for the display screen (128) of the client computer (106). The method according to claim 4, wherein the rendering step includes fitting a plurality of user account objects (414) associated with one of the plurality of the category objects (412) on the user interface for the display screen (128) of the client computer (106).

The method according to claim 5, wherein the rendering step includes fitting a plurality of action objects (416) associated with one of the plurality of the user account objects (414) on the user interface for the display screen (128) of the client computer (106).

The method according to claim 1, wherein the sequentially assembled form is based on a pre-determined configuration of the menu items.

The method according to claim 5, wherein the plurality of the user account objects (414) are selected from the group consisting of bank account objects, credit card account objects, investment account objects, mutual fund account objects, brokerage account objects, loan account objects, mortgage account objects, electronic commerce account objects, escrow account objects, fund raising account objects, social media account objects, educational account objects, insurance account objects, charitable account objects, loyalty program account objects, membership account objects, privilege card account objects, gift card account objects, subscription account objects, identification account objects, payroll account objects, utility account objects, and fund transfer account objects.

The method according to claim 8, wherein the bank account objects include any of deposit account objects, savings account objects, debit account objects, credit account objects, checking account objects, prepaid card account objects, cash card account objects, stored value card account objects, and sponsor-funded stored value card account objects.