FreshPatents.com Logo
stats FreshPatents Stats
1 views for this patent on FreshPatents.com
2013: 1 views
Updated: October 13 2014
newTOP 200 Companies filing patents this week


    Free Services  

  • MONITOR KEYWORDS
  • Enter keywords & we'll notify you when a new patent matches your request (weekly update).

  • ORGANIZER
  • Save & organize patents so you can view them later.

  • RSS rss
  • Create custom RSS feeds. Track keywords without receiving email.

  • ARCHIVE
  • View the last few months of your Keyword emails.

  • COMPANY DIRECTORY
  • Patents sorted by company.

Follow us on Twitter
twitter icon@FreshPatents

System and method of relating resources and business objects of different business object types

last patentdownload pdfdownload imgimage previewnext patent


20130036361 patent thumbnailZoom

System and method of relating resources and business objects of different business object types


A system and method of relating resources and business objects. The method includes storing business objects by a first application server and a second application server, where the first application server is configured to access a business object of a first business object type and the second application server is configured not to access the business object of the first business object type. The method further includes storing resources, and relationships between the business objects and the resources. The method further includes generating an object view in which, for a selected business object, a first relationship is editable according to a first user input, where the first relationship relates the selected business object to one of the resources. The method further includes generating a resource view in which, for a selected resource, at least one associated business object and at least one associated relationship are viewable, where the at least one associated relationship relates the selected resource and the at least one associated business object. In this manner, resources may be scheduled despite the underlying applications not being able to access all the types of business objects.
Related Terms: Application Server Server Business Objects User Input

Browse recent Sap Ag patents - Walldorf, DE
USPTO Applicaton #: #20130036361 - Class: 715738 (USPTO) - 02/07/13 - Class 715 
Data Processing: Presentation Processing Of Document, Operator Interface Processing, And Screen Saver Display Processing > Operator Interface (e.g., Graphical User Interface) >For Plural Users Or Sites (e.g., Network) >Network Resource Browsing Or Navigating

Inventors: Stefan Manuel Fischer

view organizer monitor keywords


The Patent Description & Claims data below is from USPTO Patent Application 20130036361, System and method of relating resources and business objects of different business object types.

last patentpdficondownload pdfimage previewnext patent

CROSS REFERENCE TO RELATED APPLICATIONS

Not applicable.

BACKGROUND

1. Field of the Invention

The present invention relates to resource management, and in particular, to resource management using business object types.

2. Description of the Related Art

Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

Scheduling employees to work at a business location is often automated. When multiple employees are available to work at multiple locations, the scheduling system may perform load balancing to allocate similar coverage of employees to all the locations. An example of this type of system is described in U.S. Application Pub. No. 2005/0137927.

Additionally, scheduling the time of individual employees is often automated. When an employee is available within a larger time period, the employee\'s time may be scheduled into shorter time periods. The scheduling system may receive a first request providing the availability within the larger time period, may receive a second request providing a desired availability within a shorter time period, and may then perform scheduling to take both these requests into account when scheduling the employee\'s time. An example of this type of system is described in U.S. Application Pub. No. 2005/0222884.

SUMMARY

Given the above background, there is a need to assign resources to projects in ways other than when the projects are all stored by the same homogeneous computing environment.

One embodiment includes a method of relating resources and business objects. The method includes storing business objects by a first application server and a second application server, where the first application server is configured to access a business object of a first business object type and the second application server is configured not to access the business object of the first business object type. The method further includes storing resources, and relationships between the business objects and the resources. The method further includes generating an object view in which, for a selected business object, a first relationship is editable according to a first user input, where the first relationship relates the selected business object to one of the resources. The method further includes generating a resource view in which, for a selected resource, at least one associated business object and at least one associated relationship are viewable, where the at least one associated relationship relates the selected resource and the at least one associated business object. In this manner, resources may be scheduled despite the underlying applications not being able to access all the types of business objects.

The user input may add (or remove) resources (from a selected business object) or business objects (from a selected resource) by editing the relationships. The relationships may be edited by editing their relationship attributes. The application servers may be heterogeneous.

A system may perform the above method. The system may include a number of application servers that are configured to perform steps of the method, e.g., as one or more hardware servers executing one or more computer programs.

A non-transitory computer readable medium may store instructions that correspond to the above method. The instructions may be arranged as subprograms or components that may be executed by one or more application servers (which may be implemented by one or more hardware servers).

An embodiment may have one or more of the following features. First, it allows for resource assignment in a heterogeneous environment. (Otherwise the heterogeneous components would each need to be modified to work with each other heterogeneous component.)

