Patent Application
20070203718
A business needs to have a clear understanding of the often complex nature of its business operations in order to be successful. Various mechanisms have been developed to model and represent a business. Some mechanisms include manual generation of diagrams that represent business processes that describe how work is done. For example, all aspects of a business can be analyzed to identify business capabilities, interrelationships and interdependencies between the various business operations. Based on the analysis, representative diagrams can be generated which graphically illustrate a business architecture and process flow.
However, accurate analysis of a business from a business process point of view can often take a long time to put together, and since many business processes are dynamic, changing over time, a manually generated representation of business processes may be outdated even before it is completed. Further, even if a manually generated representation of business processes were accurate at the time it was completed, changes in business processes after the business representation is generated would lead to inaccuracies in the business representation. And once representative diagrams are generated, such diagrams are not easily modified without a further investment of time, effort and resources. Thus, manually generated representations provide limited ability for a business to understand its current operations and/or determine how actual or hypothetical changes to various business capabilities would affect the business.
At least in part as a result of the above-described deficiencies, some software application programs have been developed to generate representations of business architectures. These application programs use various techniques to model and represent a business, mostly focusing on modeling business processes and detailed procedures that support those processes. Some of these application programs generate a graphical view of business processes for display over a graphical user interface. To some limited extent, these graphical views can be altered to simulate the effect of a change in different business capabilities on a business.
A shortcoming of some of these application programs is that they describe a business in terms of “how” the business is executed, focusing for example on organizational structure, procedures and process flows. In so doing, much of the detail and granularity of the business may be lost or subsumed into these categories. In particular, businesses generally include some measure of vertical and horizontal integration of layers, and may have many interrelated business units. In focusing a business model in terms of how the business is executed, much of the vertical and horizontal layering and interrelation of different units may be lost. A change in these aspects of a business may be critical, but may nonetheless be obscured in such business models.
Moreover, how a business operates may change over time, and thus criteria such as organizational structure, procedures and process flows to describe a business are relatively unstable. The useful life time of a model of a business architecture is only as valid as the least stable input.
Further, many application programs for modeling business architectures include hard-coded data types and hard-coded representations for business modeling input data. These hard-coded data types and representations can be difficult to alter without access to source code. Thus, the flexibility and extensibility of modeling businesses and generating corresponding views is limited. For example, it may be difficult to alter predefined data formats such that a business capability can be represented in a different way or such that a previously undefined business capability can be added.
An important practice in any business is the ability to keep current and knowledgeable on all applicable federal, state and local compliance regulations. It is also important for the business to have internal procedures and governance practices for ensuring compliance with these regulations, tracking costs associated with compliance, as well as understanding the consequences for non-compliance. As a few examples, businesses need to understand and have governance practices for complying with wage and labor laws, health and safety laws, environmental laws, and tax and tariff regulations. Failure to do so may result in substantial penalties or even closure. In reality, for a lot of organizations, failure to comply is less because of fraud or malice, than because of an inability to understand the specifics of governance and compliance regulations and how to map them to their business in a way that allows for proper prioritization and decision-making. And that is typically because people lack a simple way to capture the governance and compliance regulations in a consistent, structured way, and because they lack the tools to link those regulations to a stable map of their organization. This represents a known risk for many businesses, but one which they cannot quantify, or measure progress against, because of a lack of tools to enable them to measure and manage this risk.
The importance to businesses of compliance and governance practices has become even more significant in light of the implementation of the Sarbanes-Oxley Act in 2002. The Act requires the creation of internal auditing committees, as well as reporting and ethical conduct requirements for certain businesses, and provides for stern penalties and possible jail sentences for non-compliance. The Act impacts many facets of a business, including its accounting practices, IT practices, legal department, administration and management. So beyond what is for many companies an already overly complex, voluminous and growing set of regulations, Sarbanes-Oxley has added a degree of urgency to manage and report compliance—without offering much in the way of tools or guidelines with respect to how to manage that.
Current business architecture models are not well equipped to adequately define and represent regulatory business practices rigorously and consistently in a way that allows easy linkage of those regulations to the business capabilities. Nor do they have adequate mechanisms for identifying the costs of compliance and non-compliance with applicable regulations. Furthermore, under certain regulations, such as the Sarbanes-Oxley Act, a business must be able to pinpoint detailed events and practices within the business, and be able to understand and show how these events and practices affect their compliance obligations. Traditional business architecture models do not allow for this level of scrutiny, nor do they allow this level of scrutiny to be implemented in the model.
The present system, roughly described, relates to a software application program and method for providing a business architecture model which clearly identifies regulatory practices applicable to a business, and how these regulatory practices affect different aspects of a business. The business architecture model according to the present system and method may also be easily modified to model the costs and effects of compliance, non-compliance and hypothetical changes to the regulatory practices of a business.
In embodiments, the present software application program and method relating to regulatory practices makes use of, and integrates with, a recently developed paradigm for modeling businesses, referred to herein as “business capability modeling.” Business capability modeling focuses on the capabilities of a business, i.e., on “what” a business does, which criteria are more objective and stable than criteria that focus on “how” a business operates.
The stand-alone repository of regulatory practices includes regulations. Regulations may include rules with which the business must comply by law, custom, or practice recognized as binding an external agency or internally within the business. The stand-alone repository of regulatory practices may further include internal governance practices. Internal governance practices are those practices imposed by the business for complying with the regulations. A business architecture including regulatory practices may be a conceptual model, a visual model or a data model.
The data model provides a powerful operational view of a business. In embodiments, once set up, the data model itself can monitor and manage some or all aspects of a business' regulatory practices in an automated manner. For example, the model may be integrated with a business' information technology (“IT”) architecture to manage and keep track of regulatory practices, as well as to provide notifications when an event occurs related to the regulatory practices (i.e., some action to be taken to comply with an applicable regulation, some action to be taken to indicate the compliance action has or has not been taken, etc.).
The present system will now be described with reference to
In embodiments, the software application program and method of the present system may be a stand-alone repository of regulatory practices, as well as their relation to other business capabilities. This stand-alone repository of regulatory practices advantageously makes use of, and integrates neatly with, the paradigm of business capability modeling. As explained in the Background section, traditional business models that focus on “how” a business works base the models on relatively subjective and unstable criteria. Business capability modeling focuses instead on “what” a business does which is more objective and stable. Further details relating to business capability modeling are described in the following patent applications:
In general, the business capability model starts with capturing all of the capabilities that a business performs. The capabilities of a complete business may or may not coincide with the boundaries of a given corporate entity. In other words, with awareness of all of the capabilities that make up an entire business, a company may choose to outsource many areas of the business architecture, or partner with another company. Such business capabilities may include the business capability of paying its employees, the business capability of managing its inventory, and the business capability of reporting business events to stockholders, etc. These business capabilities are merely a few examples—most businesses would have many hundreds to over a thousand such business capabilities to fully describe its business architecture.
Business capabilities may cover such practices as business communications, business relationships, business dependencies, business connections (e.g., to other business capabilities), and business boundaries (between the company and other companies, or between the company and customers, or a financial services organization, and so forth). Business capability dependencies can include, for example, what needs to happen for the business capability to start (in the example of paying employees above—this capability will often have a time dependency), what needs to happen for the business capability to finish, what other business capabilities depend on the business capability. Business capability boundaries can include, for example, indications of a business capability being influenced by entities, processes, or technology internal to a business and entities (e.g., partners, suppliers, customers, financial services organizations, government organizations, etc.) external to the business.
Business capabilities may also cover measurement and analysis aspects of a business. Measurement and analysis aspects can indicate how the success of a business capability is measured, who owns the business capability, who is the customer of the business capability, notification criteria for variations in the business capability performance, workarounds if a business capability is not available, acceptable variations in inputs to and outputs of the business capability (for example, in some instances five inputs of some type may always be needed for a certain capability to start, while others may be time driven rather than volume driven—though volume can still be a valuable measure), the stability and/or volatility of the business capability (how often it changes, whether performance variations are from a common cause or not, and so forth), the importance of the business capability (does it or does it not directly relate to the key performance indicators of the organization), etc. Business capabilities may cover a wide variety of other business aspects, interrelations and practices.
Once the capabilities of a given business have been captured (and it does not have to be an exhaustive exercise for it to add significant value to an organization), each business capability may then be mapped, and related capabilities connected, to provide a conceptual model of a business which reveals in detail exactly what a business does and how those capabilities relate to each other. Two capabilities may be related to each other where a first capability may impact a second capability within the business. They may be related for example by cause and effect, consecutive events in a chain of events, vertical and horizontal association, and/or by a variety of other relationships.
The above-described capture of all business capabilities and their relation to each other provides a detailed conceptual model of a business architecture. This capture of all business capabilities and their relation may alternatively or additionally provide a detailed visual model of a business, for example over a graphical user interface or printout. For example, when displayed over a user interface, all capabilities may be represented as graphical objects on the display, such as for example graphical boxes labeled with the capability name, and related capabilities may be connected to each other by graphical lines and/or arrows.
Graphical arrows leading into a given graphical business capability represent inputs to the business capability and indicate that the given business capability is somehow impacted by the business capability to which it is connected. Likewise, graphical arrows leading away from a given graphical business capability represent outputs from the business capability, and indicate that the given business capability somehow impacts the business capability to which it is connected. Stated another way, inputs and outputs are the artifacts and events that are consumed and/or produced by business capabilities. They represent what is outward and visible about the behavior of the capabilities. Thus, for example, a “pay employee” capability may have inputs of employee name and wage, and may have an output to a financial institution or service for paying the employee. A given business capability may have multiple inputs and/or outputs. A graphical line, as opposed to an arrow, may represent two-way communication between the business capabilities.
Connections are used to represent relationships between business capabilities, and can represent a variety of different relationships between business capabilities. For example, a connection can indicate a flow of data between two digital business capabilities. A connection may represent the flow of services between two business capabilities. A connection may represent supervision of one capability over another. Other relationships are contemplated. Connections can represent a one way relationship or a two way relationship.
In a further embodiment of the business capability model, as opposed to merely representing a conceptual or visual model of a business, the business capabilities and connections may be represented in software as data to provide a robust operational model of a business architecture. The data model allows for detailed understanding of each business capability, its place in the overall business and for aggregating the capabilities into systems which allow for management, change planning and hypothetical change analysis.
In the data model, in addition to merely capturing business capabilities and their relation to other business capabilities, each business capability may be analyzed to discern its properties, or “attributes.” Attributes of a business capability are used to described the characteristics of the business capability, and may include who is responsible (or owns) the capability, the relative impact the capability has on the overall performance of the business, what events trigger the capability, what happens when the capability is triggered, etc. A business capability may have anywhere from one attribute to one-hundred or more attributes. It will be up to each organization to determine what is most valuable for them in terms of how many attributes to capture in this model.
In the data model of a business architecture, the various business capabilities, and business capability attributes for each business capability, may be stored in a database within a computing system (such as the computer system explained hereinafter with respect to
The information relating to the business capabilities and capability attributes may be formatted according to a variety of selected schemas. The schemas can be utilized to define virtually any data type for the capabilities and capability attributes, including logical, binary, octal, decimal, hexadecimal, integer, floating-point, character, character string, user-defined data types, and combinations of these data types used to define data structures. Further details relating to business capabilities, business capability attributes and formatting of capabilities and capability attributes according to a selected schema are set forth in the above-identified incorporated patent applications.
In accordance with the present system, a business architecture model may further include a stand-alone repository of regulatory practices for a business, as well as the relation of those regulatory practices to the business capabilities. In general, the regulatory practices from the stand-alone repository of regulatory practices may be integrated with the business capabilities by linking the regulatory practices to one or more business capabilities to provide a conceptual, visual and/or data model of an overall business architecture.
The stand-alone repository may be the database of the regulatory practices. In embodiments, the database of regulatory practices may be separate from or included as part of the database for the business capabilities, capability attributes, connections, etc. In an alternative embodiment, the regulatory practices may not be included in a stand-alone repository, but may be formed, integrated and stored together with the business capabilities, capability attributes, connections, etc.
The stand-alone repository of regulatory practices includes regulations. Regulations may include rules with which the business must comply by law, and/or by any custom, practice or action formally recognized as binding or enforced by an external agency or controlling authority. Regulations may also include any custom, practice or action formally recognized as binding or enforced by the business. The stand-alone repository of regulatory practices may further include internal governance practices. Internal governance practices are those practices imposed by the business for complying with the regulations. Thus, the stand-alone repository of business practices may include: 1) regulations, and 2) governance practices.
A business architecture including regulatory practices may be a conceptual model, a visual model or a data model. The conceptual model is described below with respect to
As an alternative to capturing the business capabilities and/or regulatory practices in steps 150 through 154, one or more pre-existing templates of business capabilities and/or regulatory practices may have been defined, and a group of the predefined business capabilities and/or regulatory practices may be selected from the template(s) to capture the business capabilities and/or regulatory practices that are applicable to a given business.
The conceptual business model further includes the step 156 of defining all relationships between the business capabilities identified in step 150 and the regulatory practices identified in steps 152 and 154. In general, a business capability and regulatory practice will be related if the regulatory practice impacts the business capability. This may happen a number of ways, such as for example where a certain business capability triggers compliance requirements with any applicable regulatory practice, e.g., use of certain materials may require compliance with environmental laws; hiring employees in a particular state may require compliance with minimum wage and state and federal employment laws; purchase or sale of a particular asset may be considered a material corporate event requiring reporting under the Sarbanes-Oxley Act, etc. A single regulatory practice (whether a regulation or governance practice) may affect, or relate to, multiple business capabilities, and a single business capability may be affected by multiple regulatory practices.
The present system is well suited to capturing changes that occur in the operation of a business. The conceptual model may therefore further include the step 158 of ongoing maintenance of the model. Step 158 reflects the fact that capabilities and/or regulatory practices may change, and that those changes may be easily integrated into the business model.
Embodiments of the present system for defining a visual model of a business including regulatory practices is similar to the conceptual model, but further includes the steps of graphically representing the business capabilities, the regulatory practices and the relationships in between. Thus, referring to the flowchart of
The next steps are to expose, capture and/or, in some cases, define all regulatory practices that populate the repository of regulatory practices, including all regulations that may impact an organization (step 162) as well as the internal governance practices for handling the applicable business regulations (step 164). Again, as an alternative to capturing the business capabilities and/or regulatory practices in steps 160 through 164, one or more pre-existing templates of business capabilities and/or regulatory practices may have been defined, and a group of the predefined business capabilities and/or regulatory practices may be selected from the template(s) to define the business capabilities and/or regulatory practices that are applicable to a given business. The visual business model further includes the step 166 of defining all relationships between the business capabilities and the regulatory practices.
In step 168, graphical objects may be created within a computing device to represent the business capabilities and regulatory practices. The graphical objects may for example be boxes (or other shapes) labeled with the business capability or regulatory practice. In step 170, graphical objects may be created within a computing device to represent the relationships between the various business capabilities, and between the business capabilities and the regulatory practices. The graphical objects may for example be lines and/or arrows connecting related business capabilities, and related business capabilities and regulatory practices. An arrow into a business capability or regulatory practice may represent an input to the business capability or regulatory practice. Similarly, an arrow out of a business capability or regulatory practice may represent an output from the business capability or regulatory practice. In general, information may flow from the business capabilities to the regulatory practices (i.e., arrows from the business capabilities to the regulatory practices). However, it is understood that information may flow from the regulatory practices to the business capabilities, or two-way communication between the regulatory practices and business capabilities.
Step 172 reflects the fact that capabilities and/or regulatory practices may change, and that those changes may be easily integrated into the visual model of the business architecture.
For example, Product Development capability 102a, Manage Business capability 102c, Accounting capability 102e and Manage Assets capability 102f are all impacted by SEC Compliance regulatory practice 176b, and are thus connected to SEC Compliance regulatory practice 176b. In implementation, the capabilities and regulatory practices may be captured at a more detailed level—the explicit regulatory practice may be specifically named, together with a rich set of content describing that regulatory practice at a more detailed level. As a more detailed example, a United States law (enacted as of the time of filing of the application for this patent), set forth at 18 U.S.C. § 1350, sets forth requirements for corporate officers of a business to certify financial reports, as well as penalties for the failure to meet these requirements. In particular, the law sets forth that all corporate reports filed by a business with the Securities Exchange Commission is to be accompanied by a written statement by the chief executive officer and chief financial officer of a business certifying that the report fully complies with the requirements of section 13(a) or 15(d) of the Securities Exchange Act of 1934, and that information contained in the report fairly presents, in all material respects, the financial condition and results of operations of the business. The law further states that any chief executive officer or chief financial officer who files a report known not to be correct is to be fined up to $1,000,000 or imprisoned up to 10 years, or both.
Accordingly, a more detailed graphical representation of a business model than shown in
As with
Embodiments of the present system for generating a data model of a business architecture including its regulatory practices will now be explained with reference to
Moreover, hypothetical scenarios and changes to a business may be explored through the data model to determine the effect those scenarios and changes would have on the business without having to affect the actual changes. For example, an event may require some action be taken to comply with an applicable regulation. The data model can show the cost associated with complying with the regulation, as well as the penalties, if any, for not complying. Additionally, the data model may easily represent the effects of changes made to a business in order to conform to established best business practices. Thus, a business can easily evaluate whether the established best business practice would in actuality be beneficial to the business. The flexibility of the data model also allows for exception handling, where a parameter of the business is changed in an isolated instance before returning to normal business operations.
Referring now to
The next steps are to capture all regulatory practices that populate the repository of stand-alone regulatory practices, including all regulations that may impact a business (step 184) as well as the internal governance practices for handling the applicable business regulations (step 186). The regulatory practices may alternatively be selected from pre-existing templates as described above.
In a step 188, one or more regulatory practice properties may be defined for each of the regulatory practices described in steps 184 and 186. The regulatory practice properties describe characteristics and parameters of the regulatory practices, and are analogous to the capability attributes for the business capabilities. Examples, but by no means a complete listing, of regulatory practice properties for a given regulatory practice include:
The data model of a business architecture further includes the step 190 of formatting each of the business capabilities and capability attributes, as well as each of the regulatory practices and regulatory practice properties, according to one or more selected schemas. A system for selecting the one or more schemas to apply to a particular data model are described in greater detail in the above-incorporated patent applications. As used herein, a “schema” may be defined as an expression of a shared vocabulary between a plurality of computer systems or modules that allow the plurality of computer systems or modules to process data according to the expressed shared vocabulary. A schema can define and describe classes of data using constructs (e.g., name/value pairs) of a schema language. The schema constructs can be used to constrain and document the meaning, usage, and relationships of data types, elements and their content, attributes/properties and their values, entities and their contents, and notations, as used in a specified application, such as, for example, a business capability model. Thus, any computer system or module that can access a schema can process data in accordance with the schema. Further, any computer system or module that can access a schema can compose or modify data for use by other computer systems and/or modules that can also access the schema.
A schema can be utilized to define virtually any data type including logical, binary, octal, decimal, hexadecimal, integer, floating-point, character, character string, user-defined data types, and combinations of these data types used to define data structures. Some examples of user-defined data types are business capability attributes, regulatory practice properties, business capability/regulatory practice inputs and outputs, business capability/regulatory practice processes and business capability/regulatory practice connections. A data type can also be defined to reference or link to other data types in a schema hierarchy.
An extensible Markup Language (“XML”) schema is one example of a type of schema. An XML schema can define and describe a class of XML documents using schema constructs (e.g., name/value pairs) of an XML schema language. These schema constructs can be used to constrain and document the meaning, usage, and relationships of data types, elements and their content, attributes and their values, entities and their contents, and notations, as used in XML documents. Thus, schema is also defined to include Document Type Definitions (“DTD”), such as, for example, DTD files ending with a “.dtd” extension and World Wide Web Consortium (“W3C”) XML Schemas, such as for example, XML Schema files ending with an “.xsd” extension. However, the actually file extension for a particular DTD or XML schema is not important.
A computing device may include a software module for formatting the business capabilities, capability attributes, regulatory practices, regulatory practice properties, etc. in accordance with a selected schema. For example, the formatting module can format a “fixed cost allocation” attribute/property to be of a currency data type based on data definitions set forth in a schema.
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
Depicted in
It should be understood that schema 200 is merely one example of a business capability modeling schema. Further, modeling business capabilities and/or regulatory practices do not require that capability attributes or regulatory practice properties for all the data formats in schema 200 be accessible. For example, a capability and connector can be used to model a business capability based on capability data format 214 and connector data format 223, without accessing capability attributes corresponding to other data formats. Thus, schema 200 defines data formats for business capability attributes that are accessed, but does not require that all data formats be populated to generate a business capability model.
Referring again to
Additionally, the data model may be integrated with a business' IT architecture, as indicated above, to manage and keep track of regulatory practices, as well as to provide notifications when an event occurs related to the regulatory practices (i.e., some action to be taken to comply with an applicable regulation, some action to be taken to indicate the compliance action has or has not been taken, etc.). IT architecture may include application architecture, information architecture, and technology architecture. Therefore, in step 194, those IT services that relate to the regulatory practices, as well as those IT services that relate to the business capabilities that are impacted by a regulatory practice, are identified. These IT services are those which are in place (or which may be implemented in the IT architecture) that can automate any aspect of monitoring, managing, keeping track of, reporting on and/or implementing a regulatory practice and/or business capability impacted by a regulatory practice.
The result of step 192 is to identify regulatory practices and/or business capabilities that may potentially be automated through the business' IT architecture. For those regulatory practices and/or business capabilities identified in step 194, the next step is to link the regulatory practice properties for any identified regulatory practices, and to link the capability attributes for any identified business capability, to the IT architecture (step 196). This linking step involves integrating the regulatory practice properties and/or capability attributes into the business' administrative, operating and other databases in a known manner so that the business' IT architecture may then monitor, manage, keep track of, report on and/or implement the regulatory practices identified in step 192.
Step 198 reflects the fact that capabilities, regulatory practices and/or IT services may change, and that those changes may be easily integrated into the data model of the business.
Once the links are established in step 196, the ongoing regulatory management of the business and IT architecture will be in place to allow for exception handling and notification (whatever the cause of the exception). Linking to IT services also allows for efficient change management, whether the change comes from the IT architecture or from the performance of the business.
As an example of the operation of the present system, in the case of environmental compliance, when an item is manufactured using a specific material, a form may need to be filed with a designated agency to comply with applicable regulations. Once the regulatory practices are linked to the IT architecture, the IT service may then track the requirement of the form filing, notify the appropriate people when the requirement to file the form arises, track whether or not the appropriate form was filed, track when it was filed, etc.
As a further example, in the case of a securities regulations such as Sarbanes-Oxley, once the regulatory practices are linked to the IT architecture, the IT service may then be able to notify the person if the activity would receive Sarbanes-Oxley treatment (in cases where it's purely a mathematical analysis to determine this). This is so even though the responsible personnel may not be clear on when and under what conditions events require Sarbanes-Oxley attention.
As a further example, in the case of a time based compliance regulation, such as taxes, once the regulatory practices are linked to the IT architecture, the IT service may then provide both proactive and reactive notifications of special events and/or requirements, as well as notification when there is a compliance problem.
In embodiments, the stand-alone repository of regulatory practices may integrate efficiently with the above-described business capability model based on what a business does. However, in alternative embodiments, the regulatory practices described above may instead be used with older “subjective” business models that are based on how a business operates (as described in the Background section). In such embodiments, the regulatory practices according to the present system may still be linked to aspects of the subjective business models to provide a clearer picture of the regulatory practices of the business.
The inventive system is operational with numerous other general purpose or special purpose computing systems, environments or configurations. Examples of well known computing systems, environments and/or configurations that may be suitable for use with the inventive system include, but are not limited to, personal computers, server computers, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, laptop and palm computers, hand held devices, distributed computing environments that include any of the above systems or devices, and the like.
With reference to
Computer 310 may include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disc storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 310. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
The system memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as ROM 331 and RAM 332. A basic input/output system (BIOS) 333, containing the basic routines that help to transfer information between elements within computer 310, such as during start-up, is typically stored in ROM 331. RAM 332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 320. By way of example, and not limitation,
The computer 310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, DVDs, digital video tapes, solid state RAM, solid state ROM, and the like. The hard disc drive 341 is typically connected to the system bus 321 through a non-removable memory interface such as interface 340; magnetic disc drive 351 and optical media reading device 355 are typically connected to the system bus 321 by a removable memory interface, such as interface 350.
The drives and their associated computer storage media discussed above and illustrated in
The computer 310 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 380. The remote computer 380 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 310, although only a memory storage device 381 has been illustrated in
When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communications over the WAN 373, such as the Internet. The modem 372, which may be internal or external, may be connected to the system bus 321 via the user input interface 360, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 310, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
The foregoing detailed description of the inventive system has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the inventive system to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the inventive system and its practical application to thereby enable others skilled in the art to best utilize the inventive system in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the inventive system be defined by the claims appended hereto.