Second, it allows for resource scheduling for newly-added applications. When a new type of business object is added, the tools used to create the new application may be the same tools used to access that new business object type in the scheduling program. (Otherwise the newly-added application may have a new type of business object that requires reprogramming of the scheduling application before the scheduling application can access the new type of business object; or reports from both applications must be generated and then combined together.) For example, Company X has a project management system (for tracking projects) and a customer relationship management system (for tracking sales orders) that are staffed from the same set of employees; an embodiment may be used to generate a consistent view of the assigned employees to both sales orders and projects.

Third, it allows for one consistent view on resources in a heterogeneous environment. (Otherwise each heterogeneous application would need to be modified according to each other heterogeneous application in order to pull the resource data from the other heterogeneous applications.)

Fourth it easily allows extension to new entities to assign (“schedule”) resource against. The benefit of this is greater flexibility for workforce dominated companies (usually service providers) working in heterogeneous lines of business.

The following detailed description and accompanying drawings provide a better understanding of the nature and advantages of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a system for relating resources and business objects, according to an embodiment.

FIG. 2 is a block diagram of a three tier architecture system that may be used to implement an embodiment.

FIG. 3 is flowchart of a method of relating resources and business objects, according to an embodiment.

FIG. 4 shows an example of an object view, according to an embodiment.

FIG. 5 shows an example of a resource view, according to an embodiment.

FIG. 6 is a block diagram of an example computer system and network for implementing embodiments.

DETAILED DESCRIPTION

Described herein are techniques for relating resources and business objects in an enterprise data processing environment. In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.

In this document, various methods, processes and procedures are detailed. Although particular steps may be described in a certain order, such order is mainly for convenience and clarity. A particular step may be repeated more than once, may occur before or after other steps (even if those steps are otherwise described in another order), and may occur in parallel with other steps. A second step is required to follow a first step only when the first step must be completed before the second step is begun. Such a situation will be specifically pointed out when not clear from the context. A particular step may be omitted; a particular step is required only when its omission would materially impact another step.

In this document, the terms “and”, “or” and “and/or” are used. Such terms are to be read as having the same meaning; that is, inclusively. For example, “A and B” may mean at least the following: “both A and B”, “only A”, “only B”, “at least both A and B”. As another example, “A or B” may mean at least the following: “only A”, “only B”, “both A and B”, “at least both A and B”. When an exclusive-or is intended, such will be specifically noted (e.g., “either A or B”, “at most one of A and B”).

In this document, various computer-implemented methods, processes and procedures are described. It is to be understood that the various actions (receiving, storing, sending, communicating, displaying, etc.) are performed by a hardware device, even if the action may be authorized, initiated or triggered by a user, or even if the hardware device is controlled by a computer program, software, firmware, etc. Further, it is to be understood that the hardware device is operating on data, even if the data may represent concepts or real-world objects, thus the explicit labeling as “data” as such is omitted. For example, when the hardware device is described as “storing a record”, it is to be understood that the hardware device is storing data that represents the record.

The term “business object” is used in this document. Whereas a computer program may implement classes (which typically end in objects managing or executing behaviors), a business object usually does nothing itself but instead holds a set of instance variables or properties (also known as attributes) and associations with other business objects, weaving a map of objects representing the business relationships. In general, a business object is a code construct (e.g., a data structure) that corresponds directly to a thing in the actual business, where the business uses software (e.g., a computer program) to manipulate the business object as real-world activities take place that are related to the thing. The business object encapsulates the business logic related to the thing, and encapsulates the data that is required by the logic and also describes, defines, makes up, is contained by, or is associated with the thing. In general, the “thing” is recognizable to a non-technical person familiar with the business, like the users, business analysts, etc. For example, in a video rental store business assume things such as video discs, console games, customers, rental orders, late fees, etc. In software representing that business there would be business objects that represent video discs, console games, customers, rental orders, late fees, etc. Each object has data that describes or is attributed to the object and methods that make decisions based on that data. For example, a video disc may have a Title and DateReleased attributes (data), and may have the method <calculate rental price> to determine how much it costs to rent the video disc. Things may be tangible objects with real-world meanings (such as the video discs discussed above), or may be conceptual objects that relate to the business and its business processes (such as a rental agreement or a rental policy).

The general term “business object” may be more precisely stated by using two other terms: business object instance and business object type. A business object instance refers to a specific business object, often including specific data, that is processed by the data processing system; whereas a business object type refers to a general class of business object which may itself serve as a template for business object instances. Example business object types include a purchase order, a sales order, etc.; corresponding instances include a specific purchase order with specific data, a specific sales order with specific data, etc. Embodiments use both business object types (e.g., a particular application may not be configured to access business objects of a particular type) as well as business object instances (e.g., a relationship may link a business object instance with another object); often the general term “business object” may be used to describe both since the more precise term is clear from the context.

The term “resource” is used in this document. In general, a resource may perform (or may be used to perform) an activity in a business or workplace context. A common example of a resource is employees (human resources), etc. A resource may be a type of business object, e.g., an employee business object accessed by a human resources application server.

The term “heterogeneous” is used in this document. In general, two things are heterogeneous when there exists a structural or functional difference between them such that there is no direct interaction between the two things. For example, heterogeneous computer systems may have different hardware (e.g., IBM™ hardware and HP™ hardware).

Heterogeneous computer systems may execute different operating systems (e.g., Linux™ operating system and Microsoft Windows™ operating system). Heterogeneous computer systems may execute different application programs (e.g., an inventory management application and a customer relationship management application). Indirect interaction between heterogeneous computer systems may be provided via a network. For example, each computer system is configured to connect to the network, and thus is ambivalent regarding the structure or function of the other computer system. A single hardware device may execute heterogeneous application programs that interact indirectly, for example via a common operating system.

A system may also be heterogeneous when it uses two (or more) types of business objects, one type of which is accessed by one subsystem (application, etc.) and another type of which is accessed by the other subsystem (application, etc.), and one subsystem cannot directly access the type of business objects accessed by the other. For example, two applications may be heterogeneous when one application is not configured to access (e.g., is unable to access) a particular type of business object that the other application is configured to access. In addition, the two different types of business objects may be described as being heterogeneous.

Heterogeneous may be contrasted with homogeneous. Note that many existing resource scheduling systems, such as those described in the Background, are homogeneous systems and thus omit the descriptor “homogeneous”. In the absence of the descriptor “homogeneous”, one of ordinary skill in the art may recognize a homogeneous system by its features. For example, if a scheduling system has only a single application, that system is homogeneous because all business objects stored by that system are accessible by that single application. As another example, if the business objects in a system are all directly accessible by two different applications in the system, those applications are homogeneous. As a further example, if a particular type of business object in a system is directly accessible by two different applications in the system, those applications are homogeneous with respect to that particular type of business object.

The terms “resource scheduling” and “resource assignment” are used in this document. These terms are generally synonymous, except as follows: Resource scheduling more precisely refers to an automated (machine-made) relation between a resource and a business object, whereas resource assignment more precisely refers to a non-automated (non-machine-made) relation between a resource and a business object. Such precision is not usually required for certain embodiments, or the intended term may be clear from context, so the following description generally uses the two terms interchangeably.

FIG. 1 is a block diagram of a system 100 for relating resources and business objects, according to an embodiment. FIG. 1 is a functional diagram from the perspective of the applications; specific hardware implementations of the system 100 are shown in FIG. 2 and FIG. 6. The system 100 includes an application 102, an application 104, an application 105, an application 106, and storage 108.

The storage 108 stores data used by the applications 102, 104, 105 and 106. This data includes business objects 112, resources 114, and relationships 116 between the business objects 112 and the resources 114. The business objects 112 have more than one type, and not all of the applications 102 and 104 are able to access all types of business objects (e.g., the applications 102 and 104 are heterogeneous). More specifically, the application 102 accesses the business objects 112a (read/write) but cannot access the business objects 112b; the application 104 accesses the business objects 112b (read/write) but cannot access the business objects 112a; both applications 102 and 104 may access the business objects 112c; the application 105 accesses the resources 114 (read/write); and the application 106 accesses the business objects 112 (read), the resources 114 (read), and the relationships 116 (read/write). The storage 108 may be implemented by one or more hardware devices as shown in FIG. 2 and FIG. 6.

Examples of the applications 102 and 104 include an invoice processing application, a supply chain management application, a customer relationship management application, etc. Although two applications 102 and 104 are shown, the system 100 may implement any number of applications. An example of the application 105 is a human resources application. The application 106 is a scheduling application. More details of the application 106 are provided below with reference to FIG. 3. The applications 102, 104, 105 and 106 receive input (e.g., from users) and generate output (e.g., views of data to users).

As a more specific example, assume that application 102 is an order management system managing one type of business object 112a (sales orders, including a specific Sales Order #334455); application 104 is a service management system managing another type of business object 112b (service orders, including a specific Service Order #998877); the application 105 is a human resources system managing the resources 114 (human resources, including a specific human resource John Doe); and the application 106 is a scheduling system managing the relationships 116. The scheduling system (application 106) manages a first relationship between Sales Order #334455 and John Doe, and a second relationship between Service Order #998877 and John Doe.

The applications 102 and 104 are heterogeneous applications. As heterogeneous applications, the business objects 112 accessed (edited, created, deleted, changed, manipulated, etc.) by one application may not be directly accessed by the other application. For example, an invoice processing application 102 accesses invoice business objects 112a, and a customer relationship management application 104 accesses customer business objects 112b; the invoice processing application is unable to directly access the customer business objects, and the customer relationship management application is unable to directly access the invoice business objects.

Access to business objects may be implemented in various ways, depending in large part upon the specific software and hardware choices made to implement the system 100 (see, e.g., FIG. 2 and FIG. 6). One way to implement access is via application programming interfaces (APIs). For example, the server that implements the applications 102 and 104 may implement a common programming environment that uses APIs to build applications; the applications 102 and 104 are then built using those APIs and execute in the common programming environment.

The system 100 may have different APIs for accessing different types of business objects 112a and 112b. For example, a project management application uses the APIs specific to project structure business object (or to be precise: business objects of this business object type), and a customer relationship management application uses the APIs specific to sales order business objects. Since the project management processing application does not use the APIs specific to the sales order business objects, the project management application does not have direct access to the sales order business objects. Since the customer relationship management application does not use the APIs specific to the project structure business objects, the customer relationship management application does not have direct access to the project structure business objects. Thus, the project management application and the customer relationship management application are heterogeneous applications.

As a more specific example, the system 100 may implement a SAP NetWeaver™ environment in which access to business objects is provided by BAPIs (Business Application Programming Interfaces). The system 100 may then use the BAPIs to implement various SAP NetWeaver™ applications, such as applications for supplier relationship management, customer relationship management, supply chain management, product lifecycle management, enterprise resource management, business intelligence, identity management, and master data management.

FIG. 2 is a block diagram of a three tier architecture system 200 that may be used to implement an embodiment. The system 200 includes a presentation tier 202, an application tier 204, and a database tier 206. A network 208 connects the devices within and between the tiers. The network 208 may include one or more networks, such as a local area network, a wide area network, or the internet.

The presentation tier 202 generally includes one or more client computers 212. The client computers 212 generally provide a graphical user interface for users to interact with the other parts of the system 200. The user interface may be implemented by a browser, for example as a Java application.

The application tier 204 generally includes one or more application servers 214. The application servers 214 generally implement the business logic for processing interactions between the users and the underlying data. This business logic is generally referred to as “the application” or “the application program”. The application tier 204 may implement various applications to perform various functions, such as invoicing, inventory control, supply chain management, etc. Various of the application servers 214 may perform different functions. For example, one of the application servers 214 may be used for prototyping or development, while the others may be used for business intelligence production activities.

The database tier 206 generally includes one or more database servers 216. The database servers 216 generally implement a database management system that stores and manipulates the underlying data and related metadata. This database management system is generally referred to as “the database” or “the database system” or “the database program”. The database servers 216 may implement various types of database systems, including DB2, Informix, SAP MaxDB, Oracle and Microsoft SQL Server™.



Download full PDF for full patent description/claims.

Advertise on FreshPatents.com - Rates & Info


You can also Monitor Keywords and Search for tracking patents relating to this System and method of relating resources and business objects of different business object types patent application.
###
monitor keywords



Keyword Monitor How KEYWORD MONITOR works... a FREE service from FreshPatents
1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored.
3. Each week you receive an email with patent applications related to your keywords.  
Start now! - Receive info on patent apps like System and method of relating resources and business objects of different business object types or other areas of interest.
###


Previous Patent Application:
System and method for providing supplemental content related to printed content in a printed publication
Next Patent Application:
Wireless audience response device
Industry Class:
Data processing: presentation processing of document
Thank you for viewing the System and method of relating resources and business objects of different business object types patent info.
- - - Apple patents, Boeing patents, Google patents, IBM patents, Jabil patents, Coca Cola patents, Motorola patents

Results in 0.53503 seconds


Other interesting Freshpatents.com categories:
Electronics: Semiconductor Audio Illumination Connectors Crypto

###

Data source: patent applications published in the public domain by the United States Patent and Trademark Office (USPTO). Information published here is for research/educational purposes only. FreshPatents is not affiliated with the USPTO, assignee companies, inventors, law firms or other assignees. Patent applications, documents and images may contain trademarks of the respective companies/authors. FreshPatents is not responsible for the accuracy, validity or otherwise contents of these public document patent application filings. When possible a complete PDF is provided, however, in some cases the presented document/images is an abstract or sampling of the full patent application for display purposes. FreshPatents.com Terms/Support
-g2-0.2202
     SHARE
  
           

FreshNews promo


stats Patent Info
Application #
US 20130036361 A1
Publish Date
02/07/2013
Document #
13196164
File Date
08/02/2011
USPTO Class
715738
Other USPTO Classes
International Class
/
Drawings
7


Application Server
Server
Business Objects
User Input


Follow us on Twitter
twitter icon@FreshPatents